Prev: wireless/ath: remove trailing space in messages
Next: [PATCH -mmotm] leds-input: depends on INPUT
From: Christoph Lameter on 24 Mar 2010 15:20
On Wed, 24 Mar 2010, Eric Dumazet wrote:

> I discovered that we can overflow stack if CONFIG_SLUB_DEBUG=y and use
> slabs with many objects, since list_slab_objects() and process_slab()
> use DECLARE_BITMAP(map, page->objects);

Maybe we better allocate the bitmap via kmalloc then.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Eric Dumazet on 24 Mar 2010 15:30
Le mercredi 24 mars 2010 à 14:16 -0500, Christoph Lameter a écrit :
> On Wed, 24 Mar 2010, Eric Dumazet wrote:
>
> > I discovered that we can overflow stack if CONFIG_SLUB_DEBUG=y and use
> > slabs with many objects, since list_slab_objects() and process_slab()
> > use DECLARE_BITMAP(map, page->objects);
>
> Maybe we better allocate the bitmap via kmalloc then.
>

Hmm...

Are we allowed to nest in these two functions ?

GFP_KERNEL, GFP_ATOMIC ?

These are debugging functions, what happens if kmalloc() returns NULL ?



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Lameter on 24 Mar 2010 16:00
On Wed, 24 Mar 2010, Eric Dumazet wrote:

> Are we allowed to nest in these two functions ?

This is kmem_cache_close() no danger of nesting.

> These are debugging functions, what happens if kmalloc() returns NULL ?

Then you return ENOMEM and the user gets an error. We already do that in
validate_slab_cache().

Hmmm... In this case we called from list_slab_objects() which gets called
from free_partial() (which took a spinlock!) which gets called from
kmem_cache_close().

Its just a debugging aid so no problem if it fails. GFP_ATOMIC?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Eric Dumazet on 24 Mar 2010 17:10
Le mercredi 24 mars 2010 à 14:49 -0500, Christoph Lameter a écrit :
> On Wed, 24 Mar 2010, Eric Dumazet wrote:
>
> > Are we allowed to nest in these two functions ?
>
> This is kmem_cache_close() no danger of nesting.
>
> > These are debugging functions, what happens if kmalloc() returns NULL ?
>
> Then you return ENOMEM and the user gets an error. We already do that in
> validate_slab_cache().
>
> Hmmm... In this case we called from list_slab_objects() which gets called
> from free_partial() (which took a spinlock!) which gets called from
> kmem_cache_close().
>
> Its just a debugging aid so no problem if it fails. GFP_ATOMIC?

OK, here is second version of the patch, thanks !


[PATCH] slub: Potential stack overflow

I discovered that we can overflow stack if CONFIG_SLUB_DEBUG=y and use
slabs with many objects, since list_slab_objects() and process_slab()
use DECLARE_BITMAP(map, page->objects);

With 65535 bits, we use 8192 bytes of stack ...

A possible solution is to allocate memory, using GFP_ATOMIC, and do
nothing if allocation fails.

Signed-off-by: Eric Dumazet <eric.dumazet(a)gmail.com>
---
diff --git a/mm/slub.c b/mm/slub.c
index b364844..5ee857a 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2426,9 +2426,11 @@ static void list_slab_objects(struct kmem_cache *s, struct page *page,
#ifdef CONFIG_SLUB_DEBUG
void *addr = page_address(page);
void *p;
- DECLARE_BITMAP(map, page->objects);
+ long *map = kzalloc(BITS_TO_LONGS(page->objects) * sizeof(long),
+ GFP_ATOMIC);

- bitmap_zero(map, page->objects);
+ if (!map)
+ return;
slab_err(s, page, "%s", text);
slab_lock(page);
for_each_free_object(p, s, page->freelist)
@@ -2443,6 +2445,7 @@ static void list_slab_objects(struct kmem_cache *s, struct page *page,
}
}
slab_unlock(page);
+ kfree(map);
#endif
}

@@ -3651,16 +3654,19 @@ static void process_slab(struct loc_track *t, struct kmem_cache *s,
struct page *page, enum track_item alloc)
{
void *addr = page_address(page);
- DECLARE_BITMAP(map, page->objects);
+ long *map = kzalloc(BITS_TO_LONGS(page->objects) * sizeof(long),
+ GFP_ATOMIC);
void *p;

- bitmap_zero(map, page->objects);
+ if (!map)
+ return;
for_each_free_object(p, s, page->freelist)
set_bit(slab_index(p, s, addr), map);

for_each_object(p, s, addr, page->objects)
if (!test_bit(slab_index(p, s, addr), map))
add_location(t, s, get_track(s, p, alloc));
+ kfree(map);
}

static int list_locations(struct kmem_cache *s, char *buf,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Lameter on 24 Mar 2010 17:20
Here is a patch for the second case. I think its better since it results
in an error display and it avoids the alloc for each slab. Add this piece
to your patch?

Signed-off-by: Christoph Lameter <cl(a)linux-foundation.org>

---
mm/slub.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)

Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2010-03-24 16:10:32.000000000 -0500
+++ linux-2.6/mm/slub.c 2010-03-24 16:13:06.000000000 -0500
@@ -3648,10 +3648,10 @@ static int add_location(struct loc_track
}

static void process_slab(struct loc_track *t, struct kmem_cache *s,
- struct page *page, enum track_item alloc)
+ struct page *page, enum track_item alloc,
+ unsigned long *map)
{
void *addr = page_address(page);
- DECLARE_BITMAP(map, page->objects);
void *p;

bitmap_zero(map, page->objects);
@@ -3670,8 +3670,10 @@ static int list_locations(struct kmem_ca
unsigned long i;
struct loc_track t = { 0, 0, NULL };
int node;
+ unsigned long *map = kmalloc(BITS_TO_LONGS(oo_objects(s->max)) *
+ sizeof(unsigned long), GFP_KERNEL);

- if (!alloc_loc_track(&t, PAGE_SIZE / sizeof(struct location),
+ if (!map || !alloc_loc_track(&t, PAGE_SIZE / sizeof(struct location),
GFP_TEMPORARY))
return sprintf(buf, "Out of memory\n");

@@ -3688,9 +3690,9 @@ static int list_locations(struct kmem_ca

spin_lock_irqsave(&n->list_lock, flags);
list_for_each_entry(page, &n->partial, lru)
- process_slab(&t, s, page, alloc);
+ process_slab(&t, s, page, alloc, map);
list_for_each_entry(page, &n->full, lru)
- process_slab(&t, s, page, alloc);
+ process_slab(&t, s, page, alloc, map);
spin_unlock_irqrestore(&n->list_lock, flags);
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3
Prev: wireless/ath: remove trailing space in messages
Next: [PATCH -mmotm] leds-input: depends on INPUT