All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: lkp@lists.01.org
Subject: Re: [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller()
Date: Sun, 31 Jan 2016 19:40:48 +0100	[thread overview]
Message-ID: <20160131194048.6f7add16@redhat.com> (raw)
In-Reply-To: <20160131131506.4aad01b5@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

On Sun, 31 Jan 2016 13:15:06 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Jesper,
> 
> On Sat, 30 Jan 2016 18:46:46 +0100 Jesper Dangaard Brouer <brouer@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@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@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;

WARNING: multiple messages have this Message-ID (diff)
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Valdis.Kletnieks@vt.edu,
	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, Christoph Lameter <cl@linux.com>,
	Tejun Heo <tj@kernel.org>, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	brouer@redhat.com
Subject: Re: [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller()
Date: Sun, 31 Jan 2016 19:40:48 +0100	[thread overview]
Message-ID: <20160131194048.6f7add16@redhat.com> (raw)
In-Reply-To: <20160131131506.4aad01b5@canb.auug.org.au>

On Sun, 31 Jan 2016 13:15:06 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Jesper,
> 
> On Sat, 30 Jan 2016 18:46:46 +0100 Jesper Dangaard Brouer <brouer@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@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@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;

--
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: Jesper Dangaard Brouer <brouer@redhat.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Valdis.Kletnieks@vt.edu,
	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, Christoph Lameter <cl@linux.com>,
	Tejun Heo <tj@kernel.org>, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	brouer@redhat.com
Subject: Re: [slab] a1fd55538c: WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2601 trace_hardirqs_on_caller()
Date: Sun, 31 Jan 2016 19:40:48 +0100	[thread overview]
Message-ID: <20160131194048.6f7add16@redhat.com> (raw)
In-Reply-To: <20160131131506.4aad01b5@canb.auug.org.au>

On Sun, 31 Jan 2016 13:15:06 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Jesper,
> 
> On Sat, 30 Jan 2016 18:46:46 +0100 Jesper Dangaard Brouer <brouer@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@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@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;

  reply	other threads:[~2016-01-31 18:40 UTC|newest]

Thread overview: 24+ 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 14:52 ` kernel test robot
2016-01-28 14:52 ` kernel test robot
2016-01-28 17:47 ` Jesper Dangaard Brouer
2016-01-28 17:47   ` Jesper Dangaard Brouer
2016-01-28 17:47   ` Jesper Dangaard Brouer
2016-01-30  7:09   ` Valdis.Kletnieks
2016-01-30  7:09     ` Valdis.Kletnieks
2016-01-30 17:46     ` Jesper Dangaard Brouer
2016-01-30 17:46       ` Jesper Dangaard Brouer
2016-01-30 17:46       ` Jesper Dangaard Brouer
2016-01-31  2:15       ` Stephen Rothwell
2016-01-31  2:15         ` Stephen Rothwell
2016-01-31  2:15         ` Stephen Rothwell
2016-01-31 18:40         ` Jesper Dangaard Brouer [this message]
2016-01-31 18:40           ` Jesper Dangaard Brouer
2016-01-31 18:40           ` Jesper Dangaard Brouer
2016-01-31 20:34           ` Stephen Rothwell
2016-01-31 20:34             ` Stephen Rothwell
2016-01-31 20:34             ` Stephen Rothwell
2016-02-02 19:12             ` Valdis.Kletnieks
2016-03-01 18:33 ` Andrew Morton
2016-03-01 18:33   ` Andrew Morton
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=20160131194048.6f7add16@redhat.com \
    --to=brouer@redhat.com \
    --cc=lkp@lists.01.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.