* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-04-03 23:33 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, chao.gao
In-Reply-To: <CALMp9eT2vJBdLPY2uBYrPgVrhS_aYmfGfdXe6MZXG_gyryLHVA@mail.gmail.com>
On Fri, Apr 03, 2026 at 04:22:28PM -0700, Jim Mattson wrote:
> On Fri, Apr 3, 2026 at 4:16 PM Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com> wrote:
> >
> > On Fri, Apr 03, 2026 at 02:59:33PM -0700, Jim Mattson wrote:
> > > 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.
> >
> > Yes, KVM doesn't support it yet. But, adding that support to give more
> > control to userspace VMM helps this case, and probably many other in
> > the future.
>
> But didn't you tell me that Windows doesn't want the hypervisor to set
> BHI_DIS_S behind their back?
Since cloud providers have greater control over userspace, the decision to
use BHI_DIS_S or not can be left to them. KVM would simply follow what it
is asked to do by the userspace.
> > I will check with Chao if he can prepare the next version of virtual
> > SPEC_CTRL series (leaving out virtual mitigation MSRs).
>
> Excellent.
^ permalink raw reply
* [net-next v2 3/3] selftests/net: Test PACKET_AUXDATA
From: Joe Damato @ 2026-04-03 23:32 UTC (permalink / raw)
To: netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan
Cc: andrew+netdev, linux-kernel, willemb, Joe Damato, linux-kselftest
In-Reply-To: <20260403233240.178948-1-joe@dama.to>
Extend the packet socket selftest, adding a recvmsg path, to test
PACKET_AUXDATA. Check basic attributes of tpacket_auxdata.
Signed-off-by: Joe Damato <joe@dama.to>
---
tools/testing/selftests/net/psock_snd.c | 67 ++++++++++++++++++++++--
tools/testing/selftests/net/psock_snd.sh | 5 ++
2 files changed, 67 insertions(+), 5 deletions(-)
v2:
- Add is_psock bool argument to do_rx.
- Factor out aux data check into its own function for readability.
diff --git a/tools/testing/selftests/net/psock_snd.c b/tools/testing/selftests/net/psock_snd.c
index 81096df5cffc..5464317c1764 100644
--- a/tools/testing/selftests/net/psock_snd.c
+++ b/tools/testing/selftests/net/psock_snd.c
@@ -40,6 +40,7 @@ static bool cfg_use_qdisc_bypass;
static bool cfg_use_vlan;
static bool cfg_use_vnet;
static bool cfg_drop;
+static bool cfg_aux_data;
static char *cfg_ifname = "lo";
static int cfg_mtu = 1500;
@@ -279,11 +280,54 @@ static int setup_rx(void)
return fd;
}
-static void do_rx(int fd, int expected_len, char *expected)
+static void check_aux_data(struct cmsghdr *cmsg, int expected_len)
{
+ struct tpacket_auxdata *adata;
+
+ if (!cmsg)
+ error(1, 0, "auxdata null");
+
+ if (cmsg->cmsg_level != SOL_PACKET)
+ error(1, 0, "cmsg_level != SOL_PACKET");
+
+ if (cmsg->cmsg_type != PACKET_AUXDATA)
+ error(1, 0, "cmsg_type != PACKET_AUXDATA");
+
+ adata = (struct tpacket_auxdata *)CMSG_DATA(cmsg);
+
+ if (adata->tp_net != ETH_HLEN)
+ error(1, 0, "cmsg tp_net != ETH_HLEN");
+
+ if (adata->tp_len != expected_len)
+ error(1, 0, "cmsg tp_len != %u", expected_len);
+
+ if (adata->tp_snaplen != expected_len)
+ error(1, 0, "cmsg tp_snaplen != %u", expected_len);
+}
+
+static void do_rx(int fd, int expected_len, char *expected, bool is_psock)
+{
+ bool aux = is_psock && cfg_aux_data;
+ char cmsg_buf[1024] = {};
+ struct msghdr msg = {};
+ struct iovec iov[1];
int ret;
- ret = recv(fd, rbuf, sizeof(rbuf), 0);
+ if (aux) {
+ iov[0].iov_base = rbuf;
+ iov[0].iov_len = sizeof(rbuf);
+
+ msg.msg_iov = iov;
+ msg.msg_iovlen = 1;
+
+ msg.msg_control = cmsg_buf;
+ msg.msg_controllen = sizeof(cmsg_buf);
+
+ ret = recvmsg(fd, &msg, 0);
+ } else {
+ ret = recv(fd, rbuf, sizeof(rbuf), 0);
+ }
+
if (ret == -1)
error(1, errno, "recv");
if (ret != expected_len)
@@ -292,6 +336,12 @@ static void do_rx(int fd, int expected_len, char *expected)
if (memcmp(rbuf, expected, ret))
error(1, 0, "recv: data mismatch");
+ if (aux) {
+ struct cmsghdr *cmsg = CMSG_FIRSTHDR(&msg);
+
+ check_aux_data(cmsg, expected_len);
+ }
+
fprintf(stderr, "rx: %u\n", ret);
}
@@ -312,6 +362,10 @@ static int setup_sniffer(void)
if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &one, sizeof(one)))
error(1, errno, "setsockopt SO_RCVBUF");
+ if (cfg_aux_data)
+ if (setsockopt(fd, SOL_PACKET, PACKET_AUXDATA, &one, sizeof(one)))
+ error(1, errno, "setsockopt PACKET_AUXDATA");
+
pair_udp_setfilter(fd);
do_bind(fd);
@@ -322,8 +376,11 @@ static void parse_opts(int argc, char **argv)
{
int c;
- while ((c = getopt(argc, argv, "bcCdDgl:qt:vV")) != -1) {
+ while ((c = getopt(argc, argv, "abcCdDgl:qt:vV")) != -1) {
switch (c) {
+ case 'a':
+ cfg_aux_data = true;
+ break;
case 'b':
cfg_use_bind = true;
break;
@@ -432,11 +489,11 @@ static void run_test(void)
/* BPF filter accepts only this length, vlan changes MAC */
if (cfg_payload_len == DATA_LEN && !cfg_use_vlan) {
do_rx(fds, total_len - sizeof(struct virtio_net_hdr),
- tbuf + sizeof(struct virtio_net_hdr));
+ tbuf + sizeof(struct virtio_net_hdr), true);
check_packet_stats(fds);
}
- do_rx(fdr, cfg_payload_len, tbuf + total_len - cfg_payload_len);
+ do_rx(fdr, cfg_payload_len, tbuf + total_len - cfg_payload_len, false);
out:
if (close(fds))
diff --git a/tools/testing/selftests/net/psock_snd.sh b/tools/testing/selftests/net/psock_snd.sh
index b6ef12fad5d5..111c9e2f0d21 100755
--- a/tools/testing/selftests/net/psock_snd.sh
+++ b/tools/testing/selftests/net/psock_snd.sh
@@ -97,4 +97,9 @@ echo "raw gso max size + 1 (expected to fail)"
echo "test drops statistics"
./in_netns.sh ./psock_snd -D
+# test aux data
+
+echo "test aux data"
+./in_netns.sh ./psock_snd -a
+
echo "OK. All tests passed"
--
2.52.0
^ permalink raw reply related
* [net-next v2 2/3] selftests/net: Test PACKET_STATISTICS drops
From: Joe Damato @ 2026-04-03 23:32 UTC (permalink / raw)
To: netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan
Cc: andrew+netdev, linux-kernel, willemb, Joe Damato, linux-kselftest
In-Reply-To: <20260403233240.178948-1-joe@dama.to>
Extend psock_snd to test drops by setting a tiny receive buffer and
sending a large burst of packets.
Signed-off-by: Joe Damato <joe@dama.to>
---
tools/testing/selftests/net/psock_snd.c | 48 ++++++++++++++++++++----
tools/testing/selftests/net/psock_snd.sh | 5 +++
2 files changed, 46 insertions(+), 7 deletions(-)
v2:
- Remove do_tx argument and use global cfg_drop instead
diff --git a/tools/testing/selftests/net/psock_snd.c b/tools/testing/selftests/net/psock_snd.c
index 5be481a3d2bd..81096df5cffc 100644
--- a/tools/testing/selftests/net/psock_snd.c
+++ b/tools/testing/selftests/net/psock_snd.c
@@ -39,6 +39,7 @@ static bool cfg_use_gso;
static bool cfg_use_qdisc_bypass;
static bool cfg_use_vlan;
static bool cfg_use_vnet;
+static bool cfg_drop;
static char *cfg_ifname = "lo";
static int cfg_mtu = 1500;
@@ -49,6 +50,8 @@ static uint16_t cfg_port = 8000;
/* test sending up to max mtu + 1 */
#define TEST_SZ (sizeof(struct virtio_net_hdr) + ETH_HLEN + ETH_MAX_MTU + 1)
+#define BURST_CNT (1000)
+
static char tbuf[TEST_SZ], rbuf[TEST_SZ];
static unsigned long add_csum_hword(const uint16_t *start, int num_u16)
@@ -212,13 +215,14 @@ static void do_send(int fd, char *buf, int len)
if (ret != len)
error(1, 0, "write: %u %u", ret, len);
- fprintf(stderr, "tx: %u\n", ret);
+ if (!cfg_drop)
+ fprintf(stderr, "tx: %u\n", ret);
}
static int do_tx(void)
{
const int one = 1;
- int fd, len;
+ int i, fd, len;
fd = socket(PF_PACKET, cfg_use_dgram ? SOCK_DGRAM : SOCK_RAW, 0);
if (fd == -1)
@@ -242,6 +246,10 @@ static int do_tx(void)
do_send(fd, tbuf, len);
+ if (cfg_drop)
+ for (i = 0; i < BURST_CNT; i++)
+ do_send(fd, tbuf, len);
+
if (close(fd))
error(1, errno, "close t");
@@ -290,6 +298,7 @@ static void do_rx(int fd, int expected_len, char *expected)
static int setup_sniffer(void)
{
struct timeval tv = { .tv_usec = 100 * 1000 };
+ const int one = 1;
int fd;
fd = socket(PF_PACKET, SOCK_RAW, 0);
@@ -299,6 +308,10 @@ static int setup_sniffer(void)
if (setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)))
error(1, errno, "setsockopt rcv timeout");
+ if (cfg_drop)
+ if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &one, sizeof(one)))
+ error(1, errno, "setsockopt SO_RCVBUF");
+
pair_udp_setfilter(fd);
do_bind(fd);
@@ -309,7 +322,7 @@ static void parse_opts(int argc, char **argv)
{
int c;
- while ((c = getopt(argc, argv, "bcCdgl:qt:vV")) != -1) {
+ while ((c = getopt(argc, argv, "bcCdDgl:qt:vV")) != -1) {
switch (c) {
case 'b':
cfg_use_bind = true;
@@ -323,6 +336,9 @@ static void parse_opts(int argc, char **argv)
case 'd':
cfg_use_dgram = true;
break;
+ case 'D':
+ cfg_drop = true;
+ break;
case 'g':
cfg_use_gso = true;
break;
@@ -367,11 +383,23 @@ static void check_packet_stats(int fd)
if (getsockopt(fd, SOL_PACKET, PACKET_STATISTICS, &st, &len))
error(1, errno, "getsockopt packet statistics");
- if (st.tp_packets != 1)
- error(1, 0, "stats: tp_packets %u != 1", st.tp_packets);
+ if (cfg_drop) {
+ /* PACKET_STATISTICS reports all packets seen (including
+ * drops) in tp_packets
+ */
+ if (st.tp_packets < st.tp_drops)
+ error(1, 0, "stats: tp_packets %u < tp_drops %u",
+ st.tp_packets, st.tp_drops);
- if (st.tp_drops != 0)
- error(1, 0, "stats: tp_drops %u != 0", st.tp_drops);
+ if (st.tp_drops == 0)
+ error(1, 0, "stats: expected drops but tp_drops == 0");
+ } else {
+ if (st.tp_packets != 1)
+ error(1, 0, "stats: tp_packets %u != 1", st.tp_packets);
+
+ if (st.tp_drops != 0)
+ error(1, 0, "stats: tp_drops %u != 0", st.tp_drops);
+ }
/* verify clear on read */
memset(&st, 0xff, sizeof(st));
@@ -396,6 +424,11 @@ static void run_test(void)
total_len = do_tx();
+ if (cfg_drop) {
+ check_packet_stats(fds);
+ goto out;
+ }
+
/* BPF filter accepts only this length, vlan changes MAC */
if (cfg_payload_len == DATA_LEN && !cfg_use_vlan) {
do_rx(fds, total_len - sizeof(struct virtio_net_hdr),
@@ -405,6 +438,7 @@ static void run_test(void)
do_rx(fdr, cfg_payload_len, tbuf + total_len - cfg_payload_len);
+out:
if (close(fds))
error(1, errno, "close s");
if (close(fdr))
diff --git a/tools/testing/selftests/net/psock_snd.sh b/tools/testing/selftests/net/psock_snd.sh
index 1cbfeb5052ec..b6ef12fad5d5 100755
--- a/tools/testing/selftests/net/psock_snd.sh
+++ b/tools/testing/selftests/net/psock_snd.sh
@@ -92,4 +92,9 @@ echo "raw gso max size"
echo "raw gso max size + 1 (expected to fail)"
(! ./in_netns.sh ./psock_snd -v -c -g -l "${max_mss_exceeds}")
+# test drops statistics
+
+echo "test drops statistics"
+./in_netns.sh ./psock_snd -D
+
echo "OK. All tests passed"
--
2.52.0
^ permalink raw reply related
* [net-next v2 1/3] selftests/net: Test PACKET_STATISTICS
From: Joe Damato @ 2026-04-03 23:32 UTC (permalink / raw)
To: netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan
Cc: andrew+netdev, linux-kernel, willemb, Joe Damato, linux-kselftest
In-Reply-To: <20260403233240.178948-1-joe@dama.to>
Update the existing packet socket test to include a test for the sockopt
PACKET_STATISTICS.
Signed-off-by: Joe Damato <joe@dama.to>
---
tools/testing/selftests/net/psock_snd.c | 32 ++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/psock_snd.c b/tools/testing/selftests/net/psock_snd.c
index edf1e6f80d41..5be481a3d2bd 100644
--- a/tools/testing/selftests/net/psock_snd.c
+++ b/tools/testing/selftests/net/psock_snd.c
@@ -359,6 +359,34 @@ static void parse_opts(int argc, char **argv)
error(1, 0, "option gso (-g) requires csum offload (-c)");
}
+static void check_packet_stats(int fd)
+{
+ struct tpacket_stats st = {};
+ socklen_t len = sizeof(st);
+
+ if (getsockopt(fd, SOL_PACKET, PACKET_STATISTICS, &st, &len))
+ error(1, errno, "getsockopt packet statistics");
+
+ if (st.tp_packets != 1)
+ error(1, 0, "stats: tp_packets %u != 1", st.tp_packets);
+
+ if (st.tp_drops != 0)
+ error(1, 0, "stats: tp_drops %u != 0", st.tp_drops);
+
+ /* verify clear on read */
+ memset(&st, 0xff, sizeof(st));
+ len = sizeof(st);
+
+ if (getsockopt(fd, SOL_PACKET, PACKET_STATISTICS, &st, &len))
+ error(1, errno, "getsockopt packet statistics");
+
+ if (st.tp_packets != 0)
+ error(1, 0, "stats: tp_packets %u != 0 after clear", st.tp_packets);
+
+ if (st.tp_drops != 0)
+ error(1, 0, "stats: tp_drops %u != 0 after clear", st.tp_drops);
+}
+
static void run_test(void)
{
int fdr, fds, total_len;
@@ -369,9 +397,11 @@ static void run_test(void)
total_len = do_tx();
/* BPF filter accepts only this length, vlan changes MAC */
- if (cfg_payload_len == DATA_LEN && !cfg_use_vlan)
+ if (cfg_payload_len == DATA_LEN && !cfg_use_vlan) {
do_rx(fds, total_len - sizeof(struct virtio_net_hdr),
tbuf + sizeof(struct virtio_net_hdr));
+ check_packet_stats(fds);
+ }
do_rx(fdr, cfg_payload_len, tbuf + total_len - cfg_payload_len);
--
2.52.0
^ permalink raw reply related
* [net-next 0/3] Extend packet socket selftests
From: Joe Damato @ 2026-04-03 23:32 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, linux-kernel,
willemb, Joe Damato
Greetings:
I was looking around the packet socket code and noticed there were a few
features that could be tested by extending the existing packet socket
tests.
I extended the test to test stats, drops, and auxdata and re-ran the tests.
The existing and new tests passed.
Thanks,
Joe
v2:
- patch 2: remove argument from do_tx and use global instead
- patch 3: add argument to do_rx to specify if the socket is a packet
socket. factored out the aux data check into its own function for
readability.
Joe Damato (3):
selftests/net: Test PACKET_STATISTICS
selftests/net: Test PACKET_STATISTICS drops
selftests/net: Test PACKET_AUXDATA
tools/testing/selftests/net/psock_snd.c | 137 +++++++++++++++++++++--
tools/testing/selftests/net/psock_snd.sh | 10 ++
2 files changed, 139 insertions(+), 8 deletions(-)
base-commit: 8b0e64d6c9e7feec5ba5643b4fa8b7fd54464778
--
2.52.0
^ permalink raw reply
* Re: [net-next,v17,08/14] net: homa: create homa_rpc.h and homa_rpc.c
From: John Ousterhout @ 2026-04-03 23:04 UTC (permalink / raw)
To: Paolo Abeni; +Cc: horms, netdev, kuba, edumazet
In-Reply-To: <6fb603dd-7bc2-4b60-bf93-7247d05f3250@redhat.com>
On Tue, Mar 24, 2026 at 1:55 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> >> [ ... ]
> >> Paolo also suggested using deferred SKB freeing (skb_attempt_defer_free) to
> >> reduce the cost. While you mentioned that GRO is implemented in the full
> >> Homa but was left out of the initial patch series, would it be beneficial to
> >> include at least some of these optimizations in this initial submission?
> >>
> >> Reference: https://lore.kernel.org/netdev/9209dfbb-ca3a-4fb7-a2fb-0567394f8cda@redhat.com/
> >
> > When I asked ChatGPT about homa_attempt_defer_free it said that it
> > only works if the skb has no dst, no destructor, and no skb_nfct. I'm
> > a bit unsure how to proceed. Is homa_attempt_defer_free only intended
> > for incoming packets? If so, then presumably there is no dst? But what
> > about the other fields? Do I need to do something to clean them up
> > before calling homa_attempt_defer_free?
> skb_attempt_defer_free() usage is intended for the RX path only.
>
> Incoming packets get state (dst, extensions, ct...) attached in the rx
> path before reaching the socket. You should free/release the state, if
> possible, before inserting the skb into the receive queue, so that you
> could defer free them after read.
I have modified Homa to use skb_attempt_defer_free, and this made a
significant difference in the throughput of the critical path copying
data from skbs to user space. Thanks for the suggestion.
However, skb_attempt_defer_free is not currently exported, so the
patch series will now include an EXPORT_SYMBOL line for that in
skbuff.c; hopefully that will be OK...
-John-
^ permalink raw reply
* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Jim Mattson @ 2026-04-03 23:22 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, chao.gao
In-Reply-To: <20260403231608.zopnhnypdclzqlx7@desk>
On Fri, Apr 3, 2026 at 4:16 PM Pawan Gupta
<pawan.kumar.gupta@linux.intel.com> wrote:
>
> On Fri, Apr 03, 2026 at 02:59:33PM -0700, Jim Mattson wrote:
> > 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.
>
> Yes, KVM doesn't support it yet. But, adding that support to give more
> control to userspace VMM helps this case, and probably many other in
> the future.
But didn't you tell me that Windows doesn't want the hypervisor to set
BHI_DIS_S behind their back?
> I will check with Chao if he can prepare the next version of virtual
> SPEC_CTRL series (leaving out virtual mitigation MSRs).
Excellent.
^ permalink raw reply
* Re: [net-next] net: ethernet: ravb: Suspend and resume the transmission flow
From: patchwork-bot+netdevbpf @ 2026-04-03 23:20 UTC (permalink / raw)
To: =?utf-8?q?Niklas_S=C3=B6derlund_=3Cniklas=2Esoderlund+renesas=40ragnatech=2E?=,
=?utf-8?q?se=3E?=
Cc: paul, andrew+netdev, davem, edumazet, kuba, pabeni, netdev,
linux-renesas-soc, yoshihiro.shimoda.uh
In-Reply-To: <20260401183608.1852225-1-niklas.soderlund+renesas@ragnatech.se>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 1 Apr 2026 20:36:08 +0200 you wrote:
> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> The current driver does not follow the latest datasheet and does not
> suspend the flow when stopping DMA and resume it when starting. Update
> the driver to do so.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> [Niklas: Rebase from BSP and reword commit message]
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
> [...]
Here is the summary with links:
- [net-next] net: ethernet: ravb: Suspend and resume the transmission flow
https://git.kernel.org/netdev/net-next/c/353d8e7989b6
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 2/3] net: lan966x: fix page pool and resources leak in error paths
From: Jakub Kicinski @ 2026-04-03 23:18 UTC (permalink / raw)
To: David Carlier
Cc: horatiu.vultur, UNGLinuxDriver, andrew+netdev, davem, edumazet,
pabeni, netdev, linux-kernel, stable
In-Reply-To: <20260403230714.10667-2-devnexen@gmail.com>
On Sat, 4 Apr 2026 00:07:13 +0100 David Carlier wrote:
> lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if
> the subsequent fdma_alloc_coherent() call fails, leaking the pool and
> leaving a dangling pointer in rx->page_pool.
>
> Similarly, lan966x_fdma_init() frees the coherent DMA memory when
> lan966x_fdma_tx_alloc() fails but does not destroy the page pool that
> was successfully created by lan966x_fdma_rx_alloc(), leaking it.
>
> Add the missing page_pool_destroy() calls in both error paths and
> NULL-out rx->page_pool after destruction to avoid a dangling pointer.
Okay...
> Fixes: 11871aba1974 ("net: lan96x: Use page_pool API")
> Cc: stable@vger.kernel.org
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
> drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> index 34bbcae2f068..b985ce64bb50 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> @@ -120,8 +120,11 @@ static int lan966x_fdma_rx_alloc(struct lan966x_rx *rx)
> return PTR_ERR(rx->page_pool);
>
> err = fdma_alloc_coherent(lan966x->dev, fdma);
> - if (err)
> + if (err) {
> + page_pool_destroy(rx->page_pool);
> + rx->page_pool = NULL;
> return err;
> + }
>
> fdma_dcbs_init(fdma, FDMA_DCB_INFO_DATAL(fdma->db_size),
> FDMA_DCB_STATUS_INTR);
> @@ -958,6 +961,7 @@ int lan966x_fdma_init(struct lan966x *lan966x)
> err = lan966x_fdma_tx_alloc(&lan966x->tx);
> if (err) {
> fdma_free_coherent(lan966x->dev, &lan966x->rx.fdma);
> + page_pool_destroy(lan966x->rx.page_pool);
but here the "dangling pointer" is fine?
I don't care either way but be consistent.
> return err;
> }
>
^ permalink raw reply
* Re: [PATCH v2 1/3] net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool()
From: Jakub Kicinski @ 2026-04-03 23:17 UTC (permalink / raw)
To: David Carlier
Cc: horatiu.vultur, UNGLinuxDriver, andrew+netdev, davem, edumazet,
pabeni, netdev, linux-kernel, stable
In-Reply-To: <20260403230714.10667-1-devnexen@gmail.com>
On Sat, 4 Apr 2026 00:07:12 +0100 David Carlier wrote:
> page_pool_create() can return an ERR_PTR on failure. The return value
> is used unconditionally in the loop that follows, passing the error
> pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(),
> which dereferences it, causing a kernel oops.
>
> Add an IS_ERR check after page_pool_create() to return early on failure.
Wow, that was fast, are you generating this patches with AI?
You've written and tested this code in 40min?
Please with at least 24h before sending v3, per:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html
You're missing a cover letter, if there's more than 2 patches the
series must have a cover letter.
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> index 7b6369e43451..34bbcae2f068 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
> @@ -92,6 +92,9 @@ static int lan966x_fdma_rx_alloc_page_pool(struct lan966x_rx *rx)
>
> rx->page_pool = page_pool_create(&pp_params);
>
no empty lines between call and its error check, fix this in all
checks you're adding
> + if (unlikely(IS_ERR(rx->page_pool)))
> + return PTR_ERR(rx->page_pool);
> +
> for (int i = 0; i < lan966x->num_phys_ports; ++i) {
> struct lan966x_port *port;
>
^ permalink raw reply
* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-04-03 23:16 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, chao.gao
In-Reply-To: <CALMp9eSXfJvR=PHtttbqm3q3nH436T1eH4YdpVqxQeP-cxEPsA@mail.gmail.com>
On Fri, Apr 03, 2026 at 02:59:33PM -0700, Jim Mattson wrote:
> 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.
Yes, KVM doesn't support it yet. But, adding that support to give more
control to userspace VMM helps this case, and probably many other in
the future.
I will check with Chao if he can prepare the next version of virtual
SPEC_CTRL series (leaving out virtual mitigation MSRs).
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: qcom-ethqos: set clk_csr
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Russell King
Cc: andrew, alexandre.torgue, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-arm-msm, linux-stm32, mohd.anwar, netdev,
pabeni
In-Reply-To: <E1w8JKr-0000000EdLC-41Bt@rmk-PC.armlinux.org.uk>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 02 Apr 2026 15:47:53 +0100 you wrote:
> The clocks for qcom-ethqos return a rate of zero as firmware manages
> their rate. According to hardware documentation, the clock which is
> fed to the slave AHB interface can range between 50 to 100MHz for
> non-RGMII and 30 to 75MHz for boards with a RGMII interfaces.
>
> Currently, stmmac uses an undefined divisor value. Instead, use
> STMMAC_CSR_60_100M which will mean we meet IEEE 802.3 specification
> since this will generate:
>
> [...]
Here is the summary with links:
- [net-next] net: stmmac: qcom-ethqos: set clk_csr
https://git.kernel.org/netdev/net-next/c/789ec16eb397
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2] ppp: update Kconfig help message
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Qingfang Deng
Cc: linux-ppp, andrew+netdev, davem, edumazet, kuba, pabeni,
julianbraha, ebiggers, netdev, linux-kernel, paulus, dianne, jaco,
carlsonj
In-Reply-To: <20260402050053.144250-1-qingfang.deng@linux.dev>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 13:00:50 +0800 you wrote:
> Both links of the PPPoE section are no longer valid, and the CVS version
> is no longer relevant.
>
> - Replace the TLDP URL with the pppd project homepage.
> - Update pppd version requirement for PPPoE.
> - Update RP-PPPoE project homepage, and clarify that it's only needed
> for server mode.
>
> [...]
Here is the summary with links:
- [net-next,v2] ppp: update Kconfig help message
https://git.kernel.org/netdev/net-next/c/779fae61a3c8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: macb: Remove dedicated IRQ handler for WoL
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Kevin Hao
Cc: nicolas.ferre, claudiu.beznea, andrew+netdev, davem, edumazet,
kuba, pabeni, netdev, nb
In-Reply-To: <20260402-macb-irq-v2-0-942d98ab1154@gmail.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 02 Apr 2026 21:41:21 +0800 you wrote:
> During debugging of a suspend/resume issue, I observed that the macb driver
> employs a dedicated IRQ handler for Wake-on-LAN (WoL) support. To my knowledge,
> no other Ethernet driver adopts this approach. This implementation unnecessarily
> complicates the suspend/resume process without providing any clear benefit.
> Instead, we can easily modify the existing IRQ handler to manage WoL events,
> avoiding any overhead in the TX/RX hot path.
>
> [...]
Here is the summary with links:
- [net-next,v2,1/4] net: macb: Replace open-coded implementation with napi_schedule()
https://git.kernel.org/netdev/net-next/c/dc3bd465ea36
- [net-next,v2,2/4] net: macb: Introduce macb_queue_isr_clear() helper function
https://git.kernel.org/netdev/net-next/c/5986ff6e4136
- [net-next,v2,3/4] net: macb: Factor out the handling of non-hot IRQ events into a separate function
https://git.kernel.org/netdev/net-next/c/6d55ce805b26
- [net-next,v2,4/4] net: macb: Remove dedicated IRQ handler for WoL
https://git.kernel.org/netdev/net-next/c/6637c03f35fa
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: always inline some skb helpers
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, kuniyu, netdev, eric.dumazet
In-Reply-To: <20260402152654.1720627-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 15:26:54 +0000 you wrote:
> Some performance critical helpers from include/linux/skbuff.h
> are not inlined by clang.
>
> Use __always_inline hint for:
>
> - __skb_fill_netmem_desc()
> - __skb_fill_page_desc()
> - skb_fill_netmem_desc()
> - skb_fill_page_desc()
> - __skb_pull()
> - pskb_may_pull_reason()
> - pskb_may_pull()
> - pskb_pull()
> - pskb_trim()
> - skb_orphan()
> - skb_postpull_rcsum()
> - skb_header_pointer()
> - skb_clear_delivery_time()
> - skb_tstamp_cond()
> - skb_warn_if_lro()
>
> [...]
Here is the summary with links:
- [net-next] net: always inline some skb helpers
https://git.kernel.org/netdev/net-next/c/a9b460225e47
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] inet: remove leftover EXPORT_SYMBOL()
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, kuniyu, netdev, eric.dumazet
In-Reply-To: <20260402174430.2462800-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 17:44:30 +0000 you wrote:
> IPv6 is no longer a module, we no longer need to export these symbols.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv4/icmp.c | 4 ----
> net/ipv4/ipmr_base.c | 13 -------------
> net/ipv4/udp_offload.c | 4 ----
> 3 files changed, 21 deletions(-)
Here is the summary with links:
- [net-next] inet: remove leftover EXPORT_SYMBOL()
https://git.kernel.org/netdev/net-next/c/1666d945b57b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2 0/8] selftests: drv-net: gro: more test cases
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
willemb, petrm, anubhavsinggh, richardbgobert, linux-kselftest
In-Reply-To: <20260402210000.1512696-1-kuba@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 13:59:52 -0700 you wrote:
> Add a few more test cases for GRO.
>
> First 4 patches are unchanged from v1.
>
> Patches 5 and 6 are new. Willem pointed out that the defines are
> duplicated and all these imprecise defines have been annoying me
> for a while so I decided to clean them up.
>
> [...]
Here is the summary with links:
- [net-next,v2,1/8] selftests: drv-net: gro: add data burst test case
https://git.kernel.org/netdev/net-next/c/30f831b44a98
- [net-next,v2,2/8] selftests: drv-net: gro: add 1 byte payload test
https://git.kernel.org/netdev/net-next/c/436ea8a1b7ed
- [net-next,v2,3/8] selftests: drv-net: gro: always wait for FIN in the capacity test
https://git.kernel.org/netdev/net-next/c/d97348474708
- [net-next,v2,4/8] selftests: drv-net: gro: prepare for ip6ip6 support
https://git.kernel.org/netdev/net-next/c/5469b695f236
- [net-next,v2,5/8] selftests: drv-net: gro: remove TOTAL_HDR_LEN
https://git.kernel.org/netdev/net-next/c/166b0cc6df8c
- [net-next,v2,6/8] selftests: drv-net: gro: make large packet math more precise
https://git.kernel.org/netdev/net-next/c/024597cc2077
- [net-next,v2,7/8] selftests: drv-net: gro: test ip6ip6
https://git.kernel.org/netdev/net-next/c/9a84a4047df7
- [net-next,v2,8/8] selftests: drv-net: gro: add a test for bad IPv4 csum
https://git.kernel.org/netdev/net-next/c/764d0833e795
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] stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Julian Braha
Cc: davem, peppe.cavallaro, alexandre.torgue, mcoquelin.stm32, linux,
kuba, netdev, linux-arm-kernel, linux-kernel, rmk+kernel
In-Reply-To: <20260402145858.240231-1-julianbraha@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 15:58:58 +0100 you wrote:
> There are already 'if STMMAC_ETH' and 'STMMAC_PLATFORM'
> conditions wrapping these config options, making the
> 'depends on' statements duplicate dependencies (dead code).
>
> I propose leaving the outer 'if STMMAC_PLATFORM...endif' and
> 'if STMMAC_ETH...endif' conditions, and removing the
> individual 'depends on' statements.
>
> [...]
Here is the summary with links:
- [v2] stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig
https://git.kernel.org/netdev/net-next/c/e2f152c822cf
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] ipv4: icmp: fix null-ptr-deref in icmp_build_probe()
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Yiqi Sun; +Cc: davem, dsahern, edumazet, kuba, pabeni, horms, netdev
In-Reply-To: <20260402070419.2291578-1-sunyiqixm@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 15:04:19 +0800 you wrote:
> ipv6_stub->ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the
> IPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing
> this error pointer to dev_hold() will cause a kernel crash with
> null-ptr-deref.
>
> Instead, silently discard the request. RFC 8335 does not appear to
> define a specific response for the case where an IPv6 interface
> identifier is syntactically valid but the implementation cannot perform
> the lookup at runtime, and silently dropping the request may safer than
> misreporting "No Such Interface".
>
> [...]
Here is the summary with links:
- [net] ipv4: icmp: fix null-ptr-deref in icmp_build_probe()
https://git.kernel.org/netdev/net/c/fde29fd93493
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 V4 0/3] net: stmmac: Fix Tegra234 MGBE clock
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Jon Hunter
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, thierry.reding, netdev, devicetree, linux-tegra
In-Reply-To: <20260401102941.17466-1-jonathanh@nvidia.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 1 Apr 2026 11:29:38 +0100 you wrote:
> The name of the PTP ref clock for the Tegra234 MGBE ethernet controller
> does not match the generic name in the stmmac platform driver. Despite
> this basic ethernet is functional on the Tegra234 platforms that use
> this driver and as far as I know, we have not tested PTP support with
> this driver. Hence, the risk of breaking any functionality is low.
>
> The previous attempt to fix this in the stmmac platform driver, by
> supporting the Tegra234 PTP clock name, was rejected [0]. The preference
> from the netdev maintainers is to fix this in the DT binding for
> Tegra234.
>
> [...]
Here is the summary with links:
- [V4,1/3] net: stmmac: Fix PTP ref clock for Tegra234
https://git.kernel.org/netdev/net/c/1345e9f4e3f3
- [V4,2/3] dt-bindings: net: Fix Tegra234 MGBE PTP clock
https://git.kernel.org/netdev/net/c/fb22b1fc5bca
- [V4,3/3] arm64: tegra: Fix Tegra234 MGBE PTP clock
(no matching commit)
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: increase IP_TUNNEL_RECURSION_LIMIT to 5
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Chris J Arges
Cc: pabeni, bestswngs, kernel-team, davem, dsahern, edumazet, kuba,
horms, netdev, linux-kernel
In-Reply-To: <20260402222401.3408368-1-carges@cloudflare.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 17:23:16 -0500 you wrote:
> In configurations with multiple tunnel layers and MPLS lwtunnel routing, a
> single tunnel hop can increment the counter beyond this limit. This causes
> packets to be dropped with the "Dead loop on virtual device" message even
> when a routing loop doesn't exist.
>
> Increase IP_TUNNEL_RECURSION_LIMIT from 4 to 5 to handle this use-case.
>
> [...]
Here is the summary with links:
- net: increase IP_TUNNEL_RECURSION_LIMIT to 5
https://git.kernel.org/netdev/net/c/77facb35227c
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] nfc: s3fwrn5: allocate rx skb before consuming bytes
From: patchwork-bot+netdevbpf @ 2026-04-03 23:10 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: krzk, bongsu.jeon, netdev, linux-kernel, stable
In-Reply-To: <20260402042148.65236-1-pengpeng@iscas.ac.cn>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 12:21:48 +0800 you wrote:
> s3fwrn82_uart_read() reports the number of accepted bytes to the serdev
> core. The current code consumes bytes into recv_skb and may already
> deliver a complete frame before allocating a fresh receive buffer.
>
> If that alloc_skb() fails, the callback returns 0 even though it has
> already consumed bytes, and it leaves recv_skb as NULL for the next
> receive callback. That breaks the receive_buf() accounting contract and
> can also lead to a NULL dereference on the next skb_put_u8().
>
> [...]
Here is the summary with links:
- nfc: s3fwrn5: allocate rx skb before consuming bytes
https://git.kernel.org/netdev/net/c/5c14a19d5b16
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v2 3/3] net: lan966x: fix use-after-free and leak in lan966x_fdma_reload()
From: David Carlier @ 2026-04-03 23:07 UTC (permalink / raw)
To: horatiu.vultur, UNGLinuxDriver, andrew+netdev, davem, edumazet,
kuba, pabeni, netdev, linux-kernel
Cc: stable, David Carlier
In-Reply-To: <20260403230714.10667-1-devnexen@gmail.com>
When lan966x_fdma_reload() fails to allocate new RX buffers, the restore
path restarts DMA using old descriptors whose pages were already freed
via lan966x_fdma_rx_free_pages(). Since page_pool_put_full_page() can
release pages back to the buddy allocator, the hardware may DMA into
memory now owned by other kernel subsystems.
Additionally, on the restore path, the newly created page pool (if
allocation partially succeeded) is overwritten without being destroyed,
leaking it.
Fix both issues by deferring the release of old pages until after the
new allocation succeeds. Save the old page array before the allocation
so old pages can be freed on the success path. On the failure path, the
old descriptors, pages and page pool are all still valid, making the
restore safe. Also ensure the restore path re-enables NAPI and wakes
the netdev, matching the success path.
Fixes: 89ba464fcf54 ("net: lan966x: refactor buffer reload function")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
---
.../ethernet/microchip/lan966x/lan966x_fdma.c | 22 ++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
index b985ce64bb50..fd6718a23676 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
@@ -814,9 +814,16 @@ static int lan966x_qsys_sw_status(struct lan966x *lan966x)
static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
{
+ struct page *(*old_pages)[FDMA_RX_DCB_MAX_DBS];
struct page_pool *page_pool;
struct fdma fdma_rx_old;
- int err;
+ int err, i, j;
+
+ old_pages = kmemdup(lan966x->rx.page, sizeof(lan966x->rx.page),
+ GFP_KERNEL);
+
+ if (!old_pages)
+ return -ENOMEM;
/* Store these for later to free them */
memcpy(&fdma_rx_old, &lan966x->rx.fdma, sizeof(struct fdma));
@@ -827,7 +834,6 @@ static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
lan966x_fdma_stop_netdev(lan966x);
lan966x_fdma_rx_disable(&lan966x->rx);
- lan966x_fdma_rx_free_pages(&lan966x->rx);
lan966x->rx.page_order = round_up(new_mtu, PAGE_SIZE) / PAGE_SIZE - 1;
lan966x->rx.max_mtu = new_mtu;
err = lan966x_fdma_rx_alloc(&lan966x->rx);
@@ -835,6 +841,11 @@ static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
goto restore;
lan966x_fdma_rx_start(&lan966x->rx);
+ for (i = 0; i < fdma_rx_old.n_dcbs; ++i)
+ for (j = 0; j < fdma_rx_old.n_dbs; ++j)
+ page_pool_put_full_page(page_pool,
+ old_pages[i][j], false);
+
fdma_free_coherent(lan966x->dev, &fdma_rx_old);
page_pool_destroy(page_pool);
@@ -842,12 +853,17 @@ static int lan966x_fdma_reload(struct lan966x *lan966x, int new_mtu)
lan966x_fdma_wakeup_netdev(lan966x);
napi_enable(&lan966x->napi);
- return err;
+ kfree(old_pages);
+ return 0;
restore:
lan966x->rx.page_pool = page_pool;
memcpy(&lan966x->rx.fdma, &fdma_rx_old, sizeof(struct fdma));
lan966x_fdma_rx_start(&lan966x->rx);
+ lan966x_fdma_wakeup_netdev(lan966x);
+ napi_enable(&lan966x->napi);
+
+ kfree(old_pages);
return err;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/3] net: lan966x: fix page pool and resources leak in error paths
From: David Carlier @ 2026-04-03 23:07 UTC (permalink / raw)
To: horatiu.vultur, UNGLinuxDriver, andrew+netdev, davem, edumazet,
kuba, pabeni, netdev, linux-kernel
Cc: stable, David Carlier
In-Reply-To: <20260403230714.10667-1-devnexen@gmail.com>
lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if
the subsequent fdma_alloc_coherent() call fails, leaking the pool and
leaving a dangling pointer in rx->page_pool.
Similarly, lan966x_fdma_init() frees the coherent DMA memory when
lan966x_fdma_tx_alloc() fails but does not destroy the page pool that
was successfully created by lan966x_fdma_rx_alloc(), leaking it.
Add the missing page_pool_destroy() calls in both error paths and
NULL-out rx->page_pool after destruction to avoid a dangling pointer.
Fixes: 11871aba1974 ("net: lan96x: Use page_pool API")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
---
drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
index 34bbcae2f068..b985ce64bb50 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
@@ -120,8 +120,11 @@ static int lan966x_fdma_rx_alloc(struct lan966x_rx *rx)
return PTR_ERR(rx->page_pool);
err = fdma_alloc_coherent(lan966x->dev, fdma);
- if (err)
+ if (err) {
+ page_pool_destroy(rx->page_pool);
+ rx->page_pool = NULL;
return err;
+ }
fdma_dcbs_init(fdma, FDMA_DCB_INFO_DATAL(fdma->db_size),
FDMA_DCB_STATUS_INTR);
@@ -958,6 +961,7 @@ int lan966x_fdma_init(struct lan966x *lan966x)
err = lan966x_fdma_tx_alloc(&lan966x->tx);
if (err) {
fdma_free_coherent(lan966x->dev, &lan966x->rx.fdma);
+ page_pool_destroy(lan966x->rx.page_pool);
return err;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/3] net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool()
From: David Carlier @ 2026-04-03 23:07 UTC (permalink / raw)
To: horatiu.vultur, UNGLinuxDriver, andrew+netdev, davem, edumazet,
kuba, pabeni, netdev, linux-kernel
Cc: stable, David Carlier
page_pool_create() can return an ERR_PTR on failure. The return value
is used unconditionally in the loop that follows, passing the error
pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(),
which dereferences it, causing a kernel oops.
Add an IS_ERR check after page_pool_create() to return early on failure.
Fixes: 11871aba1974 ("net: lan96x: Use page_pool API")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
---
drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
index 7b6369e43451..34bbcae2f068 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
@@ -92,6 +92,9 @@ static int lan966x_fdma_rx_alloc_page_pool(struct lan966x_rx *rx)
rx->page_pool = page_pool_create(&pp_params);
+ if (unlikely(IS_ERR(rx->page_pool)))
+ return PTR_ERR(rx->page_pool);
+
for (int i = 0; i < lan966x->num_phys_ports; ++i) {
struct lan966x_port *port;
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox