From: Daniel Lezcano <daniel.lezcano@free.fr>
To: nicolas.dichtel@dev.6wind.com
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, containers@lists.osdl.org,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] netns: remove useless synchronize_net()
Date: Tue, 10 Feb 2009 18:13:45 +0100 [thread overview]
Message-ID: <4991B5C9.9040005@free.fr> (raw)
In-Reply-To: <4991AFDA.8020704@dev.6wind.com>
Nicolas Dichtel wrote:
> Le 10.02.2009 17:40, Daniel Lezcano a écrit :
>> Nicolas Dichtel wrote:
>>> Le 06.02.2009 23:10, David Miller a écrit :
>>>> From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
>>>> Date: Fri, 06 Feb 2009 14:50:53 +0100
>>>>
>>>>> If namespace is destroyed after this function, then cleanup_net()
>>>>> will ensure that nobody is looking at it
>>>>
>>>> Maybe, but you better get some opinions from the people who wrote
>>>> and maintain the network namespace code before I can consider
>>>> your change seriously.
>>>>
>>>> None of them responded to your patch posting, probably because
>>>> you failed to CC: any of them.
>>> Sorry, I forget to cc them, now it's done.
>>> The thread can be found here:
>>> http://marc.info/?l=linux-netdev&m=123382930115535&w=2
>>>
>>> So, I'm waiting for maintainers's opinions.
>> We can move one network device from one namespace to another
>> namespace, and that do not necessarily implies the network namespace
>> will die and call cleanup_net.
>> Without synchronize_net, it would be possible to have
>> netif_receive_skb and dev_change_net_namespace to be executed
>> concurrently, no ?
>> Wouldn't the execution of one of this function be problematic if we
>> are in the delivery of a packet to the upper protocol in the big
>> rcu_read_lock section of netif_receive_skb ?
> Just to be sure: there is two synchronize_net() in
> dev_change_net_namespace(), and I was talking about the second one.
> The second one is called just before exiting the function.
>
>
> Regards,
> Nicolas
Ah, ok :)
Hmm, at the first glance I would say it is useless but perhaps there is
a trick here I do not understand.
Eric, is there any particular reason to call synchronize_net before
exiting the dev_change_net_namespace function ?
next prev parent reply other threads:[~2009-02-10 17:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-05 10:21 [PATCH] netns: remove useless synchronize_net() Nicolas Dichtel
2009-02-06 7:45 ` David Miller
2009-02-06 13:50 ` Nicolas Dichtel
2009-02-06 22:10 ` David Miller
2009-02-10 15:40 ` Nicolas Dichtel
2009-02-10 16:40 ` Daniel Lezcano
2009-02-10 16:48 ` Nicolas Dichtel
2009-02-10 17:13 ` Daniel Lezcano [this message]
2009-02-11 7:51 ` Eric W. Biederman
2009-02-11 15:49 ` Daniel Lezcano
2009-02-11 23:03 ` Eric W. Biederman
2009-02-12 15:11 ` Daniel Lezcano
[not found] ` <49943C17.5080509-GANU6spQydw@public.gmane.org>
2009-02-15 16:13 ` Daniel Lezcano
[not found] ` <49983F0D.2090905-GANU6spQydw@public.gmane.org>
2009-02-16 13:46 ` Nicolas Dichtel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4991B5C9.9040005@free.fr \
--to=daniel.lezcano@free.fr \
--cc=containers@lists.osdl.org \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@dev.6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).