On Wed, Jun 12, 2024 at 8:17 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, May 27, 2024 at 03:55:57PM -0400, Jason Andryuk wrote:
From: Dmitry Torokhov dmitry.torokhov@gmail.com
commit 0774d19038c496f0c3602fb505c43e1b2d8eed85 upstream.
If an input device declares too many capability bits then modalias string for such device may become too long and not fit into uevent buffer, resulting in failure of sending said uevent. This, in turn, may prevent userspace from recognizing existence of such devices.
This is typically not a concern for real hardware devices as they have limited number of keys, but happen with synthetic devices such as ones created by xen-kbdfront driver, which creates devices as being capable of delivering all possible keys, since it doesn't know what keys the backend may produce.
To deal with such devices input core will attempt to trim key data, in the hope that the rest of modalias string will fit in the given buffer. When trimming key data it will indicate that it is not complete by placing "+," sign, resulting in conversions like this:
old: k71,72,73,74,78,7A,7B,7C,7D,8E,9E,A4,AD,E0,E1,E4,F8,174, new: k71,72,73,74,78,7A,7B,7C,+,
This should allow existing udev rules continue to work with existing devices, and will also allow writing more complex rules that would recognize trimmed modalias and check input device characteristics by other means (for example by parsing KEY= data in uevent or parsing input device sysfs attributes).
Note that the driver core may try adding more uevent environment variables once input core is done adding its own, so when forming modalias we can not use the entire available buffer, so we reduce it by somewhat an arbitrary amount (96 bytes).
Reported-by: Jason Andryuk jandryuk@gmail.com Reviewed-by: Peter Hutterer peter.hutterer@who-t.net Tested-by: Jason Andryuk jandryuk@gmail.com Link: https://lore.kernel.org/r/ZjAWMQCJdrxZkvkB@google.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com [ Apply to linux-6.1.y ] Signed-off-by: Jason Andryuk jason.andryuk@amd.com
Patch did not automatically apply to 6.1.y because input_print_modalias_parts() does not have const on *id.
Tested on 6.1. Seems to also apply and build on 5.4 and 4.19.
How was this tested?
I built a kernel for 6.1.92 + this patch and booted a VM with it. Inside, I used udevadm and looked at the sysfs entries for xen-kbdfront.ko.
For 5.4 and 4.19, I just built the module with `make drivers/input/misc/xen-kbdfront.ko`. I see now that misses building the actual change. Sorry about that.
It blows up the build on all branches, 6.1 and older kernels with a ton of errors like: drivers/input/input.c: In function ‘input_print_modalias_parts’: drivers/input/input.c:1397:40: error: passing argument 4 of ‘input_print_modalias_bits’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers] 1397 | 'e', id->evbit, 0, EV_MAX); | ~~^~~~~~~
Re-building, I see these as warnings. I don't have -Werror, so they were non-fatal, and I missed when in the scroll of the full kernel build.
Sorry about this. I'm preparing new patches.
Regards, Jason