Looks OK to me, apart from the mentions of libusb rather than libusbx,
which I'll fix when applying to mainline.
Also maybe a shorter description of the issue, with a link to the
relevant thread for further clarifications would go down better, as the
commit message will be quite verbose otherwise (though to be fair, I
don't exactly care that much about a git commit messages being 10,000
words long)
I'm planning to wait for the 2 previous patches to have been sorted out
before applying this one.
Regards,
/Pete
On 2012.08.21 10:12, Hans de Goede wrote:
> Currently applications for devices which only are accessed from userspace
> can use claim / release interface to make sure they don't get in each others
> way. The same however does not work for applications which first need to
> detach
> a "native" / in kernel driver, as this detach will not only detach native
> drivers but also the usbfs driver, thus stealing the device from another
> userspace / libusb app.
>
> This patch fixes libusb_detach_kernel_driver to only detach "real" kernel
> drivers and not the special usbfs driver used for userspace access to
> USB devices. If the usbfs driver is found LIBUSB_ERROR_NOT_FOUND will be
> returned to indicate no driver was detached.
>
> Note that the check beforen detach this patch does is theoretically sensitive
> to a race. And most apps which detach drivers want to do a detach then claim,
> which again is sensitive to a race. To fix both races, work is underway to add
> a new USBDEVFS_DETACH_CLAIM ioctl to the Linux kernel, which:
> 1) Checks if the driver which will be detach matches or does not match the
> specified driver (optional, can be used to exclude usbfs from detaching)
> 2) Detaches the driver
> 3) Claims the interface
> All in one, race free kernel call.
>
> Still we also want and need the usbfs check here because:
> 1) The new ioctl requires a new libusb function to match, and older apps will
> still be using the old way, and not checking in the old way is causing real
> world problems now, where as the race is mostly theoretical.
> 2) The new libusb function for detach_and_claim will fallback to doing a
> separate detach, then claim on older kernels, and we want to do the right
> thing there too.
>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>
> ---
> libusb/core.c | 4 ++++
> libusb/os/linux_usbfs.c | 6 ++++++
> 2 files changed, 10 insertions(+)
>
> diff --git a/libusb/core.c b/libusb/core.c
> index 7c2f4d7..4c513f7 100644
> --- a/libusb/core.c
> +++ b/libusb/core.c
> @@ -1513,6 +1513,10 @@ int API_EXPORTED
> libusb_kernel_driver_active(libusb_device_handle *dev,
> *
> * This functionality is not available on Darwin or Windows.
> *
> + * Note that libusb itself also talks to the device through a special kernel
> + * driver, if this driver is already attached to the device, this call will
> + * not detach it and return LIBUSB_ERROR_NOT_FOUND.
> + *
> * \param dev a device handle
> * \param interface_number the interface to detach the driver from
> * \returns 0 on success
> diff --git a/libusb/os/linux_usbfs.c b/libusb/os/linux_usbfs.c
> index 487b94e..462b772 100644
> --- a/libusb/os/linux_usbfs.c
> +++ b/libusb/os/linux_usbfs.c
> @@ -1538,12 +1538,18 @@ static int op_detach_kernel_driver(struct
> libusb_device_handle *handle,
> {
> int fd = _device_handle_priv(handle)->fd;
> struct usbfs_ioctl command;
> + struct usbfs_getdriver getdrv;
> int r;
>
> command.ifno = interface;
> command.ioctl_code = IOCTL_USBFS_DISCONNECT;
> command.data = NULL;
>
> + getdrv.interface = interface;
> + r = ioctl(fd, IOCTL_USBFS_GETDRIVER, &getdrv);
> + if (r == 0 && strcmp(getdrv.driver, "usbfs") == 0)
> + return LIBUSB_ERROR_NOT_FOUND;
> +
> r = ioctl(fd, IOCTL_USBFS_IOCTL, &command);
> if (r) {
> if (errno == ENODATA)
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
