[PATCH 0/10] use safer test on the result of find_first_zero_bit
julia.lawall at lip6.fr
Wed Jun 4 02:52:32 PDT 2014
On Wed, 4 Jun 2014, David Laight wrote:
> From: Julia Lawall
> > On Wed, 4 Jun 2014, Geert Uytterhoeven wrote:
> > > Hi Julia,
> > >
> > > On Wed, Jun 4, 2014 at 11:07 AM, Julia Lawall <Julia.Lawall at lip6.fr> wrote:
> > > > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
> > > > return a larger number than the maximum position argument if that position
> > > > is not a multiple of BITS_PER_LONG.
> > >
> > > Shouldn't this be fixed in find_first_zero_bit() instead?
> > OK, I could do that as well. Most of the callers currently test with >=.
> > Should they be left as is, or changed to use ==?
> Do we want to add an extra test to find_first_zero_bit() and effectively
> slow down all the calls - especially those where the length is a
> multiple of 8 (probably the most common).
Currently, most of the calls test with >=, and most of the others seem to
need to (either the size value did not look like a multiple of anything in
particular, or it was eg read from a device).
Note that it is BITS_PER_LONG, so it seems like it is typically 32 or 64,
> Maybe the documented return code should be changed to allow for the
> existing behaviour.
Sorry, I'm not sure to understand what you suggest here.
More information about the ath10k