Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753357AbbFNXGd (ORCPT ); Sun, 14 Jun 2015 19:06:33 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:36063 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752093AbbFNXGZ (ORCPT ); Sun, 14 Jun 2015 19:06:25 -0400 Message-ID: <557E08ED.8030808@lwfinger.net> Date: Sun, 14 Jun 2015 18:06:21 -0500 From: Larry Finger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: LKML , Martin KaFai Lau , "David S. Miller" Subject: Suspicious RCU usage in linux-next: Bisected to commit 8d52d399 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4872 Lines: 100 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: [] rtnetlink_rcv+0x1f/0x40 [ 2.821855] #1: (rcu_read_lock_bh){......}, at: [] ipv6_add_addr+0x62/0x540 [ 2.822808] #2: (addrconf_hash_lock){+...+.}, at: [] 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] [] dump_stack+0x4c/0x6e [ 2.828937] [] ? console_unlock+0x1ca/0x510 [ 2.829514] [] lockdep_rcu_suspicious+0xe7/0x120 [ 2.830139] [] ___might_sleep+0x1d5/0x1f0 [ 2.830699] [] __might_sleep+0x4d/0x90 [ 2.831239] [] ? create_object+0x39/0x2e0 [ 2.831800] [] kmem_cache_alloc+0x47/0x250 [ 2.832375] [] ? find_next_zero_bit+0x1e/0x20 [ 2.832973] [] create_object+0x39/0x2e0 [ 2.833515] [] ? mark_held_locks+0x66/0x90 [ 2.834089] [] ? _raw_spin_unlock_irqrestore+0x4b/0x60 [ 2.834761] [] kmemleak_alloc_percpu+0x61/0xe0 [ 2.835369] [] pcpu_alloc+0x370/0x630 [ 2.835900] [] ? dst_ifdown+0x41/0x90 [ 2.836425] [] __alloc_percpu_gfp+0x12/0x20 [ 2.837008] [] ip6_dst_alloc.isra.41+0x30/0xa0 [ 2.837610] [] addrconf_dst_alloc+0x3d/0xf0 [ 2.838191] [] ipv6_add_addr+0x27c/0x540 [ 2.838743] [] ? ipv6_add_addr+0x62/0x540 [ 2.839307] [] inet6_addr_add+0x11b/0x260 [ 2.839872] [] inet6_rtm_newaddr+0x343/0x450 [ 2.840457] [] ? __lock_acquire+0x53d/0x1510 [ 2.841048] [] rtnetlink_rcv_msg+0x95/0x240 [ 2.841625] [] ? trace_hardirqs_on+0xd/0x10 [ 2.860830] [] ? rtnetlink_rcv+0x1f/0x40 [ 2.879948] [] ? rtnetlink_rcv+0x40/0x40 [ 2.898849] [] netlink_rcv_skb+0xaf/0xc0 [ 2.917687] [] rtnetlink_rcv+0x2e/0x40 [ 2.936468] [] netlink_unicast+0x14c/0x1f0 [ 2.955266] [] netlink_sendmsg+0x320/0x3a0 [ 2.973517] [] ? __might_fault+0x4d/0xa0 [ 2.991353] [] sock_sendmsg+0x38/0x50 [ 3.009172] [] SYSC_sendto+0xef/0x170 [ 3.026925] [] ? up_write+0x23/0x50 [ 3.045032] [] ? lockdep_sys_exit_thunk+0x12/0x14 [ 3.063189] [] SyS_sendto+0xe/0x10 [ 3.081227] [] entry_SYSCALL_64_fastpath+0x12/0x6f The above splat is followed by several "BUG: sleeping function called from invalid context at mm/slub.c:1268" messages, but these are probably secondary. The most recent commit was d9b5ec5b1b4d4055e256674de4a5337f6a66d284. This problem has been bisected to the following: commit d52d3997f843ffefaa8d8462790ffcaca6c74192 Author: Martin KaFai Lau Date: Fri May 22 20:56:06 2015 -0700 ipv6: Create percpu rt6_info After the patch 'ipv6: Only create RTF_CACHE routes after encountering pmtu exception', we need to compensate the performance hit (bouncing dst->__refcnt). Signed-off-by: Martin KaFai Lau Cc: Hannes Frederic Sowa Cc: Steffen Klassert Cc: Julian Anastasov Signed-off-by: David S. Miller I will be happy to test any suggested patches. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/