Re: [PATCH] slab: cache_grow cleanup

Previous thread: Re: [BUG 2.6.20-rc3-mm1] raid1 mount blocks for ever by Jens Axboe on Tuesday, January 9, 2007 - 8:15 am. (1 message)

Next thread: [RFC] Stable kvm userspace interface by Avi Kivity on Tuesday, January 9, 2007 - 9:37 am. (12 messages)
To: <akpm@...>
Cc: <linux-kernel@...>, <hugh@...>, <clameter@...>
Date: Tuesday, January 9, 2007 - 9:40 am

From: Pekka Enberg <penberg@cs.helsinki.fi>

The current implementation of cache_grow() has to either (1) use pre-allocated
memory for the slab or (2) allocate the memory itself which makes the error
paths messy. Move __GFP_NO_GROW and __GFP_WAIT processing to kmem_getpages()
and introduce a new __cache_grow() variant that expects the memory for a new
slab to always be handed over in the 'objp' parameter.

Cc: Hugh Dickins <hugh@veritas.com>
Cc: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---

diff --git a/mm/slab.c b/mm/slab.c
index c610062..856856c 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1597,6 +1597,14 @@ static int __init cpucache_init(void)
}
__initcall(cpucache_init);

+static void kmem_flagcheck(struct kmem_cache *cachep, gfp_t flags)
+{
+ if (flags & GFP_DMA)
+ BUG_ON(!(cachep->gfpflags & GFP_DMA));
+ else
+ BUG_ON(cachep->gfpflags & GFP_DMA);
+}
+
/*
* Interface to system's page allocator. No need to hold the cache-lock.
*
@@ -1608,8 +1616,22 @@ static void *kmem_getpages(struct kmem_c
{
struct page *page;
int nr_pages;
+ void *ret;
int i;

+ if (flags & __GFP_NO_GROW)
+ return NULL;
+
+ /*
+ * The test for missing atomic flag is performed here, rather than
+ * the more obvious place, simply to reduce the critical path length
+ * in kmem_cache_alloc(). If a caller is seriously mis-behaving they
+ * will eventually be caught here (where it matters).
+ */
+ kmem_flagcheck(cachep, flags);
+ if (flags & __GFP_WAIT)
+ local_irq_enable();
+
#ifndef CONFIG_MMU
/*
* Nommu uses slab's for process anonymous memory allocations, and thus
@@ -1621,8 +1643,10 @@ #endif
flags |= cachep->gfpflags;

page = alloc_pages_node(nodeid, flags, cachep->gfporder);
- if (!page)
- return NULL;
+ if (!page) {
+ ret = NULL;
+ goto out;
+ }

nr_pages = (1 << cachep->gfporder);
if (cachep->flags & SLAB_RECL...

To: Pekka J Enberg <penberg@...>
Cc: <linux-kernel@...>, <hugh@...>, <clameter@...>
Date: Saturday, January 27, 2007 - 8:12 pm

On Tue, 9 Jan 2007 15:40:03 +0200 (EET)

This gets its local interrupt state mucked up.

BUG: sleeping function called from invalid context at mm/slab.c:3038
in_atomic():0, irqs_disabled():1
no locks held by init/1.
irq event stamp: 656902
hardirqs last enabled at (656901): [<c015f48b>] mod_zone_page_state+0x4b/0x50
hardirqs last disabled at (656902): [<c0171f54>] cache_alloc_refill+0x384/0x6a0
softirqs last enabled at (650628): [<c03a6317>] unix_release_sock+0x67/0x220
softirqs last disabled at (650626): [<c03cfe8e>] _write_lock_bh+0xe/0x40
[<c0103f7a>] show_trace_log_lvl+0x1a/0x30
[<c0104682>] show_trace+0x12/0x20
[<c0104736>] dump_stack+0x16/0x20
[<c01175ea>] __might_sleep+0xba/0xd0
[<c017262f>] kmem_cache_alloc+0xaf/0xd0
[<c0172131>] cache_alloc_refill+0x561/0x6a0
[<c0172574>] kmem_cache_zalloc+0xe4/0xf0
[<c011cb49>] copy_process+0x89/0x1280
[<c011dfcb>] do_fork+0x6b/0x1c0
[<c0100e13>] sys_clone+0x33/0x40
[<c0102edc>] sysenter_past_esp+0x5d/0x99
=======================
-

To: Andrew Morton <akpm@...>
Cc: <linux-kernel@...>, <hugh@...>, <clameter@...>
Date: Sunday, January 28, 2007 - 7:14 am

Hi Andrew,

Hmm, alloc_slabmgmt calls kmem_cache_alloc with interrupts disabled
which triggers the warning. We won't deadlock though as we enable
interrupts in kmem_getpages in case we need to refill
cachep->slabp_cache. So the debug check is bogus when calling
kmem_cache_alloc within the slab allocator, I think.

I'll whack it some more and resend. Thanks Andrew!

Pekka
-

To: <akpm@...>
Cc: <linux-kernel@...>, <hugh@...>, <clameter@...>
Date: Friday, January 12, 2007 - 5:22 am

Hi Andrew,

Can we get this into -mm, please?
-

To: Pekka J Enberg <penberg@...>
Cc: <akpm@...>, <linux-kernel@...>, <hugh@...>
Date: Tuesday, January 9, 2007 - 2:18 pm

I am loosing track of these. What is the difference to earlier versions?
-

To: Christoph Lameter <clameter@...>
Cc: <akpm@...>, <linux-kernel@...>, <hugh@...>
Date: Wednesday, January 10, 2007 - 10:44 am

It is just a rediff on top of Linus' tree as Hugh's fix already went in.

Pekka
-

To: Christoph Lameter <clameter@...>
Cc: <akpm@...>, <linux-kernel@...>, <hugh@...>
Date: Wednesday, January 10, 2007 - 3:12 am

[Empty message]
Previous thread: Re: [BUG 2.6.20-rc3-mm1] raid1 mount blocks for ever by Jens Axboe on Tuesday, January 9, 2007 - 8:15 am. (1 message)

Next thread: [RFC] Stable kvm userspace interface by Avi Kivity on Tuesday, January 9, 2007 - 9:37 am. (12 messages)