Hi,
On 06-06-16 16:48, Greg Kroah-Hartman wrote:
On Mon, Jun 06, 2016 at 01:44:23PM +0200, Hans de Goede wrote:
Hi All,
While looking at libusb today I ended up looking at the
reap-after-disconnect code.
What stands out is that libusb expects to be able to
reap all outstanding urbs on a device on receiving
a POLL_ERR status from poll (on supported kernels).
But the usbfs poll implementation will return POLL_ERR
as soon as ps->dev->state == USB_STATE_NOTATTACHED,
and the kernel usb code sets state = USB_STATE_NOTATTACHED
some time before usbdev_remove() gets called and moves
all pending urbs to the async_completed list.
So if libusb ends up calling poll between the
setting state = USB_STATE_NOTATTACHED and usbdev_remove()
being called then it ends up not reaping all urbs
since it will stop monitoring the device after
the first POLL_ERR.
I'll write a libusb fix for this, but I'm wondering if this
is something which we also want to fix on the kernel side?
Would fixing this in the kernel mean that libusb fixes are not needed?
If so, I would recommend doing this.
A kernel side fix is non trivial, whereas the libusb fix is trivial
since we also need to deal with kernels which do not support
reaping urbs after disconnect at all.
Basically the question is, do we consider not being able to
reap all urbs after the first POLL_ERR a kernel bug, or should
userspace keep track of how many urbs it has outstanding and
call the reap ioctl (with some msleep after failure) until it
has reaped all urbs ?
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
