Re: [PATCH 6/10] hpsa: use safer test on the result of find_first_zero_bit

[scameron]

On Wed, Jun 04, 2014 at 05:06:44PM +0200, Julia Lawall wrote:
> 
> 
> On Wed, 4 Jun 2014, scameron@xxxxxxxxxxxxxxxxxx wrote:
> 
> > On Wed, Jun 04, 2014 at 11:07:56AM +0200, Julia Lawall wrote:
> > > From: Julia Lawall <Julia.Lawall@xxxxxxx>
> > >
> > > 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.
> > >
> > > The semantic match that finds this problem is as follows:
> > > (http://coccinelle.lip6.fr/)
> > >
> > > // <smpl>
> > > @@
> > > expression e1,e2,e3;
> > > statement S1,S2;
> > > @@
> > >
> > > e1 = find_first_zero_bit(e2,e3)
> > > ...
> > > if (e1
> > > - ==
> > > + >=
> > >   e3)
> > > S1 else S2
> > > // </smpl>
> > >
> > > Signed-off-by: Julia Lawall <Julia.Lawall@xxxxxxx>
> > >
> > > ---
> > >  drivers/scsi/hpsa.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff -u -p a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> > > --- a/drivers/scsi/hpsa.c
> > > +++ b/drivers/scsi/hpsa.c
> > > @@ -4703,7 +4703,7 @@ static struct CommandList *cmd_alloc(str
> > >  	spin_lock_irqsave(&h->lock, flags);
> > >  	do {
> > >  		i = find_first_zero_bit(h->cmd_pool_bits, h->nr_cmds);
> > > -		if (i == h->nr_cmds) {
> > > +		if (i >= h->nr_cmds) {
> > >  			spin_unlock_irqrestore(&h->lock, flags);
> > >  			return NULL;
> > >  		}
> >
> > Thanks, Ack.
> >
> > You can add
> >
> > Reviewed-by: Stephen M. Cameron <scameron@xxxxxxxxxxxxxxxxxx>
> >
> > to this patch if you want.
> >
> > You might also consider adding "Cc: stable@xxxxxxxxxxxxxxx" to the sign-off area.
> 
> Actually, it seems that the function can never overshoot the specified
> limit.  So the change is not needed.

Well, that would explain why nobody has complained about it in all these years.
I figured that must have been the case at least on x86, but I thought maybe
other archictectures might behave differently, and the change seemed harmless
in any case. 

-- steve


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