linux-kernel - Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Jan 2011 15:32:13 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Mark Lord <kernel@...savvy.com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils
 ?

Em 26-01-2011 13:05, Mark Lord escreveu:
> On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
>> On Tue, Jan 25, 2011 at 03:29:14PM -0800, Dmitry Torokhov wrote:
>>> On Tue, Jan 25, 2011 at 05:22:09PM -0500, Mark Lord wrote:
>>>> On 11-01-25 05:00 PM, Mauro Carvalho Chehab wrote:
>>>>> Em 25-01-2011 18:54, Dmitry Torokhov escreveu:
> ..
>>>>>> That has been done as well; we have 2 new ioctls and kept 2 old ioctls.
>>>>
>>>> That's the problem: you did NOT keep the two old ioctls().
>>>> Those got changed too.. so now we have four NEW ioctls(),
>>>> none of which backward compatible with userspace.
>>>>
>>>
>>> Please calm down. This, in fact, is not new vs old ioctl problem but
>>> rather particular driver (or rather set of drivers) implementation
>>> issue. Even if we drop the new ioctls and convert the RC code to use the
>>> old ones you'd be observing the same breakage as RC code responds with
>>> -EINVAL to not-yet-established mappings.
>>>
>>> I'll see what can be done for these drivers; I guess we could supply a
>>> fake KEY_RESERVED entry for not mapped scancodes if there are mapped
>>> scancodes "above" current one. That should result in the same behavior
>>> for RCs as before.
>>>
>>
>> I wonder if the patch below is all that is needed...
> 
> 
> Nope. Does not work here:
> 
> $ lsinput
> protocol version mismatch (expected 65536, got 65537)

You need to relax the version test at the tree. As I said before, this is
a development tool from the early RC days, bound to work with one specific
version of the API, and programmed by purpose to fail if there would by any
updates at the Input layer.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/