On Wednesday 10 October 2012 15:11:29 Bjørn Mork wrote: > Oliver Neukum <oliver@xxxxxxxxxx> writes: > > > For mice with card readers the HID driver can deadlock > > as its post_reset() method allocates memory. GFP_NOIO > > must be used in a block layer error handler, which > > usbhid can be indirectly part of. > > I am wondering a bit where this will eventually end. Given enough time, > I assume we will see all USB interface drivers attached to some > composite device with a usb-storage function. Although it probably Yes. Even worse, we are getting more block drivers (uas) A need to put PTP into kernel space may arise and so on. > won't hurt that much, it feels somewhat wrong to put unnecessary > restrictions into all existing interface drivers just because there is > some device which in theory could cause the driver to lockup. After > all, I am pretty sure that more than 99% of the devices using the mouse > driver won't have a card reader. We support all valid configurations. > Instead of assuming the worst, wouldn't it make more sense to add some > real knowledge about the composite device restrictions at the device > level, and then use this knowledge in the interface drivers? Well, the code would be more complex, not easier. > Maybe let drivers like usb-storage register a restriction and create a > pm_or_reset_gfp(struct usb_device *) function returning the appropriate > flag for the other interface drivers? This function could the return > GFP_KERNEL to the mouse driver for the common single HID function > device, and GFP_NOIO for the composite mouse+storage device. It would be much, much easier to just unconditionally use GFP_NOIO. Regards Oliver -- 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
