* [PATCH bpf v2 0/3] bpf: prevent offloaded programs from running on host via tcx/netkit
From: Jiayuan Chen @ 2026-04-24 10:41 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Daniel Borkmann, Nikolay Aleksandrov, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Martin KaFai Lau, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Simon Horman, Jesper Dangaard Brouer, Willem de Bruijn,
Samiullah Khawaja, Hangbin Liu, Krishna Kumar, Kuniyuki Iwashima,
Toke Høiland-Jørgensen, netdev, linux-kernel
Yinhao reported a splat [1] when attaching a BPF program loaded with
prog_ifindex (targeted at an offload-capable device such as netdevsim)
to the software path via BPF_TCX_EGRESS. The program's bpf_func had
already been replaced by bpf_prog_warn_on_exec() during offload compile,
so the first packet that reaches tcx_run() trips the WARN:
[ 19.592982] ------------[ cut here ]------------
[ 19.594654] attempt to execute device eBPF program on the host!
[ 19.594659] WARNING: kernel/bpf/offload.c:420 at 0x0, CPU#0: poc/337
[ 19.599906] Modules linked in:
[ 19.600680] CPU: 0 UID: 0 PID: 337 Comm: poc Not tainted
6.18.0-rc7-next-20251125 #10 PREEMPT(none)
[ 19.601659] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX,
1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 19.602684] RIP: 0010:bpf_prog_warn_on_exec+0xc/0x20
[ 19.603241] Code: 28 00 48 89 ef e8 74 44 2f 00 eb d7 66 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8d 3d a4 eb 95
06 <67> 48 0f b9 3a 31 c0 e9 83 76 44 ff 0f 1f 84 00 00 00 00 00 90 90
[ 19.605093] RSP: 0018:ffff8881066e73d8 EFLAGS: 00010246
[ 19.605663] RAX: ffffffff81cbca70 RBX: ffff8881013c4210 RCX:
0000000000000004
[ 19.606378] RDX: 1ffff11020278842 RSI: ffffc90000563060 RDI:
ffffffff8861b620
[ 19.607107] RBP: ffff8881010d0640 R08: ffff8881013c4210 R09:
ffff8881010d06b0
[ 19.607827] R10: ffff8881010d06c3 R11: ffffc90000563000 R12:
ffffc90000563000
[ 19.608751] R13: ffff8881010d06b4 R14: ffff888115eb1a34 R15:
dffffc0000000000
[ 19.609478] FS: 000000000294c380(0000) GS:ffff8881911e9000(0000)
knlGS:0000000000000000
[ 19.610316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 19.610943] CR2: 000057f6b9eb38c0 CR3: 00000001010ea000 CR4:
0000000000750ef0
[ 19.611712] PKRU: 55555554
[ 19.612006] Call Trace:
[ 19.612281] <TASK>
[ 19.612523] __dev_queue_xmit+0x22cb/0x3530
[ 19.617607] ip_finish_output2+0x621/0x1a60
[ 19.621371] ip_output+0x170/0x2e0
[ 19.624586] ip_send_skb+0x129/0x180
[ 19.624940] udp_send_skb+0x65d/0x1300
[ 19.625316] udp_sendmsg+0x13bf/0x2000
[ 19.629960] __sys_sendto+0x396/0x470
[ 19.633720] __x64_sys_sendto+0xdc/0x1b0
[ 19.635066] do_syscall_64+0x76/0x10a0
[ 19.641701] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 19.642240] RIP: 0033:0x4240d7
[ 19.642597] Code: 00 89 01 e9 c1 fe ff ff e8 f6 03 00 00 66 0f 1f 44
00 00 f3 0f 1e fa 80 3d 8d 3f 09 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f
05 <48> 3d 00 f0 ff ff 77 69 c3 55 48 89 e5 53 48 83 ec 38 44 89 4d d0
[ 19.646088] RSP: 002b:00007fffcb9ecb68 EFLAGS: 00000202 ORIG_RAX:
000000000000002c
[ 19.648938] RAX: ffffffffffffffda RBX: 0000000000000001 RCX:
00000000004240d7
[ 19.652116] RDX: 0000000000000008 RSI: 00007fffcb9ecce0 RDI:
0000000000000005
[ 19.653148] RBP: 00007fffcb9eccf0 R08: 00007fffcb9ecbb0 R09:
0000000000000010
[ 19.653951] R10: 0000000000000000 R11: 0000000000000202 R12:
00007fffcb9ece08
[ 19.654760] R13: 00007fffcb9ece18 R14: 00000000004b2868 R15:
0000000000000001
[ 19.657462] </TASK>
[ 19.657703] ---[ end trace 0000000000000000 ]---
The reason is that tcx and netkit never checked for offloaded programs
on attach, unlike XDP which already rejects this in dev_xdp_attach().
While auditing the other link entry points, bpf_xdp_link_update() turned
out to have the same gap: it calls dev_xdp_install() directly and skips
the dev_xdp_attach() offload check, so an XDP link created in SKB/native
mode can still be swapped to an offloaded program via BPF_LINK_UPDATE.
This series adds the same guard to all three so offloaded programs can't
be attached to (or swapped into) the software path.
v1 -> v2:
- tcx/netkit: also reject offloaded progs in the link update callback
(tcx_link_update/netkit_link_update), not just attach; pointed out
by the AI review on v1.
- Add patch 3/3 for the same hole in bpf_xdp_link_update().
v1: https://lore.kernel.org/bpf/20260423033609.252464-1-jiayuan.chen@linux.dev/
[1]: https://lore.kernel.org/bpf/64d8e2b5-a214-4f3c-b9e8-bcedbcb2c602@hust.edu.cn/
Jiayuan Chen (3):
bpf, tcx: reject offloaded programs on attach
bpf, netkit: reject offloaded programs on attach
bpf, xdp: reject offloaded programs on link update
drivers/net/netkit.c | 9 +++++++++
kernel/bpf/tcx.c | 9 +++++++++
net/core/dev.c | 5 +++++
3 files changed, 23 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH bpf v2 1/3] bpf, tcx: reject offloaded programs on attach
From: Jiayuan Chen @ 2026-04-24 10:41 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Yinhao Hu, Kaiyan Mei, Dongliang Mu,
Daniel Borkmann, Nikolay Aleksandrov, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Martin KaFai Lau, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Simon Horman, Jesper Dangaard Brouer, Willem de Bruijn,
Samiullah Khawaja, Hangbin Liu, Krishna Kumar, Kuniyuki Iwashima,
Toke Høiland-Jørgensen, netdev, linux-kernel
In-Reply-To: <20260424104201.217604-1-jiayuan.chen@linux.dev>
An offloaded prog's bpf_func is replaced by bpf_prog_warn_on_exec(),
since it's supposed to run on the NIC, not the host. But tcx doesn't
check this and happily attaches it to the software path, so the first
packet hits the WARN.
XDP already guards this in dev_xdp_attach(); tcx just never got the
same check. Add it to tcx_prog_attach(), tcx_link_attach() and also
tcx_link_update() so the fix cannot be bypassed by loading a normal
program and then swapping it out via BPF_LINK_UPDATE.
Use bpf_prog_is_offloaded() rather than bpf_prog_is_dev_bound() +
bpf_offload_dev_match() (as XDP does): bpf_prog_dev_bound_init()
already rejects BPF_F_XDP_DEV_BOUND_ONLY for BPF_PROG_TYPE_SCHED_CLS,
so a dev-bound SCHED_CLS program is always offloaded. The simpler
check is sufficient and also rejects attaching a program offloaded to
device A onto device B.
Fixes: e420bed025071 ("bpf: Add fd-based tcx multi-prog infra with link support")
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/64d8e2b5-a214-4f3c-b9e8-bcedbcb2c602@hust.edu.cn/
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
kernel/bpf/tcx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/bpf/tcx.c b/kernel/bpf/tcx.c
index 02db0113b8e7c..1144627483d53 100644
--- a/kernel/bpf/tcx.c
+++ b/kernel/bpf/tcx.c
@@ -16,6 +16,9 @@ int tcx_prog_attach(const union bpf_attr *attr, struct bpf_prog *prog)
struct net_device *dev;
int ret;
+ if (bpf_prog_is_offloaded(prog->aux))
+ return -EINVAL;
+
rtnl_lock();
dev = __dev_get_by_index(net, attr->target_ifindex);
if (!dev) {
@@ -209,6 +212,9 @@ static int tcx_link_update(struct bpf_link *link, struct bpf_prog *nprog,
struct net_device *dev;
int ret = 0;
+ if (bpf_prog_is_offloaded(nprog->aux))
+ return -EINVAL;
+
rtnl_lock();
dev = tcx->dev;
if (!dev) {
@@ -315,6 +321,9 @@ int tcx_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
struct tcx_link *tcx;
int ret;
+ if (bpf_prog_is_offloaded(prog->aux))
+ return -EINVAL;
+
rtnl_lock();
dev = __dev_get_by_index(net, attr->link_create.target_ifindex);
if (!dev) {
--
2.43.0
^ permalink raw reply related
* [PATCH bpf v2 2/3] bpf, netkit: reject offloaded programs on attach
From: Jiayuan Chen @ 2026-04-24 10:41 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Daniel Borkmann, Nikolay Aleksandrov, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Martin KaFai Lau, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Simon Horman, Jesper Dangaard Brouer, Willem de Bruijn,
Samiullah Khawaja, Hangbin Liu, Krishna Kumar, Kuniyuki Iwashima,
Toke Høiland-Jørgensen, netdev, linux-kernel
In-Reply-To: <20260424104201.217604-1-jiayuan.chen@linux.dev>
Same issue as the tcx fix: netkit accepts SCHED_CLS programs but never
checks if they were loaded for hardware offload. If someone loads a
program with prog_ifindex pointing to an offload-capable device and then
attaches it to a netkit peer, the bpf_func is bpf_prog_warn_on_exec()
and the first packet triggers the WARN.
Reject offloaded programs in netkit_prog_attach(), netkit_link_attach()
and netkit_link_update().
Fixes: 35dfaad7188cd ("netkit, bpf: Add bpf programmable net device")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
drivers/net/netkit.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/netkit.c b/drivers/net/netkit.c
index 5c0e01396e064..dae4d7b24d80e 100644
--- a/drivers/net/netkit.c
+++ b/drivers/net/netkit.c
@@ -533,6 +533,9 @@ int netkit_prog_attach(const union bpf_attr *attr, struct bpf_prog *prog)
struct net_device *dev;
int ret;
+ if (bpf_prog_is_offloaded(prog->aux))
+ return -EINVAL;
+
rtnl_lock();
dev = netkit_dev_fetch(current->nsproxy->net_ns, attr->target_ifindex,
attr->attach_type);
@@ -683,6 +686,9 @@ static int netkit_link_update(struct bpf_link *link, struct bpf_prog *nprog,
struct net_device *dev;
int ret = 0;
+ if (bpf_prog_is_offloaded(nprog->aux))
+ return -EINVAL;
+
rtnl_lock();
dev = nkl->dev;
if (!dev) {
@@ -788,6 +794,9 @@ int netkit_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
struct net_device *dev;
int ret;
+ if (bpf_prog_is_offloaded(prog->aux))
+ return -EINVAL;
+
rtnl_lock();
dev = netkit_dev_fetch(current->nsproxy->net_ns,
attr->link_create.target_ifindex,
--
2.43.0
^ permalink raw reply related
* [PATCH bpf v2 3/3] bpf, xdp: reject offloaded programs on link update
From: Jiayuan Chen @ 2026-04-24 10:41 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Daniel Borkmann, Nikolay Aleksandrov, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Martin KaFai Lau, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Simon Horman, Jesper Dangaard Brouer, Willem de Bruijn,
Samiullah Khawaja, Hangbin Liu, Krishna Kumar, Kuniyuki Iwashima,
Toke Høiland-Jørgensen, netdev, linux-kernel
In-Reply-To: <20260424104201.217604-1-jiayuan.chen@linux.dev>
Same class of bug as the tcx/netkit fixes: bpf_xdp_link_update() calls
dev_xdp_install() directly and bypasses dev_xdp_attach(), so the offload
check in dev_xdp_attach() is skipped. A user can create an XDP link in
SKB or native mode with a regular program and then replace it via
BPF_LINK_UPDATE with an offloaded program, whose bpf_func is
bpf_prog_warn_on_exec(), tripping the WARN on the first packet.
Mirror the check from dev_xdp_attach(): reject when the link is not in
HW mode and the new program is offloaded.
Fixes: 026a4c28e1db3 ("bpf, xdp: Implement LINK_UPDATE for BPF XDP link")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
net/core/dev.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 831129f2a69b5..984d44b2a626d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -10648,6 +10648,11 @@ static int bpf_xdp_link_update(struct bpf_link *link, struct bpf_prog *new_prog,
netdev_lock_ops(xdp_link->dev);
mode = dev_xdp_mode(xdp_link->dev, xdp_link->flags);
+ if (mode != XDP_MODE_HW && bpf_prog_is_offloaded(new_prog->aux)) {
+ netdev_unlock_ops(xdp_link->dev);
+ err = -EINVAL;
+ goto out_unlock;
+ }
bpf_op = dev_xdp_bpf_op(xdp_link->dev, mode);
err = dev_xdp_install(xdp_link->dev, mode, bpf_op, NULL,
xdp_link->flags, new_prog);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 net 01/11] octeontx2-af: npc: cn20k: Propagate MCAM key-type errors on cn20k
From: Ratheesh Kannoth @ 2026-04-24 10:54 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, davem, edumazet, kuba, pabeni, andrew+netdev,
Suman Ghosh, Dan Carpenter
In-Reply-To: <20260423104317.2707923-2-rkannoth@marvell.com>
On 2026-04-23 at 16:13:07, Ratheesh Kannoth (rkannoth@marvell.com) wrote:
> npc_mcam_idx_2_key_type() can fail; callers used to ignore it and still
> used kw_type when enabling, configuring, copying, and reading MCAM
> entries. That could program or decode hardware with an undefined key
> type.
>
>https://sashiko.dev/#/patchset/20260423104317.2707923-1-rkannoth%40marvell.com
>
>> @@ -1415,14 +1435,14 @@ int rvu_mbox_handler_npc_cn20k_mcam_alloc_and_write_entry(struct rvu *rvu,
>> else
>> nix_intf = pfvf->nix_rx_intf;
>>
>> - npc_cn20k_config_mcam_entry(rvu, blkaddr, entry, nix_intf,
>> - &req->entry_data, req->enable_entry,
>> - req->hw_prio, req->req_kw_type);
>> + rc = npc_cn20k_config_mcam_entry(rvu, blkaddr, entry, nix_intf,
>> + &req->entry_data, req->enable_entry,
>> + req->hw_prio, req->req_kw_type);
>>
>> mutex_unlock(&mcam->lock);
>>
>> rsp->entry = entry_rsp.entry;
>> - return 0;
>> + return rc;
>> }
>Does this code leak the allocated MCAM entry if npc_cn20k_config_mcam_entry()
>fails?
>Earlier in rvu_mbox_handler_npc_cn20k_mcam_alloc_and_write_entry(), an entry
>is successfully allocated via rvu_mbox_handler_npc_mcam_alloc_entry(). If
>the configuration step then fails, returning rc without rolling back the
>allocation leaves the hardware MCAM entry unmapped but still reserved.
>Because the generic mailbox framework propagates the error code, the
>requester will assume the entire allocation failed and will never send a
>free request. This could allow a VF to repeatedly trigger this failure path
>and exhaust all available MCAM entries.
This commit is to address a smatch error reported by Dan. To fix issue, raised here
by sashiko, we need to change multiple files to handle all errors gracefully. it will be an enhancement change.
I will add a follow up patch to net-next. Ignoring this comment for this patch.
^ permalink raw reply
* [BUG] mlx5: VLAN-aware bridge drops all traffic in legacy eswitch mode without promiscuous
From: bryan @ 2026-04-24 11:07 UTC (permalink / raw)
To: netdev; +Cc: saeedm, tariqt
Good day,
I wanted to check whether there is an open bug report or known fix in
progress for an issue that has been affecting mlx5 users (specifically
ConnectX-4 Lx, but likely broader from what I have seen other
reporting) since at least 2021:
When an mlx5 interface is added as a port to a VLAN-aware Linux bridge
(bridge-vlan-aware yes / vlan_filtering 1) in legacy eswitch mode, all
traffic stops passing through the bridge. Both tagged and untagged
traffic is affected. The same configuration works correctly with non-
mlx5 NICs (tested Intel, Chelsio cards).
The only known workarounds are:
1. Enable promiscuous mode on the interface (ip link set dev <iface>
promisc on), which bypasses hardware VLAN filtering but has security
and performance implications. (this is what I am doing on my systems at
the moment)
2. Switch the eswitch to switchdev mode, which was fixed for a kernel
panic in February 2023 (net/mlx5e: Fix crash unsetting rx-vlan-filter
in switchdev mode) but introduces other issues including MDB errors and
is not suitable for all configurations.
Based on reports I have seen from other in forums, this appears to have
been introduced somewhere around kernel 6.1-6.5, possibly related to a
commit that changed promiscuous mode efficiency in mlx5_core. I was not
using this hardware at the time, and cannot confirm firsthand. The
NVIDIA out-of-tree MLNX_EN driver does not exhibit this behavior in
legacy eswitch mode, which strongly suggests this is a regression in
the upstream mlx5 driver rather than a firmware or hardware issue. I do
not have first-hand experience with the mlx5 driver ever working
correctly - the idea that it did historically work correctly is based
purely on the reports of others (and the existence of old setup guides
that do not mention needing to try either of these workarounds.)
If it helps at all, I have tried various firmware versions on ConnectX-
4 Lx cards ranging from from an old release from 2017 all the way up to
the latest 14_32_1912. There has been no difference in behaviour with
regard to this issue.
This is well documented in community forums but does not appear to have
been formally reported to netdev that I have been able to find. My
apologies in advance if this has been reported and I wasn't able to
locate it. Here are a couple of forum examples where this is discussed
among other affected users:
- NVIDIA Developer Forum (opened 2021, unresolved):
https://forums.developer.nvidia.com/t/vlan-aware-linux-bridging-is-not-functional-on-connectx4lx-card-unless-manually-put-in-promiscuous-mode/206083
- Proxmox Forum thread (2023, ongoing):
https://forum.proxmox.com/threads/mellanox-connectx-4-lx-and-brigde-vlan-aware-on-proxmox-8-0-1.130902/
- Community writeup with analysis:
https://www.apalrd.net/posts/2023/tip_mellanox/
Has anyone bisected this or is there a fix already in progress that I
did not find? This affects a fairly common hypervisor configuration
(VLAN-aware bridge for VM networking) and the workarounds are not
conducive to production use.
Thank you for your time,
Bryan Pliscott
^ permalink raw reply
* Re: [GIT PULL] Networking deletions for 7.1
From: Daniel Palmer @ 2026-04-24 11:14 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: torvalds, davem, netdev, linux-kernel, pabeni
In-Reply-To: <20260423235422.1541768-1-kuba@kernel.org>
Hi Jakub,
On Fri, 24 Apr 2026 at 08:56, Jakub Kicinski <kuba@kernel.org> wrote:
> ----------------------------------------------------------------
> Andrew Lunn (12):
> drivers: net: 3com: 3c509: Remove this driver
> drivers: net: 3com: 3c515: Remove this driver
> drivers: net: 3com: 3c574: Remove this driver
> drivers: net: 3com: 3c589: Remove this driver
> drivers: net: amd: lance: Remove this driver
> drivers: net: amd: nmclan: Remove this driver
> drivers: net: smsc: smc9194: Remove this driver
> drivers: net: smsc: smc91c92: Remove this driver
> drivers: net: fujitsu: fmvj18x: Remove this driver
> drivers: net: 8390: AX88190: Remove this driver
> drivers: net: 8390: ultra: Remove this driver
> drivers: net: 8390: wd80x3: Remove this driver
For the drivers I really don't think enough time was given for people
to come out of the woodwork and say they are using one of them and if
they'd be willing to maintain it or not.
If this does get merged and someone wants to put one of them back will
it be as simple as sending a revert?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH net] net: macb: drop in-flight Tx SKBs on close
From: Théo Lebrun @ 2026-04-24 11:45 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Haavard Skinnemoen,
Jeff Garzik, Paolo Valerio, Conor Dooley, netdev, linux-kernel,
Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
Tawfik Bayouk, Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <1030f36978e299123c914917a15b934b@tipi-net.de>
Hello Nicolai,
On Fri Apr 24, 2026 at 12:30 PM CEST, Nicolai Buchwitz wrote:
> On 24.4.2026 12:01, Théo Lebrun wrote:
>> [...]
>
>>
>> for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
>> + dropped = CIRC_CNT(queue->tx_head, queue->tx_tail,
>> + bp->tx_ring_size);
>> + queue->stats.tx_dropped += dropped;
>> + bp->dev->stats.tx_dropped += dropped;
>
> AFAIUI CIRC_CNT counts descriptor slots, not packets. A fragmented
> skb uses multiple slots so tx_dropped would be overcounted?
Ah yes, agreed. dropped is the count of !!macb_tx_skb(queue, tail)->skb.
>> + for (tail = queue->tx_tail; tail != queue->tx_head; tail++)
>> + macb_tx_unmap(bp, macb_tx_skb(queue, tail), 0);
>
> I might be missing something, but couldn't this crash on the
> macb_alloc_consistent() -> out_err path after a previous close
> with in-flight frames?
>
> 1. First close: the new loop runs and frees skbs, but tx_head and
> tx_tail are not reset. kfree(tx_skb) sets it to NULL.
> 2. Second open: macb_alloc_consistent() fails early (e.g. the tx
> dma_alloc_coherent on the first line) and jumps to out_err.
> 3. macb_free_consistent() runs again. CIRC_CNT is non-zero (stale
> from previous session). macb_tx_skb() dereferences queue->tx_skb
> which is NULL.
>
> Or if the failure happens later, the loop would iterate over a
> freshly kmalloc'd (uninitialized) tx_skb array and macb_tx_unmap()
> would read garbage mapping/skb pointers.
>
> Maybe reset tx_head = tx_tail = 0 after the loop, or guard with
> if (queue->tx_skb)?
Ah yes, guarding on queue->tx_skb sounds good for the error case of
macb_alloc_coherent(). I didn't notice we could land in free with
queue->tx_skb NULL. But it is also surprising to keep stall head/tail
cursors. I'll probably reset them as well for V2.
So along the lines of:
static void macb_free_consistent(struct macb *bp)
{
// ... as before ...
for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
if (queue->tx_skb) {
for (tail = queue->tx_tail; tail != queue->tx_head; tail++) {
if (macb_tx_skb(queue, tail)->skb)
dropped++;
macb_tx_unmap(bp, macb_tx_skb(queue, tail), 0);
}
queue->stats.tx_dropped += dropped;
bp->dev->stats.tx_dropped += dropped;
}
kfree(queue->tx_skb);
queue->tx_skb = NULL;
queue->tx_head = 0;
queue->tx_tail = 0;
queue->tx_ring = NULL;
queue->rx_ring = NULL;
}
}
Thanks for the swift review!
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v2] netlink: clean up failed initial dump-start state
From: Michael Bommarito @ 2026-04-24 11:48 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Kuniyuki Iwashima, Kees Cook, Feng Yang, netdev, linux-kernel
In-Reply-To: <20260423185014.08269f73@kernel.org>
On Thu, Apr 23, 2026 at 9:50 PM Jakub Kicinski <kuba@kernel.org> wrote:
> Looks like this changes existing behavior :(
> The tools/testing/selftests/net/netlink-dumps.c test used to always
> see a NLMSG_DONE now it doesn't. Maybe this change is more risk
> than reward?
>
> process nit: please don't post new versions in reply to previous
Sorry about both of those. And yes, I think you're right about
risk-reward. While it's fully unprivileged and could cause issues on
very small devices, it's probably only worth addressing if someone is
touching errout_skb and related branches for some other bigger reason.
Maybe the shared cleanup pattern is helpful in the future but I'll
drop this unless you say otherwise
Thanks,
Mike Bommarito
^ permalink raw reply
* Re: [PATCH 0/9] bitfield: add FIELD_GET_SIGNED()
From: Jonathan Cameron @ 2026-04-24 12:09 UTC (permalink / raw)
To: Yury Norov
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, David Lechner,
Nuno Sá, Andy Shevchenko, Ping-Ke Shih, Richard Cochran,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Alexandre Belloni, Yury Norov, Rasmus Villemoes,
Hans de Goede, Linus Walleij, Sakari Ailus, Salah Triki,
Achim Gratz, Ben Collins, linux-kernel, linux-iio, linux-wireless,
netdev, linux-rtc
In-Reply-To: <20260417173621.368914-1-ynorov@nvidia.com>
On Fri, 17 Apr 2026 13:36:11 -0400
Yury Norov <ynorov@nvidia.com> wrote:
> The bitfields are designed in assumption that fields contain unsigned
> integer values, thus extracting the values from the field implies
> zero-extending.
>
> Some drivers need to sign-extend their fields, and currently do it like:
>
> dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
>
> It's error-prone because it relies on user to provide the correct
> index of the most significant bit.
>
> This series adds a signed version of FIELD_GET(), which is the more
> convenient and compiles (on x86_64) to just a couple instructions:
> shl and sar.
>
> Patch #1 adds FIELD_GET_SIGNED(), and the rest of the series applies it
> tree-wide.
>
Just a quick heads up that I'm beginning to assume that this series
will land in some form. If it does can we do it as an immutable branch
as I'm suggesting it gets used in some other patches in that should land
in the new cycle.
Thanks,
Jonathan
> Yury Norov (9):
> bitfield: add FIELD_GET_SIGNED()
> x86/extable: switch to using FIELD_GET_SIGNED()
> iio: intel_dc_ti_adc: switch to using
> iio: magnetometer: yas530: switch to using FIELD_GET_SIGNED()
> iio: pressure: bmp280: switch to using
> iio: mcp9600: switch to using FIELD_GET_SIGNED()
> wifi: rtw89: switch to using FIELD_GET_SIGNED()
> rtc: rv3032: switch to using FIELD_GET_SIGNED()
> ptp: switch to using FIELD_GET_SIGNED()
>
> arch/x86/include/asm/extable_fixup_types.h | 13 ++++---------
> arch/x86/mm/extable.c | 2 +-
> drivers/iio/adc/intel_dc_ti_adc.c | 4 ++--
> drivers/iio/magnetometer/yamaha-yas530.c | 12 ++++++------
> drivers/iio/pressure/bmp280-core.c | 2 +-
> drivers/iio/temperature/mcp9600.c | 2 +-
> .../net/wireless/realtek/rtw89/rtw8852a_rfk.c | 4 ++--
> .../net/wireless/realtek/rtw89/rtw8852b_common.c | 4 ++--
> .../net/wireless/realtek/rtw89/rtw8852b_rfk.c | 4 ++--
> drivers/net/wireless/realtek/rtw89/rtw8852c.c | 4 ++--
> drivers/ptp/ptp_fc3.c | 4 ++--
> drivers/rtc/rtc-rv3032.c | 2 +-
> include/linux/bitfield.h | 16 ++++++++++++++++
> 13 files changed, 42 insertions(+), 31 deletions(-)
>
^ permalink raw reply
* Re: [PATCH net] net: mana: Optimize irq affinity for low vcpu configs
From: Dipayaan Roy @ 2026-04-24 12:21 UTC (permalink / raw)
To: Shradha Gupta
Cc: Dexuan Cui, Wei Liu, Haiyang Zhang, K. Y. Srinivasan, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Konstantin Taranov, Simon Horman, Erni Sri Satya Vennela,
Shiraz Saleem, Michael Kelley, Long Li, Yury Norov, linux-hyperv,
linux-kernel, netdev, Paul Rosswurm, Shradha Gupta,
Saurabh Singh Sengar, stable
In-Reply-To: <20260424061702.1442618-1-shradhagupta@linux.microsoft.com>
On Thu, Apr 23, 2026 at 11:17:00PM -0700, Shradha Gupta wrote:
> In mana driver, the number of IRQs allocated are capped by the
> min(num_cpu + 1, queue count). In cases, where the IRQ count is greater
> than the vcpu count, we want to utilize all the vcpus, irrespective of
> their NUMA/core bindings.
>
> This is important, especially in the envs where number of vcpus are so
> few that the softIRQ handling overhead on two IRQs on the same vcpu is
> much more than their overheads if they were spread across sibling vcpus
>
> This behaviour is more evident with dynamic IRQ allocation. Since MANA
> IRQs are assigned at a later stage compared to static allocation, other
> device IRQs may already be affinitized to the vCPUs. As a result, IRQ
> weights become imbalanced, causing multiple MANA IRQs to land on the
> same vCPU.
>
> In such cases when many parallel TCP connections are tested, the
> throughput drops significantly
>
> Test envs:
> =======================================================
> Case 1: without this patch
> =======================================================
> 4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue)
>
> TYPE effective vCPU aff
> =======================================================
> IRQ0: HWC 0
> IRQ1: mana_q1 0
> IRQ2: mana_q2 2
> IRQ3: mana_q3 0
> IRQ4: mana_q4 3
>
> %soft on each vCPU(mpstat -P ALL 1) on receiver
> vCPU 0 1 2 3
> =======================================================
> pass 1: 38.85 0.03 24.89 24.65
> pass 2: 39.15 0.03 24.57 25.28
> pass 3: 40.36 0.03 23.20 23.17
>
> =======================================================
> Case 2: with this patch
> =======================================================
> 4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue)
>
> TYPE effective vCPU aff
> =======================================================
> IRQ0: HWC 0
> IRQ1: mana_q1 0
> IRQ2: mana_q2 1
> IRQ3: mana_q3 2
> IRQ4: mana_q4 3
>
> %soft on each vCPU(mpstat -P ALL 1) on receiver
> vCPU 0 1 2 3
> =======================================================
> pass 1: 15.42 15.85 14.99 14.51
> pass 2: 15.53 15.94 15.81 15.93
> pass 3: 16.41 16.35 16.40 16.36
>
> =======================================================
> Throughput Impact(in Gbps, same env)
> =======================================================
> TCP conn with patch w/o patch
> 20480 15.65 7.73
> 10240 15.63 8.93
> 8192 15.64 9.69
> 6144 15.64 13.16
> 4096 15.69 15.75
> 2048 15.69 15.83
> 1024 15.71 15.28
>
> Fixes: 755391121038 ("net: mana: Allocate MSI-X vectors dynamically")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
> Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> .../net/ethernet/microsoft/mana/gdma_main.c | 35 +++++++++++++++++--
> 1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> index 098fbda0d128..433c044d53c6 100644
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> @@ -1672,6 +1672,23 @@ static int irq_setup(unsigned int *irqs, unsigned int len, int node,
> return 0;
> }
>
> +static int irq_setup_linear(unsigned int *irqs, unsigned int len)
> +{
> + int cpu;
> +
> + rcu_read_lock();
We do not need to call rcu_read_lock here, as the caller of this
function has already acquired cpus_read_lock.
> + for_each_online_cpu(cpu) {
> + if (len <= 0)
len is unsigned here so <= doesnot makes sense. PLease change it to int
or better use if(!len)
> + break;
> +
> + irq_set_affinity_and_hint(*irqs++, cpumask_of(cpu));
> + len--;
> + }
> + rcu_read_unlock();
> +
> + return 0;
> +}
> +
> static int mana_gd_setup_dyn_irqs(struct pci_dev *pdev, int nvec)
> {
> struct gdma_context *gc = pci_get_drvdata(pdev);
> @@ -1722,10 +1739,24 @@ static int mana_gd_setup_dyn_irqs(struct pci_dev *pdev, int nvec)
> * first CPU sibling group since they are already affinitized to HWC IRQ
> */
> cpus_read_lock();
> - if (gc->num_msix_usable <= num_online_cpus())
> + if (gc->num_msix_usable <= num_online_cpus()) {
> skip_first_cpu = true;
> + err = irq_setup(irqs, nvec, gc->numa_node, skip_first_cpu);
> + } else {
> + /*
> + * In case our IRQs are more than num_online_cpus, we try to
> + * make sure we are using all vcpus. In such a case NUMA or
> + * CPU core affinity does not matter.
> + * Note that in this case the total mana IRQ should always be
> + * num_online_cpu + 1. The first HWC IRQ is already handled
> + * in HWC setup calls
> + * So, the nvec value in this path should always be equal to
> + * num_online_cpu
nit: typo: should be num_online_cpus
> + */
> + WARN_ON(nvec > num_online_cpus());
> + err = irq_setup_linear(irqs, nvec);
> + }
>
> - err = irq_setup(irqs, nvec, gc->numa_node, skip_first_cpu);
> if (err) {
> cpus_read_unlock();
> goto free_irq;
>
> base-commit: e728258debd553c95d2e70f9cd97c9fde27c7130
> --
> 2.34.1
>
Regards
Dipayaan Roy
^ permalink raw reply
* Re: [PATCH RFC net-next 4/4] net: phy: own phydev->psec via PSE notifier and remove fwnode_mdio hook
From: Kory Maincent @ 2026-04-24 12:36 UTC (permalink / raw)
To: Corey Leavitt via B4 Relay
Cc: corey, Oleksij Rempel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Heiner Kallweit, Russell King,
Andrew Lunn, netdev, linux-kernel
In-Reply-To: <20260423-pse-notifier-decouple-v1-4-86ed750a9d62@leavitt.info>
On Thu, 23 Apr 2026 01:42:17 -0600
Corey Leavitt via B4 Relay <devnull+corey.leavitt.info@kernel.org> wrote:
> From: Corey Leavitt <corey@leavitt.info>
>
> Transfer ownership of phydev->psec from fwnode_mdio to the phy
> subsystem itself. The phy subsystem now subscribes to the pse-pd
> notifier chain and manages psec attach/detach in response to PSE
> controller lifecycle events, while fwnode_mdio loses its PSE
> awareness entirely.
>
> Split phy_device_register() into a public entry point that takes
> rtnl_lock() and a phy_device_register_locked() variant that assumes
> rtnl is already held. Callers that already hold rtnl (the SFP
> module state machine via __sfp_sm_event) use the _locked form to
> avoid deadlock; all other callers use the unchanged public API.
> This pair mirrors the register_netdevice() / register_netdev()
> split convention already established in the core networking stack.
> rtnl must span the full registration sequence through device_add(),
> not just phy_try_attach_pse(): a PSE_REGISTERED event firing between
> a narrow attach lock and device_add() would walk mdio_bus_type, find
> the phy not yet on the bus, and leave it permanently unattached.
>
> With rtnl held across the full registration sequence:
>
> - At phy_device_register_locked(), phy_try_attach_pse() attempts
> an of_pse_control_get() for phys whose DT pses phandle resolves
> now. If the controller is already registered, psec is attached
> before device_add() makes the phy visible on mdio_bus_type.
> If the controller is not yet registered, the swallow-error path
> leaves psec NULL and relies on the subsequent notifier event.
>
> - On PSE_REGISTERED: an rtnl-guarded bus walk retries the attach
> for every registered phy whose psec is still NULL. This is the
> "phy was enumerated before the PSE controller loaded" case,
> which is the root cause of the boot-time probe-retry storm on
> systems with a modular PSE controller driver. Because the
> pse_controller_notifier is fired synchronously, a concurrent
> pse_controller_register() either (a) completes list_add and
> releases pse_list_mutex before this function takes rtnl, in
> which case phy_try_attach_pse() finds the controller in the
> list and attaches; or (b) fires its notifier during this
> function, in which case the callback blocks on rtnl until this
> function returns, then walks the bus and finds the phy fully
> registered (attaching if psec is still NULL).
>
> - On PSE_UNREGISTERED: an rtnl-guarded bus walk releases every
> phydev->psec that targets the departing controller before
> pse_release_pis() frees pcdev->pi. Without this, a phy still
> holding a pse_control reference would cause a use-after-free
> in __pse_control_release's pcdev->pi[psec->id] access, and the
> PSE driver module could not finish unloading while any phy
> still held a reference via module_put().
>
> Introduce phy_try_attach_pse() as the rtnl-guarded helper used by
> both the register path and the notifier walk. Holding rtnl across
> of_pse_control_get() is safe because pse_list_mutex is never held
> in the opposite order.
>
> Expose pse_control_matches_pcdev() as a predicate so subscribers
> can identify which of their held pse_control references target a
> given controller, without leaking the struct pse_controller_dev *
> out of pse_control opacity.
>
> Move the final pse_control_put() of phydev->psec from
> phy_device_remove() to phy_device_release(). The kobject release
> callback runs only after every reference on the device has been
> dropped, including the bus iterator references taken by
> bus_for_each_dev() in the notifier walk, which means by the time
> release fires no concurrent reader or writer of phydev->psec can
> exist. The mdio_bus_type klist is set up in bus_register() with
> klist_devices_get() / klist_devices_put() (drivers/base/bus.c),
> which bracket each iteration step with get_device() / put_device()
> on the underlying struct device; that reference defers the release
> callback from firing until the walk has advanced past this phy.
> Keeping phy_device_remove() unchanged avoids introducing a new
> locking contract on its many callers (sfp, fixed_phy, xgbe, hns,
> netsec, bcm_sf2, mdiobus_unregister).
>
> Finally, delete fwnode_find_pse_control() and its call site in
> fwnode_mdiobus_register_phy(), and drop the PSE header from
> fwnode_mdio.c. This removes the probe-time -EPROBE_DEFER coupling
> between mdio and pse-pd that caused the boot-hang regression on
> systems with a modular PSE controller driver and a DT phy with a
> pses phandle: the MDIO/DSA probe no longer sees any PSE-originated
> -EPROBE_DEFER, so the probe-retry storm is gone. fwnode_mdio is
> now PSE-agnostic.
>
> Fixes: fa2f0454174c ("net: pse-pd: Introduce attached_phydev to pse control")
This patch depends on the other patches (2 and 3) which do not have any fixes
tag. So either all of them have the fixes tag or none of them have it.
Except from this, your design seems a great idea!
The only thing that puzzle me is to have the RTNLOCK hold in the
phy_device_register function. This is an important change but I am not a netdev
sufficient expert to know if that could break things.
Jakub, Russell what do you think?
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH net v3] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Daniel Golle @ 2026-04-24 12:37 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>
---
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 | 69 ++++++++++++++++++++++++++++++++++++++--
drivers/net/dsa/mt7530.h | 8 +++++
2 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index b9423389c2ef..9733ff9fc322 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,48 @@ static void mt7530_get_stats64(struct dsa_switch *ds, int port,
&storage->rx_crc_errors);
}
+static void mt7530_stats_poll(struct work_struct *work)
+{
+ struct mt7530_priv *priv = container_of(work, struct mt7530_priv,
+ stats_work.work);
+ 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);
+ }
+
+ 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_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 +3181,24 @@ mt753x_setup(struct dsa_switch *ds)
if (ret && priv->irq_domain)
mt7530_free_mdio_irq(priv);
+ if (!ret && priv->bus) {
+ spin_lock_init(&priv->stats_lock);
+ INIT_DELAYED_WORK(&priv->stats_work, mt7530_stats_poll);
+ 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 +3316,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,
@@ -3409,6 +3469,9 @@ mt7530_remove_common(struct mt7530_priv *priv)
dsa_unregister_switch(priv->ds);
+ if (priv->bus)
+ cancel_delayed_work_sync(&priv->stats_work);
+
mutex_destroy(&priv->reg_mutex);
}
EXPORT_SYMBOL_GPL(mt7530_remove_common);
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.54.0
^ permalink raw reply related
* RE: [PATCH net v4 4/4] ice: skip unnecessary VF reset when setting trust
From: Jose Ignacio Tornos Martinez @ 2026-04-24 12:40 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: anthony.l.nguyen, davem, edumazet, horms, intel-wired-lan,
jacob.e.keller, jesse.brandeburg, jtornosm, kuba, netdev, pabeni,
przemyslaw.kitszel
In-Reply-To: <IA3PR11MB89861630A18B1BE712F14E68E52B2@IA3PR11MB8986.namprd11.prod.outlook.com>
Hello Aleksandr,
>>> You declare ice_vf_clear_all_promisc_modes() returning int, but
>>> ignore the return value.
>>> Looks suspicious isn't it?
>> Well, it is used like that when the funciton is called locally (the
>> function is not modifiedi, just made public), and really my intention
>> was to clean as much as possible (so error checking is not necessary).
>> In my opinion it would be enough to warn about the possible problems
>> (already done in the existing function).
> Can you go extra mile and add error code handling?
> Or at least document it in the code why you don't do it?
Ok, I can add the error handling in ice_setup_vf_trust and an extra warning
to indicate that promiscuous mode clear failed when revoking trust.
Just let me wait a bit longer for more possible reviews to create the next
version of the series.
Thanks
Best regards
Jose Ignacio
^ permalink raw reply
* Re: [PATCH RFC net-next 0/4] net: pse-pd: decouple controller lookup from MDIO probe
From: Kory Maincent @ 2026-04-24 12:41 UTC (permalink / raw)
To: Corey Leavitt
Cc: Carlo Szelinsky, Oleksij Rempel, Andrew Lunn, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Heiner Kallweit, Russell King, netdev, linux-kernel
In-Reply-To: <177693772506.254295.6378636892307427408@leavitt.info>
On Thu, 23 Apr 2026 09:48:53 +0000
Corey Leavitt <corey@leavitt.info> wrote:
> Hi Kory,
>
> Thanks for the pointer -- I had not seen Carlo's thread; I should have
> searched lore before sending and will do so before v2. Adding Carlo on
> cc.
>
> Having read it end-to-end, my read of the state as of 2026-04-13 was
> that the conversation had narrowed to two open directions: propagate
> EPROBE_DEFER further up into phylink/MAC probe (Andrew/Russell), or
> resolve psec at PSE controller register time (your msg on 9 Apr,
> "save the phandle ... then at PSE register time look for each PHY and
> try to resolve every unresolved phandle"). Nothing concrete had been
> posted for either.
>
> This RFC implements the second direction. pse_core publishes a
> BLOCKING_NOTIFIER chain with REGISTERED / UNREGISTERED events,
> phy_device subscribes, and psec ownership moves from fwnode_mdio probe
> into the notifier handler. Concretely with respect to points raised in
> the earlier thread:
>
> - fwnode_mdio loses PSE awareness entirely, so the MDIO bus scan no
> longer sees -EPROBE_DEFER from PSE lookup. Consistent with
> Andrew's point that bus and device lifecycles are separate.
>
> - psec is acquired at PSE register time, before
> regulator_late_cleanup (30s) can run. Carlo's admin_state_synced
> guard (his patch 1) therefore isn't needed in this model. psec
> resolution happens eagerly on the REGISTERED event rather than
> lazily on first ethtool access, so his patch 2 is also not needed.
> And because fwnode_mdio no longer looks up PSE at all, the
> non-fatal EPROBE_DEFER handling there (patch 3) drops out. This
> series is a different architectural shape, not an increment on
> his v2.
>
> - Oleksij's concern about lazy resolution dropping UAPI
> notifications is addressed: the notifier fires at register time,
> so boot-time observer semantics are preserved.
>
> - One caveat I already owe a fix for in v2: the attach helper in
> phy_device currently treats every error from of_pse_control_get()
> as retry-on-notifier, including non-transient ones. Carlo's v2
> patch 3 was careful to differentiate -EPROBE_DEFER from bad-DT
> errors at the fwnode_mdio lookup site (which matches his msg 1
> concern about catching broken bindings at boot rather than
> silently later). I need to preserve that discrimination at the
> notifier-handler site -- phydev_warn() on anything other than
> -EPROBE_DEFER. Trivial, but worth flagging.
>
> - The DSA genphy force-bind sequence Carlo hit
> (phy_attach_direct -> device_bind_driver -> deferred retry
> skipped) does not apply, because psec attachment is not tied to
> phy_probe.
>
> - Patch 1 of this series scopes the regulator handle held by
> pse_control to its own kref lifetime, fixing a latent
> dangling-handle sequence that the notifier unregister path makes
> reachable. This is a separate regulator-lifetime bug from the one
> Carlo's patch 1 addresses.
This seems to provide a solution to all our problems, and it is well designed.
Carlo, it would be nice if you could test it on your side.
> Validated end-to-end on a Cudy C200P (MT7621 DSA + i2c IP804AR as
> module), with lockdep active, across the i2c driver unbind/rebind
> cycle that triggers UNREGISTERED -> REGISTERED on the live system.
> The cover letter has the full evidence.
>
> I would welcome your view on whether this is the shape you had in
> mind on 9 Apr, or whether the MDI-based binding you raised with
> Maxime is the better endpoint and we should be reshaping around that.
> Happy to keep this RFC as the scaffolding either way.
After a second thought, MDI-based binding is currently not in the pipe and we
should solve this without it for now.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2] mptcp: do not drop partial packets
From: Simon Horman @ 2026-04-24 13:20 UTC (permalink / raw)
To: shardulsb08
Cc: 'Simon Horman', pabeni, matttbe, martineau, geliang,
davem, edumazet, kuba, netdev, mptcp, linux-kernel, janak,
kalpan.jani, shardul.b
In-Reply-To: <20260422143931.43281-1-shardul.b@mpiricsoftware.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
---
mptcp: do not drop partial packets
This commit modifies the handling of out-of-order packets where
map_seq < ack_seq < end_seq. Instead of dropping the entire packet,
it skips the already-acknowledged bytes and enqueues the remainder.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/600
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index fbffd3a43fe86..4e9fba692a701 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
[ ... ]
> @@ -397,12 +397,24 @@ static bool __mptcp_move_skb(struct sock *sk, struct sk_buff *skb)
[ ... ]
> + /* Partial packet: map_seq < ack_seq < end_seq.
> + * Skip the already-acked bytes and enqueue the new data.
> + */
> + copy_len = MPTCP_SKB_CB(skb)->end_seq - msk->ack_seq;
> + MPTCP_SKB_CB(skb)->offset += msk->ack_seq - MPTCP_SKB_CB(skb)->map_seq;
> + msk->bytes_received += copy_len;
> + WRITE_ONCE(msk->ack_seq, msk->ack_seq + copy_len);
Should MPTCP_SKB_CB(skb)->map_seq also be advanced here to reflect the newly
adjusted offset?
If map_seq remains stale after skipping the already-acked bytes, does this
cause mptcp_inq_hint() to overestimate the amount of unread data?
Looking at the hint calculation, it calculates the unread bytes using
READ_ONCE(msk->ack_seq) - MPTCP_SKB_CB(skb)->map_seq for the first
enqueued SKB.
If inq_hint is artificially large, could this corrupt the ioctl(FIONREAD)
and TCP_INQ cmsg values returned to userspace?
Furthermore, could this suppress receive window auto-tuning? In
mptcp_rcv_space_adjust(), an artificially large inq_hint might cause
the calculation copied -= mptcp_inq_hint(sk) to become negative, which
would stall window growth.
> +
> + skb_set_owner_r(skb, sk);
> + __skb_queue_tail(&sk->sk_receive_queue, skb);
> + return true;
> }
^ permalink raw reply
* [PATCH 6.6 132/166] i40e: Fix preempt count leak in napi poll tracepoint
From: Greg Kroah-Hartman @ 2026-04-24 13:30 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Thomas Gleixner, Tony Nguyen,
Przemek Kitszel, intel-wired-lan, netdev, Joe Damato,
Aleksandr Loktionov, Charles Xu, Sasha Levin
In-Reply-To: <20260424132532.812258529@linuxfoundation.org>
6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <tglx@kernel.org>
[ Upstream commit 4b3d54a85bd37ebf2d9836f0d0de775c0ff21af9 ]
Using get_cpu() in the tracepoint assignment causes an obvious preempt
count leak because nothing invokes put_cpu() to undo it:
softirq: huh, entered softirq 3 NET_RX with preempt_count 00000100, exited with 00000101?
This clearly has seen a lot of testing in the last 3+ years...
Use smp_processor_id() instead.
Fixes: 6d4d584a7ea8 ("i40e: Add i40e_napi_poll tracepoint")
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
Reviewed-by: Joe Damato <joe@dama.to>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Charles Xu <charles_xu@189.cn>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/i40e/i40e_trace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_trace.h b/drivers/net/ethernet/intel/i40e/i40e_trace.h
index 33b4e30f5e004..9b735a9e21140 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_trace.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_trace.h
@@ -88,7 +88,7 @@ TRACE_EVENT(i40e_napi_poll,
__entry->rx_clean_complete = rx_clean_complete;
__entry->tx_clean_complete = tx_clean_complete;
__entry->irq_num = q->irq_num;
- __entry->curr_cpu = get_cpu();
+ __entry->curr_cpu = smp_processor_id();
__assign_str(qname, q->name);
__assign_str(dev_name, napi->dev ? napi->dev->name : NO_DEV);
__assign_bitmask(irq_affinity, cpumask_bits(&q->affinity_mask),
--
2.53.0
^ permalink raw reply related
* Re: [PATCH bpf-next v3 0/9] Refactor verifier object relationship tracking
From: Alexei Starovoitov @ 2026-04-24 13:55 UTC (permalink / raw)
To: Amery Hung
Cc: bpf, netdev, andrii, daniel, eddyz87, memxor, martin.lau,
mykyta.yatsenko5, kernel-team
In-Reply-To: <CAMB2axMg=Y5q=9CEFs=8rHLQJipT-5rYkg3wp2BhWgDwVvOUQw@mail.gmail.com>
On Thu Apr 23, 2026 at 10:44 PM PDT, Amery Hung wrote:
> On Thu, Apr 23, 2026 at 5:55 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On Tue Apr 21, 2026 at 3:10 PM PDT, Amery Hung wrote:
>> >
>> > (3) Referenced dynptr with referenced parent:
>> >
>> > file (1,1,0)
>> > ^ ^
>> > bpf_dynptr_from_file | +-------------------------------+
>> > | bpf_dynptr_clone(A, C) |
>> > dynptr A (2,3,1) dynptr C (4,3,1)
>> > ^ ^
>> > | |
>> > dynptr A and C have the same lifetime
>>
>> If I understand the proposal correctly above should be:
>>
>> file (1,0,0)
>> ^
>> bpf_dynptr_from_file +-------------------------------+
>>
>> ref_obj_id will be inited bpf_dynptr_clone() as 3 into A and C.
>> but original file->ref_obj_id will be zero.
>>
>> ?
>
> This is the existing behavior. bpf_get_task_exe_file() is tagged with
> (KF_ACQUIRE | KF_RET_NULL). Therefore, file will have id and
> ref_obj_id both initialized to the same value. Here is the
> corresponding verifier code:
>
> if (is_kfunc_acquire(&meta)) {
> int id = acquire_reference(env, insn_idx);
>
> if (id < 0)
> return id;
> if (is_kfunc_ret_null(&meta))
> regs[BPF_REG_0].id = id;
> regs[BPF_REG_0].ref_obj_id = id;
ok, but the arrow should still point to first '1', since that's
what parent_id inherits?
^ permalink raw reply
* Re: [PATCH bpf v2 1/3] bpf, tcx: reject offloaded programs on attach
From: Alexei Starovoitov @ 2026-04-24 13:57 UTC (permalink / raw)
To: Jiayuan Chen, bpf
Cc: Yinhao Hu, Kaiyan Mei, Dongliang Mu, Daniel Borkmann,
Nikolay Aleksandrov, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Martin KaFai Lau, John Fastabend,
Stanislav Fomichev, Alexei Starovoitov, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Song Liu,
Yonghong Song, Jiri Olsa, Simon Horman, Jesper Dangaard Brouer,
Willem de Bruijn, Samiullah Khawaja, Hangbin Liu, Krishna Kumar,
Kuniyuki Iwashima, Toke Høiland-Jørgensen, netdev,
linux-kernel
In-Reply-To: <20260424104201.217604-2-jiayuan.chen@linux.dev>
On Fri Apr 24, 2026 at 3:41 AM PDT, Jiayuan Chen wrote:
> An offloaded prog's bpf_func is replaced by bpf_prog_warn_on_exec(),
> since it's supposed to run on the NIC, not the host. But tcx doesn't
> check this and happily attaches it to the software path, so the first
> packet hits the WARN.
>
> XDP already guards this in dev_xdp_attach(); tcx just never got the
> same check. Add it to tcx_prog_attach(), tcx_link_attach() and also
> tcx_link_update() so the fix cannot be bypassed by loading a normal
> program and then swapping it out via BPF_LINK_UPDATE.
>
> Use bpf_prog_is_offloaded() rather than bpf_prog_is_dev_bound() +
> bpf_offload_dev_match() (as XDP does): bpf_prog_dev_bound_init()
> already rejects BPF_F_XDP_DEV_BOUND_ONLY for BPF_PROG_TYPE_SCHED_CLS,
> so a dev-bound SCHED_CLS program is always offloaded. The simpler
> check is sufficient and also rejects attaching a program offloaded to
> device A onto device B.
>
> Fixes: e420bed025071 ("bpf: Add fd-based tcx multi-prog infra with link support")
> 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/64d8e2b5-a214-4f3c-b9e8-bcedbcb2c602@hust.edu.cn/
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
> kernel/bpf/tcx.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/kernel/bpf/tcx.c b/kernel/bpf/tcx.c
> index 02db0113b8e7c..1144627483d53 100644
> --- a/kernel/bpf/tcx.c
> +++ b/kernel/bpf/tcx.c
> @@ -16,6 +16,9 @@ int tcx_prog_attach(const union bpf_attr *attr, struct bpf_prog *prog)
> struct net_device *dev;
> int ret;
>
> + if (bpf_prog_is_offloaded(prog->aux))
> + return -EINVAL;
> +
instead of sprinkling the check everywhere do it at the source of the bug.
pw-bot: cr
^ permalink raw reply
* netdev, Your order EBFA0471GF was processed
From: anithambabazi1983 @ 2026-04-24 13:58 UTC (permalink / raw)
To: netdev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
Sub: Your PayPal,Inc. Account is Now Verified
Dear Account Holder,
We've successfully completed your account verification. Your PayPal,Inc. account is now fully active.
Verification Details
• Process: Standard authentication
• Authorization: $261.6 (temporary hold)
• Reference: ZKXPWQMT91
About the Authorization
Temporary hold only (not a charge)
Automatically released in 1-3 business days
No action required on your part
Customer Support
For any questions:
📞 (803)-886-5964 (24/7)
Welcome to the PayPal,Inc. community!
Best regards,
The PayPal,Inc. Team
^ permalink raw reply
* Re: [PATCH iwl-next v3 3/3] igc: add support for forcing link speed without autonegotiation
From: Simon Horman @ 2026-04-24 13:59 UTC (permalink / raw)
To: KhaiWenTan
Cc: anthony.l.nguyen, przemyslaw.kitszel, andrew+netdev, davem,
edumazet, kuba, pabeni, intel-wired-lan, netdev, linux-kernel,
faizal.abdul.rahim, hong.aun.looi, khai.wen.tan, Faizal Rahim,
Looi
In-Reply-To: <20260422155701.7420-4-khai.wen.tan@linux.intel.com>
On Wed, Apr 22, 2026 at 11:57:01PM +0800, KhaiWenTan wrote:
> From: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
>
> Allow users to force 10/100 Mb/s link speed and duplex via ethtool
> when autonegotiation is disabled. Previously, the driver rejected
> these requests with "Force mode currently not supported.".
>
> Forcing at 1000 Mb/s and 2500 Mb/s is not supported.
>
> Reviewed-by: Looi, Hong Aun <hong.aun.looi@intel.com>
> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> Signed-off-by: KhaiWenTan <khai.wen.tan@linux.intel.com>
...
> diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c
...
> @@ -2000,6 +2013,41 @@ static int igc_ethtool_get_link_ksettings(struct net_device *netdev,
> return 0;
> }
>
> +/**
> + * igc_handle_autoneg_disabled - Configure forced speed/duplex settings
> + * @adapter: private driver structure
> + * @speed: requested speed (must be SPEED_10 or SPEED_100)
> + * @duplex: requested duplex
> + *
> + * Records forced speed/duplex when autoneg is disabled.
> + * Caller must validate speed before calling this function.
> + */
> +static void igc_handle_autoneg_disabled(struct igc_adapter *adapter, u32 speed,
> + u8 duplex)
> +{
> + struct igc_mac_info *mac = &adapter->hw.mac;
> +
> + switch (speed) {
> + case SPEED_10:
> + mac->forced_speed_duplex = (duplex == DUPLEX_FULL) ?
> + IGC_FORCED_10F : IGC_FORCED_10H;
> + break;
> + case SPEED_100:
> + mac->forced_speed_duplex = (duplex == DUPLEX_FULL) ?
> + IGC_FORCED_100F : IGC_FORCED_100H;
> + break;
> + default:
> + WARN_ONCE(1, "Unsupported speed %u\n", speed);
> + return;
> + }
> +
> + mac->autoneg_enabled = false;
> +
> + /* Half-duplex cannot support flow control per IEEE 802.3 */
> + if (duplex != DUPLEX_FULL)
> + adapter->hw.fc.requested_mode = igc_fc_none;
> +}
> +
> /**
> * igc_handle_autoneg_enabled - Configure autonegotiation advertisement
> * @adapter: private driver structure
> @@ -2038,6 +2086,7 @@ static void igc_handle_autoneg_enabled(struct igc_adapter *adapter,
> 10baseT_Half))
> advertised |= ADVERTISE_10_HALF;
>
> + hw->mac.autoneg_enabled = true;
> hw->phy.autoneg_advertised = advertised;
> if (adapter->fc_autoneg)
> hw->fc.requested_mode = igc_fc_default;
> @@ -2071,14 +2120,20 @@ igc_ethtool_set_link_ksettings(struct net_device *netdev,
> }
> }
>
> + if (cmd->base.autoneg == AUTONEG_DISABLE &&
> + cmd->base.speed != SPEED_10 && cmd->base.speed != SPEED_100) {
> + netdev_info(dev, "Unsupported speed for forced link\n");
> + return -EINVAL;
> + }
The condition above verifies speed only if autoneg is AUTONEG_DISABLE.
> +
> while (test_and_set_bit(__IGC_RESETTING, &adapter->state))
> usleep_range(1000, 2000);
>
> - if (cmd->base.autoneg == AUTONEG_ENABLE) {
> + if (cmd->base.autoneg == AUTONEG_ENABLE)
> igc_handle_autoneg_enabled(adapter, cmd);
> - } else {
> - netdev_info(dev, "Force mode currently not supported\n");
> - }
> + else
> + igc_handle_autoneg_disabled(adapter, cmd->base.speed,
> + cmd->base.duplex);
But here igc_handle_autoneg_disabled, which relies on speed having been
verified, is called if autoneg is not AUTONEG_ENABLE.
If autoneg is AUTONEG_DISABLE here, then all is good.
But if it is neither AUTONEG_DISABLE nor AUTONEG_ENABLE then we
are in trouble.
I suggest verifying autoneg is either AUTONEG_ENABLE or AUTONEG_DISABLE
earlier in this function.
The above is based on my analysis of review AI generated review from Sashiko.
I believe that addressing autoneg verification address the review by
Sashiko that is relevant to the progress of this patch.
...
^ permalink raw reply
* Re: [GIT PULL] Networking deletions for 7.1
From: Jakub Kicinski @ 2026-04-24 14:28 UTC (permalink / raw)
To: Daniel Palmer; +Cc: torvalds, davem, netdev, linux-kernel, pabeni
In-Reply-To: <CAFr9PXnNVL4mUEu19jMu2sPkOucGK7Q32iB-7FY8eUpKZY_XJA@mail.gmail.com>
On Fri, 24 Apr 2026 20:14:51 +0900 Daniel Palmer wrote:
> > ----------------------------------------------------------------
> > Andrew Lunn (12):
> > drivers: net: 3com: 3c509: Remove this driver
> > drivers: net: 3com: 3c515: Remove this driver
> > drivers: net: 3com: 3c574: Remove this driver
> > drivers: net: 3com: 3c589: Remove this driver
> > drivers: net: amd: lance: Remove this driver
> > drivers: net: amd: nmclan: Remove this driver
> > drivers: net: smsc: smc9194: Remove this driver
> > drivers: net: smsc: smc91c92: Remove this driver
> > drivers: net: fujitsu: fmvj18x: Remove this driver
> > drivers: net: 8390: AX88190: Remove this driver
> > drivers: net: 8390: ultra: Remove this driver
> > drivers: net: 8390: wd80x3: Remove this driver
>
> For the drivers I really don't think enough time was given for people
> to come out of the woodwork and say they are using one of them and if
> they'd be willing to maintain it or not.
Real users show up a few releases later. Waiting for more responses on
the ML has little value.
> If this does get merged and someone wants to put one of them back will
> it be as simple as sending a revert?
For the users? Normally they just send an email and we handle
the reverts. It happened multiple times in the past, we remove
a few drivers in each release.
^ permalink raw reply
* Re: [PATCH 1/9] bitfield: add FIELD_GET_SIGNED()
From: David Laight @ 2026-04-24 14:50 UTC (permalink / raw)
To: Johannes Berg
Cc: Yury Norov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Ping-Ke Shih, Richard Cochran, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexandre Belloni,
Yury Norov, Rasmus Villemoes, Hans de Goede, Linus Walleij,
Sakari Ailus, Salah Triki, Achim Gratz, Ben Collins, linux-kernel,
linux-iio, linux-wireless, netdev, linux-rtc
In-Reply-To: <6170788fcab2ec835597e3d7411928d36850c20a.camel@sipsolutions.net>
On Mon, 20 Apr 2026 10:43:08 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
...
> I (personally) tend to prefer the "__MAKE_OP" versions (*_get_bits()
> etc.), in particular because WiFi and firmware interfaces deal a lot
> with fixed endian fields.
>
> Any chance it'd be simple to generate u32_get_bits_signed() etc.? Could
> be especially useful for le32_get_bits_signed() for example, to have the
> endian conversion built-in unlike FIELD_GET_SIGNED().
The problem is that the number of options explodes.
You need PREP/GET/GET_SIGNED functions x_64() x_64le() x_64be() x_32() x_32le()
x_32be() x_16le() and x_16be().
I make that 24 functions.
For UPDATE you also need x_16() and x_8() for another 10.
So at least 34 definitions - it is all getting silly.
(And I've excluded the pointless 8/16 bit functions where the result
is promoted to signed int.)
Then you have the problem that some (common) architectures don't have
byteswap instructions, but do have byteswapping memory accesses (maybe not
16bit). Which means that is it generally better to byteswap the value
before passing to FIELD_GET() and after building the full 'word' using
FIELD_PREP() (and just | for single bits).
(Except it is probably always better to byteswap constants.)
It is also worth nothing that FIELD_PREP() will reject requests to
fill signed fields with negative constants.
David
>
> johannes
>
^ permalink raw reply
* [PATCH net] neigh: let neigh_xmit take skb ownership
From: Florian Westphal @ 2026-04-24 14:58 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, horms,
kuniyu, idosch, Florian Westphal
neigh_xmit always releases the skb, except when no neighbour table is
found. But even the first added user of neigh_xmit (mpls) relied on
neigh_xmit to release the skb (or queue it for tx).
sashiko reported:
If neigh_xmit() is called with an uninitialized neighbor table (for
example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT
and bypasses its internal out_kfree_skb error path. Because the return
value of neigh_xmit() is ignored here, does this leak the SKB?
Assume full ownership and remove the last code path that doesn't
xmit or free skb.
Fixes: 4fd3d7d9e868 ("neigh: Add helper function neigh_xmit")
Signed-off-by: Florian Westphal <fw@strlen.de>
---
could followup in -next to make it "void", existing
callers either ignore retval or do:
if (err)
net_dbg_ratelimited("%s: ...
net/core/neighbour.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index c56a4e7bf790..5a9cc7268521 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -3211,8 +3211,10 @@ int neigh_xmit(int index, struct net_device *dev,
rcu_read_lock();
tbl = rcu_dereference(neigh_tables[index]);
- if (!tbl)
- goto out_unlock;
+ if (!tbl) {
+ rcu_read_unlock();
+ goto out_kfree_skb;
+ }
if (index == NEIGH_ARP_TABLE) {
u32 key = *((u32 *)addr);
@@ -3228,7 +3230,6 @@ int neigh_xmit(int index, struct net_device *dev,
goto out_kfree_skb;
}
err = READ_ONCE(neigh->output)(neigh, skb);
-out_unlock:
rcu_read_unlock();
}
else if (index == NEIGH_LINK_TABLE) {
@@ -3238,11 +3239,10 @@ int neigh_xmit(int index, struct net_device *dev,
goto out_kfree_skb;
err = dev_queue_xmit(skb);
}
-out:
return err;
out_kfree_skb:
kfree_skb(skb);
- goto out;
+ return err;
}
EXPORT_SYMBOL(neigh_xmit);
--
2.53.0
^ permalink raw reply related
* [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen()
From: Deepanshu Kartikey @ 2026-04-24 15:03 UTC (permalink / raw)
To: mst, jasowang, xuanzhuo, eperezma, stefanha, sgarzare, davem,
edumazet, kuba, pabeni, horms
Cc: virtualization, kvm, netdev, linux-kernel, Deepanshu Kartikey,
syzbot+1b2c9c4a0f8708082678
Two bugs exist in virtio_transport_recv_listen():
1. On the transport assignment error path, sk_acceptq_added() is called
but sk_acceptq_removed() is never called when vsock_assign_transport()
fails or assigns a different transport than expected. This causes the
parent listener's accept backlog counter to be permanently inflated,
eventually causing sk_acceptq_is_full() to reject legitimate incoming
connections.
2. There is a race between __vsock_release() and vsock_enqueue_accept().
__vsock_release() sets sk->sk_shutdown to SHUTDOWN_MASK and flushes
the accept queue under the parent socket lock. However,
virtio_transport_recv_listen() checks sk_shutdown and subsequently
calls vsock_enqueue_accept() without holding the parent socket lock.
This means a child socket can be enqueued after __vsock_release() has
already flushed the queue, causing the child socket and its associated
resources to leak
permanently. The existing comment in the code hints at this race but
the fix was never implemented.
Fix both issues: add sk_acceptq_removed() on the transport error path,
and re-check sk->sk_shutdown under the parent socket lock before calling
vsock_enqueue_accept() to close the race window. The child socket lock
is released before acquiring the parent socket lock to maintain correct
lock ordering (parent before child).
Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
Tested-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
net/vmw_vsock/virtio_transport_common.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 416d533f493d..fad5fa4a4296 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -1578,6 +1578,7 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
*/
if (ret || vchild->transport != &t->transport) {
release_sock(child);
+ sk_acceptq_removed(sk);
virtio_transport_reset_no_sock(t, skb, sock_net(sk));
sock_put(child);
return ret;
@@ -1588,11 +1589,19 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
child->sk_write_space(child);
vsock_insert_connected(vchild);
+ release_sock(child);
+ lock_sock(sk);
+ if (sk->sk_shutdown == SHUTDOWN_MASK) {
+ release_sock(sk);
+ sk_acceptq_removed(sk);
+ virtio_transport_reset_no_sock(t, skb, sock_net(sk));
+ sock_put(child);
+ return -ESHUTDOWN;
+ }
vsock_enqueue_accept(sk, child);
+ release_sock(sk);
virtio_transport_send_response(vchild, skb);
- release_sock(child);
-
sk->sk_data_ready(sk);
return 0;
}
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox