[net-next,v2,4/4] netdev: use napi_schedule bool instead of napi_schedule_prep/__napi_schedule
Message ID | 20231003145150.2498-4-ansuelsmth@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp2277699vqb; Tue, 3 Oct 2023 11:37:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEjePXZqNFr8McJ47vizzBq7BO1tPNJhA27P+wipB98qBY5rKu9NTWf2oknP6CwzGm+A2+p X-Received: by 2002:a05:6a00:cd1:b0:690:c1e5:9359 with SMTP id b17-20020a056a000cd100b00690c1e59359mr479295pfv.17.1696358225065; Tue, 03 Oct 2023 11:37:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696358225; cv=none; d=google.com; s=arc-20160816; b=w/B+YvCUeMugtSwtyCRCuy76SPbdLBLDUT8qousdf+pj7Sg186YjXgOCNejhCoQMa2 PDmY7I7EBlu/oTwftNVZ82x8Ti9DlpTakb3wfZJm2VCZ/U3joGxintzUDsuMMfcFWf+C imVRo1BnTMJvyoXnePgPCzpZACO9FW16kvr+a/YfNxqsbq0+tDEz+9yyfV7jfE8+ppeM u1WXI/g9UvHAp7Tyt34vY9fZQIrq80Knz9ZKNneU9/LoqYJSFeqkKqb/ZhOv0v8kvpdI LtrWGpdU6KdPCvYPAwqvWPJJ3gEE2k0zB2iSZgTPxzZ47+6qFmyXtWXcFJtG/euu8Ltn yDMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:to:from :dkim-signature; bh=6gyQNJ2XnyFpWZfsSOVQ7NTvT9jbamCtiO1RkGRSocs=; fh=bHCJamIrbEWtWkzmhZZuRieh9gijj2axkIRs8LsjvR8=; b=ReGx/OvL+K26zn5beswLdT9KqN5yXnMlh/8igmwbest9Ja3bwnR2ekLM2oaP8bw2RL jVSpATlBNs8scSOChTqzyg9MrFcHaeXlfou1g94TCtdemumdlvSu1252qicI3nWh1idb SmGHqrErCvkgMMw9Th6PStbc+O6KlWsj8aalN6xLRBmkM9+Krf2DlGZozEDOwUNU+mGc x7qxN/pcuR0XwZbI/Klp9amBVGzmo3Z9IbeSvTI4g4bcUsQXjge8L9w5ibRsITqC+Mwr Ccg4o8+xaphx9QhkAkLriKyJbfa62RwFKUyBj6/l0FaGUvPGa10LNb5phwg0Szdv9iSk G4sA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=H1s3zgci; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id j7-20020a056a00234700b0069026fd5a48si2140317pfj.34.2023.10.03.11.37.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 11:37:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=H1s3zgci; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 6FC2C81A6E6D; Tue, 3 Oct 2023 11:37:04 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240848AbjJCSg7 (ORCPT <rfc822;chrisfriedt@gmail.com> + 17 others); Tue, 3 Oct 2023 14:36:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240810AbjJCSgx (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 3 Oct 2023 14:36:53 -0400 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80021AC; Tue, 3 Oct 2023 11:36:47 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-40651a72807so12648845e9.1; Tue, 03 Oct 2023 11:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696358206; x=1696963006; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=6gyQNJ2XnyFpWZfsSOVQ7NTvT9jbamCtiO1RkGRSocs=; b=H1s3zgciXLCZusBZWw3ADVu1lzKUhWWNECQpIat/xTggEO+yE+mK4UOFYPAfR2ScK6 oSvgGsDKEc5AC5gQ2kNhAU2vdREUdFfDfQXxMQSC9QuI2f75ObGWvhii4IuLhYfR1Y1g aAMUIv11aBKdGJ6RlZmi30JqnUZ7CGLBPbKiHslF3cZYEJYyuliBhKUVjRoj7NizrJf9 sBXR3e2bnpnlAyAPWHT9xBDJiCyFpjJDZoUHNBwatfU426Fn/JQLdtxBFUEt0BlvZsz6 KzKGDqX00CB7XebouXwmR+7o+B1psqtrcM02VnSmkUzoCDfEdYGKrK0GSAg8JxuzKgEc Z+zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696358206; x=1696963006; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6gyQNJ2XnyFpWZfsSOVQ7NTvT9jbamCtiO1RkGRSocs=; b=mpuOlkrTI3hBjfNnWHRt7s3ocaOE0oOFRgjeRRKywiQi0rvG8I5pJjSbhX47S6hiy2 iw1nsj3vDCnMYKMx1Gl6V9Q0/unhmEA7kXWo9bctnkhDZDiY87ZGhBzo480eDMO/xmlA BQgf+VN+wu0d0ImBQVQVgvWLWTCjz5PWUbsFY0TsM6sAPiBN2srnZsv0tRKlun7VMzjW JElPkyRjhmskjM/5Sv3akBKhZ+uGdsaB+apzw24F+8QzirQwMPAHU3YoP4g5pQ+f07Sq YECkZnsMsidDyECKlXT1WthtU1DGSE/JEw8RksXv1L2prsmsFhdiFxI6z3yh3DpR7YMr PQAQ== X-Gm-Message-State: AOJu0YzdieaH3XKXpPmGDGQCOF0Z/Rc1Z7ZbvGzEhjoSK9SFJ7FYyXut euSPcKlUGDEctHqvOLpTtk0= X-Received: by 2002:a05:600c:22ce:b0:405:4c3a:796f with SMTP id 14-20020a05600c22ce00b004054c3a796fmr308411wmg.2.1696358205305; Tue, 03 Oct 2023 11:36:45 -0700 (PDT) Received: from localhost.localdomain (93-34-89-13.ip49.fastwebnet.it. [93.34.89.13]) by smtp.googlemail.com with ESMTPSA id k15-20020a7bc40f000000b004013797efb6sm10147400wmi.9.2023.10.03.11.36.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 11:36:45 -0700 (PDT) From: Christian Marangi <ansuelsmth@gmail.com> To: Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>, Wolfgang Grandegger <wg@grandegger.com>, Marc Kleine-Budde <mkl@pengutronix.de>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Chris Snook <chris.snook@gmail.com>, Raju Rangoju <rajur@chelsio.com>, Jeroen de Borst <jeroendb@google.com>, Praveen Kaligineedi <pkaligineedi@google.com>, Shailend Chand <shailend@google.com>, Douglas Miller <dougmill@linux.ibm.com>, Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy <christophe.leroy@csgroup.eu>, Nick Child <nnac123@linux.ibm.com>, Haren Myneni <haren@linux.ibm.com>, Rick Lindsley <ricklind@linux.ibm.com>, Dany Madden <danymadden@us.ibm.com>, Thomas Falcon <tlfalcon@linux.ibm.com>, Tariq Toukan <tariqt@nvidia.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Jose Abreu <joabreu@synopsys.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Krzysztof Halasa <khalasa@piap.pl>, Kalle Valo <kvalo@kernel.org>, Jeff Johnson <quic_jjohnson@quicinc.com>, Gregory Greenman <gregory.greenman@intel.com>, Chandrashekar Devegowda <chandrashekar.devegowda@intel.com>, Intel Corporation <linuxwwan@intel.com>, Chiranjeevi Rapolu <chiranjeevi.rapolu@linux.intel.com>, Liu Haijun <haijun.liu@mediatek.com>, M Chetan Kumar <m.chetan.kumar@linux.intel.com>, Ricardo Martinez <ricardo.martinez@linux.intel.com>, Loic Poulain <loic.poulain@linaro.org>, Sergey Ryazanov <ryazanov.s.a@gmail.com>, Johannes Berg <johannes@sipsolutions.net>, Christian Marangi <ansuelsmth@gmail.com>, Yuanjun Gong <ruc_gongyuanjun@163.com>, Simon Horman <horms@kernel.org>, Rob Herring <robh@kernel.org>, Ziwei Xiao <ziweixiao@google.com>, Rushil Gupta <rushilg@google.com>, Coco Li <lixiaoyan@google.com>, Thomas Gleixner <tglx@linutronix.de>, Junfeng Guo <junfeng.guo@intel.com>, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>, Wei Fang <wei.fang@nxp.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Yuri Karpov <YKarpov@ispras.ru>, Zhengchao Shao <shaozhengchao@huawei.com>, Andrew Lunn <andrew@lunn.ch>, Zheng Zengkai <zhengzengkai@huawei.com>, Lee Jones <lee@kernel.org>, Maximilian Luz <luzmaximilian@gmail.com>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, Dawei Li <set_pte_at@outlook.com>, Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>, Benjamin Berg <benjamin.berg@intel.com>, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, linux-can@vger.kernel.org, netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, ath10k@lists.infradead.org, linux-wireless@vger.kernel.org Subject: [net-next PATCH v2 4/4] netdev: use napi_schedule bool instead of napi_schedule_prep/__napi_schedule Date: Tue, 3 Oct 2023 16:51:50 +0200 Message-Id: <20231003145150.2498-4-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20231003145150.2498-1-ansuelsmth@gmail.com> References: <20231003145150.2498-1-ansuelsmth@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 03 Oct 2023 11:37:04 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778760522296839260 X-GMAIL-MSGID: 1778760522296839260 |
Series |
[net-next,v2,1/4] netdev: replace simple napi_schedule_prep/__napi_schedule to napi_schedule
|
|
Commit Message
Christian Marangi
Oct. 3, 2023, 2:51 p.m. UTC
Replace if condition of napi_schedule_prep/__napi_schedule and use bool
from napi_schedule directly where possible.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/net/ethernet/atheros/atlx/atl1.c | 4 +---
drivers/net/ethernet/toshiba/tc35815.c | 4 +---
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 4 +---
3 files changed, 3 insertions(+), 9 deletions(-)
Comments
On Tue, Oct 3, 2023 at 8:36 PM Christian Marangi <ansuelsmth@gmail.com> wrote: > > Replace if condition of napi_schedule_prep/__napi_schedule and use bool > from napi_schedule directly where possible. > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > --- > drivers/net/ethernet/atheros/atlx/atl1.c | 4 +--- > drivers/net/ethernet/toshiba/tc35815.c | 4 +--- > drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 4 +--- > 3 files changed, 3 insertions(+), 9 deletions(-) > > diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c > index 02aa6fd8ebc2..a9014d7932db 100644 > --- a/drivers/net/ethernet/atheros/atlx/atl1.c > +++ b/drivers/net/ethernet/atheros/atlx/atl1.c > @@ -2446,7 +2446,7 @@ static int atl1_rings_clean(struct napi_struct *napi, int budget) > > static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) > { > - if (!napi_schedule_prep(&adapter->napi)) > + if (!napi_schedule(&adapter->napi)) > /* It is possible in case even the RX/TX ints are disabled via IMR > * register the ISR bits are set anyway (but do not produce IRQ). > * To handle such situation the napi functions used to check is > @@ -2454,8 +2454,6 @@ static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) > */ > return 0; > > - __napi_schedule(&adapter->napi); > - > /* > * Disable RX/TX ints via IMR register if it is > * allowed. NAPI handler must reenable them in same > diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c > index 14cf6ecf6d0d..a8b8a0e13f9a 100644 > --- a/drivers/net/ethernet/toshiba/tc35815.c > +++ b/drivers/net/ethernet/toshiba/tc35815.c > @@ -1436,9 +1436,7 @@ static irqreturn_t tc35815_interrupt(int irq, void *dev_id) > if (!(dmactl & DMA_IntMask)) { > /* disable interrupts */ > tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); > - if (napi_schedule_prep(&lp->napi)) > - __napi_schedule(&lp->napi); > - else { > + if (!napi_schedule(&lp->napi)) { > printk(KERN_ERR "%s: interrupt taken in poll\n", > dev->name); > BUG(); Hmmm... could you also remove this BUG() ? I think this code path can be taken if some applications are using busy polling. Or simply rewrite this with the traditional if (napi_schedule_prep(&lp->napi)) { /* disable interrupts */ tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); __napi_schedule(&lp->napi); } > diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > index 23b5a0adcbd6..146bc7bd14fb 100644 > --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > @@ -1660,9 +1660,7 @@ irqreturn_t iwl_pcie_irq_rx_msix_handler(int irq, void *dev_id) > IWL_DEBUG_ISR(trans, "[%d] Got interrupt\n", entry->entry); > > local_bh_disable(); > - if (napi_schedule_prep(&rxq->napi)) > - __napi_schedule(&rxq->napi); > - else > + if (!napi_schedule(&rxq->napi)) > iwl_pcie_clear_irq(trans, entry->entry); Same remark here about twisted logic. > local_bh_enable(); > > -- > 2.40.1 >
On Thu, Oct 05, 2023 at 06:16:26PM +0200, Eric Dumazet wrote: > On Tue, Oct 3, 2023 at 8:36 PM Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > Replace if condition of napi_schedule_prep/__napi_schedule and use bool > > from napi_schedule directly where possible. > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > --- > > drivers/net/ethernet/atheros/atlx/atl1.c | 4 +--- > > drivers/net/ethernet/toshiba/tc35815.c | 4 +--- > > drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 4 +--- > > 3 files changed, 3 insertions(+), 9 deletions(-) > > > > diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c > > index 02aa6fd8ebc2..a9014d7932db 100644 > > --- a/drivers/net/ethernet/atheros/atlx/atl1.c > > +++ b/drivers/net/ethernet/atheros/atlx/atl1.c > > @@ -2446,7 +2446,7 @@ static int atl1_rings_clean(struct napi_struct *napi, int budget) > > > > static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) > > { > > - if (!napi_schedule_prep(&adapter->napi)) > > + if (!napi_schedule(&adapter->napi)) > > /* It is possible in case even the RX/TX ints are disabled via IMR > > * register the ISR bits are set anyway (but do not produce IRQ). > > * To handle such situation the napi functions used to check is > > @@ -2454,8 +2454,6 @@ static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) > > */ > > return 0; > > > > - __napi_schedule(&adapter->napi); > > - > > /* > > * Disable RX/TX ints via IMR register if it is > > * allowed. NAPI handler must reenable them in same > > diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c > > index 14cf6ecf6d0d..a8b8a0e13f9a 100644 > > --- a/drivers/net/ethernet/toshiba/tc35815.c > > +++ b/drivers/net/ethernet/toshiba/tc35815.c > > @@ -1436,9 +1436,7 @@ static irqreturn_t tc35815_interrupt(int irq, void *dev_id) > > if (!(dmactl & DMA_IntMask)) { > > /* disable interrupts */ > > tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); > > - if (napi_schedule_prep(&lp->napi)) > > - __napi_schedule(&lp->napi); > > - else { > > + if (!napi_schedule(&lp->napi)) { > > printk(KERN_ERR "%s: interrupt taken in poll\n", > > dev->name); > > BUG(); > > Hmmm... could you also remove this BUG() ? I think this code path can be taken > if some applications are using busy polling. > > Or simply rewrite this with the traditional > > if (napi_schedule_prep(&lp->napi)) { > /* disable interrupts */ > tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); > __napi_schedule(&lp->napi); > } > > Mhhh is it safe to do so? I mean it seems very wrong to print a warning and BUG() instead of disabling the interrupt only if napi can be scheduled... Maybe is very old code? The more I see this the more I see problem... (randomly disabling the interrupt and then make the kernel die) > > > diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > > index 23b5a0adcbd6..146bc7bd14fb 100644 > > --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > > +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c > > @@ -1660,9 +1660,7 @@ irqreturn_t iwl_pcie_irq_rx_msix_handler(int irq, void *dev_id) > > IWL_DEBUG_ISR(trans, "[%d] Got interrupt\n", entry->entry); > > > > local_bh_disable(); > > - if (napi_schedule_prep(&rxq->napi)) > > - __napi_schedule(&rxq->napi); > > - else > > + if (!napi_schedule(&rxq->napi)) > > iwl_pcie_clear_irq(trans, entry->entry); > > Same remark here about twisted logic. > Ehhh here we need to be careful... We can do the usual prep/__schedule with the DMA disable in between... From the comments of iwl_pcie_clear_irq. /* * Before sending the interrupt the HW disables it to prevent * a nested interrupt. This is done by writing 1 to the corresponding * bit in the mask register. After handling the interrupt, it should be * re-enabled by clearing this bit. This register is defined as * write 1 clear (W1C) register, meaning that it's being clear * by writing 1 to the bit. */ So the device disable the interrupt after being fired and the bit needs to set again for the interrupt to be reenabled. So the function correctly reenable the irq if a napi can't be scheduled... Think there isn't another way to handle this. > > local_bh_enable(); > > > > -- > > 2.40.1 > >
On Fri, Oct 6, 2023 at 8:49 PM Christian Marangi <ansuelsmth@gmail.com> wrote: > > On Thu, Oct 05, 2023 at 06:16:26PM +0200, Eric Dumazet wrote: > > On Tue, Oct 3, 2023 at 8:36 PM Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > > > Replace if condition of napi_schedule_prep/__napi_schedule and use bool > > > from napi_schedule directly where possible. > > > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > > --- > > > drivers/net/ethernet/atheros/atlx/atl1.c | 4 +--- > > > drivers/net/ethernet/toshiba/tc35815.c | 4 +--- > > > drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 4 +--- > > > 3 files changed, 3 insertions(+), 9 deletions(-) > > > > > > diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c > > > index 02aa6fd8ebc2..a9014d7932db 100644 > > > --- a/drivers/net/ethernet/atheros/atlx/atl1.c > > > +++ b/drivers/net/ethernet/atheros/atlx/atl1.c > > > @@ -2446,7 +2446,7 @@ static int atl1_rings_clean(struct napi_struct *napi, int budget) > > > > > > static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) > > > { > > > - if (!napi_schedule_prep(&adapter->napi)) > > > + if (!napi_schedule(&adapter->napi)) > > > /* It is possible in case even the RX/TX ints are disabled via IMR > > > * register the ISR bits are set anyway (but do not produce IRQ). > > > * To handle such situation the napi functions used to check is > > > @@ -2454,8 +2454,6 @@ static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) > > > */ > > > return 0; > > > > > > - __napi_schedule(&adapter->napi); > > > - > > > /* > > > * Disable RX/TX ints via IMR register if it is > > > * allowed. NAPI handler must reenable them in same > > > diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c > > > index 14cf6ecf6d0d..a8b8a0e13f9a 100644 > > > --- a/drivers/net/ethernet/toshiba/tc35815.c > > > +++ b/drivers/net/ethernet/toshiba/tc35815.c > > > @@ -1436,9 +1436,7 @@ static irqreturn_t tc35815_interrupt(int irq, void *dev_id) > > > if (!(dmactl & DMA_IntMask)) { > > > /* disable interrupts */ > > > tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); > > > - if (napi_schedule_prep(&lp->napi)) > > > - __napi_schedule(&lp->napi); > > > - else { > > > + if (!napi_schedule(&lp->napi)) { > > > printk(KERN_ERR "%s: interrupt taken in poll\n", > > > dev->name); > > > BUG(); > > > > Hmmm... could you also remove this BUG() ? I think this code path can be taken > > if some applications are using busy polling. > > > > Or simply rewrite this with the traditional > > > > if (napi_schedule_prep(&lp->napi)) { > > /* disable interrupts */ > > tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); > > __napi_schedule(&lp->napi); > > } > > > > > > Mhhh is it safe to do so? I mean it seems very wrong to print a warning > and BUG() instead of disabling the interrupt only if napi can be > scheduled... Maybe is very old code? The more I see this the more I see > problem... (randomly disabling the interrupt and then make the kernel > die) I am pretty sure this BUG() can be hit these days with busy polling or setting gro_flush_timeout. I wish we could remove these bugs before someone copy-paste them. Again, this is orthogonal, I might simply stop doing reviews if this is not useful.
On Sun, Oct 08, 2023 at 09:08:41AM +0200, Eric Dumazet wrote: > On Fri, Oct 6, 2023 at 8:49 PM Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > On Thu, Oct 05, 2023 at 06:16:26PM +0200, Eric Dumazet wrote: > > > On Tue, Oct 3, 2023 at 8:36 PM Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > > > > > Replace if condition of napi_schedule_prep/__napi_schedule and use bool > > > > from napi_schedule directly where possible. > > > > > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > > > --- > > > > drivers/net/ethernet/atheros/atlx/atl1.c | 4 +--- > > > > drivers/net/ethernet/toshiba/tc35815.c | 4 +--- > > > > drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 4 +--- > > > > 3 files changed, 3 insertions(+), 9 deletions(-) > > > > > > > > diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c > > > > index 02aa6fd8ebc2..a9014d7932db 100644 > > > > --- a/drivers/net/ethernet/atheros/atlx/atl1.c > > > > +++ b/drivers/net/ethernet/atheros/atlx/atl1.c > > > > @@ -2446,7 +2446,7 @@ static int atl1_rings_clean(struct napi_struct *napi, int budget) > > > > > > > > static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) > > > > { > > > > - if (!napi_schedule_prep(&adapter->napi)) > > > > + if (!napi_schedule(&adapter->napi)) > > > > /* It is possible in case even the RX/TX ints are disabled via IMR > > > > * register the ISR bits are set anyway (but do not produce IRQ). > > > > * To handle such situation the napi functions used to check is > > > > @@ -2454,8 +2454,6 @@ static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) > > > > */ > > > > return 0; > > > > > > > > - __napi_schedule(&adapter->napi); > > > > - > > > > /* > > > > * Disable RX/TX ints via IMR register if it is > > > > * allowed. NAPI handler must reenable them in same > > > > diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c > > > > index 14cf6ecf6d0d..a8b8a0e13f9a 100644 > > > > --- a/drivers/net/ethernet/toshiba/tc35815.c > > > > +++ b/drivers/net/ethernet/toshiba/tc35815.c > > > > @@ -1436,9 +1436,7 @@ static irqreturn_t tc35815_interrupt(int irq, void *dev_id) > > > > if (!(dmactl & DMA_IntMask)) { > > > > /* disable interrupts */ > > > > tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); > > > > - if (napi_schedule_prep(&lp->napi)) > > > > - __napi_schedule(&lp->napi); > > > > - else { > > > > + if (!napi_schedule(&lp->napi)) { > > > > printk(KERN_ERR "%s: interrupt taken in poll\n", > > > > dev->name); > > > > BUG(); > > > > > > Hmmm... could you also remove this BUG() ? I think this code path can be taken > > > if some applications are using busy polling. > > > > > > Or simply rewrite this with the traditional > > > > > > if (napi_schedule_prep(&lp->napi)) { > > > /* disable interrupts */ > > > tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); > > > __napi_schedule(&lp->napi); > > > } > > > > > > > > > > Mhhh is it safe to do so? I mean it seems very wrong to print a warning > > and BUG() instead of disabling the interrupt only if napi can be > > scheduled... Maybe is very old code? The more I see this the more I see > > problem... (randomly disabling the interrupt and then make the kernel > > die) > > I am pretty sure this BUG() can be hit these days with busy polling or > setting gro_flush_timeout. > > I wish we could remove these bugs before someone copy-paste them. > > Again, this is orthogonal, I might simply stop doing reviews if this > is not useful. They are very useful and thanks a lot for them! I'm asking these as to understand how to proceed. I have in queue 2 other series that depends on this and I'm just asking info on how to speedup the progress on this! Soo think I have to send v3 with the suggested change and BUG() dropped? Happy to do everything to fix and improve this series!
On Sun, Oct 8, 2023 at 8:27 PM Christian Marangi <ansuelsmth@gmail.com> wrote: > > On Sun, Oct 08, 2023 at 09:08:41AM +0200, Eric Dumazet wrote: > > On Fri, Oct 6, 2023 at 8:49 PM Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > > > On Thu, Oct 05, 2023 at 06:16:26PM +0200, Eric Dumazet wrote: > > > > On Tue, Oct 3, 2023 at 8:36 PM Christian Marangi <ansuelsmth@gmail.com> wrote: > > > > > > > > > > Replace if condition of napi_schedule_prep/__napi_schedule and use bool > > > > > from napi_schedule directly where possible. > > > > > > > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > > > > --- > > > > > drivers/net/ethernet/atheros/atlx/atl1.c | 4 +--- > > > > > drivers/net/ethernet/toshiba/tc35815.c | 4 +--- > > > > > drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 4 +--- > > > > > 3 files changed, 3 insertions(+), 9 deletions(-) > > > > > > > > > > diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c > > > > > index 02aa6fd8ebc2..a9014d7932db 100644 > > > > > --- a/drivers/net/ethernet/atheros/atlx/atl1.c > > > > > +++ b/drivers/net/ethernet/atheros/atlx/atl1.c > > > > > @@ -2446,7 +2446,7 @@ static int atl1_rings_clean(struct napi_struct *napi, int budget) > > > > > > > > > > static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) > > > > > { > > > > > - if (!napi_schedule_prep(&adapter->napi)) > > > > > + if (!napi_schedule(&adapter->napi)) > > > > > /* It is possible in case even the RX/TX ints are disabled via IMR > > > > > * register the ISR bits are set anyway (but do not produce IRQ). > > > > > * To handle such situation the napi functions used to check is > > > > > @@ -2454,8 +2454,6 @@ static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) > > > > > */ > > > > > return 0; > > > > > > > > > > - __napi_schedule(&adapter->napi); > > > > > - > > > > > /* > > > > > * Disable RX/TX ints via IMR register if it is > > > > > * allowed. NAPI handler must reenable them in same > > > > > diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c > > > > > index 14cf6ecf6d0d..a8b8a0e13f9a 100644 > > > > > --- a/drivers/net/ethernet/toshiba/tc35815.c > > > > > +++ b/drivers/net/ethernet/toshiba/tc35815.c > > > > > @@ -1436,9 +1436,7 @@ static irqreturn_t tc35815_interrupt(int irq, void *dev_id) > > > > > if (!(dmactl & DMA_IntMask)) { > > > > > /* disable interrupts */ > > > > > tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); > > > > > - if (napi_schedule_prep(&lp->napi)) > > > > > - __napi_schedule(&lp->napi); > > > > > - else { > > > > > + if (!napi_schedule(&lp->napi)) { > > > > > printk(KERN_ERR "%s: interrupt taken in poll\n", > > > > > dev->name); > > > > > BUG(); > > > > > > > > Hmmm... could you also remove this BUG() ? I think this code path can be taken > > > > if some applications are using busy polling. > > > > > > > > Or simply rewrite this with the traditional > > > > > > > > if (napi_schedule_prep(&lp->napi)) { > > > > /* disable interrupts */ > > > > tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); > > > > __napi_schedule(&lp->napi); > > > > } > > > > > > > > > > > > > > Mhhh is it safe to do so? I mean it seems very wrong to print a warning > > > and BUG() instead of disabling the interrupt only if napi can be > > > scheduled... Maybe is very old code? The more I see this the more I see > > > problem... (randomly disabling the interrupt and then make the kernel > > > die) > > > > I am pretty sure this BUG() can be hit these days with busy polling or > > setting gro_flush_timeout. > > > > I wish we could remove these bugs before someone copy-paste them. > > > > Again, this is orthogonal, I might simply stop doing reviews if this > > is not useful. > > They are very useful and thanks a lot for them! I'm asking these as to > understand how to proceed. I have in queue 2 other series that depends > on this and I'm just asking info on how to speedup the progress on this! > > Soo think I have to send v3 with the suggested change and BUG() dropped? > Happy to do everything to fix and improve this series! I think that your patch series is all about doing cleanups, so I suggested adding another cleanup/fix, and this can be done independently. I doubt this matters, this code has probably not been used for quite a long time...
diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c b/drivers/net/ethernet/atheros/atlx/atl1.c index 02aa6fd8ebc2..a9014d7932db 100644 --- a/drivers/net/ethernet/atheros/atlx/atl1.c +++ b/drivers/net/ethernet/atheros/atlx/atl1.c @@ -2446,7 +2446,7 @@ static int atl1_rings_clean(struct napi_struct *napi, int budget) static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) { - if (!napi_schedule_prep(&adapter->napi)) + if (!napi_schedule(&adapter->napi)) /* It is possible in case even the RX/TX ints are disabled via IMR * register the ISR bits are set anyway (but do not produce IRQ). * To handle such situation the napi functions used to check is @@ -2454,8 +2454,6 @@ static inline int atl1_sched_rings_clean(struct atl1_adapter* adapter) */ return 0; - __napi_schedule(&adapter->napi); - /* * Disable RX/TX ints via IMR register if it is * allowed. NAPI handler must reenable them in same diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c index 14cf6ecf6d0d..a8b8a0e13f9a 100644 --- a/drivers/net/ethernet/toshiba/tc35815.c +++ b/drivers/net/ethernet/toshiba/tc35815.c @@ -1436,9 +1436,7 @@ static irqreturn_t tc35815_interrupt(int irq, void *dev_id) if (!(dmactl & DMA_IntMask)) { /* disable interrupts */ tc_writel(dmactl | DMA_IntMask, &tr->DMA_Ctl); - if (napi_schedule_prep(&lp->napi)) - __napi_schedule(&lp->napi); - else { + if (!napi_schedule(&lp->napi)) { printk(KERN_ERR "%s: interrupt taken in poll\n", dev->name); BUG(); diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c index 23b5a0adcbd6..146bc7bd14fb 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c @@ -1660,9 +1660,7 @@ irqreturn_t iwl_pcie_irq_rx_msix_handler(int irq, void *dev_id) IWL_DEBUG_ISR(trans, "[%d] Got interrupt\n", entry->entry); local_bh_disable(); - if (napi_schedule_prep(&rxq->napi)) - __napi_schedule(&rxq->napi); - else + if (!napi_schedule(&rxq->napi)) iwl_pcie_clear_irq(trans, entry->entry); local_bh_enable();