public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ravikiran G Thirumalai <kiran@scalex86.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>,
	linux-kernel@vger.kernel.org, Andi Kleen <ak@muc.de>,
	Jan Beulich <jbeulich@novell.com>,
	Alok Kataria <alok.kataria@calsoftinc.com>
Subject: Re: mm snapshot broken-out-2006-08-08-00-59.tar.gz uploaded
Date: Tue, 8 Aug 2006 23:21:59 -0700	[thread overview]
Message-ID: <20060809062159.GA3829@localhost.localdomain> (raw)
In-Reply-To: <20060808164210.edb10cdc.akpm@osdl.org>

On Tue, Aug 08, 2006 at 04:42:10PM -0700, Andrew Morton wrote:
> On Wed, 9 Aug 2006 00:11:38 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> 
> ah-hah, thanks.  The oopsing statement was added by
> slab-fix-lockdep-warnings.patch.
> 
> I guess we can fix this by whacking another #ifdef CONFIG_NUMA in there but
> I don't think that's how we want to address this.
> 
> We've been moving towards making the NUMA slab code work OK in a non-NUMA
> build by setting the NUMA-specific fields to NULL and simply blowing a few
> cycles at runtime to avoid many tens of ifdefs (it's that bad).
> 
> Here, we should have had either l3==NULL or l3->alien==NULL, but that has
> been violated, hence the crash.
> Kiran, could you take a look please?  The 0x01020304 is interesting...

Eeesh, because on SMP,  alloc_alien_cache returns 0x01020304 instead of
NULL, And it returns 0x01020304 because CPU_UP_PREPARE fails if
alloc_alien_cache returns NULL.  NUMA and non NUMA slab should be able to
work even without alien caches, currently that doesn't seem to be the case.
We are working on that.  In the meanwhile, the following patch should
fix the oops due to locdep annotation.

Thanks,
Kiran

Fix oops due to alien cache locdep annotation on non NUMA configurations.
A plain alien != NULL won't work as l3->alien is initialized with
0x01020304ul

Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>

Index: linux-2.6.18-rc3mm3/mm/slab.c
===================================================================
--- linux-2.6.18-rc3mm3.orig/mm/slab.c	2006-08-08 19:19:51.000000000 -0700
+++ linux-2.6.18-rc3mm3/mm/slab.c	2006-08-08 21:53:53.000000000 -0700
@@ -674,6 +674,8 @@ static struct kmem_cache cache_cache = {
 #endif
 };
 
+#define BAD_ALIEN_MAGIC 0x01020304ul
+
 #ifdef CONFIG_LOCKDEP
 
 /*
@@ -705,7 +707,14 @@ static inline void init_lock_keys(void)
 				continue;
 			lockdep_set_class(&l3->list_lock, &on_slab_l3_key);
 			alc = l3->alien;
-			if (!alc)
+			/*
+			 * FIXME: This check for BAD_ALIEN_MAGIC
+			 * should go away when common slab code is taught to 
+			 * work even without alien caches.  
+			 * Currently, non NUMA code returns BAD_ALIEN_MAGIC
+			 * for alloc_alien_cache,
+			 */
+			if (!alc || (unsigned long) alc == BAD_ALIEN_MAGIC)
 				continue;
 			for_each_node(r) {
 				if (alc[r])
@@ -1112,7 +1121,7 @@ static inline int cache_free_alien(struc
 
 static inline struct array_cache **alloc_alien_cache(int node, int limit)
 {
-	return (struct array_cache **) 0x01020304ul;
+	return (struct array_cache **) BAD_ALIEN_MAGIC;
 }
 
 static inline void free_alien_cache(struct array_cache **ac_ptr)

  parent reply	other threads:[~2006-08-09  6:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200608080800.k7880noU028915@shell0.pdx.osdl.net>
2006-08-08 20:29 ` mm snapshot broken-out-2006-08-08-00-59.tar.gz uploaded Michal Piotrowski
2006-08-08 21:05   ` Andrew Morton
2006-08-08 21:19     ` Michal Piotrowski
2006-08-08 21:37       ` Andrew Morton
2006-08-08 22:11         ` Michal Piotrowski
2006-08-08 23:24           ` Michal Piotrowski
2006-08-08 23:42           ` Andrew Morton
2006-08-09  0:01             ` Michal Piotrowski
2006-08-09  6:21             ` Ravikiran G Thirumalai [this message]
2006-08-09 13:21               ` Michal Piotrowski
2006-08-09  1:43           ` Andi Kleen
2006-08-09 12:49             ` Michal Piotrowski
2006-08-09  1:42     ` Andi Kleen
2006-08-09 14:20 ` Michal Piotrowski
2006-08-09 22:44   ` Michal Piotrowski
2006-08-10  6:35     ` Jens Axboe
2006-08-10 13:06       ` Michal Piotrowski
2006-08-10 13:09         ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060809062159.GA3829@localhost.localdomain \
    --to=kiran@scalex86.org \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=alok.kataria@calsoftinc.com \
    --cc=jbeulich@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.k.k.piotrowski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox