Re: linux-next: Tree for July 30

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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@gmail.com> 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