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]

 



Am 14.05.2018 um 11:58 schrieb Benjamin Tissoires:
> 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.
> 
I used the latest linux-next kernel, so I assume these changes should
be included. When trying to create the "udevadm monitor" log I found
that I can't reproduce the issue. Hmm, strange ..
I will keep an eye on it. Until then: sorry for the noise.

Heiner

> 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-usb" 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]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux