* Re: [PATCH net v3 0/7] net/sched: Fix packet loops in mirred and netem
From: Stephen Hemminger @ 2026-04-03 22:01 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev
In-Reply-To: <20260403140040.7aeb565c@kernel.org>
On Fri, 3 Apr 2026 14:00:40 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> On Fri, 3 Apr 2026 12:03:54 -0700 Stephen Hemminger wrote:
> > On Thu, 2 Apr 2026 17:49:06 -0700
> > Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > > On Thu, 2 Apr 2026 13:16:18 -0700 Stephen Hemminger wrote:
> > > > Why is this marked Changes Requested.
> > >
> > > Is this a question.
> > Yes a process question what is the blocker? What needs to change?
> > More review?
>
> I think what happened was it was posted at the same time as another
> series for netem and made TDC fail. Then Jamal said something which
> TBH I didn't completely follow so I left it as Changes Requested :S
> Imperfection of the maintainer, I'd say :S
>
> Please repost if the series is good (presumably once the other
> series you have pending for net goes in?)
No problem
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix memory leak in airoha_qdma_rx_process()
From: patchwork-bot+netdevbpf @ 2026-04-03 22:00 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260402-airoha_qdma_rx_process-mem-leak-fix-v1-1-b5706f402d3c@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 02 Apr 2026 14:57:10 +0200 you wrote:
> If an error occurs on the subsequents buffers belonging to the
> non-linear part of the skb (e.g. due to an error in the payload length
> reported by the NIC or if we consumed all the available fragments for
> the skb), the page_pool fragment will not be linked to the skb so it will
> not return to the pool in the airoha_qdma_rx_process() error path. Fix the
> memory leak partially reverting commit 'd6d2b0e1538d ("net: airoha: Fix
> page recycling in airoha_qdma_rx_process()")' and always running
> page_pool_put_full_page routine in the airoha_qdma_rx_process() error
> path.
>
> [...]
Here is the summary with links:
- [net] net: airoha: Fix memory leak in airoha_qdma_rx_process()
https://git.kernel.org/netdev/net/c/285fa6b1e03c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()
From: patchwork-bot+netdevbpf @ 2026-04-03 22:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, dsahern, netdev, eric.dumazet,
yimingqian591, justin.iurman
In-Reply-To: <20260402101732.1188059-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 10:17:32 +0000 you wrote:
> We need to check __in6_dev_get() for possible NULL value, as
> suggested by Yiming Qian.
>
> Also add skb_dst_dev_rcu() instead of skb_dst_dev(),
> and two missing READ_ONCE().
>
> Note that @dev can't be NULL.
>
> [...]
Here is the summary with links:
- [net] ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()
https://git.kernel.org/netdev/net/c/4e65a8b8daa1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: fec: make FIXED_PHY dependency unconditional
From: patchwork-bot+netdevbpf @ 2026-04-03 22:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, hkallweit1, arnd,
netdev, linux-kernel
In-Reply-To: <20260402141048.2713445-1-arnd@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 16:10:40 +0200 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When CONFIG_FIXED_PHY is in a loadable module, the fec driver cannot be
> built-in any more:
>
> x86_64-linux-ld: vmlinux.o: in function `fec_enet_mii_probe':
> fec_main.c:(.text+0xc4f367): undefined reference to `fixed_phy_unregister'
> x86_64-linux-ld: vmlinux.o: in function `fec_enet_close':
> fec_main.c:(.text+0xc59591): undefined reference to `fixed_phy_unregister'
> x86_64-linux-ld: vmlinux.o: in function `fec_enet_mii_probe.cold':
>
> [...]
Here is the summary with links:
- net: fec: make FIXED_PHY dependency unconditional
https://git.kernel.org/netdev/net/c/e16a0d36777b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 1/1] net: sched: act_csum: validate nested VLAN headers
From: patchwork-bot+netdevbpf @ 2026-04-03 22:00 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, jhs, jiri, davem, edumazet, kuba, pabeni, horms, elibr,
yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z,
caoruide123
In-Reply-To: <22df2fcb49f410203eafa5d97963dd36089f4ecf.1774892775.git.caoruide123@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 22:46:20 +0800 you wrote:
> From: Ruide Cao <caoruide123@gmail.com>
>
> tcf_csum_act() walks nested VLAN headers directly from skb->data when an
> skb still carries in-payload VLAN tags. The current code reads
> vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without
> first ensuring that the full VLAN header is present in the linear area.
>
> [...]
Here is the summary with links:
- [net,1/1] net: sched: act_csum: validate nested VLAN headers
https://git.kernel.org/netdev/net/c/c842743d073b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 net] net: lapbether: handle NETDEV_PRE_TYPE_CHANGE
From: patchwork-bot+netdevbpf @ 2026-04-03 22:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, netdev, eric.dumazet,
syzbot+d8c285748fa7292580a9, ms, linux-x25
In-Reply-To: <20260402103519.1201565-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 10:35:19 +0000 you wrote:
> lapbeth_data_transmit() expects the underlying device type
> to be ARPHRD_ETHER.
>
> Returning NOTIFY_BAD from lapbeth_device_event() makes sure
> bonding driver can not break this expectation.
>
> Fixes: 872254dd6b1f ("net/bonding: Enable bonding to enslave non ARPHRD_ETHER")
> Reported-by: syzbot+d8c285748fa7292580a9@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/69cd22a1.050a0220.70c3a.0002.GAE@google.com/T/#u
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Martin Schiller <ms@dev.tdt.de>
> Cc: linux-x25@vger.kernel.org
>
> [...]
Here is the summary with links:
- [v2,net] net: lapbether: handle NETDEV_PRE_TYPE_CHANGE
https://git.kernel.org/netdev/net/c/b120e4432f9f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] bridge: guard local VLAN-0 FDB helpers against NULL vlan group
From: patchwork-bot+netdevbpf @ 2026-04-03 22:00 UTC (permalink / raw)
To: Zijing Yin
Cc: netdev, bridge, razor, idosch, davem, edumazet, kuba, pabeni,
horms, nathan, nick.desaulniers+lkml, morbo, justinstitt, petrm,
linux-kernel, llvm
In-Reply-To: <20260402140153.3925663-1-yzjaurora@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 07:01:53 -0700 you wrote:
> When CONFIG_BRIDGE_VLAN_FILTERING is not set, br_vlan_group() and
> nbp_vlan_group() return NULL (br_private.h stub definitions). The
> BR_BOOLOPT_FDB_LOCAL_VLAN_0 toggle code is compiled unconditionally and
> reaches br_fdb_delete_locals_per_vlan_port() and
> br_fdb_insert_locals_per_vlan_port(), where the NULL vlan group pointer
> is dereferenced via list_for_each_entry(v, &vg->vlan_list, vlist).
>
> [...]
Here is the summary with links:
- [net] bridge: guard local VLAN-0 FDB helpers against NULL vlan group
https://git.kernel.org/netdev/net/c/1979645e1842
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Jim Mattson @ 2026-04-03 21:59 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm, Asit Mallick,
Tao Zhang, bpf, netdev, linux-doc
In-Reply-To: <20260403213445.xzb4rxbfbg5un7li@desk>
On Fri, Apr 3, 2026 at 2:34 PM Pawan Gupta
<pawan.kumar.gupta@linux.intel.com> wrote:
>
> On Fri, Apr 03, 2026 at 01:19:17PM -0700, Jim Mattson wrote:
> > On Fri, Apr 3, 2026 at 11:52 AM Pawan Gupta
> > <pawan.kumar.gupta@linux.intel.com> wrote:
> > >
> > > On Fri, Apr 03, 2026 at 11:10:08AM -0700, Jim Mattson wrote:
> > > > On Thu, Apr 2, 2026 at 5:32 PM Pawan Gupta
> > > > <pawan.kumar.gupta@linux.intel.com> wrote:
> > > > >
> > > > > As a mitigation for BHI, clear_bhb_loop() executes branches that overwrite
> > > > > the Branch History Buffer (BHB). On Alder Lake and newer parts this
> > > > > sequence is not sufficient because it doesn't clear enough entries. This
> > > > > was not an issue because these CPUs use the BHI_DIS_S hardware mitigation
> > > > > in the kernel.
> > > > >
> > > > > Now with VMSCAPE (BHI variant) it is also required to isolate branch
> > > > > history between guests and userspace. Since BHI_DIS_S only protects the
> > > > > kernel, the newer CPUs also use IBPB.
> > > > >
> > > > > A cheaper alternative to the current IBPB mitigation is clear_bhb_loop().
> > > > > But it currently does not clear enough BHB entries to be effective on newer
> > > > > CPUs with larger BHB. At boot, dynamically set the loop count of
> > > > > clear_bhb_loop() such that it is effective on newer CPUs too. Use the
> > > > > X86_FEATURE_BHI_CTRL feature flag to select the appropriate loop count.
> > > > >
> > > > > Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> > > > > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > > > > ---
> > > > > arch/x86/entry/entry_64.S | 8 +++++---
> > > > > arch/x86/include/asm/nospec-branch.h | 2 ++
> > > > > arch/x86/kernel/cpu/bugs.c | 13 +++++++++++++
> > > > > 3 files changed, 20 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> > > > > index 3a180a36ca0e..bbd4b1c7ec04 100644
> > > > > --- a/arch/x86/entry/entry_64.S
> > > > > +++ b/arch/x86/entry/entry_64.S
> > > > > @@ -1536,7 +1536,9 @@ SYM_FUNC_START(clear_bhb_loop)
> > > > > ANNOTATE_NOENDBR
> > > > > push %rbp
> > > > > mov %rsp, %rbp
> > > > > - movl $5, %ecx
> > > > > +
> > > > > + movzbl bhb_seq_outer_loop(%rip), %ecx
> > > > > +
> > > > > ANNOTATE_INTRA_FUNCTION_CALL
> > > > > call 1f
> > > > > jmp 5f
> > > > > @@ -1556,8 +1558,8 @@ SYM_FUNC_START(clear_bhb_loop)
> > > > > * This should be ideally be: .skip 32 - (.Lret2 - 2f), 0xcc
> > > > > * but some Clang versions (e.g. 18) don't like this.
> > > > > */
> > > > > - .skip 32 - 18, 0xcc
> > > > > -2: movl $5, %eax
> > > > > + .skip 32 - 20, 0xcc
> > > > > +2: movzbl bhb_seq_inner_loop(%rip), %eax
> > > > > 3: jmp 4f
> > > > > nop
> > > > > 4: sub $1, %eax
> > > > > diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> > > > > index 70b377fcbc1c..87b83ae7c97f 100644
> > > > > --- a/arch/x86/include/asm/nospec-branch.h
> > > > > +++ b/arch/x86/include/asm/nospec-branch.h
> > > > > @@ -548,6 +548,8 @@ DECLARE_PER_CPU(u64, x86_spec_ctrl_current);
> > > > > extern void update_spec_ctrl_cond(u64 val);
> > > > > extern u64 spec_ctrl_current(void);
> > > > >
> > > > > +extern u8 bhb_seq_inner_loop, bhb_seq_outer_loop;
> > > > > +
> > > > > /*
> > > > > * With retpoline, we must use IBRS to restrict branch prediction
> > > > > * before calling into firmware.
> > > > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > > > > index 83f51cab0b1e..2cb4a96247d8 100644
> > > > > --- a/arch/x86/kernel/cpu/bugs.c
> > > > > +++ b/arch/x86/kernel/cpu/bugs.c
> > > > > @@ -2047,6 +2047,10 @@ enum bhi_mitigations {
> > > > > static enum bhi_mitigations bhi_mitigation __ro_after_init =
> > > > > IS_ENABLED(CONFIG_MITIGATION_SPECTRE_BHI) ? BHI_MITIGATION_AUTO : BHI_MITIGATION_OFF;
> > > > >
> > > > > +/* Default to short BHB sequence values */
> > > > > +u8 bhb_seq_outer_loop __ro_after_init = 5;
> > > > > +u8 bhb_seq_inner_loop __ro_after_init = 5;
> > > > > +
> > > > > static int __init spectre_bhi_parse_cmdline(char *str)
> > > > > {
> > > > > if (!str)
> > > > > @@ -3242,6 +3246,15 @@ void __init cpu_select_mitigations(void)
> > > > > x86_spec_ctrl_base &= ~SPEC_CTRL_MITIGATIONS_MASK;
> > > > > }
> > > > >
> > > > > + /*
> > > > > + * Switch to long BHB clear sequence on newer CPUs (with BHI_CTRL
> > > > > + * support), see Intel's BHI guidance.
> > > > > + */
> > > > > + if (cpu_feature_enabled(X86_FEATURE_BHI_CTRL)) {
> > > > > + bhb_seq_outer_loop = 12;
> > > > > + bhb_seq_inner_loop = 7;
> > > > > + }
> > > > > +
> > > >
> > > > How does this work for VMs in a heterogeneous migration pool that
> > > > spans the Alder Lake boundary? They can't advertise BHI_CTRL, because
> > > > it isn't available on all hosts in the migration pool, but they need
> > > > the long sequence when running on Alder Lake or newer.
> > >
> > > As we discussed elsewhere, support for migration pool is much more
> > > involved. It should be dealt in a separate QEMU/KVM focused series.
> > >
> > > A quickfix could be adding support for spectre_bhi=long that guests in a
> > > migration pool can use?
> >
> > The simplest solution is to add "|
> > cpu_feature_enabled(X86_FEATURE_HYPERVISOR)" to the condition above.
> > If that is unacceptable for the performance of pre-Alder Lake
>
> Yes, that would be unnecessary overhead.
>
> > migration pools, you could define a CPUID or MSR bit that says
> > explicitly, "long BHB flush sequence needed," rather than trying to
> > intuit that property from the presence of BHI_CTRL. Like
> > IA32_ARCH_CAPABILITIES.SKIP_L1DFL_VMENTRY, the bit would only be set
> > by a hypervisor.
>
> I will think about this more.
>
> > I am still skeptical of the need for MSR_VIRTUAL_ENUMERATION and
> > friends, unless there is a major guest OS out there that relies on
> > them.
>
> If we forget about MSR_VIRTUAL_ENUMERATION for a moment, userspace VMM is
> in the best position to decide whether a guest needs
> virtual.SPEC_CTRL[BHI_DIS_S]. Via a KVM interface userspace VMM can get
> BHI_DIS_S for the guests that are in migration pool?
That is not possible today, since KVM does not implement Intel's
IA32_SPEC_CTRL virtualization, and cedes the hardware IA32_SPEC_CTRL
to the guest after the first non-zero write to the guest's MSR.
^ permalink raw reply
* Re: [PATCH net] ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()
From: Eric Dumazet @ 2026-04-03 21:51 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, pabeni, horms, dsahern, netdev, eric.dumazet,
yimingqian591, justin.iurman
In-Reply-To: <20260403145010.4b4e5865@kernel.org>
On Fri, Apr 3, 2026 at 2:50 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 3 Apr 2026 14:47:32 -0700 Eric Dumazet wrote:
> > > If the ingress device has more RX queues than the egress device (dev) has
> > > TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues.
> > >
> > > Since skb_get_tx_queue() does not clamp the index, will it return an
> > > out-of-bounds pointer into the egress device's dev->_tx array, causing
> > > dereferencing queue->qdisc to read invalid memory?
> >
> > This seems a different bug ?
> >
> > I mean, do we need to fix all bug in a single patch ?
>
> no no, sorry, i'm just sending this out for Justin or you as a separate
> thing.
Ah ok, thanks for the clarification :)
^ permalink raw reply
* Re: [PATCH net] ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()
From: Jakub Kicinski @ 2026-04-03 21:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, pabeni, horms, dsahern, netdev, eric.dumazet,
yimingqian591, justin.iurman
In-Reply-To: <CANn89iKUKTYZ7NVNidtdssZXUAa95LmRpTYUQ29uGE99jLmLOw@mail.gmail.com>
On Fri, 3 Apr 2026 14:47:32 -0700 Eric Dumazet wrote:
> > If the ingress device has more RX queues than the egress device (dev) has
> > TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues.
> >
> > Since skb_get_tx_queue() does not clamp the index, will it return an
> > out-of-bounds pointer into the egress device's dev->_tx array, causing
> > dereferencing queue->qdisc to read invalid memory?
>
> This seems a different bug ?
>
> I mean, do we need to fix all bug in a single patch ?
no no, sorry, i'm just sending this out for Justin or you as a separate
thing.
^ permalink raw reply
* Re: [PATCH net] ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()
From: Eric Dumazet @ 2026-04-03 21:47 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, pabeni, horms, dsahern, netdev, eric.dumazet,
yimingqian591, justin.iurman
In-Reply-To: <20260403214418.2233266-2-kuba@kernel.org>
On Fri, Apr 3, 2026 at 2:44 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> This is an AI-generated review of your patch. The human sending this
> email says "more bugs to fix.."
> ---
> ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()
>
> This commit fixes potential NULL pointer dereferences in
> __ioam6_fill_trace_data() by checking __in6_dev_get() and using
> skb_dst_dev_rcu(). It also adds missing READ_ONCE() annotations.
>
> > diff --git a/net/ipv6/ioam6.c b/net/ipv6/ioam6.c
> > index 3978773bec42..05a0b7d7e2aa 100644
> > --- a/net/ipv6/ioam6.c
> > +++ b/net/ipv6/ioam6.c
> > @@ -710,7 +710,9 @@ static void __ioam6_fill_trace_data(struct sk_buff *skb,
> > struct ioam6_schema *sc,
> > unsigned int sclen, bool is_input)
> > {
> > - struct net_device *dev = skb_dst_dev(skb);
> > + /* Note: skb_dst_dev_rcu() can't be NULL at this point. */
> > + struct net_device *dev = skb_dst_dev_rcu(skb);
>
> Could this code lead to an out-of-bounds access of the dev->_tx[] array
> further down in this function?
>
> While reviewing this patch, a pre-existing regression was noticed when
> trace->type.bit6 is set:
>
> if (trace->type.bit6) {
> ...
> queue = skb_get_tx_queue(dev, skb);
> qdisc = rcu_dereference(queue->qdisc);
>
> When is_input is true, the packet is on the RX path and skb->queue_mapping
> contains the RX queue index of the ingress device.
>
> If the ingress device has more RX queues than the egress device (dev) has
> TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues.
>
> Since skb_get_tx_queue() does not clamp the index, will it return an
> out-of-bounds pointer into the egress device's dev->_tx array, causing
> dereferencing queue->qdisc to read invalid memory?
This seems a different bug ?
I mean, do we need to fix all bug in a single patch ?
^ permalink raw reply
* Re: [PATCH 6/7] clk: qcom: gcc: Add multiple global clock controller driver for Nord SoC
From: Dmitry Baryshkov @ 2026-04-03 21:46 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Taniya Das,
Richard Cochran, Shawn Guo, Deepti Jaggi, linux-arm-msm,
linux-clk, devicetree, linux-kernel, netdev
In-Reply-To: <20260403-nord-clks-v1-6-018af14979fd@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 04:10:54PM +0200, Bartosz Golaszewski wrote:
> From: Taniya Das <taniya.das@oss.qualcomm.com>
>
> The global clock controller on the Nord SoC is partitioned into
> GCC, SE_GCC, NE_GCC, and NW_GCC. Introduce driver support for each
> of these controllers.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> [Shawn: Drop include of <linux/of.h> as the driver doesn't use any OF APIs]
> Co-developed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 10 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/gcc-nord.c | 1901 +++++++++++++++++++++++++++++++++++++++
> drivers/clk/qcom/negcc-nord.c | 1987 +++++++++++++++++++++++++++++++++++++++++
> drivers/clk/qcom/nwgcc-nord.c | 688 ++++++++++++++
> drivers/clk/qcom/segcc-nord.c | 1609 +++++++++++++++++++++++++++++++++
> 6 files changed, 6196 insertions(+)
>
> +
> +static const struct qcom_cc_desc se_gcc_nord_desc = {
> + .config = &se_gcc_nord_regmap_config,
> + .clks = se_gcc_nord_clocks,
> + .num_clks = ARRAY_SIZE(se_gcc_nord_clocks),
> + .resets = se_gcc_nord_resets,
> + .num_resets = ARRAY_SIZE(se_gcc_nord_resets),
> + .gdscs = se_gcc_nord_gdscs,
> + .num_gdscs = ARRAY_SIZE(se_gcc_nord_gdscs),
> + .driver_data = &se_gcc_nord_driver_data,
use_rpm = true?
(here and in other drivers)
> +};
> +
> +static const struct of_device_id se_gcc_nord_match_table[] = {
> + { .compatible = "qcom,nord-segcc" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, se_gcc_nord_match_table);
> +
> +static int se_gcc_nord_probe(struct platform_device *pdev)
> +{
> + return qcom_cc_probe(pdev, &se_gcc_nord_desc);
> +}
> +
> +static struct platform_driver se_gcc_nord_driver = {
> + .probe = se_gcc_nord_probe,
> + .driver = {
> + .name = "segcc-nord",
> + .of_match_table = se_gcc_nord_match_table,
> + },
> +};
> +
> +module_platform_driver(se_gcc_nord_driver);
> +
> +MODULE_DESCRIPTION("QTI SEGCC NORD Driver");
> +MODULE_LICENSE("GPL");
>
> --
> 2.47.3
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH net] ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()
From: Jakub Kicinski @ 2026-04-03 21:44 UTC (permalink / raw)
To: edumazet
Cc: Jakub Kicinski, davem, pabeni, horms, dsahern, netdev,
eric.dumazet, yimingqian591, justin.iurman
In-Reply-To: <20260402101732.1188059-1-edumazet@google.com>
This is an AI-generated review of your patch. The human sending this
email says "more bugs to fix.."
---
ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()
This commit fixes potential NULL pointer dereferences in
__ioam6_fill_trace_data() by checking __in6_dev_get() and using
skb_dst_dev_rcu(). It also adds missing READ_ONCE() annotations.
> diff --git a/net/ipv6/ioam6.c b/net/ipv6/ioam6.c
> index 3978773bec42..05a0b7d7e2aa 100644
> --- a/net/ipv6/ioam6.c
> +++ b/net/ipv6/ioam6.c
> @@ -710,7 +710,9 @@ static void __ioam6_fill_trace_data(struct sk_buff *skb,
> struct ioam6_schema *sc,
> unsigned int sclen, bool is_input)
> {
> - struct net_device *dev = skb_dst_dev(skb);
> + /* Note: skb_dst_dev_rcu() can't be NULL at this point. */
> + struct net_device *dev = skb_dst_dev_rcu(skb);
Could this code lead to an out-of-bounds access of the dev->_tx[] array
further down in this function?
While reviewing this patch, a pre-existing regression was noticed when
trace->type.bit6 is set:
if (trace->type.bit6) {
...
queue = skb_get_tx_queue(dev, skb);
qdisc = rcu_dereference(queue->qdisc);
When is_input is true, the packet is on the RX path and skb->queue_mapping
contains the RX queue index of the ingress device.
If the ingress device has more RX queues than the egress device (dev) has
TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues.
Since skb_get_tx_queue() does not clamp the index, will it return an
out-of-bounds pointer into the egress device's dev->_tx array, causing
dereferencing queue->qdisc to read invalid memory?
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix memory leak in airoha_qdma_rx_process()
From: Jakub Kicinski @ 2026-04-03 21:42 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260402-airoha_qdma_rx_process-mem-leak-fix-v1-1-b5706f402d3c@kernel.org>
This is an AI-generated review of your patch. The human sending this
email says: "more thing to fix.."
---
net: airoha: Fix memory leak in airoha_qdma_rx_process()
This commit fixes a memory leak in the error path of
airoha_qdma_rx_process() by partially reverting a previous commit and
always calling page_pool_put_full_page().
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 95ba99b89428e..91cb63a32d990 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -697,9 +697,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
This problem wasn't introduced by this patch, but while reviewing this
function I noticed the descriptor field msg1 is read from memory before
the ownership bit is validated:
airoha_qdma_rx_process() {
while (done < budget) {
struct airoha_queue_entry *e = &q->entry[q->tail];
struct airoha_qdma_desc *desc = &q->desc[q->tail];
u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
struct page *page = virt_to_head_page(e->buf);
u32 desc_ctrl = le32_to_cpu(desc->ctrl);
if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
break;
Could this lead to processing stale descriptor metadata? On weakly-ordered
architectures, the CPU might reorder these reads before the device commits
the new descriptor data.
Are we missing a dma_rmb() after the ownership check?
> if (q->skb) {
> dev_kfree_skb(q->skb);
> q->skb = NULL;
> - } else {
> - page_pool_put_full_page(q->page_pool, page, true);
> }
This is also an existing issue, but does jumping to this error path on a
scattered packet fragment leave the receive loop in an inconsistent state?
If an error occurs while processing a middle fragment of a packet, q->skb
is freed and set to NULL here. However, the loop continues to the next
descriptor.
Since q->skb is now NULL, won't the next fragment of the same corrupted
packet be erroneously parsed as the start of a brand new Ethernet frame:
if (!q->skb) { /* first buffer */
q->skb = napi_build_skb(e->buf, q->buf_size);
Could this desynchronization allow arbitrary payload to be injected into
the network stack as a legitimate packet? The driver may need to discard
all subsequent fragments until a descriptor without QDMA_DESC_MORE_MASK is
encountered.
> + page_pool_put_full_page(q->page_pool, page, true);
> }
> airoha_qdma_fill_rx_queue(q);
>
^ permalink raw reply
* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-04-03 21:34 UTC (permalink / raw)
To: Jim Mattson
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm, Asit Mallick,
Tao Zhang, bpf, netdev, linux-doc
In-Reply-To: <CALMp9eSPkMpKQELTnsaj6=gXD+EyE0n2_p93n4maDc93bPFe+w@mail.gmail.com>
On Fri, Apr 03, 2026 at 01:19:17PM -0700, Jim Mattson wrote:
> On Fri, Apr 3, 2026 at 11:52 AM Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com> wrote:
> >
> > On Fri, Apr 03, 2026 at 11:10:08AM -0700, Jim Mattson wrote:
> > > On Thu, Apr 2, 2026 at 5:32 PM Pawan Gupta
> > > <pawan.kumar.gupta@linux.intel.com> wrote:
> > > >
> > > > As a mitigation for BHI, clear_bhb_loop() executes branches that overwrite
> > > > the Branch History Buffer (BHB). On Alder Lake and newer parts this
> > > > sequence is not sufficient because it doesn't clear enough entries. This
> > > > was not an issue because these CPUs use the BHI_DIS_S hardware mitigation
> > > > in the kernel.
> > > >
> > > > Now with VMSCAPE (BHI variant) it is also required to isolate branch
> > > > history between guests and userspace. Since BHI_DIS_S only protects the
> > > > kernel, the newer CPUs also use IBPB.
> > > >
> > > > A cheaper alternative to the current IBPB mitigation is clear_bhb_loop().
> > > > But it currently does not clear enough BHB entries to be effective on newer
> > > > CPUs with larger BHB. At boot, dynamically set the loop count of
> > > > clear_bhb_loop() such that it is effective on newer CPUs too. Use the
> > > > X86_FEATURE_BHI_CTRL feature flag to select the appropriate loop count.
> > > >
> > > > Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> > > > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > > > ---
> > > > arch/x86/entry/entry_64.S | 8 +++++---
> > > > arch/x86/include/asm/nospec-branch.h | 2 ++
> > > > arch/x86/kernel/cpu/bugs.c | 13 +++++++++++++
> > > > 3 files changed, 20 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> > > > index 3a180a36ca0e..bbd4b1c7ec04 100644
> > > > --- a/arch/x86/entry/entry_64.S
> > > > +++ b/arch/x86/entry/entry_64.S
> > > > @@ -1536,7 +1536,9 @@ SYM_FUNC_START(clear_bhb_loop)
> > > > ANNOTATE_NOENDBR
> > > > push %rbp
> > > > mov %rsp, %rbp
> > > > - movl $5, %ecx
> > > > +
> > > > + movzbl bhb_seq_outer_loop(%rip), %ecx
> > > > +
> > > > ANNOTATE_INTRA_FUNCTION_CALL
> > > > call 1f
> > > > jmp 5f
> > > > @@ -1556,8 +1558,8 @@ SYM_FUNC_START(clear_bhb_loop)
> > > > * This should be ideally be: .skip 32 - (.Lret2 - 2f), 0xcc
> > > > * but some Clang versions (e.g. 18) don't like this.
> > > > */
> > > > - .skip 32 - 18, 0xcc
> > > > -2: movl $5, %eax
> > > > + .skip 32 - 20, 0xcc
> > > > +2: movzbl bhb_seq_inner_loop(%rip), %eax
> > > > 3: jmp 4f
> > > > nop
> > > > 4: sub $1, %eax
> > > > diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> > > > index 70b377fcbc1c..87b83ae7c97f 100644
> > > > --- a/arch/x86/include/asm/nospec-branch.h
> > > > +++ b/arch/x86/include/asm/nospec-branch.h
> > > > @@ -548,6 +548,8 @@ DECLARE_PER_CPU(u64, x86_spec_ctrl_current);
> > > > extern void update_spec_ctrl_cond(u64 val);
> > > > extern u64 spec_ctrl_current(void);
> > > >
> > > > +extern u8 bhb_seq_inner_loop, bhb_seq_outer_loop;
> > > > +
> > > > /*
> > > > * With retpoline, we must use IBRS to restrict branch prediction
> > > > * before calling into firmware.
> > > > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > > > index 83f51cab0b1e..2cb4a96247d8 100644
> > > > --- a/arch/x86/kernel/cpu/bugs.c
> > > > +++ b/arch/x86/kernel/cpu/bugs.c
> > > > @@ -2047,6 +2047,10 @@ enum bhi_mitigations {
> > > > static enum bhi_mitigations bhi_mitigation __ro_after_init =
> > > > IS_ENABLED(CONFIG_MITIGATION_SPECTRE_BHI) ? BHI_MITIGATION_AUTO : BHI_MITIGATION_OFF;
> > > >
> > > > +/* Default to short BHB sequence values */
> > > > +u8 bhb_seq_outer_loop __ro_after_init = 5;
> > > > +u8 bhb_seq_inner_loop __ro_after_init = 5;
> > > > +
> > > > static int __init spectre_bhi_parse_cmdline(char *str)
> > > > {
> > > > if (!str)
> > > > @@ -3242,6 +3246,15 @@ void __init cpu_select_mitigations(void)
> > > > x86_spec_ctrl_base &= ~SPEC_CTRL_MITIGATIONS_MASK;
> > > > }
> > > >
> > > > + /*
> > > > + * Switch to long BHB clear sequence on newer CPUs (with BHI_CTRL
> > > > + * support), see Intel's BHI guidance.
> > > > + */
> > > > + if (cpu_feature_enabled(X86_FEATURE_BHI_CTRL)) {
> > > > + bhb_seq_outer_loop = 12;
> > > > + bhb_seq_inner_loop = 7;
> > > > + }
> > > > +
> > >
> > > How does this work for VMs in a heterogeneous migration pool that
> > > spans the Alder Lake boundary? They can't advertise BHI_CTRL, because
> > > it isn't available on all hosts in the migration pool, but they need
> > > the long sequence when running on Alder Lake or newer.
> >
> > As we discussed elsewhere, support for migration pool is much more
> > involved. It should be dealt in a separate QEMU/KVM focused series.
> >
> > A quickfix could be adding support for spectre_bhi=long that guests in a
> > migration pool can use?
>
> The simplest solution is to add "|
> cpu_feature_enabled(X86_FEATURE_HYPERVISOR)" to the condition above.
> If that is unacceptable for the performance of pre-Alder Lake
Yes, that would be unnecessary overhead.
> migration pools, you could define a CPUID or MSR bit that says
> explicitly, "long BHB flush sequence needed," rather than trying to
> intuit that property from the presence of BHI_CTRL. Like
> IA32_ARCH_CAPABILITIES.SKIP_L1DFL_VMENTRY, the bit would only be set
> by a hypervisor.
I will think about this more.
> I am still skeptical of the need for MSR_VIRTUAL_ENUMERATION and
> friends, unless there is a major guest OS out there that relies on
> them.
If we forget about MSR_VIRTUAL_ENUMERATION for a moment, userspace VMM is
in the best position to decide whether a guest needs
virtual.SPEC_CTRL[BHI_DIS_S]. Via a KVM interface userspace VMM can get
BHI_DIS_S for the guests that are in migration pool?
^ permalink raw reply
* Re: [PATCH net-next v3 1/3] gve: skip error logging for retryable AdminQ commands
From: Jordan Rhee @ 2026-04-03 21:29 UTC (permalink / raw)
To: Jacob Keller
Cc: Harshitha Ramamurthy, netdev, joshwash, andrew+netdev, davem,
edumazet, kuba, pabeni, richardcochran, willemb, nktgrg, jfraker,
ziweixiao, maolson, thostet, jefrogers, alok.a.tiwari, yyd,
linux-kernel
In-Reply-To: <1e3a815e-4fdf-4bf4-b298-42abeed67fcf@intel.com>
On Fri, Apr 3, 2026 at 2:11 PM Jacob Keller <jacob.e.keller@intel.com> wrote:
>
> On 4/3/2026 12:44 PM, Harshitha Ramamurthy wrote:
> > From: Jordan Rhee <jordanrhee@google.com>
> >
> > AdminQ commands may return -EAGAIN under certain transient conditions.
> > These commands are intended to be retried by the driver, so logging
> > a formal error to the system log is misleading and creates
> > unnecessary noise.
> >
> > Modify the logging logic to skip the error message when the result
> > is -EAGAIN.
> >
>
> The implementation changes from using dev_err() to using
> dev_err_ratelimited(). IMO that is a good change but it would be nice if
> this was mentioned in the commit message.
Ack, will do.
>
> Thanks,
> Jake
>
> > Reviewed-by: Joshua Washington <joshwash@google.com>
> > Signed-off-by: Jordan Rhee <jordanrhee@google.com>
> > Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
> > ---
> > drivers/net/ethernet/google/gve/gve_adminq.c | 26 +++++++++++++++-----
> > 1 file changed, 20 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/google/gve/gve_adminq.c b/drivers/net/ethernet/google/gve/gve_adminq.c
> > index 08587bf40ed4..c7834614c5f0 100644
> > --- a/drivers/net/ethernet/google/gve/gve_adminq.c
> > +++ b/drivers/net/ethernet/google/gve/gve_adminq.c
> > @@ -416,11 +416,6 @@ static bool gve_adminq_wait_for_cmd(struct gve_priv *priv, u32 prod_cnt)
> >
> > static int gve_adminq_parse_err(struct gve_priv *priv, u32 status)
> > {
> > - if (status != GVE_ADMINQ_COMMAND_PASSED &&
> > - status != GVE_ADMINQ_COMMAND_UNSET) {
> > - dev_err(&priv->pdev->dev, "AQ command failed with status %d\n", status);
> > - priv->adminq_cmd_fail++;
> > - }
>
> You also now log every error regardless of what the status is since this
> is no longer checked?
PASSED gets translated to err=0, so it will not be printed.
You bring up a good point that GVE_ADMINQ_COMMAND_UNSET will now
result in two messages being printed:
dev_err(&priv->pdev->dev, "parse_aq_err: err and status both
unset, this should not be possible.\n");
dev_err_ratelimited(&priv->pdev->dev, "AQ command %d failed with
status %d\n", opcode, status);
The first message doesn't make sense anymore, so I'll remove it.
Thanks for catching this.
>
> > switch (status) {
> > case GVE_ADMINQ_COMMAND_PASSED:
> > return 0;
> > @@ -455,6 +450,16 @@ static int gve_adminq_parse_err(struct gve_priv *priv, u32 status)
> > }
> > }
> >
> > +static bool gve_adminq_is_retryable(enum gve_adminq_opcodes opcode)
> > +{
> > + switch (opcode) {
> > + case GVE_ADMINQ_REPORT_NIC_TIMESTAMP:
> > + return true;
> > + default:
> > + return false;
> > + }
> > +}
> > +
> > /* Flushes all AQ commands currently queued and waits for them to complete.
> > * If there are failures, it will return the first error.
> > */
> > @@ -482,9 +487,18 @@ static int gve_adminq_kick_and_wait(struct gve_priv *priv)
> > cmd = &priv->adminq[i & priv->adminq_mask];
> > status = be32_to_cpu(READ_ONCE(cmd->status));
> > err = gve_adminq_parse_err(priv, status);
> > - if (err)
> > + if (err) {
> > + enum gve_adminq_opcodes opcode =
> > + be32_to_cpu(READ_ONCE(cmd->opcode));
> > + priv->adminq_cmd_fail++;
> > + if (!gve_adminq_is_retryable(opcode) || err != -EAGAIN)
> > + dev_err_ratelimited(&priv->pdev->dev,
> > + "AQ command %d failed with status %d\n",
> > + opcode, status);
> > +
> > // Return the first error if we failed.
> > return err;
> > + }
> > }
> >
> > return 0;
>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net] ice: fix PTP timestamping broken by SyncE code on E825C
From: Mekala, SunithaX D @ 2026-04-03 21:28 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Vecera, Ivan, Kitszel, Przemyslaw, Richard Cochran, Eric Dumazet,
stable@vger.kernel.org, Kubalewski, Arkadiusz,
Loktionov, Aleksandr, Andrew Lunn, Nguyen, Anthony L,
intel-wired-lan@lists.osuosl.org, Jakub Kicinski, Paolo Abeni,
David S. Miller, linux-kernel@vger.kernel.org
In-Reply-To: <20260327074658.2963328-1-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr Oros
> Sent: Friday, March 27, 2026 12:47 AM
> To: netdev@vger.kernel.org
> Cc: Vecera, Ivan <ivecera@redhat.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Richard Cochran <richardcochran@gmail.com>; Eric Dumazet <edumazet@google.com>; > stable@vger.kernel.org; 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>; 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] ice: fix PTP timestamping broken by SyncE code on E825C
>
> The E825C SyncE support added in commit ad1df4f2d591 ("ice: dpll:
> Support E825-C SyncE and dynamic pin discovery") introduced a SyncE
> reconfiguration block in ice_ptp_link_change() that prevents
> ice_ptp_port_phy_restart() from being called in several error paths.
> Without the PHY restart, PTP timestamps stop working after any link
> change event.
>
> There are three ways the PHY restart gets blocked:
>
> 1. When DPLL initialization fails (e.g. missing ACPI firmware node
> properties), ICE_FLAG_DPLL is not set and the function returns early
> before reaching the PHY restart.
>
> 2. When ice_tspll_bypass_mux_active_e825c() fails to read the CGU
> register, WARN_ON_ONCE fires and the function returns early.
>
>3. When ice_tspll_cfg_synce_ethdiv_e825c() fails to configure the
> clock divider for an active pin, same early return.
>
>SyncE and PTP are independent features. SyncE reconfiguration failures
>must not prevent the PTP PHY restart that is essential for timestamp
>recovery after link changes.
>
>Fix by making the entire SyncE block conditional on ICE_FLAG_DPLL
>without an early return, and replacing the WARN_ON_ONCE + return error
>handling inside the loop with dev_err_once + break. The function always
>proceeds to ice_ptp_port_phy_restart() regardless of SyncE errors.
>
>Fixes: ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and dynamic pin discovery")
>Signed-off-by: Petr Oros <poros@redhat.com>
>---
> drivers/net/ethernet/intel/ice/ice_ptp.c | 22 ++++++++++++----------
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* Re: [PATCH net-next v3 3/3] gve: implement PTP gettimex64
From: Jacob Keller @ 2026-04-03 21:17 UTC (permalink / raw)
To: Harshitha Ramamurthy, netdev
Cc: joshwash, andrew+netdev, davem, edumazet, kuba, pabeni,
richardcochran, willemb, nktgrg, jfraker, ziweixiao, maolson,
thostet, jordanrhee, jefrogers, alok.a.tiwari, yyd, linux-kernel,
Naman Gulati
In-Reply-To: <20260403194427.1830609-4-hramamurthy@google.com>
On 4/3/2026 12:44 PM, Harshitha Ramamurthy wrote:
> From: Jordan Rhee <jordanrhee@google.com>
>
> Enable chrony and phc2sys to synchronize system clock to NIC clock.
>
> The system cycle counters are sampled by the device to minimize the
> uncertainty window. If the system times are sampled in the host, the
> delta between pre and post readings is 100us or more due to AQ command
> latency. The system times returned by the device have a delta of ~1us,
> which enables significantly more accurate clock synchronization.
>
> Reviewed-by: Willem de Bruijn <willemb@google.com>
> Reviewed-by: Kevin Yang <yyd@google.com>
> Reviewed-by: Naman Gulati <namangulati@google.com>
> Signed-off-by: Jordan Rhee <jordanrhee@google.com>
> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
> ---
> +/*
> + * Convert a raw cycle count (e.g. from get_cycles()) to the system clock
> + * type specified by clockid. The system_time_snapshot must be taken before
> + * the cycle counter is sampled.
> + */
> +static int gve_cycles_to_timespec64(struct gve_priv *priv, clockid_t clockid,
> + struct system_time_snapshot *snap,
> + u64 cycles, struct timespec64 *ts)
> +{
> + struct gve_cycles_to_clock_callback_ctx ctx = {0};
> + struct system_device_crosststamp xtstamp;
> + int err;
> +
> + ctx.cycles = cycles;
> + err = get_device_system_crosststamp(gve_cycles_to_clock_fn, &ctx, snap,
> + &xtstamp);
> + if (err) {
> + dev_err_ratelimited(&priv->pdev->dev,
> + "get_device_system_crosststamp() failed to convert %lld cycles to system time: %d\n",
> + cycles,
> + err);
> + return err;
> + }
> +
This looks a lot like a cross timestamp (i.e. something like PCIe PTM)
Why not just implement the .crosstimestamp and PTP_SYS_OFF_PRECISE? Does
that not work properly? Or is this not really a cross timestamp despite
use of the get_device_system_crosststamp handler? :D
Thanks,
Jake
> + switch (clockid) {
> + case CLOCK_REALTIME:
> + *ts = ktime_to_timespec64(xtstamp.sys_realtime);
> + break;
> + case CLOCK_MONOTONIC_RAW:
> + *ts = ktime_to_timespec64(xtstamp.sys_monoraw);
> + break;
> + default:
> + dev_err_ratelimited(&priv->pdev->dev,
> + "Cycle count conversion to clockid %d not supported\n",
> + clockid);
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +
^ permalink raw reply
* Re: [PATCH net-next v3 1/3] gve: skip error logging for retryable AdminQ commands
From: Jacob Keller @ 2026-04-03 21:11 UTC (permalink / raw)
To: Harshitha Ramamurthy, netdev
Cc: joshwash, andrew+netdev, davem, edumazet, kuba, pabeni,
richardcochran, willemb, nktgrg, jfraker, ziweixiao, maolson,
thostet, jordanrhee, jefrogers, alok.a.tiwari, yyd, linux-kernel
In-Reply-To: <20260403194427.1830609-2-hramamurthy@google.com>
On 4/3/2026 12:44 PM, Harshitha Ramamurthy wrote:
> From: Jordan Rhee <jordanrhee@google.com>
>
> AdminQ commands may return -EAGAIN under certain transient conditions.
> These commands are intended to be retried by the driver, so logging
> a formal error to the system log is misleading and creates
> unnecessary noise.
>
> Modify the logging logic to skip the error message when the result
> is -EAGAIN.
>
The implementation changes from using dev_err() to using
dev_err_ratelimited(). IMO that is a good change but it would be nice if
this was mentioned in the commit message.
Thanks,
Jake
> Reviewed-by: Joshua Washington <joshwash@google.com>
> Signed-off-by: Jordan Rhee <jordanrhee@google.com>
> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
> ---
> drivers/net/ethernet/google/gve/gve_adminq.c | 26 +++++++++++++++-----
> 1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/google/gve/gve_adminq.c b/drivers/net/ethernet/google/gve/gve_adminq.c
> index 08587bf40ed4..c7834614c5f0 100644
> --- a/drivers/net/ethernet/google/gve/gve_adminq.c
> +++ b/drivers/net/ethernet/google/gve/gve_adminq.c
> @@ -416,11 +416,6 @@ static bool gve_adminq_wait_for_cmd(struct gve_priv *priv, u32 prod_cnt)
>
> static int gve_adminq_parse_err(struct gve_priv *priv, u32 status)
> {
> - if (status != GVE_ADMINQ_COMMAND_PASSED &&
> - status != GVE_ADMINQ_COMMAND_UNSET) {
> - dev_err(&priv->pdev->dev, "AQ command failed with status %d\n", status);
> - priv->adminq_cmd_fail++;
> - }
You also now log every error regardless of what the status is since this
is no longer checked?
> switch (status) {
> case GVE_ADMINQ_COMMAND_PASSED:
> return 0;
> @@ -455,6 +450,16 @@ static int gve_adminq_parse_err(struct gve_priv *priv, u32 status)
> }
> }
>
> +static bool gve_adminq_is_retryable(enum gve_adminq_opcodes opcode)
> +{
> + switch (opcode) {
> + case GVE_ADMINQ_REPORT_NIC_TIMESTAMP:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> /* Flushes all AQ commands currently queued and waits for them to complete.
> * If there are failures, it will return the first error.
> */
> @@ -482,9 +487,18 @@ static int gve_adminq_kick_and_wait(struct gve_priv *priv)
> cmd = &priv->adminq[i & priv->adminq_mask];
> status = be32_to_cpu(READ_ONCE(cmd->status));
> err = gve_adminq_parse_err(priv, status);
> - if (err)
> + if (err) {
> + enum gve_adminq_opcodes opcode =
> + be32_to_cpu(READ_ONCE(cmd->opcode));
> + priv->adminq_cmd_fail++;
> + if (!gve_adminq_is_retryable(opcode) || err != -EAGAIN)
> + dev_err_ratelimited(&priv->pdev->dev,
> + "AQ command %d failed with status %d\n",
> + opcode, status);
> +
> // Return the first error if we failed.
> return err;
> + }
> }
>
> return 0;
^ permalink raw reply
* Re: [PATCH] netfilter: xt_HL: add pr_fmt, default case and NULL checks
From: Pablo Neira Ayuso @ 2026-04-03 21:01 UTC (permalink / raw)
To: Marino Dzalto; +Cc: fw, netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20260403193929.89449-1-marino.dzalto@gmail.com>
On Fri, Apr 03, 2026 at 09:39:29PM +0200, Marino Dzalto wrote:
> diff --git a/net/netfilter/xt_hl.c b/net/netfilter/xt_hl.c
> index c1a70f8f0..9434d5ca8 100644
> --- a/net/netfilter/xt_hl.c
> +++ b/net/netfilter/xt_hl.c
[...]
> static bool hl_mt6(const struct sk_buff *skb, struct xt_action_param *par)
> {
> const struct ip6t_hl_info *info = par->matchinfo;
> - const struct ipv6hdr *ip6h = ipv6_hdr(skb);
> + const struct ipv6hdr *ip6h;
> +
> + if (!skb)
> + return false;
No skb !?
This codebase is frozen, I don't see any benefit in this update.
^ permalink raw reply
* Re: [PATCH net v3 0/7] net/sched: Fix packet loops in mirred and netem
From: Jakub Kicinski @ 2026-04-03 21:00 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20260403120354.6e926c05@phoenix.local>
On Fri, 3 Apr 2026 12:03:54 -0700 Stephen Hemminger wrote:
> On Thu, 2 Apr 2026 17:49:06 -0700
> Jakub Kicinski <kuba@kernel.org> wrote:
>
> > On Thu, 2 Apr 2026 13:16:18 -0700 Stephen Hemminger wrote:
> > > Why is this marked Changes Requested.
> >
> > Is this a question.
> Yes a process question what is the blocker? What needs to change?
> More review?
I think what happened was it was posted at the same time as another
series for netem and made TDC fail. Then Jamal said something which
TBH I didn't completely follow so I left it as Changes Requested :S
Imperfection of the maintainer, I'd say :S
Please repost if the series is good (presumably once the other
series you have pending for net goes in?)
^ permalink raw reply
* Re: [PATCH net-next 1/9] net: tso: add tso_features_check()
From: Eric Dumazet @ 2026-04-03 21:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David S . Miller, Paolo Abeni, Simon Horman, Andrew Lunn,
Joe Damato, netdev, eric.dumazet
In-Reply-To: <CANn89i+SnfFboyNed81NvBDXHMGe6oWgE3AGcGfDb7eqg7z4jA@mail.gmail.com>
On Fri, Apr 3, 2026 at 1:49 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Fri, Apr 3, 2026 at 1:47 PM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Fri, 3 Apr 2026 00:20:13 -0700 Eric Dumazet wrote:
> > > > I forgot that netif_skb_features() uses:
> > > >
> > > > if (dev->netdev_ops->ndo_features_check)
> > > > features &= dev->netdev_ops->ndo_features_check(skb, dev,
> > > > features);
> > > > else
> > > > features &= dflt_features_check(skb, dev, features);
> > > >
> > > > So I need to call vlan_features_check() from tso_features_check()
> > >
> > > I could be wrong though, vlan_features_check() is about skbs with
> > > multiple vlan tags,
> > > and net/core/tso.c should support them just fine.
> >
> > But we probably still need to clear NETIF_F_IP_CSUM for example?
> > Better safe than sorry. (I won't repeat the sashiko complaints
> > assuming you saw those ;))
>
> Ah not yet, let me check ;)
Oh well, lots of orthonal errors.
It is probably time for qdisc_pkt_len_segs_init() to pull the headers
(at least for GSO packets)
and return an error if this pull fails, instead of letting malicious
packets continue their way :/
^ permalink raw reply
* [PATCH v3] netfilter: xt_HL: add pr_fmt and checkentry validation
From: Marino Dzalto @ 2026-04-03 20:59 UTC (permalink / raw)
To: pablo, fw
Cc: jacob.e.keller, netfilter-devel, coreteam, netdev, linux-kernel,
Marino Dzalto
Add pr_fmt to prefix log messages with the module name for
easier debugging in dmesg.
Add checkentry functions for IPv4 (ttl_mt_check) and IPv6
(hl_mt6_check) to validate the match mode at rule registration
time, rejecting invalid modes with -EINVAL.
Signed-off-by: Marino Dzalto <marino.dzalto@gmail.com>
---
v3: Remove mention of NULL checks from commit message, as they
were never part of the original code.
v2: Remove NULL checks for skb as suggested by Florian Westphal
(skb is guaranteed non-NULL by netfilter core). Move mode
validation to checkentry functions instead of match function,
also as suggested by Florian Westphal.
---
net/netfilter/xt_hl.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/net/netfilter/xt_hl.c b/net/netfilter/xt_hl.c
index c1a70f8f0441..4a12a757ecbf 100644
--- a/net/netfilter/xt_hl.c
+++ b/net/netfilter/xt_hl.c
@@ -6,6 +6,7 @@
* Hop Limit matching module
* (C) 2001-2002 Maciej Soltysiak <solt@dns.toxicfilms.tv>
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/ip.h>
#include <linux/ipv6.h>
@@ -22,6 +23,18 @@ MODULE_LICENSE("GPL");
MODULE_ALIAS("ipt_ttl");
MODULE_ALIAS("ip6t_hl");
+static int ttl_mt_check(const struct xt_mtchk_param *par)
+{
+ const struct ipt_ttl_info *info = par->matchinfo;
+
+ if (info->mode > IPT_TTL_GT) {
+ pr_err("Unknown TTL match mode: %d\n", info->mode);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static bool ttl_mt(const struct sk_buff *skb, struct xt_action_param *par)
{
const struct ipt_ttl_info *info = par->matchinfo;
@@ -41,6 +54,18 @@ static bool ttl_mt(const struct sk_buff *skb, struct xt_action_param *par)
return false;
}
+static int hl_mt6_check(const struct xt_mtchk_param *par)
+{
+ const struct ip6t_hl_info *info = par->matchinfo;
+
+ if (info->mode > IP6T_HL_GT) {
+ pr_err("Unknown Hop Limit match mode: %d\n", info->mode);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static bool hl_mt6(const struct sk_buff *skb, struct xt_action_param *par)
{
const struct ip6t_hl_info *info = par->matchinfo;
@@ -65,6 +90,7 @@ static struct xt_match hl_mt_reg[] __read_mostly = {
.name = "ttl",
.revision = 0,
.family = NFPROTO_IPV4,
+ .checkentry = ttl_mt_check,
.match = ttl_mt,
.matchsize = sizeof(struct ipt_ttl_info),
.me = THIS_MODULE,
@@ -73,6 +99,7 @@ static struct xt_match hl_mt_reg[] __read_mostly = {
.name = "hl",
.revision = 0,
.family = NFPROTO_IPV6,
+ .checkentry = hl_mt6_check,
.match = hl_mt6,
.matchsize = sizeof(struct ip6t_hl_info),
.me = THIS_MODULE,
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH iwl-next] ixgbe: extend 5 s SWFW semaphore timeout to all X550EM variants
From: Tony Nguyen @ 2026-04-03 20:55 UTC (permalink / raw)
To: Aleksandr Loktionov, intel-wired-lan; +Cc: netdev
In-Reply-To: <20260327073046.134085-12-aleksandr.loktionov@intel.com>
On 3/27/2026 12:30 AM, Aleksandr Loktionov wrote:
> From: Marta Plantykow <marta.a.plantykow@intel.com>
>
> The 5-second SWFW semaphore timeout added for X550 (ixgbe_mac_X550)
> also applies to X550EM devices (e.g. X550EM_a, X550EM_x) since they
> share the same FW and the same SR-dump-driven worst-case latency of
> ~3.2 s / module-update latency of ~4.5 s. Change the mac-type
> comparison from '== ixgbe_mac_X550' to a range check that covers
> all three X550-family enum values (ixgbe_mac_X550, ixgbe_mac_X550EM_x,
> ixgbe_mac_x550em_a) without inadvertently capturing later entries such
> as ixgbe_mac_e610 which share the same swfw-sync function but have
> not been validated against this exact timing requirement.
>
> Signed-off-by: Marta Plantykow <marta.a.plantykow@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
> index 85047ef..298958d 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
> @@ -577,7 +577,8 @@ int ixgbe_acquire_swfw_sync_X540(struct ixgbe_hw *hw, u32 mask)
>
> swmask |= swi2c_mask;
> fwmask |= swi2c_mask << 2;
> - if (hw->mac.type == ixgbe_mac_X550)
> + if (hw->mac.type >= ixgbe_mac_X550 &&
> + hw->mac.type <= ixgbe_mac_x550em_a)
Seems like this can be squashed with this patch?
https://lore.kernel.org/intel-wired-lan/20260327073046.134085-1-aleksandr.loktionov@intel.com/
Also, since the X550 range is 3 MAC types, I think it'd be clearer to
use each MAC type rather than the range. It's only 1 more line and much
more explicit on what qualifies.
Thanks,
Tony
> timeout = 1000;
>
> for (i = 0; i < timeout; i++) {
^ permalink raw reply
* Re: [PATCH v2] mm/vmpressure: skip socket pressure for costly order reclaim
From: Jakub Kicinski @ 2026-04-03 20:49 UTC (permalink / raw)
To: JP Kobryn (Meta)
Cc: linux-mm, willy, hannes, akpm, david, ljs, Liam.Howlett, vbabka,
rppt, surenb, mhocko, kasong, qi.zheng, shakeel.butt, baohua,
axelrasmussen, yuanchu, weixugc, riel, edumazet, netdev,
linux-kernel, kernel-team
In-Reply-To: <20260402232511.17246-1-jp.kobryn@linux.dev>
On Thu, 2 Apr 2026 16:25:11 -0700 JP Kobryn (Meta) wrote:
> When kswapd reclaims at high order due to fragmentation, vmpressure() can
> report poor reclaim efficiency even though the system has plenty of free
> memory. This is because kswapd scans many pages but finds little to reclaim
> - the pages are actively in use and don't need to be freed. The resulting
> scan:reclaim ratio triggers socket pressure, throttling TCP throughput
> unnecessarily.
Acked-by: Jakub Kicinski <kuba@kernel.org>
FWIW
^ 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