Re: [GIT PULL v2] Early SLAB fixes for 2.6.31

[Nick Piggin]

On Mon, Jun 15, 2009 at 01:21:44PM +0300, Pekka Enberg wrote:
> On Mon, 2009-06-15 at 12:20 +0200, Heiko Carstens wrote:
> > > > ---
> > > >  mm/slub.c |   17 ++++++++++++++---
> > > >  1 file changed, 14 insertions(+), 3 deletions(-)
> > > > 
> > > > Index: linux-2.6/mm/slub.c
> > > > ===================================================================
> > > > --- linux-2.6.orig/mm/slub.c
> > > > +++ linux-2.6/mm/slub.c
> > > > @@ -2596,6 +2596,7 @@ static noinline struct kmem_cache *dma_k
> > > >  	struct kmem_cache *s;
> > > >  	char *text;
> > > >  	size_t realsize;
> > > > +	unsigned long slabflags;
> > > >  
> > > >  	s = kmalloc_caches_dma[index];
> > > >  	if (s)
> > > > @@ -2617,9 +2618,18 @@ static noinline struct kmem_cache *dma_k
> > > >  			 (unsigned int)realsize);
> > > >  	s = kmalloc(kmem_size, flags & ~SLUB_DMA);
> > > >  
> > > > +	/*
> > > > +	 * Must defer sysfs creation to a workqueue because we don't know
> > > > +	 * what context we are called from. Before sysfs comes up, we don't
> > > > +	 * need to do anything because slab_sysfs_init will start by
> > > > +	 * adding all existing slabs to sysfs.
> > > > +	 */
> > > > +	slabflags = SLAB_CACHE_DMA;
> > > > +	if (slab_state >= SYSFS)
> > > > +		slabflags |= __SYSFS_ADD_DEFERRED;
> > > > +
> > > >  	if (!s || !text || !kmem_cache_open(s, flags, text,
> > > > -			realsize, ARCH_KMALLOC_MINALIGN,
> > > > -			SLAB_CACHE_DMA|__SYSFS_ADD_DEFERRED, NULL)) {
> > > > +			realsize, ARCH_KMALLOC_MINALIGN, slabflags, NULL)) {
> > > >  		kfree(s);
> > > >  		kfree(text);
> > > >  		goto unlock_out;
> > > > @@ -2628,7 +2638,8 @@ static noinline struct kmem_cache *dma_k
> > > >  	list_add(&s->list, &slab_caches);
> > > >  	kmalloc_caches_dma[index] = s;
> > > >  
> > > > -	schedule_work(&sysfs_add_work);
> > > > +	if (slab_state >= SYSFS)
> > > > +		schedule_work(&sysfs_add_work);
> > > >  
> > > >  unlock_out:
> > > >  	up_write(&slub_lock);
> > > 
> > > Looks good to me. Heiko, does it fix your case?
> > 
> > Yes, works fine. Thanks!
> > 
> > Tested-by: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
> 
> Thanks! Nick, care to send a patch with your sign-off? Does SLQB need
> something like this too (I didn't check)?

No, it does not defer DMA slab creation.
--

Recent change to use slab allocations earlier exposed a bug where
SLUB can call schedule_work and try to call sysfs before it is
safe to do so.

Reported-by: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
Tested-by: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
Signed-off-by: Nick Piggin <npiggin@xxxxxxx>
---
 mm/slub.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c
+++ linux-2.6/mm/slub.c
@@ -2596,6 +2596,7 @@ static noinline struct kmem_cache *dma_k
 	struct kmem_cache *s;
 	char *text;
 	size_t realsize;
+	unsigned long slabflags;
 
 	s = kmalloc_caches_dma[index];
 	if (s)
@@ -2617,9 +2618,18 @@ static noinline struct kmem_cache *dma_k
 			 (unsigned int)realsize);
 	s = kmalloc(kmem_size, flags & ~SLUB_DMA);
 
+	/*
+	 * Must defer sysfs creation to a workqueue because we don't know
+	 * what context we are called from. Before sysfs comes up, we don't
+	 * need to do anything because our sysfs initcall will start by
+	 * adding all existing slabs to sysfs.
+	 */
+	slabflags = SLAB_CACHE_DMA;
+	if (slab_state >= SYSFS)
+		slabflags |= __SYSFS_ADD_DEFERRED;
+
 	if (!s || !text || !kmem_cache_open(s, flags, text,
-			realsize, ARCH_KMALLOC_MINALIGN,
-			SLAB_CACHE_DMA|__SYSFS_ADD_DEFERRED, NULL)) {
+			realsize, ARCH_KMALLOC_MINALIGN, slabflags, NULL)) {
 		kfree(s);
 		kfree(text);
 		goto unlock_out;
@@ -2628,7 +2638,8 @@ static noinline struct kmem_cache *dma_k
 	list_add(&s->list, &slab_caches);
 	kmalloc_caches_dma[index] = s;
 
-	schedule_work(&sysfs_add_work);
+	if (slab_state >= SYSFS)
+		schedule_work(&sysfs_add_work);
 
 unlock_out:
 	up_write(&slub_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/