linux-kernel - Re: [PATCH] lis3lv02d: Avoid zero-division

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] [day] [month] [year] [list]

Date:	Mon, 14 Nov 2011 15:59:06 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Éric Piel <eric.piel@...mplin-utc.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lis3lv02d: Avoid zero-division

At Fri, 11 Nov 2011 19:11:06 +0100,
Éric Piel wrote:
> 
> Op 08-11-11 07:19, Takashi Iwai schreef:
> > At Tue, 08 Nov 2011 04:57:42 +0100,
> > Éric Piel wrote:
> >>
> >> Op 03-11-11 13:09, Takashi Iwai schreef:
> >>> In some weird situation, HP DriveGuard chip can't read ODR value
> >>> correctly, and it results in a zero-division Oops in lis3lv02d driver.
> >>> This patch fixes the Oops by checking the value appopriately, and skips
> >>> if any weird value is read.
> >> Hi Takashi,
> >> Actually, a similar patch already just landed in linus' tree:
> >> 1510dd5954 (lis3lv02d: avoid divide by zero due to unchecked)
> >>
> >> However, in the patch applied, the device is disabled (until next
> >> reboot) while in yours, the sleep is just skipped. Does it work again
> >> after the read of odr fails? If so, maybe I could improve the current
> >> version by, after the odr read fails, sleeping a long and safe time and
> >> then trying to read the odr again. Then if it fails again, we give up,
> >> otherwise the device can be used again.
> >
> > I guess it's possible to use the device afterward.  The possible
> > reason is either the chip is set to an invalid mode or ACPI isn't set
> > up properly.  But this path usually means that ACPI does work more or
> > less since you could read WHOAMI.
> >
> >> Do you have such a device yourself? Could you let me know if after a
> >> failing read of the odr, the device keeps working?
> >
> > I have a machine but I'm not quite sure how to reproduce this error.
> > It happened casually during the installation of a new system, so it's
> > not so trivial to switch the module during it...
> Dear Takashi,
> 
> I've looked more at the error. Now it seems to me that the fact that 
> get_odr() returns 0 is not because there is a problem with the device 
> but just because it is powered off: for the "3dc" device, this reflects 
> in rate of 0. We assume that the ACPI code does turn the device on, but 
> it might not do it, or the device might still need more time to fully 
> initialize. So, just turning the device on and waiting a bit long should 
> work fine.

Sounds reasonable.  FWIW, I got the zero-division error only in a rare
case, while the installation of a system.

> However, looking for the spec document of lis3dc (or hp3dc), I couldn't 
> find any reference to such device. I've found documents for lis3dh, with 
> apparently same registers and WHOAMI value. However, contrarily to what 
> is currently expected, it's a 16-bit device, not 8-bit. So my main 
> question is: are you sure the device you have is 8-bit? Isn't your 
> device a 16-bit lis3dh? Do you have the spec of lis3dc/hp3dc?

The device works with 8bit mode well, and the values I get from the
joystick device is almost same as the old lis3 chip on other HP
laptops.  So I suppose this is 8bit device.

I have also no spec for this chip.  I was informed from HP a little
bit about their new stuff to add the support in hp_accel driver, but
not in details, unfortunately.


thanks,

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