Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1365320 > unrolled thread

[PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again

Started byjs1304@gmail.com
First post2016-03-28 07:30 +0200
Last post2016-03-29 03:00 +0200
Articles 5 — 5 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again js1304@gmail.com - 2016-03-28 07:30 +0200
    Re: [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again Geert Uytterhoeven <geert@linux-m68k.org> - 2016-03-28 11:00 +0200
      Re: [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-03-30 10:10 +0200
    Re: [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again Andrew Morton <akpm@linux-foundation.org> - 2016-03-28 23:20 +0200
      Re: [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again Christoph Lameter <cl@linux.com> - 2016-03-29 03:00 +0200

#1365320 — [PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again

Fromjs1304@gmail.com
Date2016-03-28 07:30 +0200
Subject[PATCH 02/11] mm/slab: remove BAD_ALIEN_MAGIC again
Message-ID<rhxUv-2rs-23@gated-at.bofh.it>
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. 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.

Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
---
 mm/slab.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 043606a..a5a205b 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -421,8 +421,6 @@ static struct kmem_cache kmem_cache_boot = {
 	.name = "kmem_cache",
 };
 
-#define BAD_ALIEN_MAGIC 0x01020304ul
-
 static DEFINE_PER_CPU(struct delayed_work, slab_reap_work);
 
 static inline struct array_cache *cpu_cache_get(struct kmem_cache *cachep)
@@ -637,7 +635,7 @@ static int transfer_objects(struct array_cache *to,
 static inline struct alien_cache **alloc_alien_cache(int node,
 						int limit, gfp_t gfp)
 {
-	return (struct alien_cache **)BAD_ALIEN_MAGIC;
+	return NULL;
 }
 
 static inline void free_alien_cache(struct alien_cache **ac_ptr)
@@ -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++)
-- 
1.9.1

[toc] | [next] | [standalone]


#1365393

FromGeert Uytterhoeven <geert@linux-m68k.org>
Date2016-03-28 11:00 +0200
Message-ID<rhBbH-4sP-9@gated-at.bofh.it>
In reply to#1365320
Hi Jonsoo,

On Mon, Mar 28, 2016 at 7:26 AM,  <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. 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.
>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

I gave this a try on m68k/ARAnyM, and it didn't crash, unlike the previous
version that was reverted, so
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]


#1366972

FromJoonsoo Kim <iamjoonsoo.kim@lge.com>
Date2016-03-30 10:10 +0200
Message-ID<rijmp-2uB-3@gated-at.bofh.it>
In reply to#1365393
On Mon, Mar 28, 2016 at 10:58:38AM +0200, Geert Uytterhoeven wrote:
> Hi Jonsoo,
> 
> On Mon, Mar 28, 2016 at 7:26 AM,  <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. 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.
> >
> > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> 
> I gave this a try on m68k/ARAnyM, and it didn't crash, unlike the previous
> version that was reverted, so
> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>

Thanks for testing!!!

Thanks.

[toc] | [prev] | [next] | [standalone]


#1365680

FromAndrew Morton <akpm@linux-foundation.org>
Date2016-03-28 23:20 +0200
Message-ID<rhMJQ-4ie-21@gated-at.bofh.it>
In reply to#1365320
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?

[toc] | [prev] | [next] | [standalone]


#1365746

FromChristoph Lameter <cl@linux.com>
Date2016-03-29 03:00 +0200
Message-ID<rhQaK-6GM-5@gated-at.bofh.it>
In reply to#1365680
On Mon, 28 Mar 2016, Andrew Morton wrote:

> 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.

Yes we have that and the support for this caused numerous issues. Can we
stop supporting such a configuration?

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web