From patchwork Fri Apr 21 15:34:35 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 753498 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.180.67]) by ozlabs.org (Postfix) with ESMTP id 3w8jgN1hkGz9s65 for ; Sat, 22 Apr 2017 03:40:16 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="ra74GbZw"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423004AbdDURjL (ORCPT ); Fri, 21 Apr 2017 13:39:11 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:36374 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1038291AbdDURi5 (ORCPT ); Fri, 21 Apr 2017 13:38:57 -0400 Received: by mail-io0-f193.google.com with SMTP id x86so32721807ioe.3; Fri, 21 Apr 2017 10:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=9sBQa8Vw9j6onzf/RcgVBK8fYtIMAWa6CLB6ob5Quxk=; b=ra74GbZwfgUlGwn9Gt5QvCboTP1YrsSOj6g0ZxpuF8SxUpwtRlKkV8CgbReimcAXz0 +lOZFCpVD4aSQrS8YsFDUu+0yoVok1ZktxA4L4g0tNkaeC+OMskkUwa8DgaNPkMkyorS P4DabWtsCxSMhWRh5myJC5N1ph2dZvwHAEI3bi/y4sjExM0alB2cJObk49Uuvht9CWdT caMTgNEiue8ZE/MFI4biDiRoYUNsE1/RH8wPBKyIZjbrEEeQ3zql2T5kfF5XgkL9ZGHG 3EigLhRmS07ryjsXV2e9d4IX6Pi+AyLMFgIKQ8R/WJzfo1eJV6aADYogcjHll38r5UCH OZ9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=9sBQa8Vw9j6onzf/RcgVBK8fYtIMAWa6CLB6ob5Quxk=; b=c7r1i2kOO3t3tl1zVjpeBEsBt2TSXXC0b57HRTUbZh3wleiddv6z164PydKEhJeM4r mc36D6LsE1bH7VYWl9qXxL+0s3VgP7fxFkO8o3Rrz1e/hCa+sOBnBAWNdMx6aziLIB3l 757OkuJMs/qBroFPSCuWGuxCAdnEwk5+x5x94j7RyLOrCoSp58HqjYUZGv3OC/0LOpo6 b6LxABlFtJVmt/XANBb/ZB9C8aw8M8vxuP6tNEfymq3xwQvtjbiedlMFIyQxJKI42U1P 3CKNkJDaBfFDhqOzBy+ZlCLvotiYRzJ79OwKInzG63BxvYSxn5e1UKSt5X1iEb2phN8E y2wA== X-Gm-Message-State: AN3rC/41krQbgEWHX/9igrkePpwqRNblOKYptZ8tTU9tjP0A+Th76wxG skYKK0xBiZ6ulItP X-Received: by 10.98.160.144 with SMTP id p16mr13244993pfl.236.1492788876991; Fri, 21 Apr 2017 08:34:36 -0700 (PDT) Received: from ?IPv6:2620:0:1000:1704:5196:1eb1:8706:4cae? ([2620:0:1000:1704:5196:1eb1:8706:4cae]) by smtp.googlemail.com with ESMTPSA id h14sm16885333pgn.64.2017.04.21.08.34.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 08:34:36 -0700 (PDT) Message-ID: <1492788875.6453.18.camel@edumazet-glaptop3.roam.corp.google.com> Subject: Re: [regression v4.11] 617f01211baf ("8139too: use napi_complete_done()") From: Eric Dumazet To: Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= Cc: Eric Dumazet , "David S. Miller" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Fri, 21 Apr 2017 08:34:35 -0700 In-Reply-To: <1492787366.6453.9.camel@edumazet-glaptop3.roam.corp.google.com> References: <20170407181754.GL30290@intel.com> <20170421114001.GJ30290@intel.com> <1492781375.6453.1.camel@edumazet-glaptop3.roam.corp.google.com> <1492787366.6453.9.camel@edumazet-glaptop3.roam.corp.google.com> X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, 2017-04-21 at 08:09 -0700, Eric Dumazet wrote: > On Fri, 2017-04-21 at 06:29 -0700, Eric Dumazet wrote: > > > Thanks for this report. > > > > Interesting to see how many drivers got the netpoll stuff wrong :/ > > > > Can you try : > > > > diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c > > index 81f18a8335276495a59fa93219c4607c2b8a47aa..74e4c72c331d5a6cc5b653970ef4133c8ddf9999 100644 > > --- a/drivers/net/ethernet/realtek/r8169.c > > +++ b/drivers/net/ethernet/realtek/r8169.c > > @@ -7668,7 +7668,7 @@ static void rtl8169_netpoll(struct net_device *dev) > > { > > struct rtl8169_private *tp = netdev_priv(dev); > > > > - rtl8169_interrupt(tp->pci_dev->irq, dev); > > + napi_schedule(&tp->napi); > > The problem is more likely that netconsole handling can call rtl_tx() > from hard irq context, while standard NAPI poll calls it from BH > > Meaning that the following sequence triggers a lockdep warning. > > u64_stats_update_begin(&tp->tx_stats.syncp); > tp->tx_stats.packets++; > tp->tx_stats.bytes += tx_skb->skb->len; > u64_stats_update_end(&tp->tx_stats.syncp); > > Lockdep does not know that poll_napi() ( called from netpoll_poll_dev()) > uses an cmpxchg() to make sure that there is no race. > > I am not sure how we can teach lockdep to not splat in this case. Well, could you try the following patch ? Thanks ! diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index 0a8f2817ea60f2172eb28177473a4879f85bd18a..f64f812b86029b772bb245e51cdc2263adc4e6ea 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -7313,10 +7313,10 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp) rtl8169_unmap_tx_skb(&tp->pci_dev->dev, tx_skb, tp->TxDescArray + entry); if (status & LastFrag) { - u64_stats_update_begin(&tp->tx_stats.syncp); + u64_stats_update_begin_raw(&tp->tx_stats.syncp); tp->tx_stats.packets++; tp->tx_stats.bytes += tx_skb->skb->len; - u64_stats_update_end(&tp->tx_stats.syncp); + u64_stats_update_end_raw(&tp->tx_stats.syncp); dev_kfree_skb_any(tx_skb->skb); tx_skb->skb = NULL; }