Re: net: suspicious RCU usage in nf_hook

On Wed, 2017-02-01 at 15:48 -0800, Eric Dumazet wrote: > On Wed, Feb 1, 2017 at 3:29 PM, Cong Wang wrote: > > > Not sure if it is better. The difference is caught up in > > net_enable_timestamp(), > > which is called setsockopt() path and sk_clone() path, so we could

Re: net: suspicious RCU usage in nf_hook

On Wed, Feb 1, 2017 at 3:29 PM, Cong Wang wrote: > Not sure if it is better. The difference is caught up in > net_enable_timestamp(), > which is called setsockopt() path and sk_clone() path, so we could be > in netstamp_needed state for a long time too until user-space

Re: net: suspicious RCU usage in nf_hook

On Wed, Feb 1, 2017 at 1:16 PM, Eric Dumazet wrote: > On Wed, 2017-02-01 at 12:51 -0800, Cong Wang wrote: >> On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet wrote: >> > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote: >> > >> >> >> >> The context

Re: net: suspicious RCU usage in nf_hook

On Wed, 2017-02-01 at 13:16 -0800, Eric Dumazet wrote: > This would permanently leave the kernel in the netstamp_needed state. > > I would prefer the patch using a process context to perform the > cleanup ? Note there is a race window, but probably not a big deal. > > net/core/dev.c | 30

Re: net: suspicious RCU usage in nf_hook

On Wed, 2017-02-01 at 12:51 -0800, Cong Wang wrote: > On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet wrote: > > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote: > > > >> > >> The context is process context (TX path before hitting qdisc), and > >> BH is not disabled, so

Re: net: suspicious RCU usage in nf_hook

On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet wrote: > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote: > >> >> The context is process context (TX path before hitting qdisc), and >> BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this >> makes me thinking

Re: net: suspicious RCU usage in nf_hook

On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote: > > The context is process context (TX path before hitting qdisc), and > BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this > makes me thinking maybe we really need to disable BH in this > case for nf_hook()? But it is called in

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 5:31 PM, Eric Dumazet wrote: > On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote: >> On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: >> > Oh well, I forgot to submit the official patch I think, Jan 9th. >> > >> >

Re: net: suspicious RCU usage in nf_hook

On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote: > On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: > > Oh well, I forgot to submit the official patch I think, Jan 9th. > > > > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ > > > > Hmm, but why only

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet wrote: > Oh well, I forgot to submit the official patch I think, Jan 9th. > > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ > Hmm, but why only fragments need skb_orphan()? It seems like any kfree_skb() inside

Re: net: suspicious RCU usage in nf_hook

On Fri, Jan 27, 2017 at 1:15 PM, Dmitry Vyukov wrote: > stack backtrace: > CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:15

net: suspicious RCU usage in nf_hook

Hello, I've got the following report while running syzkaller fuzzer on fd694aaa46c7ed811b72eb47d5eb11ce7ab3f7f1: [ INFO: suspicious RCU usage. ] 4.10.0-rc5+ #192 Not tainted --- ./include/linux/rcupdate.h:561 Illegal context switch in RCU read-side critical section!