Re: [PATCH 00/15] bitops: Change bitmap index from int to unsigned long

[Matthew Wilcox <matthew@wil.cx>]

On Wed, Feb 25, 2009 at 04:46:00PM +0100, Peter Zijlstra wrote:
> > Adding one more bit only doubles the maximum size.  That buys us, what,
> > another eighteen months until we have to change it again?  Unsigned long
> > seems most sensible to me.  Unsigned long long probably isn't worth
> > doing -- you'd have to be using one eighth of your address space on a
> > single bitmap.
> 
> Are you serious? Bitmaps of length 4G-bit (512M-byte) are way past the
> sanely allocatable size anyway.

Runtime allocatable, yes.  This particular instance was during boot.
Justin wrote:

> If the caller passes a large unsigned integer and we interpret it as
> being negative, we compute an address outside the bitmap.  This can
> cause memory corruption or other errors.

> The issue that triggered me to do this change is the routine
> mark_bootmem_node() while we ran on an ia64 box with large memory.
> As long as the EFI maps the available memory chunk at the physical
> address 0x200000000000 (or above), the routine mark_bootmem_node() will
> get the start PFN>=0x80000000.  While it calls the __free() with this
> sidx=0x80000000 (bit31 set), the bitops (test_and_clear_bit) will treat
> this idx as a negative number since it accepts it as an "int".  It turns
> out the memory outside the bitmap will be corrupted.

If we've got problems with overflowing 'int' on memory size, we'll be
overflowing 'unsigned int' in eighteen months.  0x200000000000 is large,
but we can easily add on an extra four nybbles.

I don't see the downside to using unsigned long instead of unsigned int.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."