From patchwork Tue Dec 8 03:03:30 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 40551 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 C0FDFB7BCF for ; Tue, 8 Dec 2009 14:04:29 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757349AbZLHDER (ORCPT ); Mon, 7 Dec 2009 22:04:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756911AbZLHDEQ (ORCPT ); Mon, 7 Dec 2009 22:04:16 -0500 Received: from gw1.cosmosbay.com ([212.99.114.194]:38542 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756541AbZLHDEQ (ORCPT ); Mon, 7 Dec 2009 22:04:16 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw1.cosmosbay.com (8.13.7/8.13.7) with ESMTP id nB833Vr1015902; Tue, 8 Dec 2009 04:03:31 +0100 Message-ID: <4B1DC202.20607@gmail.com> Date: Tue, 08 Dec 2009 04:03:30 +0100 From: Eric Dumazet User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Chris Rankin CC: netdev@vger.kernel.org, Andrew Morton , bugzilla-daemon@bugzilla.kernel.org, bugme-daemon@bugzilla.kernel.org, stable@kernel.org, Neil Horman Subject: Re: [Bugme-new] [Bug 14749] New: Kernel locks up after a few minutes of heavy surfing References: <138412.20552.qm@web52903.mail.re2.yahoo.com> In-Reply-To: <138412.20552.qm@web52903.mail.re2.yahoo.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [0.0.0.0]); Tue, 08 Dec 2009 04:03:32 +0100 (CET) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Chris Rankin a écrit : > > I saw something interesting in 2.6.31.7 about a crash due to fragmentation: > > ipv4: additional update of dev_net(dev) to struct *net in ip_fragment.c, NULL ptr OOPS > > I'll try applying that patch too, to see if it makes any difference. Along with that other UDP-related thing I noticed: > > udp: Fix udp_poll() and ioctl() > Its all two years old UDP bugs (I spot another one some hours ago), and very rare. I run heavy duty servers with lot of UDP trafic and never caught a _single_ error, I am quite suprised it could happen on your machine on demand. 1) Do you have another NIC adapter to try ? It might be a buggy driver. (Neil Horman found an error on Intel drivers some hours ago, that can corrupt skbs) 2) Could you add following debugging aid ? 3) Any chance you can do a git bisect ? Thanks --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c index 7d12c6a..5a7a456 100644 --- a/net/ipv4/af_inet.c +++ b/net/ipv4/af_inet.c @@ -147,10 +147,15 @@ void inet_sock_destruct(struct sock *sk) return; } - WARN_ON(atomic_read(&sk->sk_rmem_alloc)); - WARN_ON(atomic_read(&sk->sk_wmem_alloc)); - WARN_ON(sk->sk_wmem_queued); - WARN_ON(sk->sk_forward_alloc); + WARN((atomic_read(&sk->sk_rmem_alloc) | atomic_read(&sk->sk_wmem_alloc) | + sk->sk_wmem_queued | sk->sk_forward_alloc) != 0, + "%s socket sk_rmem_alloc=%d sk_wmem_alloc=%d " + "sk_wmem_queued=%d sk_forward_alloc=%d\n", + sk->sk_prot->name, + atomic_read(&sk->sk_rmem_alloc), + atomic_read(&sk->sk_wmem_alloc), + sk->sk_wmem_queued, + sk->sk_forward_alloc); kfree(inet->opt); dst_release(sk->sk_dst_cache);