[Pcsclite-muscle] Fix libudev hotplug

[Ludovic Rousseau]

2014-07-07 14:22 GMT+02:00 Stefani Seibold <stefani at seibold.net>:
> Hi,

Hello,

> the current libudev hotplug code have some issues.
>
> The HPRegisterForHotplugEvents() does first a HPRescanUsbBus() and than
> start the HPEstablishUSBNotifications() thread. This could lead in a
> race condition, where a add event occurred  between the scan and the
> start of the thread. I moved the scan after the
> udev_monitor_enable_receiving() call, so the race is fixed.

Do you get this problem in a real use case or is it theoretical?

If you do get the problem in real life what is your application use case?

> Next: The HPRescanUsbBus() is broken too. It will set all
> readerTracker.status to READER_ABSENT. This make it very hard to track
> reader where added twice. This can happen due the fix above and due the
> fact that any udev event in the origin code could lead to a add, because
> the "remove" event whill call HPRescanUsbBus() which calls
> HPAddDevice(). This problem could be fixed using a temporary array of
> status bytes.

It looks like the problem is that HPRescanUsbBus() is not reentrant by
using a global state.
But HPRescanUsbBus() is only called from HPEstablishUSBNotifications()
when a device is removed. The call to HPRescanUsbBus() is synchronous
and thus HPEstablishUSBNotifications() can't call HPRescanUsbBus()
again before the previous call has returned.

So unless you modify the code to try solve the 1st issue the use of
HPRescanUsbBus() should be correct and safe.

> And at last the HPAddDevice() is broken because a SCARD_E_UNKNOWN_READER
> status could never overwriten. But the "remove" event handling which
> also do device adds it could happen that a HPRescanUsbBus() will try to
> add a device via HPAddDevice() which is still in use by other processes
> or not ready. So a device should not permanently marked as
> SCARD_E_UNKNOWN_READER because when the udev "add" event arrives than
> the device should be normaly accessible.

I do not follow you here.
What do you call "a device [..] which is still in use by other
processes or not ready."

If the driver can't use the device then the device is marked
SCARD_E_UNKNOWN_READER.
If the device need more time so the driver can use it then the driver
should wait for the device to be ready before returning
IFD_NO_SUCH_DEVICE error code.

A device has no second chance of being detected. It works or it does not.

> The following small patch fix all this issues.

Thanks for your patch.
First I need to understand what the problems are so I can work on
unitary tests and verify the problems are really solved.

It looks like you are working with virtual machines and moving USB
devices from one virtual machine to another. Is that the case?

Regards,

-- 
 Dr. Ludovic Rousseau