[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1459473592.6473.243.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Thu, 31 Mar 2016 18:19:52 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
sasha.levin@...cle.com, daniel@...earbox.net,
alexei.starovoitov@...il.com, mkubecek@...e.cz
Subject: Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around
__sk_dst_get
On Fri, 2016-04-01 at 02:21 +0200, Hannes Frederic Sowa wrote:
>
> [ 31.064029] ===============================
> [ 31.064030] [ INFO: suspicious RCU usage. ]
> [ 31.064032] 4.5.0+ #13 Not tainted
> [ 31.064033] -------------------------------
> [ 31.064034] include/net/sock.h:1594 suspicious
> rcu_dereference_check() usage!
> [ 31.064035]
> other info that might help us debug this:
>
> [ 31.064041]
> rcu_scheduler_active = 1, debug_locks = 1
> [ 31.064042] no locks held by ssh/817.
> [ 31.064043]
> stack backtrace:
> [ 31.064045] CPU: 0 PID: 817 Comm: ssh Not tainted 4.5.0+ #13
> [ 31.064046] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.8.2-20150714_191134- 04/01/2014
> [ 31.064047] 0000000000000286 000000006730b46b ffff8800badf7bd0
> ffffffff81442b33
> [ 31.064050] ffff8800b8c78000 0000000000000001 ffff8800badf7c00
> ffffffff8110ae75
> [ 31.064052] ffff880035ea2f00 ffff8800b8e28000 0000000000000003
> 00000000000004c4
> [ 31.064054] Call Trace:
> [ 31.064058] [<ffffffff81442b33>] dump_stack+0x85/0xc2
> [ 31.064062] [<ffffffff8110ae75>] lockdep_rcu_suspicious+0xc5/0x100
> [ 31.064064] [<ffffffff8173bf57>] __sk_dst_check+0x77/0xb0
> [ 31.064066] [<ffffffff8182e502>] inet6_sk_rebuild_header+0x52/0x300
> [ 31.064068] [<ffffffff813bb61e>] ? selinux_skb_peerlbl_sid+0x5e/0xa0
> [ 31.064070] [<ffffffff813bb69e>] ?
> selinux_inet_conn_established+0x3e/0x40
> [ 31.064072] [<ffffffff817c2bad>] tcp_finish_connect+0x4d/0x270
> [ 31.064074] [<ffffffff817c33f7>] tcp_rcv_state_process+0x627/0xe40
> [ 31.064076] [<ffffffff81866584>] tcp_v6_do_rcv+0xd4/0x410
> [ 31.064078] [<ffffffff8173bc65>] release_sock+0x85/0x1c0
> [ 31.064079] [<ffffffff817e9983>] __inet_stream_connect+0x1c3/0x340
> [ 31.064081] [<ffffffff8173b089>] ? lock_sock_nested+0x49/0xb0
> [ 31.064083] [<ffffffff81100270>] ? abort_exclusive_wait+0xb0/0xb0
> [ 31.064084] [<ffffffff817e9b38>] inet_stream_connect+0x38/0x50
> [ 31.064086] [<ffffffff8173794f>] SYSC_connect+0xcf/0xf0
> [ 31.064088] [<ffffffff8110d069>] ? trace_hardirqs_on_caller+0x129/0x1b0
> [ 31.064090] [<ffffffff8100301b>] ? trace_hardirqs_on_thunk+0x1b/0x1d
> [ 31.064091] [<ffffffff8173854e>] SyS_connect+0xe/0x10
> [ 31.064094] [<ffffffff818a0e7c>] entry_SYSCALL_64_fastpath+0x1f/0xbd
>
> Bye,
> Hannes
Thanks.
As you can see, release_sock() messes badly lockdep (once your other
patches are in )
Once we properly fix release_sock() and/or __release_sock(), all these
false positives disappear.
Powered by blists - more mailing lists