A gen_pool_chunk uses a bitmap to find what addresses ranges it has
allocated and bugs when we destroy the pool and a chunk has some bits
set.
There is a problem when it allocates the bitmap. It allocates only the
number of bytes needed for the bits that represent the size it's
allocating. That is, if it needs 16 bits, it will allocate only 2 bytes,
if it needs 31 bits, it will allocate 4 bytes.
However, the bitops functions uses long types. And when the gen_pool_add
allocates a bitmap, it only clears the bytes it has allocated. So, it's
possible that we have a long word with the contents 0xffffffffffffffff,
and only the first (most significant) bytes are cleared by memset.
However, the destroy function is going to test for the least significant
bits, which will not be clear as expected.
Signed-off-by: Thadeu Lima de Souza Cascardo <casca...@linux.vnet.ibm.com>
---
lib/genalloc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/genalloc.c b/lib/genalloc.c
index ca208a9..5492043 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -178,7 +178,7 @@ int gen_pool_add_virt(struct gen_pool *pool, unsigned long
virt, phys_addr_t phy
struct gen_pool_chunk *chunk;
int nbits = size >> pool->min_alloc_order;
int nbytes = sizeof(struct gen_pool_chunk) +
- (nbits + BITS_PER_BYTE - 1) / BITS_PER_BYTE;
+ BITS_TO_LONGS(nbits) * sizeof(long);
chunk = kmalloc_node(nbytes, GFP_KERNEL | __GFP_ZERO, nid);
if (unlikely(chunk == NULL))
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
