Re: linux-next: Tree for July 30

Dmitry Torokhov
2008-07-31T19:03:51Z

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