Cc: LKML <linux-kernel@...>, Netdev <netdev@...>, David S. Miller <davem@...>, Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, Evgeniy Polyakov <johnpol@...>
...Yes, also the previous one you quoted was already over the network.
But I think the key is in the receiving end rather than in the sending
end. Could try to extract any information about these I mentioned earlier,
to me there are mainly two weird things:
1) Why we see orphaning with data in the first place. I think distcc would
be interested to read everything, unless some worker crashed in early...
Though some timeout in distcc could explain it as well but I don't know
too well how distcc does everything...
2) Why the receiving end of the connection is still in ESTABLISHED
without an owner... If it had some unread data, should be in CLOSE or in
FIN_WAIT1 otherwise. Ie., tcp_close() would change the state of the flow.
These both basically happen at the receiving end, though if there was
unread data the RST would also reflected state change to the sending side
and since there's window, also FIN would be sent right away and
cause sender to leave ESTABLISHED rather than that FIN would get stuck
into the tail of the TCP queue.
How to collect the information, I'm not too sure, tcp_close might well
work as a plain printk because I think it shouldn't be that noisy. But
that would likely just show that it wasn't called for a stuck receiver
at all, so it would probably end up being a dead-end anyway.
--
i.
--
