Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755410AbcC1VTO (ORCPT ); Mon, 28 Mar 2016 17:19:14 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:57263 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754065AbcC1VTM (ORCPT ); Mon, 28 Mar 2016 17:19:12 -0400 Date: Mon, 28 Mar 2016 14:19:11 -0700 From: Andrew Morton To: js1304@gmail.com Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Jesper Dangaard Brouer , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joonsoo Kim Subject: Re: [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again Message-Id: <20160328141911.3048ab8d406b86a6e5b9f910@linux-foundation.org> In-Reply-To: <1459142821-20303-3-git-send-email-iamjoonsoo.kim@lge.com> References: <1459142821-20303-1-git-send-email-iamjoonsoo.kim@lge.com> <1459142821-20303-3-git-send-email-iamjoonsoo.kim@lge.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1304 Lines: 35 On Mon, 28 Mar 2016 14:26:52 +0900 js1304@gmail.com wrote: > From: Joonsoo Kim > > 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?