* Re: [PATCH] net: pcs: xpcs-plat: fix runtime PM initialization
From: Jakub Kicinski @ 2026-07-21 13:49 UTC (permalink / raw)
To: Coia Prant
Cc: netdev, Andrew Lunn, Heiner Kallweit, Russell King,
David S . Miller, Eric Dumazet, Paolo Abeni, Serge Semin,
linux-kernel, stable
In-Reply-To: <7BA9366A-3243-4A46-BA8F-BB170C8AD912@gmail.com>
On Tue, 21 Jul 2026 09:53:53 +0800 Coia Prant wrote:
> I came across what looks like a runtime PM initialization issue while
> using pcs-xpcs-plat.c as a reference for the Rockchip XPCS glue driver
> (drivers/net/pcs/pcs-xpcs-rk.c).
>
> The current code in pcs-xpcs-plat.c does:
>
> pm_runtime_set_active(dev);
> ret = devm_pm_runtime_enable(dev);
>
> This sets the initial PM state to ACTIVE before runtime PM is fully
> enabled, and before the clock is prepared and enabled.
>
> If the device is later suspended (e.g., during unbind), the suspend
> callback may try to disable a clock that was never enabled, leading to:
>
> clk_csr already disabled
> clk_csr already unprepared
>
> On Rockchip platforms, the CSR clock (PCLK_XPCS) is required for register
> access, and this pattern seems problematic when a clock is actually
> provided.
Thanks for a clear explanation! A couple of sentences to this effect in
the commit msg could help backporters understand the severity of the
issue.
> I have a few questions:
>
> 1. Is there a reason this hasn't been noticed before?
> As far as I can tell, there is currently no mainline device tree
> user that enables this driver on a platform with a real clock
> dependency. Out-of-tree users might be using it without any clock
> at all, or ACPI users might behave differently.
Ditto. I think we should drop the Fixes / CC: stable and instead
add a sentence that no upstream platform can currently trigger this.
> 2. Should we select PM in Kconfig and drop __maybe_unused from the
> PM callbacks? Since this driver relies on runtime PM for clock
> management, it seems odd to allow !PM builds.
I'm no PM expert but if it works for current users I don't see the need
to force the dependency?
> 3. Should we add a .remove callback to force suspend the device on
> unbind? Otherwise the clock might remain enabled if the driver is
> removed while active.
Embedded experts would have to chime in on this one. AFAIK this is a bit
of a gray area. Some users may want the link to stay up, eg to allow
WoL or avoid link training, maybe?
> I'm happy to send a follow-up patch addressing these points if you
> agree with the direction. Let me know what you think.
^ permalink raw reply
* Re: [PATCH net-next 7/9] net/ipv6: support RFC6724 rule 5.5 via subtrees
From: Simon Horman @ 2026-07-21 13:50 UTC (permalink / raw)
To: equinox
Cc: Simon Horman, pabeni, kuba, idosch, dsahern, davem, edumazet,
corbet, skhan, fmancera, lorenzo, maze, prohr, netdev, linux-doc,
linux-kselftest, furry13
In-Reply-To: <20260714094030.136317-8-equinox@diac24.net>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
https://sashiko.dev/#/patchset/20260714094030.136317-2-equinox@diac24.net?part=7
---
--- Patch [7]: [PATCH net-next 7/9] net/ipv6: support RFC6724 rule 5.5 via subtrees ---
commit 8c6cdd876548668f6d35fa2db4feb39f16c09a62
Author: David 'equinox' Lamparter <equinox@diac24.net>
net/ipv6: support RFC6724 rule 5.5 via subtrees
This commit implements RFC6724 rule 5.5 for IPv6 source address selection.
It introduces subtrees logic to prefer source addresses in a prefix advertised
by the chosen next-hop.
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 0ba46ed518a9a..f5c04928aa142 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
[ ... ]
> @@ -1593,6 +1595,80 @@ static bool ipv6_allow_optimistic_dad(const struct net *net,
> #endif
> }
>
> +/* "source address is preferable if the chosen nexthop advertised it as a PIO"
> + * => consider 'advertised as a PIO' to be 'the routes for the source's subtree
> + * include one with the same nexthop'
> + *
> + * NB: there is no backtracking in the subtree here, this is intentional -
> + * each prefix seen (and accepted) in PIOs creates essentially a "zone" which
> + * is our search scope.
> + */
> +static int ipv6_saddr_rule5p5(struct ipv6_saddr_score *score,
> + struct ipv6_saddr_dst *saddr_dst)
> +{
> + const struct rt6_info *rt, *cmp_rt;
> + struct dst_entry *cmp_dst;
> + struct fib6_info *f6i;
> + int ret = 0;
> +
> + rt = container_of(saddr_dst->dst, struct rt6_info, dst);
> +
> + /* fl6->saddr is ::, cf. check at the top of ipv6_common_get_saddr() */
> + saddr_dst->fl6->saddr = score->ifa->addr;
> + cmp_dst = ip6_route_output(saddr_dst->net, saddr_dst->sk,
> + saddr_dst->fl6);
[Severity: High]
When ipv6_saddr_rule5p5() passes the caller-provided saddr_dst->fl6 pointer
into ip6_route_output(), does this permanently alter the flow state?
ip6_route_output() calls ip6_route_output_flags_noref(), which
unconditionally mutates fields in the flow struct, such as setting
flowi6_iif to LOOPBACK_IFINDEX. It can also call l3mdev_update_flow()
to alter flowi6_oif.
Since the code only clears the injected saddr via memset() below, could this
cause silent corruption of the network flow state for subsequent lookups,
potentially breaking policy routing or VRF logic?
> + memset(&saddr_dst->fl6->saddr, 0, sizeof(saddr_dst->fl6->saddr));
> +
> + if (cmp_dst->error)
> + goto out_release_dst;
> +
> + cmp_rt = container_of(cmp_dst, struct rt6_info, dst);
> +
> + /* this must work if _any_ nexthop matches; the non-subtree best may
> + * not be in same order as subtree best
> + */
> + for (f6i = rcu_dereference(cmp_rt->from); f6i;
> + f6i = rcu_dereference(f6i->fib6_next)) {
> + struct fib6_nh *f6n = f6i->fib6_nh;
[Severity: High]
Can this cause a slab-out-of-bounds read if the route uses an external
nexthop?
When an IPv6 route is configured with an external nexthop, fib6_info_alloc()
allocates the fib6_info object without space for the inline fib6_nh flexible
array, and instead sets f6i->nh.
Is it safe to unconditionally dereference f6i->fib6_nh without checking if
f6i->nh is in use?
> + struct fib6_info *sibling;
> +
> + /* non-subtree route: says nothing about router advertising this source */
> + if (f6i->fib6_src.plen == 0)
> + continue;
> +
> + if (f6n->nh_common.nhc_dev != saddr_dst->dst->dev ||
> + f6n->nh_common.nhc_gw_family != AF_INET6)
> + continue;
> +
> + if (ipv6_addr_equal(&f6n->nh_common.nhc_gw.ipv6,
> + &rt->rt6i_gateway)) {
> + ret = 1;
> + goto out_release_dst;
> + }
> +
> + if (!f6i->fib6_nsiblings)
> + continue;
> +
> + list_for_each_entry(sibling, &f6i->fib6_siblings, fib6_siblings) {
[Severity: High]
Is this list traversal safe to perform without RCU primitives?
The fib6_siblings list is actively mutated by the routing subsystem using RCU
list primitives like list_add_tail_rcu() and list_del_rcu().
Since ipv6_saddr_rule5p5() is executed locklessly under the rcu_read_lock()
held by its caller, should this be using list_for_each_entry_rcu() to avoid
reading torn or uninitialized pointers on weakly ordered architectures?
> + f6n = sibling->fib6_nh;
[Severity: High]
Similar to the issue above, can this unconditionally access an unallocated
fib6_nh array if the sibling route uses an external nexthop?
> +
> + if (f6n->nh_common.nhc_dev != saddr_dst->dst->dev ||
> + f6n->nh_common.nhc_gw_family != AF_INET6)
> + continue;
> +
> + if (ipv6_addr_equal(&f6n->nh_common.nhc_gw.ipv6,
> + &rt->rt6i_gateway)) {
> + ret = 1;
> + goto out_release_dst;
> + }
> + }
> + }
> +
> +out_release_dst:
> + dst_release(cmp_dst);
> + return ret;
> +}
[ ... ]
^ permalink raw reply
* Re: [PATCH net-next 8/9] selftests: net: RFC6724 rule 5.5 tests
From: Simon Horman @ 2026-07-21 13:50 UTC (permalink / raw)
To: equinox
Cc: Simon Horman, pabeni, kuba, idosch, dsahern, davem, edumazet,
corbet, skhan, fmancera, lorenzo, maze, prohr, netdev, linux-doc,
linux-kselftest, furry13
In-Reply-To: <20260714094030.136317-9-equinox@diac24.net>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
https://sashiko.dev/#/patchset/20260714094030.136317-2-equinox@diac24.net?part=8
---
--- Patch [8]: [PATCH net-next 8/9] selftests: net: RFC6724 rule 5.5 tests ---
commit ae975bc04160e9173acb7759f9db7580aa0ca14e
Author: David 'equinox' Lamparter <equinox@diac24.net>
selftests: net: RFC6724 rule 5.5 tests
This commit introduces a new Python-based test script to verify IPv6 source
address selection logic, focusing on RFC6724 rule 5.5. It also enables
CONFIG_IPV6_SUBTREES in the net selftests config and wires up the script in
the Makefile.
> diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
> index 708d960ae07d5..c07d2aebad695 100644
> --- a/tools/testing/selftests/net/Makefile
> +++ b/tools/testing/selftests/net/Makefile
> @@ -53,6 +53,7 @@ TEST_PROGS := \
> ipv6_flowlabel.sh \
> ipv6_force_forwarding.sh \
> ipv6_route_update_soft_lockup.sh \
> + ipv6_saddr_rfc6724rule5p5.py \
> ipvtap_test.sh \
[ ... ]
> diff --git a/tools/testing/selftests/net/ipv6_saddr_rfc6724rule5p5.py b/tools/testing/selftests/net/ipv6_saddr_rfc6724rule5p5.py
> new file mode 100644
[Severity: Medium]
Since ipv6_saddr_rfc6724rule5p5.py is added to TEST_PROGS in the Makefile,
the kselftest framework expects it to be directly executable. However, it is
being created with mode 100644 instead of 100755.
Will this cause the test runner to skip the script or fail to execute it
during automated testing?
> index 0000000000000..682b39ba991da
> --- /dev/null
> +++ b/tools/testing/selftests/net/ipv6_saddr_rfc6724rule5p5.py
> @@ -0,0 +1,231 @@
> +#!/usr/bin/env python3
^ permalink raw reply
* Re: [PATCH net] net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()
From: Alexandra Winter @ 2026-07-21 13:54 UTC (permalink / raw)
To: Hidayath Khan, davem, edumazet, kuba, pabeni
Cc: horms, linux-s390, netdev, linux-kernel, twinkler, heiko.carstens,
gor, agordeev, borntraeger, svens
In-Reply-To: <20260709191732.124092-1-hidayath@linux.ibm.com>
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.
Kind regards
Alexandra
^ permalink raw reply
* Re: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
From: Simon Schippers @ 2026-07-21 14:04 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Willem de Bruijn, Jason Wang, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Simon Horman,
Jonathan Corbet, Shuah Khan, Andrew Lunn, Tim Gebauer,
Brett Sheffield, linux-doc, linux-kernel
In-Reply-To: <5016ae84-7049-4a5f-91c9-ba0047b06ee3@tu-dortmund.de>
On 7/14/26 18:50, Simon Schippers wrote:
> On 7/14/26 15:40, Michael S. Tsirkin wrote:
>> On Thu, Jul 09, 2026 at 11:55:11AM +0200, Simon Schippers wrote:
>>> Commit 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop
>>> when a qdisc is present") did not show a relevant performance regression
>>> in my testing but on Brett Sheffield's librecast testbed it shows a
>>> significant performance drop in a IPv6 multicast testcase. The regression
>>> can be pinpointed when multiple iperf3 TCP threads are sending. For 8
>>> threads the performance dropped from 13.5 Gbit/s to 9.13 Gbit/s. This is
>>> the reason why this patch makes the qdisc backpressure behavior opt-in.
>>>
>>> One option to accomplish the opt-in would be to set the default qdisc to
>>> noqueue at init. However this may also break userspace as users might
>>> have chosen a custom qdisc even though most of the qdiscs did nothing
>>> for tun/tap in the past due to missing backpressure...
>>>
>>> This is the reason why in this patch, the flag IFF_BACKPRESSURE is
>>> introduced instead which is required to enable the backpressure logic.
>>> This means the stopping logic in tun_net_xmit() and the waking logic in
>>> __tun_wake_queue() are skipped if the flag is disabled. Setting
>>> IFF_BACKPRESSURE makes an attached qdisc effective by stopping the queue
>>> instead of tail-dropping when the internal ring is full.
>>>
>>> To avoid a possible stall due to disabling IFF_BACKPRESSURE, the new
>>> helper tun_force_wake_queue() is implemented. The helper safely wakes the
>>> respective netdev queue and resets cons_cnt while the consumer_lock and
>>> the producer_lock of the ring are held. The helper is run in tun_attach()
>>> when a queue (re)attaches, in tun_set_iff() for attached tfiles, and
>>> in tun_queue_resize().
>>>
>>> The documentation in tuntap.rst is updated accordingly.
>>>
>>> Fixes: 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present")
>>> Reported-by: Brett Sheffield <brett@librecast.net>
>>> Closes: https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/T/#u
>>> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
>>
>>
>> The patch itself is fine:
>>
>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>>
>> What bothers me is the timing: we
>> are past freeze and this new interface hasn't been tested
>> much.
>>
>> We can either apply this, or revert the original patch for now
>> and reapply with this for next.
>
> I prefer applying it, but you maintainers must decide that.
>
Hi,
just a gentle ping.
Has there been any decision on this patch?
Thanks!
^ permalink raw reply
* [PATCH net 0/2] net: bridge: fix vlan range dumps starting with a PVID
From: Nikolay Aleksandrov @ 2026-07-21 14:09 UTC (permalink / raw)
To: netdev
Cc: Ido Schimmel, davem, edumazet, kuba, pabeni, horms, bridge,
Nikolay Aleksandrov
Hi,
Patch 01 fixes a bug that can skip dumping VLANs which a part of a range
starting with a PVID VLAN and share the same flags. PVID VLAN should be
always on its own. Patch 02 adds a selftest for this case. More information
can be found in the respective patches.
Thanks,
Nik
Nikolay Aleksandrov (2):
net: bridge: vlan: fix vlan range dumps starting with pvid
selftests: net: bridge: test ranges with PVID VLAN
net/bridge/br_netlink_tunnel.c | 3 ++-
net/bridge/br_private.h | 6 +++--
net/bridge/br_vlan.c | 10 ++++----
net/bridge/br_vlan_options.c | 3 +--
.../testing/selftests/net/bridge_vlan_dump.sh | 23 +++++++++++++++++++
5 files changed, 36 insertions(+), 9 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH net 1/2] net: bridge: vlan: fix vlan range dumps starting with pvid
From: Nikolay Aleksandrov @ 2026-07-21 14:09 UTC (permalink / raw)
To: netdev
Cc: Ido Schimmel, davem, edumazet, kuba, pabeni, horms, bridge,
Nikolay Aleksandrov
In-Reply-To: <20260721140922.682265-1-razor@blackwall.org>
There is a bug in all range dumps that rely on br_vlan_can_enter_range()
when the PVID is a range starting VLAN, all following VLANs that match
its flags can enter the range, but when the range is filled in only the
PVID VLAN is dumped and the rest of the range is discarded because
br_vlan_fill_vids() checks for the PVID flag. Since the PVID VLAN can
be only one, we need to break ranges around it, the best way to do that
consistently for all is to alter br_vlan_can_enter_range() to take into
account the PVID and return false to break the range when it's matched.
Before the fix:
$ ip l add br0 type bridge vlan_filtering 1
$ ip l add dumdum type dummy
$ ip l set dumdum master br0
$ ip l set br0 up
$ ip l set dumdum up
$ bridge vlan add dev dumdum vid 1 pvid untagged master
$ bridge vlan add dev dumdum vid 2 untagged master
$ bridge vlan show dev dumdum # use legacy dump to show all vlans
port vlan-id
dumdum 1 PVID Egress Untagged
2 Egress Untagged
$ bridge -d vlan show dev dumdum # use the new dump (RTM_GETVLAN)
port vlan-id
dumdum 1 PVID Egress Untagged
state forwarding mcast_router 1
VLAN 2 is missing, and if there are more matching VLANs afterwards
they'd be missing too.
After the fix:
[ same setup steps ]
$ bridge vlan show dev dumdum
port vlan-id
dumdum 1 PVID Egress Untagged
2 Egress Untagged
$ bridge -d vlan show dev dumdum # use the new dump (RTM_GETVLAN)
port vlan-id
dumdum 1 PVID Egress Untagged
state forwarding mcast_router 1
2 Egress Untagged
state forwarding mcast_router 1
Fixes: 0ab558795184 ("net: bridge: vlan: add rtm range support")
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
---
The change for the tunnel should add a separate notification for a PVID
VLAN which is fine because br_vlan_notify will properly fill in the pvid
flag for that VLAN.
net/bridge/br_netlink_tunnel.c | 3 ++-
net/bridge/br_private.h | 6 ++++--
net/bridge/br_vlan.c | 10 ++++++----
net/bridge/br_vlan_options.c | 3 +--
4 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/net/bridge/br_netlink_tunnel.c b/net/bridge/br_netlink_tunnel.c
index 71a12da30004..a713668ea34f 100644
--- a/net/bridge/br_netlink_tunnel.c
+++ b/net/bridge/br_netlink_tunnel.c
@@ -271,7 +271,8 @@ static void __vlan_tunnel_handle_range(const struct net_bridge_port *p,
if (!*v_start)
goto out_init;
- if (v && curr_change && br_vlan_can_enter_range(v, *v_end)) {
+ if (v && curr_change &&
+ br_vlan_can_enter_range(v, *v_end, br_get_pvid(vg))) {
*v_end = v;
return;
}
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index d55ea9516e3e..d3880f31edc4 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -1627,7 +1627,8 @@ void br_vlan_notify(const struct net_bridge *br,
u16 vid, u16 vid_range,
int cmd);
bool br_vlan_can_enter_range(const struct net_bridge_vlan *v_curr,
- const struct net_bridge_vlan *range_end);
+ const struct net_bridge_vlan *range_end,
+ u16 pvid);
void br_vlan_fill_forward_path_pvid(struct net_bridge *br,
struct net_device_path_ctx *ctx,
@@ -1874,7 +1875,8 @@ static inline void br_vlan_notify(const struct net_bridge *br,
}
static inline bool br_vlan_can_enter_range(const struct net_bridge_vlan *v_curr,
- const struct net_bridge_vlan *range_end)
+ const struct net_bridge_vlan *range_end,
+ u16 pvid)
{
return true;
}
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 5560afcaaca3..31c1b2cf75d9 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -1982,9 +1982,11 @@ void br_vlan_notify(const struct net_bridge *br,
/* check if v_curr can enter a range ending in range_end */
bool br_vlan_can_enter_range(const struct net_bridge_vlan *v_curr,
- const struct net_bridge_vlan *range_end)
+ const struct net_bridge_vlan *range_end,
+ u16 pvid)
{
- return v_curr->vid - range_end->vid == 1 &&
+ return v_curr->vid != pvid && range_end->vid != pvid &&
+ v_curr->vid - range_end->vid == 1 &&
range_end->flags == v_curr->flags &&
br_vlan_opts_eq_range(v_curr, range_end);
}
@@ -2066,8 +2068,8 @@ static int br_vlan_dump_dev(const struct net_device *dev,
idx += range_end->vid - range_start->vid + 1;
range_start = v;
- } else if (dump_stats || v->vid == pvid ||
- !br_vlan_can_enter_range(v, range_end)) {
+ } else if (dump_stats ||
+ !br_vlan_can_enter_range(v, range_end, pvid)) {
u16 vlan_flags = br_vlan_flags(range_start, pvid);
if (!br_vlan_fill_vids(skb, range_start->vid,
diff --git a/net/bridge/br_vlan_options.c b/net/bridge/br_vlan_options.c
index fcc200c3e3da..cb0f556ff40d 100644
--- a/net/bridge/br_vlan_options.c
+++ b/net/bridge/br_vlan_options.c
@@ -350,8 +350,7 @@ int br_vlan_process_options(const struct net_bridge *br,
continue;
}
- if (v->vid == pvid ||
- !br_vlan_can_enter_range(v, curr_end)) {
+ if (!br_vlan_can_enter_range(v, curr_end, pvid)) {
br_vlan_notify(br, p, curr_start->vid,
curr_end->vid, RTM_NEWVLAN);
curr_start = v;
--
2.47.3
^ permalink raw reply related
* [PATCH net 2/2] selftests: net: bridge: test ranges with PVID VLAN
From: Nikolay Aleksandrov @ 2026-07-21 14:09 UTC (permalink / raw)
To: netdev
Cc: Ido Schimmel, davem, edumazet, kuba, pabeni, horms, bridge,
Nikolay Aleksandrov
In-Reply-To: <20260721140922.682265-1-razor@blackwall.org>
Add a test with PVID VLAN that matches the flags of the VLAN following it
and check if the range is properly dumped. PVID VLAN should be on its own
and all VLANs should be present in the dump.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
---
.../testing/selftests/net/bridge_vlan_dump.sh | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/tools/testing/selftests/net/bridge_vlan_dump.sh b/tools/testing/selftests/net/bridge_vlan_dump.sh
index ad66731d2a6f..90e18e2104e3 100755
--- a/tools/testing/selftests/net/bridge_vlan_dump.sh
+++ b/tools/testing/selftests/net/bridge_vlan_dump.sh
@@ -13,6 +13,7 @@ ALL_TESTS="
vlan_range_mcast_max_groups
vlan_range_mcast_n_groups
vlan_range_mcast_enabled
+ vlan_range_pvid
"
setup_prepare()
@@ -191,6 +192,28 @@ vlan_range_mcast_enabled()
log_test "VLAN range grouping with mcast_enabled"
}
+vlan_range_pvid()
+{
+ RET=0
+
+ ip -n "$NS" link set dev br0 type bridge vlan_default_pvid 1
+ check_err $? "Failed to configure default PVID"
+ defer ip -n "$NS" link set dev br0 type bridge vlan_default_pvid 0
+
+ bridge -n "$NS" vlan add vid 2 dev dummy0 untagged
+ check_err $? "Failed to add VLAN 2"
+ defer bridge -n "$NS" vlan del vid 2 dev dummy0
+
+ bridge -n "$NS" -d vlan show dev dummy0 |
+ grep -Eq '(^|[[:space:]])2([[:space:]]|$)'
+ check_err $? "VLAN following PVID is missing from detailed dump"
+
+ bridge -n "$NS" -d vlan show dev dummy0 | grep -q "1-2"
+ check_fail $? "PVID was incorrectly included in a VLAN range"
+
+ log_test "PVID is isolated from VLAN dump ranges"
+}
+
# Verify the newest tested option is supported
if ! bridge vlan help 2>&1 | grep -q "neigh_suppress"; then
echo "SKIP: iproute2 too old, missing per-VLAN neighbor suppression support"
--
2.47.3
^ permalink raw reply related
* Re: [PATCH net-next] net/tcp: Prevent inlining tcp_syn_ack_timeout()
From: Eric Dumazet @ 2026-07-21 14:18 UTC (permalink / raw)
To: Paolo Abeni; +Cc: Emil Tsalapatis, netdev, ncardwell, kuniyu, davem, kuba
In-Reply-To: <6c01c713-14a8-43c2-aaaf-2fcf622f7e4f@redhat.com>
On Tue, Jul 21, 2026 at 3:24 PM Paolo Abeni <pabeni@redhat.com> 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???
Tracing has some merits that a MIB counter can not replace :)
Emil, next time add a link to the V1, this would have helped to
understand the motivation.
https://mail-archive.com/linux-trace-kernel@vger.kernel.org/msg24624.html
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next v5] net: phy: Add driver for Motorcomm Quad 2.5GbE phy
From: Andrew Lunn @ 2026-07-21 14:18 UTC (permalink / raw)
To: Kyle Switch
Cc: Frank.Sae, hkallweit1, linux, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, ming.xu, xiaolin.xu, jianmin.wang, jie.han
In-Reply-To: <20260721114810.660718-1-kyle.switch@motor-comm.com>
Just checking something here....
> +/**
> + * ytphy_write_top_ext() - write a PHY's top extended register for YT8824
> + * @phydev: a pointer to a &struct phy_device
> + * @regnum: register number to write
> + * @val: register val to write
> + *
> + * Returns: the value of regnum reg or negative error code
> + */
> +static int ytphy_write_top_ext(struct phy_device *phydev, u16 regnum,
> + u16 val)
> +{
> + int ret;
> +
> + lockdep_assert_held(&phydev->mdio.bus->mdio_lock);
> + ret = __phy_package_write(phydev, 0, YTPHY_PAGE_SELECT, regnum);
> + if (ret < 0)
> + return ret;
> +
> + return __phy_package_write(phydev, 0, YTPHY_PAGE_DATA, val);
The _top_ registers are in a different MDIO address, and are shared by
all PHYs within one package. Correct?
> +static int yt8824_write_page(struct phy_device *phydev, int page)
> +{
> + int old_page;
> + u16 data;
> +
> + old_page = ytphy_read_top_ext(phydev, YT8521_REG_SPACE_SELECT_REG);
> + data = old_page & (~YT8824_RSSR_SPACE_MASK);
> + data |= page;
> +
> + return ytphy_write_top_ext(phydev, YT8521_REG_SPACE_SELECT_REG, data);
The page register is in a top register. So when accessing a paged
register, all other PHYs also get swapped to that page. And so it is
necessary to block all other PHYs from accessing registers, until the
paged access if completed?
If i have that right, that is an odd hardware design. Since this is an
odd design, it deserves to be documented. Locking is hard, and it is
made harder by not having good documentation about the design of the
locking scheme.
> + old_page = phy_select_page(phydev, reg_space);
> + if (old_page < 0)
> + goto err_restore_page;
> +
> + if (reg_space == YT8824_RSSR_UTP_SPACE) {
> + ret = __phy_read_mmd(phydev, 0x1,
> + YT8824_UTP_TEMPLATE_MODE_CTRL);
What address spaces are paged? Every other design i've seen only has
pages of C22 registers, since you only have 32 of them. But looking at
this code, does this hardware also page C45?
Andrew
^ permalink raw reply
* [PATCH net] net/openvswitch: check Ethernet header length before key_extract()
From: Cen Zhang (Microsoft) @ 2026-07-21 14:36 UTC (permalink / raw)
To: aconole, echaudro, i.maximets, davem, edumazet, kuba, pabeni,
horms
Cc: netdev, dev, linux-kernel, AutonomousCodeSecurity, tgopinath, kys,
blbllhy
When a packet arrives on an ARPHRD_NONE device (e.g. TUN),
ovs_flow_key_extract() trusts the user-provided skb->protocol field: if
it is ETH_P_TEB, the packet is classified as MAC_PROTO_ETHERNET and
key_extract() is called without ensuring the skb has ETH_HLEN (14) bytes
of linear data. key_extract() unconditionally pulls 2 * ETH_ALEN bytes
for MAC addresses and parse_ethertype() pulls 2 more, either of which
triggers a kernel BUG in __skb_pull() when the linear area is too small.
kernel BUG at include/linux/skbuff.h:2848!
RIP: 0010:key_extract+0xa7e/0xd90 net/openvswitch/flow.c:933
ovs_flow_key_extract+0x419/0xa70
ovs_vport_receive+0x222/0x390
netdev_frame_hook+0x3e0/0x630
tun_get_user+0x2d0c/0x38e0
Fixed by adding check_header(skb, ETH_HLEN) in ovs_flow_key_extract()
before calling key_extract().
Fixes: 217ac77a3c25 ("openvswitch: allow L3 netdev ports")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com>
---
net/openvswitch/flow.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 66366982f604..a0f9d788d284 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -1035,6 +1035,13 @@ int ovs_flow_key_extract(const struct ip_tunnel_info *tun_info,
return res;
key->mac_proto = res;
+ if (res == MAC_PROTO_ETHERNET) {
+ int err = check_header(skb, ETH_HLEN);
+
+ if (unlikely(err))
+ return err;
+ }
+
#if IS_ENABLED(CONFIG_NET_TC_SKB_EXT)
if (tc_skb_ext_tc_enabled()) {
tc_ext = skb_ext_find(skb, TC_SKB_EXT);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v5 2/3] ptp: Add driver for R-Car Gen4
From: Vadim Fedorenko @ 2026-07-21 14:36 UTC (permalink / raw)
To: Niklas Söderlund, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Richard Cochran,
Andrew Lunn, DavidS. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-renesas-soc, devicetree, linux-kernel, netdev
In-Reply-To: <20260721132936.1331318-3-niklas.soderlund+renesas@ragnatech.se>
On 21/07/2026 14:29, Niklas Söderlund wrote:
> Add driver for the gPTP timer found on R-Car Gen4 devices. The timer is
> system-wide and shared by different Ethernet devices on each Gen4
> platform. The operation of the timer is however not completely in
> depended of the systems Ethernet devices.
>
> - On R-Car S4 is gated by the RSWITCH Ethernet module clock.
>
> - On R-Car V4H is gated by the RTSN Ethernet module clock.
>
> - On R-Car V4M is gated by its own module clock, the system have
> neither RTSN or RSWITCH device. But the module clock is the same as
> RTSN on V4H and the documentation referees to it as tsn (EtherTSN).
>
> The gPTP device do have its own register space on all three platforms.
> But on S4 and V4H it will share its clock and reset property with
> RSWITCH or RTSN, respectively.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> * Changes since v4
> - Drop mod_devicetable.h include.
> - Remove clap of register value as .max_adj prevents any overflow.
Hi Niklas!
Sorry for being silent for a while, was traveling a bit. Your
explanation about addend in v3 is good enough and proofs that
there will be no overflow for the values provided.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
^ permalink raw reply
* Re: [PATCH net-next 7/9] net/ipv6: support RFC6724 rule 5.5 via subtrees
From: David 'equinox' Lamparter @ 2026-07-21 14:37 UTC (permalink / raw)
To: Simon Horman
Cc: equinox, pabeni, kuba, idosch, dsahern, davem, edumazet, corbet,
skhan, fmancera, lorenzo, maze, netdev, linux-doc,
linux-kselftest, furry13
In-Reply-To: <20260721135013.387122-2-horms@kernel.org>
Hi Simon,
On Tue, Jul 21, 2026 at 02:50:14PM +0100, Simon Horman wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> https://sashiko.dev/#/patchset/20260714094030.136317-2-equinox@diac24.net?part=7
Thanks for forwarding the Sashiko reports, I was already aware of them & am almost done addressing them. The external nexthop stuff is "inapplicable" since the kernel refuses subtree routes with nexthop objects, but I've made that more explicit. Other than that it's relatively simple oversights on my end.
I just need to make it pretty & hit send, I'll hopefully get to it tomorrow.
Cheers,
-equi
^ permalink raw reply
* Re: [PATCH net-next v2 12/14] gpio: tc956x: add TC956x/QPS615 support
From: Manivannan Sadhasivam @ 2026-07-21 14:43 UTC (permalink / raw)
To: Alex Elder
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, daniel, mohd.anwar, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, mcoquelin.stm32, me, prabhakar.mahadev-lad.rj,
richardcochran, rohan.g.thomas, sdf, siyanteng, weishangjuan,
wens, netdev, bpf, linux-arm-msm, devicetree, linux-gpio,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <df217d83-272a-4d4c-8aba-a87e4b8869fc@riscstar.com>
On Thu, Jul 16, 2026 at 11:24:15AM -0500, Alex Elder wrote:
> On 7/16/26 2:02 AM, Manivannan Sadhasivam wrote:
> > On Thu, Jun 04, 2026 at 08:00:19PM -0500, Alex Elder wrote:
> > > Toshiba TC956x is an Ethernet-AVB/TSN bridge and is essentially
> > > a small and highly-specialized SoC. TC956x includes a GPIO block that
> > > can be accessed, alongside several other peripherals, via two PCIe
> > > endpoint functions. The PCIe function driver creates an auxiliary
> > > device for the GPIO block, and that device gets bound to this auxiliary
> > > device driver.
> > >
> > > This driver is implemented using the generic regmap-based GPIO driver.
> > >
> >
> > While the regmap over the switch BAR works for GPIO access post-enumeration,
> > there is a blocker in using these GPIOs to control the power to endpoints.
>
> We're aware of the power control driver and its use of these GPIOs.
>
> I think the point you're making is not about the specific way we
> are using GPIOs, but that someone could try to use this GPIO
> controller in a way that would lead to a circular dependency
> (between the controller and the PCIe device it depends on).
>
This not a future problem, but a present one :)
> And you suggest a GPIO driver that uses I2C (and would be
> used by the pwrctrl driver as well), and I think it's a pretty
> reasonable suggestion.
>
> > We have a design [1] where the GPIOs from the switch are used to control power
> > and PERST# signals to the EP. With this current design, during the initial PCI
> > bus scan, the switch will get enumerated, but the EP will not. Because, power to
> > the EP depends on the GPIO Aux driver that will get probed only after the switch
> > enumeration.
>
> Yes, on the RB3gen2 platform, reset signals (PERST#) for two of
> the TC9563 PCIe switch ports (downstream 1 and downstream 2) are
> managed by the GPIO controller that resides within the TC9563
> itself. The pwrctl driver takes special care to ensure the GPIO
> controller is functional (powered) before trying to use it.
>
> The TC9563 *chip* gets powered when its embedded PCIe switch is
> probed--that is, when its upstream port begins its enumeration.
> (It's a little unclear to me which of the supplies are required
> for the various non-PCIe components on the chip, including I2C
> and GPIO, to be functional.)
>
Well, the TC9563 should get powered ON when its pwrctrl driver gets probed and
the pci_pwrctrl_power_on_device() is called. There is no dependency with the
upstream port enumeration AFAIK.
> And so until the switch gets probed (and its pwrctl driver used),
> the GPIO controller can't work. So nothing internal to the TC956x should be
> dependent on any of the GPIOs supplied by this controller.
> (Except the pwrctrl driver, which enables power before using GPIO.)
>
>
> Two things to note:
> - We are working with TC9564 (and there are other successors in
> the TC956x series).
> - Downstream port 3 (which we are using) on the switch does not
> have such a distinct controlled reset line.
>
> > But this creates a chicken-and-egg problem with the PCI Pwrctrl design.
> > pcie-qcom driver uses the Pwrctrl framework to power on the PCI endpoints before
> > the initial PCI bus scan. It calls pci_pwrctrl_create_devices() and
> > pci_pwrctrl_power_on_devices() APIs to create the platform device for all PCI
> > devices defined in DT (that require pwrctrl support), waits for their respective
> > pwrctrl drivers to get probed and then power ON all of them.
>
> The way I understood it was that certain parameters for the PCIe
> links needed to be set before using them, and the pwrctrl framework
> made that possible. (I summarize what that driver does at the end
> of this message.)
>
Yeah, it does handle both power ON and some configuration for stable operation.
> This step is
> > required because in DT platforms, many Root Ports are not hotplug capable and
> > also BIOS doesn't assign bridge windows during boot. So all the devices has to
> > appear during the initial PCI bus scan so that the PCI core can allocate the
> > resources properly.
>
> This part I didn't know before. Yes, the bridge windows are
> allocated by Linux rather than by firmware. And if this host
> bridge doesn't support hotplug, then yes, to correctly assign
> address space, all PCIe devices must be available to report
> their required memory space.
>
> Are you saying that "setting those parameters" wouldn't be
> needed if this particular root port supported hotplug? (I'm
> just curious; it's not relevant to the point you're making.)
>
Yeah, more or less. If the Root Port is hotplug capable, PCI core will allocate
more resources like bridge windows and bus numbers in anticipation of devices
getting attached to it after boot. But that also sometimes becomes insufficient
if a resource hungry device like GPU gets plugged in later, as the PCI core can
only guess the memory for hotplug capable Root Port.
> > Now the issue with this Aux driver design is that, if an EP makes use of the
> > switch GPIO for PERST# or power, like:
> >
> > tc9563: pcie@0,0 {
> > compatible = "pci1179,0623";
> > reg = <0x10000 0x0 0x0 0x0 0x0>;
> > ...
> >
> > pcie@1,0 {
> > compatible = "pciclass,0604";
> > reg = <0x20800 0x0 0x0 0x0 0x0>;
> > #address-cells = <3>;
> > #size-cells = <2>;
> >
> > device_type = "pci";
> > ranges;
> > bus-range = <0x3 0xff>;
> >
> > reset-gpios = <&tc9563 5 GPIO_ACTIVE_LOW>;
> > };
> > ...
> >
> > };
> >
> > Then the pwrctrl driver (pci/pwrctrl/generic.c) will try to acquire the GPIO
> > controller during its probe, but will fail with -EPROBE_DEFER as the GPIO
> > controller won't be available at that time. So the whole PCIe instance will
> > probe defer as the driver requires all pwrctrl drivers to be probed before
> > starting the initial bus scan.
>
> The only GPIOs we're using are for asserting reset on the two
> Ethernet PHYs. That doesn't occur until after the embedded
> endpoint functions are probed, so this should be OK.
>
> However you're right, the lines on this GPIO controller should
> be restricted to avoid this circular dependency.
> > So we need to make sure that the GPIO controller driver is available before
> > enumerating the switch device. One way to achieve is by creating the GPIO Aux
> > device in the pci/pwrctrl/pci-pwrctrl-tc9563.c driver and let the GPIO
> > controller driver use I2C communication for setting up the GPIOs. Thankfully,
> > the switch allows both I2C and BAR MMIO configurations for internal GPIOs.
>
> Daniel and I have talked about this solution exactly, but opted
> not to propose using it just yet (not unless someone like you
> suggested it...). Our solution for now was just to have the
> (PCIe BAR-based) GPIO driver reserve the two GPIO lines used by
> the pwrctrl driver, and rely on the fact that the pwrctrl driver
> will only touch those shared registers at times the "real" GPIO
> driver does not.
>
Yeah. If those GPIO lines are not used to power up any endpoint devices, then
there should be no issues. But this is something we cannot control as the board
designers can do whatever they want.
>
> We could instead implement a "proper" I2C-based GPIO controller
> driver. This would be used by the pwrctrl driver (rather than
> that driver just updating the registers directly), as well as
> the Ethernet PHY for reset control, and for any other uses on
> future platforms.
>
Sounds like a plan.
> All uses so far are for managing resets, so the higher I2C
> latency wouldn't be much of an issue.
>
> > With this change, the GPIO driver will get probed by the time the pwrctrl
> > generic driver acquires the 'reset-gpios' and will turn ON the EP.
>
> One thing I'll point out is that the next version of this
> code will define "pci-ep-bus" nodes, and will not use the
> auxiliary bus model. However the issue you raise remains
> in that model too.
>
Please do CC me on the upcoming versions as well.
> Thank you very much for raising this Mani. Please see my
> questions a little further below.
>
> -Alex
>
> > Let me know your thoughts!
> >
> > - Mani
> >
> > [1] https://lore.kernel.org/linux-pci/e2inl7k5gsjj6oomv2k5ximuzpb3gfiz66ufet3b4hvov7zqt4@qz4pifbos7yf/
>
>
> Here's what the pwrctrl driver does:
>
> In drivers/pci/pwrctrl/pci-pwrctrl-tc9563.c, the registers at
> offset 0x1208 and 0x1210 from the base of the "SFR" address space
> are updated to assert/deassert these two reset signals. It does
> so using the I2C interface--out of band from access via PCI BARs.
> The reset signals are GPIO02 (for downstream endpoint 1 on the
> switch) and GPIO03 (for endpoint 2), which are controlled by
> bits 2 and 3 in the two registers, respectively.
>
> The pwrctrl driver enables a set of regulators defined in the
> devicetree node for the upstream port of the TC9564 embedded
> PCIe switch. It then asserts the main RESX (chip) reset signal,
> and after a short delay asserts these other two resets.
>
> At that point it uses properties defined in devicetree to
> configure five "ports": upstream, downstream 1-3, and Ethernet.
> (I have some questions related to this--but I put them below.)
> The properties configured are: ASPM L0s entry delay; ASP L1 entry
> delay; TX amplitude; Number of Fast Training Sequences (NTFS); and Decision
> Feedback Equalization (DFE).
>
The driver confuses between ports and endpoint. TC9563_ETHERNET is not a port,
but an integrated endpoint. I've identified some issues while reviewing it now.
Will try to fix them asap.
> Finally, the two resets and the main RESX reset are deasserted,
> and the driver reports that the device is now ready, with:
> devm_pci_pwrctrl_device_set_ready();
>
>
>
> Questions related to the "ports" configured by the pwrctrl driver:
> - Given that downstream port 3 connects to the internal, embedded
> PCIe endpoint, does it still require these settings programmed?
>
Not all of the settings are applicable to all ports. Only ASPM and N_FTS are
applicable to all ports and endpoints, but the rest are optional. But the driver
treats all properties mandatory for all ports/endpoint, and safeguards itself by
having some absurd checks. This is something I'm going to fix.
> - Does the TC9563 chip have only *one* function on its embedded
> endpoint, supporting just one Ethernet?
> - If so, this driver will have to be modified to support
> the second embedded function and Ethernet controller.
>
The driver assumes only one endpoint, but the binding lists 2. So the driver is
not complying with its own binding now :/
So technically, the driver supports 2 integrated endpoints.
> - Why is "Ethernet" configured like the PCIe ports, *in addition*
> to the downstream port 3 that it sits behind?
>
Both ASPM and N_FTS properties are applicable to ports and integrated endpoints
as well. But other 2, DFE and Tx Amplitude are only applicable to ports only,
excluding DSP3.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH net-next] ipv6: initialize ipcm6_cookie before parsing control messages
From: Fernando Fernandez Mancera @ 2026-07-21 14:45 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178358611790.128118.11036367713019213946@gmail.com>
On Thu, 09 Jul 2026 16:32:30 +0800, Wayen Yan <win847@gmail.com> wrote:
> ip6_datagram_send_ctl() parses both SOL_IPV6 and SOL_SOCKET control
> messages. For SOL_SOCKET messages it passes ipc6->sockc to
> __sock_cmsg_send(), which updates fields such as tsflags with
> read-modify-write operations.
>
> The IPV6_2292PKTOPTIONS and flowlabel option paths only set ipc6.opt
> before calling ip6_datagram_send_ctl(). If a SOL_SOCKET control message
> such as SO_TIMESTAMPING_* or SCM_TS_OPT_ID is present, this can read
> uninitialized sockc state.
>
> Initialize the ipcm6_cookie with ipcm6_init_sk(), as the normal IPv6
> sendmsg paths do, before overriding ->opt with the temporary option
> buffer.
>
> Signed-off-by: Wayen Yan <win847@gmail.com>
>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Thanks!
^ permalink raw reply
* Re: [PATCH net-next] ipv6: initialize ipcm6_cookie before parsing control messages
From: Fernando Fernandez Mancera @ 2026-07-21 14:47 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: Wayen Yan, netdev, lorenzo, horms, pabeni, kuba, edumazet,
andrew+netdev, angelogioacchino.delregno, matthias.bgg,
linux-arm-kernel, linux-mediatek
In-Reply-To: <178464510579.7763.6518393222506443032.b4-review@b4>
On 2026-07-21 16:45 +0200, Fernando Fernandez Mancera wrote:
> On Thu, 09 Jul 2026 16:32:30 +0800, Wayen Yan <win847@gmail.com> wrote:
> > ip6_datagram_send_ctl() parses both SOL_IPV6 and SOL_SOCKET control
> > messages. For SOL_SOCKET messages it passes ipc6->sockc to
> > __sock_cmsg_send(), which updates fields such as tsflags with
> > read-modify-write operations.
> >
> > The IPV6_2292PKTOPTIONS and flowlabel option paths only set ipc6.opt
> > before calling ip6_datagram_send_ctl(). If a SOL_SOCKET control message
> > such as SO_TIMESTAMPING_* or SCM_TS_OPT_ID is present, this can read
> > uninitialized sockc state.
> >
> > Initialize the ipcm6_cookie with ipcm6_init_sk(), as the normal IPv6
> > sendmsg paths do, before overriding ->opt with the temporary option
> > buffer.
> >
> > Signed-off-by: Wayen Yan <win847@gmail.com>
> >
>
> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
>
> Thanks!
Now that I think about it, shouldn't this go to net tree with a proper
fixes tag?
^ permalink raw reply
* Re: [PATCH net v2] psp: fix NULL genl_sock deref race with concurrent netns teardown
From: Jakub Kicinski @ 2026-07-21 14:52 UTC (permalink / raw)
To: Kiran Kella
Cc: daniel.zahka, willemdebruijn.kernel, davem, edumazet, pabeni,
horms, weibunny, netdev, linux-kernel, jayakrishnan.udayavarma,
ajit.khaparde, akhilesh.samineni, Vikas Gupta, Bhargava Marreddy,
Daniel Zahka
In-Reply-To: <20260707185937.3177211-1-kiran.kella@broadcom.com>
On Tue, 7 Jul 2026 11:59:37 -0700 Kiran Kella wrote:
> The race occurs between network namespace removal and PSP device
> unregistration. When a netns is deleted while a PSP device associated
> with that netns is concurrently being removed, psp_dev_unregister()
> triggers psp_nl_notify_dev() to send a device change notification.
> Concurrently, cleanup_net() running in the netns workqueue calls
> genl_pernet_exit(), which sets net->genl_sock to NULL. If
> genl_pernet_exit() wins the race, two sites in psp_nl_multicast_per_ns()
> then dereference the NULL socket and crash:
>
> CPU 0 (netns teardown) CPU 1 (PSP device unregister)
> ====================== =============================
> cleanup_net [workqueue]
> genl_pernet_exit() psp_dev_unregister()
> net->genl_sock = NULL psp_nl_notify_dev()
> psp_nl_multicast_per_ns()
> build_ntf()
> -> netlink_has_listeners(NULL)
> /* crash */
> genlmsg_multicast_netns()
> -> nlmsg_multicast_filtered(NULL)
> /* crash */
Can you explain how you hit this, in reality? Seems like an extreme
corner case to me.
> Both the main_net path (derived from psd->main_netdev) and each
> assoc_net entry in psd->assoc_dev_list are affected.
I don't see how assoc_dev_list is affected. Assoc dev list has
a notifier which should serialize the netdev unreg on psd->lock.
And netdev unreg must happen before the netns dismantle.
> Fix by replacing the bare dev_net() calls with maybe_get_net().
> maybe_get_net() returns NULL if the namespace is already dying.
> Holding the reference ensures genl_sock remains valid across both the
> build_ntf() and genlmsg_multicast_netns() calls.
>
> Fixes: 00c94ca2b99e ("psp: base PSP device support")
> Fixes: 06c2dce2d0f6 ("psp: add new netlink cmd for dev-assoc and dev-disassoc")
> Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Reviewed-by: Vikas Gupta <vikas.gupta@broadcom.com>
> Reviewed-by: Bhargava Marreddy <bhargava.marreddy@broadcom.com>
> Reviewed-by: Akhilesh Samineni <akhilesh.samineni@broadcom.com>
> Reviewed-by: Daniel Zahka <daniel.zahka@broadcom.com>
> Tested-by: Daniel Zahka <daniel.zahka@broadcom.com>
> Signed-off-by: Kiran Kella <kiran.kella@broadcom.com>
> ---
> v2:
> - get rid of the extra struct net *net, by doing
> (!maybe_get_net(assoc_net)) directly (as suggested by Daniel Zahka)
>
> v1: https://lore.kernel.org/all/20260703112431.2860506-1-kiran.kella@broadcom.com/
>
> net/psp/psp_nl.c | 23 ++++++++++++++---------
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/net/psp/psp_nl.c b/net/psp/psp_nl.c
> index 9610d8c456ff..1438dbb07949 100644
> --- a/net/psp/psp_nl.c
> +++ b/net/psp/psp_nl.c
> @@ -62,7 +62,10 @@ psp_nl_multicast_per_ns(struct psp_dev *psd, unsigned int group,
> struct net *main_net;
> struct sk_buff *ntf;
>
> - main_net = dev_net(psd->main_netdev);
comment like:
/* device may be changing netns in parallel */
> + main_net = maybe_get_net(dev_net(psd->main_netdev));
not sure how the dev_net() is safe here if we're not holding any
relevant lock. Do we need rcu?
> + if (!main_net)
> + return;
> +
> xa_init(&sent_nets);
>
> list_for_each_entry(entry, &psd->assoc_dev_list, dev_list) {
> @@ -77,21 +80,23 @@ psp_nl_multicast_per_ns(struct psp_dev *psd, unsigned int group,
> if (ret == -EBUSY)
> continue;
>
> - ntf = build_ntf(psd, assoc_net, ctx);
> - if (!ntf)
> + if (!maybe_get_net(assoc_net))
> continue;
AFAICT we clear the psd on netns move for assoc dev so I don't think
this is needed today.
> - genlmsg_multicast_netns(&psp_nl_family, assoc_net, ntf, 0,
> - group, GFP_KERNEL);
> + ntf = build_ntf(psd, assoc_net, ctx);
> + if (ntf)
> + genlmsg_multicast_netns(&psp_nl_family, assoc_net, ntf,
> + 0, group, GFP_KERNEL);
> + put_net(assoc_net);
> }
> xa_destroy(&sent_nets);
>
> /* Send to main device netns */
> ntf = build_ntf(psd, main_net, ctx);
> - if (!ntf)
> - return;
> - genlmsg_multicast_netns(&psp_nl_family, main_net, ntf, 0, group,
> - GFP_KERNEL);
> + if (ntf)
> + genlmsg_multicast_netns(&psp_nl_family, main_net, ntf, 0, group,
> + GFP_KERNEL);
> + put_net(main_net);
> }
>
> static struct sk_buff *psp_nl_clone_ntf(struct psp_dev *psd, struct net *net,
^ permalink raw reply
* Re: [PATCH net-next v6 2/2] net: dsa: realtek: rtl8365mb: add HSGMII support for RTL8367S
From: Mieczyslaw Nalewaj @ 2026-07-21 14:32 UTC (permalink / raw)
To: contact, Linus Walleij, Alvin Šipraga, Andrew Lunn,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Russell King
Cc: Maxime Chevallier, Luiz Angelo Daros de Luca, netdev,
linux-kernel
In-Reply-To: <20260711-rtl8367s-sgmii-v6-2-88f7944ddca7@c127.dev>
On 7/12/2026 6:31 AM, Johan Alvarado via B4 Relay wrote:
> From: Johan Alvarado <contact@c127.dev>
>
> In addition to SGMII, the RTL8367S SerDes also supports HSGMII, which
> carries 2.5 Gbps with the same signaling as SGMII at 2.5x clock rate.
> The chip info table already declares HSGMII as a supported interface
> mode for external interface 1.
>
> Extend the SerDes PCS to handle HSGMII, which phylink represents as
> 2500base-x:
>
> - Select the HSGMII SerDes tuning parameters and external interface
> mode, and mux the SerDes to MAC8 in HSGMII mode, from pcs_config()
> according to the interface. The parameters are again lifted from the
> GPL-licensed Realtek rtl8367c vendor driver, and again only cover
> the tuning variant for a non-zero chip option, so the mode is gated
> on the option probed at setup.
>
[...]
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
^ permalink raw reply
* Re: [PATCH net v3] psp: fix NULL genl_sock deref race with concurrent netns teardown
From: Jakub Kicinski @ 2026-07-21 14:53 UTC (permalink / raw)
To: Kiran Kella
Cc: daniel.zahka, willemdebruijn.kernel, davem, edumazet, pabeni,
horms, weibunny, netdev, linux-kernel, jayakrishnan.udayavarma,
ajit.khaparde, akhilesh.samineni, Vikas Gupta, Bhargava Marreddy
In-Reply-To: <20260715110701.3775026-1-kiran.kella@broadcom.com>
On Wed, 15 Jul 2026 04:07:01 -0700 Kiran Kella wrote:
> Subject: [PATCH net v3] psp: fix NULL genl_sock deref race with concurrent netns teardown
Missed this, same questions as v2:
https://lore.kernel.org/all/20260721075252.1d577783@kernel.org/
^ permalink raw reply
* Re: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
From: Michael S. Tsirkin @ 2026-07-21 14:59 UTC (permalink / raw)
To: Simon Schippers
Cc: Willem de Bruijn, Jason Wang, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Simon Horman,
Jonathan Corbet, Shuah Khan, Andrew Lunn, Tim Gebauer,
Brett Sheffield, linux-doc, linux-kernel
In-Reply-To: <5089fc5e-2fb8-41fb-9aab-42b22cc2c201@tu-dortmund.de>
On Tue, Jul 21, 2026 at 04:04:33PM +0200, Simon Schippers wrote:
> On 7/14/26 18:50, Simon Schippers wrote:
> > On 7/14/26 15:40, Michael S. Tsirkin wrote:
> >> On Thu, Jul 09, 2026 at 11:55:11AM +0200, Simon Schippers wrote:
> >>> Commit 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop
> >>> when a qdisc is present") did not show a relevant performance regression
> >>> in my testing but on Brett Sheffield's librecast testbed it shows a
> >>> significant performance drop in a IPv6 multicast testcase. The regression
> >>> can be pinpointed when multiple iperf3 TCP threads are sending. For 8
> >>> threads the performance dropped from 13.5 Gbit/s to 9.13 Gbit/s. This is
> >>> the reason why this patch makes the qdisc backpressure behavior opt-in.
> >>>
> >>> One option to accomplish the opt-in would be to set the default qdisc to
> >>> noqueue at init. However this may also break userspace as users might
> >>> have chosen a custom qdisc even though most of the qdiscs did nothing
> >>> for tun/tap in the past due to missing backpressure...
> >>>
> >>> This is the reason why in this patch, the flag IFF_BACKPRESSURE is
> >>> introduced instead which is required to enable the backpressure logic.
> >>> This means the stopping logic in tun_net_xmit() and the waking logic in
> >>> __tun_wake_queue() are skipped if the flag is disabled. Setting
> >>> IFF_BACKPRESSURE makes an attached qdisc effective by stopping the queue
> >>> instead of tail-dropping when the internal ring is full.
> >>>
> >>> To avoid a possible stall due to disabling IFF_BACKPRESSURE, the new
> >>> helper tun_force_wake_queue() is implemented. The helper safely wakes the
> >>> respective netdev queue and resets cons_cnt while the consumer_lock and
> >>> the producer_lock of the ring are held. The helper is run in tun_attach()
> >>> when a queue (re)attaches, in tun_set_iff() for attached tfiles, and
> >>> in tun_queue_resize().
> >>>
> >>> The documentation in tuntap.rst is updated accordingly.
> >>>
> >>> Fixes: 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present")
> >>> Reported-by: Brett Sheffield <brett@librecast.net>
> >>> Closes: https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/T/#u
> >>> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
> >>
> >>
> >> The patch itself is fine:
> >>
> >> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> >>
> >> What bothers me is the timing: we
> >> are past freeze and this new interface hasn't been tested
> >> much.
> >>
> >> We can either apply this, or revert the original patch for now
> >> and reapply with this for next.
> >
> > I prefer applying it, but you maintainers must decide that.
> >
>
> Hi,
> just a gentle ping.
> Has there been any decision on this patch?
>
> Thanks!
Hi netdev maintainers. Given there's a perf regression otherwise,
we should either take this or revert the original and reapply
in next.
Thanks!
--
MST
^ permalink raw reply
* Re: [PATCH] net: pcs: xpcs-plat: fix runtime PM initialization
From: Maxime Chevallier @ 2026-07-21 15:00 UTC (permalink / raw)
To: Jakub Kicinski, Coia Prant
Cc: netdev, Andrew Lunn, Heiner Kallweit, Russell King,
David S . Miller, Eric Dumazet, Paolo Abeni, Serge Semin,
linux-kernel, stable
In-Reply-To: <20260721064910.217a6af7@kernel.org>
>> 3. Should we add a .remove callback to force suspend the device on
>> unbind? Otherwise the clock might remain enabled if the driver is
>> removed while active.
>
> Embedded experts would have to chime in on this one. AFAIK this is a bit
> of a gray area. Some users may want the link to stay up, eg to allow
> WoL or avoid link training, maybe?
Avoiding link flaps/training is mostly a concern at boot time if the
bootloader set everything up beforehand, but I'd say for unbinding,
this should be OK and would mirror the probe.
Maxime
^ permalink raw reply
* Re: [PATCH net-next v6 1/2] net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S
From: Mieczyslaw Nalewaj @ 2026-07-21 14:32 UTC (permalink / raw)
To: contact, Linus Walleij, Alvin Šipraga, Andrew Lunn,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Russell King
Cc: Maxime Chevallier, Luiz Angelo Daros de Luca, netdev,
linux-kernel
In-Reply-To: <20260711-rtl8367s-sgmii-v6-1-88f7944ddca7@c127.dev>
On 7/12/2026 6:31 AM, Johan Alvarado via B4 Relay wrote:
> From: Johan Alvarado <contact@c127.dev>
>
> The RTL8367S can mux its embedded SerDes to external interface 1,
> which is typically used to connect the switch to a CPU port. The chip
> info table already declares SGMII as a supported interface mode for
> this chip, but the driver only implements RGMII so far.
>
> Implement SGMII support as a phylink PCS, with the configuration
> sequence derived from the GPL-licensed Realtek rtl8367c vendor driver
> as distributed in the Mercusys MR80X GPL code drop:
>
[...]
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
^ permalink raw reply
* [PATCH v3 net-next] ethtool: link 10000baseCR to SFF-8431, Appendix-E SFP+ DA
From: Siddaraju DH @ 2026-07-21 15:06 UTC (permalink / raw)
To: Michal Kubecek, Andrew Lunn, Maxime Chevallier, kuba, netdev
Cc: Shubham Das, Balaji Chintalapalle, Vijay Srinivasan,
Magnus Lindberg, Niklas Damberg, Jonas Wirandi, Siddaraju DH,
Siddaraju DH
Add comment to clarify the physical media 10000baseCR follows.
10000baseCR does not correspond to any IEEE 802.3 *base-CR PMD.
It has no autonegotiation, no link training, and no mandatory FEC.
The industry standard for this media type is SFF-8431 Appendix-E
Direct Attach cable, also known as 10G_SFI_DA.
Link: https://lore.kernel.org/r/SN7PR11MB69003D33489DB1D6B17EF72A9AF52@SN7PR11MB6900.namprd11.prod.outlook.com
Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
include/uapi/linux/ethtool.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index a2091d4e00f3..986d70caec33 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -2013,7 +2013,13 @@ enum ethtool_link_mode_bit_indices {
ETHTOOL_LINK_MODE_100000baseLR4_ER4_Full_BIT = 39,
ETHTOOL_LINK_MODE_50000baseSR2_Full_BIT = 40,
ETHTOOL_LINK_MODE_1000baseX_Full_BIT = 41,
+
+ /* Despite the "baseCR" in 10000baseCR, this is not an IEEE 802.3 baseCR
+ * It represents SFF-8431 Appendix-E SFP+ Direct Attach (10G-SFI-DA).
+ * The name is kept as-is for uAPI backward compatibility.
+ */
ETHTOOL_LINK_MODE_10000baseCR_Full_BIT = 42,
+
ETHTOOL_LINK_MODE_10000baseSR_Full_BIT = 43,
ETHTOOL_LINK_MODE_10000baseLR_Full_BIT = 44,
ETHTOOL_LINK_MODE_10000baseLRM_Full_BIT = 45,
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v14 00/15] net: introduce QUIC infrastructure and core subcomponents
From: Xin Long @ 2026-07-21 15:09 UTC (permalink / raw)
To: network dev, quic
Cc: davem, kuba, Eric Dumazet, Paolo Abeni, Simon Horman,
Stefan Metzmacher, Moritz Buhl, Tyler Fanelli, Pengtao He,
Thomas Dreibholz, linux-cifs, Steve French, Namjae Jeon,
Tom Talpey, kernel-tls-handshake, Chuck Lever, Jeff Layton,
Steve Dickson, Hannes Reinecke, Alexander Aring, David Howells,
Matthieu Baerts, John Ericson, Cong Wang, D . Wythe, Jason Baron,
illiliti, Sabrina Dubroca, Marcelo Ricardo Leitner,
Daniel Stenberg, Andy Gospodarek, mef, paul
In-Reply-To: <cover.1784147238.git.lucien.xin@gmail.com>
On Wed, Jul 15, 2026 at 4:32 PM Xin Long <lucien.xin@gmail.com> wrote:
>
> Introduction
> ============
>
> The QUIC protocol, defined in RFC 9000, is a secure, multiplexed transport
> built on top of UDP. It enables low-latency connection establishment,
> stream-based communication with flow control, and supports connection
> migration across network paths, while ensuring confidentiality, integrity,
> and availability.
>
> This implementation introduces QUIC support in Linux Kernel, offering
> several key advantages:
>
> - In-Kernel QUIC Support for Subsystems: Enables kernel subsystems
> such as SMB and NFS to operate over QUIC with minimal changes. Once the
> handshake is complete via the net/handshake APIs, data exchange proceeds
> over standard in-kernel transport interfaces.
>
> - Standard Socket API Semantics: Implements core socket operations
> (listen(), accept(), connect(), sendmsg(), recvmsg(), close(),
> getsockopt(), setsockopt(), getsockname(), and getpeername()),
> allowing user space to interact with QUIC sockets in a familiar,
> POSIX-compliant way.
>
> - ALPN-Based Connection Dispatching: Supports in-kernel ALPN
> (Application-Layer Protocol Negotiation) routing, allowing demultiplexing
> of QUIC connections across different user-space processes based
> on the ALPN identifiers.
>
> - Performance Enhancements: Handles all control messages in-kernel
> to reduce syscall overhead, incorporates zero-copy mechanisms such as
> sendfile() to minimize data movement, and is also structured to support
> future crypto hardware offloads.
>
> This implementation offers fundamental support for the following RFCs:
>
> - RFC9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
> - RFC9001 - Using TLS to Secure QUIC
> - RFC9002 - QUIC Loss Detection and Congestion Control
> - RFC9221 - An Unreliable Datagram Extension to QUIC
> - RFC9287 - Greasing the QUIC Bit
> - RFC9368 - Compatible Version Negotiation for QUIC
> - RFC9369 - QUIC Version 2
>
> The socket APIs for QUIC follow the RFC draft [1]:
>
> - The Sockets API Extensions for In-kernel QUIC Implementations
>
> Implementation
> ==============
>
> The central design is to implement QUIC within the kernel while delegating
> the handshake to userspace.
>
> Only the processing and creation of raw TLS Handshake Messages are handled
> in userspace, facilitated by a TLS library like GnuTLS. These messages are
> exchanged between kernel and userspace via sendmsg() and recvmsg(), with
> cryptographic details conveyed through control messages (cmsg).
>
> The entire QUIC protocol, aside from the TLS Handshake Messages processing
> and creation, is managed in the kernel. Rather than using an Upper Layer
> Protocol (ULP) layer, this implementation establishes a socket of type
> IPPROTO_QUIC (similar to IPPROTO_MPTCP), operating over UDP tunnels.
>
> For kernel consumers, they can initiate a handshake request from the kernel
> to userspace using the existing net/handshake netlink. The userspace
> component, such as tlshd service [2], then manages the processing
> of the QUIC handshake request.
>
> - Handshake Architecture:
>
> ┌──────┐ ┌──────┐
> │ APP1 │ │ APP2 │ ...
> └──────┘ └──────┘
> ┌──────────────────────────────────────────┐
> │ {quic_client/server_handshake()} │<─────────────┐
> └──────────────────────────────────────────┘ ┌─────────────┐
> {send/recvmsg()} {set/getsockopt()} │ tlshd │
> [CMSG handshake_info] [SOCKOPT_CRYPTO_SECRET] └─────────────┘
> [SOCKOPT_TRANSPORT_PARAM_EXT] │ ^
> │ ^ │ ^ │ │
> Userspace │ │ │ │ │ │
> ──────────────│─│──────────────────│─│──────────────────│───│───────
> Kernel │ │ │ │ │ │
> v │ v │ v │
> ┌──────────────────┬───────────────────────┐ ┌─────────────┐
> │ protocol, timer, │ socket (IPPROTO_QUIC) │<──┐ │ handshake │
> │ ├───────────────────────┤ │ │netlink APIs │
> │ common, family, │ outqueue | inqueue │ │ └─────────────┘
> │ ├───────────────────────┤ │ │ │
> │ stream, connid, │ frame │ │ ┌─────┐ ┌─────┐
> │ ├───────────────────────┤ │ │ │ │ │
> │ path, pnspace, │ packet │ │───│ SMB │ │ NFS │...
> │ ├───────────────────────┤ │ │ │ │ │
> │ cong, crypto │ UDP tunnels │ │ └─────┘ └─────┘
> └──────────────────┴───────────────────────┘ └──────┴───────┘
>
> - User Data Architecture:
>
> ┌──────┐ ┌──────┐
> │ APP1 │ │ APP2 │ ...
> └──────┘ └──────┘
> {send/recvmsg()} {set/getsockopt()} {recvmsg()}
> [CMSG stream_info] [SOCKOPT_KEY_UPDATE] [EVENT conn update]
> [SOCKOPT_CONNECTION_MIGRATION] [EVENT stream update]
> [SOCKOPT_STREAM_OPEN/RESET/STOP]
> │ ^ │ ^ ^
> Userspace │ │ │ │ │
> ──────────────│─│───────────────│─│─────────────────────│───────────
> Kernel │ │ │ │ │
> v │ v │ ┌──────────────────┘
> ┌──────────────────┬───────────────────────┐
> │ protocol, timer, │ socket (IPPROTO_QUIC) │<──┐{kernel_send/recvmsg()}
> │ ├───────────────────────┤ │{kernel_set/getsockopt()}
> │ common, family, │ outqueue | inqueue │ │{kernel_recvmsg()}
> │ ├───────────────────────┤ │
> │ stream, connid, │ frame │ │ ┌─────┐ ┌─────┐
> │ ├───────────────────────┤ │ │ │ │ │
> │ path, pnspace, │ packet │ │───│ SMB │ │ NFS │...
> │ ├───────────────────────┤ │ │ │ │ │
> │ cong, crypto │ UDP tunnels │ │ └─────┘ └─────┘
> └──────────────────┴───────────────────────┘ └──────┴───────┘
>
> Interface
> =========
>
> This implementation supports a mapping of QUIC into sockets APIs. Similar
> to TCP and SCTP, a typical Server and Client use the following system call
> sequence to communicate:
>
> Client Server
> ──────────────────────────────────────────────────────────────────────
> sockfd = socket(IPPROTO_QUIC) listenfd = socket(IPPROTO_QUIC)
> bind(sockfd) bind(listenfd)
> listen(listenfd)
> connect(sockfd)
> quic_client_handshake(sockfd)
> sockfd = accept(listenfd)
> quic_server_handshake(sockfd, cert)
>
> sendmsg(sockfd) recvmsg(sockfd)
> close(sockfd) close(sockfd)
> close(listenfd)
>
> Please note that quic_client_handshake() and quic_server_handshake()
> functions are currently sourced from libquic [3]. These functions are
> responsible for receiving and processing the raw TLS handshake messages
> until the completion of the handshake process.
>
> For utilization by kernel consumers, it is essential to have tlshd
> service [2] installed and running in userspace. This service receives
> and manages kernel handshake requests for kernel sockets. In the kernel,
> the APIs closely resemble those used in userspace:
>
> Client Server
> ────────────────────────────────────────────────────────────────────────
> __sock_create(IPPROTO_QUIC, &sock) __sock_create(IPPROTO_QUIC, &sock)
> kernel_bind(sock) kernel_bind(sock)
> kernel_listen(sock)
> kernel_connect(sock)
> tls_client_hello_x509(args:{sock})
> kernel_accept(sock, &newsock)
> tls_server_hello_x509(args:{newsock})
>
> kernel_sendmsg(sock) kernel_recvmsg(newsock)
> sock_release(sock) sock_release(newsock)
> sock_release(sock)
>
> Please be aware that tls_client_hello_x509() and tls_server_hello_x509()
> are APIs from net/handshake/. They are used to dispatch the handshake
> request to the userspace tlshd service and subsequently block until the
> handshake process is completed.
>
> Use Cases
> =========
>
> - Samba
>
> Stefan Metzmacher has integrated Linux QUIC into Samba for both client
> and server roles [4].
>
> - tlshd
>
> The tlshd daemon [2] facilitates Linux QUIC handshake requests from
> kernel sockets. This is essential for enabling protocols like SMB
> and NFS over QUIC.
>
> - curl
>
> Linux QUIC is being integrated into curl [5] for HTTP/3. Example usage:
>
> # curl --http3-only https://nghttp2.org:4433/
> # curl --http3-only https://www.google.com/
> # curl --http3-only https://facebook.com/
> # curl --http3-only https://outlook.office.com/
> # curl --http3-only https://cloudflare-quic.com/
>
> - httpd-portable
>
> Moritz Buhl has deployed an HTTP/3 server over Linux QUIC [6] that is
> accessible via Firefox and curl:
>
> https://d.moritzbuhl.de/pub
>
> - NetPerfMeter
>
> The latest NetPerfMeter release supports Linux QUIC and can be used to
> run performance evaluations [10].
>
> Test Coverage
> =============
>
> The Coverage (gcov) of Functional and Interop Tests:
>
> https://d.moritzbuhl.de/lcov
>
> - Functional Tests
>
> The libquic self-tests (make check) pass on all major architectures:
> x86_64, i386, s390x, aarch64, ppc64le.
>
> - Interop tests
>
> Interoperability was validated using the QUIC Interop Runner [7] against
> all major userland QUIC stacks. Results are available at:
>
> https://d.moritzbuhl.de/
>
> - Fuzzing via Syzkaller
>
> Syzkaller has been running kernel fuzzing with QUIC for weeks using
> tests/syzkaller/ in libquic [3].
>
> - Performance Testing
>
> Performance was benchmarked using iperf [8] over a 100G NIC using
> various MTUs and packet sizes:
>
> - QUIC vs. kTLS:
>
> UNIT size:1024 size:4096 size:16384 size:65536
> Gbits/sec QUIC | kTLS QUIC | kTLS QUIC | kTLS QUIC | kTLS
> ────────────────────────────────────────────────────────────────────
> mtu:1500 2.27 | 3.26 3.02 | 6.97 3.36 | 9.74 3.48 | 10.8
> ────────────────────────────────────────────────────────────────────
> mtu:9000 3.66 | 3.72 5.87 | 8.92 7.03 | 11.2 8.04 | 11.4
>
> - QUIC(disable_1rtt_encryption) vs. TCP:
>
> UNIT size:1024 size:4096 size:16384 size:65536
> Gbits/sec QUIC | TCP QUIC | TCP QUIC | TCP QUIC | TCP
> ────────────────────────────────────────────────────────────────────
> mtu:1500 3.09 | 4.59 4.46 | 14.2 5.07 | 21.3 5.18 | 23.9
> ────────────────────────────────────────────────────────────────────
> mtu:9000 4.60 | 4.65 8.41 | 14.0 11.3 | 28.9 13.5 | 39.2
>
>
> The performance gap between QUIC and kTLS may be attributed to:
>
> - The absence of Generic Segmentation Offload (GSO) for QUIC.
> - An additional data copy on the transmission (TX) path.
> - Extra encryption required for header protection in QUIC.
> - A longer header length for the stream data in QUIC.
>
> Patches
> =======
>
> Note: This implementation is organized into five parts and submitted across
> two patchsets for review. This patchset includes Parts 1–2, while Parts 3–5
> will be submitted in a subsequent patchset. For complete series, see [9].
>
> 1. Infrastructure (2):
>
> net: define IPPROTO_QUIC and SOL_QUIC constants
> net: build socket infrastructure for QUIC protocol
>
> 2. Subcomponents (13):
>
> quic: provide common utilities and data structures
> quic: provide family ops for address and protocol
> quic: provide quic.h header files for kernel and userspace
> quic: add stream management
> quic: add connection id management
> quic: add path management
> quic: add congestion control
> quic: add packet number space
> quic: add crypto key derivation and installation
> quic: add crypto packet encryption and decryption
> quic: add timer management
> quic: add packet builder base
> quic: add packet parser base
>
> 3. Data Processing (8):
>
> quic: add frame encoder and decoder base
> quic: implement outqueue transmission and flow control
> quic: implement outqueue sack and retransmission
> quic: implement inqueue receiving and flow control
> quic: implement frame creation functions
> quic: implement frame processing functions
> quic: implement packet creation functions
> quic: implement packet processing functions
>
> 4. Socket APIs (6):
>
> quic: support bind/listen/connect/accept/close()
> quic: support sendmsg() and recvmsg()
> quic: support socket options related to interaction after handshake
> quic: support socket options related to settings prior to handshake
> quic: support socket options related to setup during handshake
> quic: support socket ioctls and socket dump via procfs
>
> 5. Documentation and Selftests (3):
>
> Documentation: describe QUIC protocol interface in quic.rst
> quic: create sample test using handshake APIs for kernel consumers
> selftests: net: add tests for QUIC protocol
>
> Notice: The QUIC module is currently labeled as "EXPERIMENTAL".
>
> All contributors are recognized in the respective patches with the tag of
> 'Signed-off-by:'. Special thanks to Moritz Buhl and Stefan Metzmacher whose
> practical use cases and insightful feedback have been instrumental in
> shaping the design and advancing the development.
>
> References
> ==========
>
> [1] https://datatracker.ietf.org/doc/html/draft-lxin-quic-socket-apis
> [2] https://github.com/oracle/ktls-utils
> [3] https://github.com/lxin/quic
> [4] https://gitlab.com/samba-team/samba/-/merge_requests/4019
> [5] https://github.com/moritzbuhl/curl/tree/linux_curl
> [6] https://github.com/moritzbuhl/httpd-portable
> [7] https://github.com/quic-interop/quic-interop-runner
> [8] https://github.com/lxin/iperf
> [9] https://github.com/lxin/net-next/commits/quic/
> [10] https://www.nntb.no/~dreibh/netperfmeter/
>
> Changes in v2-v14: See individual patch changelogs for details.
>
> Xin Long (15):
> net: define IPPROTO_QUIC and SOL_QUIC constants
> net: build socket infrastructure for QUIC protocol
> quic: provide common utilities and data structures
> quic: provide family ops for address and protocol
> quic: provide quic.h header files for kernel and userspace
> quic: add stream management
> quic: add connection id management
> quic: add path management
> quic: add congestion control
> quic: add packet number space
> quic: add crypto key derivation and installation
> quic: add crypto packet encryption and decryption
> quic: add timer management
> quic: add packet builder base
> quic: add packet parser base
>
> Documentation/networking/ip-sysctl.rst | 39 +
> MAINTAINERS | 9 +
> include/linux/quic.h | 24 +
> include/linux/socket.h | 1 +
> include/uapi/linux/in.h | 2 +
> include/uapi/linux/quic.h | 241 +++++
> net/Kconfig | 1 +
> net/Makefile | 1 +
> net/quic/Kconfig | 35 +
> net/quic/Makefile | 9 +
> net/quic/common.c | 565 +++++++++++
> net/quic/common.h | 220 +++++
> net/quic/cong.c | 338 +++++++
> net/quic/cong.h | 130 +++
> net/quic/connid.c | 271 +++++
> net/quic/connid.h | 183 ++++
> net/quic/crypto.c | 1249 ++++++++++++++++++++++++
> net/quic/crypto.h | 88 ++
> net/quic/family.c | 439 +++++++++
> net/quic/family.h | 44 +
> net/quic/packet.c | 890 +++++++++++++++++
> net/quic/packet.h | 120 +++
> net/quic/path.c | 568 +++++++++++
> net/quic/path.h | 190 ++++
> net/quic/pnspace.c | 251 +++++
> net/quic/pnspace.h | 201 ++++
> net/quic/protocol.c | 417 ++++++++
> net/quic/protocol.h | 63 ++
> net/quic/socket.c | 482 +++++++++
> net/quic/socket.h | 209 ++++
> net/quic/stream.c | 416 ++++++++
> net/quic/stream.h | 133 +++
> net/quic/timer.c | 154 +++
> net/quic/timer.h | 45 +
> usr/include/Makefile | 1 +
> 35 files changed, 8029 insertions(+)
> create mode 100644 include/linux/quic.h
> create mode 100644 include/uapi/linux/quic.h
> create mode 100644 net/quic/Kconfig
> create mode 100644 net/quic/Makefile
> create mode 100644 net/quic/common.c
> create mode 100644 net/quic/common.h
> create mode 100644 net/quic/cong.c
> create mode 100644 net/quic/cong.h
> create mode 100644 net/quic/connid.c
> create mode 100644 net/quic/connid.h
> create mode 100644 net/quic/crypto.c
> create mode 100644 net/quic/crypto.h
> create mode 100644 net/quic/family.c
> create mode 100644 net/quic/family.h
> create mode 100644 net/quic/packet.c
> create mode 100644 net/quic/packet.h
> create mode 100644 net/quic/path.c
> create mode 100644 net/quic/path.h
> create mode 100644 net/quic/pnspace.c
> create mode 100644 net/quic/pnspace.h
> create mode 100644 net/quic/protocol.c
> create mode 100644 net/quic/protocol.h
> create mode 100644 net/quic/socket.c
> create mode 100644 net/quic/socket.h
> create mode 100644 net/quic/stream.c
> create mode 100644 net/quic/stream.h
> create mode 100644 net/quic/timer.c
> create mode 100644 net/quic/timer.h
>
> --
> 2.47.1
>
Note: I reviewed the reports from sashiko-claude [1] and sashiko-gemini
[2], and from my perspective, this run did not uncover any real issues.
[1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/cover.1784147238.git.lucien.xin%40gmail.com
[2] https://sashiko.dev/#/patchset/cover.1784147238.git.lucien.xin%40gmail.com
Thanks.
^ 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