Hi Thomas, On Thu, Oct 22, 2015, at 18:45, Thomas Graf wrote: > On 10/22/15 at 05:00pm, 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. > > I understand the race but when does it occur? Whoever creates > the original interface owns it and is responsible for its > lifecycle. *Iff* for some reason multiple entities manipulate > the interface, then it's probably a lot safer to just use flock > or something similar to serialize access entirely in user space.
This only works if all networking configuration programs would standardize on the same flock. Also, under memory pressure we lose netlink monitor messages, so we need to deal with timeouts and retries and manual sync up on the networking configuration, which makes this scheme a lot harder. For normal socket io, where we specify e.g. ifindex in sin6_addr, this is not really usable at all. Bye, 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
