* Re: [PATCH net] amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN
From: patchwork-bot+netdevbpf @ 2026-07-21 16:20 UTC (permalink / raw)
To: Prashanth Kumar KR
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, stable, Shyam-sundar.S-k, patrick.oppenlander,
regressions
In-Reply-To: <20260709095006.3683940-1-prashanthkumar.k.r@amd.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Jul 2026 15:20:06 +0530 you wrote:
> From: Prashanth Kumar KR <PrashanthKumar.K.R@amd.com>
>
> MAC_AUTO_SW (VR_MII_DIG_CTRL1 bit 9) enables automatic XPCS speed
> mode switching after CL37 auto-negotiation and is only meaningful in
> SGMII MAC mode. The original code unconditionally set this bit on
> every call to xgbe_an37_set(), including when called from
> xgbe_an37_disable() with enable=false. This left MAC_AUTO_SW=1 after
> AN was disabled, causing the XPCS to autonomously switch speed from
> stale AN state during subsequent mode changes, breaking SGMII speed
> negotiation on 1G copper SFP modules.
>
> [...]
Here is the summary with links:
- [net] amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN
https://git.kernel.org/netdev/net/c/4bf22afe53a1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [RFC PATCH net-next 02/13] net: devmem: extend memory provider for knod
From: Taehee Yoo @ 2026-07-21 16:15 UTC (permalink / raw)
To: Mina Almasry
Cc: Alex Deucher, Alexei Starovoitov, amd-gfx, Andrew Lunn,
Andrii Nakryiko, Bill Wendling, bpf, Christian König,
Daniel Borkmann, David Airlie, David S. Miller, Donald Hunter,
dri-devel, Eduard Zingerman, Emil Tsalapatis, Eric Dumazet,
Felix Kuehling, Hoyeon Lee, Ilias Apalodimas, Jakub Kicinski,
Jesper Dangaard Brouer, Jiri Olsa, John Fastabend, Justin Stitt,
Kees Cook, Kumar Kartikeya Dwivedi, Leon Romanovsky,
linaro-mm-sig, linux-hardening, linux-kernel, linux-kselftest,
linux-media, linux-rdma, llvm, Mark Bloch, Martin KaFai Lau,
Michael Chan, Nathan Chancellor, netdev, Nick Desaulniers,
Paolo Abeni, Pavan Chebbi, Saeed Mahameed, Shuah Khan,
Simona Vetter, Simon Horman, Song Liu, Stanislav Fomichev,
Sumit Semwal, Tariq Toukan, Yonghong Song
In-Reply-To: <CAHS8izMU4gQCH2v0dcOFkjP6Sxj7RUvC8=Baet=+pFXG24qh7A@mail.gmail.com>
On Tue, Jul 21, 2026 at 4:44 AM Mina Almasry <almasrymina@google.com> wrote:
>
Hi Mina,
Thanks a lot for your review!
> On Sun, Jul 19, 2026 at 11:03 AM Taehee Yoo <ap420073@gmail.com> wrote:
> >
> > Extend the devmem memory-provider path so a knod accelerator can back a
> > NIC page_pool with accelerator-exported memory (dma-buf), letting the
> > NIC DMA received packets directly into accelerator memory.
> >
> > Signed-off-by: Taehee Yoo <ap420073@gmail.com>
>
> Changes look fine in general but I do not understand in the design how
> the page_pool not bound to rx queue would be used. Maybe elaborate on
> the design in the commit message or cover letter in the next
> iteration.
>
Sorry, this is not clear from the commit message or cover letter.
We added a custom provider type for page_pool that allocates GTT memory
- host memory that is also mapped to a GPU VA, which lets us copy between
VRAM and host without a separate staging buffer. So when the XDP verdict
is XDP_PASS, or on the IPsec path, this page_pool is used for the
allocation. To configure the page_pool with our KNOD backend, we
define mp_ops/priv in knod_core.c and set them directly as the
page_pool's mp_ops/priv, rather than going through netdev_rx_queue.
As a result, each combined channel has two page_pools: a NETMEM
page_pool created by the device driver to refill the RX ring through
the normal netdev_rx_queue path, and one CUSTOM_PROVIDER page_pool
created and managed by knod core for the XDP_PASS / IPsec allocations.
The latter is created per channel by knod core, so it is not bound
through netdev_rx_queue.
We will describe this distinction in the next revision.
> > (cherry picked from commit d511a8cb3e229f8f5cf060985880d45bd384db87)
>
> I guess remove unintended cherry-pick tag.
>
Yes, we will remove it.
> > ---
> > include/net/devmem.h | 58 +++++++++++++
> > include/net/netmem.h | 9 +++
> > include/net/page_pool/memory_provider.h | 4 +
> > include/net/page_pool/types.h | 23 +++++-
> > net/core/devmem.c | 103 +++++++++++++++++++-----
> > net/core/devmem.h | 7 +-
> > net/core/page_pool.c | 22 ++++-
> > 7 files changed, 198 insertions(+), 28 deletions(-)
> > create mode 100644 include/net/devmem.h
> >
> > diff --git a/include/net/devmem.h b/include/net/devmem.h
> > new file mode 100644
> > index 000000000000..f1c3895d7833
> > --- /dev/null
> > +++ b/include/net/devmem.h
>
> Try to keep only include/net/netmem.h and net/core/devmem.h rather
> than add an include/net/devmem.h
>
Thanks. We will keep the declarations in include/net/netmem.h and
> > @@ -0,0 +1,58 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/*
> > + * Device memory TCP support
> > + *
> > + * Authors: Mina Almasry <almasrymina@google.com>
> > + * Willem de Bruijn <willemb@google.com>
> > + * Kaiyuan Zhang <kaiyuanz@google.com>
> > + *
> > + */
> > +#ifndef _NET_DEVMEM_H
> > +#define _NET_DEVMEM_H
> > +
> > +#include <linux/dma-direction.h>
> > +#include <linux/err.h>
> > +#include <linux/types.h>
> > +
> > +struct device;
> > +struct dma_buf;
> > +struct dma_buf_attach_ops;
> > +struct net_device;
> > +struct net_devmem_dmabuf_binding;
> > +struct netlink_ext_ack;
> > +
> > +#if defined(CONFIG_NET_DEVMEM)
> > +struct net_devmem_dmabuf_binding *
> > +__net_devmem_binding_create(struct net_device *dev, struct device *dma_dev,
> > + struct dma_buf *dmabuf,
> > + enum dma_data_direction direction,
> > + const struct dma_buf_attach_ops *importer_ops,
> > + struct netlink_ext_ack *extack);
> > +int net_devmem_bind_dmabuf_to_queue_direct(struct net_device *dev, u32 rxq_idx,
> > + struct net_devmem_dmabuf_binding *binding);
> > +void net_devmem_unbind_dmabuf_direct(struct net_devmem_dmabuf_binding *binding);
> > +#else
> > +static inline struct net_devmem_dmabuf_binding *
> > +__net_devmem_binding_create(struct net_device *dev, struct device *dma_dev,
> > + struct dma_buf *dmabuf,
> > + enum dma_data_direction direction,
> > + const struct dma_buf_attach_ops *importer_ops,
> > + struct netlink_ext_ack *extack)
> > +{
> > + return ERR_PTR(-EOPNOTSUPP);
> > +}
> > +
> > +static inline int
> > +net_devmem_bind_dmabuf_to_queue_direct(struct net_device *dev, u32 rxq_idx,
> > + struct net_devmem_dmabuf_binding *binding)
> > +{
> > + return -EOPNOTSUPP;
> > +}
> > +
> > +static inline void
> > +net_devmem_unbind_dmabuf_direct(struct net_devmem_dmabuf_binding *binding)
> > +{
> > +}
> > +#endif
> > +
> > +#endif /* _NET_DEVMEM_H */
> > diff --git a/include/net/netmem.h b/include/net/netmem.h
> > index bccacd21b6c3..3ddfbd37500f 100644
> > --- a/include/net/netmem.h
> > +++ b/include/net/netmem.h
> > @@ -127,6 +127,15 @@ static inline void net_iov_init(struct net_iov *niov,
> > niov->type = type;
> > }
> >
> > +/* Global page index within the dma-buf, accounting for multi-chunk
> > + * scatter-gather layouts where each chunk owner's niovs start at 0.
> > + */
> > +static inline unsigned int net_iov_binding_idx(const struct net_iov *niov)
> > +{
> > + return (net_iov_owner(niov)->base_virtual >> PAGE_SHIFT) +
> > + net_iov_idx(niov);
> > +}
> > +
> > /* netmem */
> >
> > /**
> > diff --git a/include/net/page_pool/memory_provider.h b/include/net/page_pool/memory_provider.h
> > index 255ce4cfd975..4b58a9702fb7 100644
> > --- a/include/net/page_pool/memory_provider.h
> > +++ b/include/net/page_pool/memory_provider.h
> > @@ -23,6 +23,10 @@ bool net_mp_niov_set_dma_addr(struct net_iov *niov, dma_addr_t addr);
> > void net_mp_niov_set_page_pool(struct page_pool *pool, struct net_iov *niov);
> > void net_mp_niov_clear_page_pool(struct net_iov *niov);
> >
> > +void page_pool_provider_set_netmem(struct page_pool *pool, netmem_ref netmem,
> > + dma_addr_t addr);
> > +void page_pool_clear_pp_info(netmem_ref netmem);
> > +
> > int netif_mp_open_rxq(struct net_device *dev, unsigned int rxq_idx,
> > const struct pp_memory_provider_params *p,
> > struct netlink_ext_ack *extack);
> > diff --git a/include/net/page_pool/types.h b/include/net/page_pool/types.h
> > index 03da138722f5..3e866f249768 100644
> > --- a/include/net/page_pool/types.h
> > +++ b/include/net/page_pool/types.h
> > @@ -31,8 +31,16 @@
> > */
> > #define PP_FLAG_ALLOW_UNREADABLE_NETMEM BIT(3)
> >
> > +/* Driver-managed pool with a directly-supplied memory provider, not bound to a
> > + * netdev rx queue. Setting this flag requires page_pool_params.mp_ops and
> > + * .mp_priv to both be set.
> > + */
> > +#define PP_FLAG_CUSTOM_MEMORY_PROVIDER BIT(4)
> > +
> > #define PP_FLAG_ALL (PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV | \
> > - PP_FLAG_SYSTEM_POOL | PP_FLAG_ALLOW_UNREADABLE_NETMEM)
> > + PP_FLAG_SYSTEM_POOL | \
> > + PP_FLAG_ALLOW_UNREADABLE_NETMEM | \
> > + PP_FLAG_CUSTOM_MEMORY_PROVIDER)
> >
> > /* Index limit to stay within PP_DMA_INDEX_BITS for DMA indices */
> > #define PP_DMA_INDEX_LIMIT XA_LIMIT(1, BIT(PP_DMA_INDEX_BITS) - 1)
> > @@ -54,11 +62,11 @@
> > * would have to take a slower code path.
> > */
> > #if PAGE_SIZE >= SZ_64K
> > -#define PP_ALLOC_CACHE_REFILL 4
> > +#define PP_ALLOC_CACHE_REFILL 256
> > #elif PAGE_SIZE >= SZ_16K
> > -#define PP_ALLOC_CACHE_REFILL 16
> > +#define PP_ALLOC_CACHE_REFILL 1024
> > #else
> > -#define PP_ALLOC_CACHE_REFILL 64
> > +#define PP_ALLOC_CACHE_REFILL 4096
> > #endif
> >
>
> I'm guessing this is just a workaround/optimization. You need a proper
> change for this, maybe make it configurable arguments when creating a
> pp or something.
>
Agreed. We will rework this as a per-pool setting instead of changing
the global page_pool cache size.
> > #define PP_ALLOC_CACHE_SIZE (PP_ALLOC_CACHE_REFILL * 2)
> > @@ -67,6 +75,8 @@ struct pp_alloc_cache {
> > netmem_ref cache[PP_ALLOC_CACHE_SIZE];
> > };
> >
> > +struct memory_provider_ops;
> > +
> > /**
> > * struct page_pool_params - page pool parameters
> > * @fast: params accessed frequently on hotpath
> > @@ -83,6 +93,9 @@ struct pp_alloc_cache {
> > * @queue_idx: queue idx this page_pool is being created for.
> > * @flags: PP_FLAG_DMA_MAP, PP_FLAG_DMA_SYNC_DEV, PP_FLAG_SYSTEM_POOL,
> > * PP_FLAG_ALLOW_UNREADABLE_NETMEM.
> > + * @mp_ops: driver-supplied memory provider for a pool not bound to a
> > + * netdev rx queue (NULL to use rxq->mp_params instead)
> > + * @mp_priv: context passed to @mp_ops
> > */
> > struct page_pool_params {
> > struct_group_tagged(page_pool_params_fast, fast,
> > @@ -99,6 +112,8 @@ struct page_pool_params {
> > struct net_device *netdev;
> > unsigned int queue_idx;
> > unsigned int flags;
> > + const struct memory_provider_ops *mp_ops;
> > + void *mp_priv;
> > /* private: used by test code only */
> > void (*init_callback)(netmem_ref netmem, void *arg);
> > void *init_arg;
> > diff --git a/net/core/devmem.c b/net/core/devmem.c
> > index 957d6b96216b..9e21cffc9643 100644
> > --- a/net/core/devmem.c
> > +++ b/net/core/devmem.c
> > @@ -121,12 +121,9 @@ void net_devmem_free_dmabuf(struct net_iov *niov)
> > gen_pool_free(binding->chunk_pool, dma_addr, PAGE_SIZE);
> > }
> >
> > -void net_devmem_unbind_dmabuf(struct net_devmem_dmabuf_binding *binding)
> > +static void
> > +net_devmem_binding_unpublish(struct net_devmem_dmabuf_binding *binding)
> > {
> > - struct netdev_rx_queue *rxq;
> > - unsigned long xa_idx;
> > - unsigned int rxq_idx;
> > -
> > xa_erase(&net_devmem_dmabuf_bindings, binding->id);
> >
> > /* Ensure no tx net_devmem_lookup_dmabuf() are in flight after the
> > @@ -136,6 +133,15 @@ void net_devmem_unbind_dmabuf(struct net_devmem_dmabuf_binding *binding)
> >
> > if (binding->list.next)
> > list_del(&binding->list);
> > +}
> > +
> > +void net_devmem_unbind_dmabuf(struct net_devmem_dmabuf_binding *binding)
> > +{
> > + struct netdev_rx_queue *rxq;
> > + unsigned long xa_idx;
> > + unsigned int rxq_idx;
> > +
> > + net_devmem_binding_unpublish(binding);
> >
> > xa_for_each(&binding->bound_rxqs, xa_idx, rxq) {
> > const struct pp_memory_provider_params mp_params = {
> > @@ -151,6 +157,47 @@ void net_devmem_unbind_dmabuf(struct net_devmem_dmabuf_binding *binding)
> > percpu_ref_kill(&binding->ref);
> > }
> >
> > +/* Bind/unbind variants for in-kernel offload importers that drive the rx
> > + * queue lifecycle themselves. The mp_params are poked directly, without the
> > + * tcp-data-split/XDP guards or the queue reconfigure that the netlink control
> > + * plane applies through netif_mp_open_rxq()/netif_mp_close_rxq().
> > + */
> > +int net_devmem_bind_dmabuf_to_queue_direct(struct net_device *dev, u32 rxq_idx,
> > + struct net_devmem_dmabuf_binding *binding)
> > +{
>
> The LLM says in this function you need to check if the queue is
> already bound to a devmem tcp memory provider.
>
Right. We will reject the bind if the RX queue already has a memory
provider.
Thanks a lot!
Taehee Yoo
> --
> Thanks,
> Mina
^ permalink raw reply
* Re: [RESEND PATCH] net/core: consolidate RPS dispatch into netif_rps() helpers
From: Jemmy Wong @ 2026-07-21 16:05 UTC (permalink / raw)
To: Jakub Kicinski, pabeni
Cc: Jemmy Wong, netdev, linux-kernel, andrew+netdev, davem, edumazet,
horms
In-Reply-To: <20260720162518.38414fa0@kernel.org>
> On Jul 21, 2026, at 7:25 AM, Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 7 Jul 2026 23:48:55 +0800 Jemmy Wong wrote:
>> The RPS steering logic in netif_rx_internal(), netif_receive_skb_internal()
>> and netif_receive_skb_list_internal() was open-coded three times, each with
>> its own #ifdef CONFIG_RPS block and manual rcu_read_lock()/unlock() pairs.
>>
>> Factor it into two helpers, netif_rps() for the single-skb path and
>> netif_rps_list() for the list path, and switch the callers to
>> guard(rcu)/scoped_guard(rcu). A new internal NET_RX_UNHANDLED sentinel lets
>> a helper report "RPS did not take this skb" so the caller falls back to the
>> local enqueue / __netif_receive_skb() path; it never escapes to callers.
>>
>> netif_rps_list() keeps the early static_branch_unlikely(&rps_needed) bail
>> out so the list is not needlessly walked and re-spliced when RPS is
>> compiled in but disabled.
>>
>> No functional change intended.
>
> You haven't read Paolo's reply, please go away.
Hi Jakub,
Apologies for the confusion — I am new to the netdev subsystem and
may have handled the process incorrectly.
I did read Paolo's reply and sent v2 [1] the following day to address
his two concerns:
1. Dropped guard()/scoped_guard() in favour of explicit
rcu_read_lock()/rcu_read_unlock() per the cleanup.h guidance [2].
2. Moved the RCU section inside the static_branch_unlikely() check so
the hot path (!rps_needed) acquires no lock. Verified with objdump
and bloat-o-meter that the fast path is instruction-identical to base.
I should have replied here first before posting v2 — apologies for
that process mistake.
After re-reading the maintainer-netdev.rst guide I also noticed:
- v2 subject is missing the target tree prefix (should be
"[PATCH net-next v2]").
- The patch is a standalone refactoring with no functional change,
which the guide discourages [3]. If it does not carry enough value
on its own, I am happy to drop it or fold it into a future
functional change.
[1] https://lore.kernel.org/all/20260711121009.76842-1-jemmywong512@gmail.com/
[2] https://elixir.bootlin.com/linux/v7.1.2/source/Documentation/process/maintainer-netdev.rst#L400
[3] https://elixir.bootlin.com/linux/v7.1.2/source/Documentation/process/maintainer-netdev.rst#L416
Thanks,
Jemmy Wong
^ permalink raw reply
* Re: [PATCH net] net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()
From: Paolo Abeni @ 2026-07-21 16:02 UTC (permalink / raw)
To: Alexandra Winter, Hidayath Khan, davem, edumazet, kuba
Cc: horms, linux-s390, netdev, linux-kernel, twinkler, heiko.carstens,
gor, agordeev, borntraeger, svens
In-Reply-To: <fff72695-88b5-4ba5-b1f4-f70a2b02ed1b@linux.ibm.com>
On 7/21/26 3:54 PM, Alexandra Winter wrote:
> On 09.07.26 21:17, Hidayath Khan wrote:
>> afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC.
>> If the allocation fails, nsk is NULL.
>>
>> The connection-refused path is entered when the listen state check
>> fails, the accept backlog is full, or nsk is NULL. The code
>> unconditionally calls iucv_sock_kill(nsk) in that path.
>>
>> iucv_sock_kill() does not accept a NULL socket pointer and immediately
>> dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL,
>> calling iucv_sock_kill(nsk) results in a NULL pointer dereference.
>>
>> Only call iucv_sock_kill() when a child socket was successfully
>> allocated.
>>
>> Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport")
>> Cc: stable@vger.kernel.org
>> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
>> Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com>
>> ---
>> net/iucv/af_iucv.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
>> index fed240b453bd..f5b1ec44b6ae 100644
>> --- a/net/iucv/af_iucv.c
>> +++ b/net/iucv/af_iucv.c
>> @@ -1872,7 +1872,8 @@ static int afiucv_hs_callback_syn(struct sock *sk, struct sk_buff *skb)
>> afiucv_swap_src_dest(skb);
>> trans_hdr->flags = AF_IUCV_FLAG_SYN | AF_IUCV_FLAG_FIN;
>> err = dev_queue_xmit(skb);
>> - iucv_sock_kill(nsk);
>> + if (nsk)
>> + iucv_sock_kill(nsk);
>> bh_unlock_sock(sk);
>> goto out;
>> }
>>
>> base-commit: 262b2eac463d880a664cf92af1107b4f9d84ad37
>
>
> Gentle ping to netdev maintainers:
> Did this one get lost in the overflow?
> It is all green in patchwork. Is there something you need us to do?
> Should we re-send it?
> I don't see this as urgent or especially dangerous.
It's still alive in PW. Our backlog is unusually huge due to an
unfortunate sequence of season holidays and conferences, but hopefully
it should get back to normality someday in the future :)
/P
^ permalink raw reply
* Re: [PATCH net v2] ila: reload IPv6 header after pskb_may_pull in checksum adjust
From: Simon Horman @ 2026-07-21 16:03 UTC (permalink / raw)
To: Michael Bommarito
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Antoine Tenart, Tom Herbert, netdev, linux-kernel, stable
In-Reply-To: <20260714114903.3763420-1-michael.bommarito@gmail.com>
On Tue, Jul 14, 2026 at 07:49:03AM -0400, Michael Bommarito wrote:
> ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling
> pskb_may_pull(). On a non-linear skb whose transport header sits in a page
> fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head()
> and free the old skb head, leaving ip6h dangling; the following
> get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator()
> uses ip6h (and the iaddr derived from it) again after the csum-adjust
> call and additionally writes the new locator through that pointer.
>
> Impact: a remote IPv6 packet routed through a configured ILA
> csum-adjust-transport route or receive-side mapping triggers a
> slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or
> mapping requires CAP_NET_ADMIN to configure, but trigger packets are
> unauthenticated once it exists.
>
> Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport()
> before the csum-diff read. In ila_update_ipv6_locator() only the
> ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in
> that case alone before the destination-address write; the neutral-map
> modes never pull and keep their cached pointers.
>
> Fixes: 33f11d16142b ("ila: Create net/ipv6/ila directory")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> v2: In ila_update_ipv6_locator() reload ip6h/iaddr only in the
> ILA_CSUM_ADJUST_TRANSPORT case instead of unconditionally, per
> Antoine Tenart's review; the neutral-map modes never pull the skb,
> so their cached pointers remain valid.
> v1: https://lore.kernel.org/netdev/20260711150648.2915106-1-michael.bommarito@gmail.com/
>
> Evidence: a KUnit case on UML+KASAN drives ila_update_ipv6_locator()
> with a non-linear skb whose transport header sits in a fragment, so the
> pskb_may_pull() in ila_csum_adjust_transport() reallocates the head.
> Stock: BUG: KASAN: slab-use-after-free in ila_update_ipv6_locator, Read of
> size 4 (the stale ip6h/iaddr). Patched: both the valid-linear control and
> the fragmented case pass, KASAN-clean. Built clean, no new warnings.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next] net/tcp: Prevent inlining tcp_syn_ack_timeout()
From: Paolo Abeni @ 2026-07-21 16:03 UTC (permalink / raw)
To: Jakub Kicinski, edumazet
Cc: Emil Tsalapatis, netdev, ncardwell, kuniyu, davem
In-Reply-To: <20260721081240.1b88db50@kernel.org>
On 7/21/26 5:12 PM, Jakub Kicinski wrote:
> On Tue, 21 Jul 2026 15:24:52 +0200 Paolo Abeni wrote:
>> On 7/8/26 8:08 PM, Emil Tsalapatis wrote:
>>> The tcp_syn_ack_timeout() function gets inlined by Clang,
>>> preventing tracing. Since the call is not in the fast
>>> path, prevent it from being inlined.
>>>
>>> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
>>> ---
>>> net/ipv4/tcp_timer.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
>>> index bf171b5e1eb3..f7215d53bbda 100644
>>> --- a/net/ipv4/tcp_timer.c
>>> +++ b/net/ipv4/tcp_timer.c
>>> @@ -748,7 +748,7 @@ static void tcp_write_timer(struct timer_list *t)
>>> sock_put(sk);
>>> }
>>>
>>> -void tcp_syn_ack_timeout(const struct request_sock *req)
>>> +noinline_for_tracing void tcp_syn_ack_timeout(const struct request_sock *req)
>>> {
>>> struct net *net = read_pnet(&inet_rsk(req)->ireq_net);
>>>
>>
>> What's the point of tracing such function? It just increment a mib. If
>> you want to discriminate between TFO and non TFO syn ack timeout,
>> possibly adding another MIB counter and incrementing it in
>> tcp_fastopen_synack_timer() would be better???
>
> FWIW we seem to capture the 5 tuple when it happens, not just mib
> counter. Internal commit (form 2019) just says we want to know when
> syn-ack is blackholed, unclear under what conditions this happens.
Thanks for the context infos. I'm fine with the patch as-is.
/P
^ permalink raw reply
* [GIT PULL] bluetooth 2026-07-21
From: Luiz Augusto von Dentz @ 2026-07-21 16:02 UTC (permalink / raw)
To: davem, kuba; +Cc: linux-bluetooth, netdev
The following changes since commit e13caf1c26587434f0b768193100440939c0fb91:
Merge tag 'net-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2026-07-17 10:25:13 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-07-21
for you to fetch changes up to df541cd485ff80a5ddc579d99687bc7506df9851:
Bluetooth: btusb: validate Realtek vendor event length (2026-07-20 17:41:28 -0400)
----------------------------------------------------------------
bluetooth pull request for net:
- hci_sync: Protect UUID list traversal
- RFCOMM: Fix session UAF in set_termios
- btusb: validate Realtek vendor event length
----------------------------------------------------------------
Chengfeng Ye (2):
Bluetooth: hci_sync: Protect UUID list traversal
Bluetooth: RFCOMM: Fix session UAF in set_termios
Pengpeng Hou (1):
Bluetooth: btusb: validate Realtek vendor event length
drivers/bluetooth/btusb.c | 4 +++-
include/net/bluetooth/rfcomm.h | 3 +++
net/bluetooth/hci_sync.c | 13 +++++++++++--
net/bluetooth/rfcomm/core.c | 17 +++++++++++++++++
net/bluetooth/rfcomm/tty.c | 7 +++----
5 files changed, 37 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: [PATCH net] packet: use a consistent hard_header_len in send paths
From: Daniel Zahka @ 2026-07-21 16:01 UTC (permalink / raw)
To: Qihang, netdev
Cc: willemdebruijn.kernel, davem, edumazet, kuba, pabeni, horms,
stable
In-Reply-To: <20260721084935.12312-1-q.h.hack.winter@gmail.com>
On 7/21/26 4:49 AM, Qihang wrote:
> packet_snd() and tpacket_snd() read dev->hard_header_len multiple times
> while building an skb. Device reconfiguration can change this value
> concurrently, for example through bonding device type changes.
>
> For SOCK_RAW, packet_snd() stores the first value in reserve, later
> allocates headroom using LL_RESERVED_SPACE(dev), and then subtracts
> reserve from the skb headroom. If hard_header_len decreases between the
> reads, the skb can be allocated with less headroom than reserve, moving
> skb->data before skb->head. The subsequent skb_copy_datagram_from_iter()
> can then attempt an out-of-bounds copy. Hardened usercopy catches this as
> a kernel memory overwrite attempt.
>
Wouldn't there be a similar issue in the SOCK_DGRAM path with
dev_hard_header() calling skb_push() after packet_alloc_skb()?
^ permalink raw reply
* Re: [PATCH net-next v6 7/7] r8169: fix RTL8116af can not enter s0idle and c10
From: Jakub Kicinski @ 2026-07-21 15:57 UTC (permalink / raw)
To: javen
Cc: hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, pabeni,
maxime.chevallier, horms, netdev, linux-kernel, daniel, linux,
enelsonmoore, daniel
In-Reply-To: <20260709100237.541-8-javen_xu@realsil.com.cn>
On Thu, 9 Jul 2026 18:02:36 +0800 javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> RTL8116AF is a multi-function device. Functions 2 to 7 are hidden from
> the PCI core and return an all-ones response when their vendor ID is read,
> so they are not enumerated as normal PCI functions.
>
> However, these hidden functions can still affect platform power
> management. If they are left in D0 or keep ASPM disabled, the platform may
> fail to enter the low-power s0ix state and the CPU package may fail to
> enter Package C10.
>
> Put functions 2 to 7 into D3hot and enable ASPM on their PCIe link control
> register. Since these functions are hidden, access their configuration
> space through pci_bus_read_config_dword() / pci_bus_write_config_dword()
> using the same slot and the target function numbers.
>
> Ignore functions that return a PCI error response when reading their
> configuration space.
drivers/net/ethernet/realtek/r8169_main.c:3803:29: warning: invalid assignment: |=
drivers/net/ethernet/realtek/r8169_main.c:3803:29: left side has type unsigned short
drivers/net/ethernet/realtek/r8169_main.c:3803:29: right side has type restricted pci_power_t
--
pw-bot: cr
^ permalink raw reply
* [PATCH 7.1 0184/2077] uaccess: fix ignored_trailing logic in copy_struct_to_user()
From: Greg Kroah-Hartman @ 2026-07-21 14:57 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dmitry Safonov, Dmitry Safonov,
Francesco Ruggeri, Salam Noureddine, David Ahern, David S. Miller,
Michal Luczaj, David Wei, Luiz Augusto von Dentz,
Luiz Augusto von Dentz, Marcel Holtmann, Xin Long, Eric Dumazet,
Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn, Neal Cardwell,
Jakub Kicinski, Simon Horman, Aleksa Sarai, Christian Brauner,
Kees Cook, netdev, linux-bluetooth, linux-kernel,
Stefan Metzmacher, Aleksa Sarai, Sasha Levin
In-Reply-To: <20260721152552.646164743@linuxfoundation.org>
7.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <metze@samba.org>
[ Upstream commit 4911de3145a797389577abfdf9a5185d36cc18d7 ]
Currently all callers pass ignored_trailing=NULL, but I have
code that will make use of.
Now it actually behaves like documented:
* If @usize < @ksize, then the kernel is trying to pass userspace a newer
struct than it supports. Thus we only copy the interoperable portions
(@usize) and ignore the rest (but @ignored_trailing is set to %true if
any of the trailing (@ksize - @usize) bytes are non-zero).
Fixes: 424a55a4a908 ("uaccess: add copy_struct_to_user helper")
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Dmitry Safonov <dima@arista.com>
Cc: Francesco Ruggeri <fruggeri@arista.com>
Cc: Salam Noureddine <noureddine@arista.com>
Cc: David Ahern <dsahern@kernel.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Michal Luczaj <mhal@rbox.co>
Cc: David Wei <dw@davidwei.uk>
Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Xin Long <lucien.xin@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Kuniyuki Iwashima <kuniyu@google.com>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Simon Horman <horms@kernel.org>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Christian Brauner <brauner@kernel.org>
CC: Kees Cook <keescook@chromium.org>
Cc: netdev@vger.kernel.org
Cc: linux-bluetooth@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Link: https://patch.msgid.link/71f69442410c1186ed8ce6d5b4b9d4a5a70edbad.1775576651.git.metze@samba.org
Reviewed-by: Aleksa Sarai <aleksa@amutable.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/uaccess.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 56328601218c5a..09a09cc4aac274 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -510,7 +510,7 @@ copy_struct_to_user(void __user *dst, size_t usize, const void *src,
return -EFAULT;
}
if (ignored_trailing)
- *ignored_trailing = ksize < usize &&
+ *ignored_trailing = usize < ksize &&
memchr_inv(src + size, 0, rest) != NULL;
/* Copy the interoperable parts of the struct. */
if (copy_to_user(dst, src, size))
--
2.53.0
^ permalink raw reply related
* [PATCH 7.1 0185/2077] sockptr: fix usize check in copy_struct_from_sockptr() for user pointers
From: Greg Kroah-Hartman @ 2026-07-21 14:57 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Dmitry Safonov, Dmitry Safonov,
Francesco Ruggeri, Salam Noureddine, David Ahern, David S. Miller,
Michal Luczaj, David Wei, Luiz Augusto von Dentz,
Luiz Augusto von Dentz, Marcel Holtmann, Xin Long, Eric Dumazet,
Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn, Neal Cardwell,
Jakub Kicinski, Simon Horman, Aleksa Sarai, Christian Brauner,
Kees Cook, netdev, linux-bluetooth, linux-kernel,
Stefan Metzmacher, Aleksa Sarai, Sasha Levin
In-Reply-To: <20260721152552.646164743@linuxfoundation.org>
7.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Metzmacher <metze@samba.org>
[ Upstream commit db0493512931fe1e5a71612e6a358df1aa22d80c ]
copy_struct_from_user will never hit the check_zeroed_user() call
and will never return -E2BIG if new userspace passed new bits in a
larger structure than the current kernel structure.
As far as I can there are no critical/related uapi changes in
- include/net/bluetooth/bluetooth.h and net/bluetooth/sco.c
after the use of copy_struct_from_sockptr in v6.13-rc3
- include/uapi/linux/tcp.h and net/ipv4/tcp_ao.c
after the use of copy_struct_from_sockptr in v6.6-rc1
So that new callers will get the correct behavior from the start.
Fixes: 4954f17ddefc ("net/tcp: Introduce TCP_AO setsockopt()s")
Fixes: ef84703a911f ("net/tcp: Add TCP-AO getsockopt()s")
Fixes: faadfaba5e01 ("net/tcp: Add TCP_AO_REPAIR")
Fixes: 3e643e4efa1e ("Bluetooth: Improve setsockopt() handling of malformed user input")
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Dmitry Safonov <dima@arista.com>
Cc: Francesco Ruggeri <fruggeri@arista.com>
Cc: Salam Noureddine <noureddine@arista.com>
Cc: David Ahern <dsahern@kernel.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Michal Luczaj <mhal@rbox.co>
Cc: David Wei <dw@davidwei.uk>
Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Xin Long <lucien.xin@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Kuniyuki Iwashima <kuniyu@google.com>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Simon Horman <horms@kernel.org>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Christian Brauner <brauner@kernel.org>
CC: Kees Cook <keescook@chromium.org>
Cc: netdev@vger.kernel.org
Cc: linux-bluetooth@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Link: https://patch.msgid.link/cfaedbc33ae9d36adaabf04fa79424f30ff1efdd.1775576651.git.metze@samba.org
Reviewed-by: Aleksa Sarai <aleksa@amutable.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/sockptr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/sockptr.h b/include/linux/sockptr.h
index 3e6c8e9d67aef6..ba88f4d78c1b16 100644
--- a/include/linux/sockptr.h
+++ b/include/linux/sockptr.h
@@ -91,7 +91,7 @@ static inline int copy_struct_from_sockptr(void *dst, size_t ksize,
size_t rest = max(ksize, usize) - size;
if (!sockptr_is_kernel(src))
- return copy_struct_from_user(dst, ksize, src.user, size);
+ return copy_struct_from_user(dst, ksize, src.user, usize);
if (usize < ksize) {
memset(dst + size, 0, rest);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 net] gre: fix ERSPAN o_flags race/corruption in xmit and fill_info
From: Eric Dumazet @ 2026-07-21 15:37 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Ido Schimmel, netdev, eric.dumazet, stable
In-Reply-To: <20260720135132.3957146-1-edumazet@google.com>
On Mon, Jul 20, 2026 at 3:51 PM Eric Dumazet <edumazet@google.com> wrote:
>
> For IPv4 ERSPAN:
> In erspan_xmit(), the driver clears IP_TUNNEL_SEQ_BIT (for version 0)
> and IP_TUNNEL_KEY_BIT directly in the shared tunnel->parms.o_flags
> structure. Since transmit paths can run locklessly and concurrently,
> this leads to a data race.
>
> Furthermore, modifying tunnel->parms.o_flags permanently alters the
> tunnel configuration. To work around this, erspan_fill_info() (which
> reports config to userspace) was setting IP_TUNNEL_KEY_BIT back. If
> erspan_fill_info (running under RTNL) and erspan_xmit (running locklessly)
> race, erspan_xmit might see IP_TUNNEL_KEY_BIT set when it shouldnt,
> leading to GRE header corruption (injecting a key field into the ERSPAN
> GRE header).
>
> Fix this by:
> 1) Snapshotting tunnel->parms.o_flags onto the stack in ipgre_xmit(),
> gre_tap_xmit(), and __gre6_xmit(), and computing the GRE header length via
> gre_calc_hlen(flags) instead of reading tunnel->tun_hlen. This eliminates
> TOCTOU races between flags, offload checks, and header length.
> Note: Since tunnel->tun_hlen is no longer used in fast path xmit, it could be
> removed altogether in net-next.
> 2) Using local flags in erspan_xmit(), clearing IP_TUNNEL_CSUM_BIT and
> IP_TUNNEL_KEY_BIT (and IP_TUNNEL_SEQ_BIT for v0) before passing them to
> __gre_xmit().
> 3) Removing the racy modification of t->parms.o_flags in erspan_fill_info().
> 4) Forcing IP_TUNNEL_KEY_BIT in the reported flags for ERSPAN locally
> in ipgre_fill_info().
>
> For IPv6 ERSPAN:
> ip6erspan_tunnel_xmit() was locklessly clearing IP_TUNNEL_KEY_BIT in
> t->parms.o_flags even though it does not use these flags for building
> the GRE header (it uses local flags). This permanently corrupts the
> configuration and races with ip6gre_fill_info() which reads it.
>
> Remove the redundant and racy modification.
> This should remove false sharing in a fast path.
>
> Add const qualifiers in ipgre_fill_info(), erspan_fill_info()
> and ip6gre_fill_info() to clarify that these methods are not
> supposed to write any live parameters.
>
> Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
> Fixes: ee496694b9ee ("ip_gre: do not report erspan version on GRE interface")
> Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> v2: addressed Sashiko and Ido feedback.
> v1: https://lore.kernel.org/netdev/20260615140333.3161072-1-edumazet@google.com/
Sashiko said:
<quote>
Does this code generate malformed GRE headers for ERSPAN if the sequence bit
is missing from the output flags?
erspan_validate() permits configurations where the sequence bit is present in
the input flags but missing from the output flags. In that case, the snapshot
of the flags lacks IP_TUNNEL_SEQ_BIT.
After clearing IP_TUNNEL_CSUM_BIT and IP_TUNNEL_KEY_BIT, if IP_TUNNEL_SEQ_BIT
is also missing:
net/ipv4/ip_gre.c:__gre_xmit() {
...
gre_build_header(skb, gre_calc_hlen(flags),
...
}
gre_calc_hlen(flags) will evaluate to 4 bytes instead of the 8 bytes required
by the ERSPAN protocol. Before this patch, the hardcoded tunnel->tun_hlen
ensured an 8-byte header for ERSPAN.
Could this result in structurally malformed packets being transmitted?
</quote>
What a mess.
pw-bot: cr
I will squash the following:
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 442a2c9513e84e84013b4a6d447dd5e243428c5c..e102c378eeb5f0e6e9e6f710db1e05826e0fb070
100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -739,11 +739,13 @@ static netdev_tx_t erspan_xmit(struct sk_buff *skb,
tunnel->index,
truncate, true);
proto = htons(ETH_P_ERSPAN);
+ __set_bit(IP_TUNNEL_SEQ_BIT, flags);
} else if (tunnel->erspan_ver == 2) {
erspan_build_header_v2(skb, ntohl(tunnel->parms.o_key),
tunnel->dir, tunnel->hwid,
truncate, true);
proto = htons(ETH_P_ERSPAN2);
+ __set_bit(IP_TUNNEL_SEQ_BIT, flags);
} else {
goto free_skb;
}
^ permalink raw reply
* Re: [PATCH bpf-next v5 8/8] selftests: net: add test for XDP_PASS skb checksum invalidation
From: Jakub Kicinski @ 2026-07-21 15:27 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Lorenzo Bianconi, Donald Hunter, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Andrew Lunn, Tony Nguyen, Przemek Kitszel, Alexander Lobakin,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Shuah Khan,
Maciej Fijalkowski, Jonathan Corbet, Shuah Khan,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Vladimir Vdovin,
Jakub Sitnicki, netdev, bpf, intel-wired-lan, linux-kselftest,
linux-doc
In-Reply-To: <al53WS9FMTnu7tBI@devvm7509.cco0.facebook.com>
On Mon, 20 Jul 2026 12:32:55 -0700 Stanislav Fomichev wrote:
> > > (although for gve I might be wrong, there is also gve_rx_skb_csum that only
> > > does UNNECESSARY).
> > >
> > > I'd wait for Jakub to chime in, but it feels like we should just document
> > > what we currently do as a recommended approach: for the drivers
> > > that support COMPLETE, do not report it when the bpf program is attached.
> > > Both NONE and UNNECESSARY are ok.
> >
> > I am not completely sure the UNNECESSARY case is different from the COMPLETE
> > one. What are we supposed to do if the driver reports UNNECESSARY and the ebpf
> > program modifies some fields covered by the rx-checksum?
>
> For unnecessary, I think the safe expectation is that the bpf program
> will update the value of the checksum in the packet if it touches the data?
Documenting as expected behavior which no driver currently follows
is a bit silly. I thought the ask was to sketch out the plan of
explicitly updating/invalidating the checksum even if we don't
implement it today?
> > > Also, did you run this test on real HW? NIPA now has HW tests, maybe it
> > > makes sense to route this series via net-next to get the real coverage?
> >
> > What about splitting this series and have two different series:
> > - bpf-next: add xdp rx kfunc and related selftest
> > - net-next: add kselftest for the driver expected behaviour.
> >
> > What do you think?
>
> I'd post everything to net-next to get the HW coverage. Once you get all
> the acks we can ask the maintainers' guidance.
+1, and please add proper tests for the real drivers exercising the
kfunc with traffic (would be good to try to send a non-TCP/UDP frame
to try to cajole the driver into using COMPLETE).
^ permalink raw reply
* [PATCH 1/1] xfrm: avoid lock inversion in nat keepalive work
From: Ren Wei @ 2026-07-21 15:25 UTC (permalink / raw)
To: netdev
Cc: steffen.klassert, herbert, davem, edumazet, pabeni, horms,
eyal.birger, vega, xizh2024, enjou1224z
In-Reply-To: <cover.1784645321.git.xizh2024@lzu.edu.cn>
From: Zihan Xi <xizh2024@lzu.edu.cn>
nat_keepalive_work() walks the state table while xfrm_state_walk()
holds net->xfrm.xfrm_state_lock. Its callback then acquires x->lock,
which conflicts with the delete path taking the same locks in reverse
order via xfrm_state_delete() and __xfrm_state_delete(). This creates
an AB-BA deadlock that is reported by lockdep when a NAT keepalive
worker races with SA deletion.
Fix this by splitting the keepalive walk into two phases. First,
collect the candidate states while the walk holds xfrm_state_lock and
take a reference on each state. Then, after the walk completes, process
each collected state and acquire x->lock without nesting it under
xfrm_state_lock.
Fixes: f531d13bdfe3 ("xfrm: support sending NAT keepalives in ESP in UDP states")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Assisted-by: Codex:gpt-5.4
Signed-off-by: Zihan Xi <xizh2024@lzu.edu.cn>
Signed-off-by: Ren Wei <enjou1224z@gmail.com>
---
net/xfrm/xfrm_nat_keepalive.c | 57 +++++++++++++++++++++++++++++------
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/net/xfrm/xfrm_nat_keepalive.c b/net/xfrm/xfrm_nat_keepalive.c
index 458931062a04..132de23e64c2 100644
--- a/net/xfrm/xfrm_nat_keepalive.c
+++ b/net/xfrm/xfrm_nat_keepalive.c
@@ -153,24 +153,51 @@ static void nat_keepalive_send(struct nat_keepalive *ka)
}
struct nat_keepalive_work_ctx {
+ struct list_head states;
time64_t next_run;
time64_t now;
};
-static int nat_keepalive_work_single(struct xfrm_state *x, int count, void *ptr)
+struct nat_keepalive_state {
+ struct list_head list;
+ struct xfrm_state *x;
+};
+
+static int nat_keepalive_work_collect(struct xfrm_state *x, int count, void *ptr)
{
struct nat_keepalive_work_ctx *ctx = ptr;
+ struct nat_keepalive_state *state;
+
+ if (!READ_ONCE(x->nat_keepalive_interval))
+ return 0;
+
+ state = kmalloc_obj(*state, GFP_ATOMIC);
+ if (!state)
+ return -ENOMEM;
+
+ xfrm_state_hold(x);
+ state->x = x;
+ list_add_tail(&state->list, &ctx->states);
+ return 0;
+}
+
+static void nat_keepalive_work_single(struct xfrm_state *x,
+ struct nat_keepalive_work_ctx *ctx)
+{
bool send_keepalive = false;
struct nat_keepalive ka;
- time64_t next_run;
+ time64_t next_run = 0;
u32 interval;
int delta;
+ spin_lock_bh(&x->lock);
+
+ if (x->km.state == XFRM_STATE_DEAD)
+ goto out;
+
interval = x->nat_keepalive_interval;
if (!interval)
- return 0;
-
- spin_lock(&x->lock);
+ goto out;
delta = (int)(ctx->now - x->lastused);
if (delta < interval) {
@@ -184,29 +211,41 @@ static int nat_keepalive_work_single(struct xfrm_state *x, int count, void *ptr)
send_keepalive = true;
}
- spin_unlock(&x->lock);
+out:
+ spin_unlock_bh(&x->lock);
if (send_keepalive)
nat_keepalive_send(&ka);
- if (!ctx->next_run || next_run < ctx->next_run)
+ if (next_run && (!ctx->next_run || next_run < ctx->next_run))
ctx->next_run = next_run;
- return 0;
}
static void nat_keepalive_work(struct work_struct *work)
{
+ struct nat_keepalive_state *state, *tmp;
struct nat_keepalive_work_ctx ctx;
struct xfrm_state_walk walk;
struct net *net;
+ int err;
+ INIT_LIST_HEAD(&ctx.states);
ctx.next_run = 0;
ctx.now = ktime_get_real_seconds();
net = container_of(work, struct net, xfrm.nat_keepalive_work.work);
xfrm_state_walk_init(&walk, IPPROTO_ESP, NULL);
- xfrm_state_walk(net, &walk, nat_keepalive_work_single, &ctx);
+ err = xfrm_state_walk(net, &walk, nat_keepalive_work_collect, &ctx);
xfrm_state_walk_done(&walk, net);
+ list_for_each_entry_safe(state, tmp, &ctx.states, list) {
+ nat_keepalive_work_single(state->x, &ctx);
+ xfrm_state_put(state->x);
+ kfree(state);
+ }
+ if (err == -ENOMEM) {
+ schedule_delayed_work(&net->xfrm.nat_keepalive_work, 0);
+ return;
+ }
if (ctx.next_run)
schedule_delayed_work(&net->xfrm.nat_keepalive_work,
(ctx.next_run - ctx.now) * HZ);
--
2.43.0
^ permalink raw reply related
* [PATCH 0/1] xfrm: avoid lock inversion in nat keepalive work
From: Ren Wei @ 2026-07-21 15:25 UTC (permalink / raw)
To: netdev
Cc: steffen.klassert, herbert, davem, edumazet, pabeni, horms,
eyal.birger, vega, xizh2024, enjou1224z
From: Zihan Xi <xizh2024@lzu.edu.cn>
Hi Linux kernel maintainers,
We found and validated a lock inversion issue in
net/xfrm/xfrm_nat_keepalive.c. The bug is reachable when an outbound
ESP-in-UDP state enables NAT keepalives and races with SA deletion.
We've tested the fix, and it does not affect the normal delete path.
This series contains one patch:
1/1 xfrm: avoid lock inversion in nat keepalive work
We provide bug details, reproducer steps, and a crash log below.
---- details below ----
Bug details:
nat_keepalive_work() walks the state table through xfrm_state_walk()
while xfrm_state_walk() holds net->xfrm.xfrm_state_lock. In the buggy
code, the walk callback nat_keepalive_work_single() then acquires
x->lock. The delete path takes the reverse order:
xfrm_state_delete() acquires x->lock first, and __xfrm_state_delete()
later acquires net->xfrm.xfrm_state_lock. That creates an AB-BA lock
inversion between the keepalive worker and the delete path, and lockdep
reports it as a circular dependency.
The fix keeps xfrm_state_lock out of the per-state processing phase.
The worker first collects matching states under the walk with an extra
reference, then processes them after the walk finishes and only then
takes x->lock. This preserves the original logic while avoiding the
reverse lock nesting.
We first tried to validate this with the original userspace
NETLINK_XFRM reproducer in the bug directory. On this validation kernel,
that reproducer was rejected during strict attribute validation with
"attribute type 34 has an invalid length" before it could reach the
buggy path. To validate the same root cause and the same keepalive
worker versus SA delete ordering in-kernel, we used a temporary local
in-kernel reproducer that creates an outbound ESP-in-UDP state with
NAT keepalive enabled, flushes the keepalive worker, and then deletes
the state. This temporary reproducer was used only for local validation
and is not part of the patch series.
Reproducer:
# Build kernels with the temporary local in-kernel reproducer linked in
make -C /var/cache/linux-patch/xfrm-nat-keepalive-src \
O=/var/cache/linux-patch/bt-parent-uaf-net-main-build -j$(nproc) bzImage
# Boot the unfixed kernel
qemu-system-x86_64 -m 2G -cpu max -smp 2 -machine accel=tcg \
-kernel verify/bzImage-unfixed-kpoc \
-append 'root=/dev/sda rw console=ttyS0 earlyprintk=serial \
net.ifnames=0 biosdevname=0 panic_on_warn=1 oops=panic \
slub_debug=FZPU page_poison=1 init_on_alloc=1 init_on_free=1' \
-drive file=/tmp/qemu-unfixed-realboot.qcow2,format=qcow2
# Boot the fixed kernel
qemu-system-x86_64 -m 2G -cpu max -smp 2 -machine accel=tcg \
-kernel verify/bzImage-fixed-kpoc \
-append 'root=/dev/sda rw console=ttyS0 earlyprintk=serial \
net.ifnames=0 biosdevname=0 panic_on_warn=1 oops=panic \
slub_debug=FZPU page_poison=1 init_on_alloc=1 init_on_free=1' \
-drive file=/tmp/qemu-fixed-realboot.qcow2,format=qcow2
We run the validation in a 2 vCPU, 2 GB RAM x86 QEMU environment.
------BEGIN xfrm_nat_keepalive_repro.c------
// SPDX-License-Identifier: GPL-2.0
#include <linux/init.h>
#include <linux/in.h>
#include <linux/ip.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/workqueue.h>
#include <net/net_namespace.h>
#include <net/xfrm.h>
static int __init xfrm_nat_keepalive_repro_init(void)
{
struct xfrm_state *x;
struct xfrm_encap_tmpl *encap;
int err;
pr_info("xfrm_nat_keepalive_repro: start\n");
x = xfrm_state_alloc(&init_net);
if (!x)
return 0;
encap = kzalloc(sizeof(*encap), GFP_KERNEL);
if (!encap) {
xfrm_state_put(x);
return 0;
}
encap->encap_type = UDP_ENCAP_ESPINUDP;
encap->encap_sport = htons(4500);
encap->encap_dport = htons(4500);
x->id.proto = IPPROTO_ESP;
x->id.spi = htonl(0x100);
x->id.daddr.a4 = htonl(INADDR_LOOPBACK);
x->props.saddr.a4 = htonl(INADDR_LOOPBACK);
x->props.family = AF_INET;
x->props.mode = XFRM_MODE_TRANSPORT;
x->props.reqid = 1;
x->sel.family = AF_INET;
x->sel.daddr.a4 = htonl(INADDR_LOOPBACK);
x->sel.saddr.a4 = htonl(INADDR_LOOPBACK);
x->sel.prefixlen_d = 32;
x->sel.prefixlen_s = 32;
x->encap = encap;
x->dir = XFRM_SA_DIR_OUT;
x->nat_keepalive_interval = 1;
x->lastused = ktime_get_real_seconds();
x->km.state = XFRM_STATE_VALID;
xfrm_state_insert(x);
flush_delayed_work(&init_net.xfrm.nat_keepalive_work);
err = xfrm_state_delete(x);
xfrm_flush_gc();
pr_info("xfrm_nat_keepalive_repro: delete err=%d\n", err);
return 0;
}
late_initcall_sync(xfrm_nat_keepalive_repro_init);
------END xfrm_nat_keepalive_repro.c--------
----BEGIN crash log----
[ 129.325779][ T1] xfrm_nat_keepalive_repro: start
[ 129.348170][ T1] WARNING: possible circular locking dependency detected
[ 129.348170][ T1] 7.2.0-rc2+ #5 Not tainted
[ 129.348170][ T1] ------------------------------------------------------
[ 129.348170][ T1] swapper/0/1 is trying to acquire lock:
[ 129.348170][ T1] ffffffff989f9fd8 (&net->xfrm.xfrm_state_lock){+...}-{3:3}, at: __xfrm_state_delete+0xa4/0x9d0
[ 129.460853][ T1] but task is already holding lock:
[ 129.460853][ T1] ff1100001bbfc0c8 (&x->lock){+...}-{3:3}, at: xfrm_state_delete+0x1b/0x40
[ 129.460853][ T1] -> #1 (&x->lock){+...}-{3:3}:
[ 129.460853][ T1] _raw_spin_lock+0x2d/0x40
[ 129.460853][ T1] nat_keepalive_work_single+0x15c/0x1c40
[ 129.460853][ T1] xfrm_state_walk+0x4ed/0xb70
[ 129.460853][ T1] nat_keepalive_work+0xe8/0x1b0
[ 129.460853][ T1] -> #0 (&net->xfrm.xfrm_state_lock){+...}-{3:3}:
[ 129.460853][ T1] __xfrm_state_delete+0xa4/0x9d0
[ 129.460853][ T1] xfrm_state_delete+0x23/0x40
[ 129.460853][ T1] xfrm_nat_keepalive_repro_init+0x4ba/0x640
[ 129.460853][ T1] *** DEADLOCK ***
[ 130.799594][ T1] xfrm_nat_keepalive_repro: delete err=0
-----END crash log-----
Best regards,
Zihan Xi
Zihan Xi (1):
xfrm: avoid lock inversion in nat keepalive work
net/xfrm/xfrm_nat_keepalive.c | 57 +++++++++++++++++++++++++++++------
1 file changed, 48 insertions(+), 9 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH bpf-next v5 1/8] netlink: specs: add XDP RX checksum capability to XDP metadata specs
From: Jakub Kicinski @ 2026-07-21 15:21 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Donald Hunter, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Andrew Lunn, Tony Nguyen, Przemek Kitszel, Alexander Lobakin,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Shuah Khan,
Maciej Fijalkowski, Jonathan Corbet, Shuah Khan,
Kumar Kartikeya Dwivedi, Emil Tsalapatis, Vladimir Vdovin,
Jakub Sitnicki, netdev, bpf, intel-wired-lan, linux-kselftest,
linux-doc, Aleksandr Loktionov
In-Reply-To: <20260715-bpf-xdp-meta-rxcksum-v5-1-623d5c0d0ab7@kernel.org>
On Wed, 15 Jul 2026 23:39:41 +0200 Lorenzo Bianconi wrote:
> + * In case of success, ``cksum`` contains the checksum value calculated by the
> + * NIC. ``cksum`` is valid only if ``XDP_CHECKSUM_COMPLETE`` is set in
> + * ``ip_summed``. ``cksum_level`` contains the checksum level reported by the
> + * hw. ``cksum_level`` can be considered valid only if
> + * ``XDP_CHECKSUM_UNNECESSARY`` is set in ``ip_summed``.
nit: cksum -> csum like the rest of the networking stack
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] selftests: net: add coverage for fdb nexthop dst port
From: Ido Schimmel @ 2026-07-21 15:20 UTC (permalink / raw)
To: Jack Ma
Cc: David Ahern, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260717-b4-vxlan-fdb-port-v2-3-f4862e8fe867@gmail.com>
On Fri, Jul 17, 2026 at 06:45:18AM +0000, Jack Ma wrote:
> Add fib_nexthops_fdb_port.sh, which exercises the NHA_FDB_PORT rules:
> accept a port on an fdb nexthop that has a gateway and echo it back on
> dump, reject it on non-fdb or gateway-less nexthops, allow a group whose
> legs differ only in UDP port, and confirm a portless fdb nexthop omits
> the attribute. The test SKIPs cleanly on kernels or iproute2 without
> NHA_FDB_PORT support.
We already have control plane test for FDB nexthops in fib_nexthops.sh,
can you add the new test cases there instead? Probably fit in
ipv4_fdb_grp_fcnal() and ipv6_fdb_grp_fcnal()
>
> Signed-off-by: Jack Ma <jack4it@gmail.com>
> ---
> tools/testing/selftests/net/Makefile | 1 +
> .../testing/selftests/net/fib_nexthops_fdb_port.sh | 78 ++++++++++++++++++++++
> 2 files changed, 79 insertions(+)
>
> diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
> index 708d960ae..c06eb4927 100644
> --- a/tools/testing/selftests/net/Makefile
> +++ b/tools/testing/selftests/net/Makefile
> @@ -36,6 +36,7 @@ TEST_PROGS := \
> fib_nexthop_multiprefix.sh \
> fib_nexthop_nongw.sh \
> fib_nexthops.sh \
> + fib_nexthops_fdb_port.sh \
> fib_rule_tests.sh \
> fib_tests.sh \
> fin_ack_lat.sh \
> diff --git a/tools/testing/selftests/net/fib_nexthops_fdb_port.sh b/tools/testing/selftests/net/fib_nexthops_fdb_port.sh
> new file mode 100755
> index 000000000..8b401c6d2
> --- /dev/null
> +++ b/tools/testing/selftests/net/fib_nexthops_fdb_port.sh
> @@ -0,0 +1,78 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Control-plane selftest for per-nexthop VXLAN fdb destination port
> +# (NHA_FDB_PORT). Verifies the accept/reject rules and the dump roundtrip.
> +# No datapath traffic here -- see tests/integ/vxlan-fdb-port-integ.sh for the
> +# real forwarding test.
vxlan-fdb-port-integ.sh doesn't exist. We have test_vxlan_nh.sh. Can you
extend basic_tx_common() to test the new attribute? Don't change the
existing configuration (we want to test the configuration where user
space doesn't pass a port) and instead add a new:
1. FDB nexthop and a group that contains it
2. Flower filter that also matches on the destination port (not 4789)
3. FDB entry that points to the new group
Run shellcheck (preferably via ingest_mdir.py [1]) to make sure you're
not adding new warnings / errors.
[1] https://github.com/linux-netdev/nipa#running-locally
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] vxlan: honor per-nexthop fdb destination port
From: Ido Schimmel @ 2026-07-21 15:18 UTC (permalink / raw)
To: Jack Ma
Cc: David Ahern, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260717-b4-vxlan-fdb-port-v2-2-f4862e8fe867@gmail.com>
On Fri, Jul 17, 2026 at 06:45:17AM +0000, Jack Ma wrote:
> When an fdb entry points at a nexthop group, vxlan_fdb_nh_path_select()
> resolves the selected leg's remote IP but leaves the UDP destination port
> at the device default (vxlan->cfg.dst_port).
>
> Extend nexthop_path_fdb_result() to also return the selected nexthop's
> NHA_FDB_PORT (0 when unset) and have vxlan_fdb_nh_path_select() store it
> in rdst->remote_port. vxlan_xmit_one() already prefers rdst->remote_port
> when non-zero and falls back to the device port otherwise, so nexthops
> without a port are unaffected.
>
> This lets one fdb nexthop group load-balance a flow across legs that
> share an underlay IP but differ in UDP destination port.
>
> Signed-off-by: Jack Ma <jack4it@gmail.com>
> ---
> include/net/nexthop.h | 5 ++++-
> include/net/vxlan.h | 5 ++++-
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/nexthop.h b/include/net/nexthop.h
> index 9c8227996..7fb612a73 100644
> --- a/include/net/nexthop.h
> +++ b/include/net/nexthop.h
> @@ -576,7 +576,8 @@ struct fib_nh_common *nexthop_fdb_nhc(struct nexthop *nh)
> }
>
> static inline struct fib_nh_common *nexthop_path_fdb_result(struct nexthop *nh,
> - int hash)
> + int hash,
> + __be16 *fdb_port)
Alignment is off
> {
> struct nh_info *nhi;
> struct nexthop *nhp;
> @@ -585,6 +586,8 @@ static inline struct fib_nh_common *nexthop_path_fdb_result(struct nexthop *nh,
> if (unlikely(!nhp))
> return NULL;
> nhi = rcu_dereference(nhp->nh_info);
> + if (fdb_port)
Remove the check given 'fdb_port' is never NULL?
> + *fdb_port = nhi->fdb_port;
> return &nhi->fib_nhc;
> }
> #endif
> diff --git a/include/net/vxlan.h b/include/net/vxlan.h
> index dfba89695..de41b3746 100644
> --- a/include/net/vxlan.h
> +++ b/include/net/vxlan.h
> @@ -567,8 +567,9 @@ static inline bool vxlan_fdb_nh_path_select(struct nexthop *nh,
> struct vxlan_rdst *rdst)
> {
> struct fib_nh_common *nhc;
> + __be16 fdb_port = 0;
>
> - nhc = nexthop_path_fdb_result(nh, hash >> 1);
> + nhc = nexthop_path_fdb_result(nh, hash >> 1, &fdb_port);
> if (unlikely(!nhc))
> return false;
>
> @@ -583,6 +584,8 @@ static inline bool vxlan_fdb_nh_path_select(struct nexthop *nh,
> break;
> }
>
> + rdst->remote_port = fdb_port;
> +
> return true;
> }
>
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: nexthop: add NHA_FDB_PORT for fdb nexthops
From: Ido Schimmel @ 2026-07-21 15:17 UTC (permalink / raw)
To: Jack Ma
Cc: David Ahern, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260717-b4-vxlan-fdb-port-v2-1-f4862e8fe867@gmail.com>
On Fri, Jul 17, 2026 at 06:45:16AM +0000, Jack Ma wrote:
> Commit 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") lets a
> single inner MAC be reached through a group of remote VTEPs, with the
> kernel flow-hashing across the group members. Each member carries its
> own remote IP, but the UDP destination port is always taken from the
> VXLAN device (vxlan->cfg.dst_port) and cannot be set per member.
>
> Some deployments pack several receivers behind one underlay IP and tell
> them apart by UDP port, so they need a per-nexthop destination port to
> spread flows across (IP, port) tuples rather than IP alone.
>
> Add a netlink attribute NHA_FDB_PORT (__be16, mirroring NDA_PORT) that
> carries an optional UDP destination port on an fdb nexthop. It is only
> accepted together with NHA_FDB and NHA_GATEWAY; it is stored in struct
> nh_info and echoed back on dump. This patch is control-plane plumbing
> only; the VXLAN datapath is wired up in a follow-up patch, so behaviour
> is unchanged for now.
>
> Signed-off-by: Jack Ma <jack4it@gmail.com>
> ---
> include/net/nexthop.h | 2 ++
> include/uapi/linux/nexthop.h | 3 +++
> net/ipv4/nexthop.c | 20 +++++++++++++++++++-
> 3 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/nexthop.h b/include/net/nexthop.h
> index 572e69cda..9c8227996 100644
> --- a/include/net/nexthop.h
> +++ b/include/net/nexthop.h
> @@ -28,6 +28,7 @@ struct nh_config {
> u8 nh_protocol;
> u8 nh_blackhole;
> u8 nh_fdb;
> + __be16 nh_fdb_port;
> u32 nh_flags;
>
> int nh_ifindex;
> @@ -63,6 +64,7 @@ struct nh_info {
> u8 family;
> bool reject_nh;
> bool fdb_nh;
> + __be16 fdb_port;
>
> union {
> struct fib_nh_common fib_nhc;
> diff --git a/include/uapi/linux/nexthop.h b/include/uapi/linux/nexthop.h
> index bc49baf4a..e587bbf3b 100644
> --- a/include/uapi/linux/nexthop.h
> +++ b/include/uapi/linux/nexthop.h
> @@ -83,6 +83,9 @@ enum {
> /* u32; read-only; whether any driver collects HW stats */
> NHA_HW_STATS_USED,
>
> + /* be16; UDP destination port for an fdb nexthop (e.g. VXLAN) */
> + NHA_FDB_PORT,
> +
> __NHA_MAX,
> };
>
> diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
> index 6205bd57a..5b27cc9a9 100644
> --- a/net/ipv4/nexthop.c
> +++ b/net/ipv4/nexthop.c
> @@ -39,6 +39,7 @@ static const struct nla_policy rtm_nh_policy_new[] = {
> [NHA_ENCAP_TYPE] = { .type = NLA_U16 },
> [NHA_ENCAP] = { .type = NLA_NESTED },
> [NHA_FDB] = { .type = NLA_FLAG },
> + [NHA_FDB_PORT] = { .type = NLA_U16 },
Maybe NLA_POLICY_MIN(NLA_BE16, 1) given that it's BE16 and that we don't
dump / use a destination port of 0?
> [NHA_RES_GROUP] = { .type = NLA_NESTED },
> [NHA_HW_STATS_ENABLE] = NLA_POLICY_MAX(NLA_U32, true),
> };
> @@ -956,6 +957,9 @@ static int nh_fill_node(struct sk_buff *skb, struct nexthop *nh,
> } else if (nhi->fdb_nh) {
> if (nla_put_flag(skb, NHA_FDB))
> goto nla_put_failure;
> + if (nhi->fdb_port &&
> + nla_put_be16(skb, NHA_FDB_PORT, nhi->fdb_port))
> + goto nla_put_failure;
> } else {
> const struct net_device *dev;
>
> @@ -1055,6 +1059,9 @@ static size_t nh_nlmsg_size_single(struct nexthop *nh)
> break;
> }
>
> + if (nhi->fdb_nh)
Why not nhi->fdb_port ?
> + sz += nla_total_size(2); /* NHA_FDB_PORT */
> +
> if (nhi->fib_nhc.nhc_lwtstate) {
> sz += lwtunnel_get_encap_size(nhi->fib_nhc.nhc_lwtstate);
> sz += nla_total_size(2); /* NHA_ENCAP_TYPE */
> @@ -2956,8 +2963,10 @@ static struct nexthop *nexthop_create(struct net *net, struct nh_config *cfg,
> nhi->family = cfg->nh_family;
> nhi->fib_nhc.nhc_scope = RT_SCOPE_LINK;
>
> - if (cfg->nh_fdb)
> + if (cfg->nh_fdb) {
> nhi->fdb_nh = 1;
> + nhi->fdb_port = cfg->nh_fdb_port;
> + }
>
> if (cfg->nh_blackhole) {
> nhi->reject_nh = 1;
> @@ -3147,6 +3156,15 @@ static int rtm_to_nh_config(struct net *net, struct sk_buff *skb,
> cfg->nh_fdb = nla_get_flag(tb[NHA_FDB]);
> }
>
> + if (tb[NHA_FDB_PORT]) {
> + if (!tb[NHA_FDB] || !tb[NHA_GATEWAY]) {
> + NL_SET_ERR_MSG(extack,
> + "FDB port can only be set on fdb nexthops that have a gateway");
> + goto out;
> + }
> + cfg->nh_fdb_port = nla_get_be16(tb[NHA_FDB_PORT]);
> + }
> +
> if (tb[NHA_GROUP]) {
> if (nhm->nh_family != AF_UNSPEC) {
> NL_SET_ERR_MSG(extack, "Invalid family for group");
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [RFC PATCH net-next 00/13] net: knod: in-kernel network offload device
From: Taehee Yoo @ 2026-07-21 15:17 UTC (permalink / raw)
To: Mina Almasry
Cc: Alex Deucher, Alexei Starovoitov, amd-gfx, Andrew Lunn,
Andrii Nakryiko, Bill Wendling, bpf, Christian König,
Daniel Borkmann, David Airlie, David S. Miller, Donald Hunter,
dri-devel, Eduard Zingerman, Emil Tsalapatis, Eric Dumazet,
Felix Kuehling, Hoyeon Lee, Ilias Apalodimas, Jakub Kicinski,
Jesper Dangaard Brouer, Jiri Olsa, John Fastabend, Justin Stitt,
Kees Cook, Kumar Kartikeya Dwivedi, Leon Romanovsky,
linaro-mm-sig, linux-hardening, linux-kernel, linux-kselftest,
linux-media, linux-rdma, llvm, Mark Bloch, Martin KaFai Lau,
Michael Chan, Nathan Chancellor, netdev, Nick Desaulniers,
Paolo Abeni, Pavan Chebbi, Saeed Mahameed, Shuah Khan,
Simona Vetter, Simon Horman, Song Liu, Stanislav Fomichev,
Sumit Semwal, Tariq Toukan, Yonghong Song
In-Reply-To: <CAHS8izMocev_0TtAsUr9BqCm6sH2DBh-bPK4DfZYNEAb_d2G6w@mail.gmail.com>
On Tue, Jul 21, 2026 at 4:18 AM Mina Almasry <almasrymina@google.com> wrote:
>
Hi Mina,
Thanks a lot for your review!
> On Sun, Jul 19, 2026 at 11:01 AM Taehee Yoo <ap420073@gmail.com> wrote:
> >
> > knod (in-kernel network offload device) drives a GPU directly from the
> > Linux kernel - with no userspace GPU runtime such as CUDA or ROCm, and
> > no userspace component in the data path - to accelerate packet
> > processing.
> >
> > The kernel itself allocates the GPU's queues, JIT-compiles the
> > per-packet program to GPU machine code, and dispatches it; the NIC DMAs
> > received packets straight into GPU memory and the GPU returns a verdict.
> > The GPU is programmed like any other in-kernel offload, not through a
> > userspace framework, so existing XDP programs and IPsec SAs can be
> > offloaded to it transparently.
> >
> > The design and motivation were presented at Linux Plumbers Conference
> > 2025:
> >
> > https://lpc.events/event/19/contributions/2267/
> >
> > Motivation
> > ==========
> >
> > Line-rate packet processing that does non-trivial per-packet work - an
> > XDP program doing L4 load balancing, or IPsec crypto - is bound by the
> > host CPU: each core handles one packet at a time, so scaling means
> > spending more cores. A GPU is the opposite shape - thousands of lanes
> > running the same small program over many packets at once (SIMT) - which
> > happens to match the per-packet-program model of XDP.
> >
> > knod moves that per-packet compute off the host CPU and onto a GPU. The
> > NIC DMAs received packets directly into GPU memory, the GPU runs the
> > program across a batch of packets in parallel, and only the result
> > comes back: a verdict for every packet, plus the packet itself for the
> > ones destined to the host. The CPU no longer pays the per-packet
> > program cost, and throughput scales with GPU occupancy rather than core
> > count.
> >
> > Crucially this happens entirely inside the kernel. GPU packet processing
> > today generally launches work from a userspace GPU runtime (CUDA and
> > friends) and keeps that runtime in the data path; knod instead builds
> > the GPU queues, compiles the program, and dispatches it from the kernel,
> > so it plugs into existing offload paths (XDP, xfrm) with nothing to
> > install or keep running in userspace.
> >
>
> TBH I found this motivation weak, especially since IIUC you're asking
> for almost ~50K lines of code to be merged to the kernel. My thinking
> is that (a) it's true that Native XDP takes up CPU cores, but
> HW-offload XDP already exists and takes up no CPU. (b) with AI, GPUs
> are very expensive and the work they're doing is critical, so you're
> unlikely to buy a GPU and use it for knod-offloaded XDP; you'd
> probably buy a cheaper smart-NIC? And in the cases where you do have a
> GPU, it's likely your system's money-maker, and you probably want to
> offload work from the GPU, not to your GPU.
>
Thanks, these are fair concerns.
For a system where the GPU is already fully utilized, a SmartNIC may
indeed be the better target for XDP offload. We are not arguing that
GPU offload is always cheaper or more efficient.
The goal of KNOD is to provide an upstream path for using programmable
accelerators already available in the system for kernel networking.
Hardware XDP offload exists, but the available functionality is tied to
the NIC, its firmware, and the features maintained by the vendor.
KNOD instead aims to provide an execution layer that can be extended
in the kernel community. XDP is the first workload used to validate
this layer, rather than the intended limit of KNOD.
> But as far as I can tell there should be much more interesting
> applications for what you're doing rather than offloading XDP. Like
> wouldn't you with this feature be able to implement ML collectively
> like all-to-all/all-reduce/all-gather as purely XDP programs offloaded
> to the GPU? If you have that implemented and can positively compare
> performance to RoCE or RDMA that would be a much more interesting use
> case IMO.
>
I agree that this is a promising direction, and collective communication
could be a good fit for this model. At least for all-reduce, however,
BPF/XDP does not currently support the required floating-point
operations. If that support is discussed and added by the BPF community,
this would be an interesting use case to explore with KNOD and evaluate
against RoCE or RDMA.
> > Model
> > =====
> >
> > knod binds two endpoints through a third object:
> >
> > - a NIC-side netdev, registered by the NIC driver;
> > - an accelerator (the GPU), registered by a provider built into the
> > GPU driver;
> > - an offload device, created on attach, that connects them and owns
> > the per-queue data-path state.
> >
> > The accelerator ops are feature-agnostic, so different per-packet
> > programs plug in behind one interface. This series ships two features
> > to show the framework is not tied to a single use case (the accel-type
> > uAPI also reserves "dpu" for future non-GPU backends):
> >
> > - BPF: an XDP program attached in offload mode is JIT-compiled from
> > eBPF to an AMD GCN shader and executed on the GPU.
> > - IPsec: RX ESP full-packet decrypt on the GPU (proof of concept,
> > see below).
> >
> > Data path
> > =========
> >
> > For a NIC RX queue bound to an accelerator, a received packet flows as
> > follows:
> >
> > 1. Attach reconfigures the NIC's page_pool so its pages come from GPU
> > memory, exported as a dma-buf and plugged in through the devmem
> > memory provider. The NIC therefore DMAs the packet straight into
> > GPU memory - there is no host-side copy on RX.
> >
> > 2. Instead of building an skb and entering the stack, the NIC's NAPI
> > pushes a small descriptor (memory ref + offset + length) onto a
> > per-queue lock-free SPSC ring shared with the GPU.
> >
> > 3. A persistent GPU worker drains descriptors and runs the active
> > feature's shader over a batch of packets in parallel - one
> > workgroup per packet - then writes a per-packet verdict back onto
> > the ring: PASS, DROP or TX.
> >
> > 4. Back on the NIC NAPI, each verdict is applied:
> > - DROP: the GPU page is recycled to the pool;
> > - TX: the packet is sent back out the NIC directly from GPU
> > memory (XDP_TX), with no host round-trip;
> > - PASS: the packet is copied out of GPU memory into a host
> > delivery page by the GPU's DMA engine (async SDMA),
> > wrapped as an skb, and handed to the normal stack.
> >
> > So only PASS packets ever touch host memory, and even then the copy is
> > done by the GPU, not the CPU.
> >
> > The control plane is a generic netlink family ("knod") for
> > attach/detach, accelerator/NIC inventory, and per-accelerator feature
> > selection, with notifications on bind/unbind.
> >
> > Code layout
> > ===========
> >
> > knod separates into a subsystem-neutral core and a GPU-specific
> > provider; nothing in the core knows about GPUs. Roughly:
> >
> > - core + control plane + NIC drivers net/, kernel/bpf/ (~4.4k)
> > - GPU provider (queues, JIT, shaders) drivers/gpu/drm/amd/ (~39k)
> >
>
> Since the changes are so large, I would break this work into many
> series, the first which only supports a very minimal set of work
> (which I would guess would be XDP_DROP and XDP_TX), and then follow up
> with another series which adds XDP_PASS support, and then IPSec, etc.
>
That makes sense. We will split the work and start with the minimum
functionality needed to demonstrate the architecture, likely XDP_DROP
and XDP_TX. XDP_PASS, IPsec, and the remaining functionality can follow
in separate series.
Thanks a lot!
Taehee Yoo
> --
> Thanks,
> Mina
^ permalink raw reply
* AW: [PATCH net-next v4 0/8] net: mdio: realtek-rtl9300: Add RTL83xx support
From: Markus Stockhausen @ 2026-07-21 15:17 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, netdev,
chris.packham, daniel
In-Reply-To: <20260709064157.2865063-1-markus.stockhausen@gmx.de>
> Von: Markus Stockhausen <markus.stockhausen@gmx.de>
> Gesendet: Donnerstag, 9. Juli 2026 08:42
> Betreff: [PATCH net-next v4 0/8] net: mdio: realtek-rtl9300: Add RTL83xx
support
>
> The Realtek Otto switch platform consists of four different series
>
> - RTL838x aka maple : 28 port 1G Switches
> - RTL839x aka cypress : 52 port 1G Switches
> - RTL930x aka longan : 28 port 1G/2.5G/10G Switches
> - RTL931x aka mango : 56 port 1G/2.5G/10G Switches
>
> While the MDIO hardware polling unit and its necessity for the MAC
> layer was always well known, no detailed documentation was available.
> For this series the MDIO bus was inspected with a logic analyzer for
> a better understanding how polling and kernel access interact on the
> bus. All this will be explained now in the driver comments.
>
> This patch series adds support for the RTL83xx devices. For this
>
> - Enhance device tree binding.
> - Add special handling for limitations enforced by hardware polling.
> These already have minor side effects on RTL93xx devices but are even
> more critical for the RTL83xx hardware.
> - Add RTL83xx coding.
>
> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Gentle ping.
^ permalink raw reply
* Re: [PATCH net-next] Revert "gtp: annotate PDP lookups under RTNL"
From: Jakub Kicinski @ 2026-07-21 15:16 UTC (permalink / raw)
To: Simon Horman
Cc: Pablo Neira Ayuso, Harald Welte, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, osmocom-net-gprs, netdev
In-Reply-To: <20260708-gtp-rtnl-v1-1-218091f171bc@kernel.org>
On Wed, 08 Jul 2026 20:02:05 +0100 Simon Horman wrote:
> This reverts commit 0be5c3f0fbef3679f50f345b9237b8f9ea5de4e9.
>
> Commit 0be5c3f0fbef ("gtp: annotate PDP lookups under RTNL") added a
> lockdep_rtnl_is_held condition to hlist_for_each_rcu() loops to help
> insure that RTNL is held.
>
> Unfortunately, as pointed out by Pablo Neira Ayuso, the PDP context list
> is actually protected by the genetlink mutex. And so the condition
> is incorrect.
In the future please remember to add a Link: to the message being
referenced.
^ permalink raw reply
* RE: Loopback, PRBS and link topo enumeration
From: Das, Shubham @ 2026-07-21 15:12 UTC (permalink / raw)
To: Maxime Chevallier, Andrew Lunn, Russell King, Heiner Kallweit,
Vladimir Oltean, Florian Fainelli, Alexander H Duyck,
lee@trager.us, mkubecek@suse.cz, Chintalapalle, Balaji,
Lindberg, Magnus, niklas.damberg@ericsson.com, Oleksij Rempel,
Susheela Doddagoudar, Naveen Mamindlapalli
Cc: netdev, Jakub Kicinski, Eric Dumazet, Paolo Abeni,
Thomas Petazzoni
In-Reply-To: <ef8fe714-5ad9-4f98-96fa-d8468beecd38@bootlin.com>
> A proposed approach would be to decompose this into separate ethnl commands
> :
>
> - A set of commands to report the HW layout to the user :
> ethtool --interface-capabilities ?
>
> it would return a list of the above mentionned blocks, packages, as well
> as an identifier for each block, something like what Björn has proposed for
> loopback [2] :
>
> [2] : https://lore.kernel.org/netdev/20260325145022.2607545-4-
> bjorn@kernel.org/
>
> "
> Each loopback point is described by a nested entry attribute
> containing:
>
> - component where in the path (MAC, PHY, MODULE)
> - name subsystem label, e.g. "cmis-host" or "cmis-media"
> - id optional instance selector (e.g. PHY id, port id)
> - depth ordering index within a component (0 = first/only)
> - supported bitmask of supported directions
> - direction LOCAL, REMOTE, or 0 (disabled) "
>
> We'd remove the "direction" part, but "component" is same as "domain", name
> could be an enum instead (PMA / PMD / RS / FEC / PCS ?) or we keep it as a
> string, id should be renamed "component_id", and we would return an extra 'id',
> unique per entry, that we would use for the actual PRBS/Loopback command,
> here as the 'block' parameter.
>
>
> ethtool --set-loopback eth0 block <XXX> type local
>
> ethtool --phy-test eth0 block <XXX> lane 0 tx-pattern prbs7
Thanks, Maxime, and everyone, for the feedback.
I will respond to the PRBS discussion with a proposal for a new
ethtool --interface-capabilities command to obtain the block ID parameter.
- Shubham
^ permalink raw reply
* Re: [PATCH net-next] net/tcp: Prevent inlining tcp_syn_ack_timeout()
From: Jakub Kicinski @ 2026-07-21 15:12 UTC (permalink / raw)
To: Paolo Abeni; +Cc: Emil Tsalapatis, netdev, edumazet, ncardwell, kuniyu, davem
In-Reply-To: <6c01c713-14a8-43c2-aaaf-2fcf622f7e4f@redhat.com>
On Tue, 21 Jul 2026 15:24:52 +0200 Paolo Abeni wrote:
> On 7/8/26 8:08 PM, Emil Tsalapatis wrote:
> > The tcp_syn_ack_timeout() function gets inlined by Clang,
> > preventing tracing. Since the call is not in the fast
> > path, prevent it from being inlined.
> >
> > Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
> > ---
> > net/ipv4/tcp_timer.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> > index bf171b5e1eb3..f7215d53bbda 100644
> > --- a/net/ipv4/tcp_timer.c
> > +++ b/net/ipv4/tcp_timer.c
> > @@ -748,7 +748,7 @@ static void tcp_write_timer(struct timer_list *t)
> > sock_put(sk);
> > }
> >
> > -void tcp_syn_ack_timeout(const struct request_sock *req)
> > +noinline_for_tracing void tcp_syn_ack_timeout(const struct request_sock *req)
> > {
> > struct net *net = read_pnet(&inet_rsk(req)->ireq_net);
> >
>
> What's the point of tracing such function? It just increment a mib. If
> you want to discriminate between TFO and non TFO syn ack timeout,
> possibly adding another MIB counter and incrementing it in
> tcp_fastopen_synack_timer() would be better???
FWIW we seem to capture the 5 tuple when it happens, not just mib
counter. Internal commit (form 2019) just says we want to know when
syn-ack is blackholed, unclear under what conditions this happens.
^ permalink raw reply
* Re: [PATCH v11] mm/page_alloc: boost watermarks on atomic allocation failure
From: Vlastimil Babka (SUSE) @ 2026-07-21 15:10 UTC (permalink / raw)
To: Andrew Morton, Qiliang Yuan
Cc: David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Brendan Jackman, Johannes Weiner, Zi Yan,
Lance Yang, SeongJae Park, Matthew Wilcox, netdev
In-Reply-To: <20260720163719.cf37f6be63bfd88a06965761@linux-foundation.org>
On 7/21/26 01:37, Andrew Morton wrote:
> On Mon, 20 Jul 2026 16:15:48 +0800 Qiliang Yuan <realwujing@gmail.com> wrote:
>
>> Atomic allocations (GFP_ATOMIC) are prone to failure under heavy memory
>> pressure as they cannot enter direct reclaim.
>>
>> Handle these failures by introducing a watermark boost mechanism for
>> atomic requests. Refactor boost_watermark() using an internal helper to
>> support both fragmentation and atomic paths. Apply zone-proportional
>> boosts (~0.1% of managed pages) for atomic allocations, while
>> decoupling it from watermark_boost_factor.
>
> Thanks for persisting with this.
>
> You didn't retain Vlastimil's Reviewed-by: from v8?
It was Acked-by: and I asked for it to be removed due [1] to significant
changes in v10, which was acknowleded [2] (thanks):
> This is very much a networking thing - they must have considered
> similar things. But my not-very-energetic attempts to get input from
> networking people have thus far failed.
Yes it would have been useful to have their input.
>> This failure signature keeps recurring in production: a host running
>> a downstream 4.19 kernel logged 144 order-0 GFP_ATOMIC failures over a
I think first only in [2] and now here we learn it's motivated by failures
observed on a downstream 4.19 based kernel.
>> 4h15m window, all through the same NIC driver receive softirq path,
>> across several unrelated network-facing services on the box. This
>> confirms the underlying problem is real and ongoing.
... on a 4.19 (released in 2018) based kernel. There were many changes to
this area since then, some for highatomic allocations even very recently.
So it's necessary to demonstrate the problem exists today as well.
And it shouldn't exist in the form of "logged failures" anyway, thanks to
commits such as c89cca307b20 ("net: skbuff: sprinkle more __GFP_NOWARN on
ingress allocs") that use GFP_ATOMIC with __GFP_NOWARN. So it's not about
avoiding warnings anymore, but preventing fallbacks to non-irq contexts
(that those allocations AFAIK have) and probably thus rather demonstrating
how that improves performance and justifies the patch and risks that come
with it (these heurstics are unfortunately fraught with them).
> It does not by
>> itself measure this patch's effect, since the fix has not been
>> deployed on that fleet yet.
That makes the argument for this patch even worse, but also due to the
above, it wouldn't really be relevant to do that with that 4.19 based kernel
so I can advice not investing time into that.
So what we'd need is to demonstrate that current mainline has a problem and
how it's fixed. A synthetic reproducer suggested in [2] can however be
misleading in the form of apparently confirming that yes, increasing
watermarks by 10% can succeed 10% longer bursts of atomic allocations. But
that alone is not enough to justify this change.
> We'll of course be very interested in these results. Do you know
> if/when they'll be available?
>
> Anyway, let me get this into mm.git and linux-next so we can at least
> parallelize wider testing with ongoing review.
linux-next means mm-unstable? I don't think this should be headed for the
next merge window given the above.
[1] https://lore.kernel.org/all/e011c6a8-cda5-42ce-9d42-b23d1c81b26b@suse.cz/#t
[2] https://lore.kernel.org/all/20260720033804.3862547-1-realwujing@gmail.com/
^ 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