Re: Suspicious RCU usage in linux-next: Bisected to commit 8d52d399

[Martin KaFai Lau <kafai@fb.com>]

On Sun, Jun 14, 2015 at 06:06:21PM -0500, Larry Finger wrote:
> When booting kernels from Linux-next, the following is output:
> 
> [    2.816564] ===============================
> [    2.816986] [ INFO: suspicious RCU usage. ]
> [    2.817402] 4.1.0-rc7-next-20150612 #1 Not tainted
> [    2.817881] -------------------------------
> [    2.818297] kernel/sched/core.c:7318 Illegal context switch in
> RCU-bh read-side critical section!
> [    2.819180]
> other info that might help us debug this:
> 
> [    2.819947]
> rcu_scheduler_active = 1, debug_locks = 0
> [    2.820578] 3 locks held by systemd/1:
> [    2.820954]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff815f0c8f>]
> rtnetlink_rcv+0x1f/0x40
> [    2.821855]  #1:  (rcu_read_lock_bh){......}, at:
> [<ffffffff816a34e2>] ipv6_add_addr+0x62/0x540
> [    2.822808]  #2:  (addrconf_hash_lock){+...+.}, at:
> [<ffffffff816a3604>] ipv6_add_addr+0x184/0x540
> [    2.823790]
> stack backtrace:
> [    2.824212] CPU: 0 PID: 1 Comm: systemd Not tainted 4.1.0-rc7-next-20150612 #1
> [    2.824932] Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS
> Version 4.20   04/17/2014
> [    2.825751]  0000000000000001 ffff880224e07838 ffffffff817263a4 ffffffff810ccf2a
> [    2.826560]  ffff880224e08000 ffff880224e07868 ffffffff810b6827 0000000000000000
> [    2.827368]  ffffffff81a445d3 00000000000004f4 ffff88022682e100 ffff880224e07898
> [    2.828177] Call Trace:
> [    2.828422]  [<ffffffff817263a4>] dump_stack+0x4c/0x6e
> [    2.828937]  [<ffffffff810ccf2a>] ? console_unlock+0x1ca/0x510
> [    2.829514]  [<ffffffff810b6827>] lockdep_rcu_suspicious+0xe7/0x120
> [    2.830139]  [<ffffffff8108cf05>] ___might_sleep+0x1d5/0x1f0
> [    2.830699]  [<ffffffff8108cf6d>] __might_sleep+0x4d/0x90
> [    2.831239]  [<ffffffff811f3789>] ? create_object+0x39/0x2e0
> [    2.831800]  [<ffffffff811da427>] kmem_cache_alloc+0x47/0x250
> [    2.832375]  [<ffffffff813c19ae>] ? find_next_zero_bit+0x1e/0x20
> [    2.832973]  [<ffffffff811f3789>] create_object+0x39/0x2e0
> [    2.833515]  [<ffffffff810b7eb6>] ? mark_held_locks+0x66/0x90
> [    2.834089]  [<ffffffff8172efab>] ? _raw_spin_unlock_irqrestore+0x4b/0x60
> [    2.834761]  [<ffffffff817193c1>] kmemleak_alloc_percpu+0x61/0xe0
It seems to be a problem specific to kmemleak_alloc_percpu()
which does not get the 'gfp' param from pcpu_alloc.  The comment from
kmemleak_alloc_percpu():
/*
 * This function is called from the kernel percpu allocator when a new object
 * (memory block) is allocated (alloc_percpu). It assumes GFP_KERNEL
 * allocation.
 */

I will try out a change tomorrow.

--Martin