* Re: [PATCH 2/4] tools: ynl-gen-c: optionally emit structs and helpers
From: Jakub Kicinski @ 2026-04-14 15:35 UTC (permalink / raw)
To: Christoph Böhmwalder
Cc: Jens Axboe, drbd-dev, linux-kernel, Lars Ellenberg,
Philipp Reisner, linux-block, Donald Hunter, Eric Dumazet, netdev
In-Reply-To: <ad4ox7ibZoiW-tje@localhost.localdomain>
On Tue, 14 Apr 2026 14:08:58 +0200 Christoph Böhmwalder wrote:
> But we still need to support the current family via a compat path, and
> I would much rather have two YNL-based families than one genl_magic and
> one YNL-based. Carrying both sounds like a nightmare.
>
> So the spec proposed in this series would never actually be used to
> generate a userspace client, if that's what you're asking. We would
> continue to use the current libgenl-based approach, with some userspace
> compat shims to make it work with YNL. Then, when "drbd2" comes along,
> we could "do things properly".
Let's jump to the drbd2 work.
^ permalink raw reply
* Re: [PATCH net v2 3/4] net: mana: Don't overwrite port probe error with add_adev result
From: Simon Horman @ 2026-04-14 15:35 UTC (permalink / raw)
To: ernis
Cc: 'Simon Horman', kys, haiyangz, wei.liu, decui, longli,
andrew+netdev, davem, edumazet, kuba, pabeni, ssengar, dipayanroy,
gargaditya, shirazsaleem, kees, kotaranov, leon, shacharr,
stephen, linux-hyperv, netdev, linux-kernel
In-Reply-To: <20260413050843.605789-4-ernis@linux.microsoft.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
net: mana: Don't overwrite port probe error with add_adev result
This commit ensures that if mana_probe_port() or mana_attach() fails, the
error is not overwritten by the result of add_adev(). By preserving the
error, it triggers mana_remove() cleanup instead of leaving ports partially
initialized.
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> index 9d095a6fb56c7..4d42cbfb3f15b 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> @@ -3634,10 +3634,9 @@ int mana_probe(struct gdma_dev *gd, bool resuming)
> if (!resuming) {
> for (i = 0; i < ac->num_ports; i++) {
> err = mana_probe_port(ac, i, &ac->ports[i]);
> - /* we log the port for which the probe failed and stop
> - * probes for subsequent ports.
> - * Note that we keep running ports, for which the probes
> - * were successful, unless add_adev fails too
> + /* Log the port for which the probe failed, stop probing
> + * subsequent ports, and skip add_adev.
> + * Already-probed ports remain functional.
> */
Are these comments accurate regarding ports remaining functional?
Since this patch preserves the error code, execution falls through to the end
of mana_probe() where it checks if err is set and calls mana_remove().
mana_remove() will iterate over the successfully allocated ports, completely
detach them, unregister their net_devices, and destroy event queues.
It appears no ports remain functional because the device is completely torn
down.
[ ... ]
> @@ -3651,10 +3650,9 @@ int mana_probe(struct gdma_dev *gd, bool resuming)
> enable_work(&apc->queue_reset_work);
> err = mana_attach(ac->ports[i]);
> rtnl_unlock();
> - /* we log the port for which the attach failed and stop
> - * attach for subsequent ports
> - * Note that we keep running ports, for which the attach
> - * were successful, unless add_adev fails too
> + /* Log the port for which the attach failed, stop
> + * attaching subsequent ports, and skip add_adev.
> + * Already-attached ports remain functional.
> */
> if (err) {
> dev_err(dev, "Attach Failed for port %d\n", i);
> @@ -3663,7 +3661,8 @@ int mana_probe(struct gdma_dev *gd, bool resuming)
Does propagating this error during PM resume introduce a NULL pointer
dereference?
If PM resume fails here (resuming == true), the preserved error code causes
mana_probe() to call mana_remove(), which tears down the device and sets
gd->gdma_context = NULL.
However, a failed resume callback does not automatically unbind the driver.
When the device is eventually unbound later, mana_remove() is invoked again:
drivers/net/ethernet/microsoft/mana/mana_en.c:mana_remove() {
struct gdma_context *gc = gd->gdma_context;
struct device *dev = gc->dev;
...
}
In the second invocation, gd->gdma_context is NULL, meaning gc is NULL,
which could lead to a kernel panic when dereferencing gc->dev.
^ permalink raw reply
* Re: [PATCH bpf] bpf,tcp: avoid infinite recursion in BPF_SOCK_OPS_HDR_OPT_LEN_CB
From: mkf @ 2026-04-14 15:37 UTC (permalink / raw)
To: Jiayuan Chen, bpf
Cc: Quan Sun, Yinhao Hu, Kaiyan Mei, Dongliang Mu, Eric Dumazet,
Neal Cardwell, Kuniyuki Iwashima, David S. Miller, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
David Ahern, netdev, linux-doc, linux-kernel
In-Reply-To: <20260414105702.248310-1-jiayuan.chen@linux.dev>
On Tue, 2026-04-14 at 18:57 +0800, Jiayuan Chen wrote:
> A BPF_PROG_TYPE_SOCK_OPS program can set BPF_SOCK_OPS_WRITE_HDR_OPT_CB_FLAG
> to inject custom TCP header options. When the kernel builds a TCP packet,
> it calls tcp_established_options() to calculate the header size, which
> invokes bpf_skops_hdr_opt_len() to trigger the BPF_SOCK_OPS_HDR_OPT_LEN_CB
> callback.
>
> If the BPF program calls bpf_setsockopt(TCP_NODELAY) inside this callback,
> __tcp_sock_set_nodelay() will call tcp_push_pending_frames(), which calls
> tcp_current_mss(), which calls tcp_established_options() again,
> re-triggering the same BPF callback. This creates an infinite recursion
> that exhausts the kernel stack and causes a panic.
>
> BPF_SOCK_OPS_HDR_OPT_LEN_CB
> -> bpf_setsockopt(TCP_NODELAY)
> -> tcp_push_pending_frames()
> -> tcp_current_mss()
> -> tcp_established_options()
> -> bpf_skops_hdr_opt_len()
> /* infinite recursion */
> -> BPF_SOCK_OPS_HDR_OPT_LEN_CB
>
> A similar reentrancy issue exists for TCP congestion control, which is
> guarded by tp->bpf_chg_cc_inprogress. Adopt the same approach: introduce
> tp->bpf_hdr_opt_len_cb_inprogress, set it before invoking the callback in
> bpf_skops_hdr_opt_len(), and check it in sol_tcp_sockopt() to reject
> bpf_setsockopt(TCP_NODELAY) calls that would trigger
> tcp_push_pending_frames() and cause the recursion.
>
> Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn>
> Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
> Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
> Reported-by: Dongliang Mu <dzm91@hust.edu.cn>
> Closes: https://lore.kernel.org/bpf/d1d523c9-6901-4454-a183-94462b8f3e4e@std.uestc.edu.cn/
> Fixes: 0813a841566f ("bpf: tcp: Allow bpf prog to write and parse TCP header option")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
> Documentation/networking/net_cachelines/tcp_sock.rst | 1 +
> include/linux/tcp.h | 11 ++++++++++-
> net/core/filter.c | 4 ++++
> net/ipv4/tcp_minisocks.c | 1 +
> net/ipv4/tcp_output.c | 3 +++
> 5 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/networking/net_cachelines/tcp_sock.rst
> b/Documentation/networking/net_cachelines/tcp_sock.rst
> index 563daea10d6c..07d3226d90cc 100644
> --- a/Documentation/networking/net_cachelines/tcp_sock.rst
> +++ b/Documentation/networking/net_cachelines/tcp_sock.rst
> @@ -152,6 +152,7 @@ unsigned_int keepalive_intvl
> int linger2
> u8 bpf_sock_ops_cb_flags
> u8:1 bpf_chg_cc_inprogress
> +u8:1 bpf_hdr_opt_len_cb_inprogress
> u16 timeout_rehash
> u32 rcv_ooopack
> u32 rcv_rtt_last_tsecr
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index f72eef31fa23..2bfb73cf922e 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -475,12 +475,21 @@ struct tcp_sock {
> u8 bpf_sock_ops_cb_flags; /* Control calling BPF programs
> * values defined in uapi/linux/tcp.h
> */
> - u8 bpf_chg_cc_inprogress:1; /* In the middle of
> + u8 bpf_chg_cc_inprogress:1, /* In the middle of
> * bpf_setsockopt(TCP_CONGESTION),
> * it is to avoid the bpf_tcp_cc->init()
> * to recur itself by calling
> * bpf_setsockopt(TCP_CONGESTION, "itself").
> */
> + bpf_hdr_opt_len_cb_inprogress:1; /* It is set before invoking the
> + * callback so that a nested
> + * bpf_setsockopt(TCP_NODELAY) or
> + * bpf_setsockopt(TCP_CORK) cannot
> + * trigger tcp_push_pending_frames(),
> + * which would call tcp_current_mss()
> + * -> bpf_skops_hdr_opt_len(), causing
> + * infinite recursion.
> + */
> #define BPF_SOCK_OPS_TEST_FLAG(TP, ARG) (TP->bpf_sock_ops_cb_flags & ARG)
> #else
> #define BPF_SOCK_OPS_TEST_FLAG(TP, ARG) 0
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 78b548158fb0..518699429a7a 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5483,6 +5483,10 @@ static int sol_tcp_sockopt(struct sock *sk, int optname,
> if (sk->sk_protocol != IPPROTO_TCP)
> return -EINVAL;
>
> + if ((optname == TCP_NODELAY || optname == TCP_CORK) &&
> + tcp_sk(sk)->bpf_hdr_opt_len_cb_inprogress)
> + return -EBUSY;
> +
TCP_CORK is not support in sol_tcp_sockopt(), return -EINVAL by default. and put the check here
could also prevent us from calling getsockopt(TCP_NODELAY) below.
> switch (optname) {
> case TCP_NODELAY:
> case TCP_MAXSEG:
> diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
> index dafb63b923d0..fb06c464ac16 100644
> --- a/net/ipv4/tcp_minisocks.c
> +++ b/net/ipv4/tcp_minisocks.c
> @@ -663,6 +663,7 @@ struct sock *tcp_create_openreq_child(const struct sock *sk,
> RCU_INIT_POINTER(newtp->fastopen_rsk, NULL);
>
> newtp->bpf_chg_cc_inprogress = 0;
> + newtp->bpf_hdr_opt_len_cb_inprogress = 0;
> tcp_bpf_clone(sk, newsk);
>
> __TCP_INC_STATS(sock_net(sk), TCP_MIB_PASSIVEOPENS);
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 326b58ff1118..c9654e690e1a 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -475,6 +475,7 @@ static void bpf_skops_hdr_opt_len(struct sock *sk, struct sk_buff *skb,
> unsigned int *remaining)
> {
> struct bpf_sock_ops_kern sock_ops;
> + struct tcp_sock *tp = tcp_sk(sk);
> int err;
>
> if (likely(!BPF_SOCK_OPS_TEST_FLAG(tcp_sk(sk),
> @@ -519,7 +520,9 @@ static void bpf_skops_hdr_opt_len(struct sock *sk, struct sk_buff *skb,
> if (skb)
> bpf_skops_init_skb(&sock_ops, skb, 0);
>
> + tp->bpf_hdr_opt_len_cb_inprogress = 1;
we check the BPF_SOCK_OPS_WRITE_HDR_OPT_CB_FLAG before calling BPF_CGROUP_RUN_PROG_SOCK_OPS_SK,
could this flag use for the same purpose? so we don't need to add an extra field.
if (likely(!BPF_SOCK_OPS_TEST_FLAG(tcp_sk(sk),
BPF_SOCK_OPS_WRITE_HDR_OPT_CB_FLAG)) ||
!*remaining)
return;
> err = BPF_CGROUP_RUN_PROG_SOCK_OPS_SK(&sock_ops, sk);
> + tp->bpf_hdr_opt_len_cb_inprogress = 0;
>
> if (err || sock_ops.remaining_opt_len == *remaining)
> return;
--
Thanks,
KaFai
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] net: phy: Fix phy_init_hw() placement and update locking
From: Jakub Kicinski @ 2026-04-14 15:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: Biju, Heiner Kallweit, David S. Miller, Eric Dumazet, Paolo Abeni,
Biju Das, Russell King, netdev, linux-kernel, Geert Uytterhoeven,
Prabhakar Mahadev Lad, linux-renesas-soc
In-Reply-To: <20260412140032.122841-1-biju.das.jz@bp.renesas.com>
On Sun, 12 Apr 2026 15:00:22 +0100 Biju wrote:
> This series fixes two related issues in the PHY subsystem: incorrect
> placement of phy_init_hw() in the resume path, and drop/update locking
> in several PHY drivers.
Hi Andrew, IIUC this should be applied for 7.1 but we're waiting
for Russell (who is AFK/busy) to review. Did I get that right?
^ permalink raw reply
* [PATCH net-next 0/4] WireGuard fixes for 7.1-rc1
From: Jason A. Donenfeld @ 2026-04-14 15:39 UTC (permalink / raw)
To: netdev, kuba, pabeni; +Cc: Jason A. Donenfeld
Hi Jakub,
Please find 4 simple patches attached:
1) Asbjørn's YNL sample, finally merged. Sorry for the wait on this one.
2) A simplification to use kfree_rcu instead of call_rcu, since
kfree_rcu now works with kmem caches.
3) A trivial formatting derp.
4) Fix for a deadlock by moving to using exit_rtnl instead of pre_exit.
Please apply these!
Thanks,
Jason
Asbjørn Sloth Tønnesen (1):
tools: ynl: add sample for wireguard
Fushuai Wang (1):
wireguard: allowedips: Use kfree_rcu() instead of call_rcu()
Jason A. Donenfeld (1):
wireguard: allowedips: remove redundant space in comment
Shardul Bankar (1):
wireguard: device: use exit_rtnl callback instead of manual rtnl_lock
in pre_exit
drivers/net/wireguard/allowedips.c | 9 +-
drivers/net/wireguard/device.c | 8 +-
drivers/net/wireguard/selftest/allowedips.c | 2 +-
tools/net/ynl/tests/.gitignore | 1 +
tools/net/ynl/tests/wireguard.c | 106 ++++++++++++++++++++
5 files changed, 113 insertions(+), 13 deletions(-)
create mode 100644 tools/net/ynl/tests/wireguard.c
--
2.53.0
^ permalink raw reply
* [PATCH net-next 1/4] wireguard: allowedips: Use kfree_rcu() instead of call_rcu()
From: Jason A. Donenfeld @ 2026-04-14 15:39 UTC (permalink / raw)
To: netdev, kuba, pabeni; +Cc: Fushuai Wang, Simon Horman, Jason A. Donenfeld
In-Reply-To: <20260414153944.2742252-1-Jason@zx2c4.com>
From: Fushuai Wang <wangfushuai@baidu.com>
Replace call_rcu() + kmem_cache_free() with kfree_rcu() to simplify
the code and reduce function size.
Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/net/wireguard/allowedips.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireguard/allowedips.c b/drivers/net/wireguard/allowedips.c
index 09f7fcd7da78b..5ece9acad64d8 100644
--- a/drivers/net/wireguard/allowedips.c
+++ b/drivers/net/wireguard/allowedips.c
@@ -48,11 +48,6 @@ static void push_rcu(struct allowedips_node **stack,
}
}
-static void node_free_rcu(struct rcu_head *rcu)
-{
- kmem_cache_free(node_cache, container_of(rcu, struct allowedips_node, rcu));
-}
-
static void root_free_rcu(struct rcu_head *rcu)
{
struct allowedips_node *node, *stack[MAX_ALLOWEDIPS_DEPTH] = {
@@ -271,13 +266,13 @@ static void remove_node(struct allowedips_node *node, struct mutex *lock)
if (free_parent)
child = rcu_dereference_protected(parent->bit[!(node->parent_bit_packed & 1)],
lockdep_is_held(lock));
- call_rcu(&node->rcu, node_free_rcu);
+ kfree_rcu(node, rcu);
if (!free_parent)
return;
if (child)
child->parent_bit_packed = parent->parent_bit_packed;
*(struct allowedips_node **)(parent->parent_bit_packed & ~3UL) = child;
- call_rcu(&parent->rcu, node_free_rcu);
+ kfree_rcu(parent, rcu);
}
static int remove(struct allowedips_node __rcu **trie, u8 bits, const u8 *key,
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 2/4] tools: ynl: add sample for wireguard
From: Jason A. Donenfeld @ 2026-04-14 15:39 UTC (permalink / raw)
To: netdev, kuba, pabeni; +Cc: Asbjørn Sloth Tønnesen, Jason A. Donenfeld
In-Reply-To: <20260414153944.2742252-1-Jason@zx2c4.com>
From: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Add a sample application for WireGuard, using the generated C library.
The main benefit of this is to exercise the generated library,
which might be useful for future self-tests.
Example:
$ make -C tools/net/ynl/lib
$ make -C tools/net/ynl/generated
$ make -C tools/net/ynl/tests wireguard
$ ./tools/net/ynl/tests/wireguard
usage: ./tools/net/ynl/tests/wireguard <ifindex|ifname>
$ sudo ./tools/net/ynl/tests/wireguard wg-test
Interface 3: wg-test
Peer 6adfb183a4a2c94a2f92dab5ade762a4788[...]:
Data: rx: 42 / tx: 42 bytes
Allowed IPs:
0.0.0.0/0
::/0
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
tools/net/ynl/tests/.gitignore | 1 +
tools/net/ynl/tests/wireguard.c | 106 ++++++++++++++++++++++++++++++++
2 files changed, 107 insertions(+)
create mode 100644 tools/net/ynl/tests/wireguard.c
diff --git a/tools/net/ynl/tests/.gitignore b/tools/net/ynl/tests/.gitignore
index 045385df42a45..a7832ebfdbbc3 100644
--- a/tools/net/ynl/tests/.gitignore
+++ b/tools/net/ynl/tests/.gitignore
@@ -7,3 +7,4 @@ rt-link
rt-route
tc
tc-filter-add
+wireguard
diff --git a/tools/net/ynl/tests/wireguard.c b/tools/net/ynl/tests/wireguard.c
new file mode 100644
index 0000000000000..df601e742c287
--- /dev/null
+++ b/tools/net/ynl/tests/wireguard.c
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <arpa/inet.h>
+#include <string.h>
+#include <stdio.h>
+#include <errno.h>
+#include <ynl.h>
+
+#include "wireguard-user.h"
+
+static void print_allowed_ip(const struct wireguard_wgallowedip *aip)
+{
+ char addr_out[INET6_ADDRSTRLEN];
+
+ if (!inet_ntop(aip->family, aip->ipaddr, addr_out, sizeof(addr_out))) {
+ addr_out[0] = '?';
+ addr_out[1] = '\0';
+ }
+ printf("\t\t\t%s/%u\n", addr_out, aip->cidr_mask);
+}
+
+/* Only printing public key in this demo. For better key formatting,
+ * use the constant-time implementation as found in wireguard-tools.
+ */
+static void print_peer_header(const struct wireguard_wgpeer *peer)
+{
+ unsigned int len = peer->_len.public_key;
+ uint8_t *key = peer->public_key;
+ unsigned int i;
+
+ if (len != 32)
+ return;
+ printf("\tPeer ");
+ for (i = 0; i < len; i++)
+ printf("%02x", key[i]);
+ printf(":\n");
+}
+
+static void print_peer(const struct wireguard_wgpeer *peer)
+{
+ unsigned int i;
+
+ print_peer_header(peer);
+ printf("\t\tData: rx: %llu / tx: %llu bytes\n",
+ peer->rx_bytes, peer->tx_bytes);
+ printf("\t\tAllowed IPs:\n");
+ for (i = 0; i < peer->_count.allowedips; i++)
+ print_allowed_ip(&peer->allowedips[i]);
+}
+
+static void build_request(struct wireguard_get_device_req *req, char *arg)
+{
+ char *endptr;
+ int ifindex;
+
+ ifindex = strtol(arg, &endptr, 0);
+ if (endptr != arg + strlen(arg) || errno != 0)
+ ifindex = 0;
+ if (ifindex > 0)
+ wireguard_get_device_req_set_ifindex(req, ifindex);
+ else
+ wireguard_get_device_req_set_ifname(req, arg);
+}
+
+int main(int argc, char **argv)
+{
+ struct wireguard_get_device_list *devs;
+ struct wireguard_get_device_req *req;
+ struct ynl_error yerr;
+ struct ynl_sock *ys;
+
+ if (argc < 2) {
+ fprintf(stderr, "usage: %s <ifindex|ifname>\n", argv[0]);
+ return 1;
+ }
+
+ ys = ynl_sock_create(&ynl_wireguard_family, &yerr);
+ if (!ys) {
+ fprintf(stderr, "YNL: %s\n", yerr.msg);
+ return 2;
+ }
+
+ req = wireguard_get_device_req_alloc();
+ build_request(req, argv[1]);
+
+ devs = wireguard_get_device_dump(ys, req);
+ if (!devs) {
+ fprintf(stderr, "YNL (%d): %s\n", ys->err.code, ys->err.msg);
+ wireguard_get_device_req_free(req);
+ ynl_sock_destroy(ys);
+ return 3;
+ }
+
+ ynl_dump_foreach(devs, d) {
+ unsigned int i;
+
+ printf("Interface %d: %s\n", d->ifindex, d->ifname);
+ for (i = 0; i < d->_count.peers; i++)
+ print_peer(&d->peers[i]);
+ }
+
+ wireguard_get_device_list_free(devs);
+ wireguard_get_device_req_free(req);
+ ynl_sock_destroy(ys);
+
+ return 0;
+}
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 3/4] wireguard: allowedips: remove redundant space
From: Jason A. Donenfeld @ 2026-04-14 15:39 UTC (permalink / raw)
To: netdev, kuba, pabeni; +Cc: Jason A. Donenfeld
In-Reply-To: <20260414153944.2742252-1-Jason@zx2c4.com>
Not a contentful commit, but amusingly found when porting ba3d7b93 to
Windows.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/net/wireguard/selftest/allowedips.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireguard/selftest/allowedips.c b/drivers/net/wireguard/selftest/allowedips.c
index 2da3008c3a014..3e857e6fb627b 100644
--- a/drivers/net/wireguard/selftest/allowedips.c
+++ b/drivers/net/wireguard/selftest/allowedips.c
@@ -623,7 +623,7 @@ bool __init wg_allowedips_selftest(void)
test_boolean(!remove(6, b, 0x24446801, 0x40e40800, 0xdeaebeef, 0xdefbeef, 128));
test(6, a, 0x24446801, 0x40e40800, 0xdeaebeef, 0xdefbeef);
/* invalid CIDR should have no effect and return -EINVAL */
- test_boolean(remove(6, a, 0x24446801, 0x40e40800, 0xdeaebeef, 0xdefbeef, 129) == -EINVAL);
+ test_boolean(remove(6, a, 0x24446801, 0x40e40800, 0xdeaebeef, 0xdefbeef, 129) == -EINVAL);
test(6, a, 0x24446801, 0x40e40800, 0xdeaebeef, 0xdefbeef);
remove(6, a, 0x24446801, 0x40e40800, 0xdeaebeef, 0xdefbeef, 128);
test_negative(6, a, 0x24446801, 0x40e40800, 0xdeaebeef, 0xdefbeef);
--
2.53.0
^ permalink raw reply related
* [PATCH net-next 4/4] wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit
From: Jason A. Donenfeld @ 2026-04-14 15:39 UTC (permalink / raw)
To: netdev, kuba, pabeni
Cc: Shardul Bankar, syzbot+f2fbf7478a35a94c8b7c, stable,
Jason A. Donenfeld
In-Reply-To: <20260414153944.2742252-1-Jason@zx2c4.com>
From: Shardul Bankar <shardul.b@mpiricsoftware.com>
wg_netns_pre_exit() manually acquires rtnl_lock() inside the
pernet .pre_exit callback. This causes a hung task when another
thread holds rtnl_mutex - the cleanup_net workqueue (or the
setup_net failure rollback path) blocks indefinitely in
wg_netns_pre_exit() waiting to acquire the lock.
Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net:
Add ->exit_rtnl() hook to struct pernet_operations."), where the
framework already holds RTNL and batches all callbacks under a
single rtnl_lock()/rtnl_unlock() pair, eliminating the contention
window.
The rcu_assign_pointer(wg->creating_net, NULL) is safe to move
from .pre_exit to .exit_rtnl (which runs after synchronize_rcu())
because all RCU readers of creating_net either use maybe_get_net()
- which returns NULL for a dying namespace with zero refcount - or
access net->user_ns which remains valid throughout the entire
ops_undo_list sequence.
Reported-by: syzbot+f2fbf7478a35a94c8b7c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?id=cb64c22a492202ca929e18262fdb8cb89e635c70
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
[ Jason: added __net_exit and __read_mostly annotations that were missing. ]
Fixes: 900575aa33a3 ("wireguard: device: avoid circular netns references")
Cc: stable@vger.kernel.org
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/net/wireguard/device.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index 46a71ec36af87..67b07ee2d6600 100644
--- a/drivers/net/wireguard/device.c
+++ b/drivers/net/wireguard/device.c
@@ -411,12 +411,11 @@ static struct rtnl_link_ops link_ops __read_mostly = {
.newlink = wg_newlink,
};
-static void wg_netns_pre_exit(struct net *net)
+static void __net_exit wg_netns_exit_rtnl(struct net *net, struct list_head *dev_kill_list)
{
struct wg_device *wg;
struct wg_peer *peer;
- rtnl_lock();
list_for_each_entry(wg, &device_list, device_list) {
if (rcu_access_pointer(wg->creating_net) == net) {
pr_debug("%s: Creating namespace exiting\n", wg->dev->name);
@@ -429,11 +428,10 @@ static void wg_netns_pre_exit(struct net *net)
mutex_unlock(&wg->device_update_lock);
}
}
- rtnl_unlock();
}
-static struct pernet_operations pernet_ops = {
- .pre_exit = wg_netns_pre_exit
+static struct pernet_operations pernet_ops __read_mostly = {
+ .exit_rtnl = wg_netns_exit_rtnl
};
int __init wg_device_init(void)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit
From: Jason A. Donenfeld @ 2026-04-14 15:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Shardul Bankar, kuniyu, andrew+netdev, davem, edumazet, pabeni,
wireguard, netdev, linux-kernel, janak, kalpan.jani, shardulsb08,
syzbot+f2fbf7478a35a94c8b7c
In-Reply-To: <20260414081824.0edf6113@kernel.org>
On Tue, Apr 14, 2026 at 5:18 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 14 Apr 2026 15:28:37 +0200 Jason A. Donenfeld wrote:
> > Thanks. Applied to the wireguard tree, and also added the missing
> > __net_exit and __read_mostly annotations in the process.
>
> Hi Jason, while we have you - do you have a PR for us for wireguard?
> We're going to be sending the net-next PR later today..
Sent!
^ permalink raw reply
* Re: [PATCH net v2 4/4] net: mana: Fix EQ leak in mana_remove on NULL port
From: Simon Horman @ 2026-04-14 15:40 UTC (permalink / raw)
To: ernis
Cc: Simon Horman, pabeni, edumazet, ssengar, dipayanroy, gargaditya,
decui, shacharr, linux-hyperv, kotaranov, kys, shirazsaleem,
longli, kuba, andrew+netdev, wei.liu, linux-kernel, netdev,
haiyangz, kees, stephen, leon, davem
In-Reply-To: <20260413050843.605789-5-ernis@linux.microsoft.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: mana: Fix EQ leak in mana_remove on NULL port
In mana_remove(), when a NULL port is encountered in the port iteration
loop, 'goto out' skips the mana_destroy_eq(ac) call, leaking the event
queues allocated earlier by mana_create_eq(). This can happen when
mana_probe_port() fails for port 0, leaving ac->ports[0] as NULL. On
driver unload or error cleanup, mana_remove() hits the NULL entry and
jumps past mana_destroy_eq(). Change 'goto out' to 'break' so the
for-loop exits normally and mana_destroy_eq() is always reached.
> Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
Does this Fixes tag point to the correct commit? Looking at the commit
history, the original driver commit ca9c54d2d6a5 did not have
mana_destroy_eq() in mana_remove() at all, so the 'goto out' pattern could
not have caused an EQ leak at that point.
The bug appears to have been introduced by commit 1e2d0824a9c3 ("net: mana:
Add support for EQ sharing"), which added mana_destroy_eq(ac) to
mana_remove() and placed it after the 'out:' label, making it skippable by
the 'goto out' on NULL port.
Should the Fixes tag be:
Fixes: 1e2d0824a9c3 ("net: mana: Add support for EQ sharing")
^ permalink raw reply
* Re: [PATCH net v2 1/4] net: mana: Init link_change_work before potential error paths in probe
From: Simon Horman @ 2026-04-14 15:41 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, ssengar, dipayanroy, gargaditya,
shirazsaleem, kees, kotaranov, leon, shacharr, stephen,
linux-hyperv, netdev, linux-kernel
In-Reply-To: <20260413050843.605789-2-ernis@linux.microsoft.com>
On Sun, Apr 12, 2026 at 10:08:37PM -0700, Erni Sri Satya Vennela wrote:
> Move INIT_WORK(link_change_work) to right after the mana_context
> allocation, before any error path that could reach mana_remove().
>
> Previously, if mana_create_eq() or mana_query_device_cfg() failed,
> mana_probe() would jump to the error path which calls mana_remove().
> mana_remove() unconditionally calls disable_work_sync(link_change_work),
> but the work struct had not been initialized yet. This can trigger
> CONFIG_DEBUG_OBJECTS_WORK enabled.
>
> Fixes: 54133f9b4b53 ("net: mana: Support HW link state events")
> Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
> ---
> Changes in v2:
> * Apply the patch in net instead of net-next.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net v2 2/4] net: mana: Init gf_stats_work before potential error paths in probe
From: Simon Horman @ 2026-04-14 15:41 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, ssengar, dipayanroy, gargaditya,
shirazsaleem, kees, kotaranov, leon, shacharr, stephen,
linux-hyperv, netdev, linux-kernel
In-Reply-To: <20260413050843.605789-3-ernis@linux.microsoft.com>
On Sun, Apr 12, 2026 at 10:08:38PM -0700, Erni Sri Satya Vennela wrote:
> Move INIT_DELAYED_WORK(gf_stats_work) to before mana_create_eq(),
> while keeping schedule_delayed_work() at its original location.
>
> Previously, if any function between mana_create_eq() and the
> INIT_DELAYED_WORK call failed, mana_probe() would call mana_remove()
> which unconditionally calls cancel_delayed_work_sync(gf_stats_work)
> in __flush_work() or debug object warnings with
> CONFIG_DEBUG_OBJECTS_WORK enabled.
>
> Fixes: be4f1d67ec56 ("net: mana: Add standard counter rx_missed_errors")
> Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit
From: Jakub Kicinski @ 2026-04-14 15:44 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Shardul Bankar, kuniyu, andrew+netdev, davem, edumazet, pabeni,
wireguard, netdev, linux-kernel, janak, kalpan.jani, shardulsb08,
syzbot+f2fbf7478a35a94c8b7c
In-Reply-To: <CAHmME9rwKae5b9PYzuqmwG3p05iZ=jqyp6LQefg0OsB3OP6oWg@mail.gmail.com>
On Tue, 14 Apr 2026 17:40:03 +0200 Jason A. Donenfeld wrote:
> On Tue, Apr 14, 2026 at 5:18 PM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Tue, 14 Apr 2026 15:28:37 +0200 Jason A. Donenfeld wrote:
> > > Thanks. Applied to the wireguard tree, and also added the missing
> > > __net_exit and __read_mostly annotations in the process.
> >
> > Hi Jason, while we have you - do you have a PR for us for wireguard?
> > We're going to be sending the net-next PR later today..
>
> Sent!
Thanks!
(I'll apply in a couple of hours once the CI had its way with it.)
^ permalink raw reply
* Re: [PATCH] net: mdio: MDIO_PIC64HPSC should depend on ARCH_MICROCHIP
From: Charles Perry @ 2026-04-14 15:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Charles Perry, Conor Dooley, Jakub Kicinski, Maxime Chevallier,
Andrew Lunn, Heiner Kallweit, Russell King, David S . Miller,
Eric Dumazet, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <980c57efa5843733ef95459c3283aebade56f142.1776162544.git.geert+renesas@glider.be>
On Tue, Apr 14, 2026 at 12:30:47PM +0200, Geert Uytterhoeven wrote:
> The PIC64-HPSC/HX MDIO interface is only present on Microchip
> PIC64-HPSC/HX SoCs. Hence add a dependency on ARCH_MICROCHIP, to
> prevent asking the user about this driver when configuring a kernel
> without Microchip SoC support.
>
> Fixes: f76aef980206e7c6 ("net: mdio: add a driver for PIC64-HPSC/HX MDIO controller")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Charles Perry <charles.perry@microchip.com>
Thanks!
Charles
^ permalink raw reply
* Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Marek Vasut @ 2026-04-14 15:49 UTC (permalink / raw)
To: Andrew Lunn
Cc: Fidelio Lawson, Woojung Huh, UNGLinuxDriver, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Maxime Chevallier, Simon Horman, Heiner Kallweit, Russell King,
netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <d9b161dd-f698-4d7e-8ccb-9ec12411bf87@lunn.ch>
On 4/14/26 2:40 PM, Andrew Lunn wrote:
> On Tue, Apr 14, 2026 at 01:05:49PM +0200, Marek Vasut wrote:
>> On 4/14/26 11:12 AM, Fidelio Lawson wrote:
>>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>>> Microchip document DS80000687C for KSZ87xx switches.
>>>
>>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>>> where the PHY receiver equalizer may amplify high-amplitude signals
>>> excessively, resulting in internal distortion and link establishment
>>> failures.
>>>
>>> KSZ87xx devices require a workaround for the Module 3 low-loss cable
>>> condition, controlled through the switch TABLE_LINK_MD_V indirect
>>> registers.
>>>
>>> The affected registers are part of the switch address space and are not
>>> directly accessible from the PHY driver. To keep the PHY-facing API
>>> clean and avoid leaking switch-specific details, model this errata
>>> control as vendor-specific Clause 22 PHY registers.
>>>
>>> A vendor-specific Clause 22 PHY register is introduced as a mode
>>> selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
>>> translate accesses to these bits into the appropriate indirect
>>> TABLE_LINK_MD_V accesses.
>>>
>>> The control register defines the following modes:
>>> 0: disabled (default behavior)
>>> 1: EQ training workaround
>>> 2: LPF 90 MHz
>>> 3: LPF 62 MHz
>>> 4: LPF 55 MHz
>>> 5: LPF 44 MHz
>> I may not fully understand this, but aren't the EQ and LPF settings
>> orthogonal ?
>
> What is the real life experience using this feature? Is it needed for
> 1cm cables, but most > 1m cables are O.K with the defaults? Do we need
> all these configuration options? How is a user supposed to discover
> the different options? Can we simplify it down to a Boolean?
The report I got was, that if the device is cooled down AND the user
used special short low-loss CAT6 cable, then there was packet loss until
the communication completely broke down.
With the LPF set to 62 MHz and DSP EQ initial value set to 0, that
situation improved and there was still up to 0.14% packet less, but it
is better than total breakdown of communication. We couldn't get the
packet loss down to 0% no matter which tuning we applied.
> Ethernet is just supposed to work with any valid length of cable,
> KISS. So maybe we should try to keep this feature KISS. Just tell the
> driver it is a short cable, pick different defaults which should work
> with any short cable?
I think the user should be able to configure the LPF bandwidth and DSP
EQ initial value as needed. While the short cable improvement settings
are "LPF set to 62 MHz bandwidth and DSP EQ initial value to 0", there
might be future configurations which require different settings.
I think the ideal setup would be if those two settings were configurable
separately, with a bit of documentation explaining the two currently
known good settings:
- Default (LPF 90 MHz BW, DSP EQ initial value as needed)
- Short cable (LPF 62 MHz BW, DSP EQ initial value 0)
But if the user needs to reduce the BW further e.g. to improve noise
resistance further, they shouldn't be prevented from doing so.
> A boolean should also help with making this tunable reusable with
> other devices. It is unlikely any other devices have these same
> configuration options, unless it is from the same vendor.
Could the LPF PHY tunable simply take integer as a parameter ? Then it
would be portable across other PHYs I think ?
The DSP EQ initial value can also be an integer tunable.
^ permalink raw reply
* Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Marek Vasut @ 2026-04-14 15:50 UTC (permalink / raw)
To: Andrew Lunn, Fidelio LAWSON
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Marek Vasut,
Maxime Chevallier, Simon Horman, Heiner Kallweit, Russell King,
netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <d584bd42-ee6d-465f-b4f7-2edc992368d6@lunn.ch>
On 4/14/26 4:54 PM, Andrew Lunn wrote:
> On Tue, Apr 14, 2026 at 03:48:33PM +0200, Fidelio LAWSON wrote:
>> On 4/14/26 14:40, Andrew Lunn wrote:
>>> On Tue, Apr 14, 2026 at 01:05:49PM +0200, Marek Vasut wrote:
>>>> On 4/14/26 11:12 AM, Fidelio Lawson wrote:
>>>>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>>>>> Microchip document DS80000687C for KSZ87xx switches.
>>>>>
>>>>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>>>>> where the PHY receiver equalizer may amplify high-amplitude signals
>>>>> excessively, resulting in internal distortion and link establishment
>>>>> failures.
>>>>>
>>>>> KSZ87xx devices require a workaround for the Module 3 low-loss cable
>>>>> condition, controlled through the switch TABLE_LINK_MD_V indirect
>>>>> registers.
>>>>>
>>>>> The affected registers are part of the switch address space and are not
>>>>> directly accessible from the PHY driver. To keep the PHY-facing API
>>>>> clean and avoid leaking switch-specific details, model this errata
>>>>> control as vendor-specific Clause 22 PHY registers.
>>>>>
>>>>> A vendor-specific Clause 22 PHY register is introduced as a mode
>>>>> selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
>>>>> translate accesses to these bits into the appropriate indirect
>>>>> TABLE_LINK_MD_V accesses.
>>>>>
>>>>> The control register defines the following modes:
>>>>> 0: disabled (default behavior)
>>>>> 1: EQ training workaround
>>>>> 2: LPF 90 MHz
>>>>> 3: LPF 62 MHz
>>>>> 4: LPF 55 MHz
>>>>> 5: LPF 44 MHz
>>>> I may not fully understand this, but aren't the EQ and LPF settings
>>>> orthogonal ?
>>>
>>> What is the real life experience using this feature? Is it needed for
>>> 1cm cables, but most > 1m cables are O.K with the defaults? Do we need
>>> all these configuration options? How is a user supposed to discover
>>> the different options? Can we simplify it down to a Boolean?
>> We were seeing random link dropouts with the default settings, and since
>> enabling the workaround 2, the link has remained stable and we have not
>> observed any further issues.
>
> So for you, a boolean which enables workaround 2 would be sufficient.
I agree with the observation from Fidelio, the hardware behaves that
way. As for the rest format of the tunables, I now replied to previous
email.
^ permalink raw reply
* Re: [PATCH net v4 1/2] flow_dissector: do not dissect PPPoE PFC frames
From: Simon Horman @ 2026-04-14 15:50 UTC (permalink / raw)
To: Qingfang Deng
Cc: linux-ppp, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Guillaume Nault, Wojciech Drewek, Tony Nguyen,
linux-kernel, netdev, Paul Mackerras, Jaco Kroon, James Carlson,
Marcin Szycik
In-Reply-To: <717da5ac-a020-4710-8ebb-6ed9d6e48bf4@linux.dev>
On Sat, Apr 11, 2026 at 11:56:30AM +0800, Qingfang Deng wrote:
> Hi,
>
> On 4/11/2026 1:10 AM, Simon Horman wrote:
> > On Fri, Apr 10, 2026 at 11:36:20AM +0800, Qingfang Deng wrote:
> > > @@ -1361,7 +1376,7 @@ bool __skb_flow_dissect(const struct net *net,
> > > struct pppoe_hdr hdr;
> > > __be16 proto;
> > > } *hdr, _hdr;
> > > - u16 ppp_proto;
> > > + __be16 ppp_proto;
> >
> > I'm unclear of the relationship between changing the type of ppp_proto
> > and the problem described in the patch description. And it
> > is creating a log of churn in this patch. I suggest dropping it.
>
> The intention is to restore the original behavior before the blamed commit.
> If you find it too verbose for a fix, I can drop it and then repost that
> part later to net-next.
Thanks, I see you have posted v5, which I plan to review.
FTR: I think it is best to split the fix, for net, from
other changes for net-next.
...
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: Add netkit selftest files
From: patchwork-bot+netdevbpf @ 2026-04-14 15:50 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, kuba, dw, pabeni, razor
In-Reply-To: <20260414075249.611608-1-daniel@iogearbox.net>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 14 Apr 2026 09:52:49 +0200 you wrote:
> The following selftest files are related to netkit and should have
> netkit folks in Cc for review:
>
> - tools/testing/selftests/bpf/prog_tests/tc_netkit.c
> - tools/testing/selftests/drivers/net/hw/nk_qlease.py
> - tools/testing/selftests/net/nk_qlease.py
>
> [...]
Here is the summary with links:
- [net-next] MAINTAINERS: Add netkit selftest files
https://git.kernel.org/netdev/net-next/c/bc28831d7a09
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] Follow-ups to nk_qlease net selftests
From: patchwork-bot+netdevbpf @ 2026-04-14 15:50 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, kuba, dw, pabeni, razor
In-Reply-To: <20260413220809.604592-1-daniel@iogearbox.net>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 14 Apr 2026 00:08:03 +0200 you wrote:
> This is a set of follow-ups addressing [0]:
>
> - Split netdevsim tests from HW tests in nk_qlease and move the SW
> tests under selftests/net/
> - Remove multiple ksft_run()s to fix the recently enforced hard-fail
> - Move all the setup inside the test cases for the ones under
> selftests/net/ (I'll defer the HW ones to David)
> - Add more test coverage related to queue leasing behavior and corner
> cases, so now we have 45 tests in nk_qlease.py with netdevsim
> which does not need special HW
>
> [...]
Here is the summary with links:
- [net-next,v2,1/3] tools/ynl: Make YnlFamily closeable as a context manager
https://git.kernel.org/netdev/net-next/c/4a6fe5fe6004
- [net-next,v2,2/3] selftests/net: Split netdevsim tests from HW tests in nk_qlease
https://git.kernel.org/netdev/net-next/c/e254ffb9502c
- [net-next,v2,3/3] selftests/net: Add additional test coverage in nk_qlease
https://git.kernel.org/netdev/net-next/c/1e822171ba9b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexei Starovoitov @ 2026-04-14 15:58 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZd31GzdpEqR8VhfK4JtUKyyRMgbBoAbeGACJgm7WvB6Vw@mail.gmail.com>
On Tue, Apr 14, 2026 at 8:10 AM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> On Tue, Apr 14, 2026 at 4:36 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > > ACK, I'll try to use those kasan_check_read and kasan_check_write rather
> > > than __asan_{load,store}X.
> >
> > No. The performance penalty will be too high.
>
> With using __asan_load/storeX(), it will be one function call to get
> to check_region_inline(): __asan_load/storeX->check_region_inline.
>
> With kasan_check_read/write(), right now, it would be two function
> calls: __kasan_check_read->kasan_check_range->check_region_inline.
>
> I doubt an extra function call would make a difference in terms of
> performance: the shadow checking itself is also expensive.
>
> But if the second call is a concern, we can move kasan_check_range()
> and lower-level functions into mm/kasan/generic.h and include it into
> shadow.c, and then it will be just one function call.
>
> To improve performance further, the JIT compiler could emit inlined
> shadow checking instructions, same as the C compiler does with
> KASAN_INLINE=y.
>
> > hw_tags won't work without corresponding JIT work.
>
> You probably meant SW_TAGS here.
>
> HW_TAGS will likely just work without any JIT changes (even the
> kasan_check_byte() thing I mentioned should not be required), assuming
> JIT'ed BPF code just accesses kernel-returned pointers as is.
>
> > I see no point sacrificing performance for aesthetics.
>
> With the change I suggested above, there would be no performance
> difference. And the code stays cleaner.
>
> > __asan_load/storeX is what compilers emit.
>
> For Generic mode. For SW_TAGS, the function names are different.
> Keeping this detail within the KASAN code is cleaner.
I think we're talking past each other.
We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
We're not going to modify arm64 JIT at all.
This is purely KASAN_GENRIC and only on x86-64.
JIT will emit exactly what compilers emit for generic
which is __asan_load/store. This is as stable ABI as it can get
and we don't want to deviate from it.
The goal here is to find bugs in the verifier.
If something got past it, that shouldn't have,
kasan generic on x86-64 is enough.
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: Dipayaan Roy @ 2026-04-14 16:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, leon, longli, kotaranov, horms, shradhagupta, ssengar,
ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, leitao, kees, john.fastabend,
hawk, bpf, daniel, ast, sdf, dipayanroy
In-Reply-To: <20260412125917.4fa8fc8d@kernel.org>
On Sun, Apr 12, 2026 at 12:59:17PM -0700, Jakub Kicinski wrote:
> On Thu, 9 Apr 2026 18:35:09 -0700 Jakub Kicinski wrote:
> > On Tue, 7 Apr 2026 12:59:17 -0700 Dipayaan Roy wrote:
> > > This behavior is observed on a single platform; other platforms
> > > perform better with page_pool fragments, indicating this is not a
> > > page_pool issue but platform-specific.
> >
> > Well, someone has to run some experiments and confirm other ARM
> > platforms are not impacted, with data. I was hoping to do it myself
> > but doesn't look like that will happen in time for the merge window :(
>
> Please repost with the perf analysis on other commercially available
> ARM platform. Something like:
>
> This is a workaround applicable to only some platforms. Modifying
> driver X to use a similar workaround on [Ampere Max|nVidia
> Grace|Amazon Graviton 3|..] the performance for split pages is
> y% higher than when using single pages.
> --
> pw-bot: cr
Hi Jakub,
I ran the same experiment on an alternate ARM64 platform from a
different vendor, which I was able to access only recently. I still see
roughly a 5% overhead from the atomic refcount operation itself, but on
that platform there is no throughput drop when using page fragments
versus full-page mode. In both cases, the setup reaches line rate. That
suggests the atomic overhead alone does not explain the throughput loss
on the specific hardware we are discussing.
I also received an update from the hardware team. They collected PCIe
traces and observed stalls on this particular ARM64 prcossor
when running with page fragments, while those stalls are not seen in
full-page mode. The exact root cause is still under investigation, but
their current assessment is that this is likely a microarchitectural
issue in the PCIe root port. Based on that, they are asking for a
software workaround that uses full pages until the issue is fully
understood.
For that reason, I am asking whether this could be accepted as an
ethtool private flag rather than as a generic driver change,
since the problem is still specific to one CPU/platform.
Please let me know whether you think this patch with private flag
would be acceptable here.
Regards
Dipayaan Roy
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] net: phy: Move phy_init_hw() from phy_resume() to __phy_resume()
From: Andrew Lunn @ 2026-04-14 16:03 UTC (permalink / raw)
To: Biju
Cc: Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Biju Das, Russell King, netdev, linux-kernel,
Geert Uytterhoeven, Prabhakar Mahadev Lad, linux-renesas-soc
In-Reply-To: <20260412140032.122841-6-biju.das.jz@bp.renesas.com>
On Sun, Apr 12, 2026 at 03:00:27PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Now that redundant locking has been removed from PHY driver callbacks,
> phy_init_hw() can be called with phydev->lock held.
>
> Many MAC drivers and the phylink framework resume the PHY via
> phy_start(), which invokes __phy_resume() directly without going
> through phy_resume(). Keeping phy_init_hw() in phy_resume() means it
> is not called in this path.
>
> Move phy_init_hw() into __phy_resume() so that PHY soft reset and
> re-initialisation happen unconditionally on every resume, regardless
> of which code path triggers it.
I would change the order of these patches. First remove the redundant
locks. You can then put phy_init_hw() into __phy_resume(), rather than
first moving it into phy_resume() and then __phy_resume().
Andrew
^ permalink raw reply
* [PATCH] net: mdio: octeon: use %p for bus id
From: Chen Jung Ku @ 2026-04-14 15:56 UTC (permalink / raw)
To: davem, kuba
Cc: edumazet, pabeni, andrew, hkallweit1, linux, netdev, linux-kernel,
Chen Jung Ku
Replace %px with %p to avoid exposing raw kernel pointer values.
Signed-off-by: Chen Jung Ku <ku.loong@gapp.nthu.edu.tw>
---
drivers/net/mdio/mdio-octeon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mdio/mdio-octeon.c b/drivers/net/mdio/mdio-octeon.c
index cb53dccbde1a..c9c000bb0cd5 100644
--- a/drivers/net/mdio/mdio-octeon.c
+++ b/drivers/net/mdio/mdio-octeon.c
@@ -38,7 +38,7 @@ static int octeon_mdiobus_probe(struct platform_device *pdev)
oct_mdio_writeq(smi_en.u64, bus->register_base + SMI_EN);
bus->mii_bus->name = KBUILD_MODNAME;
- snprintf(bus->mii_bus->id, MII_BUS_ID_SIZE, "%px", bus->register_base);
+ snprintf(bus->mii_bus->id, MII_BUS_ID_SIZE, "%p", bus->register_base);
bus->mii_bus->parent = &pdev->dev;
bus->mii_bus->read = cavium_mdiobus_read_c22;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v3 3/5] net: phy: mscc: Drop unnecessary phydev->lock
From: Andrew Lunn @ 2026-04-14 16:06 UTC (permalink / raw)
To: Biju
Cc: Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Biju Das, Russell King, Lad Prabhakar,
Horatiu Vultur, Vladimir Oltean, netdev, linux-kernel,
Geert Uytterhoeven, linux-renesas-soc
In-Reply-To: <20260412140032.122841-4-biju.das.jz@bp.renesas.com>
On Sun, Apr 12, 2026 at 03:00:25PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Remove manual mutex_lock/unlock(&phydev->lock) calls from several
> functions in the MSCC PHY driver.
>
> In vsc85xx_edge_rate_cntl_set(), phydev->lock is taken around a single
> phy_modify_paged() call. phy_modify_paged() is already a fully locked
> atomic operation that acquires the MDIO bus lock internally, so the
> additional phydev->lock is unnecessary.
>
> The remaining three functions — vsc85xx_mac_if_set(),
> vsc8531_pre_init_seq_set(), and vsc85xx_eee_init_seq_set() — use
> phy_read(), phy_write(), phy_select_page(), and phy_restore_page(),
> all of which operate under the MDIO bus lock. Taking phydev->lock
> around them provides no additional serialisation.
>
> Along with dropping the locks, error-path labels are renamed from
> out_unlock to err or restore_oldpage to better reflect their purpose.
> In vsc8531_pre_init_seq_set() and vsc85xx_eee_init_seq_set(), the
> redundant intermediate assignment of oldpage before returning is also
> eliminated.
>
> No functional change intended.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ 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