stack leaks resources on non-MMI session reconnect

libdvben50221 Stephan Trebels 3 participants 5 messages Jul 15, 2010 – Nov 2, 2010 Media (V4L/DVB)

Share & tools

Stephan Trebels

author

2010-07-15 13:35 UTC #0 lore raw

The issue was, that LIBDVBEN50221 did not allow a CAM to re-establish the session holding non-MMI resources if using the lowlevel interface. The session_number was recorded on open, but not freed on close (which IMO is an bug in the code, I attach the scaled down hg changeset). With this change, the SMIT CAM with a showtime card works fine according to tests so far.

The effect was, that the CAM tried to constantly close and re-open the session and the LIBDVBEN50221 kept telling it, that the resource is already allocated to a different session. Additionally this caused the library to use the _old_ session number in communications with the CAM, which did not even exist anymore, so caused all writes of CA PMTs to fail with EINTR.

Stephan

P.S. If there is a better place to report user-space library bugs for linuxtv, please let me know.

# HG changeset patch
# User Stephan Trebels <[email protected]>
# Date 1279192697 -3600
# Node ID 12928658e57ea046b35dfab485f23559b3036d42
# Parent 4ba933ff13fbd619be9bdbbf097b8dbfe0fbf679
Correctly free resources when a session is closed. This allows a CAM module to re-open a session.

lib/libdvben50221/en50221_stdcam_llci.c +13 -6

diff -r 4ba933ff13fb -r 12928658e57e lib/libdvben50221/en50221_stdcam_llci.c
@@ -374,14 +374,21 @@
 		} else if (resource_id == EN50221_APP_MMI_RESOURCEID) {
 			llci->stdcam.mmi_session_number = session_number;
 		}
+		break;
 
+	case S_SCALLBACK_REASON_CLOSE:
+		if (resource_id == EN50221_APP_MMI_RESOURCEID) {
+			llci->stdcam.mmi_session_number = -1;
+		} else if (resource_id == EN50221_APP_DATETIME_RESOURCEID) {
+			llci->datetime_session_number = -1;
+		} else if (resource_id == EN50221_APP_AI_RESOURCEID) {
+			llci->stdcam.ai_session_number = -1;
+		} else if (resource_id == EN50221_APP_CA_RESOURCEID) {
+			llci->stdcam.ca_session_number = -1;
+		} else if (resource_id == EN50221_APP_MMI_RESOURCEID) {
+			llci->stdcam.mmi_session_number = -1;
+		}
 		break;
-    case S_SCALLBACK_REASON_CLOSE:
-        if (resource_id == EN50221_APP_MMI_RESOURCEID) {
-            llci->stdcam.mmi_session_number = -1;
-        }
-
-        break;
 	}
 	return 0;
 }

DUBOST Brice

2010-08-08 21:31 UTC #1 lore raw

Re: [libdvben50221] stack leaks resources on non-MMI session reconnect.

Quoted 8 lines · Stephan Trebels

The issue was, that LIBDVBEN50221 did not allow a CAM to re-establish the session holding non-MMI resources if using the lowlevel interface. The session_number was recorded on open, but not freed on close (which IMO is an bug in the code, I attach the scaled down hg changeset). With this change, the SMIT CAM with a showtime card works fine according to tests so far.

Quoted 9 lines

The effect was, that the CAM tried to constantly close and re-open the session and the LIBDVBEN50221 kept telling it, that the resource is already allocated to a different session. Additionally this caused the library to use the _old_ session number in communications with the CAM, which did not even exist anymore, so caused all writes of CA PMTs to fail with EINTR.
Stephan

Hello

Just to inform that this patch solves problems with CAM PowerCAM v4.3, so I think it can interest more people.

Before gnutv -cammenu (and other applications using libdvben50221) was returning ti;eout (-3) errors constantly after the display of the system IDs.

Now, the menu is working flawlessly

I cannot test the descrambling for the moment but it improved quite a lot the situation (communication with th CAM is now possible).

One note concerning the patch itself, the last "else if (resource_id == EN50221_APP_MMI_RESOURCEID)" is useless.

Best regards

Signature · 3 lines

Brice

A: Yes.

Quoted 3 lines

Q: Are you sure?
Quoted 2 lines
A: Because it reverses the logical flow of conversation.
Quoted 1 line
Q: Why is top posting annoying in email?

DUBOST Brice

2010-11-02 10:22 UTC #2 lore raw

Re: [libdvben50221] stack leaks resources on non-MMI session reconnect.

Quoted 30 lines · DUBOST Brice

Quoted 8 lines · Stephan Trebels
The issue was, that LIBDVBEN50221 did not allow a CAM to re-establish the session holding non-MMI resources if using the lowlevel interface. The session_number was recorded on open, but not freed on close (which IMO is an bug in the code, I attach the scaled down hg changeset). With this change, the SMIT CAM with a showtime card works fine according to tests so far.
Quoted 9 lines
The effect was, that the CAM tried to constantly close and re-open the session and the LIBDVBEN50221 kept telling it, that the resource is already allocated to a different session. Additionally this caused the library to use the _old_ session number in communications with the CAM, which did not even exist anymore, so caused all writes of CA PMTs to fail with EINTR.
Stephan
Hello
Just to inform that this patch solves problems with CAM PowerCAM v4.3, so I think it can interest more people.
Before gnutv -cammenu (and other applications using libdvben50221) was returning ti;eout (-3) errors constantly after the display of the system IDs.
Now, the menu is working flawlessly

Quoted 9 lines

I cannot test the descrambling for the moment but it improved quite a lot the situation (communication with th CAM is now possible).
One note concerning the patch itself, the last "else if (resource_id == EN50221_APP_MMI_RESOURCEID)" is useless.
Best regards

Hello

After more testing this Patches allow several CAM models to work and don't seem to make any regression.

Is there anything to be improved/tested for having it included upstream ?

Thank you

Regards

Signature · 3 lines

Brice

A: Yes.

Quoted 3 lines

Q: Are you sure?
Quoted 2 lines
A: Because it reverses the logical flow of conversation.
Quoted 1 line
Q: Why is top posting annoying in email?

Stephan Trebels

author

2010-11-02 10:44 UTC #3 lore raw

Re: [libdvben50221] stack leaks resources on non-MMI session reconnect.

Hi Brice,

I did not find more things to be changed, and it works fine for me now. Given, that the responsiveness on this list is a bit underwhelming, I wonder whether we can find someone with commit privileges, to push this change.

Stephan

Quoted 54 lines · DUBOST Brice

Quoted 30 lines · DUBOST Brice
Quoted 8 lines · Stephan Trebels
The issue was, that LIBDVBEN50221 did not allow a CAM to re-establish the session holding non-MMI resources if using the lowlevel interface. The session_number was recorded on open, but not freed on close (which IMO is an bug in the code, I attach the scaled down hg changeset). With this change, the SMIT CAM with a showtime card works fine according to tests so far.
Quoted 9 lines
The effect was, that the CAM tried to constantly close and re-open the session and the LIBDVBEN50221 kept telling it, that the resource is already allocated to a different session. Additionally this caused the library to use the _old_ session number in communications with the CAM, which did not even exist anymore, so caused all writes of CA PMTs to fail with EINTR.
Stephan
Hello
Just to inform that this patch solves problems with CAM PowerCAM v4.3, so I think it can interest more people.
Before gnutv -cammenu (and other applications using libdvben50221) was returning ti;eout (-3) errors constantly after the display of the system IDs.
Now, the menu is working flawlessly
Quoted 9 lines
I cannot test the descrambling for the moment but it improved quite a lot the situation (communication with th CAM is now possible).
One note concerning the patch itself, the last "else if (resource_id == EN50221_APP_MMI_RESOURCEID)" is useless.
Best regards
Hello
After more testing this Patches allow several CAM models to work and don't seem to make any regression.
Is there anything to be improved/tested for having it included upstream ?
Thank you
Regards

pierre.gronlier

2010-11-02 16:18 UTC #4 lore raw

Re: [libdvben50221] stack leaks resources on non-MMI session reconnect.

Stephan Trebels wrote, On 11/02/2010 11:38 AM:

Quoted 7 lines

Hi Brice,
I did not find more things to be changed, and it works fine for me now. Given, that the responsiveness on this list is a bit underwhelming, I wonder whether we can find someone with commit privileges, to push this change.

Hi,

I've tested this patch too and it solves problems with two different cams. (powercam v4 and cryptoworks by philips)

Commiting it would be great.

Signature · 1 line

Pierre

Quoted 58 lines

Stephan
Quoted 54 lines · DUBOST Brice
Quoted 30 lines · DUBOST Brice
Quoted 8 lines · Stephan Trebels
The issue was, that LIBDVBEN50221 did not allow a CAM to re-establish the session holding non-MMI resources if using the lowlevel interface. The session_number was recorded on open, but not freed on close (which IMO is an bug in the code, I attach the scaled down hg changeset). With this change, the SMIT CAM with a showtime card works fine according to tests so far.
Quoted 9 lines
The effect was, that the CAM tried to constantly close and re-open the session and the LIBDVBEN50221 kept telling it, that the resource is already allocated to a different session. Additionally this caused the library to use the _old_ session number in communications with the CAM, which did not even exist anymore, so caused all writes of CA PMTs to fail with EINTR.
Stephan
Hello
Just to inform that this patch solves problems with CAM PowerCAM v4.3, so I think it can interest more people.
Before gnutv -cammenu (and other applications using libdvben50221) was returning ti;eout (-3) errors constantly after the display of the system IDs.
Now, the menu is working flawlessly
Quoted 9 lines
I cannot test the descrambling for the moment but it improved quite a lot the situation (communication with th CAM is now possible).
One note concerning the patch itself, the last "else if (resource_id == EN50221_APP_MMI_RESOURCEID)" is useless.
Best regards
Hello
After more testing this Patches allow several CAM models to work and don't seem to make any regression.
Is there anything to be improved/tested for having it included upstream ?
Thank you
Regards