[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120119195349.GN2262734@jupiter.n2.diac24.net>
Date: Thu, 19 Jan 2012 20:53:49 +0100
From: David Lamparter <equinox@...c24.net>
To: David Miller <davem@...emloft.net>
Cc: equinox@...c24.net, hans.schillstrom@...csson.com,
netdev@...r.kernel.org, ebiederm@...ssion.com
Subject: Re: RFC Hanging clean-up of a namespace
On Thu, Jan 19, 2012 at 02:31:05PM -0500, David Miller wrote:
> >> >> Keeping the timewait sockets around is necessary to absorb any lingering
> >> >> packets in the network meant for those sockets.
[...]
> >> The assumption is that the address is moving, which might not be true.
> >
> > I don't understand what you mean, what address may not be moving?
> >
> > We're talking about dropping a netns. All of its addresses disappear,
> > all of its soft devices disappear. Its hard devices fall back into the
> > init namespace, is that what you're referring to?
>
> And then you immediately start up a new netns with the same address
> and then resets go back to lingering TCP packets the time-waits would
> have consumed.
>
> The reason this is different from a host reboot is that a host reboot
> takes some amount of time, which even if around 30 seconds is superior
> in behavior to what can happen with netns which can be created almost
> instantly.
Arjan van de Ven booted Linux in 5 seconds in 2008,
cf. http://lwn.net/Articles/299483/
On the TCP timewait scale of time, this is pretty much "immediate".
[..]
> Then if a new netns is created that tries to reuse the address used by
> the mini-netns which hasn't cleared yet, you give -EAGAIN until all
> the timewaits expire.
The effect of this is that you end up being unable to reboot lxc based
virtualised hosts without waiting 2 minutes for the TCP timers to
expire. That sounds completely unacceptable to me.
Another perspective of this is looking at the device references held by a
namespace. I can without any issue and at any time move a network device
into another namespace. This creates exactly the same situation where
the TCP stack that now has the device may reset old connections.
(Now you may argue that one should remove the network devices from a
netns before closing it. One could do that, yes, but that would require
having access to the netns before it actually goes down. That's
problematic if the system inside the netns shuts down uncleanly. Also,
the now-device-devoid network namespace will hold kernel resources for
no good reason.)
> That's much more acceptable to me than what it being proposed, which is
> complete gatbage.
I respectfully disagree.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists