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: <20160328141911.3048ab8d406b86a6e5b9f910@linux-foundation.org>
Date:	Mon, 28 Mar 2016 14:19:11 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	js1304@...il.com
Cc:	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Jesper Dangaard Brouer <brouer@...hat.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again

On Mon, 28 Mar 2016 14:26:52 +0900 js1304@...il.com wrote:

> From: Joonsoo Kim <iamjoonsoo.kim@....com>
> 
> Initial attemp to remove BAD_ALIEN_MAGIC is once reverted by
> 'commit edcad2509550 ("Revert "slab: remove BAD_ALIEN_MAGIC"")'
> because it causes a problem on m68k which has many node
> but !CONFIG_NUMA.

Whaaa?  How is that even possible?  I'd have thought that everything
would break at compile time (at least) with such a setup.

> In this case, although alien cache isn't used
> at all but to cope with some initialization path, garbage value
> is used and that is BAD_ALIEN_MAGIC. Now, this patch set
> use_alien_caches to 0 when !CONFIG_NUMA, there is no initialization
> path problem so we don't need BAD_ALIEN_MAGIC at all. So remove it.
> 
> ...
>
> @@ -1205,7 +1203,7 @@ void __init kmem_cache_init(void)
>  					sizeof(struct rcu_head));
>  	kmem_cache = &kmem_cache_boot;
>  
> -	if (num_possible_nodes() == 1)
> +	if (!IS_ENABLED(CONFIG_NUMA) || num_possible_nodes() == 1)
>  		use_alien_caches = 0;
>  
>  	for (i = 0; i < NUM_INIT_LISTS; i++)

This does look screwy.  How can num_possible_nodes() possibly return
anything but "1" if CONFIG_NUMA=n.

Can we please get a code comment in here to explain things to the poor
old reader and to prevent people from trying to "fix" it?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ