Re: [LKP] [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller()
9:46 a.m.
On Sat, 30 Jan 2016 02:09:30 -0500
Valdis.Kletnieks(a)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-bootst...
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
6:15 p.m.
New subject: [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller()
Hi Jesper,
On Sat, 30 Jan 2016 18:46:46 +0100 Jesper Dangaard Brouer <brouer(a)redhat.com>
wrote:
Let me know, if the linux-next tree need's an explicit fix?
It would be a good idea if you could send a fix against linux-next to
me as Andrew is currently travelling.
--
Cheers,
Stephen Rothwell
10:40 a.m.
New subject: [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller()
On Sun, 31 Jan 2016 13:15:06 +1100
Stephen Rothwell <sfr(a)canb.auug.org.au> wrote:
Hi Jesper,
On Sat, 30 Jan 2016 18:46:46 +0100 Jesper Dangaard Brouer <brouer(a)redhat.com>
wrote:
>
> Let me know, if the linux-next tree need's an explicit fix?
It would be a good idea if you could send a fix against linux-next to
me as Andrew is currently travelling.
My analysis before was wrong, the fix was much simpler. No need to
revert my FAILSLAB patch. Just forgot to mask flags with gfp_allowed_mask.
I expect AKPM can pickup these two small fixes to my patches.
Below is a patch for linux-next.
- -
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
[PATCH] mm: temporary fix for SLAB in linux-next
From: Jesper Dangaard Brouer <brouer(a)redhat.com>
This is only for linux-next, until AKPM pickup fixes two patches:
base url: http://ozlabs.org/~akpm/mmots/broken-out/
[1] mm-fault-inject-take-over-bootstrap-kmem_cache-check.patch
[2] slab-use-slab_pre_alloc_hook-in-slab-allocator-shared-with-slub.patch
First fix is for compiling with CONFIG_FAILSLAB. The linux-next commit
needing this fix is 074b6f53c320 ("mm: fault-inject take over
bootstrap kmem_cache check").
Second fix is for correct masking of allowed GFP flags (gfp_allowed_mask),
in SLAB allocator. This triggered a WARN, by percpu_init_late ->
pcpu_mem_zalloc invoking kzalloc with GFP_KERNEL flags. The linux-next
commit needing this fix is a1fd55538cae ("slab: use
slab_pre_alloc_hook in SLAB allocator shared with SLUB").
Signed-off-by: Jesper Dangaard Brouer <brouer(a)redhat.com>
---
mm/failslab.c | 1 +
mm/slab.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/mm/failslab.c b/mm/failslab.c
index 0c5b3f31f310..b0fac98cd938 100644
--- a/mm/failslab.c
+++ b/mm/failslab.c
@@ -1,5 +1,6 @@
#include <linux/fault-inject.h>
#include <linux/slab.h>
+#include <linux/mm.h>
#include "slab.h"
static struct {
diff --git a/mm/slab.c b/mm/slab.c
index e90d259b3242..ddd974e6b3bb 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3190,6 +3190,7 @@ slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid,
void *ptr;
int slab_node = numa_mem_id();
+ flags &= gfp_allowed_mask;
cachep = slab_pre_alloc_hook(cachep, flags);
if (unlikely(!cachep))
return NULL;
@@ -3268,6 +3269,7 @@ slab_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long
caller)
unsigned long save_flags;
void *objp;
+ flags &= gfp_allowed_mask;
cachep = slab_pre_alloc_hook(cachep, flags);
if (unlikely(!cachep))
return NULL;
12:34 p.m.
New subject: [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller()
Hi Jesper,
On Sun, 31 Jan 2016 19:40:48 +0100 Jesper Dangaard Brouer <brouer(a)redhat.com>
wrote:
On Sun, 31 Jan 2016 13:15:06 +1100
Stephen Rothwell <sfr(a)canb.auug.org.au> wrote:
> On Sat, 30 Jan 2016 18:46:46 +0100 Jesper Dangaard Brouer <brouer(a)redhat.com>
wrote:
> >
> > Let me know, if the linux-next tree need's an explicit fix?
>
> It would be a good idea if you could send a fix against linux-next to
> me as Andrew is currently travelling.
My analysis before was wrong, the fix was much simpler. No need to
revert my FAILSLAB patch. Just forgot to mask flags with gfp_allowed_mask.
I expect AKPM can pickup these two small fixes to my patches.
Below is a patch for linux-next.
- -
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
[PATCH] mm: temporary fix for SLAB in linux-next
From: Jesper Dangaard Brouer <brouer(a)redhat.com>
This is only for linux-next, until AKPM pickup fixes two patches:
base url: http://ozlabs.org/~akpm/mmots/broken-out/
[1] mm-fault-inject-take-over-bootstrap-kmem_cache-check.patch
[2] slab-use-slab_pre_alloc_hook-in-slab-allocator-shared-with-slub.patch
First fix is for compiling with CONFIG_FAILSLAB. The linux-next commit
needing this fix is 074b6f53c320 ("mm: fault-inject take over
bootstrap kmem_cache check").
Second fix is for correct masking of allowed GFP flags (gfp_allowed_mask),
in SLAB allocator. This triggered a WARN, by percpu_init_late ->
pcpu_mem_zalloc invoking kzalloc with GFP_KERNEL flags. The linux-next
commit needing this fix is a1fd55538cae ("slab: use
slab_pre_alloc_hook in SLAB allocator shared with SLUB").
Signed-off-by: Jesper Dangaard Brouer <brouer(a)redhat.com>
---
mm/failslab.c | 1 +
mm/slab.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/mm/failslab.c b/mm/failslab.c
index 0c5b3f31f310..b0fac98cd938 100644
--- a/mm/failslab.c
+++ b/mm/failslab.c
@@ -1,5 +1,6 @@
#include <linux/fault-inject.h>
#include <linux/slab.h>
+#include <linux/mm.h>
#include "slab.h"
static struct {
diff --git a/mm/slab.c b/mm/slab.c
index e90d259b3242..ddd974e6b3bb 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3190,6 +3190,7 @@ slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int
nodeid,
void *ptr;
int slab_node = numa_mem_id();
+ flags &= gfp_allowed_mask;
cachep = slab_pre_alloc_hook(cachep, flags);
if (unlikely(!cachep))
return NULL;
@@ -3268,6 +3269,7 @@ slab_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long
caller)
unsigned long save_flags;
void *objp;
+ flags &= gfp_allowed_mask;
cachep = slab_pre_alloc_hook(cachep, flags);
if (unlikely(!cachep))
return NULL;
Applied to linux-next today.
--
Cheers,
Stephen Rothwell
1585
days inactive
1586
days old
3 comments
2 participants
participants (2)
-
Jesper Dangaard Brouer -
Stephen Rothwell