[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d56b7989-8ac6-36be-0d0b-43251e1a2907@gmail.com>
Date: Mon, 29 Apr 2019 12:43:14 -0600
From: David Ahern <dsahern@...il.com>
To: David Ahern <dsahern@...il.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Eric Dumazet <eric.dumazet@...il.com>,
"David S. Miller" <davem@...emloft.net>
Cc: Julian Anastasov <ja@....bg>, Cong Wang <xiyou.wangcong@...il.com>,
syzbot <syzbot+30209ea299c09d8785c9@...kaller.appspotmail.com>,
ddstreet@...e.org, dvyukov@...gle.com,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
syzkaller-bugs@...glegroups.com
Subject: Re: unregister_netdevice: waiting for DEV to become free (2)
On 4/29/19 12:34 PM, David Ahern wrote:
> On 4/27/19 10:22 PM, Tetsuo Handa wrote:
>> On 2019/04/28 8:52, Eric Dumazet wrote:
>>> On 4/27/19 3:33 PM, Tetsuo Handa wrote:
>>>>
>>>> I'm waiting for davem why it is safe to move the dst entry from
>>>> "a device to unregister" to "a loopback device in that namespace".
>>>> I'm waiting for an explanation how the dst entry which was moved to
>>>> "a loopback device in that namespace" is released (i.e. what the
>>>> expected shutdown sequence is).
>>>
>>> The most probable explanation is that we make sure the loopback device
>>> is the last one to be dismantled at netns deletion,
>>> and this would obviously happen after all dst have been released.
>>>
>>
>> rt_flush_dev() becomes a no-op if "dev" == "a loopback device in that
>> namespace". And according to debug printk(), rt_flush_dev() is called
>> on "a loopback device in that namespace" itself.
>>
>> If "a loopback device in that namespace" is the last "one" (== "a network
>> device in that namespace" ?), which shutdown sequence should have called
>> dev_put("a loopback device in that namespace") before unregistration of
>> "a loopback device in that namespace" starts?
>>
>> Since I'm not a netdev person, I appreciate if you can explain
>> that shutdown sequence using a flow chart.
>>
>
> The attached patch adds a tracepoint to notifier_call_chain. If you have
> KALLSYMS enabled it will show the order of the function handlers:
>
> perf record -e notifier:* -a -g &
>
> ip netns del <NAME>
> <wait a few seconds>
>
> fg
> <ctrl-c on perf-record>
>
> perf script
>
with the header file this time.
View attachment "0001-notifier-add-tracepoint-to-notifier_call_chain.patch" of type "text/plain" (2436 bytes)
Powered by blists - more mailing lists