[PATCH V2] mm: kmemleak_alloc_percpu() should follow the gfp from

[Larry Finger]

Beginning at commit d52d3997f843 ("ipv6: Create percpu rt6_info"), the
following INFO splat is logged:

===============================
[ INFO: suspicious RCU usage. ]
4.1.0-rc7-next-20150612 #1 Not tainted
-------------------------------
kernel/sched/core.c:7318 Illegal context switch in RCU-bh read-side critical section!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
 3 locks held by systemd/1:
 #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff815f0c8f>] rtnetlink_rcv+0x1f/0x40
 #1:  (rcu_read_lock_bh){......}, at: [<ffffffff816a34e2>] ipv6_add_addr+0x62/0x540
 #2:  (addrconf_hash_lock){+...+.}, at: [<ffffffff816a3604>] ipv6_add_addr+0x184/0x540
stack backtrace:
CPU: 0 PID: 1 Comm: systemd Not tainted 4.1.0-rc7-next-20150612 #1
Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20   04/17/2014
 0000000000000001 ffff880224e07838 ffffffff817263a4 ffffffff810ccf2a
 ffff880224e08000 ffff880224e07868 ffffffff810b6827 0000000000000000
 ffffffff81a445d3 00000000000004f4 ffff88022682e100 ffff880224e07898
Call Trace:
 [<ffffffff817263a4>] dump_stack+0x4c/0x6e
 [<ffffffff810ccf2a>] ? console_unlock+0x1ca/0x510
 [<ffffffff810b6827>] lockdep_rcu_suspicious+0xe7/0x120
 [<ffffffff8108cf05>] ___might_sleep+0x1d5/0x1f0
 [<ffffffff8108cf6d>] __might_sleep+0x4d/0x90
 [<ffffffff811f3789>] ? create_object+0x39/0x2e0
 [<ffffffff811da427>] kmem_cache_alloc+0x47/0x250
 [<ffffffff813c19ae>] ? find_next_zero_bit+0x1e/0x20
 [<ffffffff811f3789>] create_object+0x39/0x2e0
 [<ffffffff810b7eb6>] ? mark_held_locks+0x66/0x90
 [<ffffffff8172efab>] ? _raw_spin_unlock_irqrestore+0x4b/0x60
 [<ffffffff817193c1>] kmemleak_alloc_percpu+0x61/0xe0
 [<ffffffff811a26f0>] pcpu_alloc+0x370/0x630

Additional backtrace lines are truncated. In addition, the above splat is
followed by several "BUG: sleeping function called from invalid context
at mm/slub.c:1268" outputs. As suggested by Martin KaFai Lau, these are the
clue to the fix. Routine kmemleak_alloc_percpu() always uses GFP_KERNEL
for its allocations, whereas it should follow the gfp from its callers.

Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx>
Reviewed-by: Kamalesh Babulal <kamalesh@xxxxxxxxxxxxxxxxxx>
Signed-off-by: Larry Finger <Larry.Finger@xxxxxxxxxxxx>
Cc: Martin KaFai Lau <kafai@xxxxxx>
Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
To: Tejun Heo <tj@xxxxxxxxxx>
Cc: Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx
Cc: linux-mm@xxxxxxxxx
Cc: <stable@xxxxxxxxxxxxxxx> # v3.18+
Acked-by: Martin KaFai Lau <kafai@xxxxxx>
---
V2 - Remove extraneous file added by mistake as noted by Catalin and Kamalesh
     Comment revised and Stable added as suggested by Catalin
     Wording changes in commit message suggested by Martin

---
 include/linux/kmemleak.h | 3 ++-
 mm/kmemleak.c            | 9 +++++----
 mm/percpu.c              | 2 +-
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
index e705467..ec4437b 100644
--- a/include/linux/kmemleak.h
+++ b/include/linux/kmemleak.h
@@ -28,7 +28,8 @@
 extern void kmemleak_init(void) __ref;
 extern void kmemleak_alloc(const void *ptr, size_t size, int min_count,
 			   gfp_t gfp) __ref;
-extern void kmemleak_alloc_percpu(const void __percpu *ptr, size_t size) __ref;
+extern void kmemleak_alloc_percpu(const void __percpu *ptr, size_t size,
+				  gfp_t gfp) __ref;
 extern void kmemleak_free(const void *ptr) __ref;
 extern void kmemleak_free_part(const void *ptr, size_t size) __ref;
 extern void kmemleak_free_percpu(const void __percpu *ptr) __ref;
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index ca9e5a5..cf79f11 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -930,12 +930,13 @@ EXPORT_SYMBOL_GPL(kmemleak_alloc);
  * kmemleak_alloc_percpu - register a newly allocated __percpu object
  * @ptr:	__percpu pointer to beginning of the object
  * @size:	size of the object
+ * @gfp:	flags used for kmemleak internal memory allocations
  *
  * This function is called from the kernel percpu allocator when a new object
- * (memory block) is allocated (alloc_percpu). It assumes GFP_KERNEL
- * allocation.
+ * (memory block) is allocated (alloc_percpu).
  */
-void __ref kmemleak_alloc_percpu(const void __percpu *ptr, size_t size)
+void __ref kmemleak_alloc_percpu(const void __percpu *ptr, size_t size,
+				 gfp_t gfp)
 {
 	unsigned int cpu;
 
@@ -948,7 +949,7 @@ void __ref kmemleak_alloc_percpu(const void __percpu *ptr, size_t size)
 	if (kmemleak_enabled && ptr && !IS_ERR(ptr))
 		for_each_possible_cpu(cpu)
 			create_object((unsigned long)per_cpu_ptr(ptr, cpu),
-				      size, 0, GFP_KERNEL);
+				      size, 0, gfp);
 	else if (kmemleak_early_log)
 		log_early(KMEMLEAK_ALLOC_PERCPU, ptr, size, 0);
 }
diff --git a/mm/percpu.c b/mm/percpu.c
index dfd0248..2dd7448 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1030,7 +1030,7 @@ area_found:
 		memset((void *)pcpu_chunk_addr(chunk, cpu, 0) + off, 0, size);
 
 	ptr = __addr_to_pcpu_ptr(chunk->base_addr + off);
-	kmemleak_alloc_percpu(ptr, size);
+	kmemleak_alloc_percpu(ptr, size, gfp);
 	return ptr;
 
 fail_unlock:
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/