On Thu, Jul 31, 2008 at 11:55:38AM -0700, Andrew Morton wrote: > On Thu, 31 Jul 2008 14:34:41 -0400 > Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > > > > > > No. The X driver is broken. It tells kernel to use buffer bugger than > > > > > > allocated and gets its stack smashed. Tslib has also soma funkiness > > > > > > in the ioctl handling as well... *shrug* > > > > > > > > > > > > We have a couple months to get distros updated... > > > > > > > > > > > > > > > > aaarrrrgggggghhh. I don't think this is practical. This means that > > > > > (for example) FC5 machines (of which I happen to have one) are dead. > > > > > And lots of other older-distro-based systems. > > > > > > > > > > Is there some userspace workaround which doesn't require an X server > > > > > update? > > > > > > > > > > Surely it must be possible to make the kernel contiue to support these > > > > > servers? > > > > > > > > > > > > > Andrew, > > > > > > > > It is not like we broke ABI here. The progam (synaptics driver) had a > > > > grave bug. Older kernels happened to paper over the bug because they > > > > did not fill the whole buffer that was advertised as available. Now > > > > that we have more data to report the bug bit us. What do you want me > > > > to do? > > > > > > Paper over the bug again. When it happens, spit out a loud printk. > > > > For that we we need to be sure that the size of the buffer passed to > > us is incorrect. I.e. if we decide that 512 is a magic bad number and > > decide to limit the output then legit programs supplying 512 byte > > buffers they will not get the whole thing. > > uh. I'm still scrabbling to understand all this. Where is the > information about this kept? Which commit caused this problem to > occur? > It is commit "Input: expand keycode space" (git log include/linux/input.h) > It _sounds_ like userspace is passing in a buffer and is also passing > in an incorrect (too large) `size' parameter, yes? > Yes. > This is an ioctl interface? Yes. > Could we leave the old ioctl unchanged and > introduce the offending changes into a new ioctl number? > Then you will punish other users of this ioctl (the ones that use it correctly). X proper, HAL, DirectFB, etc, etc. They will have to implement the new interface just because of other programs having an issue. > > > > > > > Synaptics driver is a small package and takes 2 minutes to recompile. > > > > You don't have to update entire X server with it (in fact I don't think > > > > it is even part of X distribution because it is GPL). > > > > > > What proportion of the X servers out there did we just break? > > > > > > Was the crash I saw due to this? > > > > > > Where would I (Aunt Tillie running FC5) go to find out how to fix my > > > machine up again? > > > > What is Aunt Tillie doing compiling her own kernels on FC5? You > > OTOH managed to get an answer fairly quickly ;) > > I'll ask again: where do our users go to find out how to make their X > server work again? If the answer is "nowhere" then can we please at > least write up a simple step-by-step repair procedure, as we'll surely > be needing it a lot. > Changes? We could also get Peter to add some verbage onto his web-page that hosts the driver. We are looking at .28 release for this code so we have some time. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
