[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1445527240.7084.46.camel@redhat.com>
Date: Thu, 22 Oct 2015 17:20:40 +0200
From: Thomas Haller <thaller@...hat.com>
To: Jiri Benc <jbenc@...hat.com>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net] net: try harder to not reuse ifindex when moving
interfaces
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
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists