On Fri, Jul 08, 2011 at 04:18:11PM -0700, H. Peter Anvin wrote: > On 07/08/2011 03:37 PM, Dmitry Torokhov wrote: > >> > >>> 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. > > > > So the point still holds... you're right now using INPUT_COMPAT_TEST for > those, but what you *should* use is whether or not you were entered via > the compat ioctl entry point. Since we still do need (at least for now) INPUT_COMPAT_TEST in non-ioctl paths it does not matter much. > > >> > >>>> 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. > > Ah yes, it is the "binary output masquerading as text, so we end up with > something that is worse a mess than either" problem. > > >> > >> 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. > > > > I'm desperately trying to come up with a solution which doesn't require > us to replicate every single system call (which is what relying on > is_compat_task() does -- it remembers the entry point used) in order > support one single misdesigned subsystem. Do you have any kind of ideas > for what we might be able to do? Input only need to do this compat stuff on read/write paths so maybe if you add plumbing similar to compat_ioctl we could switch owver to it. Thanks. -- 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
