[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20251025160905.3857885-425-sashal@kernel.org>
Date: Sat, 25 Oct 2025 12:00:56 -0400
From: Sasha Levin <sashal@...nel.org>
To: patches@...ts.linux.dev,
stable@...r.kernel.org
Cc: Fan Gong <gongfan1@...wei.com>,
Zhu Yikai <zhuyikai1@...artners.com>,
Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
Paolo Abeni <pabeni@...hat.com>,
Sasha Levin <sashal@...nel.org>,
netdev@...r.kernel.org
Subject: [PATCH AUTOSEL 6.17] hinic3: Fix missing napi->dev in netif_queue_set_napi
From: Fan Gong <gongfan1@...wei.com>
[ Upstream commit 4404f6af810829588a51968959c6b85574109c13 ]
As netif_queue_set_napi checks napi->dev, if it doesn't have it and
it will warn_on and return. So we should use netif_napi_add before
netif_queue_set_napi because netif_napi_add has "napi->dev = dev".
Co-developed-by: Zhu Yikai <zhuyikai1@...artners.com>
Signed-off-by: Zhu Yikai <zhuyikai1@...artners.com>
Signed-off-by: Fan Gong <gongfan1@...wei.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Link: https://patch.msgid.link/a17a5a087350eaf2e081dcd879779ca2c69b0908.1757653621.git.zhuyikai1@h-partners.com
Signed-off-by: Paolo Abeni <pabeni@...hat.com>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---
LLM Generated explanations, may be completely bogus:
YES – The patch fixes a real bug that every hinic3 user will hit, and it
does so with a minimal, obviously-correct change.
- `drivers/net/ethernet/huawei/hinic3/hinic3_irq.c:45-50` now calls
`netif_napi_add()` before `netif_queue_set_napi()`. Before this change
the calls were reversed, so the queue registration happened while
`napi->dev` was still NULL.
- `net/core/dev.c:7159-7166` shows `netif_queue_set_napi()` emits
`WARN_ON_ONCE(napi && !napi->dev)` and returns early. That warning
fires on every queue bring-up in current kernels because
`qp_add_napi()` tried to attach the queue first, and the association
silently failed.
- Because the helper bails out, the driver leaves
`rxq->napi`/`txq->napi` unset, meaning busy-polling, queue
diagnostics, and any code using `netif_queue_get_napi()` lose the
mapping, on top of the user-visible WARN splat. `netif_napi_add()` is
precisely where `napi->dev` becomes valid (`net/core/dev.c:7440`), so
executing it first is required.
- The fix is a one-line reordering with no side effects or dependencies,
so the regression risk is negligible while the benefit is immediate.
Given the always-on warning and missing queue-to-NAPI wiring, this is a
good and safe candidate for stable backporting.
drivers/net/ethernet/huawei/hinic3/hinic3_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c b/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c
index 8b92eed25edfe..aba1a1d579c50 100644
--- a/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c
+++ b/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c
@@ -42,11 +42,11 @@ void qp_add_napi(struct hinic3_irq_cfg *irq_cfg)
{
struct hinic3_nic_dev *nic_dev = netdev_priv(irq_cfg->netdev);
+ netif_napi_add(nic_dev->netdev, &irq_cfg->napi, hinic3_poll);
netif_queue_set_napi(irq_cfg->netdev, irq_cfg->irq_id,
NETDEV_QUEUE_TYPE_RX, &irq_cfg->napi);
netif_queue_set_napi(irq_cfg->netdev, irq_cfg->irq_id,
NETDEV_QUEUE_TYPE_TX, &irq_cfg->napi);
- netif_napi_add(nic_dev->netdev, &irq_cfg->napi, hinic3_poll);
napi_enable(&irq_cfg->napi);
}
--
2.51.0
Powered by blists - more mailing lists