[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0805301436260.16829@wrl-59.cs.helsinki.fi>
Date: Sat, 31 May 2008 00:12:23 +0300 (EEST)
From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To: Ingo Molnar <mingo@...e.hu>
cc: LKML <linux-kernel@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [bug] stuck localhost TCP connections, v2.6.26-rc3+
On Fri, 30 May 2008, Ingo Molnar wrote:
> * Ingo Molnar <mingo@...e.hu> wrote:
>
> > btw., i now also have a hung socket over real network:
>
> last night i turned off distcc support, and got about 200 successful
> bootups and zero TCP hangs (as expected - there's not much TCP traffic
> if the distcc cluster is not utilized).
>
> but that's 200 overnight tests instead of the expected 600, so this is a
> major and rather crippling bug to me.
>
> There's no good way to detect these hung sockets by me from userspace
> and get rid of them. Has anyone before thought of the obvious: to write
> a kernel-space "TCP socket watchdog" kernel feature that detects them
> and tries to free them so that people can become aware of it?
>
> Hung sockets is a re-occuring bug in the TCP stack after all. (and it's
> a natural property of it: state machine designs are always vulnerable to
> lost event problems.)
...It is quite easy to kill a TCP flow with enough information (seqnos
which one could collect e.g., from a tcpdump), just a RST is necessary,
so user-space could do that too.
--
i.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists