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. > > >> 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
