Re: [Xen-devel] [PATCH] only use legitimate shift counts in bitmap shifting

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Wed, 2014-04-23 at 10:11 +0100, Jan Beulich wrote:
> >>> On 23.04.14 at 11:01, <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > On Wed, 2014-04-23 at 07:50 +0100, Jan Beulich wrote:
> >> An alternative would be to remove these implicitly unused functions.
> > 
> > Why "implicitly"?
> 
> Because they have users (cpumask shifts), but those users are
> themselves unused.

So they are, I grepped but misread the answer somehow (despite it being
quite clear)

> 
> > Looks like we got this file from Linux, which I suppose is a reason to
> > keep it intact even if we aren't using these particular functions. It
> > does look like the same fix applies to Linux though.
> > 
> > Can you be explicit about which thing is illegitimate? I have inferred
> > it is when rem == 0, which leads to "upper << BITS_PER_LONG"? If you
> > make that clear in the commit message then:
> > Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> 
> Thanks - added
> 
> For rem being zero (where rem is the remainder of a division by
> BITS_PER_LONG, "upper << (BITS_PER_LONG - rem)" degenerates to
> "upper << BITS_PER_LONG", which is undefined.
> 
> despite thinking that this just describes the obvious.

It's only obvious once you have spotted it ;-) "When rem is zero" would
have been enough of a hint for me FWIW (sorry for appearing to suggest I
wanted more).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel