Messages in this thread | | | Date | Mon, 28 Mar 2016 14:19:11 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again |
| |
On Mon, 28 Mar 2016 14:26:52 +0900 js1304@gmail.com wrote:
> From: Joonsoo Kim <iamjoonsoo.kim@lge.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?
| |