Em 15-04-2016 17:58, Stephen Hemminger escreveu:
On Sat, 09 Apr 2016 01:55:06 +0200
Hannes Frederic Sowa <han...@stressinduktion.org> wrote:
On Sat, Apr 9, 2016, at 01:24, Cong Wang wrote:
On Fri, Apr 8, 2016 at 1:55 PM, Hannes Frederic Sowa
<han...@stressinduktion.org> wrote:
Due to the fact that the udp socket is destructed asynchronously in a
work queue, we have some nondeterministic behavior during shutdown of
vxlan tunnels and creating new ones. Fix this by keeping the destruction
process synchronous in regards to the user space process so IFF_UP can
be reliably set.
udp_tunnel_sock_release destroys vs->sock->sk if reference counter
indicates so. We expect to have the same lifetime of vxlan_sock and
vxlan_sock->sock->sk even in fast paths with only rcu locks held. So
only destruct the whole socket after we can be sure it cannot be found
by searching vxlan_net->sock_list.
I am wondering what is the reason why we used work queue from
the beginning?
I actually don't know. It was like that from the beginning. I cc'ed
Stephen, maybe he remembers?
Bye,
Hannes
The problem was that VXLAN needs to update multicast settings and that
can't be done under RTNL.
If the socket destroy was delayed just due to this, it should be all
good then, because I took care of this multicast issue on commits
56ef9c909b40 ("vxlan: Move socket initialization to within rtnl scope")
54ff9ef36bdf ("ipv4, ipv6: kill ip_mc_{join, leave}_group and
ipv6_sock_mc_{join, drop}")
Marcelo
