On Thu, 2015-10-22 at 17:00 +0200, 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. > > I guess Thomas Haller can elaborate more as he ran into this.
Jiri, It's really just what you said. Whatever action the application wants to perform when using the ifindex, there is a time-window between learning about the ifindex and using it. There is nothing userspace can do except trying to hurry and hoping for the best. Thomas
signature.asc
Description: This is a digitally signed message part
