[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140604151410.GF6970@beardog.cce.hp.com>
Date: Wed, 4 Jun 2014 10:14:10 -0500
From: scameron@...rdog.cce.hp.com
To: Julia Lawall <julia.lawall@...6.fr>
Cc: kernel-janitors@...r.kernel.org,
"James E.J. Bottomley" <JBottomley@...allels.com>,
iss_storagedev@...com, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org, scameron@...rdog.cce.hp.com
Subject: Re: [PATCH 6/10] hpsa: use safer test on the result of find_first_zero_bit
On Wed, Jun 04, 2014 at 05:06:44PM +0200, Julia Lawall wrote:
>
>
> On Wed, 4 Jun 2014, scameron@...rdog.cce.hp.com wrote:
>
> > On Wed, Jun 04, 2014 at 11:07:56AM +0200, Julia Lawall wrote:
> > > From: Julia Lawall <Julia.Lawall@...6.fr>
> > >
> > > 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@...6.fr>
> > >
> > > ---
> > > 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@...rdog.cce.hp.com>
> >
> > to this patch if you want.
> >
> > You might also consider adding "Cc: stable@...r.kernel.org" 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@...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