From patchwork Thu Nov 26 21:54:53 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Ilpo_J=C3=A4rvinen?= X-Patchwork-Id: 39591 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 31A4A1007D4 for ; Fri, 27 Nov 2009 08:55:01 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753034AbZKZVyt (ORCPT ); Thu, 26 Nov 2009 16:54:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753030AbZKZVyt (ORCPT ); Thu, 26 Nov 2009 16:54:49 -0500 Received: from courier.cs.helsinki.fi ([128.214.9.1]:48859 "EHLO mail.cs.helsinki.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753016AbZKZVys (ORCPT ); Thu, 26 Nov 2009 16:54:48 -0500 Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.11.93]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 26 Nov 2009 23:54:53 +0200 id 0006C4BF.4B0EF92D.0000147D Date: Thu, 26 Nov 2009 23:54:53 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: David Miller cc: eric.dumazet@gmail.com, Andrew Morton , Stephen Hemminger , Netdev , kolo@albatani.cz, bugzilla-daemon@bugzilla.kernel.org Subject: Re: [Bug 14470] New: freez in TCP stack In-Reply-To: <20091029.010009.175904855.davem@davemloft.net> Message-ID: References: <20091028151313.ba4a4d23.akpm@linux-foundation.org> <4AE9298C.1000204@gmail.com> <4AE92F4D.6070101@gmail.com> <20091029.010009.175904855.davem@davemloft.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 29 Oct 2009, David Miller wrote: > From: Eric Dumazet > Date: Thu, 29 Oct 2009 06:59:41 +0100 > > > [PATCH] tcp: clear retrans hints in tcp_send_synack() > > > > There is a small possibility the skb we unlink from write queue > > is still referenced by retrans hints. > > > > Signed-off-by: Eric Dumazet > > So, this would only be true if we were dealing with a data > packet here. We're not, this is a SYN+ACK which happens to > be cloned in the write queue. > > The hint SKBs pointers can only point to real data packets. > > And we're only dealing with data packets once we enter established > state, and when we enter established by definition we have unlinked > and freed up any SYN and SYN+ACK SKBs in the write queue. How about this then... Does the original reporter have NFS in use? [PATCH] tcp: clear hints to avoid a stale one (nfs only affected?) Eric Dumazet mentioned in a context of another problem: "Well, it seems NFS reuses its socket, so maybe we miss some cleaning as spotted in this old patch" I've not check under which conditions that actually happens but if true, we need to make sure we don't accidently leave stale hints behind when the write queue had to be purged (whether reusing with NFS can actually happen if purging took place is something I'm not sure of). ...At least it compiles. Signed-off-by: Ilpo Järvinen --- include/net/tcp.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/net/tcp.h b/include/net/tcp.h index 03a49c7..6b13faa 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -1228,6 +1228,7 @@ static inline void tcp_write_queue_purge(struct sock *sk) while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL) sk_wmem_free_skb(sk, skb); sk_mem_reclaim(sk); + tcp_clear_all_retrans_hints(tcp_sk(sk)); } static inline struct sk_buff *tcp_write_queue_head(struct sock *sk)