Bug 3571 - pcsctund.exe race condition
Summary: pcsctund.exe race condition
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Smart card (show other bugs)
Version: 3.0.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Pierre Ossman
Depends on:
Reported: 2010-07-01 10:56 CEST by Peter Åstrand
Modified: 2021-10-01 12:25 CEST (History)
0 users

See Also:
Acceptance Criteria:

tlclient.log (30.91 KB, text/plain)
2010-07-01 11:05 CEST, Peter Åstrand

Description Peter Åstrand cendio 2010-07-01 10:56:02 CEST
There seems to be a race condition in pcsctund. Using TL server 3.1.0 (demo system) and the Windows client on my XP laptop, I've managed to hang pcsctund. I've done: 

* In one console window, executed:
while true; do pkcs15-tool -c; done

* In another console window:

In some cases, pcsctund hangs as soon as Net ID on the WTS starts working. In some other cases, the hang occurs if I disconnect+reconnect the TL client.
Comment 1 Peter Åstrand cendio 2010-07-01 11:05:00 CEST
Created attachment 366 [details]
Comment 2 Peter Åstrand cendio 2010-07-01 11:09:02 CEST
The problem has been verified with build 2638, as well as the 3.1.0 client. 
Comment 3 Pierre Ossman cendio 2010-07-01 11:22:33 CEST
Looks like we need to start treating every PC/SC call as potentially blocking, which means a redesign of the pcsctun architecture where a new thread is created for every call.
Comment 4 Peter Åstrand cendio 2010-07-01 11:34:33 CEST
Since this is not a regression, it's not a 3.1.1 showstopper. 
Comment 5 Pierre Ossman cendio 2014-09-05 10:18:48 CEST
We've been running in to similar problems with rdesktop and it's interaction with pcsc-lite, and just treating every call as potentially blocking might not be enough.

The new idea is to give up on the principle of pcsctun being a simple RPC transport. Instead we separate the PC/SC interface presented to the clients from the backend PC/SC calls to the local system. E.g. we might only have a single SCardGetStatusChange() being made to the local system and multiplex this ourselves to all such calls that are waiting from the clients.

The point of this is that we can carefully create and use contexts in a way that avoids dead locks. The pcsc-lite architecture blocks the entire context if you have an ongoing blocking call on it. So we would need at least three contexts; one for SCardGetStatusChange(), one for SCardBeginTransaction(), and one for all non-blocking calls. Incoming calls would be multiplexed between these as necessary.

See also bug 3404 for rdesktop, as it probably needs the same kind of work and we can probably share code/design.

Note You need to log in before you can comment on or make changes to this bug.