Re: INPUT_COMPAT_TEST

On Fri, Jul 08, 2011 at 03:22:24PM -0700, H. Peter Anvin wrote:

On 07/08/2011 01:46 PM, Dmitry Torokhov wrote:

quoted

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.

quoted

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.

quoted

quoted

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