From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Schillstrom Subject: Re: conntrack, suspicious RCU usage Date: Wed, 11 Jan 2012 14:24:26 +0100 Message-ID: <201201111424.27282.hans.schillstrom@ericsson.com> References: <201201111025.50994.hans.schillstrom@ericsson.com> <1326276111.2767.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "netfilter-devel@vger.kernel.org" To: Eric Dumazet Return-path: Received: from mailgw10.se.ericsson.net ([193.180.251.61]:45932 "EHLO mailgw10.se.ericsson.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757190Ab2AKNYa convert rfc822-to-8bit (ORCPT ); Wed, 11 Jan 2012 08:24:30 -0500 In-Reply-To: <1326276111.2767.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> Content-Disposition: inline Sender: netfilter-devel-owner@vger.kernel.org List-ID: On Wednesday 11 January 2012 11:01:51 Eric Dumazet wrote: > Le mercredi 11 janvier 2012 =C3=A0 10:25 +0100, Hans Schillstrom a =C3= =A9crit : > > Hello > > I got this the first time using conntrack -L when there is a lot of= traffic. > > It doesn't result in any thing bad yet. > >=20 > > Is this a know thing ? > > or should I dig into it.. > >=20 > > I'm running the latest and greatest conntrack / netfilter tools and= libs. > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > [ INFO: suspicious RCU usage. ] > > ------------------------------- > > /home/hans/evip.git/kvm/net-next.git/include/net/netfilter/nf_connt= rack_l3proto.h:92 suspicious rcu_dereference_check() usage! > >=20 > > other info that might help us debug this: > >=20 > >=20 > > rcu_scheduler_active =3D 1, debug_locks =3D 0 > > 3 locks held by conntrack/2249: > > #0: (nfnl_mutex){+.+.+.}, at: [] nfnl_lock+0x17= /0x19 > > #1: (nlk->cb_mutex){+.+.+.}, at: [] netlink_dum= p+0x27/0x1ec > > #2: (nf_conntrack_lock){+.-...}, at: [] 0xfffff= fffa00b8922 > >=20 > > stack backtrace: > > Pid: 2249, comm: conntrack Tainted: G W 3.2.0+ #34 > > Call Trace: > > [] ? console_unlock+0x164/0x20c > > [] lockdep_rcu_suspicious+0xd8/0xe1 > > [] 0xffffffffa00b78a9 > > [] 0xffffffffa00b819b > > [] 0xffffffffa00b898e > > [] netlink_dump+0x74/0x1ec > > [] ? 0xffffffffa00b88e3 > > [] netlink_dump_start+0x103/0x135 > > [] ? 0xffffffffa00b77f9 > > [] 0xffffffffa00b86a7 > > [] ? nfnl_lock+0x17/0x19 > > [] nfnetlink_rcv_msg+0x493/0x4cd > > [] ? nfnetlink_rcv_msg+0x11b/0x4cd > > [] ? nfnetlink_rcv_msg+0xb8/0x4cd > > [] ? netlink_lookup+0xc4/0xcf > > [] ? nfnl_lock+0x19/0x19 > > [] netlink_rcv_skb+0x43/0x94 > > [] nfnetlink_rcv+0x15/0x17 > > [] netlink_unicast+0x13d/0x1b4 > > [] netlink_sendmsg+0x201/0x269 > > [] sock_sendmsg+0xea/0x109 > > [] ? lock_release_holdtime+0xfd/0x102 > > [] ? might_fault+0x40/0x90 > > [] ? might_fault+0x40/0x90 > > [] ? might_fault+0x40/0x90 > > [] ? might_fault+0x89/0x90 > > [] ? might_fault+0x40/0x90 > > [] ? move_addr_to_kernel+0x3f/0x56 > > [] sys_sendto+0x102/0x12a > > [] ? kmem_cache_free+0xc7/0x1b2 > > [] ? trace_hardirqs_on+0xd/0xf > > [] system_call_fastpath+0x16/0x1b > >=20 > >=20 >=20 > Hmm, we either need to take rcu_read_lock() while calling > __nf_ct_l3proto_find(), or define a variant using > rcu_dereference_protected() in places we hold nf_conntrack_lock >=20 I made a qick test with locks /unlocks in __nf_ct_l3proto_find() and __nf_ct_l4proto_find() rcu_read_lock(); =2E.. rcu_read_unlock(); return retp; It seems to help, I cant see the dump anymore and everything else that = I run works ... --=20 Regards Hans Schillstrom -- To unsubscribe from this list: send the line "unsubscribe netfilter-dev= el" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html