* Re: [PATCH net-next v11 00/14] netkit: Support for io_uring zero-copy and AF_XDP
From: Daniel Borkmann @ 2026-04-07 9:50 UTC (permalink / raw)
To: netdev
Cc: bpf, kuba, davem, razor, pabeni, willemb, sdf, john.fastabend,
martin.lau, jordan, maciej.fijalkowski, magnus.karlsson, dw, toke,
yangzhenze, wangdongdong.6
In-Reply-To: <20260402231031.447597-1-daniel@iogearbox.net>
Hi Jakub,
On 4/3/26 1:10 AM, Daniel Borkmann wrote:
> Containers use virtual netdevs to route traffic from a physical netdev
> in the host namespace. They do not have access to the physical netdev
> in the host and thus can't use memory providers or AF_XDP that require
> reconfiguring/restarting queues in the physical netdev.
>
> This patchset adds the concept of queue leasing to virtual netdevs that
> allow containers to use memory providers and AF_XDP at native speed.
> Leased queues are bound to a real queue in a physical netdev and act
> as a proxy.
>
> Memory providers and AF_XDP operations take an ifindex and queue id,
> so containers would pass in an ifindex for a virtual netdev and a queue
> id of a leased queue, which then gets proxied to the underlying real
> queue.
>
> We have implemented support for this concept in netkit and tested the
> latter against Nvidia ConnectX-6 (mlx5) as well as Broadcom BCM957504
> (bnxt_en) 100G NICs. For more details see the individual patches.
>
> v10->v11:
> - Fix missing mp_ops->uninstall upon unlease path (Gemini)
> - Fix dma device retrieval on tx queue when rx queue is leased (Gemini)
> - Rework ethtool channel checks to check rx/tx individually (Gemini)
> - The remainder of the Gemini findings were non-issues
> - Add more extensive net selftests around queue leasing corner cases
> - Rebase and retested everything with mlx5 + bnxt_en
I've look into the latest v11 findings from Gemini in the meantime, and
thought I'd share an update/comments related to them:
https://sashiko.dev/#/patchset/20260402231031.447597-1-daniel%40iogearbox.net
From all the claims related to the series, the one in the netkit device dump
looks reasonable to improve, iow, to not dump IFLA_NETKIT_SCRUB if in single
mode since we also reject the presence of the attribute during device creation,
change would look like:
- if (nla_put_u32(skb, IFLA_NETKIT_SCRUB, nk->scrub))
- return -EMSGSIZE;
+ if (nk->pair != NETKIT_DEVICE_SINGLE &&
+ nla_put_u32(skb, IFLA_NETKIT_SCRUB, nk->scrub))
+ return -EMSGSIZE;
Anyway, wrt the individual patch comments from Gemini:
Patch 2:
- The capable(CAP_NET_ADMIN) is intentional
Patch 6:
- Solved in your patch which is a good thing to do
https://patchwork.kernel.org/project/netdevbpf/patch/20260404001938.2425670-1-kuba@kernel.org/
-> Iiuc, its unreachable today due to other guards, but an explicit check
would definitely cement that
- The second double free or use-after-free on unregistered devices claim is
not true, there is an inconsistency in the io_uring vs devmem wrt clearing
mp_ops to NULL but the code handles both cases correctly
Patch 7:
- Independent of the series; oob queue index in io_uring/zcrx claims that
there is no bounds-check against real_num_rx_queues before being passed
to netdev_queue_get_dma_dev and from there into ndo_queue_get_dma_dev
callback
-> mlx5e_queue_get_dma_dev as the only implementation does bounds check
internally, it might make sense to have a guard in the core code if
more drivers implement the ndo_queue_get_dma_dev
- Order-dependent DMA dev validation in netdev_nl_get_dma_dev claim cannot
override memory provider state, mixed cases get rejected
Patch 9:
- Intentional, netkit proxies all xsk operations to the phys device
Patch 10:
- Above diff to not dump IFLA_NETKIT_SCRUB makes sense to me
- The changelink operations claim further below is intentional and for now
rejected with -EOPNOTSUPP given nothing new can be configured here
Patch 11:
- netkit notifier takes care of this and is part of this series
Some cases in patch 6 and 7 that don't require a specific driver are worth additional
tracking in the netkit leasing selftests to asset behavior though. Happy to fold that
+ the IFLA_NETKIT_SCRUB diff above into a v12 or as a follow-up, let me know.
Thanks a lot,
Daniel
^ permalink raw reply
* Re: [PATCH net-next] selftests: drv-net: adjust to socat changes
From: Breno Leitao @ 2026-04-07 9:43 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
hawk, john.fastabend, sdf, linux-kselftest
In-Reply-To: <20260404230103.2719103-1-kuba@kernel.org>
On Sat, Apr 04, 2026 at 04:01:03PM -0700, Jakub Kicinski wrote:
> socat v1.8.1.0 now defaults to shut-null, it sends an extra
> 0-length UDP packet when sender disconnects. This breaks
> our tests which expect the exact packet sequence.
>
> Add shut-none which was the old default where necessary.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* [PATCH net v2] net: txgbe: fix RTNL assertion warning when remove module
From: Jiawen Wu @ 2026-04-07 9:40 UTC (permalink / raw)
To: netdev
Cc: Russell King, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Mengyuan Lou,
Jiawen Wu, stable
For the copper NIC with external PHY, the driver called
phylink_connect_phy() during probe and phylink_disconnect_phy() during
remove. It caused an RTNL assertion warning in phylink_disconnect_phy()
upon module remove.
To fix this, add rtnl_lock() and rtnl_unlock() around the
phylink_disconnect_phy() in remove function.
------------[ cut here ]------------
RTNL: assertion failed at drivers/net/phy/phylink.c (2351)
WARNING: drivers/net/phy/phylink.c:2351 at
phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464
Modules linked in: ...
CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+
Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING
PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024
RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink]
Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7
48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a
e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000
RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020
RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000
R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348
FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0
PKRU: 55555554
Call Trace:
<TASK>
txgbe_remove_phy+0xbb/0xd0 [txgbe]
txgbe_remove+0x4c/0xb0 [txgbe]
pci_device_remove+0x41/0xb0
device_remove+0x43/0x80
device_release_driver_internal+0x206/0x270
driver_detach+0x4a/0xa0
bus_remove_driver+0x83/0x120
driver_unregister+0x2f/0x60
pci_unregister_driver+0x40/0x90
txgbe_driver_exit+0x10/0x850 [txgbe]
__do_sys_delete_module.isra.0+0x1c3/0x2f0
__x64_sys_delete_module+0x12/0x20
x64_sys_call+0x20c3/0x2390
do_syscall_64+0x11c/0x1500
? srso_alias_return_thunk+0x5/0xfbef5
? do_syscall_64+0x15a/0x1500
? srso_alias_return_thunk+0x5/0xfbef5
? do_fault+0x312/0x580
? srso_alias_return_thunk+0x5/0xfbef5
? __handle_mm_fault+0x9d5/0x1040
? srso_alias_return_thunk+0x5/0xfbef5
? count_memcg_events+0x101/0x1d0
? srso_alias_return_thunk+0x5/0xfbef5
? handle_mm_fault+0x1e8/0x2f0
? srso_alias_return_thunk+0x5/0xfbef5
? do_user_addr_fault+0x2f8/0x820
? srso_alias_return_thunk+0x5/0xfbef5
? irqentry_exit+0xb2/0x600
? srso_alias_return_thunk+0x5/0xfbef5
? exc_page_fault+0x92/0x1c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Fixes: 02b2a6f91b90 ("net: txgbe: support copper NIC with external PHY")
Cc: stable@vger.kernel.org
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
---
v2:
- Add RTNL lock instead of moving phylink connect/disconnect functions.
v1: https://lore.kernel.org/all/D56A7C3379B4DA62+20260331071107.5414-1-jiawenwu@trustnetic.com
---
drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c b/drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c
index 8ea7aa07ae4e..dc9f24314658 100644
--- a/drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c
+++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c
@@ -657,7 +657,9 @@ void txgbe_remove_phy(struct txgbe *txgbe)
return;
case wx_mac_sp:
if (txgbe->wx->media_type == wx_media_copper) {
+ rtnl_lock();
phylink_disconnect_phy(txgbe->wx->phylink);
+ rtnl_unlock();
phylink_destroy(txgbe->wx->phylink);
return;
}
--
2.48.1
^ permalink raw reply related
* [PATCH net-next] ppp: consolidate refcount decrements
From: Qingfang Deng @ 2026-04-07 9:40 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Qingfang Deng, Sebastian Andrzej Siewior, Kees Cook,
Kuniyuki Iwashima, linux-ppp, netdev, linux-kernel
ppp_destroy_{channel,interface} are always called after
refcount_dec_and_test().
To reduce boilerplate code, consolidate the decrements by moving them
into the two functions. To reflect this change in semantics, rename the
functions to ppp_release_*.
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
---
drivers/net/ppp/ppp_generic.c | 61 ++++++++++++++++-------------------
1 file changed, 28 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index cb29a6968c63..b097d1b38ac9 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -286,12 +286,12 @@ static struct compressor *find_compressor(int type);
static void ppp_get_stats(struct ppp *ppp, struct ppp_stats *st);
static int ppp_create_interface(struct net *net, struct file *file, int *unit);
static void init_ppp_file(struct ppp_file *pf, int kind);
-static void ppp_destroy_interface(struct ppp *ppp);
+static void ppp_release_interface(struct ppp *ppp);
static struct ppp *ppp_find_unit(struct ppp_net *pn, int unit);
static struct channel *ppp_find_channel(struct ppp_net *pn, int unit);
static int ppp_connect_channel(struct channel *pch, int unit);
static int ppp_disconnect_channel(struct channel *pch);
-static void ppp_destroy_channel(struct channel *pch);
+static void ppp_release_channel(struct channel *pch);
static int unit_get(struct idr *p, void *ptr, int min);
static int unit_set(struct idr *p, void *ptr, int n);
static void unit_put(struct idr *p, int n);
@@ -407,22 +407,18 @@ static int ppp_release(struct inode *unused, struct file *file)
if (pf) {
file->private_data = NULL;
- if (pf->kind == INTERFACE) {
+ switch (pf->kind) {
+ case INTERFACE:
ppp = PF_TO_PPP(pf);
rtnl_lock();
if (file == ppp->owner)
unregister_netdevice(ppp->dev);
rtnl_unlock();
- }
- if (refcount_dec_and_test(&pf->refcnt)) {
- switch (pf->kind) {
- case INTERFACE:
- ppp_destroy_interface(PF_TO_PPP(pf));
- break;
- case CHANNEL:
- ppp_destroy_channel(PF_TO_CHANNEL(pf));
- break;
- }
+ ppp_release_interface(ppp);
+ break;
+ case CHANNEL:
+ ppp_release_channel(PF_TO_CHANNEL(pf));
+ break;
}
}
return 0;
@@ -675,8 +671,7 @@ static int ppp_bridge_channels(struct channel *pch, struct channel *pchb)
synchronize_rcu();
if (pchb)
- if (refcount_dec_and_test(&pchb->file.refcnt))
- ppp_destroy_channel(pchb);
+ ppp_release_channel(pchb);
return -EALREADY;
}
@@ -708,11 +703,9 @@ static int ppp_unbridge_channels(struct channel *pch)
synchronize_rcu();
if (pchbb == pch)
- if (refcount_dec_and_test(&pch->file.refcnt))
- ppp_destroy_channel(pch);
+ ppp_release_channel(pch);
- if (refcount_dec_and_test(&pchb->file.refcnt))
- ppp_destroy_channel(pchb);
+ ppp_release_channel(pchb);
return 0;
}
@@ -786,8 +779,7 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
break;
err = ppp_bridge_channels(pch, pchb);
/* Drop earlier refcount now bridge establishment is complete */
- if (refcount_dec_and_test(&pchb->file.refcnt))
- ppp_destroy_channel(pchb);
+ ppp_release_channel(pchb);
break;
case PPPIOCUNBRIDGECHAN:
@@ -1584,8 +1576,7 @@ static void ppp_dev_priv_destructor(struct net_device *dev)
struct ppp *ppp;
ppp = netdev_priv(dev);
- if (refcount_dec_and_test(&ppp->file.refcnt))
- ppp_destroy_interface(ppp);
+ ppp_release_interface(ppp);
}
static int ppp_fill_forward_path(struct net_device_path_ctx *ctx,
@@ -3022,8 +3013,7 @@ ppp_unregister_channel(struct ppp_channel *chan)
pch->file.dead = 1;
wake_up_interruptible(&pch->file.rwait);
- if (refcount_dec_and_test(&pch->file.refcnt))
- ppp_destroy_channel(pch);
+ ppp_release_channel(pch);
}
/*
@@ -3404,12 +3394,14 @@ init_ppp_file(struct ppp_file *pf, int kind)
}
/*
- * Free the memory used by a ppp unit. This is only called once
- * there are no channels connected to the unit and no file structs
- * that reference the unit.
+ * Drop a reference to a ppp unit and free its memory if the refcount reaches
+ * zero.
*/
-static void ppp_destroy_interface(struct ppp *ppp)
+static void ppp_release_interface(struct ppp *ppp)
{
+ if (!refcount_dec_and_test(&ppp->file.refcnt))
+ return;
+
atomic_dec(&ppp_unit_count);
if (!ppp->file.dead || ppp->n_channels) {
@@ -3561,18 +3553,21 @@ ppp_disconnect_channel(struct channel *pch)
wake_up_interruptible(&ppp->file.rwait);
ppp_unlock(ppp);
synchronize_net();
- if (refcount_dec_and_test(&ppp->file.refcnt))
- ppp_destroy_interface(ppp);
+ ppp_release_interface(ppp);
err = 0;
}
return err;
}
/*
- * Free up the resources used by a ppp channel.
+ * Drop a reference to a ppp channel and free its memory if the refcount reaches
+ * zero.
*/
-static void ppp_destroy_channel(struct channel *pch)
+static void ppp_release_channel(struct channel *pch)
{
+ if (!refcount_dec_and_test(&pch->file.refcnt))
+ return;
+
put_net_track(pch->chan_net, &pch->ns_tracker);
pch->chan_net = NULL;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] net: initialize sk_rx_queue_mapping in sk_clone()
From: Eric Dumazet @ 2026-04-07 9:41 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn,
David S. Miller, Jakub Kicinski, Simon Horman,
Soheil Hassas Yeganeh, linux-kernel
In-Reply-To: <20260407084219.95718-1-jiayuan.chen@linux.dev>
On Tue, Apr 7, 2026 at 1:43 AM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>
> sk_clone() initializes sk_tx_queue_mapping via sk_tx_queue_clear()
> but does not initialize sk_rx_queue_mapping. Since this field is in
> the sk_dontcopy region, it is neither copied from the parent socket
> by sock_copy() nor zeroed by sk_prot_alloc() (called without
> __GFP_ZERO from sk_clone).
>
> Commit 03cfda4fa6ea ("tcp: fix another uninit-value
> (sk_rx_queue_mapping)") attempted to fix this by introducing
> sk_mark_napi_id_set() with force_set=true in tcp_child_process().
> However, sk_mark_napi_id_set() -> sk_rx_queue_set() only writes
> when skb_rx_queue_recorded(skb) is true. If the 3-way handshake
> ACK arrives through a device that does not record rx_queue (e.g.
> loopback or veth), sk_rx_queue_mapping remains uninitialized.
>
> When a subsequent data packet arrives with a recorded rx_queue,
> sk_mark_napi_id() -> sk_rx_queue_update() reads the uninitialized
> field for comparison (force_set=false path), triggering KMSAN.
>
> This was reproduced by establishing a TCP connection over loopback
> (which does not call skb_record_rx_queue), then attaching a BPF TC
> program on lo ingress to set skb->queue_mapping on data packets:
Ok, it's a somewhat convoluted way, and no real harm but KMSAN :)
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Kory Maincent @ 2026-04-07 9:40 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Andrew Lunn, Carlo Szelinsky, Andrew Lunn, Heiner Kallweit,
Russell King, Jakub Kicinski, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, netdev, linux-kernel
In-Reply-To: <adO_Za-X1cMjCEEa@pengutronix.de>
On Mon, 6 Apr 2026 16:12:53 +0200
Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> On Mon, Apr 06, 2026 at 02:22:16PM +0200, Andrew Lunn wrote:
> > > The core question, do we need PSE for PHY functionality?
> >
> > I don't think the PHY should require PSE in order to send/receive
> > frames. If the PSE is not supplying power, the link peer is probably
> > off, but that is not so different from the cable being unplugged.
> >
> > > We can make a step back and re-evaluate - what functionality and what
> > > order is actually required to find potentially better implementation.
> > >
> > > We have a lot of current flowing over wires, budget and port
> > > prioritization issues, things which may damage HW if done not correctly.
> > > With other word, if we do not have properly operational environment
> > > providing system specific policies, it is better to run safe
> > > configuration - all ports/regulators are off.
> > >
> > > This means:
> > > - PSE controller driver should be registered as early as possible,
> > > without caring about existence of PHYs, ports or network interfaces.
> > > And configure ports in to default safe operation - off. Accept we
> > > have some controller/firmware which would care about safety.
> >
> > Don't most PSE have I2C or SPI interfaces? So they have a different
> > life cycle to PHYs, ports or netdevs. Only PSEs which are embedded
> > within a PHY, on an MDIO bus, will have a closely linked life
> > cycle. But do such devices exist?
>
> i'm not aware of any.
Same here, but it's not impossible to have such device in the future.
> > As soon as the PSE probes with all the resources it needs, and can
> > impose a safe default setting. And that can be independent of PHY and
> > netdev. I _think_ we only need the netdev for configuration, since
> > ethtool addresses netdev's. There would only be issues with user
> > space listening to udev creation events, it knows the PSE exists, but
> > it has no way to access it until the netdev is created.
>
> Ack. netdev is for configuration as virtual representation of PSE PI. And it
> is easier to assign corresponding interface for the LLDP.
> We do not really care about the PHY; it just happens to represent the
> port at the farthest end described in the Device Tree.
>
> > > - as soon as we have all needed components, we can start provide
> > > controllable interfaces to serve external consumers.
> >
> > Yep.
> >
> > > If we decouple PSE and PHY registration (and we probably will need to do
> > > it some day), we would need to have own implementation of deferred
> > > probing in the PSE core. Event driven or by polling - which sounds not
> > > like very good idea. Pick your poison...
> >
> > I don't see why. Maybe i'm missing something. We have two cases:
> >
> > 1) PSE probes first. When the PHY looks up the PSE, it exists, and it
> > is passed a handle to the PSE.
> >
> > 2) PHY probes first. The PSE core returns EPROBE_DEFFER, and the PHY
> > will try again later.
> >
> > I don't think there is any chicken/egg problems.
>
> Ack, i guess it is optimization problem.
Yes, as I reply in another mail of the thread:
We should be able to get the PSE control either at PSE register time or at PHY
(or PHY port) probe time.
Maybe if the PHY can't find the PSE PI, we could save the phandle of the PSE PI
somewhere in the PHY structure. Then at PSE register time, look for each PHY to
resolve every unresolved phandle.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Kory Maincent @ 2026-04-07 9:31 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Carlo Szelinsky, Andrew Lunn, Andrew Lunn, Heiner Kallweit,
Russell King, Jakub Kicinski, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, netdev, linux-kernel
In-Reply-To: <adNx9z-AYxwpL2yH@pengutronix.de>
On Mon, 6 Apr 2026 10:42:31 +0200
Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> Hi,
>
> On Fri, Apr 03, 2026 at 03:38:49PM +0200, Kory Maincent wrote:
> > On Fri, 3 Apr 2026 15:31:11 +0200
> > Carlo Szelinsky <github@szelinsky.de> wrote:
> >
> > > Hi Andrew,
> > >
> > > Thx for helping me!
> > > I thought of keeping the eager path so we still catch broken DT bindings
> > > early at boot instead of silently failing later on first ethtool access.
> > > But you're right, dropping it would simplify things quite a bit. Do you
> > > think that trade-off is worth it? I will follow your lead.
> >
> > On my side I thinks that's a good idea, and I don't see any issue with that
> > for now. Oleksij you introduced it here in the first place, is it ok for
> > you?
>
> If I see it correctly - this patch kills all notifications originated
> from the PSE core to the users space, until some one calls get/set path
> from user space. Means, kernel update may break UAPI behavior of
> existing devices.
Indeed you are right, I have missed this point.
> On other hand, I agree that PSE is not a strickt requirement for PHY
> functionality in most cases. At the early stage, as initial PSE support
> was introduced, PHYs was kind of representation of the port and related
> ethernet interface (needed for LLDP). Are there better methods to solve
> it now?
Now that Maxime has merged the phy port representation (mdi) it could be binding
to it. But we should not break the current uAPI of having it bind directly
to the PHY. Thing is, the issue will be still present as PHY ports are only
created and initialized at probe time.
We should be able to get the PSE control either at PSE register time or at PHY
(or PHY port) probe time.
I just see there is more discussion about it in the thread.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [net-next PATCH 10/10] net: dsa: tag_rtl8_4: set KEEP flag
From: Linus Walleij @ 2026-04-07 9:22 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-10-44fb63033b7e@gmail.com>
On Wed, Apr 1, 2026 at 1:01 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> KEEP=1 is needed because we should respect the format of the packet as
> the kernel sends it to us. Unless tx forward offloading is used, the
> kernel is giving us the packet exactly as it should leave the specified
> port on the wire. Until now this was not needed because the ports were
> always functioning in a standalone mode in a VLAN-unaware way, so the
> switch would not tag or untag frames anyway. But arguably it should have
> been KEEP=1 all along.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
I think you could just send this and patch 1 separately so they get
merged first as they are completely self-contained and uncontroversial
and touch the same code.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [net-next PATCH 09/10] net: dsa: realtek: rtl8365mb: add bridge port flags
From: Linus Walleij @ 2026-04-07 9:20 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-9-44fb63033b7e@gmail.com>
Hi Luiz, Alvin,
On Wed, Apr 1, 2026 at 1:01 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Add bridge port flags for:
> - BR_LEARNING
> - BR_FLOOD
> - BR_MCAST_FLOOD
> - BR_BCAST_FLOOD
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
I have been working on a patch for RTL8366RB for this as well:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/patch/?id=0d58a9d74f363b969c06a8ac8446e6eef5511795
> +static int rtl8365mb_port_set_ucast_flood(struct realtek_priv *priv, int port,
> + bool enable)
> +static int rtl8365mb_port_set_mcast_flood(struct realtek_priv *priv, int port,
> + bool enable)
> +static int rtl8365mb_port_set_bcast_flood(struct realtek_priv *priv, int port,
> + bool enable)
Those are small and just writing registers so I guess they can be kept local,
but I think they should be accessed indirectly through
struct realtek_ops .rtl8366_port_set_ucast_flood() etc.
I can just make a simple patch adding the same three callbacks for
RTL8366RB and then it's done for both chips.
> +static int rtl8365mb_port_pre_bridge_flags(struct dsa_switch *ds, int port,
> + struct switchdev_brport_flags flags,
> + struct netlink_ext_ack *extack)
> +static int rtl8365mb_port_bridge_flags(struct dsa_switch *ds, int port,
> + struct switchdev_brport_flags flags,
> + struct netlink_ext_ack *exack)
Move this one to rtl8366-core.c under the name rtl8366_port_[pre_]bridge_flags()
and use the abstract accessors to do the register writes.
> @@ -1691,6 +1797,8 @@ static int rtl8365mb_port_bridge_join(struct dsa_switch *ds, int port,
> int ret;
> int i;
>
> + dev_dbg(priv->dev, "bridge %d join port %d\n", port, bridge.num);
> +
> /* Add this port to the isolation group of every other port
> * offloading this bridge.
> */
> @@ -1730,6 +1838,8 @@ static void rtl8365mb_port_bridge_leave(struct dsa_switch *ds, int port,
> u32 mask = 0;
> int i;
>
> + dev_dbg(priv->dev, "bridge %d leave port %d\n", port, bridge.num);
> +
> /* Remove this port from the isolation group of every other
> * port offloading this bridge.
> */
These debug prints seem unrelated to this patch?
> @@ -2547,6 +2657,19 @@ static int rtl8365mb_setup(struct dsa_switch *ds)
> if (ret)
> goto out_teardown_irq;
>
> + /* Enable all types of flooding */
> + ret = rtl8365mb_port_set_ucast_flood(priv, i, true);
> + if (ret)
> + goto out_teardown_irq;
> +
> + ret = rtl8365mb_port_set_mcast_flood(priv, i, true);
> + if (ret)
> + goto out_teardown_irq;
> +
> + ret = rtl8365mb_port_set_bcast_flood(priv, i, true);
> + if (ret)
> + goto out_teardown_irq;
Create rtl8366_setup_flood_control() in realtek-core.c and add these
three calls as a helper using the rtl8366_* generic calls there. It will be
done the same on all chips.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH net v2 3/3] vsock/test: add MSG_PEEK after partial recv test
From: Luigi Leonardi @ 2026-04-07 9:13 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
In-Reply-To: <20260407-fix_peek-v2-0-2e2581dc8b7c@redhat.com>
Add a test that verifies MSG_PEEK works correctly after a partial
recv().
This is to test a bug that was present in the
`virtio_transport_stream_do_peek()` when computing the number of bytes to
copy: After a partial read, the peek function didn't take into
consideration the number of bytes that were already read. So peeking the
whole buffer would cause a out-of-bounds read, that resulted in a -EFAULT.
This test does exactly this: do a partial recv on a buffer, then try to
peek the whole buffer content.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
tools/testing/vsock/vsock_test.c | 43 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
index bdb0754965df..d38a90a86f34 100644
--- a/tools/testing/vsock/vsock_test.c
+++ b/tools/testing/vsock/vsock_test.c
@@ -346,6 +346,44 @@ static void test_stream_msg_peek_server(const struct test_opts *opts)
return test_msg_peek_server(opts, false);
}
+static void test_stream_peek_after_recv_client(const struct test_opts *opts)
+{
+ unsigned char buf[MSG_PEEK_BUF_LEN];
+ int fd;
+
+ fd = vsock_stream_connect(opts->peer_cid, opts->peer_port);
+ if (fd < 0) {
+ perror("connect");
+ exit(EXIT_FAILURE);
+ }
+
+ memset(buf, 0, sizeof(buf));
+
+ send_buf(fd, buf, sizeof(buf), 0, sizeof(buf));
+
+ close(fd);
+}
+
+static void test_stream_peek_after_recv_server(const struct test_opts *opts)
+{
+ unsigned char buf[MSG_PEEK_BUF_LEN];
+ int fd;
+
+ fd = vsock_stream_accept(VMADDR_CID_ANY, opts->peer_port, NULL);
+ if (fd < 0) {
+ perror("accept");
+ exit(EXIT_FAILURE);
+ }
+
+ /* Partial recv to advance offset within the skb */
+ recv_buf(fd, buf, 1, 0, 1);
+
+ /* Ask more bytes than available */
+ recv_buf(fd, buf, sizeof(buf), MSG_PEEK, sizeof(buf) - 1);
+
+ close(fd);
+}
+
#define SOCK_BUF_SIZE (2 * 1024 * 1024)
#define SOCK_BUF_SIZE_SMALL (64 * 1024)
#define MAX_MSG_PAGES 4
@@ -2509,6 +2547,11 @@ static struct test_case test_cases[] = {
.run_client = test_stream_tx_credit_bounds_client,
.run_server = test_stream_tx_credit_bounds_server,
},
+ {
+ .name = "SOCK_STREAM MSG_PEEK after partial recv",
+ .run_client = test_stream_peek_after_recv_client,
+ .run_server = test_stream_peek_after_recv_server,
+ },
{},
};
--
2.53.0
^ permalink raw reply related
* [PATCH net v2 2/3] vsock/test: handle MSG_PEEK in `recv_buf`
From: Luigi Leonardi @ 2026-04-07 9:13 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
In-Reply-To: <20260407-fix_peek-v2-0-2e2581dc8b7c@redhat.com>
`recv_buf` does not handle the MSG_PEEK flag correctly: it keeps calling
`recv` until all requested bytes are available or an error occurs.
The problem is how it calculates the amount of bytes read: MSG_PEEK
doesn't consume any bytes, will re-read the same bytes from the buffer
head, so, summing the return value every time is wrong.
Moreover, MSG_PEEK doesn't consume the bytes in the buffer, so if the
requested amount is more than the bytes available, the loop will never
terminate, because `recv` will never return EOF. For this reason we need
to compare the amount of read bytes with the number of bytes expected.
Add a check, and if the MSG_PEEK flag is present, update the counter of
read bytes differently, and break if we read the expected amount.
This allows us to simplify the `test_stream_credit_update_test`, by
reusing `recv_buf`.
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
tools/testing/vsock/util.c | 8 ++++++++
tools/testing/vsock/vsock_test.c | 13 +------------
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/tools/testing/vsock/util.c b/tools/testing/vsock/util.c
index 9430ef5b8bc3..f12425ca99ed 100644
--- a/tools/testing/vsock/util.c
+++ b/tools/testing/vsock/util.c
@@ -399,6 +399,14 @@ void recv_buf(int fd, void *buf, size_t len, int flags, ssize_t expected_ret)
if (ret == 0 || (ret < 0 && errno != EINTR))
break;
+ if (flags & MSG_PEEK) {
+ if (ret == expected_ret) {
+ nread = ret;
+ break;
+ }
+ continue;
+ }
+
nread += ret;
} while (nread < len);
timeout_end();
diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
index 5bd20ccd9335..bdb0754965df 100644
--- a/tools/testing/vsock/vsock_test.c
+++ b/tools/testing/vsock/vsock_test.c
@@ -1500,18 +1500,7 @@ static void test_stream_credit_update_test(const struct test_opts *opts,
}
/* Wait until there will be 128KB of data in rx queue. */
- while (1) {
- ssize_t res;
-
- res = recv(fd, buf, buf_size, MSG_PEEK);
- if (res == buf_size)
- break;
-
- if (res <= 0) {
- fprintf(stderr, "unexpected 'recv()' return: %zi\n", res);
- exit(EXIT_FAILURE);
- }
- }
+ recv_buf(fd, buf, buf_size, MSG_PEEK, buf_size);
/* There is 128KB of data in the socket's rx queue, dequeue first
* 64KB, credit update is sent if 'low_rx_bytes_test' == true.
--
2.53.0
^ permalink raw reply related
* [PATCH net v2 1/3] vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy
From: Luigi Leonardi @ 2026-04-07 9:13 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
In-Reply-To: <20260407-fix_peek-v2-0-2e2581dc8b7c@redhat.com>
`virtio_transport_stream_do_peek()` does not account for the skb offset
when computing the number of bytes to copy.
This means that, after a partial recv() that advances the offset, a peek
requesting more bytes than are available in the sk_buff causes
`skb_copy_datagram_iter()` to go past the valid payload, resulting in
a -EFAULT.
The dequeue path already handles this correctly.
Apply the same logic to the peek path.
Fixes: 0df7cd3c13e4 ("vsock/virtio/vhost: read data from non-linear skb")
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
---
net/vmw_vsock/virtio_transport_common.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 8a9fb23c6e85..4b65bfe5d875 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -547,9 +547,8 @@ virtio_transport_stream_do_peek(struct vsock_sock *vsk,
skb_queue_walk(&vvs->rx_queue, skb) {
size_t bytes;
- bytes = len - total;
- if (bytes > skb->len)
- bytes = skb->len;
+ bytes = min_t(size_t, len - total,
+ skb->len - VIRTIO_VSOCK_SKB_CB(skb)->offset);
spin_unlock_bh(&vvs->rx_lock);
--
2.53.0
^ permalink raw reply related
* [PATCH net v2 0/3] vsock/virtio: fix MSG_PEEK calculation on bytes to copy
From: Luigi Leonardi @ 2026-04-07 9:13 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
`virtio_transport_stream_do_peek`, when calculating the number of bytes to
copy, didn't consider the `offset`, caused by partial reads that happened
before.
This might cause out-of-bounds read that lead to an EFAULT.
More details in the commits.
Commit 1 introduces the fix
Commit 2 introduces some preliminary work for adding a test
Commit 3 introduces a test that checks for this bug to avoid future
regressions.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
Changes in v2:
- Addressed reviewers comment
- Test now uses the recv_buf utils.
- Removed unnecessary barrier
- Checkpatch warnings.
- Added new commit that allows to use recv_buf with MSG_PEEK
- Picked up RoBs
- Link to v1: https://lore.kernel.org/r/20260402-fix_peek-v1-0-ad274fcef77b@redhat.com
---
Luigi Leonardi (3):
vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy
vsock/test: handle MSG_PEEK in `recv_buf`
vsock/test: add MSG_PEEK after partial recv test
net/vmw_vsock/virtio_transport_common.c | 5 ++-
tools/testing/vsock/util.c | 8 +++++
tools/testing/vsock/vsock_test.c | 56 ++++++++++++++++++++++++++-------
3 files changed, 54 insertions(+), 15 deletions(-)
---
base-commit: bfe62a454542cfad3379f6ef5680b125f41e20f4
change-id: 20260401-fix_peek-6837b83469e3
Best regards,
--
Luigi Leonardi <leonardi@redhat.com>
^ permalink raw reply
* Re: [PATCH net-next] selftests: forwarding: lib: rewrite processing of command line arguments
From: Ioana Ciornei @ 2026-04-07 9:13 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel, petrm, willemb,
linux-kselftest
In-Reply-To: <20260406153150.GI395680@kernel.org>
On Mon, Apr 06, 2026 at 04:31:50PM +0100, Simon Horman wrote:
> On Fri, Apr 03, 2026 at 05:19:12PM +0300, Ioana Ciornei wrote:
> > The piece of code which processes the command line arguments and
> > populates NETIFS based on them is really unobvious. Rewrite it so that
> > the intention is clear and the code is easy to follow.
> >
> > Suggested-by: Petr Machata <petrm@nvidia.com>
> > Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> > ---
> > tools/testing/selftests/net/forwarding/lib.sh | 22 +++++++++----------
> > 1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
> > index d8cc4c64148d..922cdaf2ceb9 100644
> > --- a/tools/testing/selftests/net/forwarding/lib.sh
> > +++ b/tools/testing/selftests/net/forwarding/lib.sh
> > @@ -466,18 +466,18 @@ if [ "${DRIVER_TEST_CONFORMANT}" = "yes" ]; then
> > NETIFS[p2]="$remote_netif"
> > TARGETS[$remote_netif]="$REMOTE_TYPE:$REMOTE_ARGS"
> > else
> > - count=0
>
> AI generated review on Sashiko.dev suggests that initialising count should
> be retained to ensure correct behaviour in the (unlikely) case that count
> is already set (to a non-zero value) in the environment.
>
> And this seems like a good idea to me.
Ok. Will add this in v2.
^ permalink raw reply
* Re: [PATCH net-next v2 4/9] net: dsa: lan9645x: add basic dsa driver for LAN9645X
From: Vladimir Oltean @ 2026-04-07 9:12 UTC (permalink / raw)
To: Jens Emil Schulz Ostergaard
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, davem, edumazet, pabeni,
horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <c1b824a3e597b37df133053f6b216e9196b130d5.camel@microchip.com>
On Wed, Apr 01, 2026 at 01:46:19PM +0200, Jens Emil Schulz Ostergaard wrote:
> On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > ---
> > Subject: net: dsa: lan9645x: add basic dsa driver for LAN9645X
> >
> > This commit adds a basic DSA driver for the Microchip LAN9645X switch. It
> > includes initialization, port module setup for NPI, CPU, and front ports,
> > and phylink integration for MAC side configuration.
> >
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_npi.c
> > [ ... ]
> > > +static void disable_conduit_ipv6(struct lan9645x *lan9645x,
> > > + struct net_device *conduit)
> > > +{
> > > + struct inet6_dev *dev_v6;
> > > +
> > > + if (!conduit)
> > > + return;
> > > +
> > > + /* IPv6 on the conduit will generate frames bypassing our tag driver, so
> > > + * they lack an IFH. This will be garbage in garbage out and we want to
> > > + * avoid this.
> > > + */
> > > + rtnl_lock();
> > > + dev_v6 = __in6_dev_get(conduit);
> > > + if (dev_v6) {
> > > + WRITE_ONCE(dev_v6->cnf.disable_ipv6, 1);
> > > + dev_warn(lan9645x->dev, "Disabled IPv6 on conduit device: %s\n",
> > > + netdev_name(conduit));
> > > + }
> > > + rtnl_lock();
> > > +}
> >
> > Does directly modifying dev_v6->cnf.disable_ipv6 bypass the proper sysctl
> > teardown path (addrconf_disable_ipv6) and leave the IPv6 stack in an
> > inconsistent state on the conduit device by failing to clean up routes,
> > addresses, and MLD memberships?
> >
> > Is it a layering violation for a switch driver to alter the networking
> > configuration of an external upper device, especially since this change
> > isn't reverted during driver unbind?
>
> Yes this will bypass the sysctl teardown path. I can change this to instead
> read disable_ipv6 state and warn the user that their device is misconfigured.
I don't want to have to deal with a DSA driver altering the conduit
configuration outside of the DSA core. NACK to any attempts of trying
this.
Define "garbage in, garbage out" for your case. The packets are sent to
random ports? Normally, switches are configured by their drivers to drop
those packets that don't contain DSA tags. You can also do that, by
setting up the switch to require an injection prefix.
> > [ ... ]
> > > + /* Configure IFH prefix mode for NPI port. */
> > > + lan_rmw(SYS_PORT_MODE_INCL_XTR_HDR_SET(LAN9645X_TAG_PREFIX_LONG) |
> > > + SYS_PORT_MODE_INCL_INJ_HDR_SET(LAN9645X_TAG_PREFIX_NONE),
> > > + SYS_PORT_MODE_INCL_XTR_HDR |
> > > + SYS_PORT_MODE_INCL_INJ_HDR,
> > > + lan9645x,
> > > + SYS_PORT_MODE(p->chip_port));
> >
> > Setting LAN9645X_TAG_PREFIX_NONE means the hardware interprets the first
> > bytes of any frame received from the host as an IFH command structure.
> >
> > Does this allow a local user to transmit crafted frames (for example, via
> > raw sockets or standard protocols) whose MAC address bytes map to malicious
> > IFH commands, thereby bypassing VLAN isolation or flooding the switch?
> >
> > Should the hardware be configured to require a strict prefix, such as
> > LAN9645X_TAG_PREFIX_LONG, for injected frames to prevent this?
>
> A prefix offers no protection against the described scenario. The current
> configuration is correct. If a prefix is configured frames MUST contain the
> prefix. With the conduit exposed in userspace this is not something we can
> guarantee.
The short prefix prevents user space from sending frames by mistake
which will reach the wire (daemons attaching to all interfaces, like for DHCP).
It still allows user space to intentionally inject frames into the
switch (for example from XDP on the conduit).
I recommend you go for the short prefix and drop the conduit alterations.
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > [ ... ]
> > > +static int lan9645x_setup(struct dsa_switch *ds)
> > > +{
> > > + struct lan9645x *lan9645x = ds->priv;
> > > + struct device *dev = lan9645x->dev;
> > > + u32 all_phys_ports;
> > > + int err;
> > > +
> > > + lan9645x->num_phys_ports = ds->num_ports;
> > > + all_phys_ports = GENMASK(lan9645x->num_phys_ports - 1, 0);
> > > +
> > > + err = lan9645x_reset_switch(lan9645x);
> > > + if (err)
> > > + return err;
> > > +
> > > + lan9645x->ports = devm_kcalloc(lan9645x->dev, lan9645x->num_phys_ports,
> > > + sizeof(struct lan9645x_port *),
> > > + GFP_KERNEL);
> >
> > Since the DSA .setup callback can be invoked multiple times during the
> > platform device's lifetime (for example, when the DSA master interface is
> > unbound and bound again), does using devm_kcalloc here cause a memory leak?
> > Should these allocations be moved to .probe or managed with kcalloc and
> > freed in .teardown?
> >
>
> Hmm I do not think this is right? I think dsa_tree_teardown is called from
> dsa_switch_remove which is called by the switch drivers .remove.
>
> So I do not think you can get multiple setup/teardown cycles during the device
> lifetime?
>
> As far as I can tell both felix and ksz use device managed allocations in their
> setup callback.
It's valid feedback in general. In a multi-switch tree, ds->ops->setup()
is called when the tree is complete, and ds->ops->teardown() when the
first switch disappears. If there are 2 switches and you unbind and
rebind the driver from A, then switch B will see a ds->ops->teardown()
call followed by ds->ops->setup().
In your case, since the switch doesn't support cascading, it probably
doesn't matter. But the LLM doesn't have the context to know that.
> > [ ... ]
> > > + /* Set all the entries to obey VLAN. */
> > > + for (int i = 0; i < PGID_ENTRIES; ++i)
> > > + lan_wr(ANA_PGID_CFG_OBEY_VLAN_SET(1),
> > > + lan9645x, ANA_PGID_CFG(i));
> >
> > PGID_ENTRIES is defined as 89, so this loop initializes indices 0 through
> > 88. Since the CPU port is index 9, its source PGID is PGID_SRC + CPU_PORT
> > (80 + 9 = 89).
> >
> > Is index 89 left uninitialized, breaking the OBEY_VLAN rule and allowing
> > CPU-injected frames to leak across VLAN boundaries?
> >
>
> No I this misunderstands OBEY_VLAN. When set the vlan table can control
> whether cpu copy from the pgid table is enabled. It makes no sense for PGID 89.
Explain that in a comment.
> > [ ... ]
> > > + /* Multicast to all front ports */
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MC));
> > > +
> > > + /* IP multicast to all front ports */
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV4));
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_MCIPV6));
> > > +
> > > + /* Unicast to all front ports */
> > > + lan_wr(all_phys_ports, lan9645x, ANA_PGID(PGID_UC));
> > > +
> > > + /* Broadcast to all ports */
> > > + lan_wr(BIT(CPU_PORT) | all_phys_ports, lan9645x, ANA_PGID(PGID_BC));
> >
> > PGID_BC includes BIT(CPU_PORT) and all_phys_ports (which includes the NPI
> > port). Will this forward broadcast frames to both the CPU extraction queue
> > and the NPI port's normal egress queue, causing duplicate frames for the host?
> >
> > Conversely, the multicast masks and PGID_UC exclude BIT(CPU_PORT). Does
> > this cause them to bypass the CPU extraction queue entirely, thereby
> > lacking the LONG extraction prefix and breaking the host's DSA tagger parsing?
> >
>
> No this is not how it works. Generally when you configure the CPU port to use
> an NPI port, the hardware manages this internally. You do you have to start
> using the npi port number all of a sudden.
The comment is fair though. Why would you set all_phys_ports to
GENMASK(lan9645x->num_phys_ports - 1, 0) when you can compute the mask
of user ports which are enabled? It seems sloppy at best, and also
contradictory (comments say "all front ports", but code includes the NPI
port in this mask).
> > [ ... ]
> > > +int lan9645x_port_setup(struct dsa_switch *ds, int port)
> > > +{
> > > + struct dsa_port *dp = dsa_to_port(ds, port);
> > > + struct lan9645x *lan9645x = ds->priv;
> > > + struct lan9645x_port *p;
> > > +
> > > + p = lan9645x_to_port(lan9645x, port);
> > > +
> > > + if (dp->dn) {
> > > + p->rx_internal_delay =
> > > + of_property_present(dp->dn, "rx-internal-delay-ps");
> > > + p->tx_internal_delay =
> > > + of_property_present(dp->dn, "tx-internal-delay-ps");
> > > + }
> >
> > These are standard integer properties specifying delays in picoseconds. If
> > a user explicitly disables the delay via devicetree using a value of 0,
> > will of_property_present evaluate to true and enable the hardware delay
> > anyway? Should of_property_read_u32 be used instead to check the value?
>
> A value of 0 is not allowed per the bindings. The bindings enforce that if this
> is present the value must be 2000.
Bindings may change. Please use of_property_read_u32().
^ permalink raw reply
* Re: [net-next PATCH 08/10] net: dsa: realtek: rtl8365mb: add FDB support
From: Linus Walleij @ 2026-04-07 9:11 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260331-realtek_forward-v1-8-44fb63033b7e@gmail.com>
Hi Luiz, Alvin,
thanks for your patch!
I actually at one point started to implement FDB accessors to the RTL8366RB
before I got sidetracked (for the same reasons of being able to do hardware
offloading), here is how far I got before I got distracted:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/patch/?id=9941b129f91e92423803d6e2869022ffa66e9654
You can see that it also has an L2 table albeit with 4 entries rather than 6,
and an additional "CAM" (content adressable memory...) table that I don't quite
understand.
On Wed, Apr 1, 2026 at 1:01 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> +int rtl8365mb_l2_del_mc(struct realtek_priv *priv, u16 port,
> + const unsigned char mac_addr[static ETH_ALEN],
> + u16 vid)
> +int rtl8365mb_l2_get_next_uc(struct realtek_priv *priv, u16 *addr, u16 port,
> + struct rtl8365mb_l2_uc *uc);
> +int rtl8365mb_l2_add_uc(struct realtek_priv *priv, u16 port,
> + const unsigned char addr[static ETH_ALEN],
> + u16 efid, u16 vid);
> +int rtl8365mb_l2_del_uc(struct realtek_priv *priv, u16 port,
> + const unsigned char addr[static ETH_ALEN],
> + u16 efid, u16 vid);
> +int rtl8365mb_l2_flush(struct realtek_priv *priv, int port, u16 vid);
> +
> +int rtl8365mb_l2_add_mc(struct realtek_priv *priv, u16 port,
> + const unsigned char mac_addr[static ETH_ALEN],
> + u16 vid);
> +int rtl8365mb_l2_del_mc(struct realtek_priv *priv, u16 port,
> + const unsigned char mac_addr[static ETH_ALEN],
> + u16 vid);
I think it would make sense to add these to struct realtek_ops and
make them available for all RTL8366 variants.
Possibly it would even make sense to move rtl8365mb_table_query()
to struct realtek_ops under the name .table_query and all of
these helpers to rtl8366-core.c as rtl8366_l2_del_mc() etc
just calling the per-chip table query variant. I'm not sure
but you can perhaps see what makes most sense?
> + struct mutex l2_lock;
Move to struct realtek_priv, every chip will need an l2 lock.
> +static void rtl8365mb_port_fast_age(struct dsa_switch *ds, int port)
> +static int rtl8365mb_port_fdb_add(struct dsa_switch *ds, int port,
> + const unsigned char *addr, u16 vid,
> + struct dsa_db db)
> +static int rtl8365mb_port_fdb_del(struct dsa_switch *ds, int port,
> + const unsigned char *addr, u16 vid,
> + struct dsa_db db)
> +static int rtl8365mb_port_fdb_dump(struct dsa_switch *ds, int port,
> + dsa_fdb_dump_cb_t *cb, void *data)
> +static int rtl8365mb_port_mdb_add(struct dsa_switch *ds, int port,
> + const struct switchdev_obj_port_mdb *mdb,
> + struct dsa_db db)
> +static int rtl8365mb_port_mdb_del(struct dsa_switch *ds, int port,
> + const struct switchdev_obj_port_mdb *mdb,
> + struct dsa_db db)
I think you should rename all of these rtl8366_port_* and move them
to rtl8366-core.c. They are generic.
> @@ -2498,6 +2687,12 @@ static const struct dsa_switch_ops rtl8365mb_switch_ops = {
> .port_bridge_join = rtl8365mb_port_bridge_join,
> .port_bridge_leave = rtl8365mb_port_bridge_leave,
> .port_stp_state_set = rtl8365mb_port_stp_state_set,
> + .port_fast_age = rtl8365mb_port_fast_age,
.port_fast_age = rtl8366_port_fast_age,
Etc.
Curiously I already have a hack for fast aging in the rtl8366rb driver, but
using the FDB directly to do that directly in L2 is definitely better!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Johan Hovold @ 2026-04-07 9:07 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Eric Dumazet, Leon Romanovsky,
Christoph Hellwig, Robin Murphy, maz, Alexander Lobakin,
Saravana Kannan, Mark Brown, alexander.stein, andrew, andrew,
andriy.shevchenko, astewart, bhelgaas, brgl, davem, devicetree,
driver-core, hkallweit1, jirislaby, joel, kees, kuba, lgirdwood,
linux-arm-kernel, linux-aspeed, linux-kernel, linux-pci,
linux-serial, linux-usb, linux, mani, netdev, pabeni, robh
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Doug Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "of_node_reused" over to the "flags"
> field so modifications are safe.
This flag is only set before registering a device with driver core so
there is no issue using the existing bitfield here (with the caveat that
PCI pwrctrl may have gotten that wrong). I haven't checked the other
flags, but I assume most of them work the same way.
But apart from the commit message being misleading, switching to using
atomic ops and accessors for consistency is fine.
> Cc: Johan Hovold <johan@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Not fixing any known bugs; problem is theoretical and found by code
> inspection. Change is done somewhat manually and only lightly tested
> (mostly compile-time tested).
> diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
> index dab8f1ab4450..40e0f1a7ae81 100644
> --- a/drivers/regulator/bq257xx-regulator.c
> +++ b/drivers/regulator/bq257xx-regulator.c
> @@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
> struct regulator_config cfg = {};
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
> if (!pdata)
> diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
> index e66408f23bb6..8297d31cde9f 100644
> --- a/drivers/regulator/rk808-regulator.c
> +++ b/drivers/regulator/rk808-regulator.c
> @@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
> int ret, i, nregulators;
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> if (!regmap)
These two uses are broken currently though and should be using
device_set_of_node_from_dev() so that an extra reference is taken to
balance the one dropped by the platform bus code.
I'll send two fixes to Mark, any merge conflict should be trivial to
fixup.
Reviewed-by: Johan Hovold <johan@kernel.org>
Johan
^ permalink raw reply
* Re: [net-next] net: ethernet: ravb: Suspend and resume the transmission flow
From: Geert Uytterhoeven @ 2026-04-07 9:03 UTC (permalink / raw)
To: Niklas Söderlund, Yoshihiro Shimoda
Cc: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-renesas-soc
In-Reply-To: <20260401183608.1852225-1-niklas.soderlund+renesas@ragnatech.se>
Hi Niklas, Shimoda-san,
On Wed, 1 Apr 2026 at 20:39, Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
>
> From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> The current driver does not follow the latest datasheet and does not
> suspend the flow when stopping DMA and resume it when starting. Update
> the driver to do so.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> [Niklas: Rebase from BSP and reword commit message]
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Thanks for your patch, which is now commit 353d8e7989b6babe ("net:
ethernet: ravb: Suspend and resume the transmission flow") in
linux-next/master net-next.
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -694,6 +694,9 @@ static int ravb_dmac_init(struct net_device *ndev)
> const struct ravb_hw_info *info = priv->info;
> int error;
>
> + /* Clear transmission suspension */
> + ravb_modify(ndev, CCC, CCC_DTSR, 0);
> +
> /* Set CONFIG mode */
> error = ravb_set_opmode(ndev, CCC_OPC_CONFIG);
> if (error)
> @@ -1103,6 +1106,12 @@ static int ravb_stop_dma(struct net_device *ndev)
> if (error)
> return error;
>
> + /* Request for transmission suspension */
> + ravb_modify(ndev, CCC, CCC_DTSR, CCC_DTSR);
> + error = ravb_wait(ndev, CSR, CSR_DTS, CSR_DTS);
> + if (error)
> + netdev_err(ndev, "failed to stop AXI BUS\n");
This error message is printed during resume from s2idle or s2ram on
e.g. Salvator-XS and Gray Hawk Single. Ethernet (nfsroot) still works
fine, though.
> +
> /* Stop AVB-DMAC process */
> return ravb_set_opmode(ndev, CCC_OPC_CONFIG);
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net] selftests: net: bridge_vlan_mcast: wait for h1 before querier check
From: Sverdlin, Alexander @ 2026-04-07 9:03 UTC (permalink / raw)
To: daniel@makrotopia.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <c830f130860fd2efae08bfb9e5b25fd028e58ce5.1775424423.git.daniel@makrotopia.org>
Hi Daniel,
On Sun, 2026-04-05 at 22:29 +0100, Daniel Golle wrote:
> The querier-interval test adds h1 (currently a slave of the VRF created
> by simple_if_init) to a temporary bridge br1 acting as an outside IGMP
> querier. The kernel VRF driver (drivers/net/vrf.c) calls cycle_netdev()
> on every slave add and remove, toggling the interface admin-down then up.
> Phylink takes the PHY down during the admin-down half of that cycle.
> Since h1 and swp1 are cable-connected, swp1 also loses its link may need
> several seconds to re-negotiate.
>
> Use setup_wait_dev $h1 0 which waits for h1 to return to UP state, so the
> test can rely on the link being back up at this point.
>
> Fixes: 4d8610ee8bd77 ("selftests: net: bridge: add vlan mcast_querier_interval tests")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> ---
> tools/testing/selftests/net/forwarding/bridge_vlan_mcast.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/net/forwarding/bridge_vlan_mcast.sh b/tools/testing/selftests/net/forwarding/bridge_vlan_mcast.sh
> index 72dfbeaf56b92..e8031f68200ad 100755
> --- a/tools/testing/selftests/net/forwarding/bridge_vlan_mcast.sh
> +++ b/tools/testing/selftests/net/forwarding/bridge_vlan_mcast.sh
> @@ -414,6 +414,7 @@ vlmc_querier_intvl_test()
> bridge vlan add vid 10 dev br1 self pvid untagged
> ip link set dev $h1 master br1
> ip link set dev br1 up
> + setup_wait_dev $h1 0
> bridge vlan add vid 10 dev $h1 master
> bridge vlan global set vid 10 dev br1 mcast_snooping 1 mcast_querier 1
> sleep 2
--
Alexander Sverdlin
Siemens AG
www.siemens.com
^ permalink raw reply
* Re: [PATCH net 2/2] vsock/test: add MSG_PEEK after partial recv test
From: Luigi Leonardi @ 2026-04-07 8:45 UTC (permalink / raw)
To: Arseniy Krasnov
Cc: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, kvm,
virtualization, netdev, linux-kernel
In-Reply-To: <2521971f-798d-4560-b2d8-bb540591d4b1@salutedevices.com>
Hi Arseniy,
On Sun, Apr 05, 2026 at 10:14:26PM +0300, Arseniy Krasnov wrote:
>
>
>02.04.2026 11:18, Luigi Leonardi wrote:
>> Add a test that verifies MSG_PEEK works correctly after a partial
>> recv().
>>
>> This is to test a bug that was present in the `virtio_transport_stream_do_peek()`
>> when computing the number of bytes to copy: After a partial read, the
>> peek function didn't take into consideration the number of bytes that
>> were already read. So peeking the whole buffer would cause a out-of-bounds read,
>> that resulted in a -EFAULT.
>>
>> This test does exactly this: do a partial recv on a buffer, then try to
>> peek the whole buffer content.
>>
>> Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
>> ---
>> tools/testing/vsock/vsock_test.c | 64 ++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 64 insertions(+)
>>
>> diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
>> index 5bd20ccd9335caafe68e8b7a5d02a4deb3d2deec..308f9f8f30d22bec5aaa282356e400d8438fe321 100644
>> --- a/tools/testing/vsock/vsock_test.c
>> +++ b/tools/testing/vsock/vsock_test.c
>> @@ -346,6 +346,65 @@ static void test_stream_msg_peek_server(const struct test_opts *opts)
>> return test_msg_peek_server(opts, false);
>> }
>>
>> +#define PEEK_AFTER_RECV_LEN 100
>
>Hi, may be we can just reuse MSG_PEEK_BUF_LEN which was already used in MSG_PEEK tests ?
>
yep, good idea!
Thanks!
^ permalink raw reply
* [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Greg Kroah-Hartman @ 2026-04-07 8:45 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, Greg Kroah-Hartman, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-hams,
Yizhe Zhuang, stable
There is a lack of much validation of frame size coming from a
netrom-based device. While these devices are "trusted" doing some
sanity checks is good to at least keep the fuzzing tools happy when they
stumble across this ancient protocol and light up with a range of bug
reports.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Simon Horman <horms@kernel.org>
Cc: linux-hams@vger.kernel.org
Assisted-by: gregkh_clanker_2000
Reviewed-by: Yizhe Zhuang <yizhe@darknavy.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netrom/af_netrom.c | 6 ++++++
net/netrom/nr_route.c | 6 +++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
index b816c56124ab..b605891bf86e 100644
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -885,6 +885,9 @@ int nr_rx_frame(struct sk_buff *skb, struct net_device *dev)
* skb->data points to the netrom frame start
*/
+ if (skb->len < NR_NETWORK_LEN + NR_TRANSPORT_LEN)
+ return 0;
+
src = (ax25_address *)(skb->data + 0);
dest = (ax25_address *)(skb->data + 7);
@@ -963,6 +966,9 @@ int nr_rx_frame(struct sk_buff *skb, struct net_device *dev)
sk = nr_find_listener(dest);
+ if (skb->len < NR_NETWORK_LEN + NR_TRANSPORT_LEN + 1 + AX25_ADDR_LEN)
+ return 0;
+
user = (ax25_address *)(skb->data + 21);
if (sk == NULL || sk_acceptq_is_full(sk) ||
diff --git a/net/netrom/nr_route.c b/net/netrom/nr_route.c
index 9cc29ae85b06..bf60f5682a4f 100644
--- a/net/netrom/nr_route.c
+++ b/net/netrom/nr_route.c
@@ -755,10 +755,10 @@ int nr_route_frame(struct sk_buff *skb, ax25_cb *ax25)
struct sk_buff *nskb, *oskb;
/*
- * Reject malformed packets early. Check that it contains at least 2
- * addresses and 1 byte more for Time-To-Live
+ * Reject malformed packets early. Check that it contains at least
+ * the network and transport headers (20 bytes).
*/
- if (skb->len < 2 * sizeof(ax25_address) + 1)
+ if (skb->len < NR_NETWORK_LEN + NR_TRANSPORT_LEN)
return 0;
nr_src = (ax25_address *)(skb->data + 0);
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v2 2/2] mptcp: add receive queue awareness in tcp_rcv_space_adjust()
From: Matthieu Baerts (NGI0) @ 2026-04-07 8:45 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Florian Westphal
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0)
In-Reply-To: <20260407-net-next-mptcp-reduce-rbuf-v2-0-0d1d135bf6f6@kernel.org>
From: Paolo Abeni <pabeni@redhat.com>
This is the MPTCP counter-part of commit ea33537d8292 ("tcp: add receive
queue awareness in tcp_rcv_space_adjust()").
Prior to this commit:
ESTAB 33165568 0 192.168.255.2:5201 192.168.255.1:53380 \
skmem:(r33076416,rb33554432,t0,tb91136,f448,w0,o0,bl0,d0)
After:
ESTAB 3279168 0 192.168.255.2:5201 192.168.255.1]:53042 \
skmem:(r3190912,rb3719956,t0,tb91136,f1536,w0,o0,bl0,d0)
Same throughput.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
net/mptcp/protocol.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 70a090a95299..cf5747595259 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -2159,11 +2159,13 @@ static void mptcp_rcv_space_adjust(struct mptcp_sock *msk, int copied)
if (rtt_us == U32_MAX || time < (rtt_us >> 3))
return;
- if (msk->rcvq_space.copied <= msk->rcvq_space.space)
+ copied = msk->rcvq_space.copied;
+ copied -= mptcp_inq_hint(sk);
+ if (copied <= msk->rcvq_space.space)
goto new_measure;
trace_mptcp_rcvbuf_grow(sk, time);
- if (mptcp_rcvbuf_grow(sk, msk->rcvq_space.copied)) {
+ if (mptcp_rcvbuf_grow(sk, copied)) {
/* Make subflows follow along. If we do not do this, we
* get drops at subflow level if skbs can't be moved to
* the mptcp rx queue fast enough (announced rcv_win can
@@ -2177,7 +2179,7 @@ static void mptcp_rcv_space_adjust(struct mptcp_sock *msk, int copied)
slow = lock_sock_fast(ssk);
/* subflows can be added before tcp_init_transfer() */
if (tcp_sk(ssk)->rcvq_space.space)
- tcp_rcvbuf_grow(ssk, msk->rcvq_space.copied);
+ tcp_rcvbuf_grow(ssk, copied);
unlock_sock_fast(ssk, slow);
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v2 1/2] mptcp: better mptcp-level RTT estimator
From: Matthieu Baerts (NGI0) @ 2026-04-07 8:45 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Florian Westphal
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0),
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-trace-kernel
In-Reply-To: <20260407-net-next-mptcp-reduce-rbuf-v2-0-0d1d135bf6f6@kernel.org>
From: Paolo Abeni <pabeni@redhat.com>
The current MPTCP-level RTT estimator has several issues. On high speed
links, the MPTCP-level receive buffer auto-tuning happens with a
frequency well above the TCP-level's one. That in turn can cause
excessive/unneeded receive buffer increase.
On such links, the initial rtt_us value is considerably higher than the
actual delay, and the current mptcp_rcv_space_adjust() updates
msk->rcvq_space.rtt_us with a period equal to the such field previous
value. If the initial rtt_us is 40ms, its first update will happen after
40ms, even if the subflows see actual RTT orders of magnitude lower.
Additionally:
- setting the msk RTT to the maximum among all the subflows RTTs makes
DRS constantly overshooting the rcvbuf size when a subflow has
considerable higher latency than the other(s).
- during unidirectional bulk transfers with multiple active subflows,
the TCP-level RTT estimator occasionally sees considerably higher
value than the real link delay, i.e. when the packet scheduler reacts
to an incoming ACK on given subflow pushing data on a different
subflow.
- currently inactive but still open subflows (i.e. switched to backup
mode) are always considered when computing the msk-level RTT.
Address the all the issues above with a more accurate RTT estimation
strategy: the MPTCP-level RTT is set to the minimum of all the subflows
actually feeding data into the MPTCP receive buffer, using a small
sliding window.
While at it, also use EWMA to compute the msk-level scaling_ratio, to
that MPTCP can avoid traversing the subflow list is
mptcp_rcv_space_adjust().
Use some care to avoid updating msk and ssk level fields too often.
Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-trace-kernel@vger.kernel.org
---
v2:
- samples[0] was read without READ_ONCE, prev_rtt_us was not used (AI).
---
include/trace/events/mptcp.h | 2 +-
net/mptcp/protocol.c | 63 ++++++++++++++++++++++++--------------------
net/mptcp/protocol.h | 37 +++++++++++++++++++++++++-
3 files changed, 72 insertions(+), 30 deletions(-)
diff --git a/include/trace/events/mptcp.h b/include/trace/events/mptcp.h
index 269d949b2025..04521acba483 100644
--- a/include/trace/events/mptcp.h
+++ b/include/trace/events/mptcp.h
@@ -219,7 +219,7 @@ TRACE_EVENT(mptcp_rcvbuf_grow,
__be32 *p32;
__entry->time = time;
- __entry->rtt_us = msk->rcvq_space.rtt_us >> 3;
+ __entry->rtt_us = mptcp_rtt_us_est(msk) >> 3;
__entry->copied = msk->rcvq_space.copied;
__entry->inq = mptcp_inq_hint(sk);
__entry->space = msk->rcvq_space.space;
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 2f4776a4f06a..70a090a95299 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -879,6 +879,32 @@ static bool move_skbs_to_msk(struct mptcp_sock *msk, struct sock *ssk)
return moved;
}
+static void mptcp_rcv_rtt_update(struct mptcp_sock *msk,
+ struct mptcp_subflow_context *subflow)
+{
+ const struct tcp_sock *tp = tcp_sk(subflow->tcp_sock);
+ u32 rtt_us = tp->rcv_rtt_est.rtt_us;
+ int id;
+
+ /* Update once per subflow per rcvwnd to avoid touching the msk
+ * too often.
+ */
+ if (!rtt_us || tp->rcv_rtt_est.seq == subflow->prev_rtt_seq)
+ return;
+
+ subflow->prev_rtt_seq = tp->rcv_rtt_est.seq;
+
+ /* Pairs with READ_ONCE() in mptcp_rtt_us_est(). */
+ id = msk->rcv_rtt_est.next_sample;
+ WRITE_ONCE(msk->rcv_rtt_est.samples[id], rtt_us);
+ if (++msk->rcv_rtt_est.next_sample == MPTCP_RTT_SAMPLES)
+ msk->rcv_rtt_est.next_sample = 0;
+
+ /* EWMA among the incoming subflows */
+ msk->scaling_ratio = ((msk->scaling_ratio << 3) - msk->scaling_ratio +
+ tp->scaling_ratio) >> 3;
+}
+
void mptcp_data_ready(struct sock *sk, struct sock *ssk)
{
struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk);
@@ -892,6 +918,7 @@ void mptcp_data_ready(struct sock *sk, struct sock *ssk)
return;
mptcp_data_lock(sk);
+ mptcp_rcv_rtt_update(msk, subflow);
if (!sock_owned_by_user(sk)) {
/* Wake-up the reader only for in-sequence data */
if (move_skbs_to_msk(msk, ssk) && mptcp_epollin_ready(sk))
@@ -2095,7 +2122,6 @@ static void mptcp_rcv_space_init(struct mptcp_sock *msk, const struct sock *ssk)
msk->rcvspace_init = 1;
msk->rcvq_space.copied = 0;
- msk->rcvq_space.rtt_us = 0;
/* initial rcv_space offering made to peer */
msk->rcvq_space.space = min_t(u32, tp->rcv_wnd,
@@ -2106,15 +2132,15 @@ static void mptcp_rcv_space_init(struct mptcp_sock *msk, const struct sock *ssk)
/* receive buffer autotuning. See tcp_rcv_space_adjust for more information.
*
- * Only difference: Use highest rtt estimate of the subflows in use.
+ * Only difference: Use lowest rtt estimate of the subflows in use, see
+ * mptcp_rcv_rtt_update() and mptcp_rtt_us_est().
*/
static void mptcp_rcv_space_adjust(struct mptcp_sock *msk, int copied)
{
struct mptcp_subflow_context *subflow;
struct sock *sk = (struct sock *)msk;
- u8 scaling_ratio = U8_MAX;
- u32 time, advmss = 1;
- u64 rtt_us, mstamp;
+ u32 time, rtt_us;
+ u64 mstamp;
msk_owned_by_me(msk);
@@ -2129,29 +2155,8 @@ static void mptcp_rcv_space_adjust(struct mptcp_sock *msk, int copied)
mstamp = mptcp_stamp();
time = tcp_stamp_us_delta(mstamp, READ_ONCE(msk->rcvq_space.time));
- rtt_us = msk->rcvq_space.rtt_us;
- if (rtt_us && time < (rtt_us >> 3))
- return;
-
- rtt_us = 0;
- mptcp_for_each_subflow(msk, subflow) {
- const struct tcp_sock *tp;
- u64 sf_rtt_us;
- u32 sf_advmss;
-
- tp = tcp_sk(mptcp_subflow_tcp_sock(subflow));
-
- sf_rtt_us = READ_ONCE(tp->rcv_rtt_est.rtt_us);
- sf_advmss = READ_ONCE(tp->advmss);
-
- rtt_us = max(sf_rtt_us, rtt_us);
- advmss = max(sf_advmss, advmss);
- scaling_ratio = min(tp->scaling_ratio, scaling_ratio);
- }
-
- msk->rcvq_space.rtt_us = rtt_us;
- msk->scaling_ratio = scaling_ratio;
- if (time < (rtt_us >> 3) || rtt_us == 0)
+ rtt_us = mptcp_rtt_us_est(msk);
+ if (rtt_us == U32_MAX || time < (rtt_us >> 3))
return;
if (msk->rcvq_space.copied <= msk->rcvq_space.space)
@@ -3015,6 +3020,7 @@ static void __mptcp_init_sock(struct sock *sk)
msk->timer_ival = TCP_RTO_MIN;
msk->scaling_ratio = TCP_DEFAULT_SCALING_RATIO;
msk->backlog_len = 0;
+ mptcp_init_rtt_est(msk);
WRITE_ONCE(msk->first, NULL);
inet_csk(sk)->icsk_sync_mss = mptcp_sync_mss;
@@ -3460,6 +3466,7 @@ static int mptcp_disconnect(struct sock *sk, int flags)
msk->bytes_retrans = 0;
msk->rcvspace_init = 0;
msk->fastclosing = 0;
+ mptcp_init_rtt_est(msk);
/* for fallback's sake */
WRITE_ONCE(msk->ack_seq, 0);
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 1208f317ac33..e1d4783db02f 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -269,6 +269,13 @@ struct mptcp_data_frag {
struct page *page;
};
+/* Arbitrary compromise between as low as possible to react timely to subflow
+ * close event and as big as possible to avoid being fouled by biased large
+ * samples due to peer sending data on a different subflow WRT to the incoming
+ * ack.
+ */
+#define MPTCP_RTT_SAMPLES 5
+
/* MPTCP connection sock */
struct mptcp_sock {
/* inet_connection_sock must be the first member */
@@ -341,11 +348,17 @@ struct mptcp_sock {
*/
struct mptcp_pm_data pm;
struct mptcp_sched_ops *sched;
+
+ /* Most recent rtt_us observed by in use incoming subflows. */
+ struct {
+ u32 samples[MPTCP_RTT_SAMPLES];
+ u32 next_sample;
+ } rcv_rtt_est;
+
struct {
int space; /* bytes copied in last measurement window */
int copied; /* bytes copied in this measurement window */
u64 time; /* start time of measurement window */
- u64 rtt_us; /* last maximum rtt of subflows */
} rcvq_space;
u8 scaling_ratio;
bool allow_subflows;
@@ -423,6 +436,27 @@ static inline struct mptcp_data_frag *mptcp_send_head(const struct sock *sk)
return msk->first_pending;
}
+static inline void mptcp_init_rtt_est(struct mptcp_sock *msk)
+{
+ int i;
+
+ for (i = 0; i < MPTCP_RTT_SAMPLES; ++i)
+ msk->rcv_rtt_est.samples[i] = U32_MAX;
+ msk->rcv_rtt_est.next_sample = 0;
+ msk->scaling_ratio = TCP_DEFAULT_SCALING_RATIO;
+}
+
+static inline u32 mptcp_rtt_us_est(const struct mptcp_sock *msk)
+{
+ u32 rtt_us = READ_ONCE(msk->rcv_rtt_est.samples[0]);
+ int i;
+
+ /* Lockless access of collected samples. */
+ for (i = 1; i < MPTCP_RTT_SAMPLES; ++i)
+ rtt_us = min(rtt_us, READ_ONCE(msk->rcv_rtt_est.samples[i]));
+ return rtt_us;
+}
+
static inline struct mptcp_data_frag *mptcp_send_next(struct sock *sk)
{
struct mptcp_sock *msk = mptcp_sk(sk);
@@ -524,6 +558,7 @@ struct mptcp_subflow_context {
u32 map_data_len;
__wsum map_data_csum;
u32 map_csum_len;
+ u32 prev_rtt_seq;
u32 request_mptcp : 1, /* send MP_CAPABLE */
request_join : 1, /* send MP_JOIN */
request_bkup : 1,
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v2 0/2] mptcp: autotune related improvement
From: Matthieu Baerts (NGI0) @ 2026-04-07 8:45 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Florian Westphal
Cc: netdev, mptcp, linux-kernel, Matthieu Baerts (NGI0),
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-trace-kernel
Here are two patches from Paolo that have been crafted a couple of
months ago, but needed more validation because they were indirectly
causing instabilities in the sefltests. The root cause has been fixed in
'net' recently in commit 8c09412e584d ("selftests: mptcp: more stable
simult_flows tests").
These patches refactor the receive space and RTT estimator, overall
making DRS more correct while avoiding receive buffer drifting to
tcp_rmem[2], which in turn makes the throughput more stable and less
bursty, especially with high bandwidth and low delay environments.
Note that the first patch addresses a very old issue. 'net-next' is
targeted because the change is quite invasive and based on a recent
backlog refactor. The 'Fixes' tag is then there more as a FYI, because
backporting this patch will quickly be blocked due to large conflicts.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Changes in v2:
- Patch 1: add missing READ_ONCE() and remove unused entry. (AI)
- Link to v1: https://patch.msgid.link/20260309-net-next-mptcp-reduce-rbuf-v1-0-8f471206f9c5@kernel.org
---
Paolo Abeni (2):
mptcp: better mptcp-level RTT estimator
mptcp: add receive queue awareness in tcp_rcv_space_adjust()
include/trace/events/mptcp.h | 2 +-
net/mptcp/protocol.c | 71 +++++++++++++++++++++++++-------------------
net/mptcp/protocol.h | 37 ++++++++++++++++++++++-
3 files changed, 77 insertions(+), 33 deletions(-)
---
base-commit: c149d90e260ca1b6b9175468955a15c4d95a9f3b
change-id: 20260306-net-next-mptcp-reduce-rbuf-4166ba6fb763
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
^ permalink raw reply
* [PATCH net] net: initialize sk_rx_queue_mapping in sk_clone()
From: Jiayuan Chen @ 2026-04-07 8:42 UTC (permalink / raw)
To: netdev
Cc: Jiayuan Chen, Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni,
Willem de Bruijn, David S. Miller, Jakub Kicinski, Simon Horman,
Soheil Hassas Yeganeh, linux-kernel
sk_clone() initializes sk_tx_queue_mapping via sk_tx_queue_clear()
but does not initialize sk_rx_queue_mapping. Since this field is in
the sk_dontcopy region, it is neither copied from the parent socket
by sock_copy() nor zeroed by sk_prot_alloc() (called without
__GFP_ZERO from sk_clone).
Commit 03cfda4fa6ea ("tcp: fix another uninit-value
(sk_rx_queue_mapping)") attempted to fix this by introducing
sk_mark_napi_id_set() with force_set=true in tcp_child_process().
However, sk_mark_napi_id_set() -> sk_rx_queue_set() only writes
when skb_rx_queue_recorded(skb) is true. If the 3-way handshake
ACK arrives through a device that does not record rx_queue (e.g.
loopback or veth), sk_rx_queue_mapping remains uninitialized.
When a subsequent data packet arrives with a recorded rx_queue,
sk_mark_napi_id() -> sk_rx_queue_update() reads the uninitialized
field for comparison (force_set=false path), triggering KMSAN.
This was reproduced by establishing a TCP connection over loopback
(which does not call skb_record_rx_queue), then attaching a BPF TC
program on lo ingress to set skb->queue_mapping on data packets:
BUG: KMSAN: uninit-value in tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1875)
tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1875)
tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2287)
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207)
ip_local_deliver_finish (net/ipv4/ip_input.c:242)
ip_local_deliver (net/ipv4/ip_input.c:262)
ip_rcv (net/ipv4/ip_input.c:573)
__netif_receive_skb (net/core/dev.c:6294)
process_backlog (net/core/dev.c:6646)
__napi_poll (net/core/dev.c:7710)
net_rx_action (net/core/dev.c:7929)
handle_softirqs (kernel/softirq.c:623)
do_softirq (kernel/softirq.c:523)
__local_bh_enable_ip (kernel/softirq.c:?)
__dev_queue_xmit (net/core/dev.c:?)
ip_finish_output2 (net/ipv4/ip_output.c:237)
ip_output (net/ipv4/ip_output.c:438)
__ip_queue_xmit (net/ipv4/ip_output.c:534)
__tcp_transmit_skb (net/ipv4/tcp_output.c:1693)
tcp_write_xmit (net/ipv4/tcp_output.c:3064)
tcp_sendmsg_locked (net/ipv4/tcp.c:?)
tcp_sendmsg (net/ipv4/tcp.c:1465)
inet_sendmsg (net/ipv4/af_inet.c:865)
sock_write_iter (net/socket.c:1195)
vfs_write (fs/read_write.c:688)
...
Uninit was created at:
kmem_cache_alloc_noprof (mm/slub.c:4873)
sk_prot_alloc (net/core/sock.c:2239)
sk_alloc (net/core/sock.c:2301)
inet_create (net/ipv4/af_inet.c:334)
__sock_create (net/socket.c:1605)
__sys_socket (net/socket.c:1747)
Fix this at the root by adding sk_rx_queue_clear() alongside
sk_tx_queue_clear() in sk_clone().
Fixes: 342159ee394d ("net: avoid dirtying sk->sk_rx_queue_mapping")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
net/core/sock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/sock.c b/net/core/sock.c
index 5976100a9d55..a12c5eca88f2 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2583,6 +2583,7 @@ struct sock *sk_clone(const struct sock *sk, const gfp_t priority,
sk_set_socket(newsk, NULL);
sk_tx_queue_clear(newsk);
+ sk_rx_queue_clear(newsk);
RCU_INIT_POINTER(newsk->sk_wq, NULL);
if (newsk->sk_prot->sockets_allocated)
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox