From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754007AbYEaGEA (ORCPT ); Sat, 31 May 2008 02:04:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751100AbYEaGDt (ORCPT ); Sat, 31 May 2008 02:03:49 -0400 Received: from relay.2ka.mipt.ru ([194.85.82.65]:60415 "EHLO 2ka.mipt.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751098AbYEaGDs (ORCPT ); Sat, 31 May 2008 02:03:48 -0400 Date: Sat, 31 May 2008 10:03:15 +0400 From: Evgeniy Polyakov To: Ilpo =?utf-8?B?SsOkcnZpbmVu?= Cc: Ray Lee , Ingo Molnar , LKML , Netdev , "David S. Miller" , "Rafael J. Wysocki" , Andrew Morton Subject: Re: [bug] stuck localhost TCP connections, v2.6.26-rc3+ Message-ID: <20080531060315.GA2692@2ka.mipt.ru> References: <48402BD7.2080705@madrabbit.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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