From patchwork Thu Mar 26 03:36:58 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Herbert Xu X-Patchwork-Id: 25125 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 9AF37DDD0B for ; Thu, 26 Mar 2009 14:37:51 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755953AbZCZDhK (ORCPT ); Wed, 25 Mar 2009 23:37:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755578AbZCZDhJ (ORCPT ); Wed, 25 Mar 2009 23:37:09 -0400 Received: from rhun.apana.org.au ([64.62.148.172]:55382 "EHLO arnor.apana.org.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755562AbZCZDhI (ORCPT ); Wed, 25 Mar 2009 23:37:08 -0400 Received: from gondolin.me.apana.org.au ([192.168.0.6]) by arnor.apana.org.au with esmtp (Exim 4.63 #1 (Debian)) id 1LmgOs-0001R4-DG; Thu, 26 Mar 2009 14:37:02 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.69) (envelope-from ) id 1LmgOp-0003nZ-75; Thu, 26 Mar 2009 11:36:59 +0800 Date: Thu, 26 Mar 2009 11:36:58 +0800 From: Herbert Xu To: adam_richter2004@yahoo.com Cc: davem@davemloft.net, netdev@vger.kernel.org, berkley@cs.wustl.edu Subject: Re: 2.6.29 forcedeth hang W/O NAPI enabled Message-ID: <20090326033658.GA14592@gondor.apana.org.au> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <810119.61814.qm@web57701.mail.re3.yahoo.com> Organization: Core X-Newsgroups: apana.lists.os.linux.netdev 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 Adam Richter wrote: > > The patch you forwarded to me seems to work. Thank you for bringing it > to my attention. Hi Adam: Any chance you can test this patch instead of the previous one? net: Fix netpoll lockup in legacy receive path When I fixed the GRO crash in the legacy receive path I used napi_complete to replace __napi_complete. Unfortunately they're not the same when NETPOLL is enabled, which may result in us not calling __napi_complete at all. What's more, we really do need to keep the __napi_complete call within the IRQ-off section since in theory an IRQ can occur in between and fill up the backlog to the maximum, causing us to lock up. This patch fixes this by essentially open-coding __napi_complete. Note we no longer need the memory barrier because this function is per-cpu. Signed-off-by: Herbert Xu Thanks, diff --git a/net/core/dev.c b/net/core/dev.c index e3fe5c7..2a7f6b3 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2588,9 +2588,10 @@ static int process_backlog(struct napi_struct *napi, int quota) local_irq_disable(); skb = __skb_dequeue(&queue->input_pkt_queue); if (!skb) { + list_del(&napi->poll_list); + clear_bit(NAPI_STATE_SCHED, &napi->state); local_irq_enable(); - napi_complete(napi); - goto out; + break; } local_irq_enable(); @@ -2599,7 +2600,6 @@ static int process_backlog(struct napi_struct *napi, int quota) napi_gro_flush(napi); -out: return work; }