Created attachment 293411 [details] journal -k during the error When docking my laptop (Lenovo T470s, to a traditional docking station), running 5.8.16-300.fc33.x86_64, sometimes (every other time or so), the kernel runs into a page allocation failure when adding one of the HID device associated with the USB keyboard attached to the docking station. When this does *not* happen, three evdev devices appear for the keyboard: /dev/input/event11: TypeMatrix.com USB Keyboard /dev/input/event12: TypeMatrix.com USB Keyboard System Control /dev/input/event13: TypeMatrix.com USB Keyboard Consumer Control The third device emits events such as Volume Up, Volume Down etc. The first emits events such as regular A-Z keys. Available HID devices are /dev/hidraw3: TypeMatrix.com USB Keyboard /dev/hidraw4: TypeMatrix.com USB Keyboard The first emits A-Z keys etc, while the second emits Volume up/down etc. When the page allocation failure happens, the raw HID devices remain the same and functioning, but the only evdev devices that appear are event11 and event12, missing event13, thus missing Volume up/down events. Replugging the keyboard enough times will make it work correctly again, most of the times. I'm attaching a journal -k for when it happens, containing the backtrace to the page allocation failure.
Unless the memory allocated by the hid driver needs to be physically contiguous, it should use kvmalloc(_array) instead of kmalloc(_array) (and kvfree instead of kfree) where it can be larger than a single page.
> Unless the memory allocated by the hid driver needs to be physically > contiguous, it should use kvmalloc(_array) instead of kmalloc(_array) (and > kvfree instead of kfree) where it can be larger than a single page. hmm, that is a good lead. I'll have to double check but I don't think the allocated memory should be that big. I am worried that using kvmalloc would paper over an other problem and we'll eat up all the memory by just plugging a keyboard...
(In reply to Benjamin Tissoires from comment #2) > I'll have to double check but I don't think the allocated memory should be > that big. order:5 means 32 physically contiguous pages.
... and allocating 32 physically contiguous pages can be difficult/expensive under any circumstances. (I happen to be aware of this issue because DRM drivers keep hitting it as well :)
32 pages for a single field suggests that there is a garbage in the descriptor and blindly converting to kvmalloc_array() is indeed simply papering over the problem. I suggest you post hid report descriptor and maybe instrument hid-core.c::hid_register_field() to see what number of usages and values it is being asjed to allocate.