All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Herrmann <andreas.herrmann@calxeda.com>
To: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/slub: Switch slub_debug kernel option to early_param to avoid boot panic
Date: Wed, 6 Nov 2013 22:16:04 +0100	[thread overview]
Message-ID: <20131106211604.GM5661@alberich> (raw)
In-Reply-To: <20131106203429.GL5661@alberich>

On Wed, Nov 06, 2013 at 09:34:29PM +0100, Andreas Herrmann wrote:
> On Wed, Nov 06, 2013 at 08:54:17PM +0100, Andreas Herrmann wrote:
> > On Wed, Nov 06, 2013 at 02:16:33PM -0500, Christoph Lameter wrote:
> > > On Wed, 6 Nov 2013, Andreas Herrmann wrote:
> > > 
> > > > When I've used slub_debug kernel option (e.g.
> > > > "slub_debug=,skbuff_fclone_cache" or similar) on a debug session I've
> > > > seen a panic like:
> > > 
> > > Hmmm.. That looks like its due to some slabs not having names
> > > during early boot. kmem_cache_flags is called with NULL as a parameter.
> > 
> > That's because the slub_debug parameter is not evaluated before
> > kmem_cache_flags is called.
> > 
> > Older kernels didn't show this problem. I think the sequence of those
> > calls has changed. Not sure what patch set has made that change.
> 
> Please ignore this comment.
> I revisisted the code and of course you are right.
> Hmm, now wondering why my patch covered the panic.

Arrgh, my patch changed slub_debug_slabs to be NULL.
That is why the panic didn't happen.

Would be nice, if your patch is pushed upstream asap.


Thanks,

Andreas

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andreas Herrmann <andreas.herrmann@calxeda.com>
To: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/slub: Switch slub_debug kernel option to early_param to avoid boot panic
Date: Wed, 6 Nov 2013 22:16:04 +0100	[thread overview]
Message-ID: <20131106211604.GM5661@alberich> (raw)
In-Reply-To: <20131106203429.GL5661@alberich>

On Wed, Nov 06, 2013 at 09:34:29PM +0100, Andreas Herrmann wrote:
> On Wed, Nov 06, 2013 at 08:54:17PM +0100, Andreas Herrmann wrote:
> > On Wed, Nov 06, 2013 at 02:16:33PM -0500, Christoph Lameter wrote:
> > > On Wed, 6 Nov 2013, Andreas Herrmann wrote:
> > > 
> > > > When I've used slub_debug kernel option (e.g.
> > > > "slub_debug=,skbuff_fclone_cache" or similar) on a debug session I've
> > > > seen a panic like:
> > > 
> > > Hmmm.. That looks like its due to some slabs not having names
> > > during early boot. kmem_cache_flags is called with NULL as a parameter.
> > 
> > That's because the slub_debug parameter is not evaluated before
> > kmem_cache_flags is called.
> > 
> > Older kernels didn't show this problem. I think the sequence of those
> > calls has changed. Not sure what patch set has made that change.
> 
> Please ignore this comment.
> I revisisted the code and of course you are right.
> Hmm, now wondering why my patch covered the panic.

Arrgh, my patch changed slub_debug_slabs to be NULL.
That is why the panic didn't happen.

Would be nice, if your patch is pushed upstream asap.


Thanks,

Andreas

  reply	other threads:[~2013-11-06 21:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06 18:45 [PATCH] mm/slub: Switch slub_debug kernel option to early_param to avoid boot panic Andreas Herrmann
2013-11-06 18:45 ` Andreas Herrmann
2013-11-06 19:16 ` Christoph Lameter
2013-11-06 19:16   ` Christoph Lameter
2013-11-06 19:21   ` Andreas Herrmann
2013-11-06 19:21     ` Andreas Herrmann
2013-11-06 19:54   ` Andreas Herrmann
2013-11-06 19:54     ` Andreas Herrmann
2013-11-06 20:34     ` Andreas Herrmann
2013-11-06 20:34       ` Andreas Herrmann
2013-11-06 21:16       ` Andreas Herrmann [this message]
2013-11-06 21:16         ` Andreas Herrmann
2013-11-06 21:38         ` Christoph Lameter
2013-11-06 21:38           ` Christoph Lameter
2013-11-07  8:27           ` Andreas Herrmann
2013-11-07  8:27             ` Andreas Herrmann
2013-11-07  8:41             ` Andreas Herrmann
2013-11-07  8:41               ` Andreas Herrmann
2013-11-07 16:09               ` Christoph Lameter
2013-11-07 16:09                 ` Christoph Lameter
     [not found]               ` <alpine.DEB.2.02.1311071008010.22533@gentwo.org>
2013-11-07 16:29                 ` Christoph Lameter
2013-11-07 16:29                   ` Christoph Lameter

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=20131106211604.GM5661@alberich \
    --to=andreas.herrmann@calxeda.com \
    --cc=cl@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpm@selenic.com \
    --cc=penberg@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.