From: Hagen Paul Pfeifer <hagen@jauu.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: David Miller <davem@davemloft.net>,
equinox@diac24.net, hans.schillstrom@ericsson.com,
netdev@vger.kernel.org
Subject: Re: RFC Hanging clean-up of a namespace
Date: Thu, 19 Jan 2012 22:40:53 +0100 [thread overview]
Message-ID: <20120119214052.GA12249@hell> (raw)
In-Reply-To: <m1lip32xoi.fsf@fess.ebiederm.org>
* Eric W. Biederman | 2012-01-19 13:24:13 [-0800]:
>This thread is a fascinating disconnect from reality all of the way
>around.
>
>- inet_twsk_purge already implements throwing out of timewait sockets
> when a network namespaces is being cleaned up. So the RFC is nonsense.
This is how it is implemented, not how it should be. TIME_WAIT is not the
problem, it is there to keep the stack from sending wrong RST messages. Maybe
the 2*MSL could be fixed by a more accurate 2*RTT.
>- Keeping the timewait sockets at that point we purge them in the code
> can achieve nothing. We don't have any userspace processes or network
> devices associated with the timewait sockets at the point we get rid
> of them. The network namespace exists so long as a userspace process
> can find it. The network namespace exit is asynchronous in it's own
> workqueue so userspace definitely is not blocked.
Another possible solution could be a netns global TIME_WAIT list. But this
is a little bit expensive and out of question - but this _is_ a convenient
solution.
The "5 second reboot" is no argument - it show a discrepance between TCP
requirements and the actual situation.
Hagen
next prev parent reply other threads:[~2012-01-19 21:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-19 11:07 RFC Hanging clean-up of a namespace Hans Schillstrom
2012-01-19 13:31 ` David Lamparter
2012-01-19 17:40 ` David Miller
2012-01-19 19:01 ` David Lamparter
2012-01-19 19:06 ` David Miller
2012-01-19 19:25 ` David Lamparter
2012-01-19 19:31 ` David Miller
2012-01-19 19:53 ` David Lamparter
2012-01-19 20:27 ` David Miller
2012-01-19 21:03 ` David Lamparter
2012-01-19 21:24 ` Eric W. Biederman
2012-01-19 21:40 ` David Lamparter
2012-01-19 21:40 ` Hagen Paul Pfeifer [this message]
2012-01-19 21:47 ` David Lamparter
2012-01-19 22:10 ` Rick Jones
2012-01-19 22:16 ` Hagen Paul Pfeifer
2012-01-19 22:37 ` David Miller
2012-01-20 6:08 ` Hans Schillstrom
2012-01-20 10:08 ` Eric W. Biederman
2012-01-20 11:51 ` Hans Schillstrom
2012-01-20 20:55 ` Eric W. Biederman
2012-01-23 6:07 ` Hans Schillstrom
2012-01-23 6:25 ` Eric W. Biederman
2012-01-23 6:58 ` Hans Schillstrom
2012-01-23 7:17 ` Eric W. Biederman
2012-01-23 7:30 ` Hans Schillstrom
2012-01-23 7:55 ` Eric W. Biederman
2012-01-19 19:40 ` Hans Schillström
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120119214052.GA12249@hell \
--to=hagen@jauu.net \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=equinox@diac24.net \
--cc=hans.schillstrom@ericsson.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.