[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a9075b87-4f02-fe78-e86d-34f67bdf8b2a@gmail.com>
Date: Sun, 28 Apr 2019 08:04:18 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
David Ahern <dsahern@...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/27/19 9: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.
>
This is the design yes. We can not let a dst having a pointer to some garbage memory.
(since we are going to free it very soon)
dst can be long lived objects. netdev (but loopback) are not.
> 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?
You'll have to study all the netdev notifiers to answer this question.
They are many of them, and they have a priority to let them run in a given order.
>
> Since I'm not a netdev person, I appreciate if you can explain
> that shutdown sequence using a flow chart.
I am a netdev person, but I have no time to explain this at this moment.
Powered by blists - more mailing lists