[PATCH net-next v2 0/7] net: ethtool: add dedicated GRXRINGS driver callbacks

[PATCH net-next v2 0/7] net: ethtool: add dedicated GRXRINGS driver callbacks

[Breno Leitao]

This patchset introduces a new dedicated ethtool_ops callback,
.get_rx_ring_count, which enables drivers to provide the number of RX
rings directly, improving efficiency and clarity in RX ring queries and
RSS configuration.

Number of drivers implements .get_rxnfc callback just to report the ring
count, so, having a proper callback makes sense and simplify .get_rxnfc
(in some cases remove it completely).

This has been suggested by Jakub, and follow the same idea as RXFH
driver callbacks [1].

This also port virtio_net to this new callback. Once there is consensus
on this approach, I can start moving the drivers to this new callback.

Link: https://lore.kernel.org/all/20250611145949.2674086-1-kuba@kernel.org/ [1]

Suggested-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
Tested-by: Lei Yang <leiyang@redhat.com>
---
Changes in v2:
- rename get_num_rxrings() to ethtool_get_rx_ring_count() (Jakub)
- initialize struct ethtool_rxnfc() (Jakub)
- Link to v1: https://lore.kernel.org/r/20250909-gxrings-v1-0-634282f06a54@debian.org
---
Changes v1 from RFC:
- Renaming and changing the return type of .get_rxrings() callback (Jakub)
- Add the docstring format for the new callback (Simon)
- Remove the unecessary WARN_ONCE() (Jakub)
- Link to RFC: https://lore.kernel.org/r/20250905-gxrings-v1-0-984fc471f28f@debian.org

---
Breno Leitao (7):
      net: ethtool: pass the num of RX rings directly to ethtool_copy_validate_indir
      net: ethtool: add support for ETHTOOL_GRXRINGS ioctl
      net: ethtool: remove the duplicated handling from ethtool_get_rxrings
      net: ethtool: add get_rx_ring_count callback to optimize RX ring queries
      net: ethtool: update set_rxfh to use ethtool_get_rx_ring_count helper
      net: ethtool: update set_rxfh_indir to use ethtool_get_rx_ring_count helper
      net: virtio_net: add get_rxrings ethtool callback for RX ring queries

 drivers/net/virtio_net.c | 15 ++-------
 include/linux/ethtool.h  |  2 ++
 net/ethtool/ioctl.c      | 81 +++++++++++++++++++++++++++++++++++++-----------
 3 files changed, 68 insertions(+), 30 deletions(-)
---
base-commit: 1f24a240974589ce42f70502ccb3ff3f5189d69a
change-id: 20250905-gxrings-a2ec22ee2aec

Best regards,
--  
Breno Leitao <leitao@debian.org>

[PATCH net-next v2 1/7] net: ethtool: pass the num of RX rings directly to ethtool_copy_validate_indir

[Breno Leitao]

Modify ethtool_copy_validate_indir() and callers to validate indirection
table entries against the number of RX rings as an integer instead of
accessing rx_rings->data.

This will be useful in the future, given that struct ethtool_rxnfc might
not exist for native GRXRINGS call.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
 net/ethtool/ioctl.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index 0b2a4d0573b38..15627afa4424f 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -1246,8 +1246,8 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
 }
 
 static int ethtool_copy_validate_indir(u32 *indir, void __user *useraddr,
-					struct ethtool_rxnfc *rx_rings,
-					u32 size)
+				       int num_rx_rings,
+				       u32 size)
 {
 	int i;
 
@@ -1256,7 +1256,7 @@ static int ethtool_copy_validate_indir(u32 *indir, void __user *useraddr,
 
 	/* Validate ring indices */
 	for (i = 0; i < size; i++)
-		if (indir[i] >= rx_rings->data)
+		if (indir[i] >= num_rx_rings)
 			return -EINVAL;
 
 	return 0;
@@ -1366,7 +1366,7 @@ static noinline_for_stack int ethtool_set_rxfh_indir(struct net_device *dev,
 	} else {
 		ret = ethtool_copy_validate_indir(rxfh_dev.indir,
 						  useraddr + ringidx_offset,
-						  &rx_rings,
+						  rx_rings.data,
 						  rxfh_dev.indir_size);
 		if (ret)
 			goto out;
@@ -1587,7 +1587,7 @@ static noinline_for_stack int ethtool_set_rxfh(struct net_device *dev,
 		rxfh_dev.indir_size = dev_indir_size;
 		ret = ethtool_copy_validate_indir(rxfh_dev.indir,
 						  useraddr + rss_cfg_offset,
-						  &rx_rings,
+						  rx_rings.data,
 						  rxfh.indir_size);
 		if (ret)
 			goto out_free;

-- 
2.47.3

[PATCH net-next v2 2/7] net: ethtool: add support for ETHTOOL_GRXRINGS ioctl

[Breno Leitao]

This patch adds handling for the ETHTOOL_GRXRINGS ioctl command in the
ethtool ioctl dispatcher. It introduces a new helper function
ethtool_get_rxrings() that calls the driver's get_rxnfc() callback with
appropriate parameters to retrieve the number of RX rings supported
by the device.

By explicitly handling ETHTOOL_GRXRINGS, userspace queries through
ethtool can now obtain RX ring information in a structured manner.

In this patch, ethtool_get_rxrings() is a simply copy of
ethtool_get_rxnfc().

Signed-off-by: Breno Leitao <leitao@debian.org>
---
 net/ethtool/ioctl.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index 15627afa4424f..4214ab33c3c81 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -1208,6 +1208,44 @@ static noinline_for_stack int ethtool_set_rxnfc(struct net_device *dev,
 	return 0;
 }
 
+static noinline_for_stack int ethtool_get_rxrings(struct net_device *dev,
+						  u32 cmd,
+						  void __user *useraddr)
+{
+	struct ethtool_rxnfc info;
+	size_t info_size = sizeof(info);
+	const struct ethtool_ops *ops = dev->ethtool_ops;
+	int ret;
+	void *rule_buf = NULL;
+
+	if (!ops->get_rxnfc)
+		return -EOPNOTSUPP;
+
+	ret = ethtool_rxnfc_copy_struct(cmd, &info, &info_size, useraddr);
+	if (ret)
+		return ret;
+
+	if (info.cmd == ETHTOOL_GRXCLSRLALL) {
+		if (info.rule_cnt > 0) {
+			if (info.rule_cnt <= KMALLOC_MAX_SIZE / sizeof(u32))
+				rule_buf = kcalloc(info.rule_cnt, sizeof(u32),
+						   GFP_USER);
+			if (!rule_buf)
+				return -ENOMEM;
+		}
+	}
+
+	ret = ops->get_rxnfc(dev, &info, rule_buf);
+	if (ret < 0)
+		goto err_out;
+
+	ret = ethtool_rxnfc_copy_to_user(useraddr, &info, info_size, rule_buf);
+err_out:
+	kfree(rule_buf);
+
+	return ret;
+}
+
 static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
 						u32 cmd, void __user *useraddr)
 {
@@ -3377,6 +3415,8 @@ __dev_ethtool(struct net *net, struct ifreq *ifr, void __user *useraddr,
 		rc = ethtool_set_rxfh_fields(dev, ethcmd, useraddr);
 		break;
 	case ETHTOOL_GRXRINGS:
+		rc = ethtool_get_rxrings(dev, ethcmd, useraddr);
+		break;
 	case ETHTOOL_GRXCLSRLCNT:
 	case ETHTOOL_GRXCLSRULE:
 	case ETHTOOL_GRXCLSRLALL:

-- 
2.47.3

[PATCH net-next v2 3/7] net: ethtool: remove the duplicated handling from ethtool_get_rxrings

[Breno Leitao]

ethtool_get_rxrings() was a copy of ethtool_get_rxnfc(). Clean the code
that will never be executed for GRXRINGS specifically.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
 net/ethtool/ioctl.c | 33 ++++++++++-----------------------
 1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index 4214ab33c3c81..a0f3de76cea03 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -1212,52 +1212,39 @@ static noinline_for_stack int ethtool_get_rxrings(struct net_device *dev,
 						  u32 cmd,
 						  void __user *useraddr)
 {
-	struct ethtool_rxnfc info;
-	size_t info_size = sizeof(info);
 	const struct ethtool_ops *ops = dev->ethtool_ops;
+	struct ethtool_rxnfc info;
+	size_t info_size;
 	int ret;
-	void *rule_buf = NULL;
 
 	if (!ops->get_rxnfc)
 		return -EOPNOTSUPP;
 
+	info_size = sizeof(info);
 	ret = ethtool_rxnfc_copy_struct(cmd, &info, &info_size, useraddr);
 	if (ret)
 		return ret;
 
-	if (info.cmd == ETHTOOL_GRXCLSRLALL) {
-		if (info.rule_cnt > 0) {
-			if (info.rule_cnt <= KMALLOC_MAX_SIZE / sizeof(u32))
-				rule_buf = kcalloc(info.rule_cnt, sizeof(u32),
-						   GFP_USER);
-			if (!rule_buf)
-				return -ENOMEM;
-		}
-	}
-
-	ret = ops->get_rxnfc(dev, &info, rule_buf);
+	ret = ops->get_rxnfc(dev, &info, NULL);
 	if (ret < 0)
-		goto err_out;
-
-	ret = ethtool_rxnfc_copy_to_user(useraddr, &info, info_size, rule_buf);
-err_out:
-	kfree(rule_buf);
+		return ret;
 
-	return ret;
+	return ethtool_rxnfc_copy_to_user(useraddr, &info, info_size, NULL);
 }
 
 static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
 						u32 cmd, void __user *useraddr)
 {
-	struct ethtool_rxnfc info;
-	size_t info_size = sizeof(info);
 	const struct ethtool_ops *ops = dev->ethtool_ops;
-	int ret;
+	struct ethtool_rxnfc info;
 	void *rule_buf = NULL;
+	size_t info_size;
+	int ret;
 
 	if (!ops->get_rxnfc)
 		return -EOPNOTSUPP;
 
+	info_size = sizeof(info);
 	ret = ethtool_rxnfc_copy_struct(cmd, &info, &info_size, useraddr);
 	if (ret)
 		return ret;

-- 
2.47.3

[PATCH net-next v2 4/7] net: ethtool: add get_rx_ring_count callback to optimize RX ring queries

[Breno Leitao]

Add a new optional get_rx_ring_count callback in ethtool_ops to allow
drivers to provide the number of RX rings directly without going through
the full get_rxnfc flow classification interface.

Modify ethtool_get_rxrings() to use .get_rx_ring_count if available,
falling back to get_rxnfc() otherwise.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
 include/linux/ethtool.h |  2 ++
 net/ethtool/ioctl.c     | 23 +++++++++++++++++++----
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index de5bd76a400ca..2d91fd3102c14 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -968,6 +968,7 @@ struct kernel_ethtool_ts_info {
  * @reset: Reset (part of) the device, as specified by a bitmask of
  *	flags from &enum ethtool_reset_flags.  Returns a negative
  *	error code or zero.
+ * @get_rx_ring_count: Return the number of RX rings
  * @get_rxfh_key_size: Get the size of the RX flow hash key.
  *	Returns zero if not supported for this specific device.
  * @get_rxfh_indir_size: Get the size of the RX flow hash indirection table.
@@ -1162,6 +1163,7 @@ struct ethtool_ops {
 	int	(*set_rxnfc)(struct net_device *, struct ethtool_rxnfc *);
 	int	(*flash_device)(struct net_device *, struct ethtool_flash *);
 	int	(*reset)(struct net_device *, u32 *);
+	u32	(*get_rx_ring_count)(struct net_device *dev);
 	u32	(*get_rxfh_key_size)(struct net_device *);
 	u32	(*get_rxfh_indir_size)(struct net_device *);
 	int	(*get_rxfh)(struct net_device *, struct ethtool_rxfh_param *);
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index a0f3de76cea03..4981db3e285d8 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -1208,6 +1208,23 @@ static noinline_for_stack int ethtool_set_rxnfc(struct net_device *dev,
 	return 0;
 }
 
+static int ethtool_get_rx_ring_count(struct net_device *dev)
+{
+	const struct ethtool_ops *ops = dev->ethtool_ops;
+	struct ethtool_rxnfc rx_rings = {};
+	int ret;
+
+	if (ops->get_rx_ring_count)
+		return ops->get_rx_ring_count(dev);
+
+	rx_rings.cmd = ETHTOOL_GRXRINGS;
+	ret = ops->get_rxnfc(dev, &rx_rings, NULL);
+	if (ret < 0)
+		return ret;
+
+	return rx_rings.data;
+}
+
 static noinline_for_stack int ethtool_get_rxrings(struct net_device *dev,
 						  u32 cmd,
 						  void __user *useraddr)
@@ -1217,7 +1234,7 @@ static noinline_for_stack int ethtool_get_rxrings(struct net_device *dev,
 	size_t info_size;
 	int ret;
 
-	if (!ops->get_rxnfc)
+	if (!ops->get_rxnfc && !ops->get_rx_ring_count)
 		return -EOPNOTSUPP;
 
 	info_size = sizeof(info);
@@ -1225,9 +1242,7 @@ static noinline_for_stack int ethtool_get_rxrings(struct net_device *dev,
 	if (ret)
 		return ret;
 
-	ret = ops->get_rxnfc(dev, &info, NULL);
-	if (ret < 0)
-		return ret;
+	info.data = ethtool_get_rx_ring_count(dev);
 
 	return ethtool_rxnfc_copy_to_user(useraddr, &info, info_size, NULL);
 }

-- 
2.47.3

Re: [PATCH net-next v2 4/7] net: ethtool: add get_rx_ring_count callback to optimize RX ring queries

[Jakub Kicinski]

On Fri, 12 Sep 2025 08:59:13 -0700 Breno Leitao wrote:
> @@ -1225,9 +1242,7 @@ static noinline_for_stack int ethtool_get_rxrings(struct net_device *dev,
>  	if (ret)
>  		return ret;
>  
> -	ret = ops->get_rxnfc(dev, &info, NULL);
> -	if (ret < 0)
> -		return ret;
> +	info.data = ethtool_get_rx_ring_count(dev);

Is there a reason we're no longer checking for negative errno here?
It's possible that none of the drivers actually return an error, but
we should still check. For consistency with the other patches / paths
if nothing else.

>  	return ethtool_rxnfc_copy_to_user(useraddr, &info, info_size, NULL);
-- 
pw-bot: cr

Re: [PATCH net-next v2 4/7] net: ethtool: add get_rx_ring_count callback to optimize RX ring queries

[Breno Leitao]

On Sun, Sep 14, 2025 at 12:59:49PM -0700, Jakub Kicinski wrote:
> On Fri, 12 Sep 2025 08:59:13 -0700 Breno Leitao wrote:
> > @@ -1225,9 +1242,7 @@ static noinline_for_stack int ethtool_get_rxrings(struct net_device *dev,
> >  	if (ret)
> >  		return ret;
> >  
> > -	ret = ops->get_rxnfc(dev, &info, NULL);
> > -	if (ret < 0)
> > -		return ret;
> > +	info.data = ethtool_get_rx_ring_count(dev);
> 
> Is there a reason we're no longer checking for negative errno here?
> It's possible that none of the drivers actually return an error, but
> we should still check. For consistency with the other patches / paths
> if nothing else.

Agree, we need to check the result of ethtool_get_rx_ring_count, and
return it if negative. I will update the patchset.

[PATCH net-next v2 5/7] net: ethtool: update set_rxfh to use ethtool_get_rx_ring_count helper

[Breno Leitao]

Modify ethtool_set_rxfh() to use the new ethtool_get_rx_ring_count()
helper function for retrieving the number of RX rings instead of
directly calling get_rxnfc with ETHTOOL_GRXRINGS.

This way, we can leverage the new helper if it is available in ethtool_ops.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
 net/ethtool/ioctl.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index 4981db3e285d8..01db50ba85e71 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -1548,9 +1548,9 @@ static noinline_for_stack int ethtool_set_rxfh(struct net_device *dev,
 	struct ethtool_rxfh_param rxfh_dev = {};
 	struct ethtool_rxfh_context *ctx = NULL;
 	struct netlink_ext_ack *extack = NULL;
-	struct ethtool_rxnfc rx_rings;
 	struct ethtool_rxfh rxfh;
 	bool create = false;
+	int num_rx_rings;
 	u8 *rss_config;
 	int ntf = 0;
 	int ret;
@@ -1611,10 +1611,11 @@ static noinline_for_stack int ethtool_set_rxfh(struct net_device *dev,
 	if (!rss_config)
 		return -ENOMEM;
 
-	rx_rings.cmd = ETHTOOL_GRXRINGS;
-	ret = ops->get_rxnfc(dev, &rx_rings, NULL);
-	if (ret)
+	num_rx_rings = ethtool_get_rx_ring_count(dev);
+	if (num_rx_rings < 0) {
+		ret = num_rx_rings;
 		goto out_free;
+	}
 
 	/* rxfh.indir_size == 0 means reset the indir table to default (master
 	 * context) or delete the context (other RSS contexts).
@@ -1627,7 +1628,7 @@ static noinline_for_stack int ethtool_set_rxfh(struct net_device *dev,
 		rxfh_dev.indir_size = dev_indir_size;
 		ret = ethtool_copy_validate_indir(rxfh_dev.indir,
 						  useraddr + rss_cfg_offset,
-						  rx_rings.data,
+						  num_rx_rings,
 						  rxfh.indir_size);
 		if (ret)
 			goto out_free;
@@ -1639,7 +1640,8 @@ static noinline_for_stack int ethtool_set_rxfh(struct net_device *dev,
 			rxfh_dev.indir_size = dev_indir_size;
 			indir = rxfh_dev.indir;
 			for (i = 0; i < dev_indir_size; i++)
-				indir[i] = ethtool_rxfh_indir_default(i, rx_rings.data);
+				indir[i] =
+					ethtool_rxfh_indir_default(i, num_rx_rings);
 		} else {
 			rxfh_dev.rss_delete = true;
 		}

-- 
2.47.3

[PATCH net-next v2 6/7] net: ethtool: update set_rxfh_indir to use ethtool_get_rx_ring_count helper

[Breno Leitao]

Modify ethtool_set_rxfh() to use the new ethtool_get_rx_ring_count()
helper function for retrieving the number of RX rings instead of
directly calling get_rxnfc with ETHTOOL_GRXRINGS.

This way, we can leverage the new helper if it is available in ethtool_ops.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
 net/ethtool/ioctl.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index 01db50ba85e71..c95edb228c3b5 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -1367,7 +1367,7 @@ static noinline_for_stack int ethtool_set_rxfh_indir(struct net_device *dev,
 	const struct ethtool_ops *ops = dev->ethtool_ops;
 	struct ethtool_rxfh_param rxfh_dev = {};
 	struct netlink_ext_ack *extack = NULL;
-	struct ethtool_rxnfc rx_rings;
+	int num_rx_rings;
 	u32 user_size, i;
 	int ret;
 	u32 ringidx_offset = offsetof(struct ethtool_rxfh_indir, ring_index[0]);
@@ -1393,20 +1393,21 @@ static noinline_for_stack int ethtool_set_rxfh_indir(struct net_device *dev,
 	if (!rxfh_dev.indir)
 		return -ENOMEM;
 
-	rx_rings.cmd = ETHTOOL_GRXRINGS;
-	ret = ops->get_rxnfc(dev, &rx_rings, NULL);
-	if (ret)
+	num_rx_rings = ethtool_get_rx_ring_count(dev);
+	if (num_rx_rings < 0) {
+		ret = num_rx_rings;
 		goto out;
+	}
 
 	if (user_size == 0) {
 		u32 *indir = rxfh_dev.indir;
 
 		for (i = 0; i < rxfh_dev.indir_size; i++)
-			indir[i] = ethtool_rxfh_indir_default(i, rx_rings.data);
+			indir[i] = ethtool_rxfh_indir_default(i, num_rx_rings);
 	} else {
 		ret = ethtool_copy_validate_indir(rxfh_dev.indir,
 						  useraddr + ringidx_offset,
-						  rx_rings.data,
+						  num_rx_rings,
 						  rxfh_dev.indir_size);
 		if (ret)
 			goto out;

-- 
2.47.3

[PATCH net-next v2 7/7] net: virtio_net: add get_rxrings ethtool callback for RX ring queries

[Breno Leitao]

Replace the existing virtnet_get_rxnfc callback with a dedicated
virtnet_get_rxrings implementation to provide the number of RX rings
directly via the new ethtool_ops get_rx_ring_count pointer.

This simplifies the RX ring count retrieval and aligns virtio_net with
the new ethtool API for querying RX ring parameters.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
 drivers/net/virtio_net.c | 15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 975bdc5dab84b..e35b6ef015c05 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -5610,20 +5610,11 @@ static int virtnet_set_rxfh(struct net_device *dev,
 	return 0;
 }
 
-static int virtnet_get_rxnfc(struct net_device *dev, struct ethtool_rxnfc *info, u32 *rule_locs)
+static u32 virtnet_get_rx_ring_count(struct net_device *dev)
 {
 	struct virtnet_info *vi = netdev_priv(dev);
-	int rc = 0;
 
-	switch (info->cmd) {
-	case ETHTOOL_GRXRINGS:
-		info->data = vi->curr_queue_pairs;
-		break;
-	default:
-		rc = -EOPNOTSUPP;
-	}
-
-	return rc;
+	return vi->curr_queue_pairs;
 }
 
 static const struct ethtool_ops virtnet_ethtool_ops = {
@@ -5651,7 +5642,7 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
 	.set_rxfh = virtnet_set_rxfh,
 	.get_rxfh_fields = virtnet_get_hashflow,
 	.set_rxfh_fields = virtnet_set_hashflow,
-	.get_rxnfc = virtnet_get_rxnfc,
+	.get_rx_ring_count = virtnet_get_rx_ring_count,
 };
 
 static void virtnet_get_queue_stats_rx(struct net_device *dev, int i,

-- 
2.47.3

Re: [PATCH net-next v2 0/7] net: ethtool: add dedicated GRXRINGS driver callbacks

[Lei Yang]

Hi Breno

This series of patches introduced a kernel panic bug. The tests are
based on the linux-next commit [1]. I tried it a few times and found
that if I didn't apply the current patch, the issue wouldn't be
triggered. After applying the current patch, the probability of
triggering the issue was 3/3.

Reproduced steps:
1. git clone https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
2. applied this series of patches
3. compile and install
4. reboot server(A kernel panic occurs at this step)

[1] commit 590b221ed4256fd6c34d3dea77aa5bd6e741bbc1 (tag:
next-20250912, origin/master, origin/HEAD)
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Fri Sep 12 15:15:12 2025 +1000

    Add linux-next specific files for 20250912

    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

kernel panic messages:
[   13.769667] systemd[1]: bpf-restrict-fs: LSM BPF program attached
[   13.840778] systemd-rc-local-generator[1084]: /etc/rc.d/rc.local is
not marked executable, skipping.
[   13.892736]  slab kmalloc-64 start ffff8b3784459940 pointer offset 40 size 64
[   13.899909] list_add corruption. prev->next should be next
(ffffffffb5a91608), but was dead000000000100. (prev=ffff8b3784459968).
[   13.911570] ------------[ cut here ]------------
[   13.916185] kernel BUG at lib/list_debug.c:32!
[   13.920637] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[   13.925708] CPU: 26 UID: 0 PID: 325 Comm: kworker/26:1 Tainted: G S
         E       6.17.0-rc5-next-20250912+ #2 PREEMPT(voluntary)
[   13.937692] Tainted: [S]=CPU_OUT_OF_SPEC, [E]=UNSIGNED_MODULE
[   13.943437] Hardware name: Dell Inc. PowerEdge R740xd/01YM03, BIOS
2.2.11 06/13/2019
[   13.951176] Workqueue: cgroup_free css_free_rwork_fn
[   13.956150] RIP: 0010:__list_add_valid_or_report+0x94/0xa0
[   13.961635] Code: cf 88 ff 0f 0b 48 89 f7 48 89 34 24 e8 45 ba c7
ff 48 8b 34 24 48 c7 c7 e8 fe e7 b4 48 8b 16 48 89 f1 48 89 de e8 8c
cf 88 ff <0f> 0b 90 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
90 90
[   13.980381] RSP: 0018:ffffcdcb07397dc0 EFLAGS: 00010246
[   13.985605] RAX: 0000000000000075 RBX: ffffffffb5a91608 RCX: 0000000000000003
[   13.992740] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffffb59e45c8
[   13.999870] RBP: ffff8b3008a6e5b0 R08: 0000000000000000 R09: ffffcdcb07397c48
[   14.007001] R10: ffffffffb5924588 R11: 0000000000000003 R12: ffffffffb5a91600
[   14.014135] R13: ffff8b3784459968 R14: ffff8b3008a6e040 R15: ffff8b3004e5b468
[   14.021267] FS:  0000000000000000(0000) GS:ffff8b37a9be9000(0000)
knlGS:0000000000000000
[   14.029352] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   14.035098] CR2: 00007fb1ef5862f4 CR3: 0000000ed3a24006 CR4: 00000000007706f0
[   14.042229] PKRU: 55555554
[   14.044942] Call Trace:
[   14.047395]  <TASK>
[   14.049501]  mem_cgroup_css_free+0x52/0x150
[   14.053688]  css_free_rwork_fn+0x4e/0x1f0
[   14.057701]  process_one_work+0x18b/0x340
[   14.061714]  worker_thread+0x256/0x3a0
[   14.065465]  ? __pfx_worker_thread+0x10/0x10
[   14.069737]  kthread+0xfc/0x240
[   14.072882]  ? __pfx_kthread+0x10/0x10
[   14.076633]  ? __pfx_kthread+0x10/0x10
[   14.080388]  ret_from_fork+0xf0/0x110
[   14.084053]  ? __pfx_kthread+0x10/0x10
[   14.087807]  ret_from_fork_asm+0x1a/0x30
[   14.091733]  </TASK>
[   14.093924] Modules linked in: xfs(E) sd_mod(E) ahci(E) libahci(E)
ghash_clmulni_intel(E) wdat_wdt(E) megaraid_sas(E) tg3(E) libata(E)
wmi(E) sunrpc(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E)
be2iscsi(E) iscsi_boot_sysfs(E) bnx2i(E) cnic(E) uio(E) cxgb4i(E)
cxgb4(E) tls(E) libcxgbi(E) libcxgb(E) iscsi_tcp(E) libiscsi_tcp(E)
libiscsi(E) scsi_transport_iscsi(E) nfnetlink(E)
[   14.093947] Unloaded tainted modules: fjes(E):1
[   14.132310] ---[ end trace 0000000000000000 ]---
[   14.177186] RIP: 0010:__list_add_valid_or_report+0x94/0xa0
[   14.182685] Code: cf 88 ff 0f 0b 48 89 f7 48 89 34 24 e8 45 ba c7
ff 48 8b 34 24 48 c7 c7 e8 fe e7 b4 48 8b 16 48 89 f1 48 89 de e8 8c
cf 88 ff <0f> 0b 90 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
90 90
[   14.201432] RSP: 0018:ffffcdcb07397dc0 EFLAGS: 00010246
[   14.206666] RAX: 0000000000000075 RBX: ffffffffb5a91608 RCX: 0000000000000003
[   14.213803] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffffb59e45c8
[   14.220934] RBP: ffff8b3008a6e5b0 R08: 0000000000000000 R09: ffffcdcb07397c48
[   14.228067] R10: ffffffffb5924588 R11: 0000000000000003 R12: ffffffffb5a91600
[   14.235199] R13: ffff8b3784459968 R14: ffff8b3008a6e040 R15: ffff8b3004e5b468
[   14.242331] FS:  0000000000000000(0000) GS:ffff8b37a9be9000(0000)
knlGS:0000000000000000
[   14.250419] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   14.256164] CR2: 00007fb1ef5862f4 CR3: 0000000ed3a24006 CR4: 00000000007706f0
[   14.263296] PKRU: 55555554
[   14.266011] Kernel panic - not syncing: Fatal exception
[   14.271323] Kernel Offset: 0x32600000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[   14.323149] ---[ end Kernel panic - not syncing: Fatal exception ]---

Thanks
Lei


On Fri, Sep 12, 2025 at 11:59 PM Breno Leitao <leitao@debian.org> wrote:
>
> This patchset introduces a new dedicated ethtool_ops callback,
> .get_rx_ring_count, which enables drivers to provide the number of RX
> rings directly, improving efficiency and clarity in RX ring queries and
> RSS configuration.
>
> Number of drivers implements .get_rxnfc callback just to report the ring
> count, so, having a proper callback makes sense and simplify .get_rxnfc
> (in some cases remove it completely).
>
> This has been suggested by Jakub, and follow the same idea as RXFH
> driver callbacks [1].
>
> This also port virtio_net to this new callback. Once there is consensus
> on this approach, I can start moving the drivers to this new callback.
>
> Link: https://lore.kernel.org/all/20250611145949.2674086-1-kuba@kernel.org/ [1]
>
> Suggested-by: Jakub Kicinski <kuba@kernel.org>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> Tested-by: Lei Yang <leiyang@redhat.com>
> ---
> Changes in v2:
> - rename get_num_rxrings() to ethtool_get_rx_ring_count() (Jakub)
> - initialize struct ethtool_rxnfc() (Jakub)
> - Link to v1: https://lore.kernel.org/r/20250909-gxrings-v1-0-634282f06a54@debian.org
> ---
> Changes v1 from RFC:
> - Renaming and changing the return type of .get_rxrings() callback (Jakub)
> - Add the docstring format for the new callback (Simon)
> - Remove the unecessary WARN_ONCE() (Jakub)
> - Link to RFC: https://lore.kernel.org/r/20250905-gxrings-v1-0-984fc471f28f@debian.org
>
> ---
> Breno Leitao (7):
>       net: ethtool: pass the num of RX rings directly to ethtool_copy_validate_indir
>       net: ethtool: add support for ETHTOOL_GRXRINGS ioctl
>       net: ethtool: remove the duplicated handling from ethtool_get_rxrings
>       net: ethtool: add get_rx_ring_count callback to optimize RX ring queries
>       net: ethtool: update set_rxfh to use ethtool_get_rx_ring_count helper
>       net: ethtool: update set_rxfh_indir to use ethtool_get_rx_ring_count helper
>       net: virtio_net: add get_rxrings ethtool callback for RX ring queries
>
>  drivers/net/virtio_net.c | 15 ++-------
>  include/linux/ethtool.h  |  2 ++
>  net/ethtool/ioctl.c      | 81 +++++++++++++++++++++++++++++++++++++-----------
>  3 files changed, 68 insertions(+), 30 deletions(-)
> ---
> base-commit: 1f24a240974589ce42f70502ccb3ff3f5189d69a
> change-id: 20250905-gxrings-a2ec22ee2aec
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
>

Re: [PATCH net-next v2 0/7] net: ethtool: add dedicated GRXRINGS driver callbacks

[Breno Leitao]

Hello Lei,

On Mon, Sep 15, 2025 at 06:50:15PM +0800, Lei Yang wrote:
> Hi Breno
> 
> This series of patches introduced a kernel panic bug. The tests are
> based on the linux-next commit [1]. I tried it a few times and found
> that if I didn't apply the current patch, the issue wouldn't be
> triggered. After applying the current patch, the probability of
> triggering the issue was 3/3.
> 
> Reproduced steps:
> 1. git clone https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> 2. applied this series of patches
> 3. compile and install
> 4. reboot server(A kernel panic occurs at this step)

Thanks for the report. Let me try to reproduce it on my side.

Is this a physical machine, or, are you using a VM with the virtio change?

Thanks,
--breno

Re: [PATCH net-next v2 0/7] net: ethtool: add dedicated GRXRINGS driver callbacks

[Breno Leitao]

On Mon, Sep 15, 2025 at 03:55:53AM -0700, Breno Leitao wrote:
> On Mon, Sep 15, 2025 at 06:50:15PM +0800, Lei Yang wrote:
> > This series of patches introduced a kernel panic bug. The tests are
> > based on the linux-next commit [1]. I tried it a few times and found
> > that if I didn't apply the current patch, the issue wouldn't be
> > triggered. After applying the current patch, the probability of
> > triggering the issue was 3/3.
> > 
> > Reproduced steps:
> > 1. git clone https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > 2. applied this series of patches
> > 3. compile and install
> > 4. reboot server(A kernel panic occurs at this step)
> 
> Thanks for the report. Let me try to reproduce it on my side.
> 
> Is this a physical machine, or, are you using a VM with the virtio change?

Also, I've just sent v3 earlier today, let me know if you have chance to
test it as well, given it fixes the issue raised by Jakub in [1]

Link: https://lore.kernel.org/all/20250914125949.17ea0ade@kernel.org/ [1]

Re: [PATCH net-next v2 0/7] net: ethtool: add dedicated GRXRINGS driver callbacks

[Lei Yang]

On Mon, Sep 15, 2025 at 6:58 PM Breno Leitao <leitao@debian.org> wrote:
>
> On Mon, Sep 15, 2025 at 03:55:53AM -0700, Breno Leitao wrote:
> > On Mon, Sep 15, 2025 at 06:50:15PM +0800, Lei Yang wrote:
> > > This series of patches introduced a kernel panic bug. The tests are
> > > based on the linux-next commit [1]. I tried it a few times and found
> > > that if I didn't apply the current patch, the issue wouldn't be
> > > triggered. After applying the current patch, the probability of
> > > triggering the issue was 3/3.
> > >
> > > Reproduced steps:
> > > 1. git clone https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > > 2. applied this series of patches
> > > 3. compile and install
> > > 4. reboot server(A kernel panic occurs at this step)
> >
> > Thanks for the report. Let me try to reproduce it on my side.

Hi Breno
> >
> > Is this a physical machine, or, are you using a VM with the virtio change?

Yes, I test it with a physical machine. I didn't used VM， just install
rpm which compiled based on this series patches, then hit kernel pahic
at server rebooting.
>
> Also, I've just sent v3 earlier today, let me know if you have chance to
> test it as well, given it fixes the issue raised by Jakub in [1]
>
> Link: https://lore.kernel.org/all/20250914125949.17ea0ade@kernel.org/ [1]

I already submitted a job to test v3, the test will be completed
tomorrow and I will update the results promptly.

Best Regards
Lei
>

Re: [PATCH net-next v2 0/7] net: ethtool: add dedicated GRXRINGS driver callbacks

[Jakub Kicinski]

On Mon, 15 Sep 2025 18:50:15 +0800 Lei Yang wrote:
> Hi Breno
> 
> This series of patches introduced a kernel panic bug. The tests are
> based on the linux-next commit [1]. I tried it a few times and found
> that if I didn't apply the current patch, the issue wouldn't be
> triggered. After applying the current patch, the probability of
> triggering the issue was 3/3.

I really doubt the warning you're reporting is related to this series.