[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4991AE04.7020307@free.fr>
Date: Tue, 10 Feb 2009 17:40:36 +0100
From: Daniel Lezcano <daniel.lezcano@...e.fr>
To: nicolas.dichtel@....6wind.com
CC: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
containers@...ts.osdl.org
Subject: Re: [PATCH] netns: remove useless synchronize_net()
Nicolas Dichtel wrote:
> Le 06.02.2009 23:10, David Miller a écrit :
>> From: Nicolas Dichtel <nicolas.dichtel@....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 ?
dev_shutdown(dev);
/* Notify protocols, that we are about to destroy
this device. They should clean all the things.
*/
call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
/*
* Flush the unicast and multicast chains
*/
dev_addr_discard(dev);
netdev_unregister_kobject(dev);
/* Actually switch the network namespace */
dev_net_set(dev, net);
Thanks
-- Daniel
--
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