netdev - Re: [Patch net] rtnetlink: call rtnl_lock_unregistering() in rtnl_link

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87mwenjqx6.fsf@x220.int.ebiederm.org>
Date:	Mon, 12 May 2014 02:18:45 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Cong Wang <xiyou.wangcong@...il.com>
Cc:	Stephen Hemminger <stephen@...workplumber.org>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Cong Wang <cwang@...pensource.com>
Subject: Re: [Patch net] rtnetlink: call rtnl_lock_unregistering() in rtnl_link_unregister()

Cong Wang <xiyou.wangcong@...il.com> writes:

> On Fri, May 9, 2014 at 4:05 PM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>> Cong Wang <xiyou.wangcong@...il.com> writes:
>>
>>> On Fri, May 9, 2014 at 12:02 PM, Stephen Hemminger
>>> <stephen@...workplumber.org> wrote:
>>>> On Fri, 9 May 2014 11:10:36 -0700
>>>> Cong Wang <xiyou.wangcong@...il.com> wrote:
>>>>
>>>>>
>>>>> This can't be done without a macro (at least for me). Or
>>>>> we have to duplicate the code.
>>>>
>>>> macro method is too ugly, figure out a better way.
>>>
>>> That's what I am going to do for -net-next. This patch is for -net,
>>> it's an ugly but minimum change I can find.
>>>
>>> Of course, if you insist we should clean up it for -net as well,
>>> I can do that.
>>
>> It would be no worse to rename the existing function
>> rtnl_lock_unregistering_list
>>
>> And add a second function rtnl_lock_unregistering that does
>> the same thing but uses the global list.
>>
>> Of course this begs the question what happens if the network
>> device we want to destroy is a network namespace that is currently
>> exiting and not on the global list.
>>
>
> OK, so we have to duplicate the code.
>
>> It looks like we need to grab the net_mutex to get a state where network
>> namespaces are not exiting...
>>
>
> Hmm, for me it looks like we need net_mutex only we change pernet ops,
> here rtnl lock is enough. No?

Look at net/core/net_namespace.c:cleanup_net

While namespaces are being torn down the net_mutex is held.  At the same
time the rtnl_mutex is not held, and those namespaces are not on the
net_namespace_list.

So while holding the rtnl_lock is enough to traverse the net_namespace
list without it changing.  You need the net_mutex to make certain there
are not network namespaces in the final stages of being cleaned up
that are not on the net_namespaces list.

Those namespaces in the final stages of being cleaned up are as
problematic as network devices that are being cleaned up that live
on the netdev todo list.  for_each_net in rtnl_link_unregister
can not see them.

Eric

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html