Re: Race related to e04a0442d33b "HID: core: remove the absolute need of hid_have_special_driver[]"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Heiner,

On Fri, May 11, 2018 at 12:11 AM, Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote:
> Due to some other issue with one devices supported by hid-led I figured
> out that it's no longer needed to list devices with own driver in
> hid_have_special_driver[].
>
> So I removed the entries for the hid-led devices and got the following.
> When I plugged in the device first the device-specific driver wasn't
> loaded. After unplugging/re-plugging the device-specific driver was
> loaded properly.
>
> It seems usbhid module wasn't fully loaded and active yet when
> hid-generic checks for a device-specific driver for the first time.
> This also explains why the second attempt was successful.

I don't think so. When you plugged in the device, the usb core stack
emitted a uevent requesting usbhid to be loaded. Then udev loaded
usbhid, which created the USB-HID transport layer device immediately
and started probing devices attached to it. The kernel emitted then a
uevent regarding 0003:0FC5:B080, and udev answered by loading
hid-generic. hid-generic made its initialization of the HID device,
and then only now usbhid finished its initialization where it emits
"USB HID core driver".

On the second attempt, the uevent is still emitted by the kernel, but
this time udev loaded hid-led, which is detected by the hid-sstack as
a new candidate and it takes precedence over hid-generic.

Keep in mind that the kernel doesn't load external modules, but udev
does. So here, it seems we expected udev to load hid-led the first
time, but it didn't.

>
> Did you come across similar races? At a first glance I'm not sure how
> to prevent this race. Any idea?

This is related to udev and the way the uevents are emitted.
Maybe if we see the logs from "udevadm monitor" I'll be able to tell a
little bit more. Meanwhile, I'll try reproducing it locally.

Also, the v4.17-rc series has seen a little cleanup in the way
hid-generic is unbound, so it is worth a try.

Cheers,
Benjamin

>
> [   15.785205] usb 2-5: new low-speed USB device number 4 using xhci_hcd
> [   15.917766] usb 2-5: New USB device found, idVendor=0fc5, idProduct=b080, bcdDevice= 0.1f
> [   15.917842] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [   15.917899] usb 2-5: Product: USB IO Controller
> [   15.917941] usb 2-5: Manufacturer: Delcom Products Inc.
> [   15.943667] hid-generic 0003:0FC5:B080.0001: hiddev96,hidraw0: USB HID v1.00 Device [Delcom Products Inc. USB IO Controller ] on usb-0000:00:14.0-5/input0
> [   15.944171] usbcore: registered new interface driver usbhid
> [   15.944204] usbhid: USB HID core driver
> [  101.496255] usb 2-5: USB disconnect, device number 4
> [  107.364402] usb 2-5: new low-speed USB device number 5 using xhci_hcd
> [  107.496582] usb 2-5: New USB device found, idVendor=0fc5, idProduct=b080, bcdDevice= 0.1f
> [  107.496659] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [  107.496716] usb 2-5: Product: USB IO Controller
> [  107.496757] usb 2-5: Manufacturer: Delcom Products Inc.
> [  107.510676] hid-led 0003:0FC5:B080.0002: hidraw0: USB HID v1.00 Device [Delcom Products Inc. USB IO Controller ] on usb-0000:00:14.0-5/input0
> [  107.511975] hid-led 0003:0FC5:B080.0002: Delcom Visual Signal Indicator G2 initialized
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux