[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1235544888.4645.2942.camel@laptop>
Date: Wed, 25 Feb 2009 07:54:48 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Justin Chen <jchen@...st41.cup.hp.com>
Cc: linux-arch@...r.kernel.org, bjorn.helgaas@...com,
justin.chen@...com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/15] bitops: Change bitmap index from int to unsigned
long
On Tue, 2009-02-24 at 20:41 -0800, Justin Chen wrote:
> his patch is to change the bitmap index in the bitops from "int" to
> "unsigned long".
>
> In many bitops implementations, the bitmap index is a signed int. 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.
>
> Following 15 patches will change all the bitmap index "nr" in all
> bitops from "int" to "unsigned long".
>
> The patch is based on 2.6.29-rc6
>
> Please comment -
unsigned int wasn't large enough?
--
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