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:	Tue, 10 Mar 2009 18:17:13 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Daniel Mack <daniel@...aq.de>
Cc:	linux-kernel@...r.kernel.org, syrjala@....fi, johnpol@....mipt.ru,
	david-b@...bell.net
Subject: Re: [PATCH] drivers/w1/masters/w1-gpio.c: fix read_bit()

On Wed, 11 Mar 2009 01:10:48 +0100 Daniel Mack <daniel@...aq.de> wrote:

> On Tue, Mar 10, 2009 at 03:00:59PM -0700, Andrew Morton wrote:
> > > > We recently merged a patch (I forget where) which fixed one
> > > > gpio_get_value() implementation so that it always returns 0 or 1.
> > > > 
> > > > From which I deduce that the correct fix for <whatever problem you're
> > > > seeing> is to fix <whichever driver that is>?
> > > 
> > > I agree those functions should return 0 and 1 only, but my patch fixes
> > > the w1-gpio driver for all platforms at once, so people can use it.
> > > 
> > > On the other hand, I will submit a patch which modifies PXA's
> > > gpio_get_value() and see what the maintainers say, but I can't go thru
> > > all the implemenations of all architectures to do this.
> > > 
> > > So for the time being, the above patch helps many users of that driver.
> > > 
> > 
> > Problem is, the patch will just conceal bugs.
> 
> There is a small discussion about that on the arm-linux mailing list and
> what people pointed out there is that gpio_get_value() is _not_ supposed
> to return 0 or 1 only, also according to Documentation/gpio.txt:
> 
> 	Use these calls to access such GPIOs:
> 
>         /* GPIO INPUT:  return zero or nonzero */
> 	int gpio_get_value(unsigned gpio);
> 
> Hence, any implementation of gpio_get_value() which returns 0 and 1 only
> is conform to the docs, but PXA's (which doesn't follow that rule) is as
> well. And that means that any driver using that function has to deal
> with values > 1 being returned by it, right?
> 
> Correct me if I missed the point, but I don't see how my patch will
> conceal any bug?
> 

Actually, I misremembered the discussion: http://lkml.org/lkml/2009/2/15/114

This "optimisation" has caused two bugs so far.  And it's forcing
callers of the "optimised" function to perform a test-n-branch for
something which the low-level function could have done with a shift.

Sigh, what a crock.  I'll go dig out your original fix.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ