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

Evgeniy Polyakov
2008-05-31T06:04:00Z

On Sat, May 31, 2008 at 12:11:32AM +0300, Ilpo Järvinen (ilpo.jarvinen@helsinki.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