On Fri, Jul 08, 2011 at 03:37:09PM -0700, Dmitry Torokhov wrote: > On Fri, Jul 08, 2011 at 03:22:24PM -0700, H. Peter Anvin wrote: > > On 07/08/2011 01:46 PM, Dmitry Torokhov wrote: > > > > > > One such place is evdev read/write - unfortunately "struct input_event" > > > was not created 32/64 bit safe so we need to mangle it when running 32 > > > bit userspace with 64-bit kernels. See drivers/input/input-compat.c. > > > > > > > So these are actually present on all the read/write path system calls. > > That is truly awful. > > > > Do you happen to know if there is any kind of passing around of file > > descriptors, or if this could perhaps be tied to file descriptor state. > > Not sure. > > > > > > We also have similar issues with uinput API and uploading force-freedack > > > effects. > > > > Those are ioctl, though, if I read the code right, or did I miss > > something obvious? > > Ah, yes, indeed. > uinput uses input_event_from_user in its write path. To inject events into the kernel, one must write struct input_event into uinput. So, in this case, it's not only ioctl that is affected. Regards, Cascardo. > > > > >> but it looks like input also > > >> does things like change the format(?!) of sysfs entries, all of which > > >> makes me very concerned. > > > > > > Another historical unfortunate decision. /proc/bus/input (and later > > > added sysfs entries) export bitmaps in "compressed" form so that > > > userspace can not figure out the size of the segment (32 or 64 bit) on > > > its own so we have to convert to userspace size for longs. > > > > "Compressed form"? Could you give a concrete example? They look like > > they are emitted in text form. > > We drop leading zeroes so if you get "1 0 0 1ffff" you do not know > the bit position of the most significant '1' unless we keep segments of > known size. Unfortunately we started with 32 bit segments on 32 bit > kernels and 64 bit segments on 64 bit kernels so we coudl not simply say > that we always split on 32 bit boundary when we discovered compat > problem a few years later. > > > > > Do you have a program that someone could run to see the differences > > between compat and non-compat paths? > > Hmm, cat for /proc/bus/input/devices and sysfs nodes and evtest would > either work or give garbage if compat code woudl not work. > > -- > Dmitry > -- > 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
Attachment:
signature.asc
Description: Digital signature