* Re: [PATCH net-next v2 6/7] selftests: rds: Collect pcaps on timeout
From: Allison Henderson @ 2026-05-02 5:41 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, pabeni, edumazet, horms, linux-rdma, linux-kselftest,
shuah
In-Reply-To: <20260430024207.2452372-1-kuba@kernel.org>
On Wed, 2026-04-29 at 19:42 -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> selftests: rds: Collect pcaps on timeout
>
> This commit updates the RDS selftest to collect network packet captures
> when a timeout occurs. It moves the packet capture cleanup logic into a
> new helper function and calls it from the signal handler before exiting.
>
> > diff --git a/tools/testing/selftests/net/rds/test.py b/tools/testing/selftests/net/rds/test.py
> > --- a/tools/testing/selftests/net/rds/test.py
> > +++ b/tools/testing/selftests/net/rds/test.py
> [ ... ]
> > @@ -70,11 +70,21 @@ def netns_socket(netns, *sock_args):
> > u1.close()
> > return socket.fromfd(fds[0], *sock_args)
> >
> > +def collect_pcaps():
> > + """Stop tcpdump processes and move their pcaps into the log dir."""
> > + print("Stopping network packet captures")
> > + for proc, tmp_path, dest_path, fno in tcpdump_procs:
> > + proc.terminate()
> > + proc.wait()
>
> Could this proc.wait() block indefinitely and defeat the test timeout?
>
> If a child process is unresponsive, the timeout signal handler will get
> stuck waiting for it. Using proc.wait(timeout=...) might ensure the
> timeout path remains robust and doesn't hang the test infrastructure.
Good catch, I will add a timeout
>
> > + os.close(fno)
> > + shutil.move(tmp_path, dest_path)
>
> Can this cause unhandled exceptions if the timeout triggers during or
> after the normal script cleanup phase?
>
> Because collect_pcaps() is called from both the normal execution path and
> the timeout signal handler, it might be executed twice. Since it loops
> over the global tcpdump_procs list without clearing processed items, a
> second run will attempt to close already closed file descriptors and move
> already moved files.
>
> In Python, this raises OSError (EBADF) and FileNotFoundError, which would
> abort the signal handler with a traceback instead of executing the clean
> sys.exit(1).
I see, I think if we change the for loop to a while loop that pop() items out of tcpdump_procs, that should make it safe
to call twice, if the timeout fires during or after normal cleanup.
If that sounds good, I can send that in a v3.
Thanks!
Allison
^ permalink raw reply
* Re: [PATCH net-next v2 5/7] selftests: rds: Fix gcov and pcap collection
From: Allison Henderson @ 2026-05-02 5:43 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, pabeni, edumazet, horms, linux-rdma, linux-kselftest,
shuah
In-Reply-To: <20260429194806.6ae176a9@kernel.org>
On Wed, 2026-04-29 at 19:48 -0700, Jakub Kicinski wrote:
> On Wed, 29 Apr 2026 19:42:06 -0700 Jakub Kicinski wrote:
> > > +# tcpdump saves pcaps to /tmp because it requires chown to save the
> > > +# pcap but chown is not supported by 9p. Mount tmpfs on /tmp if it is
> > > +# not already a separate filesystem
> > > +if ! mountpoint -q /tmp 2>/dev/null; then
> > > + mount -t tmpfs tmpfs /tmp
> > > +fi
> > > +
> >
> > Could this introduce a regression when the test is run directly on a host
> > workstation rather than inside an isolated VM?
> >
> > If /tmp is a regular directory on the root filesystem, mounting tmpfs over it
> > will instantly hide all existing files and UNIX domain sockets in /tmp.
> >
> > Since there is no cleanup trap to unmount it on exit or failure, does this
> > leave the host system in a degraded state?
>
> I share Sashiko's mixed feelings here. Do other tests mount /tmp ?
> Seems like something that belongs in the "CI setup", external
> to ksft itself.
Ok, I did some looking around, and while I dont see any tests that mount /tmp, I did notice that mptcp_join.sh and
simult_flows.sh use a $SUDO_USER, presumably to get away from the chown issue. But without getting off the 9p fs
with some sort of scratch area, we still end up with empty pcaps.
>
> point #2 my vng does have an overlayfs mounted over /tmp so the
> mountpoint check doesn't trigger IDK if this is what you meant
> or I have a different version.
I did try using --overlay-rwdir, and I think that gives rw to the guest, but it's ro to the host, so we dont get to keep
the pcaps post mortem.
What we can do, if it sounds ok to you, is set up a temp scratch area in the rds_logs folder so it's not mounting over
/tmp, and then run.sh can handle the mount with a cleanup trap addressing Sashiko's concern
Let me know what you think?
Thank you for the reviews!
Allison
^ permalink raw reply
* [PATCH 2/4] net: switchdev: fix duplicate word in documentation
From: Wang Zihan @ 2026-05-02 5:59 UTC (permalink / raw)
To: kuba; +Cc: netdev, linux-doc, Wang Zihan
Remove duplicate "in" word.
Signed-off-by: Wang Zihan <jiyu03@qq.com>
---
Documentation/networking/switchdev.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst
index 2966b7122..948bce44c 100644
--- a/Documentation/networking/switchdev.rst
+++ b/Documentation/networking/switchdev.rst
@@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
bond will see its upper master change. If that bond is moved into a bridge,
the bond's upper master will change. And so on. The driver will track such
-movements to know what position a port is in in the overall topology by
+movements to know what position a port is in the overall topology by
registering for netdevice events and acting on NETDEV_CHANGEUPPER.
L2 Forwarding Offload
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next v5 1/5] ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation
From: Nikolay Aleksandrov @ 2026-05-02 6:02 UTC (permalink / raw)
To: Ujjal Roy, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Ido Schimmel, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata
Cc: Ujjal Roy, bridge, netdev, linux-kernel, linux-kselftest
In-Reply-To: <20260501173130.3486-2-royujjal@gmail.com>
On 01/05/2026 20:31, Ujjal Roy wrote:
> Get rid of the IGMPV3_MRC macro and use the igmpv3_mrt() API to
> calculate the Max Resp Time from the Maximum Response Code.
>
> Similarly, for IGMPV3_QQIC, use the igmpv3_qqi() API to calculate
> the Querier's Query Interval from the QQIC field.
>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
> Signed-off-by: Ujjal Roy <royujjal@gmail.com>
> ---
> include/linux/igmp.h | 80 +++++++++++++++++++++++++++++++++++----
> net/bridge/br_multicast.c | 2 +-
> net/ipv4/igmp.c | 6 +--
> 3 files changed, 76 insertions(+), 12 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net-next v5 2/5] ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()
From: Nikolay Aleksandrov @ 2026-05-02 6:03 UTC (permalink / raw)
To: Ujjal Roy, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Ido Schimmel, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata
Cc: Ujjal Roy, bridge, netdev, linux-kernel, linux-kselftest
In-Reply-To: <20260501173130.3486-3-royujjal@gmail.com>
On 01/05/2026 20:31, Ujjal Roy wrote:
> Rename mldv2_mrc() to mldv2_mrd() as it is used to calculate
> the Maximum Response Delay from the Maximum Response Code.
>
> Introduce a new API mldv2_qqi() to define the existing
> calculation logic of QQI from QQIC. This also organizes
> the existing mld_update_qi() API.
>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
> Signed-off-by: Ujjal Roy <royujjal@gmail.com>
> ---
> include/net/mld.h | 66 +++++++++++++++++++++++++++++++++------
> net/bridge/br_multicast.c | 2 +-
> net/ipv6/mcast.c | 19 ++---------
> 3 files changed, 61 insertions(+), 26 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net-next v5 3/5] ipv4: igmp: encode multicast exponential fields
From: Nikolay Aleksandrov @ 2026-05-02 6:04 UTC (permalink / raw)
To: Ujjal Roy, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Ido Schimmel, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata
Cc: Ujjal Roy, bridge, netdev, linux-kernel, linux-kselftest
In-Reply-To: <20260501173130.3486-4-royujjal@gmail.com>
On 01/05/2026 20:31, Ujjal Roy wrote:
> In IGMP, MRC and QQIC fields are not correctly encoded
> when generating query packets. Since the receiver of the
> query interprets these fields using the IGMPv3 floating-
> point decoding logic, any value that exceeds the linear
> threshold is incorrectly parsed as an exponential value,
> leading to an incorrect interval calculation.
>
> Encode and assign the corresponding protocol fields during
> query generation. Introduce the logic to dynamically
> calculate the exponent and mantissa using bit-scan (fls).
> This ensures MRC and QQIC fields (8-bit) are properly
> encoded when transmitting query packets with intervals
> that exceed their respective linear threshold value of
> 128 (for MRT/QQI).
>
> RFC3376: for both MRC and QQIC, values >= 128 represent
> the same floating-point encoding as follows:
> 0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+
> |1| exp | mant |
> +-+-+-+-+-+-+-+-+
>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
> Signed-off-by: Ujjal Roy <royujjal@gmail.com>
> ---
> include/linux/igmp.h | 87 +++++++++++++++++++++++++++++++++++++++
> net/bridge/br_multicast.c | 14 +++----
> 2 files changed, 93 insertions(+), 8 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net-next v5 4/5] ipv6: mld: encode multicast exponential fields
From: Nikolay Aleksandrov @ 2026-05-02 6:05 UTC (permalink / raw)
To: Ujjal Roy, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Ido Schimmel, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata
Cc: Ujjal Roy, bridge, netdev, linux-kernel, linux-kselftest
In-Reply-To: <20260501173130.3486-5-royujjal@gmail.com>
On 01/05/2026 20:31, Ujjal Roy wrote:
> In MLD, MRC and QQIC fields are not correctly encoded when
> generating query packets. Since the receiver of the query
> interprets these fields using the MLDv2 floating-point
> decoding logic, any value that exceeds the linear threshold
> is incorrectly parsed as an exponential value, leading to
> an incorrect interval calculation.
>
> Encode and assign the corresponding protocol fields during
> query generation. Introduce the logic to dynamically
> calculate the exponent and mantissa using bit-scan (fls).
> This ensures MRC (16-bit) and QQIC (8-bit) fields are
> properly encoded when transmitting query packets with
> intervals that exceed their respective linear thresholds
> (32768 for MRD; 128 for QQI).
>
> RFC3810: If Maximum Response Code >= 32768, the Maximum
> Response Code field represents a floating-point value as
> follows:
> 0 1 2 3 4 5 6 7 8 9 A B C D E F
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |1| exp | mant |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> RFC3810: If QQIC >= 128, the QQIC field represents a
> floating-point value as follows:
> 0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+
> |1| exp | mant |
> +-+-+-+-+-+-+-+-+
>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
> Signed-off-by: Ujjal Roy <royujjal@gmail.com>
> ---
> include/net/mld.h | 119 ++++++++++++++++++++++++++++++++++++++
> net/bridge/br_multicast.c | 4 +-
> 2 files changed, 121 insertions(+), 2 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net-next v5 5/5] selftests: net: bridge: add MRC and QQIC field encoding tests
From: Nikolay Aleksandrov @ 2026-05-02 6:06 UTC (permalink / raw)
To: Ujjal Roy, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Ido Schimmel, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata
Cc: Ujjal Roy, bridge, netdev, linux-kernel, linux-kselftest
In-Reply-To: <20260501173130.3486-6-royujjal@gmail.com>
On 01/05/2026 20:31, Ujjal Roy wrote:
> Enhance vlmc_query_intvl_test and vlmc_query_response_intvl_test in
> bridge_vlan_mcast.sh to validate IGMPv3/MLDv2 protocol compliance for
> MRC and QQIC field encoding across both linear and exponential ranges.
>
> TEST: Vlan multicast snooping enable [ OK ]
> TEST: Vlan mcast_query_interval global option default value [ OK ]
> TEST: Number of tagged IGMPv2 general query [ OK ]
> TEST: IGMPv3 QQIC linear value 60(s) [ OK ]
> TEST: MLDv2 QQIC linear value 60(s) [ OK ]
> TEST: IGMPv3 QQIC non linear value 160(s) [ OK ]
> TEST: MLDv2 QQIC non linear value 160(s) [ OK ]
> TEST: Vlan mcast_query_response_interval global option default value [ OK ]
> TEST: IGMPv3 MRC linear value of 60(x0.1s) [ OK ]
> TEST: MLDv2 MRC linear value of 24000(ms) [ OK ]
> TEST: IGMPv3 MRC non linear value of 240(x0.1s) [ OK ]
> TEST: MLDv2 MRC non linear value of 48000(ms) [ OK ]
>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
> Signed-off-by: Ujjal Roy <royujjal@gmail.com>
> ---
> .../net/forwarding/bridge_vlan_mcast.sh | 140 +++++++++++++++++-
> 1 file changed, 132 insertions(+), 8 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* [PATCH v2] net: switchdev: fix duplicate word in documentation
From: Wang Zihan @ 2026-05-02 6:07 UTC (permalink / raw)
To: kuba; +Cc: netdev, linux-doc, Wang Zihan
Remove duplicate "in" word.
Signed-off-by: Wang Zihan <jiyu03@qq.com>
---
Documentation/networking/switchdev.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst
index 2966b7122..948bce44c 100644
--- a/Documentation/networking/switchdev.rst
+++ b/Documentation/networking/switchdev.rst
@@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
bond will see its upper master change. If that bond is moved into a bridge,
the bond's upper master will change. And so on. The driver will track such
-movements to know what position a port is in in the overall topology by
+movements to know what position a port is in the overall topology by
registering for netdevice events and acting on NETDEV_CHANGEUPPER.
L2 Forwarding Offload
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v3 0/2] net: mana: Avoid queue struct allocation failure under memory fragmentation
From: Aditya Garg @ 2026-05-02 7:45 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, kotaranov, horms, ssengar, jacob.e.keller,
dipayanroy, ernis, shirazsaleem, kees, sbhatta, leitao, netdev,
linux-hyperv, linux-kernel, linux-rdma, bpf, gargaditya,
gargaditya
The MANA driver can fail to load on systems with high memory
utilization because several allocations in the queue setup paths
require large physically contiguous blocks via kmalloc. Under memory
fragmentation these high-order allocations may fail, preventing the
driver from creating queues when opening the interface or when
reconfiguring channels, ring parameters or MTU at runtime.
Allocation sizes that are problematic:
mana_create_txq -> tx_qp flat array (sizeof(mana_tx_qp) = 35528):
16 queues (default): 35528 * 16 = ~555 KB contiguous
64 queues (max): 35528 * 64 = ~2220 KB contiguous
mana_create_rxq -> rxq struct with flex array
(sizeof(mana_rxq) = 35712, rx_oobs=296 per entry):
depth 1024 (default): 35712 + 296 * 1024 = ~331 KB per queue
depth 8192 (max): 35712 + 296 * 8192 = ~2403 KB per queue
mana_pre_alloc_rxbufs -> rxbufs_pre and das_pre arrays:
16 queues, depth 1024 (default): 16 * 1024 * 8 = 128 KB each
64 queues, depth 8192 (max): 64 * 8192 * 8 = 4096 KB each
This series addresses the issue by:
1. Converting the tx_qp flat array into an array of pointers with
per-queue kvzalloc (~35 KB each), replacing a single contiguous
allocation that can reach ~2.2 MB at 64 queues.
2. Switching rxbufs_pre, das_pre, and rxq allocations to
kvmalloc/kvzalloc so the allocator can fall back to vmalloc
when contiguous memory is unavailable.
Throughput testing confirms no regression. Since kvmalloc falls
back to vmalloc under memory fragmentation, all kvmalloc calls
were temporarily replaced with vmalloc to simulate the fallback
path (iperf3, GBits/sec):
Physically contiguous vmalloc region
Connections TX RX TX RX
--------------------------------------------------------------
1 47.2 46.9 46.8 46.6
16 181 181 181 181
32 181 181 181 181
64 181 181 181 181
---
Changes in v3:
- Rebased to latest net-next (net-next reopened)
Changes in v2:
- Rebased to latest net-next
Aditya Garg (2):
net: mana: Use per-queue allocation for tx_qp to reduce allocation
size
net: mana: Use kvmalloc for large RX queue and buffer allocations
.../net/ethernet/microsoft/mana/mana_bpf.c | 2 +-
drivers/net/ethernet/microsoft/mana/mana_en.c | 61 +++++++++++--------
.../ethernet/microsoft/mana/mana_ethtool.c | 2 +-
include/net/mana/mana.h | 2 +-
4 files changed, 39 insertions(+), 28 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH net-next v3 2/2] net: mana: Use kvmalloc for large RX queue and buffer allocations
From: Aditya Garg @ 2026-05-02 7:45 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, kotaranov, horms, ssengar, jacob.e.keller,
dipayanroy, ernis, shirazsaleem, kees, sbhatta, leitao, netdev,
linux-hyperv, linux-kernel, linux-rdma, bpf, gargaditya,
gargaditya
In-Reply-To: <20260502074552.23857-1-gargaditya@linux.microsoft.com>
The RX path allocations for rxbufs_pre, das_pre, and rxq scale with
queue count and queue depth. With high queue counts and depth, these can
exceed what kmalloc can reliably provide from physically contiguous
memory under fragmentation.
Switch these from kmalloc to kvmalloc variants so the allocator
transparently falls back to vmalloc when contiguous memory is scarce,
and update the corresponding frees to kvfree.
Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/net/ethernet/microsoft/mana/mana_en.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index 8adf72b96145..e1d8ac3417e8 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -685,11 +685,11 @@ void mana_pre_dealloc_rxbufs(struct mana_port_context *mpc)
put_page(virt_to_head_page(mpc->rxbufs_pre[i]));
}
- kfree(mpc->das_pre);
+ kvfree(mpc->das_pre);
mpc->das_pre = NULL;
out2:
- kfree(mpc->rxbufs_pre);
+ kvfree(mpc->rxbufs_pre);
mpc->rxbufs_pre = NULL;
out1:
@@ -806,11 +806,11 @@ int mana_pre_alloc_rxbufs(struct mana_port_context *mpc, int new_mtu, int num_qu
num_rxb = num_queues * mpc->rx_queue_size;
WARN(mpc->rxbufs_pre, "mana rxbufs_pre exists\n");
- mpc->rxbufs_pre = kmalloc_array(num_rxb, sizeof(void *), GFP_KERNEL);
+ mpc->rxbufs_pre = kvmalloc_array(num_rxb, sizeof(void *), GFP_KERNEL);
if (!mpc->rxbufs_pre)
goto error;
- mpc->das_pre = kmalloc_objs(dma_addr_t, num_rxb);
+ mpc->das_pre = kvmalloc_objs(dma_addr_t, num_rxb);
if (!mpc->das_pre)
goto error;
@@ -2564,7 +2564,7 @@ static void mana_destroy_rxq(struct mana_port_context *apc,
if (rxq->gdma_rq)
mana_gd_destroy_queue(gc, rxq->gdma_rq);
- kfree(rxq);
+ kvfree(rxq);
}
static int mana_fill_rx_oob(struct mana_recv_buf_oob *rx_oob, u32 mem_key,
@@ -2704,7 +2704,7 @@ static struct mana_rxq *mana_create_rxq(struct mana_port_context *apc,
gc = gd->gdma_context;
- rxq = kzalloc_flex(*rxq, rx_oobs, apc->rx_queue_size);
+ rxq = kvzalloc_flex(*rxq, rx_oobs, apc->rx_queue_size);
if (!rxq)
return NULL;
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v3 1/2] net: mana: Use per-queue allocation for tx_qp to reduce allocation size
From: Aditya Garg @ 2026-05-02 7:45 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, kotaranov, horms, ssengar, jacob.e.keller,
dipayanroy, ernis, shirazsaleem, kees, sbhatta, leitao, netdev,
linux-hyperv, linux-kernel, linux-rdma, bpf, gargaditya,
gargaditya
In-Reply-To: <20260502074552.23857-1-gargaditya@linux.microsoft.com>
Convert tx_qp from a single contiguous array allocation to per-queue
individual allocations. Each mana_tx_qp struct is approximately 35KB.
With many queues (e.g., 32/64), the flat array requires a single
contiguous allocation that can fail under memory fragmentation.
Change mana_tx_qp *tx_qp to mana_tx_qp **tx_qp (array of pointers),
allocating each queue's mana_tx_qp individually via kvzalloc. This
reduces each allocation to ~35KB and provides vmalloc fallback,
avoiding allocation failure due to fragmentation.
Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
---
.../net/ethernet/microsoft/mana/mana_bpf.c | 2 +-
drivers/net/ethernet/microsoft/mana/mana_en.c | 49 ++++++++++++-------
.../ethernet/microsoft/mana/mana_ethtool.c | 2 +-
include/net/mana/mana.h | 2 +-
4 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/mana_bpf.c b/drivers/net/ethernet/microsoft/mana/mana_bpf.c
index 7697c9b52ed3..b5e9bb184a1d 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_bpf.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_bpf.c
@@ -68,7 +68,7 @@ int mana_xdp_xmit(struct net_device *ndev, int n, struct xdp_frame **frames,
count++;
}
- tx_stats = &apc->tx_qp[q_idx].txq.stats;
+ tx_stats = &apc->tx_qp[q_idx]->txq.stats;
u64_stats_update_begin(&tx_stats->syncp);
tx_stats->xdp_xmit += count;
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index a654b3699c4c..8adf72b96145 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -355,9 +355,9 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
if (skb_cow_head(skb, MANA_HEADROOM))
goto tx_drop_count;
- txq = &apc->tx_qp[txq_idx].txq;
+ txq = &apc->tx_qp[txq_idx]->txq;
gdma_sq = txq->gdma_sq;
- cq = &apc->tx_qp[txq_idx].tx_cq;
+ cq = &apc->tx_qp[txq_idx]->tx_cq;
tx_stats = &txq->stats;
BUILD_BUG_ON(MAX_TX_WQE_SGL_ENTRIES != MANA_MAX_TX_WQE_SGL_ENTRIES);
@@ -614,7 +614,7 @@ static void mana_get_stats64(struct net_device *ndev,
}
for (q = 0; q < num_queues; q++) {
- tx_stats = &apc->tx_qp[q].txq.stats;
+ tx_stats = &apc->tx_qp[q]->txq.stats;
do {
start = u64_stats_fetch_begin(&tx_stats->syncp);
@@ -2321,21 +2321,26 @@ static void mana_destroy_txq(struct mana_port_context *apc)
return;
for (i = 0; i < apc->num_queues; i++) {
- debugfs_remove_recursive(apc->tx_qp[i].mana_tx_debugfs);
- apc->tx_qp[i].mana_tx_debugfs = NULL;
+ if (!apc->tx_qp[i])
+ continue;
+
+ debugfs_remove_recursive(apc->tx_qp[i]->mana_tx_debugfs);
+ apc->tx_qp[i]->mana_tx_debugfs = NULL;
- napi = &apc->tx_qp[i].tx_cq.napi;
- if (apc->tx_qp[i].txq.napi_initialized) {
+ napi = &apc->tx_qp[i]->tx_cq.napi;
+ if (apc->tx_qp[i]->txq.napi_initialized) {
napi_synchronize(napi);
napi_disable_locked(napi);
netif_napi_del_locked(napi);
- apc->tx_qp[i].txq.napi_initialized = false;
+ apc->tx_qp[i]->txq.napi_initialized = false;
}
- mana_destroy_wq_obj(apc, GDMA_SQ, apc->tx_qp[i].tx_object);
+ mana_destroy_wq_obj(apc, GDMA_SQ, apc->tx_qp[i]->tx_object);
- mana_deinit_cq(apc, &apc->tx_qp[i].tx_cq);
+ mana_deinit_cq(apc, &apc->tx_qp[i]->tx_cq);
- mana_deinit_txq(apc, &apc->tx_qp[i].txq);
+ mana_deinit_txq(apc, &apc->tx_qp[i]->txq);
+
+ kvfree(apc->tx_qp[i]);
}
kfree(apc->tx_qp);
@@ -2344,7 +2349,7 @@ static void mana_destroy_txq(struct mana_port_context *apc)
static void mana_create_txq_debugfs(struct mana_port_context *apc, int idx)
{
- struct mana_tx_qp *tx_qp = &apc->tx_qp[idx];
+ struct mana_tx_qp *tx_qp = apc->tx_qp[idx];
char qnum[32];
sprintf(qnum, "TX-%d", idx);
@@ -2383,7 +2388,7 @@ static int mana_create_txq(struct mana_port_context *apc,
int err;
int i;
- apc->tx_qp = kzalloc_objs(struct mana_tx_qp, apc->num_queues);
+ apc->tx_qp = kzalloc_objs(struct mana_tx_qp *, apc->num_queues);
if (!apc->tx_qp)
return -ENOMEM;
@@ -2403,10 +2408,16 @@ static int mana_create_txq(struct mana_port_context *apc,
gc = gd->gdma_context;
for (i = 0; i < apc->num_queues; i++) {
- apc->tx_qp[i].tx_object = INVALID_MANA_HANDLE;
+ apc->tx_qp[i] = kvzalloc_obj(*apc->tx_qp[i]);
+ if (!apc->tx_qp[i]) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ apc->tx_qp[i]->tx_object = INVALID_MANA_HANDLE;
/* Create SQ */
- txq = &apc->tx_qp[i].txq;
+ txq = &apc->tx_qp[i]->txq;
u64_stats_init(&txq->stats.syncp);
txq->ndev = net;
@@ -2424,7 +2435,7 @@ static int mana_create_txq(struct mana_port_context *apc,
goto out;
/* Create SQ's CQ */
- cq = &apc->tx_qp[i].tx_cq;
+ cq = &apc->tx_qp[i]->tx_cq;
cq->type = MANA_CQ_TYPE_TX;
cq->txq = txq;
@@ -2453,7 +2464,7 @@ static int mana_create_txq(struct mana_port_context *apc,
err = mana_create_wq_obj(apc, apc->port_handle, GDMA_SQ,
&wq_spec, &cq_spec,
- &apc->tx_qp[i].tx_object);
+ &apc->tx_qp[i]->tx_object);
if (err)
goto out;
@@ -3288,7 +3299,7 @@ static int mana_dealloc_queues(struct net_device *ndev)
*/
for (i = 0; i < apc->num_queues; i++) {
- txq = &apc->tx_qp[i].txq;
+ txq = &apc->tx_qp[i]->txq;
tsleep = 1000;
while (atomic_read(&txq->pending_sends) > 0 &&
time_before(jiffies, timeout)) {
@@ -3307,7 +3318,7 @@ static int mana_dealloc_queues(struct net_device *ndev)
}
for (i = 0; i < apc->num_queues; i++) {
- txq = &apc->tx_qp[i].txq;
+ txq = &apc->tx_qp[i]->txq;
while ((skb = skb_dequeue(&txq->pending_skbs))) {
mana_unmap_skb(skb, apc);
dev_kfree_skb_any(skb);
diff --git a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
index 6a4b42fe0944..04350973e19e 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
@@ -260,7 +260,7 @@ static void mana_get_ethtool_stats(struct net_device *ndev,
}
for (q = 0; q < num_queues; q++) {
- tx_stats = &apc->tx_qp[q].txq.stats;
+ tx_stats = &apc->tx_qp[q]->txq.stats;
do {
start = u64_stats_fetch_begin(&tx_stats->syncp);
diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h
index 8f721cd4e4a7..aa90a858c8e3 100644
--- a/include/net/mana/mana.h
+++ b/include/net/mana/mana.h
@@ -507,7 +507,7 @@ struct mana_port_context {
bool tx_shortform_allowed;
u16 tx_vp_offset;
- struct mana_tx_qp *tx_qp;
+ struct mana_tx_qp **tx_qp;
/* Indirection Table for RX & TX. The values are queue indexes */
u32 *indir_table;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 07/11] vfio: selftests: Allow drivers to specify required region size
From: Manuel Ebner @ 2026-05-02 8:33 UTC (permalink / raw)
To: Jason Gunthorpe, Alex Williamson, David Matlack, kvm,
Leon Romanovsky, linux-kselftest, linux-rdma, Mark Bloch, netdev,
Saeed Mahameed, Shuah Khan, Tariq Toukan
Cc: patches
In-Reply-To: <7-v1-dc5fa250ca1d+3213-mlx5st_jgg@nvidia.com>
Hi,
On Thu, 2026-04-30 at 21:08 -0300, Jason Gunthorpe wrote:
> Add a region_size field to struct vfio_pci_driver_ops so drivers can
> declare how much DMA-mapped region they need. The mlx5 driver will
> need ~18MB for firmware pages. Existing drivers leave region_size as
> 0 and get the current default of SZ_2M.
>
> Assisted-by: Claude:claude-opus-4.6
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> .../selftests/vfio/lib/include/libvfio/vfio_pci_driver.h | 3 +++
> tools/testing/selftests/vfio/vfio_pci_driver_test.c | 3 ++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git
> a/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_driver.h
> b/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_driver.h
> index e5ada209b1d102..fa172635632453 100644
> --- a/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_driver.h
> +++ b/tools/testing/selftests/vfio/lib/include/libvfio/vfio_pci_driver.h
> @@ -9,6 +9,9 @@ struct vfio_pci_device;
> struct vfio_pci_driver_ops {
> const char *name;
>
> + /* Minimum driver region size, 0 = default SZ_2M */
> + u64 region_size;
i guess i do not understand this comment, but that's no surprise
because i'm new to the kernel.
would one of my suggestions be better?
+ /* Minimum driver region size == 0 -> default = SZ_2M */
or
+ /* Minimum driver region size, default SZ_2M = 0 */
> [...]
Manuel
^ permalink raw reply
* Re: [PATCH net v3] ipv6: rpl: reserve mac_len headroom when recompressed SRH grows
From: Yuan Tan @ 2026-05-02 8:36 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: netdev, linux-kernel, David S. Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, stable
In-Reply-To: <2026042133-gout-unvented-1bd9@gregkh>
On Tue, Apr 21, 2026 at 6:16 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps
> the next segment into ipv6_hdr->daddr, recompresses, then pulls the old
> header and pushes the new one plus the IPv6 header back. The
> recompressed header can be larger than the received one when the swap
> reduces the common-prefix length the segments share with daddr (CmprI=0,
> CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).
>
> pskb_expand_head() was gated on segments_left == 0, so on earlier
> segments the push consumed unchecked headroom. Once skb_push() leaves
> fewer than skb->mac_len bytes in front of data,
> skb_mac_header_rebuild()'s call to:
>
> skb_set_mac_header(skb, -skb->mac_len);
>
> will store (data - head) - mac_len into the u16 mac_header field, which
> wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB
> past skb->head.
>
> A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two
> segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one
> pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv.
>
> Fix this by expanding the head whenever the remaining room is less than
> the push size plus mac_len, and request that much extra so the rebuilt
> MAC header fits afterwards.
>
> Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr")
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: David Ahern <dsahern@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Simon Horman <horms@kernel.org>
> Cc: stable <stable@kernel.org>
> Reported-by: Anthropic
> Assisted-by: gkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> v3: - skb_postpull_rcsum() should not be changed, it's chdr NOT hdr, ugh
> Link to v2: https://lore.kernel.org/r/2026042158-sediment-elliptic-a954@gregkh
>
> v2: - fixed up if statement to actually work properly, and test it
> against a working poc (poc will be sent separately)
> Reworded the changelog and the subject to make more sense
> Link to v1: https://lore.kernel.org/r/2026042024-cabbie-gills-9371@gregkh
>
> net/ipv6/exthdrs.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
> index 95558fd6f447..03cbce842c1a 100644
> --- a/net/ipv6/exthdrs.c
> +++ b/net/ipv6/exthdrs.c
> @@ -491,6 +491,7 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
> struct net *net = dev_net(skb->dev);
> struct inet6_dev *idev;
> struct ipv6hdr *oldhdr;
> + unsigned int chdr_len;
> unsigned char *buf;
> int accept_rpl_seg;
> int i, err;
> @@ -592,8 +593,10 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
> skb_pull(skb, ((hdr->hdrlen + 1) << 3));
> skb_postpull_rcsum(skb, oldhdr,
> sizeof(struct ipv6hdr) + ((hdr->hdrlen + 1) << 3));
> - if (unlikely(!hdr->segments_left)) {
> - if (pskb_expand_head(skb, sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3), 0,
> + chdr_len = sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3);
> + if (unlikely(!hdr->segments_left ||
> + skb_headroom(skb) < chdr_len + skb->mac_len)) {
> + if (pskb_expand_head(skb, chdr_len + skb->mac_len, 0,
> GFP_ATOMIC)) {
> __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_OUTDISCARDS);
> kfree_skb(skb);
> @@ -603,7 +606,7 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
>
> oldhdr = ipv6_hdr(skb);
> }
> - skb_push(skb, ((chdr->hdrlen + 1) << 3) + sizeof(struct ipv6hdr));
> + skb_push(skb, chdr_len);
> skb_reset_network_header(skb);
> skb_mac_header_rebuild(skb);
> skb_set_transport_header(skb, sizeof(struct ipv6hdr));
> --
> 2.53.0
>
I am happy to see this bug is finally fixed.
However, it seems the Reported-by tag does not include our credit.
We first submitted the security report and patch to
security@kernel.org on February 23, titled:
[SECURITY] IPv6/RPL: 14-byte controllable OOB write via SRH len
overflow + skb_mac_header_rebuild() u16 wraparound
[PATCH] ipv6: rpl: rebuild MAC+metadata safely when rewriting SRH
We have aslo followed up and resent the patch several times, CCing all
relevant maintainers.
Could our credit be added to the patch?
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Xin Liu <dstsmallbird@foxmail.com>
I noticed this patch has already been merged into the mainline. Maybe
it's too late to amend this patch. Is there any other way to document
our reporting credit in the official records? Maybe in the stable
backport?
This one is pretty important to us and we would appreciate it if our
reporting credit could be reflected.
^ permalink raw reply
* Re: [PATCH net v3] ipv6: rpl: reserve mac_len headroom when recompressed SRH grows
From: Greg Kroah-Hartman @ 2026-05-02 8:42 UTC (permalink / raw)
To: Yuan Tan
Cc: netdev, linux-kernel, David S. Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, stable
In-Reply-To: <CAPuPA7JS-yG_dYaPVjv9JiGOEXSpExXSQhsZaexUkr-WMeQHrw@mail.gmail.com>
On Sat, May 02, 2026 at 01:36:18AM -0700, Yuan Tan wrote:
> On Tue, Apr 21, 2026 at 6:16 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps
> > the next segment into ipv6_hdr->daddr, recompresses, then pulls the old
> > header and pushes the new one plus the IPv6 header back. The
> > recompressed header can be larger than the received one when the swap
> > reduces the common-prefix length the segments share with daddr (CmprI=0,
> > CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).
> >
> > pskb_expand_head() was gated on segments_left == 0, so on earlier
> > segments the push consumed unchecked headroom. Once skb_push() leaves
> > fewer than skb->mac_len bytes in front of data,
> > skb_mac_header_rebuild()'s call to:
> >
> > skb_set_mac_header(skb, -skb->mac_len);
> >
> > will store (data - head) - mac_len into the u16 mac_header field, which
> > wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB
> > past skb->head.
> >
> > A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two
> > segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one
> > pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv.
> >
> > Fix this by expanding the head whenever the remaining room is less than
> > the push size plus mac_len, and request that much extra so the rebuilt
> > MAC header fits afterwards.
> >
> > Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr")
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: David Ahern <dsahern@kernel.org>
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Jakub Kicinski <kuba@kernel.org>
> > Cc: Paolo Abeni <pabeni@redhat.com>
> > Cc: Simon Horman <horms@kernel.org>
> > Cc: stable <stable@kernel.org>
> > Reported-by: Anthropic
> > Assisted-by: gkh_clanker_t1000
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > v3: - skb_postpull_rcsum() should not be changed, it's chdr NOT hdr, ugh
> > Link to v2: https://lore.kernel.org/r/2026042158-sediment-elliptic-a954@gregkh
> >
> > v2: - fixed up if statement to actually work properly, and test it
> > against a working poc (poc will be sent separately)
> > Reworded the changelog and the subject to make more sense
> > Link to v1: https://lore.kernel.org/r/2026042024-cabbie-gills-9371@gregkh
> >
> > net/ipv6/exthdrs.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
> > index 95558fd6f447..03cbce842c1a 100644
> > --- a/net/ipv6/exthdrs.c
> > +++ b/net/ipv6/exthdrs.c
> > @@ -491,6 +491,7 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
> > struct net *net = dev_net(skb->dev);
> > struct inet6_dev *idev;
> > struct ipv6hdr *oldhdr;
> > + unsigned int chdr_len;
> > unsigned char *buf;
> > int accept_rpl_seg;
> > int i, err;
> > @@ -592,8 +593,10 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
> > skb_pull(skb, ((hdr->hdrlen + 1) << 3));
> > skb_postpull_rcsum(skb, oldhdr,
> > sizeof(struct ipv6hdr) + ((hdr->hdrlen + 1) << 3));
> > - if (unlikely(!hdr->segments_left)) {
> > - if (pskb_expand_head(skb, sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3), 0,
> > + chdr_len = sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3);
> > + if (unlikely(!hdr->segments_left ||
> > + skb_headroom(skb) < chdr_len + skb->mac_len)) {
> > + if (pskb_expand_head(skb, chdr_len + skb->mac_len, 0,
> > GFP_ATOMIC)) {
> > __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_OUTDISCARDS);
> > kfree_skb(skb);
> > @@ -603,7 +606,7 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb)
> >
> > oldhdr = ipv6_hdr(skb);
> > }
> > - skb_push(skb, ((chdr->hdrlen + 1) << 3) + sizeof(struct ipv6hdr));
> > + skb_push(skb, chdr_len);
> > skb_reset_network_header(skb);
> > skb_mac_header_rebuild(skb);
> > skb_set_transport_header(skb, sizeof(struct ipv6hdr));
> > --
> > 2.53.0
> >
>
> I am happy to see this bug is finally fixed.
>
> However, it seems the Reported-by tag does not include our credit.
>
> We first submitted the security report and patch to
> security@kernel.org on February 23, titled:
>
> [SECURITY] IPv6/RPL: 14-byte controllable OOB write via SRH len
> overflow + skb_mac_header_rebuild() u16 wraparound
>
> [PATCH] ipv6: rpl: rebuild MAC+metadata safely when rewriting SRH
>
> We have aslo followed up and resent the patch several times, CCing all
> relevant maintainers.
>
> Could our credit be added to the patch?
>
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Xin Liu <dstsmallbird@foxmail.com>
>
> I noticed this patch has already been merged into the mainline. Maybe
> it's too late to amend this patch. Is there any other way to document
> our reporting credit in the official records? Maybe in the stable
> backport?
Sorry, I made this patch based on a different report to me as is
documented in this patch, and did not notice that it was the same thing
as this one as I am drowning in reports.
This happens at times, and we can't rewrite public git history as that's
impossible to do, sorry about that. You have a public confirmation here
that yes, you did report this same issue, and yes, you did submit a
patch to resolve this, but it ended up being different from the one that
was accepted. Which again, happens all the time, it's just the nature
of development with a huge body of contributors.
thanks,
greg k-h
^ permalink raw reply
* Re: Re: [PATCH net-next v2 1/2] mv88e6xxx: Refactor 6352's serdes functions
From: Fidan Aliyeva @ 2026-05-02 9:25 UTC (permalink / raw)
To: andrew
Cc: olteanv, davem, edumazet, kuba, pabeni, netdev, linux-kernel,
thomas.eckerman.ext, fidan.aliyeva.ext
In-Reply-To: <8f2a1956-5cd9-4267-8035-b81024148a9d@lunn.ch>
> > I wanted to make those functions generic and not introduce new
> > functions other than 6321_serdes_get_lane. However, those functions
> > cannot be generalised the obvious way because they run with reg_lock
> > already taken which would cause deadlock in mv88e6352_serdes_get_lane function.
>
> Ah, the scratch register. None of the other serdes_get_lane() functions need to read a register. O.K.
>
> So we don't expect the scratch register to change at runtime do we?
>
> Nope, the value in it is read during reset. After that, it does not matter what happens to the pin, the value in the scratch register is fixed. So maybe read it during mv88e6xxx_setup_port() and store the value in struct mv88e6xxx_port?
Hi again. Thank you for your feedback. I can make the proposed change. But
I do not have the functional specification for 6352 to refer the change
to, neither do I have access to a 6352 to be able to test the change on.
Do you have the functional specification document of the switch, maybe?
Thanks,
Fidan.
^ permalink raw reply
* [PATCH net-next] net: phy: realtek: replace magic number with register bit macros
From: Aleksander Jan Bajkowski @ 2026-05-02 9:28 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, daniel,
vladimir.oltean, michael, olek2, ih, rmk+kernel, marek.vasut,
netdev, linux-kernel
Replace magic number with register bit macros. The description of the
RTL8211B interrupt register is obtained from publicly available
datasheet[1].
1. RTL8211B(L) Rev. 1.5 Datasheet
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
---
drivers/net/phy/realtek/realtek_main.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 79c867ef64da..9f2a0bc03728 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -40,7 +40,12 @@
RTL8201F_ISR_LINK)
#define RTL821x_INER 0x12
-#define RTL8211B_INER_INIT 0x6400
+#define RTL8211B_INER_SPEED BIT(14)
+#define RTL8211B_INER_DUPLEX BIT(13)
+#define RTL8211B_INER_LINK_STATUS BIT(10)
+#define RTL8211B_INER_INIT (RTL8211B_INER_SPEED | \
+ RTL8211B_INER_DUPLEX | \
+ RTL8211B_INER_LINK_STATUS)
#define RTL8211E_INER_LINK_STATUS BIT(10)
#define RTL8211F_INER_PME BIT(7)
#define RTL8211F_INER_LINK_STATUS BIT(4)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 09/11] vfio: selftests: Add mlx5 driver - HW init and command interface
From: Manuel Ebner @ 2026-05-02 9:35 UTC (permalink / raw)
To: Jason Gunthorpe, Alex Williamson, David Matlack, kvm,
Leon Romanovsky, linux-kselftest, linux-rdma, Mark Bloch, netdev,
Saeed Mahameed, Shuah Khan, Tariq Toukan
Cc: patches
In-Reply-To: <9-v1-dc5fa250ca1d+3213-mlx5st_jgg@nvidia.com>
Hi Jason,
i've gone through your patch, just some minor and some optional things.
On Thu, 2026-04-30 at 21:08 -0300, Jason Gunthorpe wrote:
> [...]
> diff --git a/tools/testing/selftests/vfio/lib/drivers/mlx5/mlx5.c
> b/tools/testing/selftests/vfio/lib/drivers/mlx5/mlx5.c
> new file mode 100644
> index 00000000000000..0ab941bad7a66c
> --- /dev/null
> +++ b/tools/testing/selftests/vfio/lib/drivers/mlx5/mlx5.c
> @@ -0,0 +1,1406 @@
> +// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
> +/*
> + * mlx5 VFIO selftest driver
> + *
> + * Programs mlx5 ConnectX VFs and PFs through the bare-metal command
> interface
> + * and RDMA Write self-loopback to perform DMA. Implements
Write -> write
else it feels like there is a new sentence
> + * (probe/init/remove) and plugs into the VFIO selftest framework.
> + */
> +#include <stdint.h>
> +#include <stdbool.h>
> +#include <string.h>
> +#include <time.h>
> +#include <sched.h>
> +#include <unistd.h>
> +#include <stdlib.h>
> +
> +#include <linux/errno.h>
> +#include <linux/io.h>
> +#include <linux/log2.h>
> +#include <linux/pci_regs.h>
sort álphabetically:
+#include <sched.h>
+#include <stdbool.h>
+#include <stdint.h>
+#include <stdlib.h>~
+#include <string.h>
+#include <time.h>
+#include <unistd.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/log2.h>
+#include <linux/pci_regs.h>
> +
> +#include <libvfio.h>
> +
> +#include "mlx5_hw.h"
why are these two lines grouped individually?
> +/* Forward declaration — cmd_exec polls events during command wait */
> +static void mlx5st_process_events(struct mlx5st_device *dev);
> +
> +static const char *mlx5st_cmd_name(u16 opcode)
> +{
> + switch (opcode) {
> + case MLX5_CMD_OP_QUERY_HCA_CAP: return "QUERY_HCA_CAP";
> + case MLX5_CMD_OP_INIT_HCA: return "INIT_HCA";
> + case MLX5_CMD_OP_TEARDOWN_HCA: return "TEARDOWN_HCA";
> + case MLX5_CMD_OP_ENABLE_HCA: return "ENABLE_HCA";
> + case MLX5_CMD_OP_DISABLE_HCA: return "DISABLE_HCA";
> + [...]
> + }
> +}
Maybe line them up like:
Depends on your taste.
+ switch (opcode) {
+ case MLX5_CMD_OP_QUERY_HCA_CAP: return "QUERY_HCA_CAP";
+ case MLX5_CMD_OP_INIT_HCA: return "INIT_HCA";
+ case MLX5_CMD_OP_TEARDOWN_HCA: return "TEARDOWN_HCA";
+ case MLX5_CMD_OP_ENABLE_HCA: return "ENABLE_HCA";
+ case MLX5_CMD_OP_DISABLE_HCA: return "DISABLE_HCA";
+ case MLX5_CMD_OP_QUERY_PAGES: return "QUERY_PAGES";
+ [...]
> +
> + /*
> + * Compute signatures: mailbox blocks first, then cmd_queue_entry
> last.
> + * The sig must cover the final state including ownership=0x1, but
> + * we must not set ownership until after the sig is in place —
> + * XOR in the 0x1 without storing it to memory.
> + */
- " last"
+ /*
+ * Compute signatures: mailbox blocks first, then cmd_queue_entry.
Thanks
Manuel
^ permalink raw reply
* Re: [PATCH net] net: eth: fbnic: Fix addr validation in pcs write
From: Mike Marciniszyn @ 2026-05-02 9:45 UTC (permalink / raw)
To: Simon Horman
Cc: Alexander Duyck, Jakub Kicinski, kernel-team, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, netdev, linux-kernel,
stable
In-Reply-To: <20260501134636.GE15617@horms.kernel.org>
On Fri, May 01, 2026 at 02:46:36PM +0100, Simon Horman wrote:
> On Wed, Apr 29, 2026 at 11:00:49AM -0400, mike.marciniszyn@gmail.com wrote:
> > From: "Mike Marciniszyn (Meta)" <mike.marciniszyn@gmail.com>
> >
> > This patch contains a fix for addr validation in fbnic_mdio_write_pcs().
>
> Hi Mike,
>
> I think this warrants a bit more explanation: Why should addr 2 be
> accepted? What happens from a user-perspective when it is not?
>
The DW IP part has two distinct PCS address ranges cooresponding
to the C45 PCS registers.
The shim translates the PCS mmd/addr/regno into specific CSR writes
to one of two zero-relative addr values into one of those two
ranges.
This patch fixes a one off in the test that could allow an invalid
CSR write if an addr == 2 was called.
I can update the commit message to reflect the above?
Mike
^ permalink raw reply
* [PATCH net v6] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Daniel Golle @ 2026-05-02 10:55 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Russell King,
Christian Marangi, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
The .get_stats64 callback runs in atomic context, but on
MDIO-connected switches every register read acquires the MDIO bus
mutex, which can sleep:
[ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
[ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
[ 12.663377] preempt_count: 0, expected: 0
[ 12.667410] RCU nest depth: 1, expected: 0
[ 12.671511] INFO: lockdep is turned off.
[ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
[ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
[ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
[ 12.675459] Call trace:
[ 12.675462] show_stack+0x14/0x1c (C)
[ 12.675477] dump_stack_lvl+0x68/0x8c
[ 12.675487] dump_stack+0x14/0x1c
[ 12.675495] __might_resched+0x14c/0x220
[ 12.675504] __might_sleep+0x44/0x80
[ 12.675511] __mutex_lock+0x50/0xb10
[ 12.675523] mutex_lock_nested+0x20/0x30
[ 12.675532] mt7530_get_stats64+0x40/0x2ac
[ 12.675542] dsa_user_get_stats64+0x2c/0x40
[ 12.675553] dev_get_stats+0x44/0x1e0
[ 12.675564] dev_seq_printf_stats+0x24/0xe0
[ 12.675575] dev_seq_show+0x14/0x3c
[ 12.675583] seq_read_iter+0x37c/0x480
[ 12.675595] seq_read+0xd0/0xec
[ 12.675605] proc_reg_read+0x94/0xe4
[ 12.675615] vfs_read+0x98/0x29c
[ 12.675625] ksys_read+0x54/0xdc
[ 12.675633] __arm64_sys_read+0x18/0x20
[ 12.675642] invoke_syscall.constprop.0+0x54/0xec
[ 12.675653] do_el0_svc+0x3c/0xb4
[ 12.675662] el0_svc+0x38/0x200
[ 12.675670] el0t_64_sync_handler+0x98/0xdc
[ 12.675679] el0t_64_sync+0x158/0x15c
For MDIO-connected switches, poll MIB counters asynchronously using a
delayed workqueue every second and let .get_stats64 return the cached
values under a spinlock. A mod_delayed_work() call on each read
triggers an immediate refresh so counters stay responsive when queried
more frequently.
MMIO-connected switches (MT7988, EN7581, AN7583) are not affected
because their regmap does not sleep, so they continue to read MIB
counters directly in .get_stats64.
Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
v6:
* reintroduce .teardown() for cancel_delayed_work_sync(), drop
cancel_delayed_work_sync() from .remove()
v5:
* spin_lock_init() and INIT_DELAYED_WORK() in probe()
* drop teardown as cancel_delayed_work_sync() in remove() is
sufficient and now symmetric with init happening in probe()
v4:
* extract mt7530_stats_refresh() helper from mt7530_stats_poll()
-> mt7530_stats_poll() now just refreshes and re-arms
* call helper synchronously in mt753x_setup() to seed the cache
* avoid zeroed counters during the first poll interval
* avoid INITIAL_JIFFIES vs stats_last==0 wraparound on 32-bit
* swap deprecated system_wq for system_percpu_wq in get_stats64
* keeps on-demand refresh on the same queue as schedule_*_work
v3:
* move `stats_last` access under the spinlock to avoid potential race
v2:
* use spin_lock_bh()/spin_unlock_bh() to prevent potential deadlock
* rate-limit mod_delayed_work() refresh to at most once per 100ms
* move cancel_delayed_work_sync() after dsa_unregister_switch()
* add mt753x_teardown() callback to cancel the stats work
* fix commit message
drivers/net/dsa/mt7530.c | 75 ++++++++++++++++++++++++++++++++++++++--
drivers/net/dsa/mt7530.h | 8 +++++
2 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index b9423389c2ef..44d670904ad8 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -25,6 +25,9 @@
#include "mt7530.h"
+#define MT7530_STATS_POLL_INTERVAL (1 * HZ)
+#define MT7530_STATS_RATE_LIMIT (HZ / 10)
+
static struct mt753x_pcs *pcs_to_mt753x_pcs(struct phylink_pcs *pcs)
{
return container_of(pcs, struct mt753x_pcs, pcs);
@@ -906,10 +909,9 @@ static void mt7530_get_rmon_stats(struct dsa_switch *ds, int port,
*ranges = mt7530_rmon_ranges;
}
-static void mt7530_get_stats64(struct dsa_switch *ds, int port,
- struct rtnl_link_stats64 *storage)
+static void mt7530_read_port_stats64(struct mt7530_priv *priv, int port,
+ struct rtnl_link_stats64 *storage)
{
- struct mt7530_priv *priv = ds->priv;
uint64_t data;
/* MIB counter doesn't provide a FramesTransmittedOK but instead
@@ -951,6 +953,54 @@ static void mt7530_get_stats64(struct dsa_switch *ds, int port,
&storage->rx_crc_errors);
}
+static void mt7530_stats_refresh(struct mt7530_priv *priv)
+{
+ struct rtnl_link_stats64 stats = {};
+ struct dsa_port *dp;
+ int port;
+
+ dsa_switch_for_each_user_port(dp, priv->ds) {
+ port = dp->index;
+
+ mt7530_read_port_stats64(priv, port, &stats);
+
+ spin_lock_bh(&priv->stats_lock);
+ priv->ports[port].stats = stats;
+ priv->stats_last = jiffies;
+ spin_unlock_bh(&priv->stats_lock);
+ }
+}
+
+static void mt7530_stats_poll(struct work_struct *work)
+{
+ struct mt7530_priv *priv = container_of(work, struct mt7530_priv,
+ stats_work.work);
+
+ mt7530_stats_refresh(priv);
+ schedule_delayed_work(&priv->stats_work,
+ MT7530_STATS_POLL_INTERVAL);
+}
+
+static void mt7530_get_stats64(struct dsa_switch *ds, int port,
+ struct rtnl_link_stats64 *storage)
+{
+ struct mt7530_priv *priv = ds->priv;
+ bool refresh;
+
+ if (priv->bus) {
+ spin_lock_bh(&priv->stats_lock);
+ *storage = priv->ports[port].stats;
+ refresh = time_after(jiffies, priv->stats_last +
+ MT7530_STATS_RATE_LIMIT);
+ spin_unlock_bh(&priv->stats_lock);
+ if (refresh)
+ mod_delayed_work(system_percpu_wq,
+ &priv->stats_work, 0);
+ } else {
+ mt7530_read_port_stats64(priv, port, storage);
+ }
+}
+
static void mt7530_get_eth_ctrl_stats(struct dsa_switch *ds, int port,
struct ethtool_eth_ctrl_stats *ctrl_stats)
{
@@ -3137,9 +3187,24 @@ mt753x_setup(struct dsa_switch *ds)
if (ret && priv->irq_domain)
mt7530_free_mdio_irq(priv);
+ if (!ret && priv->bus) {
+ mt7530_stats_refresh(priv);
+ schedule_delayed_work(&priv->stats_work,
+ MT7530_STATS_POLL_INTERVAL);
+ }
+
return ret;
}
+static void
+mt753x_teardown(struct dsa_switch *ds)
+{
+ struct mt7530_priv *priv = ds->priv;
+
+ if (priv->bus)
+ cancel_delayed_work_sync(&priv->stats_work);
+}
+
static int mt753x_set_mac_eee(struct dsa_switch *ds, int port,
struct ethtool_keee *e)
{
@@ -3257,6 +3322,7 @@ static int mt7988_setup(struct dsa_switch *ds)
static const struct dsa_switch_ops mt7530_switch_ops = {
.get_tag_protocol = mtk_get_tag_protocol,
.setup = mt753x_setup,
+ .teardown = mt753x_teardown,
.preferred_default_local_cpu_port = mt753x_preferred_default_local_cpu_port,
.get_strings = mt7530_get_strings,
.get_ethtool_stats = mt7530_get_ethtool_stats,
@@ -3395,6 +3461,9 @@ mt7530_probe_common(struct mt7530_priv *priv)
priv->ds->ops = &mt7530_switch_ops;
priv->ds->phylink_mac_ops = &mt753x_phylink_mac_ops;
mutex_init(&priv->reg_mutex);
+ spin_lock_init(&priv->stats_lock);
+ INIT_DELAYED_WORK(&priv->stats_work, mt7530_stats_poll);
+
dev_set_drvdata(dev, priv);
return 0;
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 3e0090bed298..dd33b0df3419 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -796,6 +796,7 @@ struct mt7530_fdb {
* @pvid: The VLAN specified is to be considered a PVID at ingress. Any
* untagged frames will be assigned to the related VLAN.
* @sgmii_pcs: Pointer to PCS instance for SerDes ports
+ * @stats: Cached port statistics for MDIO-connected switches
*/
struct mt7530_port {
bool enable;
@@ -803,6 +804,7 @@ struct mt7530_port {
u32 pm;
u16 pvid;
struct phylink_pcs *sgmii_pcs;
+ struct rtnl_link_stats64 stats;
};
/* Port 5 mode definitions of the MT7530 switch */
@@ -875,6 +877,9 @@ struct mt753x_info {
* @create_sgmii: Pointer to function creating SGMII PCS instance(s)
* @active_cpu_ports: Holding the active CPU ports
* @mdiodev: The pointer to the MDIO device structure
+ * @stats_lock: Protects cached per-port stats from concurrent access
+ * @stats_work: Delayed work for polling MIB counters on MDIO switches
+ * @stats_last: Jiffies timestamp of last MIB counter poll
*/
struct mt7530_priv {
struct device *dev;
@@ -900,6 +905,9 @@ struct mt7530_priv {
int (*create_sgmii)(struct mt7530_priv *priv);
u8 active_cpu_ports;
struct mdio_device *mdiodev;
+ spinlock_t stats_lock; /* protects cached stats counters */
+ struct delayed_work stats_work;
+ unsigned long stats_last;
};
struct mt7530_hw_vlan_entry {
--
2.53.0
^ permalink raw reply related
* [PATCH] Documentation: Fix duplicated words
From: Wang Zihan @ 2026-05-02 11:19 UTC (permalink / raw)
To: netdev, linux-doc, linux-media, linux-um
Cc: davem, edumazet, kuba, pabeni, horms, corbet, skhan, mchehab,
richard, anton.ivanov, johannes, linux-kernel, Wang Zihan
Remove duplicated words in three documentation files:
- "in in" -> "in" (switchdev.rst)
- "The the" -> "The" (dmx-reqbufs.rst)
- "on on" -> "on" (user_mode_linux_howto_v2.rst)
Signed-off-by: Wang Zihan <3772548978@qq.com>
---
Documentation/networking/switchdev.rst | 2 +-
Documentation/userspace-api/media/dvb/dmx-reqbufs.rst | 2 +-
Documentation/virt/uml/user_mode_linux_howto_v2.rst | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst
index 2966b7122..948bce44c 100644
--- a/Documentation/networking/switchdev.rst
+++ b/Documentation/networking/switchdev.rst
@@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
bond will see its upper master change. If that bond is moved into a bridge,
the bond's upper master will change. And so on. The driver will track such
-movements to know what position a port is in in the overall topology by
+movements to know what position a port is in the overall topology by
registering for netdevice events and acting on NETDEV_CHANGEUPPER.
L2 Forwarding Offload
diff --git a/Documentation/userspace-api/media/dvb/dmx-reqbufs.rst b/Documentation/userspace-api/media/dvb/dmx-reqbufs.rst
index d2bb1909e..18810f0bb 100644
--- a/Documentation/userspace-api/media/dvb/dmx-reqbufs.rst
+++ b/Documentation/userspace-api/media/dvb/dmx-reqbufs.rst
@@ -72,4 +72,4 @@ appropriately. The generic error codes are described at the
:ref:`Generic Error Codes <gen-errors>` chapter.
EOPNOTSUPP
- The the requested I/O method is not supported.
+ The requested I/O method is not supported.
diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
index c37e8e594..7b08738c3 100644
--- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst
+++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
@@ -1092,7 +1092,7 @@ be formatted as plain text.
Developing always goes hand in hand with debugging. First of all,
you can always run UML under gdb and there will be a whole section
-later on on how to do that. That, however, is not the only way to
+later on how to do that. That, however, is not the only way to
debug a Linux kernel. Quite often adding tracing statements and/or
using UML specific approaches such as ptracing the UML kernel process
are significantly more informative.
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] net: switchdev: fix duplicate word in documentation
From: Björn Persson @ 2026-05-02 11:24 UTC (permalink / raw)
To: Wang Zihan; +Cc: netdev, linux-doc, kuba
In-Reply-To: <tencent_93F8CA2FB714A80C571AC978F39E51D6E506@qq.com>
[-- Attachment #1: Type: text/plain, Size: 879 bytes --]
Wang Zihan wrote:
> @@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
> monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
> bond will see its upper master change. If that bond is moved into a bridge,
> the bond's upper master will change. And so on. The driver will track such
> -movements to know what position a port is in in the overall topology by
> +movements to know what position a port is in the overall topology by
> registering for netdevice events and acting on NETDEV_CHANGEUPPER.
>
> L2 Forwarding Offload
This change claims that a port is a position. The preceding sentences,
talking about "a particular port's position" and a port being moved,
make it clear that a port is *in* a position *in* the topology. The
port is not itself a position.
Björn Persson
[-- Attachment #2: OpenPGP digital signatur --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: Fix duplicated words
From: Björn Persson @ 2026-05-02 12:01 UTC (permalink / raw)
To: Wang Zihan
Cc: davem, edumazet, kuba, pabeni, horms, corbet, skhan, mchehab,
richard, anton.ivanov, johannes, linux-kernel, netdev, linux-doc,
linux-media, linux-um
In-Reply-To: <tencent_B1D6CBBF95486E31D04C2E1B92F5E605A307@qq.com>
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
Wang Zihan wrote:
> you can always run UML under gdb and there will be a whole section
> -later on on how to do that. That, however, is not the only way to
> +later on how to do that. That, however, is not the only way to
"Later on" is an established English expression. A plain "later" also
works. This isn't a correction of an error; it's a stylistic change.
Björn Persson
[-- Attachment #2: OpenPGP digital signatur --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] selftests: net: fib_nexthops: detect kernel splats from torture tests
From: Vastargazing @ 2026-05-02 12:22 UTC (permalink / raw)
To: netdev, linux-kselftest
Cc: David Ahern, Ido Schimmel, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Shuah Khan,
linux-kernel, Vastargazing
The four nexthop torture subtests delete and re-add a group member
while ping -f and mausezahn keep traffic flowing through the same
group, so on each iteration the read side runs nh_grp_entry_stats_inc()
while the write side goes through remove_nh_grp_entry(). That is the
exact race fixed in commit b2662e7593e9 ("net: nexthop: fix percpu
use-after-free in remove_nh_grp_entry").
The reason it never tripped these tests is the assertion. Each subtest
ends with "if we did not crash, success", so a KASAN splat without
panic_on_warn=1 lands in dmesg and the test still prints [OK]. The UAF
above would have been visible to a KASAN run of fib_nexthops.sh; the
torture loop just did not bother to look.
Drop a marker into /dev/kmsg before each torture subtest, grep for
KASAN/UBSAN/KCSAN/KFENCE/Oops/"kernel BUG at" lines once the load is
killed, and fail the subtest with the offending lines printed if any
match. The check is skipped when /dev/kmsg is not writable so the
existing pass behaviour is preserved on restricted setups. No new
TEST_PROGS, no new test mechanism, just close the assertion gap.
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Vastargazing <vebohr@gmail.com>
---
tools/testing/selftests/net/fib_nexthops.sh | 69 ++++++++++++++++++---
1 file changed, 61 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
index ac868a731694..41c8767fc310 100755
--- a/tools/testing/selftests/net/fib_nexthops.sh
+++ b/tools/testing/selftests/net/fib_nexthops.sh
@@ -128,6 +128,47 @@ run_cmd()
return $rc
}
+# Helpers used by the *_torture subtests below. The torture loops drive
+# concurrent nexthop updates and packet flood, but until now they only
+# checked "did the kernel crash". A KASAN/UBSAN report without
+# panic_on_warn=1 lands in dmesg and is silently ignored. These helpers
+# place a marker into /dev/kmsg before the load starts and grep for
+# splat lines after it stops. If /dev/kmsg is not writable the check
+# is skipped and the previous pass behaviour is kept.
+torture_dmesg_marker=""
+
+torture_dmesg_baseline()
+{
+ torture_dmesg_marker=""
+ [ -w /dev/kmsg ] || return 0
+
+ torture_dmesg_marker="fib_nexthops-torture-$$-$RANDOM"
+ echo "$torture_dmesg_marker" >/dev/kmsg
+}
+
+torture_dmesg_check()
+{
+ local since
+ local found
+
+ [ -z "$torture_dmesg_marker" ] && return 0
+
+ since=$(dmesg 2>/dev/null | \
+ awk -v m="$torture_dmesg_marker" '
+ $0 ~ m { f = 1; next }
+ f { print }
+ ')
+
+ found=$(echo "$since" | grep -E \
+ 'KASAN:|UBSAN:|KCSAN:|KFENCE:|Oops:|kernel BUG at|general protection fault')
+
+ [ -z "$found" ] && return 0
+
+ echo " Kernel splat detected during torture run:"
+ echo "$found" | sed 's/^/ /'
+ return 1
+}
+
get_linklocal()
{
local dev=$1
@@ -1333,6 +1374,8 @@ ipv6_torture()
run_cmd "$IP route add 2001:db8:101::1 nhid 102"
run_cmd "$IP route add 2001:db8:101::2 nhid 102"
+ torture_dmesg_baseline
+
ipv6_del_add_loop1 &
pid1=$!
ipv6_grp_replace_loop &
@@ -1348,8 +1391,9 @@ ipv6_torture()
kill -9 $pid1 $pid2 $pid3 $pid4 $pid5
wait $pid1 $pid2 $pid3 $pid4 $pid5 2>/dev/null
- # if we did not crash, success
- log_test 0 0 "IPv6 torture test"
+ # Pass only if we did not crash AND no kernel splat appeared.
+ torture_dmesg_check
+ log_test $? 0 "IPv6 torture test"
}
ipv6_res_grp_replace_loop()
@@ -1387,6 +1431,8 @@ ipv6_res_torture()
run_cmd "$IP route add 2001:db8:101::1 nhid 102"
run_cmd "$IP route add 2001:db8:101::2 nhid 102"
+ torture_dmesg_baseline
+
ipv6_del_add_loop1 &
pid1=$!
ipv6_res_grp_replace_loop &
@@ -1404,8 +1450,9 @@ ipv6_res_torture()
kill -9 $pid1 $pid2 $pid3 $pid4 $pid5
wait $pid1 $pid2 $pid3 $pid4 $pid5 2>/dev/null
- # if we did not crash, success
- log_test 0 0 "IPv6 resilient nexthop group torture test"
+ # Pass only if we did not crash AND no kernel splat appeared.
+ torture_dmesg_check
+ log_test $? 0 "IPv6 resilient nexthop group torture test"
}
ipv4_fcnal()
@@ -2123,6 +2170,8 @@ ipv4_torture()
run_cmd "$IP route add 172.16.101.1 nhid 102"
run_cmd "$IP route add 172.16.101.2 nhid 102"
+ torture_dmesg_baseline
+
ipv4_del_add_loop1 &
pid1=$!
ipv4_grp_replace_loop &
@@ -2138,8 +2187,9 @@ ipv4_torture()
kill -9 $pid1 $pid2 $pid3 $pid4 $pid5
wait $pid1 $pid2 $pid3 $pid4 $pid5 2>/dev/null
- # if we did not crash, success
- log_test 0 0 "IPv4 torture test"
+ # Pass only if we did not crash AND no kernel splat appeared.
+ torture_dmesg_check
+ log_test $? 0 "IPv4 torture test"
}
ipv4_res_grp_replace_loop()
@@ -2177,6 +2227,8 @@ ipv4_res_torture()
run_cmd "$IP route add 172.16.101.1 nhid 102"
run_cmd "$IP route add 172.16.101.2 nhid 102"
+ torture_dmesg_baseline
+
ipv4_del_add_loop1 &
pid1=$!
ipv4_res_grp_replace_loop &
@@ -2194,8 +2246,9 @@ ipv4_res_torture()
kill -9 $pid1 $pid2 $pid3 $pid4 $pid5
wait $pid1 $pid2 $pid3 $pid4 $pid5 2>/dev/null
- # if we did not crash, success
- log_test 0 0 "IPv4 resilient nexthop group torture test"
+ # Pass only if we did not crash AND no kernel splat appeared.
+ torture_dmesg_check
+ log_test $? 0 "IPv4 resilient nexthop group torture test"
}
basic()
--
2.51.0
^ permalink raw reply related
* [syzbot] Monthly wireless report (May 2026)
From: syzbot @ 2026-05-02 12:32 UTC (permalink / raw)
To: linux-kernel, linux-wireless, netdev, syzkaller-bugs
Hello wireless maintainers/developers,
This is a 31-day syzbot report for the wireless subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/wireless
During the period, 2 new issues were detected and 0 were fixed.
In total, 47 issues are still open and 174 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 28976 Yes WARNING in rate_control_rate_init (3)
https://syzkaller.appspot.com/bug?extid=9bdc0c5998ab45b05030
<2> 18964 No WARNING in kcov_remote_start (6)
https://syzkaller.appspot.com/bug?extid=3f51ad7ac3ae57a6fdcc
<3> 10661 Yes WARNING in __rate_control_send_low (3)
https://syzkaller.appspot.com/bug?extid=34463a129786910405dd
<4> 6955 Yes WARNING in __cfg80211_ibss_joined (2)
https://syzkaller.appspot.com/bug?extid=7f064ba1704c2466e36d
<5> 1227 Yes WARNING in ieee80211_start_next_roc
https://syzkaller.appspot.com/bug?extid=c3a167b5615df4ccd7fb
<6> 1049 Yes INFO: task hung in reg_process_self_managed_hints
https://syzkaller.appspot.com/bug?extid=1f16507d9ec05f64210a
<7> 903 Yes INFO: task hung in reg_check_chans_work (7)
https://syzkaller.appspot.com/bug?extid=a2de4763f84f61499210
<8> 827 Yes INFO: rcu detected stall in ieee80211_handle_queued_frames
https://syzkaller.appspot.com/bug?extid=1c991592da3ef18957c0
<9> 624 Yes INFO: task hung in crda_timeout_work (8)
https://syzkaller.appspot.com/bug?extid=d41f74db64598e0b5016
<10> 382 Yes WARNING in ieee80211_tx_skb_tid
https://syzkaller.appspot.com/bug?extid=8bd4574e8c52c48c2595
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
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