From patchwork Thu Jan 15 00:32:46 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Herbert Xu X-Patchwork-Id: 18563 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 6AEBEDE1C2 for ; Thu, 15 Jan 2009 11:32:58 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760880AbZAOAcw (ORCPT ); Wed, 14 Jan 2009 19:32:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760836AbZAOAcw (ORCPT ); Wed, 14 Jan 2009 19:32:52 -0500 Received: from rhun.apana.org.au ([64.62.148.172]:46865 "EHLO arnor.apana.org.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759153AbZAOAcv (ORCPT ); Wed, 14 Jan 2009 19:32:51 -0500 Received: from gondolin.me.apana.org.au ([192.168.0.6]) by arnor.apana.org.au with esmtp (Exim 4.63 #1 (Debian)) id 1LNGAD-0006k8-Cf; Thu, 15 Jan 2009 11:32:49 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.69) (envelope-from ) id 1LNGAA-0006ya-VY; Thu, 15 Jan 2009 11:32:47 +1100 Date: Thu, 15 Jan 2009 11:32:46 +1100 From: Herbert Xu To: Jeff Kirsher Cc: davem@davemloft.net, netdev@vger.kernel.org, Emil Tantilov Subject: Re: [2/2] igb: Replace LRO with GRO Message-ID: <20090115003246.GA26461@gondor.apana.org.au> References: <9929d2390901140349v4483bd23wac254673de591bec@mail.gmail.com> <20090114123653.GA19257@gondor.apana.org.au> <9929d2390901141603s65cd27a3y732c5058de9145c8@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9929d2390901141603s65cd27a3y732c5058de9145c8@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Jan 14, 2009 at 04:03:10PM -0800, Jeff Kirsher wrote: > > We are seeing a kernel panic during our testing using jumbo frames, > below is the trace. Thanks! This was the one case that I didn't test with e1000e, namely an skb with page frags which comes from the driver (as opposed to being constructed by the stack through gro_receive_frags). gro: Fix page ref count for skbs freed normally When an skb with page frags is merged into an existing one, we cannibalise its reference count. This is OK when the skb is reused because we set nr_frags to zero in that case. However, for the case where the skb is freed through kfree_skb, we didn't clear nr_frags which causes the page to be freed prematurely. This is fixed by moving the skb resetting into skb_gro_receive. Reported-by: Jeff Kirsher Signed-off-by: Herbert Xu Cheers, diff --git a/net/core/dev.c b/net/core/dev.c index 972a47d..4f69a2d 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2481,12 +2481,6 @@ EXPORT_SYMBOL(napi_gro_receive); void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb) { - skb_shinfo(skb)->nr_frags = 0; - - skb->len -= skb->data_len; - skb->truesize -= skb->data_len; - skb->data_len = 0; - __skb_pull(skb, skb_headlen(skb)); skb_reserve(skb, NET_IP_ALIGN - skb_headroom(skb)); diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 5110b35..65eac77 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -2602,6 +2602,12 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb) skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t)); skb_shinfo(p)->nr_frags += skb_shinfo(skb)->nr_frags; + skb_shinfo(skb)->nr_frags = 0; + + skb->truesize -= skb->data_len; + skb->len -= skb->data_len; + skb->data_len = 0; + NAPI_GRO_CB(skb)->free = 1; goto done; }