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  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]
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

Powered by blists - more mailing lists