Messages in this thread | | | Date | Sun, 14 Jun 2015 17:24:45 -0700 | From | Martin KaFai Lau <> | Subject | Re: Suspicious RCU usage in linux-next: Bisected to commit 8d52d399 |
| |
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
| |