Hello, On Thu, Oct 22, 2015, at 17:00, Jiri Benc wrote: > On Thu, 22 Oct 2015 16:52:13 +0200, Nicolas Dichtel wrote: > > With the proposed scenario: > > 1. create netns 'new_netns' > > 2. in root netns, move the interface with ifindex 2 to new_netns > > 3. in new_netns, delete the interface with ifindex 2 > > 4. in new_netns, create an interface - it will get ifindex 2 > > > > Operation 2 and 4 are done by dev_change_net_namespace() under rtnl_lock(). > > RTM_DELLINK(root netns) and RTM_NEWLINK(new_netns) are sent by this > > function. > > It means that operation 3 has been done before and that > > RTM_DELLINK(new_netns) > > has been sent before. > > Imagine the application trying to configure the interface with ifindex 2 > after your step 2. It constructs a netlink message and sends it to the > kernel; but while doing so, steps 3 and 4 happen. Now the application > ends up configuring a different interface than it intended to. After > that, it polls the netlink socket and receives the notifications about > interface disappearing and a new one appearing. > > I don't see any way the user space application can prevent this. There > will always be a race between receiving netlink notifications and > sending config requests.
ifindexes are not only used with netlink monitor but also normal socket api, so it would make sense to try to not reassign any ifindex before the overflow of the net->ifindex as they don't listen for notifications of interface removals or creations. Thanks, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
