* Re: [PATCH net-next] selftests: net: py: color the basics in the output
From: Jakub Kicinski @ 2026-04-01 23:58 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
petrm, willemb, linux-kselftest
In-Reply-To: <ac2OJvW8ZfzDFtHr@mini-arch>
On Wed, 1 Apr 2026 14:29:10 -0700 Stanislav Fomichev wrote:
> (not sure why you think this might be controversial)
I'd like the "libraries" to be minimal, so any increase in LoC has to
strongly justify itself. Whenever I work on something in ksft I tend
to produce a bunch of "improvements" of this sort but usually lose
confidence and don't send them out. The coloring thing has been
annoying me for a while but mostly in NIPA context (on the web).
^ permalink raw reply
* Re: [PATCH net-next] selftests: net: py: color the basics in the output
From: Joe Damato @ 2026-04-02 0:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
petrm, willemb, linux-kselftest
In-Reply-To: <20260401183309.378671-1-kuba@kernel.org>
On Wed, Apr 01, 2026 at 11:33:09AM -0700, Jakub Kicinski wrote:
> Sometimes it's hard to spot the ok / not ok lines in the output.
> This is especially true for the GRO tests which retries a lot
> so there's a wall of non-fatal output printed.
>
> Try to color the crucial lines green / red / yellow when running
> in a terminal.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> This is a bit of RFC, I'm not super convinced this is worth
> carrying in the tree? Please Ack/Review I'll apply if we get
> 3 supporting tags.
> ---
> CC: shuah@kernel.org
> CC: petrm@nvidia.com
> CC: willemb@google.com
> CC: linux-kselftest@vger.kernel.org
> ---
> tools/testing/selftests/net/lib/py/ksft.py | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
Colorized output is nice.
Acked-by: Joe Damato <joe@dama.to>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next] ice: check cross-timestamp timeout bits
From: Jacob Keller @ 2026-04-02 0:01 UTC (permalink / raw)
To: Aleksandr Loktionov, intel-wired-lan, anthony.l.nguyen; +Cc: netdev
In-Reply-To: <20260327072236.129802-3-aleksandr.loktionov@intel.com>
On 3/27/2026 12:22 AM, Aleksandr Loktionov wrote:
> From: Karol Kolacinski <karol.kolacinski@intel.com>
>
> Polling for cross-timestamp active bit depends on HW scheduling and
> actual timeout may happen before the driver finishes polling.
>
> Check cross-timestamp timeout bits to ensure that the driver finishes
> the operation earlier when HW indicates timeout.
>
> Fixes: 92456e795ac6 ("ice: Add unified ice_capture_crosststamp")
> Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
>
Waste less time once hardware gives up. Makes sense.
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
^ permalink raw reply
* Re: [PATCH net-next] selftests: net: py: color the basics in the output
From: Willem de Bruijn @ 2026-04-02 0:03 UTC (permalink / raw)
To: Stanislav Fomichev, Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
petrm, willemb, linux-kselftest
In-Reply-To: <ac2OJvW8ZfzDFtHr@mini-arch>
Stanislav Fomichev wrote:
> On 04/01, Jakub Kicinski wrote:
> > Sometimes it's hard to spot the ok / not ok lines in the output.
> > This is especially true for the GRO tests which retries a lot
> > so there's a wall of non-fatal output printed.
> >
> > Try to color the crucial lines green / red / yellow when running
> > in a terminal.
> >
> > Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> > ---
> > This is a bit of RFC, I'm not super convinced this is worth
> > carrying in the tree? Please Ack/Review I'll apply if we get
> > 3 supporting tags.
>
> Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Minor aside: I don't know exactly how to exhaustively test whether a
terminal supports colors. If unsure, an inverse approach to err on the
side of caution may be safer. But overall +1 on the intent.
^ permalink raw reply
* Re: [PATCH 2/4] net: ionic: Add PHC state page for user space access
From: Jakub Kicinski @ 2026-04-02 0:06 UTC (permalink / raw)
To: Abhijit Gangurde
Cc: jgg, leon, brett.creeley, andrew+netdev, davem, edumazet, pabeni,
allen.hubbe, nikhil.agarwal, linux-rdma, netdev, linux-kernel
In-Reply-To: <20260401102501.3395305-3-abhijit.gangurde@amd.com>
On Wed, 1 Apr 2026 15:54:59 +0530 Abhijit Gangurde wrote:
> diff --git a/include/uapi/rdma/ionic-abi.h b/include/uapi/rdma/ionic-abi.h
> index 7b589d3e9728..97f695510380 100644
> --- a/include/uapi/rdma/ionic-abi.h
> +++ b/include/uapi/rdma/ionic-abi.h
> @@ -112,4 +112,15 @@ struct ionic_srq_resp {
> __aligned_u64 rq_cmb_offset;
> };
>
> +struct ionic_phc_state {
> + __u32 seq;
> + __u32 rsvd;
> + __aligned_u64 mask;
> + __aligned_u64 tick;
> + __aligned_u64 nsec;
> + __aligned_u64 frac;
> + __u32 mult;
> + __u32 shift;
> +};
You're just exposing kernel timecounter internals.
Why is this ionic uAPI and not something reusable by other drivers?
^ permalink raw reply
* Re: [PATCH v2 0/4] ice: use better bitmap API
From: Yury Norov @ 2026-04-02 0:08 UTC (permalink / raw)
To: Tony Nguyen, David S. Miller, Thomas Hellström, Andrew Lunn,
Andrew Morton, David Airlie, Eric Dumazet, Jakub Kicinski,
Matthew Brost, Paolo Abeni, Przemek Kitszel, Rodrigo Vivi,
Simona Vetter, Yury Norov, Rasmus Villemoes, dri-devel, intel-xe,
linux-kernel, netdev, intel-wired-lan
Cc: Simon Horman, David Laight
In-Reply-To: <20260302011159.61778-1-ynorov@nvidia.com>
On Sun, Mar 01, 2026 at 08:11:54PM -0500, Yury Norov wrote:
> Use better bitmap API where appropriate. Patches #3,4 may be applied
> separately.
Added in bitmap-for-next for testing. Thanks!
> v1: https://lore.kernel.org/all/20251223162303.434659-1-yury.norov@gmail.com/
> v2:
> - new v2#4;
> - add documentation line (Simon);
>
> Yury Norov (4):
> bitmap: introduce bitmap_weighted_xor()
> ice: use bitmap_weighted_xor() in ice_find_free_recp_res_idx()
> ice: use bitmap_empty() in ice_vf_has_no_qs_ena
> drm/xe: switch xe_pagefault_queue_init() to using bitmap_weighted_or()
>
> drivers/gpu/drm/xe/xe_pagefault.c | 3 +--
> drivers/net/ethernet/intel/ice/ice_switch.c | 4 +---
> drivers/net/ethernet/intel/ice/ice_vf_lib.c | 4 ++--
> include/linux/bitmap.h | 15 +++++++++++++++
> lib/bitmap.c | 7 +++++++
> 5 files changed, 26 insertions(+), 7 deletions(-)
>
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH net-next 0/6] selftests: drv-net: gro: more test cases
From: Willem de Bruijn @ 2026-04-02 0:19 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, shuah, willemb,
petrm, anubhavsinggh, richardbgobert, linux-kselftest,
Jakub Kicinski
In-Reply-To: <20260401182625.372605-1-kuba@kernel.org>
Jakub Kicinski wrote:
> Add a few more test cases for GRO.
>
> Jakub Kicinski (6):
> selftests: drv-net: gro: add data burst test case
> selftests: drv-net: gro: add 1 byte payload test
> selftests: drv-net: gro: always wait for FIN in the capacity test
> selftests: drv-net: gro: prepare for ip6ip6 support
> selftests: drv-net: gro: test ip6ip6
> selftests: drv-net: gro: add a test for bad IPv4 csum
>
> tools/testing/selftests/net/lib/gro.c | 171 +++++++++++++++------
> tools/testing/selftests/drivers/net/gro.py | 24 ++-
> 2 files changed, 143 insertions(+), 52 deletions(-)
For the series:
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH net-next 5/6] selftests: drv-net: gro: test ip6ip6
From: Willem de Bruijn @ 2026-04-02 0:20 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, shuah, willemb,
petrm, anubhavsinggh, richardbgobert, linux-kselftest,
Jakub Kicinski
In-Reply-To: <20260401182625.372605-6-kuba@kernel.org>
Jakub Kicinski wrote:
> We explicitly test ipip encap. Let's add ip6ip6, too. Having
> just ipip seems like favoring IPv4 which we should not do :)
> Testing all combinations is left for future work, not sure
> it's actually worth it.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> tools/testing/selftests/net/lib/gro.c | 29 ++++++++++++++++------
> tools/testing/selftests/drivers/net/gro.py | 19 ++++++++------
> 2 files changed, 34 insertions(+), 14 deletions(-)
>
> diff --git a/tools/testing/selftests/net/lib/gro.c b/tools/testing/selftests/net/lib/gro.c
> index 57080ecc3df8..762e88932ed2 100644
> --- a/tools/testing/selftests/net/lib/gro.c
> +++ b/tools/testing/selftests/net/lib/gro.c
> @@ -94,11 +94,14 @@
> #define START_SEQ 100
> #define START_ACK 100
> #define ETH_P_NONE 0
> -#define TOTAL_HDR_LEN (ETH_HLEN + sizeof(struct ipv6hdr) + sizeof(struct tcphdr))
> +#define TOTAL_HDR_LEN \
> + (ETH_HLEN + sizeof(struct ipv6hdr) * 2 + sizeof(struct tcphdr))
> #define MSS (4096 - sizeof(struct tcphdr) - sizeof(struct ipv6hdr))
> -#define MAX_PAYLOAD (IP_MAXPACKET - sizeof(struct tcphdr) - sizeof(struct ipv6hdr))
> +#define MAX_PAYLOAD \
> + (IP_MAXPACKET - sizeof(struct tcphdr) - sizeof(struct ipv6hdr))
> #define NUM_LARGE_PKT (MAX_PAYLOAD / MSS)
> -#define MAX_HDR_LEN (ETH_HLEN + sizeof(struct ipv6hdr) + sizeof(struct tcphdr))
> +#define MAX_HDR_LEN \
> + (ETH_HLEN + sizeof(struct ipv6hdr) * 2 + sizeof(struct tcphdr))
Not something that needs to be addressed here (or at all), but
TOTAL_HDR_LEN and MAX_HDR_LEN seem to be the same.
^ permalink raw reply
* Re: [PATCH 6/6] net: Warn when processes listen on AF_INET sockets
From: Jakub Kicinski @ 2026-04-02 0:20 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Woodhouse, Eric Dumazet, Saeed Mahameed, Leon Romanovsky,
Tariq Toukan, Mark Bloch, Andrew Lunn, David S. Miller,
Paolo Abeni, Simon Horman, Nikolay Aleksandrov, Ido Schimmel,
Martin KaFai Lau, Daniel Borkmann, John Fastabend,
Stanislav Fomichev, Alexei Starovoitov, Andrii Nakryiko,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Johannes Berg, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Guillaume Nault, Kees Cook, Alexei Lazar,
Gal Pressman, Paul Moore, netdev, linux-rdma, linux-kernel,
oss-drivers, bridge, bpf, linux-wireless, netfilter-devel,
coreteam, torvalds
In-Reply-To: <20260401080657.70cd9bd1@phoenix.local>
On Wed, 1 Apr 2026 08:06:57 -0700 Stephen Hemminger wrote:
> On Wed, 01 Apr 2026 10:28:23 +0100
> David Woodhouse <dwmw2@infradead.org> wrote:
>
> > > Some kernels are built without CONFIG_IPV6, so this warning would be
> > > quite misleading.
> >
> > Maybe on this date next year, we could make it not possible to build
> > the kernel *without* IPv6... ?
>
> There are some government agencies that used to require that IPV6 was disabled
> for security reasons. Yes they had broken old firewalls
Which is why we sadly have to keep the ipv6_mod_enabled()
sillilitude around. But that's a runtime thing.
^ permalink raw reply
* Re: [PATCH 0/6] Deprecate Legacy IP
From: patchwork-bot+netdevbpf @ 2026-04-02 0:24 UTC (permalink / raw)
To: David Woodhouse
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, Ido Schimmel, Martin KaFai Lau,
Daniel Borkmann, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Kuniyuki Iwashima,
Willem de Bruijn, David Ahern, Neal Cardwell, Johannes Berg,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Guillaume Nault,
David Woodhouse, Kees Cook, Alexei Lazar, Gal Pressman,
Paul Moore, netdev, linux-rdma, linux-kernel, oss-drivers, bridge,
bpf, linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
In-Reply-To: <20260401074509.1897527-1-dwmw2@infradead.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 1 Apr 2026 08:44:14 +0100 David Woodhouse wrote:
> RFC1883, the IPv6 standard, was published in the final decade of the 1900s.
> That's closer in time to the Apollo 11 moon landing than it was to today.
>
> Even our esteemed Maddog has worked with computers for longer in the IPv6
> era, than he ever did before it.
> [...]
Here is the summary with links:
- [net-next,v4,1/6] net: Simplify tautological CONFIG_INET/CONFIG_IPV6 guards
https://git.kernel.org/netdev/net-next/c/8888bf4fb980
- [net-next,v4,2/6] net: Add CONFIG_LEGACY_IP option
https://git.kernel.org/netdev/net-next/c/9b29afa11660
- [net-next,v4,3/6] net: Guard Legacy IP entry points with CONFIG_LEGACY_IP
https://git.kernel.org/netdev/net-next/c/f26d43acf12f
- [net-next,v4,4/6] net: Make IPv4-only Kconfig options depend on LEGACY_IP
https://git.kernel.org/netdev/net-next/c/ba5d4128fca8
- [net-next,v4,5/6] net: Change CONFIG_INET to CONFIG_LEGACY_IP for IPv4-only code
https://git.kernel.org/netdev/net-next/c/ff1cb3ad2abc
- [net-next,v4,6/6] net: Warn when processes listen on AF_INET sockets
https://git.kernel.org/netdev/net-next/c/7dae8ffb0987
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 2/2 net v2] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
From: Jakub Kicinski @ 2026-04-02 0:28 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, idosch, petrm, horms, pabeni, edumazet, davem, dsahern,
kees, Yiming Qian
In-Reply-To: <17d4d7e2-3b55-4eac-926c-e1355fbc1cd3@suse.de>
On Wed, 1 Apr 2026 16:50:36 +0200 Fernando Fernandez Mancera wrote:
> As Ido requested some changes, update the status in patchwork.
Thanks but FWIW the idea is to toss it into your normal replies :)
The bot should be able to dig thru the thread to find the patchwork
series even if you reply deep in the conversation.
Quoting documentation:
Updating patch status
~~~~~~~~~~~~~~~~~~~~~
Contributors and reviewers do not have the permissions to update patch
state directly in patchwork. Patchwork doesn't expose much information
about the history of the state of patches, therefore having multiple
people update the state leads to confusion.
Instead of delegating patchwork permissions netdev uses a simple mail
bot which looks for special commands/lines within the emails sent to
the mailing list. For example to mark a series as Changes Requested
one needs to send the following line anywhere in the email thread::
pw-bot: changes-requested
As a result the bot will set the entire series to Changes Requested.
This may be useful when author discovers a bug in their own series
and wants to prevent it from getting applied.
The use of the bot is entirely optional, if in doubt ignore its existence
completely. Maintainers will classify and update the state of the patches
themselves. No email should ever be sent to the list with the main purpose
of communicating with the bot, the bot commands should be seen as metadata.
The use of the bot is restricted to authors of the patches (the ``From:``
header on patch submission and command must match!), maintainers of
the modified code according to the MAINTAINERS file (again, ``From:``
must match the MAINTAINERS entry) and a handful of senior reviewers.
Bot records its activity here:
https://netdev.bots.linux.dev/pw-bot.html
See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#updating-patch-status
^ permalink raw reply
* Re: [PATCH net-next 6/6] selftests: drv-net: gro: add a test for bad IPv4 csum
From: Willem de Bruijn @ 2026-04-02 0:28 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, shuah, willemb,
petrm, anubhavsinggh, richardbgobert, linux-kselftest,
Jakub Kicinski
In-Reply-To: <20260401182625.372605-7-kuba@kernel.org>
Jakub Kicinski wrote:
> We have a test for coalescing with bad TCP checksum, let's also
> test bad IPv4 header checksum.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> tools/testing/selftests/net/lib/gro.c | 25 ++++++++++++++++++++++
> tools/testing/selftests/drivers/net/gro.py | 1 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/tools/testing/selftests/net/lib/gro.c b/tools/testing/selftests/net/lib/gro.c
> index 762e88932ed2..a458cfbd11eb 100644
> --- a/tools/testing/selftests/net/lib/gro.c
> +++ b/tools/testing/selftests/net/lib/gro.c
> @@ -36,6 +36,7 @@
> * Packets with different (ECN, TTL, TOS) header, IP options or
> * IP fragments shouldn't coalesce.
> * - ip_ecn, ip_tos: shared between IPv4/IPv6
> + * - ip_csum: IPv4 only, bad IP header checksum
> * - ip_ttl, ip_opt, ip_frag4: IPv4 only
> * - ip_id_df*: IPv4 IP ID field coalescing tests
> * - ip_frag6, ip_v6ext_*: IPv6 only
> @@ -675,6 +676,21 @@ static void send_changed_checksum(int fd, struct sockaddr_ll *daddr)
> write_packet(fd, buf, pkt_size, daddr);
> }
>
> +/* Packets with incorrect IPv4 header checksum don't coalesce. */
> +static void send_changed_ip_checksum(int fd, struct sockaddr_ll *daddr)
> +{
> + static char buf[MAX_HDR_LEN + PAYLOAD_LEN];
> + struct iphdr *iph = (struct iphdr *)(buf + ETH_HLEN);
> + int pkt_size = total_hdr_len + PAYLOAD_LEN;
> +
> + create_packet(buf, 0, 0, PAYLOAD_LEN, 0);
> + write_packet(fd, buf, pkt_size, daddr);
> +
> + create_packet(buf, PAYLOAD_LEN, 0, PAYLOAD_LEN, 0);
> + iph->check = iph->check - 1;
> + write_packet(fd, buf, pkt_size, daddr);
> +}
> +
> /* Packets with non-consecutive sequence number don't coalesce.*/
> static void send_changed_seq(int fd, struct sockaddr_ll *daddr)
> {
> @@ -1392,6 +1408,10 @@ static void gro_sender(void)
> write_packet(txfd, fin_pkt, total_hdr_len, &daddr);
>
> /* ip sub-tests - IPv4 only */
> + } else if (strcmp(testname, "ip_csum") == 0) {
> + send_changed_ip_checksum(txfd, &daddr);
> + usleep(fin_delay_us);
> + write_packet(txfd, fin_pkt, total_hdr_len, &daddr);
> } else if (strcmp(testname, "ip_ttl") == 0) {
> send_changed_ttl(txfd, &daddr);
> write_packet(txfd, fin_pkt, total_hdr_len, &daddr);
> @@ -1588,6 +1608,11 @@ static void gro_receiver(void)
> check_recv_pkts(rxfd, correct_payload, 2);
>
> /* ip sub-tests - IPv4 only */
> + } else if (strcmp(testname, "ip_csum") == 0) {
> + correct_payload[0] = PAYLOAD_LEN;
> + correct_payload[1] = PAYLOAD_LEN;
> + printf("bad ip checksum doesn't coalesce: ");
> + check_recv_pkts(rxfd, correct_payload, 2);
This verifies that a packet with bad csum does not coalesce to a valid
packet. Perhaps too paranoid but, do you also want to test the reverse
case?
Can be a single test by adding another write_packet and observing all
three separate packets.
^ permalink raw reply
* [PATCH v2] net/mlx5: Fix OOB access and stack information leak in PTP event handling
From: Prathamesh Deshpande @ 2026-04-02 0:30 UTC (permalink / raw)
To: prathameshdeshpande7
Cc: leon, linux-kernel, linux-rdma, mbloch, netdev, richardcochran,
saeedm, tariqt
In-Reply-To: <20260331153152.16766-1-prathameshdeshpande7@gmail.com>
In mlx5_pps_event(), several critical issues were identified during
review by Sashiko:
1. The 'pin' index from the hardware event was used without bounds
checking to index 'pin_config' and 'pps_info->start', leading to
potential out-of-bounds memory access.
2. 'ptp_event' was not zero-initialized. Since it contains a union,
assigning a timestamp partially leaves the 'ts_raw' field with
uninitialized stack memory, which can leak kernel data or
corrupt time sync logic in hardpps().
3. A NULL 'pin_config' could be dereferenced if initialization failed.
4. 'clock->ptp' could be NULL if ptp_clock_register() failed.
Fix these by zero-initializing the event struct, adding a bounds
check against MAX_PIN_NUM, and adding appropriate NULL guards.
Fixes: 7c39afb394c7 ("net/mlx5: PTP code migration to driver core section")
Signed-off-by: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
---
v2:
- Zero-initialize ptp_event to prevent stack information leak [Sashiko].
- Add bounds check for hardware pin index to prevent OOB access [Sashiko].
- Add NULL guard for pin_config to handle initialization failures [Sashiko].
- Add NULL check for clock->ptp as originally intended.
drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
index bd4e042077af..a4d8c5c39abc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
@@ -1164,12 +1164,18 @@ static int mlx5_pps_event(struct notifier_block *nb,
pps_nb);
struct mlx5_core_dev *mdev = clock_state->mdev;
struct mlx5_clock *clock = mdev->clock;
- struct ptp_clock_event ptp_event;
+ struct ptp_clock_event ptp_event = {};
struct mlx5_eqe *eqe = data;
int pin = eqe->data.pps.pin;
unsigned long flags;
u64 ns;
+ if (!clock->ptp_info.pin_config)
+ return NOTIFY_OK;
+
+ if (pin < 0 || pin >= MAX_PIN_NUM)
+ return NOTIFY_OK;
+
switch (clock->ptp_info.pin_config[pin].func) {
case PTP_PF_EXTTS:
ptp_event.index = pin;
@@ -1185,8 +1191,8 @@ static int mlx5_pps_event(struct notifier_block *nb,
} else {
ptp_event.type = PTP_CLOCK_EXTTS;
}
- /* TODOL clock->ptp can be NULL if ptp_clock_register fails */
- ptp_clock_event(clock->ptp, &ptp_event);
+ if (clock->ptp)
+ ptp_clock_event(clock->ptp, &ptp_event);
break;
case PTP_PF_PEROUT:
if (clock->shared) {
--
2.43.0
^ permalink raw reply related
* Re: [net-next v7 07/10] net: bnxt: Implement software USO
From: Eric Dumazet @ 2026-04-02 0:35 UTC (permalink / raw)
To: Joe Damato
Cc: netdev, Michael Chan, Pavan Chebbi, Andrew Lunn, David S. Miller,
Jakub Kicinski, Paolo Abeni, horms, linux-kernel, leon
In-Reply-To: <20260401233745.2333858-8-joe@dama.to>
On Wed, Apr 1, 2026 at 4:38 PM Joe Damato <joe@dama.to> wrote:
>
> Implement bnxt_sw_udp_gso_xmit() using the core tso_dma_map API and
> the pre-allocated TX inline buffer for per-segment headers.
>
> The xmit path:
> 1. Calls tso_start() to initialize TSO state
> 2. Stack-allocates a tso_dma_map and calls tso_dma_map_init() to
> DMA-map the linear payload and all frags upfront.
> 3. For each segment:
> - Copies and patches headers via tso_build_hdr() into the
> pre-allocated tx_inline_buf (DMA-synced per segment)
> - Counts payload BDs via tso_dma_map_count()
> - Emits long BD (header) + ext BD + payload BDs
> - Payload BDs use tso_dma_map_next() which yields (dma_addr,
> chunk_len, mapping_len) tuples.
>
> Header BDs set dma_unmap_len=0 since the inline buffer is pre-allocated
> and unmapped only at ring teardown.
>
> Completion state is updated by calling tso_dma_map_completion_save() for
> the last segment.
>
> Suggested-by: Jakub Kicinski <kuba@kernel.org>
> Signed-off-by: Joe Damato <joe@dama.to>
> ---
> v7:
> - Dropped Pavan's Reviewed-by as some changes were made.
> - Updated struct bnxt_sw_tx_bd to embed a tso_dma_map_completion_state
> struct for tracking completion state.
> - Dropped an unnecessary slot check.
> - Eliminated an ugly looking ternary to simplify the code.
> - Call tso_dma_map_completion_save to update completion state.
>
> v6:
> - Addressed Paolo's feedback where the IOVA API could fail transiently,
> leaving stale state in iova_state. Fix this by always copying the state,
> noting that dma_iova_try_alloc is called unconditionally in the
> tso_dma_map_init function (via tso_dma_iova_try), which zeroes the state
> even if the API can't be used.
> - Since this was a very minor change, I retained Pavan's Reviewed-by.
>
> v5:
> - Added __maybe_unused to last_unmap_len and last_unmap_addr to silence a
> build warning when CONFIG_NEED_DMA_MAP_STATE is disabled. No functional
> changes.
> - Added Pavan's Reviewed-by.
>
> v4:
> - Fixed the early return issue Pavan pointed out when num_segs <= 1; use the
> drop label instead of returning.
>
> v3:
> - Added iova_state and iova_total_len to struct bnxt_sw_tx_bd.
> - Stores iova_state on the last segment's tx_buf during xmit.
>
> rfcv2:
> - set the unmap len on the last descriptor, so that when completions fire
> only the last completion unmaps the region.
>
> drivers/net/ethernet/broadcom/bnxt/bnxt.h | 3 +
> drivers/net/ethernet/broadcom/bnxt/bnxt_gso.c | 197 ++++++++++++++++++
> 2 files changed, 200 insertions(+)
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
> index b5b84d1e5217..993b215413c7 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
> @@ -11,6 +11,8 @@
> #ifndef BNXT_H
> #define BNXT_H
>
> +#include <net/tso.h>
> +
> #define DRV_MODULE_NAME "bnxt_en"
>
> /* DO NOT CHANGE DRV_VER_* defines
> @@ -899,6 +901,7 @@ struct bnxt_sw_tx_bd {
> u16 rx_prod;
> u16 txts_prod;
> };
> + struct tso_dma_map_completion_state sw_gso_cstate;
> };
>
> #define BNXT_SW_GSO_MID 1
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_gso.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_gso.c
> index b296769ee4fe..b0f8126b6903 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_gso.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_gso.c
> @@ -19,11 +19,208 @@
> #include "bnxt.h"
> #include "bnxt_gso.h"
>
> +static u32 bnxt_sw_gso_lhint(unsigned int len)
> +{
> + if (len <= 512)
> + return TX_BD_FLAGS_LHINT_512_AND_SMALLER;
> + else if (len <= 1023)
> + return TX_BD_FLAGS_LHINT_512_TO_1023;
> + else if (len <= 2047)
> + return TX_BD_FLAGS_LHINT_1024_TO_2047;
> + else
> + return TX_BD_FLAGS_LHINT_2048_AND_LARGER;
> +}
> +
> netdev_tx_t bnxt_sw_udp_gso_xmit(struct bnxt *bp,
> struct bnxt_tx_ring_info *txr,
> struct netdev_queue *txq,
> struct sk_buff *skb)
> {
> + unsigned int last_unmap_len __maybe_unused = 0;
> + dma_addr_t last_unmap_addr __maybe_unused = 0;
> + struct bnxt_sw_tx_bd *last_unmap_buf = NULL;
> + unsigned int hdr_len, mss, num_segs;
> + struct pci_dev *pdev = bp->pdev;
> + unsigned int total_payload;
> + struct tso_dma_map map;
> + u32 vlan_tag_flags = 0;
> + int i, bds_needed;
> + struct tso_t tso;
> + u16 cfa_action;
> + u16 prod;
> +
> + hdr_len = tso_start(skb, &tso);
> + mss = skb_shinfo(skb)->gso_size;
> + total_payload = skb->len - hdr_len;
> + num_segs = DIV_ROUND_UP(total_payload, mss);
> +
> + /* Zero the csum fields so tso_build_hdr will propagate zeroes into
> + * every segment header. HW csum offload will recompute from scratch.
> + */
We might need a call to skb_cow_head(skb, 0) before changing ->check
(or anything in skb->head)
Alternative would be to perform the clears after each tso_build_hdr()
and leave skb->head untouched.
> + udp_hdr(skb)->check = 0;
> + if (!tso.ipv6)
> + ip_hdr(skb)->check = 0;
> +
> + if (unlikely(num_segs <= 1))
> + goto drop;
> +
> + /* Upper bound on the number of descriptors needed.
> + *
> + * Each segment uses 1 long BD + 1 ext BD + payload BDs, which is
> + * at most num_segs + nr_frags (each frag boundary crossing adds at
> + * most 1 extra BD).
> + */
> + bds_needed = 3 * num_segs + skb_shinfo(skb)->nr_frags + 1;
> +
> + if (unlikely(bnxt_tx_avail(bp, txr) < bds_needed)) {
> + netif_txq_try_stop(txq, bnxt_tx_avail(bp, txr),
> + bp->tx_wake_thresh);
> + return NETDEV_TX_BUSY;
> + }
> +
> + if (unlikely(tso_dma_map_init(&map, &pdev->dev, skb, hdr_len)))
> + goto drop;
> +
> + cfa_action = bnxt_xmit_get_cfa_action(skb);
> + if (skb_vlan_tag_present(skb)) {
> + vlan_tag_flags = TX_BD_CFA_META_KEY_VLAN |
> + skb_vlan_tag_get(skb);
> + if (skb->vlan_proto == htons(ETH_P_8021Q))
> + vlan_tag_flags |= 1 << TX_BD_CFA_META_TPID_SHIFT;
> + }
> +
> + prod = txr->tx_prod;
> +
> + for (i = 0; i < num_segs; i++) {
> + unsigned int seg_payload = min_t(unsigned int, mss,
> + total_payload - i * mss);
> + u16 slot = (txr->tx_inline_prod + i) &
> + (BNXT_SW_USO_MAX_SEGS - 1);
> + struct bnxt_sw_tx_bd *tx_buf;
> + unsigned int mapping_len;
> + dma_addr_t this_hdr_dma;
> + unsigned int chunk_len;
> + unsigned int offset;
> + dma_addr_t dma_addr;
> + struct tx_bd *txbd;
> + void *this_hdr;
> + int bd_count;
> + __le32 csum;
> + bool last;
> + u32 flags;
> +
> + last = (i == num_segs - 1);
> + offset = slot * TSO_HEADER_SIZE;
> + this_hdr = txr->tx_inline_buf + offset;
> + this_hdr_dma = txr->tx_inline_dma + offset;
> +
> + tso_build_hdr(skb, this_hdr, &tso, seg_payload, last);
> +
> + dma_sync_single_for_device(&pdev->dev, this_hdr_dma,
> + hdr_len, DMA_TO_DEVICE);
> +
> + bd_count = tso_dma_map_count(&map, seg_payload);
> +
> + tx_buf = &txr->tx_buf_ring[RING_TX(bp, prod)];
> + txbd = &txr->tx_desc_ring[TX_RING(bp, prod)][TX_IDX(prod)];
> +
> + tx_buf->skb = skb;
> + tx_buf->nr_frags = bd_count;
> + tx_buf->is_push = 0;
> + tx_buf->is_ts_pkt = 0;
> +
> + dma_unmap_addr_set(tx_buf, mapping, this_hdr_dma);
> + dma_unmap_len_set(tx_buf, len, 0);
> +
> + if (last) {
> + tx_buf->is_sw_gso = BNXT_SW_GSO_LAST;
> + tso_dma_map_completion_save(&map, &tx_buf->sw_gso_cstate);
> + } else {
> + tx_buf->is_sw_gso = BNXT_SW_GSO_MID;
> + }
> +
> + flags = (hdr_len << TX_BD_LEN_SHIFT) |
> + TX_BD_TYPE_LONG_TX_BD |
> + TX_BD_CNT(2 + bd_count);
> +
> + flags |= bnxt_sw_gso_lhint(hdr_len + seg_payload);
> +
> + txbd->tx_bd_len_flags_type = cpu_to_le32(flags);
> + txbd->tx_bd_haddr = cpu_to_le64(this_hdr_dma);
> + txbd->tx_bd_opaque = SET_TX_OPAQUE(bp, txr, prod,
> + 2 + bd_count);
> +
> + csum = cpu_to_le32(TX_BD_FLAGS_TCP_UDP_CHKSUM |
> + TX_BD_FLAGS_IP_CKSUM);
> +
> + prod = NEXT_TX(prod);
> + bnxt_init_ext_bd(bp, txr, prod, csum,
> + vlan_tag_flags, cfa_action);
> +
> + /* set dma_unmap_len on the LAST BD touching each
> + * region. Since completions are in-order, the last segment
> + * completes after all earlier ones, so the unmap is safe.
> + */
> + while (tso_dma_map_next(&map, &dma_addr, &chunk_len,
> + &mapping_len, seg_payload)) {
> + prod = NEXT_TX(prod);
> + txbd = &txr->tx_desc_ring[TX_RING(bp, prod)][TX_IDX(prod)];
> + tx_buf = &txr->tx_buf_ring[RING_TX(bp, prod)];
> +
> + txbd->tx_bd_haddr = cpu_to_le64(dma_addr);
> + dma_unmap_addr_set(tx_buf, mapping, dma_addr);
> + dma_unmap_len_set(tx_buf, len, 0);
> + tx_buf->skb = NULL;
> + tx_buf->is_sw_gso = 0;
> +
> + if (mapping_len) {
> + if (last_unmap_buf) {
> + dma_unmap_addr_set(last_unmap_buf,
> + mapping,
> + last_unmap_addr);
> + dma_unmap_len_set(last_unmap_buf,
> + len,
> + last_unmap_len);
> + }
> + last_unmap_addr = dma_addr;
> + last_unmap_len = mapping_len;
> + }
> + last_unmap_buf = tx_buf;
> +
> + flags = chunk_len << TX_BD_LEN_SHIFT;
> + txbd->tx_bd_len_flags_type = cpu_to_le32(flags);
> + txbd->tx_bd_opaque = 0;
> +
> + seg_payload -= chunk_len;
> + }
> +
> + txbd->tx_bd_len_flags_type |=
> + cpu_to_le32(TX_BD_FLAGS_PACKET_END);
> +
> + prod = NEXT_TX(prod);
> + }
> +
> + if (last_unmap_buf) {
> + dma_unmap_addr_set(last_unmap_buf, mapping, last_unmap_addr);
> + dma_unmap_len_set(last_unmap_buf, len, last_unmap_len);
> + }
> +
> + txr->tx_inline_prod += num_segs;
> +
> + netdev_tx_sent_queue(txq, skb->len);
> +
> + WRITE_ONCE(txr->tx_prod, prod);
> + /* Sync BDs before doorbell */
> + wmb();
> + bnxt_db_write(bp, &txr->tx_db, prod);
> +
> + if (unlikely(bnxt_tx_avail(bp, txr) <= bp->tx_wake_thresh))
> + netif_txq_try_stop(txq, bnxt_tx_avail(bp, txr),
> + bp->tx_wake_thresh);
> +
> + return NETDEV_TX_OK;
> +
> +drop:
> dev_kfree_skb_any(skb);
> dev_core_stats_tx_dropped_inc(bp->dev);
> return NETDEV_TX_OK;
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH net] rds: ib: reject FRMR registration before IB connection is established
From: Allison Henderson @ 2026-04-02 0:36 UTC (permalink / raw)
To: Weiming Shi, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, netdev, linux-rdma, Xiang Mei
In-Reply-To: <20260330163237.2752440-2-bestswngs@gmail.com>
On Tue, 2026-03-31 at 00:32 +0800, Weiming Shi wrote:
> rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data
> and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a
> fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with
> i_cm_id = NULL because the connection worker has not yet called
> rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with
> RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses
> the control message before any connection establishment, allowing
> rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the
> kernel.
>
> The existing guard in rds_ib_reg_frmr() only checks for !ic (added in
> commit 9e630bcb7701), which does not catch this case since ic is allocated
> early and is always non-NULL once the connection object exists.
>
> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
> RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920
> Call Trace:
> rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167)
> rds_ib_map_frmr (net/rds/ib_frmr.c:252)
> rds_ib_reg_frmr (net/rds/ib_frmr.c:430)
> rds_ib_get_mr (net/rds/ib_rdma.c:615)
> __rds_rdma_map (net/rds/rdma.c:295)
> rds_cmsg_rdma_map (net/rds/rdma.c:860)
> rds_sendmsg (net/rds/send.c:1363)
> ____sys_sendmsg
> do_syscall_64
>
> Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all
> non-NULL before proceeding with FRMR registration, mirroring the guard
> already present in rds_ib_post_inv(). Return -ENODEV when the connection
> is not ready, which the existing error handling in rds_cmsg_send() converts
> to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to
> start the connection worker.
>
> Fixes: 1659185fb4d0 ("RDS: IB: Support Fastreg MR (FRMR) memory registration mode")
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
> net/rds/ib_rdma.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
> index 077f7041df155..2cfec252eeac2 100644
> --- a/net/rds/ib_rdma.c
> +++ b/net/rds/ib_rdma.c
> @@ -604,8 +604,13 @@ void *rds_ib_get_mr(struct scatterlist *sg, unsigned long nents,
> return ibmr;
> }
>
> - if (conn)
> + if (conn) {
> ic = conn->c_transport_data;
> + if (!ic || !ic->i_cm_id || !ic->i_cm_id->qp) {
> + ret = -ENODEV;
> + goto out;
> + }
> + }
>
> if (!rds_ibdev->mr_8k_pool || !rds_ibdev->mr_1m_pool) {
> ret = -ENODEV;
Hi Weiming,
Apologies for the delay, this looks looks fine to me. Thanks for catching this.
Reviewed-by: Allison Henderson <achender@kernel.org>
^ permalink raw reply
* Re: [REGRESSION] net: add xmit recursion limit to tunnel xmit functions
From: Jakub Kicinski @ 2026-04-02 0:38 UTC (permalink / raw)
To: Chris Arges
Cc: Weiming Shi, Eric Dumazet, Paolo Abeni, netdev, kernel-team,
jgriege
In-Reply-To: <acwp_cVAflwTQCBh@20HS2G4>
On Tue, 31 Mar 2026 15:09:33 -0500 Chris Arges wrote:
> Commit 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions")
> introduces a regression in our systems using legitimate multi-level tunnel
> encapsulation stacks. Our testing was with stable 6.12.y and 6.18.y where this
> patch was backported.
>
> One of the usecases we have are packets being sent to a GRE device, then
> MPLS/LWT route, then IPIP device, then SIT/FOU device. What we observed is that
> packets are getting dropped at the last device and we get the message "Dead
> loop on virtual device" sent from the iptunnel_xmit function.
Last device meaning limit of 5 would have worked for you?
I don't think there was any hard math behind the 4 so ++
on the limit may be simplest, but I defer to Paolo..
^ permalink raw reply
* Re: [PATCH net v3] ipv6: fix data race in fib6_metric_set() using cmpxchg
From: Jakub Kicinski @ 2026-04-02 0:47 UTC (permalink / raw)
To: Hangbin Liu
Cc: David S. Miller, David Ahern, Eric Dumazet, Paolo Abeni,
Simon Horman, Jiayuan Chen, David Ahern, netdev, linux-kernel,
Fei Liu
In-Reply-To: <20260331-b4-fib6_metric_set-kmemleak-v3-1-88d27f4d8825@gmail.com>
On Tue, 31 Mar 2026 12:17:18 +0800 Hangbin Liu wrote:
> - if (f6i->fib6_metrics == &dst_default_metrics) {
> + if (READ_ONCE(f6i->fib6_metrics) == &dst_default_metrics) {
> + struct dst_metrics *dflt = (struct dst_metrics *)&dst_default_metrics;
> struct dst_metrics *p = kzalloc_obj(*p, GFP_ATOMIC);
Orthogonal, but I forgot to reply - could you poke at making
cmpxchg() take const on the second argument? The type of the
first and third args must obviously match exactly but the
second one is just a reference, it should be okay to make
it const :/
^ permalink raw reply
* Re: [PATCH] igc: fix Tx timestamp timeout caused by unlocked TIMINCA write in adj fine]
From: Bob Van Valzah @ 2026-04-02 0:49 UTC (permalink / raw)
To: Vadim Fedorenko
Cc: intel-wired-lan, anthony.l.nguyen, netdev, julianstj, jeff,
Lasse Johnsen, Ian Gough
In-Reply-To: <CAD61B95-35BF-4BAC-AC26-6AC043DE6FC1@vanvalzah.com>
Vadim,
Thanks for the feedback on our first patch. We've spent more time in
the lab studying the igc TX timestamp behavior under stress. We
understand the failure modes much better now.
You were right that ptp_tx_lock was the wrong lock — it guards the TX
queue, not the timing registers. You suggested tmreg_lock instead. We
tested tmreg_lock alone (v2) and found it doesn't fix the bug: it appears
that the race is between the software TIMINCA write and the hardware’s
asynchronous TX timestamp capture pipeline, not between two software threads.
tmreg_lock serializes software register accesses but can't prevent the hardware
from reading TIMINCA at the instant software writes it.
Our v3 patch (attached) takes tmreg_lock as you suggested, and
additionally disables TX timestamping in hardware via TSYNCTXCTL around
the TIMINCA write. This prevents the hardware from starting new
timestamp captures during the rate change:
spin_lock_irqsave(&igc->tmreg_lock, flags);
txctl = rd32(IGC_TSYNCTXCTL);
wr32(IGC_TSYNCTXCTL, txctl & ~IGC_TSYNCTXCTL_ENABLED);
wr32(IGC_TIMINCA, inca);
wr32(IGC_TSYNCTXCTL, txctl);
spin_unlock_irqrestore(&igc->tmreg_lock, flags);
v3 doesn't return -EBUSY, so there's no risk of adjfine starvation
under TX load. It always completes the TIMINCA write.
This still isn't a complete fix. Under extreme stress (100k+ adjfine/s
concurrent with 100k+ TX timestamps/s), disabling TSYNCTXCTL can strand
an in-progress capture that started before the disable. The stranded
slot sits occupied for IGC_PTP_TX_TIMEOUT (15s) before the watchdog
clears it. However, these rates are far beyond any realistic PTP
deployment. At realistic rates (1 Hz adjfine + 128 Hz PTP sync), v3
passes all our tests cleanly.
We don't know of a way to prevent pathological system call patterns
from causing the hardware to lock up. The vulnerable window seems to
span the hardware's internal capture-to-latch pipeline, not just the
TIMINCA write instant, and there's no software-visible indication of
when a capture is mid-flight.
Test methodology
----------------
Our earlier multi-test runs gave misleading results because the
15-second timeout pipeline carried stranded slots from one test into
the next. We now reload the igc driver between each test to ensure
clean hardware state. The reproducer is the same one we submitted
previously:
https://github.com/bobvan/PePPAR-Fix/blob/main/tools/igc_tx_timeout_repro.py
We also have a single-test runner that reloads the driver automatically:
https://github.com/bobvan/PePPAR-Fix/blob/main/tools/igc_tx_single_test.py
Results (clean state, driver reloaded between each test)
--------------------------------------------------------
Stock driver (no patch):
TX 100/s + adj 1/s : no timeout in 60s (0 TO, 0 skip)
TX 1k/s + adj 1/s : no timeout in 60s (0 TO, 0 skip)
TX 10k/s + adj 1/s : no timeout in 60s (0 TO, 0 skip)
TX 1k/s + adj 10k/s : no timeout in 60s (0 TO, 0 skip)
TX 10k/s + adj 100k/s : no timeout in 60s (0 TO, 0 skip)
TX 100k/s + adj 100k/s : FAIL at 16s (3 TO, 76 skip)
TX 100k/s + no adj : FAIL at 16s (4 TO, 8M skip)
v3 (tmreg_lock + TSYNCTXCTL disable/enable):
TX 128/s + adj 1/s : no timeout in 300s (0 TO, 0 skip)
TX 100k/s + adj 100k/s : FAIL at 17s (12 TO, 1.7M skip)
Three distinct failure modes
----------------------------
1. TIMINCA corruption (the original bug):
adjfine writes TIMINCA while a TX timestamp capture is in progress.
The hardware latches a value computed with an inconsistent increment
rate. The valid bit in TSYNCTXCTL is never set, the slot stays
occupied, and the watchdog times out after 15 seconds.
Signature: low skip count + moderate timeout count. The capture
acquired a slot normally but the timestamp was corrupt.
This is the bug that matters in practice. At 1 Hz adjfine + 128 Hz
PTP sync, the collision probability per adjfine call is low but
nonzero — we measured ~30 minute MTBF empirically.
2. TX timestamp slot exhaustion:
At extreme TX rates (100k+) without adjfine, all 4 timestamp slots
(IGC_MAX_TX_TSTAMP_REGS) stay occupied because the interrupt/drain
path can't keep up. New packets requesting timestamps are skipped
(tx_hwtstamp_skipped). Eventually some slot's 15-second timeout
fires.
Signature: massive skip count (millions), timeout count = 4 (one
per slot). This is unrelated to the TIMINCA race.
3. TSYNCTXCTL stranding (v3 side effect):
When v3 disables TSYNCTXCTL_ENABLED, a capture that was already
in progress may never complete — the hardware won't set the valid
bit for a capture started while timestamping was enabled if it
finishes after timestamping is disabled. The slot stays occupied
for 15 seconds.
Signature: high skip count + high timeout count. At 100k adj/s,
timestamping is disabled 100k times per second, frequently
stranding captures.
This doesn't occur at realistic rates because the 1 Hz adjfine
only creates one brief (~1 µs) disable window per second.
PTP GM scaling implications
---------------------------
With adjfine fixed at 1/s (realistic for any GPSDO), the adjfine race
is not the scaling bottleneck. The limit is the 4-slot TX timestamp
queue (IGC_MAX_TX_TSTAMP_REGS). We swept TX timestamp rates from
128/s to 150k/s with 1 Hz adjfine and driver reload between each
test (v3 patch):
TX 128/s + adj 1/s : clean 60s (1 PTP client at 128 Hz)
TX 1024/s + adj 1/s : clean 60s (~8 clients)
TX 8192/s + adj 1/s : clean 60s (~64 clients)
TX 65536/s + adj 1/s : clean 60s (~512 clients)
TX 100k/s + adj 1/s : FAIL 17s (12 TO, 9M skip — slot exhaustion)
TX 100k/s + NO adj : FAIL 17s (12 TO, 10M skip — same without adj)
The 100k/s failure is slot exhaustion (identical with and without
adjfine), not the TIMINCA race. The i225/i226 hardware can handle
roughly 65k TX timestamps per second before the 4-slot queue becomes
the bottleneck. This limits the i226 to approximately 500 PTP
clients at logSyncInterval -7 (128 Hz sync).
The adjfine race itself has negligible probability at 1 Hz adjfine.
The TSYNCTXCTL disable window in v3 is ~1 µs per second — a duty
cycle of 10^-6. Even at 65k TX timestamps/s, the probability of
a capture starting during that window is ~0.065 per second, giving
an estimated MTBF of many hours.
Note on igc_ptp_tx_hang
------------------------
We noticed that igc_ptp_tx_hang() does not check TSYNCTXCTL valid
bits before declaring a timeout. It only checks whether 15 seconds
have elapsed since the slot was assigned. If the hardware captured a
valid timestamp but the completion interrupt was lost or coalesced,
the valid timestamp is thrown away by the timeout handler (which reads
TXSTMPH_0 to clear all valid bits). A more robust timeout handler
could check TSYNCTXCTL and salvage valid-but-undelivered timestamps
before declaring a timeout. This wouldn't fix the TIMINCA race but
would make the system more resilient to lost interrupts.
Tested on:
- Intel i226 (TimeHAT board on Raspberry Pi 5)
- Kernel 6.12.62+rpt-rpi-2712 (Raspberry Pi OS)
- Intel out-of-tree igc driver 5.4.0-7642.46
Thanks,
Bob Van Valzah
—
drivers/net/ethernet/intel/igc/igc_ptp.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_ptp.c b/drivers/net/ethernet/int
el/igc/igc_ptp.c
--- a/drivers/net/ethernet/intel/igc/igc_ptp.c
+++ b/drivers/net/ethernet/intel/igc/igc_ptp.c
@@ -47,6 +47,8 @@ static int igc_ptp_adjfine_i225(struct ptp_clock_info *ptp, lo
ng scaled_ppm)
{
struct igc_adapter *igc = container_of(ptp, struct igc_adapter,
ptp_caps);
struct igc_hw *hw = &igc->hw;
+ unsigned long flags;
+ u32 txctl;
int neg_adj = 0;
u64 rate;
u32 inca;
@@ -63,7 +65,17 @@ static int igc_ptp_adjfine_i225(struct ptp_clock_info *ptp, l
ong scaled_ppm)
if (neg_adj)
inca |= ISGN;
- wr32(IGC_TIMINCA, inca);
+ /* Changing TIMINCA while the hardware is capturing a TX timestamp
+ * corrupts the timestamp, causing "Tx timestamp timeout."
+ * Temporarily disable TX timestamping so no new capture can start
+ * during the rate change.
+ */
+ spin_lock_irqsave(&igc->tmreg_lock, flags);
+ txctl = rd32(IGC_TSYNCTXCTL);
+ wr32(IGC_TSYNCTXCTL, txctl & ~IGC_TSYNCTXCTL_ENABLED);
+ wr32(IGC_TIMINCA, inca);
+ wr32(IGC_TSYNCTXCTL, txctl);
+ spin_unlock_irqrestore(&igc->tmreg_lock, flags);
return 0;
}
--
2.39.2
> On Mar 31, 2026, at 6:14 PM, Bob Van Valzah <Bob@VanValzah.Com> wrote:
>
> There is one other symptom of this bug that we neglected to report previously: PEROUT stops. That’s PPS OUT for us, so it’s how we first noticed the problem. Recovery was to unload and reload the igc driver.
>
> I take this as further evidence for my hunch that the hardware just reaches some internal “this should never happen” state and the PHC just stops ticking.
>
> Hoping this additional symptom report might help with diagnosis.
>
> Bob
>
>> On Mar 30, 2026, at 12:42 PM, Bob Van Valzah <Bob@VanValzah.Com> wrote:
>>
>> Thanks for following up Vadim. To be clear, we do not see our patch as a solution to the problem, since it does not eliminate the underlying contention, it just reduces the likelihood.
>>
>> We now have a bit more hands-on time running the patch and can see its limitations. The driver just throws the timeout error less often now. Moreover, our code calling adjfine() has to be ready for an EBUSY. The patch is certainly not an elegant solution. It may well have worked better, or perhaps been a complete fix, if we had taken tmreg_lock. Sorry if we sent our patch prematurely.
>>
>> We think the contention happens when a system call made by a clock disciplining daemon like ts2phc changes a PHC's frequency, while a timestamping daemon like ptp4l has requested a timestamp against that same PHC. A plausible explanation is that the hardware fails to produce a timestamp for a packet when it collides with a PHC frequency adjustment, leading to the timestamp timeout. We see this contention 128x more often than the average user because we cranked our PTP sync rate up to 128 Hz. We care about every ns here. The likelihood probably also scales with the number of PTP clients.
>>
>> Sorry, in retrospect, we may have overstated our case in declaring the root cause as the lack of locking, since our locking only reduces the likelihood of the timestamp timeout. Intel may provide insight to the underlying cause of the timeout, but my hunch is that the collision of a timestamp request against a PHC and a frequency change of the same PHC causes the timestamp request to fail, leading to the timeout. Our repro code makes this happen so reliably that it should be easy for the hardware guys to explain exactly what’s going on. Hopefully, they can advise on a more elegant avoidance strategy than our ham-handed lock.
>>
>> We have not tried recovering a timestamp following the error. We may have used the term “corrupted” poorly here. Since the error message says “timeout," that could mean the hardware produced no timestamp at all, rather than a corrupted one.
>>
>> This isn’t a show-stopper for us, but we note that timekeeping daemons with imperfect error handling could react to this situation poorly and perhaps fail silently.
>>
>> Bob
>>
>>> On Mar 30, 2026, at 11:39 AM, Vadim Fedorenko <vadim.fedorenko@linux.dev> wrote:
>>>
>>> On 29/03/2026 04:25, Bob Van Valzah wrote:
>>>> Hi,
>>>> We found a race in igc_ptp_adjfine_i225() that causes "Tx timestamp
>>>> timeout" errors and eventually wedges EXTTS when a PTP grandmaster
>>>> (ptp4l with hardware timestamping) runs concurrently with PHC
>>>> frequency discipline (any GPSDO calling clock_adjtime ADJ_FREQUENCY).
>>>> Root cause: igc_ptp_adjfine_i225() writes IGC_TIMINCA without holding
>>>> any lock. Every other PTP clock operation in igc_ptp.c (adjtime,
>>>> gettime, settime) holds tmreg_lock, but adjfine does not. When the
>>>> increment rate changes while the hardware is capturing a TX timestamp,
>>>> the captured value is corrupt. The driver retries for
>>>> IGC_PTP_TX_TIMEOUT (15s), then logs the timeout and frees the skb.
>>>> Repeated occurrences eventually prevent EXTTS from delivering events.
>>>> The attached reproducer (triggers in ~17 seconds on i226):
>>>> One thread calling clock_adjtime(ADJ_FREQUENCY) at ~200k/s on the
>>>> PHC, another sending UDP packets with SO_TIMESTAMPING requesting
>>>> hardware TX timestamps at ~100k/s. A Python reproducer is at:
>>>> https://github.com/bobvan/PePPAR-Fix/blob/main/tools/igc_tx_timeout_repro.py
>>>> At realistic rates (1 Hz adjfine from a GPSDO + ptp4l at 128 Hz
>>>> sync), the race triggers in ~30 minutes.
>>>> The attached patch holds ptp_tx_lock around the TIMINCA write and
>>>> skips the write if any TX timestamps are pending (tx_tstamp[i].skb
>>>> != NULL), returning -EBUSY. This doesn't fully close the hardware
>>>> race (a new TX capture can start between the check and the write),
>>>> but at realistic rates the residual probability gives ~25 year MTBF
>>>> vs ~30 minutes without the patch.
>>>> A complete fix would likely require either disabling TX timestamping
>>>> around TIMINCA writes (via TSYNCTXCTL), or making the timeout recovery
>>>> path more robust so a single corrupt timestamp doesn't wedge the
>>>> subsystem. We'd welcome guidance from the igc maintainers on the
>>>> preferred approach.
>>>> Tested on:
>>>> - Intel i226 (TimeHAT v5 board on Raspberry Pi 5)
>>>> - Kernel 6.12.62+rpt-rpi-2712 (Raspberry Pi OS)
>>>> - Intel out-of-tree igc driver 5.4.0-7642.46
>>>> - Stock upstream igc_ptp.c (same code, same bug)
>>>> Bob
>>>> ---
>>>> drivers/net/ethernet/intel/igc/igc_ptp.c | 18 +++++++++++++++++-
>>>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>>> diff --git a/drivers/net/ethernet/intel/igc/igc_ptp.c b/drivers/net/ethernet/intel/igc/igc_ptp.c
>>>> index XXXXXXX..XXXXXXX 100644
>>>> --- a/drivers/net/ethernet/intel/igc/igc_ptp.c
>>>> +++ b/drivers/net/ethernet/intel/igc/igc_ptp.c
>>>> @@ -47,8 +47,10 @@ static int igc_ptp_adjfine_i225(struct ptp_clock_info *ptp, long scaled_ppm)
>>>> {
>>>> struct igc_adapter *igc = container_of(ptp, struct igc_adapter,
>>>> ptp_caps);
>>>> struct igc_hw *hw = &igc->hw;
>>>> + unsigned long flags;
>>>> int neg_adj = 0;
>>>> u64 rate;
>>>> u32 inca;
>>>> + int i;
>>>> if (scaled_ppm < 0) {
>>>> neg_adj = 1;
>>>> @@ -63,7 +65,21 @@ static int igc_ptp_adjfine_i225(struct ptp_clock_info *ptp, long scaled_ppm)
>>>> if (neg_adj)
>>>> inca |= ISGN;
>>>> - wr32(IGC_TIMINCA, inca);
>>>> + /* Changing the clock increment rate while a TX timestamp is being
>>>> + * captured by the hardware can corrupt the timestamp, causing the
>>>> + * driver to report "Tx timestamp timeout" and eventually wedging
>>>> + * the EXTTS subsystem. Serialize with pending TX timestamps:
>>>> + * skip the rate change if any are in flight.
>>>> + */
>>>> + spin_lock_irqsave(&igc->ptp_tx_lock, flags);
>>>> + for (i = 0; i < IGC_MAX_TX_TSTAMP_REGS; i++) {
>>>> + if (igc->tx_tstamp[i].skb) {
>>>> + spin_unlock_irqrestore(&igc->ptp_tx_lock, flags);
>>>> + return -EBUSY;
>>>> + }
>>>> + }
>>>> + wr32(IGC_TIMINCA, inca);
>>>> + spin_unlock_irqrestore(&igc->ptp_tx_lock, flags);
>>>
>>> It's a bit weird solution, because in this case we may end up having no
>>> successful calls to adjfine with high amount of TX timestamp packets in flight. Another problem here is that access to timing registers is
>>> guarded by tmreg_lock, but here you use ptp_tx_lock, which protects
>>> queue.
>>>
>>> Were you able to recover "corrupted" time stamps to figure out why they
>>> are discarded?
>>>
>>>
>>>> return 0;
>>>> }
>>>> --
>>>> 2.39.2
>>
>>
>
^ permalink raw reply
* [syzbot] [net?] [bpf?] KASAN: slab-use-after-free Read in __sk_msg_recvmsg
From: syzbot @ 2026-04-02 0:49 UTC (permalink / raw)
To: andrii, ast, bpf, daniel, davem, edumazet, horms, jakub,
john.fastabend, kuba, linux-kernel, netdev, pabeni,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 93d04e76bcf1 Merge branch 'r8152-add-helper-functions-for-..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14fde46a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=71d49d824b43a0d9
dashboard link: https://syzkaller.appspot.com/bug?extid=431f9a9e3f5227fbb904
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11b9baba580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=152c5e26580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/953c48b40f73/disk-93d04e76.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/edb39d99bd41/vmlinux-93d04e76.xz
kernel image: https://storage.googleapis.com/syzbot-assets/656d4ad35e4a/bzImage-93d04e76.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+431f9a9e3f5227fbb904@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in __sk_msg_recvmsg+0x19b/0xe70 net/core/skmsg.c:431
Read of size 8 at addr ffff88807eeac2b0 by task syz.0.31/6071
CPU: 0 UID: 0 PID: 6071 Comm: syz.0.31 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xba/0x230 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
__sk_msg_recvmsg+0x19b/0xe70 net/core/skmsg.c:431
udp_bpf_recvmsg+0x196/0xac0 net/ipv4/udp_bpf.c:83
sock_recvmsg_nosec net/socket.c:1071 [inline]
sock_recvmsg+0x155/0x1b0 net/socket.c:1093
____sys_recvmsg+0x1e6/0x4a0 net/socket.c:2805
___sys_recvmsg+0x215/0x590 net/socket.c:2847
do_recvmmsg+0x334/0x800 net/socket.c:2942
__sys_recvmmsg net/socket.c:3016 [inline]
__do_sys_recvmmsg net/socket.c:3039 [inline]
__se_sys_recvmmsg net/socket.c:3032 [inline]
__x64_sys_recvmmsg+0x198/0x250 net/socket.c:3032
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4a3579c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4a365f2028 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 00007f4a35a16180 RCX: 00007f4a3579c819
RDX: 0000000000000012 RSI: 0000200000000400 RDI: 0000000000000003
RBP: 00007f4a35832c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000040000021 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f4a35a16218 R14: 00007f4a35a16180 R15: 00007ffda3b0e6c8
</TASK>
Allocated by task 6069:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__kmalloc_cache_noprof+0x31c/0x660 mm/slub.c:5380
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
alloc_sk_msg net/core/skmsg.c:525 [inline]
sk_psock_skb_ingress_self+0x5e/0x370 net/core/skmsg.c:627
sk_psock_verdict_apply net/core/skmsg.c:1062 [inline]
sk_psock_verdict_recv+0x7d9/0x8d0 net/core/skmsg.c:1260
udp_read_skb+0x5d9/0x6b0 net/ipv4/udp.c:2014
sk_psock_verdict_data_ready+0x12d/0x590 net/core/skmsg.c:1281
__udp_enqueue_schedule_skb+0xc4b/0x12e0 net/ipv4/udp.c:1745
__udp_queue_rcv_skb net/ipv4/udp.c:2311 [inline]
udp_queue_rcv_one_skb+0x831/0x1230 net/ipv4/udp.c:2401
__udp4_lib_mcast_deliver+0xad7/0xb70 net/ipv4/udp.c:2513
udp_rcv+0xcc2/0x24c0 net/ipv4/udp.c:2638
ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207
ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241
NF_HOOK+0x336/0x3c0 include/linux/netfilter.h:318
dst_input include/net/dst.h:480 [inline]
ip_sublist_rcv_finish+0x1f0/0x240 net/ipv4/ip_input.c:623
ip_list_rcv_finish net/ipv4/ip_input.c:667 [inline]
ip_sublist_rcv+0x5c6/0xa70 net/ipv4/ip_input.c:683
ip_list_rcv+0x3f1/0x450 net/ipv4/ip_input.c:717
__netif_receive_skb_list_ptype net/core/dev.c:6233 [inline]
__netif_receive_skb_list_core+0x7e5/0x810 net/core/dev.c:6280
__netif_receive_skb_list net/core/dev.c:6332 [inline]
netif_receive_skb_list_internal+0x995/0xcf0 net/core/dev.c:6423
netif_receive_skb_list+0x55/0x4b0 net/core/dev.c:6475
xdp_recv_frames net/bpf/test_run.c:269 [inline]
xdp_test_run_batch net/bpf/test_run.c:350 [inline]
bpf_test_run_xdp_live+0x1946/0x1cf0 net/bpf/test_run.c:379
bpf_prog_test_run_xdp+0x81c/0x1160 net/bpf/test_run.c:1397
bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4722
__sys_bpf+0x643/0x950 kernel/bpf/syscall.c:6246
__do_sys_bpf kernel/bpf/syscall.c:6341 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6339 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6339
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 6070:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6165 [inline]
kfree+0x1c1/0x630 mm/slub.c:6483
kfree_sk_msg include/linux/skmsg.h:418 [inline]
__sk_msg_recvmsg+0xc7e/0xe70 net/core/skmsg.c:491
udp_bpf_recvmsg+0x196/0xac0 net/ipv4/udp_bpf.c:83
sock_recvmsg_nosec net/socket.c:1071 [inline]
sock_recvmsg+0x155/0x1b0 net/socket.c:1093
____sys_recvmsg+0x1e6/0x4a0 net/socket.c:2805
___sys_recvmsg+0x215/0x590 net/socket.c:2847
do_recvmmsg+0x334/0x800 net/socket.c:2942
__sys_recvmmsg net/socket.c:3016 [inline]
__do_sys_recvmmsg net/socket.c:3039 [inline]
__se_sys_recvmmsg net/socket.c:3032 [inline]
__x64_sys_recvmmsg+0x198/0x250 net/socket.c:3032
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff88807eeac000
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 688 bytes inside of
freed 1024-byte region [ffff88807eeac000, ffff88807eeac400)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7eea8
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88813fea6dc0 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800100010 00000000f5000000 0000000000000000
head: 00fff00000000040 ffff88813fea6dc0 dead000000000100 dead000000000122
head: 0000000000000000 0000000800100010 00000000f5000000 0000000000000000
head: 00fff00000000003 ffffea0001fbaa01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd2820(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 176, tgid 176 (kworker/u8:7), ts 108779589894, free_ts 108254079914
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3481
new_slab mm/slub.c:3539 [inline]
refill_objects+0x331/0x3c0 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x2e6/0x730 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
__do_kmalloc_node mm/slub.c:5259 [inline]
__kmalloc_noprof+0x474/0x760 mm/slub.c:5272
kmalloc_noprof include/linux/slab.h:954 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
ieee802_11_parse_elems_full+0x159/0x2ab0 net/mac80211/parse.c:1051
ieee802_11_parse_elems net/mac80211/ieee80211_i.h:2496 [inline]
ieee80211_rx_mgmt_probe_beacon net/mac80211/ibss.c:1565 [inline]
ieee80211_ibss_rx_queued_mgmt+0x4ca/0x2ce0 net/mac80211/ibss.c:1596
ieee80211_iface_process_skb net/mac80211/iface.c:1757 [inline]
ieee80211_iface_work+0x845/0x1380 net/mac80211/iface.c:1811
cfg80211_wiphy_work+0x2ab/0x4a0 net/wireless/core.c:513
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
page last free pid 6064 tgid 6061 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1433 [inline]
__free_frozen_pages+0xc2b/0xdb0 mm/page_alloc.c:2978
__slab_free+0x263/0x2b0 mm/slub.c:5573
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x97/0x100 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:350
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4538 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
__do_kmalloc_node mm/slub.c:5259 [inline]
__kmalloc_noprof+0x316/0x760 mm/slub.c:5272
kmalloc_noprof include/linux/slab.h:954 [inline]
iovec_from_user+0x87/0x250 lib/iov_iter.c:1321
__import_iovec+0x163/0x7e0 lib/iov_iter.c:1375
import_iovec+0x73/0xa0 lib/iov_iter.c:1440
copy_msghdr_from_user net/socket.c:2522 [inline]
recvmsg_copy_msghdr net/socket.c:2771 [inline]
___sys_recvmsg+0x4bd/0x590 net/socket.c:2843
do_recvmmsg+0x334/0x800 net/socket.c:2942
__sys_recvmmsg net/socket.c:3016 [inline]
__do_sys_recvmmsg net/socket.c:3039 [inline]
__se_sys_recvmmsg net/socket.c:3032 [inline]
__x64_sys_recvmmsg+0x198/0x250 net/socket.c:3032
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff88807eeac180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88807eeac200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88807eeac280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88807eeac300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88807eeac380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH net-next 3/4] ethtool: strset: check nla_len overflow before nla_nest_end
From: Jakub Kicinski @ 2026-04-02 0:49 UTC (permalink / raw)
To: Hangbin Liu
Cc: Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Andrew Lunn, netdev, linux-kernel
In-Reply-To: <aczI7FfIScrKhBGQ@fedora>
On Wed, 1 Apr 2026 07:27:40 +0000 Hangbin Liu wrote:
> On Tue, Mar 31, 2026 at 06:46:37PM -0700, Jakub Kicinski wrote:
> > On Tue, 31 Mar 2026 11:56:13 +0800 Hangbin Liu wrote:
> > > + if (skb_tail_pointer(skb) - (unsigned char *)strings_attr > U16_MAX)
> > > + goto nla_put_failure;
> >
> > bit ugly, let's add a variant of nla_nest_end() which can return
> > an error on overflow (without the warning from patch 4) ?
>
> I was tried to not touch nla_nest_end() as it is used everywhere. But it makes
> sense to me to add a new function to check this. I'm not very good at naming,
> maybe `nla_nest_end_validate()` ? Or any other name if you have?
I was thinking nla_nest_end_check() to match the __must_check
attribute. But I also like nla_nest_end_safe()
_validate() is a little long but anything <=5 chars is fine.
^ permalink raw reply
* Re: [PATCH net v3] ipv6: fix data race in fib6_metric_set() using cmpxchg
From: patchwork-bot+netdevbpf @ 2026-04-02 0:50 UTC (permalink / raw)
To: Hangbin Liu
Cc: davem, dsahern, edumazet, kuba, pabeni, horms, jiayuan.chen,
dsahern, netdev, linux-kernel, feliu
In-Reply-To: <20260331-b4-fib6_metric_set-kmemleak-v3-1-88d27f4d8825@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 31 Mar 2026 12:17:18 +0800 you wrote:
> fib6_metric_set() may be called concurrently from softirq context without
> holding the FIB table lock. A typical path is:
>
> ndisc_router_discovery()
> spin_unlock_bh(&table->tb6_lock) <- lock released
> fib6_metric_set(rt, RTAX_HOPLIMIT, ...) <- lockless call
>
> [...]
Here is the summary with links:
- [net,v3] ipv6: fix data race in fib6_metric_set() using cmpxchg
https://git.kernel.org/netdev/net/c/ffb5a4843c5b
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 1/4] tools: ynl: ethtool: use doit instead of dumpit for per-device GET
From: Jakub Kicinski @ 2026-04-02 0:51 UTC (permalink / raw)
To: Hangbin Liu
Cc: Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Andrew Lunn, netdev, linux-kernel
In-Reply-To: <aczHkqj_0ErqCfXS@fedora>
On Wed, 1 Apr 2026 07:21:54 +0000 Hangbin Liu wrote:
> On Tue, Mar 31, 2026 at 06:50:28PM -0700, Jakub Kicinski wrote:
> > On Tue, 31 Mar 2026 11:56:11 +0800 Hangbin Liu wrote:
> > > +++ b/tools/net/ynl/pyynl/ethtool.py
> >
> > We have converted all the samples to selftests so this script is
> > the last piece of random "PoC" code we still have laying around.
> > Should we also move it to tests/ ?
> >
> > If there's a reason to keep it as is -- could you please add that reason
> > at the top of the file for my future self? I'm pretty sure I already
> > questioned this script in the past ;)
>
> I have no objection to this. Will you keep it as it is when moving it to
> tests/ ? Should I wait for your moving first?
Would you mind moving it as part of your series?
^ permalink raw reply
* Re: [PATCH net-next v7] selftests: net: add tests for PPP
From: Jakub Kicinski @ 2026-04-02 0:56 UTC (permalink / raw)
To: Qingfang Deng
Cc: Shuah Khan, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Felix Maurer, Sebastian Andrzej Siewior,
Matthieu Baerts (NGI0), linux-kernel, linux-kselftest, linux-ppp,
netdev, Paul Mackerras
In-Reply-To: <CALW65jahWApDnVmFReW+Y3HDxBEmCwzsT1oyh03SW7X5ry6PzA@mail.gmail.com>
On Wed, 1 Apr 2026 23:45:38 +0800 Qingfang Deng wrote:
> > # iperf3: error - unable to connect to server - server may have stopped running or use a different port, firewall issue, etc.: Network is unreachable
> > # TEST: PPPoE [FAIL]
> > not ok 1 selftests: net/ppp: pppoe.sh # exit=1
>
> It looks like pppoe-server fails to start. You may check the syslog to
> see what's going on.
Hm, we don't capture syslog automatically :S We capture stdout and
stderr
I'm not even sure there's something listening on syslog in virtme-ng
Is it possible to make the daemon log to stdout or a file and dump
that file to stdout on failure? Even if we fix the current issue
it will be quite inconvenient if we have to go into syslog every time
the test is failing. The test output should provide enough info to
debug failures.
^ permalink raw reply
* [PATCH] MAINTAINERS: Update email for Allison Henderson
From: Allison Henderson @ 2026-04-02 0:58 UTC (permalink / raw)
To: netdev; +Cc: pabeni, edumazet, rds-devel, kuba, horms, linux-rdma
Switch active email address to kernel.org alias
Signed-off-by: Allison Henderson <achender@kernel.org>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2ffd9d37d5..72e56bc8865c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22119,7 +22119,7 @@ S: Supported
F: drivers/infiniband/sw/rdmavt
RDS - RELIABLE DATAGRAM SOCKETS
-M: Allison Henderson <allison.henderson@oracle.com>
+M: Allison Henderson <achender@kernel.org>
L: netdev@vger.kernel.org
L: linux-rdma@vger.kernel.org
L: rds-devel@oss.oracle.com (moderated for non-subscribers)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] net: lapbether: handle NETDEV_PRE_TYPE_CHANGE
From: Eric Dumazet @ 2026-04-02 1:11 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Andrew Lunn, netdev, eric.dumazet,
syzbot+d8c285748fa7292580a9
In-Reply-To: <20260401135304.3629615-1-edumazet@google.com>
On Wed, Apr 1, 2026 at 6:53 AM Eric Dumazet <edumazet@google.com> 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>
> ---
> drivers/net/wan/lapbether.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c
> index f357a7ac70ac4756967730fa61c07258b4b3ac00..5c91160dd68cc1dfa4308d38fb111032206fae75 100644
> --- a/drivers/net/wan/lapbether.c
> +++ b/drivers/net/wan/lapbether.c
> @@ -473,6 +473,9 @@ static int lapbeth_device_event(struct notifier_block *this,
> if (lapbeth)
> lapbeth_free_device(lapbeth);
> break;
> + case NETDEV_PRE_TYPE_CHANGE:
> + /* Our underlying device type must not change. */
> + return NOTIFY_BAD;
I will send a v2, we need to guard this with lapbeth_get_x25_dev(dev)
pw-bot: changes-requested
^ 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