* Re: [PATCH RFC bpf-next 0/8] bpf: add support for KASAN checks in JITed programs
From: Alexei Starovoitov @ 2026-04-24 23:28 UTC (permalink / raw)
To: Ihor Solodrai
Cc: Alexis Lothoré (eBPF Foundation), 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,
Andrey Konovalov, 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: <71fb19ff-6dde-43f4-a0e9-5c8cf2ba4ed4@linux.dev>
On Fri, Apr 24, 2026 at 4:10 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
> I wonder if it's feasible to implement KASAN support on the verifier
> side in post-verification fixups. AI slop for illustration:
>
> ;; Original (1 BPF insn):
> dst = *(u64 *)(src + off) ; BPF_LDX | BPF_MEM | BPF_DW
>
> ;; Rewrite (~7 BPF insns):
> r_tmp1 = src ; BPF_MOV64_REG
> r_tmp1 += off ; BPF_ALU64 | BPF_ADD | K (full address)
> r_tmp2 = r_tmp1 ; copy
> r_tmp2 >>= 3 ; KASAN_SHADOW_SCALE_SHIFT
> r_tmp2 += KASAN_SHADOW_OFFSET ; shadow address
> r_tmp3 = *(u8 *)(r_tmp2 + 0) ; BPF_LDX | BPF_B (load shadow byte)
> if r_tmp3 != 0 goto +2 ; BPF_JNE | PC+2
> dst = *(u64 *)(src + off) ; original access (fast path)
> goto +1 ; skip slowpath
> call __asan_report_load8 ; BPF kfunc
> dst = *(u64 *)(src + off) ; retry the access after report (non-fatal)
>
> A sort of inline kasan directly in BPF.
>
> There are plenty of issues with it: instruction limit, exposing asan
> API as kfuncs, etc. On the flip side we get cross-arch support out of
> the box with no or mininal JIT changes.
>
> Honestly I'm not excited about this approach, but curious if anyone
> thought about this, or maybe it was already discussed?
We discussed this.
It won't work because we don't have that many temp registers for once
and second it has to preserve all (both callee and caller saved regs).
This is arch specific.
Second, we do not want other archs. This feature is x86-64 only.
It's being added to find _verifier_ bugs. To do that one arch is enough.
>
> > - not all memory accessing BPF instructions are being instrumented:
> > - it focuses on STX/LDX instructions
> > - it discards instructions accessing BPF program stack (already
> > monitored by page guards)
> > - it discards possibly faulting instructions, like BPF_PROBE_MEM or
> > BPF_PROBE_ATOMIC insns
> >
> > The series is marked and sent as RFC:
> > - to allow collecting feedback early and make sure that it goes into the
> > right direction
> > - because it depends on Xu's work to pass data between the verifier and
> > JIT compilers. This work is not merged yet, see [2]. I have been
> > tracking the various revisions he sent on the ML and based my local
> > branch on his work
> > - because tests brought by this series currently can't run on BPF CI:
> > they expect kasan multishot to be enabled, otherwise the first test
> > will make all other kasan-related tests fail.
>
> AFAICT this can be trivially fixed on BPF CI side, we just need to set
> kasan_multi_shot for the VMs running the tests. I will do that, your
> next revision doesn't have to be and RFC.
+1
> > - because some cases like atomic loads/stores are not instrumented yet
> > (and are still making me scratch my head)
> > - because it will hopefully provide a good basis to discuss the topic at
> > LSFMMBPF (see [3])
>
> Apparently, KASAN reporting routine takes a lock [1]:
>
> __asan_load()
> -> check_region_inline()
> -> kasan_report()
> -> start_report()
> -> raw_spin_lock_irqsave(&report_lock, *flags);
>
> BPF programs can run in NMI context, and so it appears to be possible
> to get an unflagged (because of lockdep_off() in start_report)
> deadlock, if an NMI fires on a CPU already holding report_lock.
> Although I guess you'd need two KASAN bugs to happen
> simultaneously for that to occur?... A rare event, I would hope.
>
> It could be addressed with either in_nmi() check at runtime, or
> forbidding kasan for NMI-runnable BPF program types.
We don't need that. If this bpf KASAN finds a bug, it means that
it found a verifier bug. All things are out of the window.
kasan_report() splat can just as well be the last thing that users will see.
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Ihor Solodrai @ 2026-04-24 23:31 UTC (permalink / raw)
To: Alexei Starovoitov, 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: <CAADnVQKuptG_opA12O=Xb9_+cHf3f=ycAZdfUp17P2HBYQzdsg@mail.gmail.com>
On 4/19/26 3:51 PM, Alexei Starovoitov wrote:
> On Sun, Apr 19, 2026 at 2:49 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>>
>> On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>>>
>>> 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.
>>
>> OK, I supposed that's fair. You did throw me off point with your
>> performance comment. But if you decide to add SW_TAGS support at some
>> point, I think this discussion needs to be revisited.
>>
>> But please add a comment saying that those functions are only exposed
>> for BPF JIT and they are not supposed to be used by other parts of the
>> kernel. And in case you do end up adding a new config option, guard
>> the public declarations by a corresponding ifdef.
>
> I feel concerns of misuse are overblown.
> Being in include/linux/kasan.h doesn't make them free-for-all
> all of a sudden, but if you prefer we can just copy paste:
> +void __asan_load1(void *p);
> +void __asan_store1(void *p);
> into bpf_jit_comp.c
>
>>> 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.
>>
>> FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code.
>
> Ohh. Good point. Looks like modern arm64 cpus in public clouds
> don't have that enabled, so one would need pixel phone to
> catch verifier bugs via hw_tags.
This comment got me curious, and acckktually if we *really* want to,
we can get some KASAN_HW_TAGS testing for BPF already.
The first option is emulation, since QEMU supports MTE [1], e.g.:
qemu-system-aarch64 -machine virt,mte=on ...
This is of course slow, because it runs in software, so it's
infeasible to run this for every signle patch on BPF CI. But we could
run it on schedule on the base branches or smth like that.
[1] https://qemu-project.gitlab.io/qemu/system/arm/virt.html
The second option is set up an AmpereOne machine on Oracle Cloud
(assuming they are available, haven't checked), because apparently [2]
those CPUs run with MTE.
It's a bunch of infra work and spending, but it is doable if it was
a priority.
[2] https://arxiv.org/abs/2511.17773
> So we still need this x86-specific jit kasan.
> I guess eventually it can be removed when hw_tags support is widespread.
^ permalink raw reply
* Re: [PATCH v2] ice: wait for reset completion in ice_resume()
From: Kohei Enju @ 2026-04-24 23:42 UTC (permalink / raw)
To: Aaron Ma
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel,
Akeem G Abodunrin, Jesse Brandeburg, intel-wired-lan
In-Reply-To: <20260424030345.1140665-1-aaron.ma@canonical.com>
On 04/24 11:03, Aaron Ma wrote:
> ice_resume() schedules an asynchronous PF reset and returns
> immediately. The reset runs later in ice_service_task(). If
> userspace tries to bring up the net device before the reset
> finishes, ice_open() fails with -EBUSY:
>
> ice_resume()
> ice_schedule_reset() # sets ICE_PFR_REQ, returns
> ...
> ice_open()
> ice_is_reset_in_progress() # ICE_PFR_REQ still set, -EBUSY
> ...
> ice_service_task()
> ice_do_reset()
> ice_rebuild() # clears ICE_PFR_REQ, too late
>
> Reproduced on E800 series NICs during suspend/resume with irdma
> enabled, where the aux device probe widens the race window.
>
> Wait for the reset to complete before returning from ice_resume().
>
> Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL")
> Cc: stable@vger.kernel.org
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
> ---
> v2: reword comment to clarify best-effort semantics (Kohei Enju)
>
> drivers/net/ethernet/intel/ice/ice_main.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index 5f92377d4dfc2..a81eb21ea87c1 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -5635,6 +5635,15 @@ static int ice_resume(struct device *dev)
> /* Restart the service task */
> mod_timer(&pf->serv_tmr, round_jiffies(jiffies + pf->serv_tmr_period));
>
> + /* Best-effort wait for the scheduled reset to finish so that the
> + * device is operational before returning. Without this, userspace
> + * (e.g. NetworkManager) may try to open the net device while the
> + * asynchronous reset is still in progress, hitting -EBUSY.
> + */
Thanks for the update!
Reviewed-by: Kohei Enju <kohei@enjuk.jp>
> + ret = ice_wait_for_reset(pf, 10 * HZ);
> + if (ret)
> + dev_err(dev, "Wait for reset failed during resume: %d\n", ret);
> +
> return 0;
> }
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH net] neigh: let neigh_xmit take skb ownership
From: Kuniyuki Iwashima @ 2026-04-24 23:43 UTC (permalink / raw)
To: Florian Westphal
Cc: netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, horms, idosch
In-Reply-To: <20260424145843.74055-1-fw@strlen.de>
On Fri, Apr 24, 2026 at 8:00 AM Florian Westphal <fw@strlen.de> wrote:
>
> 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",
Makes sense.
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
^ permalink raw reply
* [PATCH v1 bpf] bpf: Free reuseport cBPF prog after RCU grace period.
From: Kuniyuki Iwashima @ 2026-04-24 23:52 UTC (permalink / raw)
To: Martin KaFai Lau, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi
Cc: Kuniyuki Iwashima, Kuniyuki Iwashima, bpf, netdev, Eulgyu Kim
Eulgyu Kim reported the splat below with a repro. [0]
The repro sets up a UDP reuseport group with a cBPF prog and
replaces it with a new one while another thread is sending
a UDP packet to the group.
The reuseport prog is freed by sk_reuseport_prog_free().
bpf_prog_put() is called for "e"BPF prog to destruct through
multiple stages while cBPF prog is freed immediately by
bpf_release_orig_filter() and bpf_prog_free().
If a reuseport prog is detached from the setsockopt() path
(reuseport_attach_prog() or reuseport_detach_prog()),
sk_reuseport_prog_free() is called without waiting for RCU
readers to complete, resulting in various bugs.
Let's defer freeing the reuseport cBPF prog after one RCU
grace period.
Note "e"BPF prog is safe as is unless the fast path starts
to touch fields destroyed in bpf_prog_put_deferred() and
__bpf_prog_put_noref().
[0]:
BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596
Read of size 4 at addr ffffc9000051e004 by task slowme/10208
CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<IRQ>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xca/0x240 mm/kasan/report.c:482
kasan_report+0x118/0x150 mm/kasan/report.c:595
reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596
udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495
__udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723
__udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752
__udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752
ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207
ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241
NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318
NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318
__netif_receive_skb_one_core net/core/dev.c:6181 [inline]
__netif_receive_skb net/core/dev.c:6294 [inline]
process_backlog+0xaa4/0x1960 net/core/dev.c:6645
__napi_poll+0xae/0x340 net/core/dev.c:7709
napi_poll net/core/dev.c:7772 [inline]
net_rx_action+0x5d7/0xf50 net/core/dev.c:7929
handle_softirqs+0x22b/0x870 kernel/softirq.c:622
do_softirq+0x76/0xd0 kernel/softirq.c:523
</IRQ>
<TASK>
__local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline]
__dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890
neigh_output include/net/neighbour.h:556 [inline]
ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237
NF_HOOK_COND include/linux/netfilter.h:307 [inline]
ip_output+0x29f/0x450 net/ipv4/ip_output.c:438
ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508
udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195
udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
__sys_sendto+0x554/0x680 net/socket.c:2206
__do_sys_sendto net/socket.c:2213 [inline]
__se_sys_sendto net/socket.c:2209 [inline]
__x64_sys_sendto+0xde/0x100 net/socket.c:2209
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x415a2d
Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d
RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003
RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010
R10: 0000000000000000 R11: 0000000000000212 R12: 00007f6bc31e46c0
R13: ffffffffffffffb8 R14: 0000000000000000 R15: 00007ffc9b0d70b0
</TASK>
Fixes: 538950a1b752 ("soreuseport: setsockopt SO_ATTACH_REUSEPORT_[CE]BPF")
Reported-by: Eulgyu Kim <eulgyukim@snu.ac.kr>
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
net/core/filter.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index bc96c18df4e0..dba4c9340bb7 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1654,15 +1654,24 @@ int sk_reuseport_attach_bpf(u32 ufd, struct sock *sk)
return err;
}
-void sk_reuseport_prog_free(struct bpf_prog *prog)
+static void sk_reuseport_prog_free_rcu(struct rcu_head *rcu)
+{
+ struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux, rcu);
+ struct bpf_prog *prog = aux->prog;
+
+ bpf_release_orig_filter(prog);
+ bpf_prog_free(prog);
+}
+
+void sk_reuseport_prog_free(struct bpf_prog *prog, bool wait_rcu)
{
if (!prog)
return;
- if (prog->type == BPF_PROG_TYPE_SK_REUSEPORT)
- bpf_prog_put(prog);
+ if (bpf_prog_was_classic(prog))
+ call_rcu(&prog->aux->rcu, sk_reuseport_prog_free_rcu);
else
- bpf_prog_destroy(prog);
+ bpf_prog_put(prog);
}
static inline int __bpf_try_make_writable(struct sk_buff *skb,
--
2.54.0.rc2.544.gc7ae2d5bb8-goog
^ permalink raw reply related
* [PATCH net v2 0/4] gve: Fixes for issues discovered via net selftests
From: Harshitha Ramamurthy @ 2026-04-25 0:24 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Pin-yen Lin
From: Pin-yen Lin <treapking@google.com>
This patch series addresses several issues in the gve driver. All four of
these fixes were uncovered by running the net selftests.
The series includes the following changes:
- Patch 1 adds NULL pointer checks for the per-queue statistics code to
prevent crashes when the rings are queried while the link is down. This
was discovered by the drivers/net/stats.py selftest.
- Patch 2 fixes an issue where interface stats would go backwards when the
interface was brought down or its configuration was adjusted. This was
also discovered by the drivers/net/stats.py selftest.
- Patch 3 ensures the driver falls back to the default minimum ring size if
the corresponding device option values are exposed as 0. This prevents
userspace from configuring unexpectedly small ring sizes. This was
discovered by the drivers/net/ring_reconfig.py selftest.
- Patch 4 makes sure ethtool configuration modifications are done
synchronously before returning to the userspace. This was discovered by
the drivers/net/ping.py selftest.
Changes in v2:
- Link to v1: https://lore.kernel.org/netdev/20260420171837.455487-1-hramamurthy@google.com/
- Add a NULL pointer check in gve_get_ring_err_stats() (Sashiko)
- Use local variable to prevent inflates from u64_stats_fetch_retry()
(Sashiko)
- Add u64_stats_fetch/begin to protect base stats (Sashiko)
Debarghya Kundu (2):
gve: Add NULL pointer checks for per-queue statistics
gve: Fix backward stats when interface goes down or configuration is
adjusted
Pin-yen Lin (2):
gve: Use default min ring size when device option values are 0
gve: Make ethtool config changes synchronous
drivers/net/ethernet/google/gve/gve.h | 7 +
drivers/net/ethernet/google/gve/gve_adminq.c | 4 +-
drivers/net/ethernet/google/gve/gve_main.c | 152 ++++++++++++++-----
3 files changed, 125 insertions(+), 38 deletions(-)
--
2.54.0.rc2.544.gc7ae2d5bb8-goog
base-commit: e728258debd553c95d2e70f9cd97c9fde27c7130
branch: gve-misc-fixes
^ permalink raw reply
* [PATCH net v2 1/4] gve: Add NULL pointer checks for per-queue statistics
From: Harshitha Ramamurthy @ 2026-04-25 0:24 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Debarghya Kundu, Pin-yen Lin
In-Reply-To: <20260425002450.163421-1-hramamurthy@google.com>
From: Debarghya Kundu <debarghyak@google.com>
gve_get_[tx/rx]_queue_stats references the [tx/rx] null rings when the
link is down. Add NULL pointer checks to guard this
This was discovered by drivers/net/stats.py selftest.
Cc: stable@vger.kernel.org
Fixes: 2e5e0932dff5 ("gve: add support for basic queue stats")
Signed-off-by: Debarghya Kundu <debarghyak@google.com>
Signed-off-by: Pin-yen Lin <treapking@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
---
drivers/net/ethernet/google/gve/gve_main.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 424d973c97f2..ef00d9ca1643 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -2746,9 +2746,13 @@ static void gve_get_rx_queue_stats(struct net_device *dev, int idx,
struct netdev_queue_stats_rx *rx_stats)
{
struct gve_priv *priv = netdev_priv(dev);
- struct gve_rx_ring *rx = &priv->rx[idx];
+ struct gve_rx_ring *rx;
unsigned int start;
+ if (!priv->rx)
+ return;
+ rx = &priv->rx[idx];
+
do {
start = u64_stats_fetch_begin(&rx->statss);
rx_stats->packets = rx->rpackets;
@@ -2762,9 +2766,13 @@ static void gve_get_tx_queue_stats(struct net_device *dev, int idx,
struct netdev_queue_stats_tx *tx_stats)
{
struct gve_priv *priv = netdev_priv(dev);
- struct gve_tx_ring *tx = &priv->tx[idx];
+ struct gve_tx_ring *tx;
unsigned int start;
+ if (!priv->tx)
+ return;
+ tx = &priv->tx[idx];
+
do {
start = u64_stats_fetch_begin(&tx->statss);
tx_stats->packets = tx->pkt_done;
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH net v2 2/4] gve: Fix backward stats when interface goes down or configuration is adjusted
From: Harshitha Ramamurthy @ 2026-04-25 0:24 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Debarghya Kundu, Pin-yen Lin
In-Reply-To: <20260425002450.163421-1-hramamurthy@google.com>
From: Debarghya Kundu <debarghyak@google.com>
gve_get_base_stats() sets all the stats to 0, so the stats go backwards
when interface goes down or configuration is adjusted.
Fix this by persisting baseline stats across interface down.
Cc: stable@vger.kernel.org
Fixes: 2e5e0932dff5 ("gve: add support for basic queue stats")
Signed-off-by: Debarghya Kundu <debarghyak@google.com>
Co-developed-by: Pin-yen Lin <treapking@google.com>
Signed-off-by: Pin-yen Lin <treapking@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
---
Changes in v2:
- Add a NULL pointer check in gve_get_ring_err_stats() (Sashiko)
- Use local variable to prevent inflates from u64_stats_fetch_retry()
(Sashiko)
- Add u64_stats_fetch/begin to protect base stats (Sashiko)
drivers/net/ethernet/google/gve/gve.h | 7 ++
drivers/net/ethernet/google/gve/gve_main.c | 88 ++++++++++++++++++++--
2 files changed, 88 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve.h b/drivers/net/ethernet/google/gve/gve.h
index 1d66d3834f7e..702b1641d984 100644
--- a/drivers/net/ethernet/google/gve/gve.h
+++ b/drivers/net/ethernet/google/gve/gve.h
@@ -794,6 +794,10 @@ struct gve_ptp {
struct gve_priv *priv;
};
+struct gve_ring_err_stats {
+ u64 rx_alloc_fails;
+};
+
struct gve_priv {
struct net_device *dev;
struct gve_tx_ring *tx; /* array of tx_cfg.num_queues */
@@ -883,6 +887,9 @@ struct gve_priv {
unsigned long service_task_flags;
unsigned long state_flags;
+ struct gve_ring_err_stats base_ring_err_stats;
+ struct rtnl_link_stats64 base_net_stats;
+ struct u64_stats_sync base_statss; /* sync stats for 32bit archs */
struct gve_stats_report *stats_report;
u64 stats_report_len;
dma_addr_t stats_report_bus; /* dma address for the stats report */
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index ef00d9ca1643..1fec8e1e4821 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -106,9 +106,34 @@ static netdev_tx_t gve_start_xmit(struct sk_buff *skb, struct net_device *dev)
return gve_tx_dqo(skb, dev);
}
-static void gve_get_stats(struct net_device *dev, struct rtnl_link_stats64 *s)
+static void gve_add_base_stats(struct gve_priv *priv,
+ struct rtnl_link_stats64 *s)
+{
+ struct rtnl_link_stats64 *base_stats = &priv->base_net_stats;
+ unsigned int start;
+ u64 rx_packets, rx_bytes, rx_dropped, tx_packets, tx_bytes, tx_dropped;
+
+ do {
+ start = u64_stats_fetch_begin(&priv->base_statss);
+ rx_packets = base_stats->rx_packets;
+ rx_bytes = base_stats->rx_bytes;
+ rx_dropped = base_stats->rx_dropped;
+ tx_packets = base_stats->tx_packets;
+ tx_bytes = base_stats->tx_bytes;
+ tx_dropped = base_stats->tx_dropped;
+ } while (u64_stats_fetch_retry(&priv->base_statss, start));
+
+ s->rx_packets += rx_packets;
+ s->rx_bytes += rx_bytes;
+ s->rx_dropped += rx_dropped;
+ s->tx_packets += tx_packets;
+ s->tx_bytes += tx_bytes;
+ s->tx_dropped += tx_dropped;
+}
+
+static void gve_get_ring_stats(struct gve_priv *priv,
+ struct rtnl_link_stats64 *s)
{
- struct gve_priv *priv = netdev_priv(dev);
unsigned int start;
u64 packets, bytes;
int num_tx_queues;
@@ -143,6 +168,14 @@ static void gve_get_stats(struct net_device *dev, struct rtnl_link_stats64 *s)
}
}
+static void gve_get_stats(struct net_device *dev, struct rtnl_link_stats64 *s)
+{
+ struct gve_priv *priv = netdev_priv(dev);
+
+ gve_get_ring_stats(priv, s);
+ gve_add_base_stats(priv, s);
+}
+
static int gve_alloc_flow_rule_caches(struct gve_priv *priv)
{
struct gve_flow_rules_cache *flow_rules_cache = &priv->flow_rules_cache;
@@ -1533,6 +1566,29 @@ static int gve_queues_stop(struct gve_priv *priv)
return gve_reset_recovery(priv, false);
}
+static void gve_get_ring_err_stats(struct gve_priv *priv,
+ struct gve_ring_err_stats *err_stats)
+{
+ int ring;
+
+ if (!priv->rx)
+ return;
+
+ for (ring = 0; ring < priv->rx_cfg.num_queues; ring++) {
+ struct gve_rx_ring *rx = &priv->rx[ring];
+ unsigned int start;
+ u64 rx_alloc_fails;
+
+ do {
+ start = u64_stats_fetch_begin(&rx->statss);
+ rx_alloc_fails = rx->rx_skb_alloc_fail +
+ rx->rx_buf_alloc_fail;
+ } while (u64_stats_fetch_retry(&rx->statss, start));
+
+ err_stats->rx_alloc_fails += rx_alloc_fails;
+ }
+}
+
static int gve_close(struct net_device *dev)
{
struct gve_priv *priv = netdev_priv(dev);
@@ -1542,6 +1598,12 @@ static int gve_close(struct net_device *dev)
if (err)
return err;
+ /* Save ring queue and err stats before closing the interface */
+ u64_stats_update_begin(&priv->base_statss);
+ gve_get_ring_stats(priv, &priv->base_net_stats);
+ gve_get_ring_err_stats(priv, &priv->base_ring_err_stats);
+ u64_stats_update_end(&priv->base_statss);
+
gve_queues_mem_remove(priv);
return 0;
}
@@ -2784,12 +2846,24 @@ static void gve_get_base_stats(struct net_device *dev,
struct netdev_queue_stats_rx *rx,
struct netdev_queue_stats_tx *tx)
{
- rx->packets = 0;
- rx->bytes = 0;
- rx->alloc_fail = 0;
+ const struct gve_ring_err_stats *base_err_stats;
+ const struct rtnl_link_stats64 *base_stats;
+ struct gve_priv *priv;
+ unsigned int start;
- tx->packets = 0;
- tx->bytes = 0;
+ priv = netdev_priv(dev);
+ base_stats = &priv->base_net_stats;
+ base_err_stats = &priv->base_ring_err_stats;
+
+ do {
+ start = u64_stats_fetch_begin(&priv->base_statss);
+ rx->packets = base_stats->rx_packets;
+ rx->bytes = base_stats->rx_bytes;
+ rx->alloc_fail = base_err_stats->rx_alloc_fails;
+
+ tx->packets = base_stats->tx_packets;
+ tx->bytes = base_stats->tx_bytes;
+ } while (u64_stats_fetch_retry(&priv->base_statss, start));
}
static const struct netdev_stat_ops gve_stat_ops = {
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH net v2 3/4] gve: Use default min ring size when device option values are 0
From: Harshitha Ramamurthy @ 2026-04-25 0:24 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Pin-yen Lin
In-Reply-To: <20260425002450.163421-1-hramamurthy@google.com>
From: Pin-yen Lin <treapking@google.com>
On gvnic devices that support reporting minimum ring sizes, the device
option always includes the min_(rx|tx)_ring_size fields, and the values
will be 0 if they are not configured to be exposed. This makes the
driver allow unexpected small ring size configurations from the
userspace.
Use the default ring size in the driver if the min ring sizes from the
device option are 0.
This was discovered by drivers/net/ring_reconfig.py selftest.
Cc: stable@vger.kernel.org
Fixes: ed4fb326947d ("gve: add support to read ring size ranges from the device")
Reviewed-by: Joshua Washington <joshwash@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Pin-yen Lin <treapking@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
---
drivers/net/ethernet/google/gve/gve_adminq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/google/gve/gve_adminq.c b/drivers/net/ethernet/google/gve/gve_adminq.c
index 08587bf40ed4..2cd0dd6ced94 100644
--- a/drivers/net/ethernet/google/gve/gve_adminq.c
+++ b/drivers/net/ethernet/google/gve/gve_adminq.c
@@ -189,7 +189,9 @@ void gve_parse_device_option(struct gve_priv *priv,
*dev_op_modify_ring = (void *)(option + 1);
/* device has not provided min ring size */
- if (option_length == GVE_DEVICE_OPTION_NO_MIN_RING_SIZE)
+ if (option_length == GVE_DEVICE_OPTION_NO_MIN_RING_SIZE ||
+ be16_to_cpu((*dev_op_modify_ring)->min_rx_ring_size) == 0 ||
+ be16_to_cpu((*dev_op_modify_ring)->min_tx_ring_size) == 0)
priv->default_min_ring_size = true;
break;
case GVE_DEV_OPT_ID_FLOW_STEERING:
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH net v2 4/4] gve: Make ethtool config changes synchronous
From: Harshitha Ramamurthy @ 2026-04-25 0:24 UTC (permalink / raw)
To: netdev
Cc: joshwash, hramamurthy, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Pin-yen Lin
In-Reply-To: <20260425002450.163421-1-hramamurthy@google.com>
From: Pin-yen Lin <treapking@google.com>
When modifying device features via ethtool, the driver queues the
carrier status update to its workqueue (gve_wq). This leads to a
short link-down state after running the ethtool command.
Use `gve_turnup_and_check_status()` instead of `gve_turnup()` in
`gve_queues_start()` to update the carrier status before returning to
the userspace.
This was discovered by drivers/net/ping.py selftest. The test calls
ping command right after an ethtool configuration, but the interface
could be down without this fix.
Cc: stable@vger.kernel.org
Fixes: 5f08cd3d6423 ("gve: Alloc before freeing when adjusting queues")
Signed-off-by: Pin-yen Lin <treapking@google.com>
Reviewed-by: Joshua Washington <joshwash@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
---
drivers/net/ethernet/google/gve/gve_main.c | 56 +++++++++++-----------
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 1fec8e1e4821..2c461be12a75 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -1424,6 +1424,33 @@ static void gve_queues_mem_remove(struct gve_priv *priv)
priv->rx = NULL;
}
+static void gve_handle_link_status(struct gve_priv *priv, bool link_status)
+{
+ if (!gve_get_napi_enabled(priv))
+ return;
+
+ if (link_status == netif_carrier_ok(priv->dev))
+ return;
+
+ if (link_status) {
+ netdev_info(priv->dev, "Device link is up.\n");
+ netif_carrier_on(priv->dev);
+ } else {
+ netdev_info(priv->dev, "Device link is down.\n");
+ netif_carrier_off(priv->dev);
+ }
+}
+
+static void gve_turnup_and_check_status(struct gve_priv *priv)
+{
+ u32 status;
+
+ gve_turnup(priv);
+ status = ioread32be(&priv->reg_bar0->device_status);
+ gve_handle_link_status(priv,
+ GVE_DEVICE_STATUS_LINK_STATUS_MASK & status);
+}
+
/* The passed-in queue memory is stored into priv and the queues are made live.
* No memory is allocated. Passed-in memory is freed on errors.
*/
@@ -1486,8 +1513,7 @@ static int gve_queues_start(struct gve_priv *priv,
round_jiffies(jiffies +
msecs_to_jiffies(priv->stats_report_timer_period)));
- gve_turnup(priv);
- queue_work(priv->gve_wq, &priv->service_task);
+ gve_turnup_and_check_status(priv);
priv->interface_up_cnt++;
return 0;
@@ -1608,23 +1634,6 @@ static int gve_close(struct net_device *dev)
return 0;
}
-static void gve_handle_link_status(struct gve_priv *priv, bool link_status)
-{
- if (!gve_get_napi_enabled(priv))
- return;
-
- if (link_status == netif_carrier_ok(priv->dev))
- return;
-
- if (link_status) {
- netdev_info(priv->dev, "Device link is up.\n");
- netif_carrier_on(priv->dev);
- } else {
- netdev_info(priv->dev, "Device link is down.\n");
- netif_carrier_off(priv->dev);
- }
-}
-
static int gve_configure_rings_xdp(struct gve_priv *priv,
u16 num_xdp_rings)
{
@@ -2099,15 +2108,6 @@ static void gve_turnup(struct gve_priv *priv)
gve_set_napi_enabled(priv);
}
-static void gve_turnup_and_check_status(struct gve_priv *priv)
-{
- u32 status;
-
- gve_turnup(priv);
- status = ioread32be(&priv->reg_bar0->device_status);
- gve_handle_link_status(priv, GVE_DEVICE_STATUS_LINK_STATUS_MASK & status);
-}
-
static struct gve_notify_block *gve_get_tx_notify_block(struct gve_priv *priv,
unsigned int txqueue)
{
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* Re: [PATCH v1 bpf] bpf: Free reuseport cBPF prog after RCU grace period.
From: bot+bpf-ci @ 2026-04-25 0:26 UTC (permalink / raw)
To: kuniyu, martin.lau, ast, daniel, andrii, eddyz87, memxor
Cc: kuniyu, kuni1840, bpf, netdev, eulgyukim, ast, andrii, daniel,
martin.lau, eddyz87, yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260424235247.1990272-1-kuniyu@google.com>
[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]
> diff --git a/net/core/filter.c b/net/core/filter.c
> index bc96c18df4e0..dba4c9340bb7 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -1654,15 +1654,24 @@ int sk_reuseport_attach_bpf(u32 ufd, struct sock *sk)
> return err;
> }
>
> -void sk_reuseport_prog_free(struct bpf_prog *prog)
> +static void sk_reuseport_prog_free_rcu(struct rcu_head *rcu)
> +{
> + struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux, rcu);
> + struct bpf_prog *prog = aux->prog;
> +
> + bpf_release_orig_filter(prog);
> + bpf_prog_free(prog);
> +}
> +
> +void sk_reuseport_prog_free(struct bpf_prog *prog, bool wait_rcu)
> {
The function signature was changed to add a 'bool wait_rcu' parameter, but
the header file declaration in include/linux/filter.h and all three call
sites in net/core/sock_reuseport.c were not updated.
The three call sites are:
- reuseport_attach_prog() calling sk_reuseport_prog_free(old_prog)
- reuseport_free_rcu() calling sk_reuseport_prog_free(...)
- reuseport_detach_prog() calling sk_reuseport_prog_free(old_prog)
Will this compile? It looks like the callers will fail with 'too few
arguments to function sk_reuseport_prog_free'.
> if (!prog)
> return;
>
> - if (prog->type == BPF_PROG_TYPE_SK_REUSEPORT)
> - bpf_prog_put(prog);
> + if (bpf_prog_was_classic(prog))
> + call_rcu(&prog->aux->rcu, sk_reuseport_prog_free_rcu);
> else
> - bpf_prog_destroy(prog);
> + bpf_prog_put(prog);
> }
The 'wait_rcu' parameter is never used in the function body. The decision
to defer freeing via RCU is based entirely on bpf_prog_was_classic(prog).
What is the purpose of the wait_rcu parameter? The commit message explains
the goal is to defer freeing cBPF programs, but doesn't explain why a
per-call toggle would be needed. With the parameter ignored, callers
cannot control the behavior even if they wanted to.
>
> static inline int __bpf_try_make_writable(struct sk_buff *skb,
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24917377520
^ permalink raw reply
* Re: [PATCH v1 bpf] bpf: Free reuseport cBPF prog after RCU grace period.
From: Kuniyuki Iwashima @ 2026-04-25 0:30 UTC (permalink / raw)
To: bot+bpf-ci
Cc: martin.lau, ast, daniel, andrii, eddyz87, memxor, kuni1840, bpf,
netdev, eulgyukim, martin.lau, yonghong.song, clm, ihor.solodrai
In-Reply-To: <407178e7c68a87a2a660badc2e4e8e8feae7b1767998649cb278ce4bde14371d@mail.kernel.org>
On Fri, Apr 24, 2026 at 5:26 PM <bot+bpf-ci@kernel.org> wrote:
>
> > diff --git a/net/core/filter.c b/net/core/filter.c
> > index bc96c18df4e0..dba4c9340bb7 100644
> > --- a/net/core/filter.c
> > +++ b/net/core/filter.c
> > @@ -1654,15 +1654,24 @@ int sk_reuseport_attach_bpf(u32 ufd, struct sock *sk)
> > return err;
> > }
> >
> > -void sk_reuseport_prog_free(struct bpf_prog *prog)
> > +static void sk_reuseport_prog_free_rcu(struct rcu_head *rcu)
> > +{
> > + struct bpf_prog_aux *aux = container_of(rcu, struct bpf_prog_aux, rcu);
> > + struct bpf_prog *prog = aux->prog;
> > +
> > + bpf_release_orig_filter(prog);
> > + bpf_prog_free(prog);
> > +}
> > +
> > +void sk_reuseport_prog_free(struct bpf_prog *prog, bool wait_rcu)
> > {
>
> The function signature was changed to add a 'bool wait_rcu' parameter, but
Oops, sorry I forgot to commit the staged change..
pw-bot: cr
^ permalink raw reply
* [PATCH net v1] net/mlx5: Fix eswitch offloads cleanup on QoS init failure
From: Prathamesh Deshpande @ 2026-04-25 0:29 UTC (permalink / raw)
To: saeedm, leon
Cc: kuba, tariqt, cratiu, cjubran, netdev, linux-rdma, linux-kernel,
Prathamesh Deshpande
If mlx5_esw_qos_init() fails after esw_offloads_init() succeeds,
mlx5_eswitch_init() jumps to reps_err and skips esw_offloads_cleanup(),
leaking the offloads initialization state.
Add a dedicated unwind label for QoS init failure that cleans up
offloads before continuing the existing vport and outer eswitch cleanup.
Fixes: cac7356c653d ("net/mlx5: Rework esw qos domain init and cleanup")
Signed-off-by: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 123c96716a54..db4bf17d2640 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -2059,7 +2059,7 @@ int mlx5_eswitch_init(struct mlx5_core_dev *dev)
esw->mode = MLX5_ESWITCH_LEGACY;
err = mlx5_esw_qos_init(esw);
if (err)
- goto reps_err;
+ goto qos_err;
mutex_init(&esw->offloads.encap_tbl_lock);
hash_init(esw->offloads.encap_tbl);
@@ -2088,6 +2088,8 @@ int mlx5_eswitch_init(struct mlx5_core_dev *dev)
MLX5_MAX_MC_PER_VPORT(dev));
return 0;
+qos_err:
+ esw_offloads_cleanup(esw);
reps_err:
mlx5_esw_vports_cleanup(esw);
dev->priv.eswitch = NULL;
--
2.43.0
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH net] iavf: iavf_virtchnl_completion: drop duplicate ether_addr_equal() test
From: Jacob Keller @ 2026-04-25 0:37 UTC (permalink / raw)
To: Simon Horman, intel-wired-lan, stable,
Jose Ignacio Tornos Martinez, netdev
In-Reply-To: <aesqjovwYNeLlfX4@calimero.vinschen.de>
On 4/24/2026 1:32 AM, Corinna Vinschen wrote:
> On Apr 23 19:55, Simon Horman wrote:
>> On Tue, Apr 21, 2026 at 01:12:36PM +0200, Corinna Vinschen wrote:
>>> This is just a simple cleanup fix. Commit 35a2443d0910f ("iavf: Add
>>> waiting for response from PF in set mac") introduced a duplicate
>>> ether_addr_equal() check, so the current code tests the new MAC twice
>>> against the former MAC.
>>>
>>> Remove the outer ether_addr_equal() test, remnant of commit c5c922b3e09b
>>> ("iavf: fix MAC address setting for VFs when filter is rejected")
>>>
>>> Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
>>> Fixes: 35a2443d0910f ("iavf: Add waiting for response from PF in set mac")
>>> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>>> ---
>>> Added CC: stable@vger.kernel.org
>>
>> Hi,
>>
>> This feels more like a cleanup for net-next (without a Fixes tag)
>> than a fix for net. I'm missing where the bug is here.
>
> Yeah, it's not a bug, the "Fixes" tag was just supposed to point out the
> patch introducing the duplicate test.
>
> Shall I create a v3 or is it ok as is and just goes to net-next instead
> of net?
>
>
> Thanks,
> Corinna
>
I can make a note for later and either myself or Tony can forward it
net-next as part of an Intel Wired LAN update when the merge window
re-opens and any testing has completed. (Not that there is much needing
to be tested in this patches case)
Thanks,
Jake
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net] ice: fix missing SMA pin initialization in DPLL subsystem
From: Nowlin, Alexander @ 2026-04-25 0:44 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Vecera, Ivan, Kitszel, Przemyslaw, Eric Dumazet,
Kubalewski, Arkadiusz, Andrew Lunn, Nguyen, Anthony L,
Simon Horman, intel-wired-lan@lists.osuosl.org, Jakub Kicinski,
Paolo Abeni, David S. Miller, linux-kernel@vger.kernel.org
In-Reply-To: <20260213141651.2231124-1-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr Oros
> Sent: Friday, February 13, 2026 6:17 AM
> To: netdev@vger.kernel.org
> Cc: Vecera, Ivan <ivecera@redhat.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet <edumazet@google.com>; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Simon Horman <horms@kernel.org>; intel-wired-lan@lists.osuosl.org; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net] ice: fix missing SMA pin initialization in DPLL subsystem
>
> The DPLL SMA/U.FL pin redesign introduced ice_dpll_sw_pin_frequency_get() which gates frequency reporting on the pin's active flag. This flag is determined by ice_dpll_sw_pins_update() from the PCA9575
> GPIO expander state. Before the redesign, SMA pins were exposed as direct HW input/output pins and ice_dpll_frequency_get() returned the CGU frequency unconditionally — the PCA9575 state was never
> consulted.
>
> The PCA9575 powers on with all outputs high, setting ICE_SMA1_DIR_EN, ICE_SMA1_TX_EN, ICE_SMA2_DIR_EN and ICE_SMA2_TX_EN. Nothing in the driver writes the register during initialization, so
> ice_dpll_sw_pins_update() sees all pins as inactive and
> ice_dpll_sw_pin_frequency_get() permanently returns 0 Hz for every SW pin.
>
> Fix this by writing a default SMA configuration in
> ice_dpll_init_info_sw_pins(): clear all SMA bits, then set SMA1 and
> SMA2 as active inputs (DIR_EN=0) with U.FL1 output and U.FL2 input disabled. Each SMA/U.FL pair shares a physical signal path so only one pin per pair can be active at a time. U.FL pins still report frequency 0 > after this fix: U.FL1 (output-only) is disabled by ICE_SMA1_TX_EN which keeps the TX output buffer off, and U.FL2
> (input-only) is disabled by ICE_SMA2_UFL2_RX_DIS. They can be activated by changing the corresponding SMA pin direction via dpll netlink.
>
> Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/net/ethernet/intel/ice/ice_dpll.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix SMA and U.FL pin state changes affecting paired pin
From: Nowlin, Alexander @ 2026-04-25 0:46 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Kitszel, Przemyslaw, Eric Dumazet, Kubalewski, Arkadiusz,
Andrew Lunn, Nguyen, Anthony L, Simon Horman,
intel-wired-lan@lists.osuosl.org, Jakub Kicinski, Paolo Abeni,
David S. Miller, linux-kernel@vger.kernel.org
In-Reply-To: <20260408110504.1032879-1-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr Oros
> Sent: Wednesday, April 8, 2026 4:05 AM
> To: netdev@vger.kernel.org
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet <edumazet@google.com>; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Simon Horman <horms@kernel.org>; intel-wired-lan@lists.osuosl.org; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S. Miller
> <davem@davemloft.net>; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix SMA and U.FL pin state changes affecting paired pin
>
> SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1 and
> SMA2/U.FL2) controlled by the PCA9575 GPIO expander. Each pair can only have one active pin at a time: SMA1 output and U.FL1 output share the same CGU output, SMA2 input and U.FL2 input share the
> same CGU input. The PCA9575 register bits determine which connector in each pair owns the signal path.
>
> The driver does not account for this pairing in two places:
>
> ice_dpll_ufl_pin_state_set() modifies PCA9575 bits and disables the backing CGU pin without checking whether the U.FL pin is currently active. Disconnecting an already inactive U.FL pin flips bits that the
> paired SMA pin relies on, breaking its connection.
>
> ice_dpll_sma_direction_set() does not propagate direction changes to the paired U.FL pin. For SMA2/U.FL2 the ICE_SMA2_UFL2_RX_DIS bit is never managed, so U.FL2 stays disconnected after SMA2 switches
> to output. For both pairs the backing CGU pin of the U.FL side is never enabled when a direction change activates it, so userspace sees the pin as disconnected even though the routing is correct.
>
> Fix by guarding the U.FL disconnect path against inactive pins and by updating the paired U.FL pin fully on SMA direction changes: manage ICE_SMA2_UFL2_RX_DIS for the SMA2/U.FL2 pair and enable the
> backing CGU pin whenever the peer becomes active.
>
> Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> v2:
> - fix ice_dpll_sma_direction_set() to manage ICE_SMA2_UFL2_RX_DIS
> when SMA2 direction changes
> - enable paired U.FL backing CGU pin when direction change makes
> it active, so it reports as connected immediately
> - (both reported by Intel test on the SMA init and notification
> patch threads)
> v1: https://lore.kernel.org/all/20260325151050.2081977-1-poros@redhat.com/
> ---
> drivers/net/ethernet/intel/ice/ice_dpll.c | 50 ++++++++++++++++++++++-
> 1 file changed, 49 insertions(+), 1 deletion(-)
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v7 1/3] dpll: export __dpll_pin_change_ntf() for use under dpll_lock
From: Nowlin, Alexander @ 2026-04-25 0:48 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Vecera, Ivan, Vadim Fedorenko, Rinitha, SX, Kitszel, Przemyslaw,
Jiri Pirko, Eric Dumazet, Kubalewski, Arkadiusz,
Loktionov, Aleksandr, Andrew Lunn, Nguyen, Anthony L,
Simon Horman, intel-wired-lan@lists.osuosl.org, Keller, Jacob E,
Jakub Kicinski, Paolo Abeni, David S. Miller,
linux-kernel@vger.kernel.org
In-Reply-To: <20260417145907.696307-2-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr Oros
> Sent: Friday, April 17, 2026 7:59 AM
> To: netdev@vger.kernel.org
> Cc: Vecera, Ivan <ivecera@redhat.com>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; Rinitha, SX <sx.rinitha@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> Eric Dumazet <edumazet@google.com>; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Simon Horman <horms@kernel.org>; intel-wired-lan@lists.osuosl.org; Keller, Jacob E <jacob.e.keller@intel.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-net v7 1/3] dpll: export __dpll_pin_change_ntf() for use under dpll_lock
>
> From: Ivan Vecera <ivecera@redhat.com>
>
> Export __dpll_pin_change_ntf() so that drivers can send pin change notifications from within pin callbacks, which are already called under dpll_lock. Using dpll_pin_change_ntf() in that context would deadlock.
>
> Add lockdep_assert_held() to catch misuse without the lock held.
>
> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/dpll/dpll_netlink.c | 10 ++++++++++ drivers/dpll/dpll_netlink.h | 2 --
> include/linux/dpll.h | 1 +
> 3 files changed, 11 insertions(+), 2 deletions(-)
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v7 2/3] ice: fix missing dpll notifications for SW pins
From: Nowlin, Alexander @ 2026-04-25 0:50 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Vecera, Ivan, Vadim Fedorenko, Jiri Pirko, Rinitha, SX,
Kitszel, Przemyslaw, Eric Dumazet, Kubalewski, Arkadiusz,
Loktionov, Aleksandr, Andrew Lunn, Nguyen, Anthony L,
Simon Horman, intel-wired-lan@lists.osuosl.org, Keller, Jacob E,
Jakub Kicinski, Paolo Abeni, David S. Miller,
linux-kernel@vger.kernel.org
In-Reply-To: <20260417145907.696307-3-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr Oros
> Sent: Friday, April 17, 2026 7:59 AM
> To: netdev@vger.kernel.org
> Cc: Vecera, Ivan <ivecera@redhat.com>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; Jiri Pirko <jiri@resnulli.us>; Rinitha, SX <sx.rinitha@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>;
> Eric Dumazet <edumazet@google.com>; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Simon Horman <horms@kernel.org>; intel-wired-lan@lists.osuosl.org; Keller, Jacob E <jacob.e.keller@intel.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-net v7 2/3] ice: fix missing dpll notifications for SW pins
>
> The SMA/U.FL pin redesign (commit 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")) introduced software-controlled pins that wrap backing CGU input/output pins, but never updated the notification > and data paths to propagate pin events to these SW wrappers.
>
> The periodic work sends dpll_pin_change_ntf() only for direct CGU input pins. SW pins that wrap these inputs never receive change or phase offset notifications, so userspace consumers such as synce4l
> monitoring SMA pins via dpll netlink never learn about state transitions or phase offset updates. Similarly, ice_dpll_phase_offset_get() reads the SW pin's own phase_offset field which is never updated; the PPS
> monitor writes to the backing CGU input's field instead.
>
> Fix by introducing ice_dpll_pin_ntf(), a wrapper around
> dpll_pin_change_ntf() that also notifies any registered SMA/U.FL pin whose backing CGU input matches. Replace all direct
> dpll_pin_change_ntf() calls in the periodic notification paths with this wrapper. Fix ice_dpll_phase_offset_get() to return the backing CGU input's phase_offset for input-direction SW pins.
>
> Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/net/ethernet/intel/ice/ice_dpll.c | 47 +++++++++++++++++------
> 1 file changed, 36 insertions(+), 11 deletions(-)
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v7 3/3] ice: add dpll peer notification for paired SMA and U.FL pins
From: Nowlin, Alexander @ 2026-04-25 0:50 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Vecera, Ivan, Vadim Fedorenko, Jiri Pirko, Rinitha, SX,
Kitszel, Przemyslaw, Eric Dumazet, Kubalewski, Arkadiusz,
Loktionov, Aleksandr, Andrew Lunn, Nguyen, Anthony L,
Simon Horman, intel-wired-lan@lists.osuosl.org, Keller, Jacob E,
Jakub Kicinski, Paolo Abeni, David S. Miller,
linux-kernel@vger.kernel.org
In-Reply-To: <20260417145907.696307-4-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr Oros
> Sent: Friday, April 17, 2026 7:59 AM
> To: netdev@vger.kernel.org
> Cc: Vecera, Ivan <ivecera@redhat.com>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; Jiri Pirko <jiri@resnulli.us>; Rinitha, SX <sx.rinitha@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>;
> Eric Dumazet <edumazet@google.com>; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Simon Horman <horms@kernel.org>; intel-wired-lan@lists.osuosl.org; Keller, Jacob E <jacob.e.keller@intel.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-net v7 3/3] ice: add dpll peer notification for paired SMA and U.FL pins
>
> SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1 and SMA2/U.FL2). When one pin's state changes via a PCA9575 GPIO write, the paired pin's state also changes, but no notification is sent for > the peer pin. Userspace consumers monitoring the peer via dpll netlink subscribe never learn about the update.
>
> Add ice_dpll_sw_pin_notify_peer() which sends a change notification for the paired SW pin. Call it from ice_dpll_pin_sma_direction_set(), ice_dpll_sma_pin_state_set(), and ice_dpll_ufl_pin_state_set() after
> pf->dplls.lock is released. Use __dpll_pin_change_ntf() because
> dpll_lock is still held by the dpll netlink layer (dpll_pin_pre_doit).
>
> Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/net/ethernet/intel/ice/ice_dpll.c | 32 +++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
^ permalink raw reply
* [PATCH net-next] net: bcmasp: handle EPROBE_DEFER for MAC retrieval
From: Rosen Penev @ 2026-04-25 1:37 UTC (permalink / raw)
To: netdev
Cc: Justin Chen, Florian Fainelli, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni,
open list:BROADCOM ASP 2.0 ETHERNET DRIVER, open list
of_get_ethdev_address can return EPROBE_DEFER when using nvmem. To
handle this, encode the error with ERR_PTR for minimal changes. Adjust
the only place using bcmasp_interface_create.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/net/ethernet/broadcom/asp2/bcmasp.c | 4 ++--
drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 6 ++++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.c b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
index 972474893a6b..31a9560c4aee 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
@@ -1333,10 +1333,10 @@ static int bcmasp_probe(struct platform_device *pdev)
i = 0;
for_each_available_child_of_node_scoped(ports_node, intf_node) {
intf = bcmasp_interface_create(priv, intf_node, i);
- if (!intf) {
+ if (IS_ERR(intf)) {
dev_err(dev, "Cannot create eth interface %d\n", i);
of_node_put(ports_node);
- ret = -EINVAL;
+ ret = PTR_ERR(intf);
goto err_cleanup;
}
list_add_tail(&intf->list, &priv->intfs);
diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
index ec63f50a849e..caf0e408e2f7 100644
--- a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
+++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
@@ -1254,7 +1254,7 @@ struct bcmasp_intf *bcmasp_interface_create(struct bcmasp_priv *priv,
struct device *dev = &priv->pdev->dev;
struct bcmasp_intf *intf;
struct net_device *ndev;
- int ch, port, ret;
+ int ch, port, ret = -EINVAL;
if (of_property_read_u32(ndev_dn, "reg", &port)) {
dev_warn(dev, "%s: invalid port number\n", ndev_dn->name);
@@ -1314,6 +1314,8 @@ struct bcmasp_intf *bcmasp_interface_create(struct bcmasp_priv *priv,
}
ret = of_get_ethdev_address(ndev_dn, ndev);
+ if (ret == -EPROBE_DEFER)
+ return ERR_PTR(-EPROBE_DEFER);
if (ret) {
netdev_warn(ndev, "using random Ethernet MAC\n");
eth_hw_addr_random(ndev);
@@ -1340,7 +1342,7 @@ struct bcmasp_intf *bcmasp_interface_create(struct bcmasp_priv *priv,
err_free_netdev:
free_netdev(ndev);
err:
- return NULL;
+ return ERR_PTR(ret);
}
void bcmasp_interface_destroy(struct bcmasp_intf *intf)
--
2.54.0
^ permalink raw reply related
* [PATCH iwl-next v2] libie: log more info when virtchnl fails
From: Li Li @ 2026-04-25 1:48 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, David S. Miller, Jakub Kicinski,
Eric Dumazet, intel-wired-lan
Cc: netdev, linux-kernel, David Decotigny, Anjali Singhai,
Sridhar Samudrala, Brian Vazquez, Li Li, emil.s.tantilov
Virtchnl failures can be hard to debug without logs. Logging the details
of virtchnl transactions can be useful for debugging virtchnl-related
issues.
Tested: Built and booted on a test machine.
Signed-off-by: Li Li <boolli@google.com>
---
v2:
- Use dev_warn_ratelimited instead of dev_notice_ratelimited based on
reviewer feedback.
drivers/net/ethernet/intel/libie/controlq.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/intel/libie/controlq.c b/drivers/net/ethernet/intel/libie/controlq.c
index ebc05355e39d..bf200fea1e12 100644
--- a/drivers/net/ethernet/intel/libie/controlq.c
+++ b/drivers/net/ethernet/intel/libie/controlq.c
@@ -762,6 +762,16 @@ libie_ctlq_xn_process_recv(struct libie_ctlq_xn_recv_params *params,
status = ctlq_msg->chnl_retval ? -EFAULT : 0;
xn = &xnm->ring[xn_index];
+
+ if (ctlq_msg->chnl_retval) {
+ dev_err_ratelimited(
+ params->ctlq->dev,
+ "Non-zero virtchnl ret val (msg op: %u, ret val: %u, msg_cookie: %u, data_len: %u); xn op: %u, id: %u, cookie: %u\n",
+ ctlq_msg->chnl_opcode, ctlq_msg->chnl_retval,
+ msg_cookie, ctlq_msg->data_len, xn->virtchnl_opcode,
+ xn->index, xn->cookie);
+ }
+
if (ctlq_msg->chnl_opcode != xn->virtchnl_opcode ||
msg_cookie != xn->cookie)
return false;
@@ -1011,6 +1021,11 @@ int libie_ctlq_xn_send(struct libie_ctlq_xn_send_params *params)
params->recv_mem = xn->recv_mem;
break;
default:
+ dev_warn_ratelimited(
+ params->ctlq->dev,
+ "Transaction failed (op %u, xn state: %d, id: %u, cookie: %u, size: %zu)\n",
+ params->chnl_opcode, xn->state, xn->index, xn->cookie,
+ xn->recv_mem.iov_len);
ret = -EBADMSG;
break;
}
--
2.54.0.rc2.544.gc7ae2d5bb8-goog
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH iwl-next] libie: log more info when virtchnl fails
From: Li Li @ 2026-04-25 1:50 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: Nguyen, Anthony L, Kitszel, Przemyslaw, David S. Miller,
Jakub Kicinski, Eric Dumazet, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
David Decotigny, Singhai, Anjali, Samudrala, Sridhar,
Brian Vazquez, Tantilov, Emil S
In-Reply-To: <IA3PR11MB898659D8A18DF05024CB56BEE52B2@IA3PR11MB8986.namprd11.prod.outlook.com>
On Fri, Apr 24, 2026 at 9:08 AM Loktionov, Aleksandr
<aleksandr.loktionov@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Li Li via Intel-wired-lan
> > Sent: Friday, April 24, 2026 5:16 AM
> > To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> > Przemyslaw <przemyslaw.kitszel@intel.com>; David S. Miller
> > <davem@davemloft.net>; Jakub Kicinski <kuba@kernel.org>; Eric Dumazet
> > <edumazet@google.com>; intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; David
> > Decotigny <decot@google.com>; Singhai, Anjali
> > <anjali.singhai@intel.com>; Samudrala, Sridhar
> > <sridhar.samudrala@intel.com>; Brian Vazquez <brianvv@google.com>; Li
> > Li <boolli@google.com>; Tantilov, Emil S <emil.s.tantilov@intel.com>
> > Subject: [Intel-wired-lan] [PATCH iwl-next] libie: log more info when
> > virtchnl fails
> >
> > Virtchnl failures can be hard to debug without logs. Logging the
> > details of virtchnl transactions can be useful for debugging virtchnl-
> > related issues.
> >
> > Tested: Built and booted on a test machine.
> >
> > Signed-off-by: Li Li <boolli@google.com>
> > ---
> > drivers/net/ethernet/intel/libie/controlq.c | 15 +++++++++++++++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/intel/libie/controlq.c
> > b/drivers/net/ethernet/intel/libie/controlq.c
> > index ebc05355e39d..7eaa77413621 100644
> > --- a/drivers/net/ethernet/intel/libie/controlq.c
> > +++ b/drivers/net/ethernet/intel/libie/controlq.c
> > @@ -762,6 +762,16 @@ libie_ctlq_xn_process_recv(struct
> > libie_ctlq_xn_recv_params *params,
> > status = ctlq_msg->chnl_retval ? -EFAULT : 0;
> >
> > xn = &xnm->ring[xn_index];
> > +
> > + if (ctlq_msg->chnl_retval) {
> > + dev_err_ratelimited(
> > + params->ctlq->dev,
> > + "Non-zero virtchnl ret val (msg op: %u, ret val:
> > %u, msg_cookie: %u, data_len: %u); xn op: %u, id: %u, cookie: %u\n",
> > + ctlq_msg->chnl_opcode, ctlq_msg->chnl_retval,
> > + msg_cookie, ctlq_msg->data_len, xn-
> > >virtchnl_opcode,
> > + xn->index, xn->cookie);
> > + }
> > +
> > if (ctlq_msg->chnl_opcode != xn->virtchnl_opcode ||
> > msg_cookie != xn->cookie)
> > return false;
> > @@ -1011,6 +1021,11 @@ int libie_ctlq_xn_send(struct
> > libie_ctlq_xn_send_params *params)
> > params->recv_mem = xn->recv_mem;
> > break;
> > default:
> > + dev_notice_ratelimited(
> > + params->ctlq->dev,
> > + "Transaction failed (op %u, xn state: %d, id: %u,
> > cookie: %u, size: %zu)\n",
> > + params->chnl_opcode, xn->state, xn->index, xn-
> > >cookie,
> > + xn->recv_mem.iov_len);
> For me dev_notice_ratelimited() level is low for a failure messages.
> Why not dev_warn_ratelimited() instead?
Good call. Switched to using dev_warn_ratelimited() in the v2 patch.
Thanks for the suggestion!
>
> > ret = -EBADMSG;
> > break;
> > }
> > --
> > 2.54.0.rc2.544.gc7ae2d5bb8-goog
>
^ permalink raw reply
* Re: [PATCH bpf] bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()
From: Jiayuan Chen @ 2026-04-25 2:55 UTC (permalink / raw)
To: Weiming Shi, Martin KaFai Lau, Daniel Borkmann,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: John Fastabend, Stanislav Fomichev, Song Liu, Yonghong Song,
Jiri Olsa, Simon Horman, bpf, netdev, Xiang Mei, Xinyu Ma
In-Reply-To: <20260424191602.1522411-3-bestswngs@gmail.com>
On 4/25/26 3:16 AM, Weiming Shi wrote:
> When the scatterlist ring is full or nearly full, bpf_msg_push_data()
> enters a copy fallback path and computes copy + len for the page
> allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING
> and both are u32, a crafted len can wrap the sum to a small value,
> causing an undersized allocation followed by an out-of-bounds memcpy.
>
> BUG: unable to handle page fault for address: ffffed104089a402
> Oops: Oops: 0000 [#1] SMP KASAN NOPTI
> Call Trace:
> __asan_memcpy (mm/kasan/shadow.c:105)
> bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788)
> bpf_prog_9ed8b5711920a7d7+0x2e/0x36
> sk_psock_msg_verdict (net/core/skmsg.c:934)
> tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584)
> __sys_sendto (net/socket.c:2206)
> do_syscall_64 (arch/x86/entry/syscall_64.c:94)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
>
> Add an overflow check before the allocation.
>
> Link: https://lore.kernel.org/all/20260424155913.A19FDC19425@smtp.kernel.org
> Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data")
> Tested-by: Xiang Mei <xmei5@asu.edu>
> Tested-by: Xinyu Ma <mmmxny@gmail.com>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
^ permalink raw reply
* [PATCH v1] net: phy: dp83869: fix setting CLK_O_SEL field.
From: Heiko Schocher @ 2026-04-25 3:13 UTC (permalink / raw)
To: netdev
Cc: Heiko Schocher, Andrew Lunn, David S. Miller, Eric Dumazet,
Heiner Kallweit, Jakub Kicinski, Paolo Abeni, Russell King,
linux-kernel
Table 7-121 in datasheet says we have to set register 0xc6
to value 0x10 before CLK_O_SEL can be modified. No more infos
about this field found in datasheet. With this fix, setting
of CLK_O_SEL field in IO_MUX_CFG register worked through dts
property "ti,clk-output-sel" on a DP83869HMRGZR.
Signed-off-by: Heiko Schocher <hs@nabladev.com>
---
drivers/net/phy/dp83869.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index 1f381d7b13ff..96a7d255f50f 100644
--- a/drivers/net/phy/dp83869.c
+++ b/drivers/net/phy/dp83869.c
@@ -31,6 +31,7 @@
#define DP83869_RGMIICTL 0x0032
#define DP83869_STRAP_STS1 0x006e
#define DP83869_RGMIIDCTL 0x0086
+#define DP83869_ANA_PLL_PROG_PI 0x00c6
#define DP83869_RXFCFG 0x0134
#define DP83869_RXFPMD1 0x0136
#define DP83869_RXFPMD2 0x0137
@@ -826,12 +827,22 @@ static int dp83869_config_init(struct phy_device *phydev)
dp83869_config_port_mirroring(phydev);
/* Clock output selection if muxing property is set */
- if (dp83869->clk_output_sel != DP83869_CLK_O_SEL_REF_CLK)
+ if (dp83869->clk_output_sel != DP83869_CLK_O_SEL_REF_CLK) {
+ /*
+ * Table 7-121 in datasheet says we have to set register 0xc6
+ * to value 0x10 before CLK_O_SEL can be modified.
+ */
+ ret = phy_write_mmd(phydev, DP83869_DEVADDR,
+ DP83869_ANA_PLL_PROG_PI, 0x10);
+ if (ret)
+ return ret;
+
ret = phy_modify_mmd(phydev,
DP83869_DEVADDR, DP83869_IO_MUX_CFG,
DP83869_IO_MUX_CFG_CLK_O_SEL_MASK,
dp83869->clk_output_sel <<
DP83869_IO_MUX_CFG_CLK_O_SEL_SHIFT);
+ }
if (phy_interface_is_rgmii(phydev)) {
ret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIIDCTL,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH bpf] bpf, sockmap: zero-initialize pages allocated in bpf_msg_push_data
From: Jiayuan Chen @ 2026-04-25 3:17 UTC (permalink / raw)
To: Weiming Shi, Martin KaFai Lau, Daniel Borkmann,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: John Fastabend, Stanislav Fomichev, Song Liu, Yonghong Song,
Jiri Olsa, Simon Horman, bpf, netdev, Xiang Mei, Xinyu Ma
In-Reply-To: <20260424190310.1520555-2-bestswngs@gmail.com>
On 4/25/26 3:03 AM, Weiming Shi wrote:
> bpf_msg_push_data() allocates pages via alloc_pages() without
> __GFP_ZERO. In the non-copy path, the entire page of uninitialized
> heap content is added directly to the sk_msg scatterlist, which is
> then transmitted over TCP to userspace via tcp_bpf_push(). In the
> copy path, a gap of len bytes between the front and back memcpy
> regions is similarly left uninitialized.
>
> This leads to a kernel heap information leak: stale page content
> including kernel pointers from the direct-map and vmemmap regions
> is transmitted to userspace, which can be used to defeat KASLR.
>
> Add __GFP_ZERO to the alloc_pages() call to ensure the allocated
> page is always zeroed before it enters the scatterlist.
As the helper's own documentation says:
If a program of type BPF_PROG_TYPE_SK_MSG is run on a msg it may
want to insert metadata or options into the msg. This can later be
read and used by any of the lower layer BPF hooks.
The inserted region is meant to be written by the BPF program — that's
the entire point of calling push.
If the program doesn't fill it, the push has no purpose to begin with.
Isn't the uninitialized content a bug in the BPF program rather than
something the kernel helper should paper over?
> Link: https://lore.kernel.org/all/20260424155913.A19FDC19425@smtp.kernel.org
> Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data")
> Tested-by: Xiang Mei <xmei5@asu.edu>
> Tested-by: Xinyu Ma <mmmxny@gmail.com>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
> net/core/filter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index bc96c18df4e0..ea02239892fd 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -2820,7 +2820,7 @@ BPF_CALL_4(bpf_msg_push_data, struct sk_msg *, msg, u32, start,
> if (!space || (space == 1 && start != offset))
> copy = msg->sg.data[i].length;
>
> - page = alloc_pages(__GFP_NOWARN | GFP_ATOMIC | __GFP_COMP,
> + page = alloc_pages(__GFP_NOWARN | GFP_ATOMIC | __GFP_COMP | __GFP_ZERO,
> get_order(copy + len));
> if (unlikely(!page))
> return -ENOMEM;
^ 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