[PATCH net-next] net: core: avoid WARN_ONCE for stale RX queue mappings

[PATCH net-next] net: core: avoid WARN_ONCE for stale RX queue mappings

[Li Xiasong]

An skb may retain its recorded RX queue index while a network device
reduces its number of active RX queues. For example, when a TUN queue
is detached, queued skbs can still carry the queue's previous index.

Both get_rps_cpu() and netif_get_rxqueue() validate the index before
accessing the RX queue array. They safely fall back to local processing
or the first RX queue, so an invalid index does not cause an
out-of-bounds access.

Using WARN_ONCE() for this recoverable condition can unnecessarily
panic systems with panic_on_warn enabled. Replace it with
netdev_warn_once() to retain the diagnostic without emitting a WARN
splat.

Signed-off-by: Li Xiasong <lixiasong1@huawei.com>
---
 net/core/dev.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index af260ff5462a..5db98b0a853f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5126,10 +5126,11 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
 		u16 index = skb_get_rx_queue(skb);
 
 		if (unlikely(index >= dev->real_num_rx_queues)) {
-			WARN_ONCE(dev->real_num_rx_queues > 1,
-				  "%s received packet on queue %u, but number "
-				  "of RX queues is %u\n",
-				  dev->name, index, dev->real_num_rx_queues);
+			if (dev->real_num_rx_queues > 1)
+				netdev_warn_once(dev,
+						 "received packet on queue %u, but number "
+						 "of RX queues is %u\n",
+						 index, dev->real_num_rx_queues);
 			goto done;
 		}
 		rxqueue += index;
@@ -5443,11 +5444,11 @@ static struct netdev_rx_queue *netif_get_rxqueue(struct sk_buff *skb)
 		u16 index = skb_get_rx_queue(skb);
 
 		if (unlikely(index >= dev->real_num_rx_queues)) {
-			WARN_ONCE(dev->real_num_rx_queues > 1,
-				  "%s received packet on queue %u, but number "
-				  "of RX queues is %u\n",
-				  dev->name, index, dev->real_num_rx_queues);
-
+			if (dev->real_num_rx_queues > 1)
+				netdev_warn_once(dev,
+						 "received packet on queue %u, but number "
+						 "of RX queues is %u\n",
+						 index, dev->real_num_rx_queues);
 			return rxqueue; /* Return first rxqueue */
 		}
 		rxqueue += index;
-- 
2.34.1

Re: [PATCH net-next] net: core: avoid WARN_ONCE for stale RX queue mappings

[Jiayuan Chen]

On 8/10/26 8:50 PM, Li Xiasong wrote:
> An skb may retain its recorded RX queue index while a network device
> reduces its number of active RX queues. For example, when a TUN queue
> is detached, queued skbs can still carry the queue's previous index.
>
> Both get_rps_cpu() and netif_get_rxqueue() validate the index before
> accessing the RX queue array. They safely fall back to local processing
> or the first RX queue, so an invalid index does not cause an
> out-of-bounds access.
>
> Using WARN_ONCE() for this recoverable condition can unnecessarily
> panic systems with panic_on_warn enabled. Replace it with
> netdev_warn_once() to retain the diagnostic without emitting a WARN
> splat.
>
> Signed-off-by: Li Xiasong <lixiasong1@huawei.com>




Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>


I just run ethtool -L rx 2 on my host and got such message..


------------[ cut here ]------------
veth1 received packet on queue 2, but number of RX queues is 2
WARNING: net/core/dev.c:5132 at get_rps_cpu+0x1d1/0x4b0, CPU#2: 
kworker/2:1/59
  <TASK>
  netif_rx_internal+0xa1/0x120
  __netif_rx+0x19/0xc0
  veth_xmit+0x267/0x360
  dev_hard_start_xmit+0x64/0x1d0
  __dev_queue_xmit+0x803/0x1190
  ip6_finish_output2+0x2d2/0x700
  ip6_finish_output+0xfb/0x3c0
  ip6_output+0x81/0x180
  NF_HOOK.constprop.0+0x4f/0x110
  mld_sendpack+0x1bf/0x290
  mld_ifc_work+0x19a/0x400
  process_one_work+0x19c/0x3e0
  worker_thread+0x1a8/0x330
  kthread+0xfb/0x140
  ret_from_fork+0x1c1/0x2c0
  ret_from_fork_asm+0x1a/0x30
  </TASK>
---[ end trace 0000000000000000 ]---


> ---
>   net/core/dev.c | 19 ++++++++++---------
>   1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index af260ff5462a..5db98b0a853f 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5126,10 +5126,11 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
>   		u16 index = skb_get_rx_queue(skb);
>   
>   		if (unlikely(index >= dev->real_num_rx_queues)) {
> -			WARN_ONCE(dev->real_num_rx_queues > 1,
> -				  "%s received packet on queue %u, but number "
> -				  "of RX queues is %u\n",
> -				  dev->name, index, dev->real_num_rx_queues);
> +			if (dev->real_num_rx_queues > 1)
> +				netdev_warn_once(dev,
> +						 "received packet on queue %u, but number "
> +						 "of RX queues is %u\n",
> +						 index, dev->real_num_rx_queues);
>   			goto done;
>   		}
>   		rxqueue += index;
> @@ -5443,11 +5444,11 @@ static struct netdev_rx_queue *netif_get_rxqueue(struct sk_buff *skb)
>   		u16 index = skb_get_rx_queue(skb);
>   
>   		if (unlikely(index >= dev->real_num_rx_queues)) {
> -			WARN_ONCE(dev->real_num_rx_queues > 1,
> -				  "%s received packet on queue %u, but number "
> -				  "of RX queues is %u\n",
> -				  dev->name, index, dev->real_num_rx_queues);
> -
> +			if (dev->real_num_rx_queues > 1)
> +				netdev_warn_once(dev,
> +						 "received packet on queue %u, but number "
> +						 "of RX queues is %u\n",
> +						 index, dev->real_num_rx_queues);
>   			return rxqueue; /* Return first rxqueue */
>   		}
>   		rxqueue += index;

Re: [PATCH net-next] net: core: avoid WARN_ONCE for stale RX queue mappings

[Jakub Kicinski]

On Tue, 11 Aug 2026 14:58:31 +0800 Jiayuan Chen wrote:
> I just run ethtool -L rx 2 on my host and got such message..

Looks like veth fails to restamp the queues, tho, doesn't it?
If so it's not an accidental race, the drivers are buggy and should 
be fixed..

Re: [PATCH net-next] net: core: avoid WARN_ONCE for stale RX queue mappings

[Jiayuan Chen]

On 8/13/26 10:03 AM, Jakub Kicinski wrote:
> On Tue, 11 Aug 2026 14:58:31 +0800 Jiayuan Chen wrote:
>> I just run ethtool -L rx 2 on my host and got such message..
> Looks like veth fails to restamp the queues, tho, doesn't it?
> If so it's not an accidental race, the drivers are buggy and should
> be fixed..

Yes, you're right.

My test only triggered a mismatch between veth's rx and tx queue counts, 
which is not a race condition, unlike the one this patch addresses.