[PATCH] netns: remove useless synchronize_net()

Nicolas Dichtel nicolas.dichtel at dev.6wind.com
Tue Feb 10 08:48:26 PST 2009


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

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


More information about the Containers mailing list