From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Valdis.Kletnieks@vt.edu
Cc: kernel test robot <fengguang.wu@intel.com>, LKP <lkp@01.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
wfg@linux.intel.com, brouer@redhat.com,
Christoph Lameter <cl@linux.com>, Tejun Heo <tj@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller()
Date: Sat, 30 Jan 2016 18:46:46 +0100 [thread overview]
Message-ID: <20160130184646.6ea9c5f8@redhat.com> (raw)
In-Reply-To: <21684.1454137770@turing-police.cc.vt.edu>
On Sat, 30 Jan 2016 02:09:30 -0500
Valdis.Kletnieks@vt.edu wrote:
> On Thu, 28 Jan 2016 18:47:49 +0100, Jesper Dangaard Brouer said:
> > I cannot reproduce below problem... have enabled all kind of debugging
> > and also lockdep.
> >
> > Can I get a version of the .config file used?
>
> I'm not the 0day bot, but my laptop hits the same issue at boot.
Thank you! I'm now able to reproduce, and I've found the issue. It only
happens for SLAB, and with FAILSLAB disabled.
The problem were introduced in the patch before:
http://ozlabs.org/~akpm/mmots/broken-out/mm-fault-inject-take-over-bootstrap-kmem_cache-check.patch
which moved the check function:
static bool slab_should_failslab(struct kmem_cache *cachep, gfp_t flags)
{
if (unlikely(cachep == kmem_cache))
return false;
return should_failslab(cachep->object_size, flags, cachep->flags);
}
into the fault injection framework, call of should_failslab().
That change was wrong, as some very early boot code depend on SLAB
failing, when still allocating from the bootstrap kmem_cache. SLUB seem
to handle this better.
In this case the percpu system, have a workqueue function, calling
pcpu_extend_area_map() which sort-of probe the slab-allocator, and
depending on it fails, until it is fully ready.
I will fix up my patches, reverting this change... and let them go
through Andrews quilt process.
Let me know, if the linux-next tree need's an explicit fix?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
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>
next prev parent reply other threads:[~2016-01-30 17:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 14:52 [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller() kernel test robot
2016-01-28 17:47 ` Jesper Dangaard Brouer
2016-01-30 7:09 ` Valdis.Kletnieks
2016-01-30 17:46 ` Jesper Dangaard Brouer [this message]
2016-01-31 2:15 ` Stephen Rothwell
2016-01-31 18:40 ` Jesper Dangaard Brouer
2016-01-31 20:34 ` Stephen Rothwell
2016-02-02 19:12 ` Valdis.Kletnieks
2016-03-01 18:33 ` Andrew Morton
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=20160130184646.6ea9c5f8@redhat.com \
--to=brouer@redhat.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=fengguang.wu@intel.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@01.org \
--cc=sfr@canb.auug.org.au \
--cc=tj@kernel.org \
--cc=wfg@linux.intel.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;
as well as URLs for NNTP newsgroup(s).