linux-kernel - Re: 2.6.22-rc2-mm1: SLUB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <465C6D4B.90403@oracle.com>
Date:	Tue, 29 May 2007 11:13:31 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Christoph Lameter <clameter@....com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.22-rc2-mm1: SLUB

Christoph Lameter wrote:
> On Mon, 28 May 2007, Randy Dunlap wrote:
> 
>> Has then already been posted and I missed it.. and it's fixed?  :)
>> /me hopes
> 
> Maybe this patch wil help?

Nope, still no booty.

> SLUB: Fix NUMA / SYSFS bootstrap issue
> 
> The kmem_cache_node cache is very special because it is needed for
> NUMA bootstrap. Under certain conditions (like for example if lockdep is
> enabled and significantly increases the size of spinlock_t) the structure
> may become exactly the size as one of the larger caches in the kmalloc array.
> 
> That early during bootstrap we cannot perform merging properly. The unique
> id for the kmem_cache_node cache will match one of the kmalloc array. Sysfs
> will complain about a duplicate directory entry. All of this occurs while
> the console is not yet fully operational. Thus boot may appear to be
> silently failing.
> 
> The kmem_cache_node cache is very special. During early boostrap the main
> allocation function is not operational yet and so we have to run our
> own small special alloc function during early boot. It is also special in
> that it is never freed.
> 
> We really do not want any merging on that cache. Set the refcount -1 and
> forbid merging of slabs that have a negative refcount.
> 
> Signed-off-by: Christoph Lameter <clameter@....com>
> 
> ---
>  mm/slub.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> Index: slub/mm/slub.c
> ===================================================================
> --- slub.orig/mm/slub.c	2007-05-25 18:28:42.000000000 -0700
> +++ slub/mm/slub.c	2007-05-25 18:29:46.000000000 -0700
> @@ -2473,6 +2473,7 @@ void __init kmem_cache_init(void)
>  	 */
>  	create_kmalloc_cache(&kmalloc_caches[0], "kmem_cache_node",
>  		sizeof(struct kmem_cache_node), GFP_KERNEL);
> +	kmalloc_caches[0].refcount = -1;
>  #endif
>  
>  	/* Able to allocate the per node structures */
> @@ -2520,6 +2521,12 @@ static int slab_unmergeable(struct kmem_
>  	if (s->ctor)
>  		return 1;
>  
> +	/*
> +	 * We may have set a slab to be unmergeable during bootstrap.
> +	 */
> +	if (s->refcount < 0)
> +		return 1;
> +
>  	return 0;
>  }
>  


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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/