linux-kernel - Re: [PATCH] [media] imon: don't submit urb before rc

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 for Android: free password hash cracker in your pocket

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

Message-Id: <D7E52A85-331A-4650-94F0-C1477F457457@redhat.com>
Date:	Tue, 19 Jul 2011 08:23:19 -0400 (EDT)
From:	Jarod Wilson <jwilson@...hat.com>
To:	Chris W <lkml@...chogeeks.com>
Cc:	Jarod Wilson <jarod@...hat.com>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	Andy Walls <awalls@...metrocast.net>,
	Randy Dunlap <rdunlap@...otime.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [media] imon: don't submit urb before rc_dev set up

On Jul 18, 2011, at 6:29 PM, Chris W <lkml@...chogeeks.com> wrote:

> On 19/07/11 02:46, Jarod Wilson wrote:
>> The interface 0 urb callback was being wired up before the rc_dev device
>> was allocated, meaning the callback could be called with a null rc_dev,
>> leading to an oops. This likely only ever happens on the older 0xffdc
>> SoundGraph devices, which continually trigger interrupts even when they
>> have no valid keydata, and the window in which it could happen is small,
>> but its actually happening regularly for at least one user, and its an
>> obvious fix. Compile and sanity-tested with one of my own imon devices.
> 
> As the "at least one user" I can confirm that the patch has indeed
> corrected the problem on my 2.6.38-gentoo-r6, 2.6.39.3 vanilla, and
> 3.0.0-rc7 kernels.
> 
> This is what loading the module with the "debug=1" option outputs:
> 
> input: iMON Panel, Knob and Mouse(15c2:ffdc) as
> /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input7
> imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00)

Ugh, damn, that change broke the ffdc device auto-detection... Better than a crash, but lemme see if I can alter things slightly so we can have our cake and eat it too...


> Registered IR keymap rc-imon-pad
> input: iMON Remote (15c2:ffdc) as
> /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc2/input8
> rc2: iMON Remote (15c2:ffdc) as
> /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc2
> imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb<4:3> initialized
> usbcore: registered new interface driver imon
> intf0 decoded packet: 00 00 00 00 00 00 24 01
> intf0 decoded packet: 00 00 00 00 00 00 24 01
> intf0 decoded packet: 00 00 00 00 00 00 24 01
> intf0 decoded packet: 00 00 00 00 00 00 24 01
> ...
> 
> The decoded packet lines are fast and furious with no deliberate IR
> input (the VFD is in use), which might explain how this device managed
> to break the code in the small window available.

Yep. I hate hate hate hate the ffdc imon hardware, for this and multiple other reasons (including the nasty hack used for ffdc device type auto-detection)... My ffdc devices do similar constant spewing, but never triggered the oops, so maybe yours is even worse, or your system is faster, or a kernel config change made a difference here...


> Thank you Jarod and Andy for taking the time to track this problem down
> to give it a drubbing.

Thanks for the testing and patience, hopefully just one more patch to test out before we can say case closed here...

--jarod
--
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/