linux-kernel - Re: [bug] stuck localhost TCP connections, v2.6.26-rc3+

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080531060315.GA2692@2ka.mipt.ru>
Date:	Sat, 31 May 2008 10:03:15 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:	Ray Lee <ray-lk@...rabbit.org>, Ingo Molnar <mingo@...e.hu>,
	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 Sat, May 31, 2008 at 12:11:32AM +0300, Ilpo Järvinen (ilpo.jarvinen@...sinki.fi) wrote:
> > > > Active Internet connections (w/o servers)
> > > > Proto Recv-Q Send-Q Local Address               Foreign Address
> > > > State
> > > > tcp        0 174592 10.0.1.14:58015             10.0.1.14:3632  ESTABLISHED
> > > > tcp    72134      0 10.0.1.14:3632              10.0.1.14:58015 ESTABLISHED
> 
>              ^^^^^
> 
> Can you perhaps find/guess/think some explanation for this _receiver 
> queue_...? This was a trick question :-), as we already know that the 
> receiving process is no longer there and therefore obviously won't be 
> reading anything anymore. But that opened another question, why TCP is 
> then still in ESTABLISHED as orphaned TCP shouldn't be in establised state 
> anymore, tcp_close should have changed the state (either at close or at 
> process exit). I guess once it becomes known why tcp_close either wasn't 
> called at all or it didn't change the state of the flow (it's quite 
> simple, see for yourself), the cause of the bug is found (it might even be 
> that the process went away when it shouldn't have, either a bookkeeping 
> bug somewhere or real death, or something along those lines).

In that case pid Ingo straced was still valid and existed (ans stuck
probably in tcp_sendpage() - sysrq-t dump was messy), so process still
exist, but sock somewhat lost its reference to socket. AFICS all (three)
calls for sk_orphan() can not happen without state change to something
closing (like fin wait or close), except some linger things and
listening socket, which frees its connection requests.

-- 
	Evgeniy Polyakov
--
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/