roundup_pow_of_two() may not handle 64-bit integers

roundup_pow_of_two() may not handle 64-bit integers

[Brian Norris]

Hi,

I'm looking to use roundup_pow_of_two() (actually, order_base_2())
from <linux/log2.h>, but it seems that it only supports 64-bit integers
if your toolchain uses a 64-bit 'unsigned long' type. This is strange,
considering that ilog2() is explicitly designed for 32-bit or 64-bit
compatibility.

I also note that there is at least one location in which this limitation
currently might be problematic: in pnv_pci_ioda2_set_bypass()
(arch/powerpc/platforms/powernv/pci-ioda.c). It looks like this could be
a problem if using large amounts of DRAM on a 32-bit PPC build, with
64-bit physical addresses.

(There may be other cases like this one, but I haven't closely studied
all callers of roundup_pow_of_two().)

I'm thinking of cooking a patch to improve roundup_pow_of_two() (and
thus order_base_2()), but I'd like to solicit comments on the basic
problem first.

Regards,
Brian

P.S. And of course, rounddown_pow_of_two() has the same issue.

Re: roundup_pow_of_two() may not handle 64-bit integers

[David Howells]

Brian Norris <computersforpeace@gmail.com> wrote:

> I'm looking to use roundup_pow_of_two() (actually, order_base_2())
> from <linux/log2.h>, but it seems that it only supports 64-bit integers
> if your toolchain uses a 64-bit 'unsigned long' type. This is strange,
> considering that ilog2() is explicitly designed for 32-bit or 64-bit
> compatibility.

ilog2() was explicitly designed for use with 'unsigned long'.  See the commit
description (f0d1b0b30d250a07627ad8b9fbbb5c7cc08422e8).  It may work with
unsigned long long, however...

David

Re: roundup_pow_of_two() may not handle 64-bit integers

[Brian Norris]

On Thu, May 15, 2014 at 04:03:09PM +0100, David Howells wrote:
> Brian Norris <computersforpeace@gmail.com> wrote:
> > I'm looking to use roundup_pow_of_two() (actually, order_base_2())
> > from <linux/log2.h>, but it seems that it only supports 64-bit integers
> > if your toolchain uses a 64-bit 'unsigned long' type. This is strange,
> > considering that ilog2() is explicitly designed for 32-bit or 64-bit
> > compatibility.
> 
> ilog2() was explicitly designed for use with 'unsigned long'.  See the commit
> description (f0d1b0b30d250a07627ad8b9fbbb5c7cc08422e8).  It may work with
> unsigned long long, however...

That's another confusing point; the commit description says 'unsigned
long', but the code shows nothing of that sort, and the comments say
nearly the reverse (mentioning '32-bit and 64-bit', not 'unsigned
long'). The code only referenes ULL constants, and it selects a 32-bit
or 64-bit runtime version based on the type. To me, this demonstrates an
explicit design for "32-bit or 64-bit", regardless of the dimensions of
your 'long'.

So this leaves me with 2 main issues:

(1) Can we make <linux/ilog2.h> have some sense of consistency? If so,
    how?
     - Enforce the 'unsigned long' design (i.e., don't support
       ilog2(u64) when sizeof(unsigned long) == 4)?
     - Make all high-level macros automatically support 32-bit or 64-bit,
       regardless of type?
     - Split out 32-bit vs. 64-bit functions for everything?

    Obviously some of these options are sillier than others.

(2) Powerpc (and maybe some of SH's PCI) code has a potential bug, due
    to using roundup_pow_of_two() on type phys_addr_t, which could
    overflow for LPAE systems with large physical memory ranges. Is this
    a legitimate concern?

Brian