* Re: [net-next PATCH 07/10] net: dsa: realtek: rtl8365mb: add port_bridge_{join,leave}
From: Linus Walleij @ 2026-04-07 8: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-7-44fb63033b7e@gmail.com>
Hi Luiz, Alvin,
thanks for your patch!
On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> static int rtl8365mb_port_set_isolation(struct realtek_priv *priv, int port,
> u32 mask)
> +static int rtl8365mb_port_add_isolation(struct realtek_priv *priv, int port,
> + u32 mask)
> +static int rtl8365mb_port_remove_isolation(struct realtek_priv *priv, int port,
> + u32 mask)
This is smart!
> +static int rtl8365mb_port_bridge_join(struct dsa_switch *ds, int port,
> + struct dsa_bridge bridge,
> + bool *tx_forward_offload,
> + struct netlink_ext_ack *extack)
> +static void rtl8365mb_port_bridge_leave(struct dsa_switch *ds, int port,
> + struct dsa_bridge bridge)
The content of these functions are very similar to
rtl8366rb_port_bridge_join() and rtl8366rb_port_bridge_leave().
What about moving this code to the shared library rtl8366-core as
rtl8366_port_bridge_join() and rtl8366_port_bridge_leave()
and add per-variant callbacks for ->port_set_isolation()
->port_add_isolation() and ->port_remove_isolation() to
struct realtek_ops and share this with rtl8366rb by refactoring
rtl8366rb.c to use the same callbacks.
Using shared code will help us to avoid having to fix the same
bugs in more than one place.
I don't know about this EFID stuff in rtl8365mb_port_set_efid()
(maybe RTL8366RB needs something like that too) but certainly that
can be an optional callback in struct realtek_ops for now.
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH net] net: txgbe: fix RTNL assertion warning when remove module
From: Jiawen Wu @ 2026-04-07 8:07 UTC (permalink / raw)
To: 'Russell King (Oracle)'
Cc: netdev, 'Mengyuan Lou', 'Andrew Lunn',
'David S. Miller', 'Eric Dumazet',
'Jakub Kicinski', 'Paolo Abeni',
'Simon Horman', 'Jacob Keller',
'Abdun Nihaal', stable, netdev, 'Mengyuan Lou',
'Andrew Lunn', 'David S. Miller',
'Eric Dumazet', 'Jakub Kicinski',
'Paolo Abeni', 'Simon Horman',
'Jacob Keller', 'Abdun Nihaal', stable
In-Reply-To: <adS0_I_2HBH-gM19@shell.armlinux.org.uk>
On Tue, Apr 7, 2026 3:41 PM, Russell King (Oracle) wrote:
> On Tue, Apr 07, 2026 at 02:27:34PM +0800, Jiawen Wu wrote:
> > On Wed, Apr 1, 2026 2:22 PM, Russell King (Oracle) wrote:
> > > On Wed, Apr 01, 2026 at 10:16:34AM +0800, Jiawen Wu wrote:
> > > > On Tue, Mar 31, 2026 9:08 PM, Russell King (Oracle) wrote:
> > > > > On Tue, Mar 31, 2026 at 03:11:07PM +0800, Jiawen Wu wrote:
> > > > > > 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, move the phylink connect/disconnect PHY to ndo_open/close.
> > > > >
> > > > > Wouldn't it be simpler to just wrap the phylink_disconnect_phy() in the
> > > > > remove function with rtnl_lock()..rtnl_unlock() ?
> > > >
> > > > This is also a solution. But I think it would be nice to unify with other drivers
> > > > that call the functions in ndo_open/close.
> > >
> > > Both approaches are equally valid. Some network drivers attach the PHY
> > > at probe time (and thus can return -EPROBE_DEFER if the PHY is specified
> > > but not present). Others attach in .ndo_open which can only fail in this
> > > circumstance with no retry without userspace manually implementing that.
> > >
> > > There are other advantages and disadvantages to each approach.
> >
> > Hi,
> >
> > So is it still recommended that add rtnl_lock()...rtnl_unlock() instead of moving it?
>
> The reaosn phylink_disconnect_phy() requires the RTNL lock is because it
> _can_ be called while the netdev is published, and the RTNL lock
> protects the networking core from the PHY being removed from the netdev,
> preventing ethtool ops into the PHY driver from running concurrently
> with the PHY's disconnection and potential later destruction.
>
> Offering two APIs, one which requires the lock to provide that
> protection and one which doesn't would over-complicate the phylink code
> and make reviews way more difficult, as we'd now have to spot the
> wrong function being used in the wrong code path.
>
> It's simpler for drivers that want to connect and disconnect the PHY
> at probe/remove time for them to just take the RTNL lock briefly over
> the call to phylink_disconnect_phy().
>
> There is no "recommendation" for connecting and disconnecting the
> PHY at probe/remove time vs ndo_open/ndo_release. That's entirely up
> to the driver author. As I've already said, there are advantages and
> disadvantages of either way and that's a matter for the driver author
> to consider and select the most appropriate choice for their driver.
OK. I'll change it at v2 patch.
^ permalink raw reply
* Re: [PATCH v2] xfrm6: fix slab-out-of-bounds write in xfrm6_input_addr()
From: Steffen Klassert @ 2026-04-07 8:15 UTC (permalink / raw)
To: I Viswanath; +Cc: nicholas, netdev, Herbert Xu, David S . Miller, Milad Nasr
In-Reply-To: <CAPrAcgNbbcLrJDBs03=CQU0VzbqaEGi_h4gsrWY693ERsuTE1A@mail.gmail.com>
On Wed, Apr 01, 2026 at 09:56:40PM +0530, I Viswanath wrote:
> On Wed, 1 Apr 2026 at 10:26, <nicholas@carlini.com> wrote:
>
> > - if (1 + sp->len == XFRM_MAX_DEPTH) {
> > + if (1 + sp->len >= XFRM_MAX_DEPTH) {
> > XFRM_INC_STATS(net, LINUX_MIB_XFRMINBUFFERERROR);
> > goto drop;
> > }
>
> If you look at other places where sp->len is incremented, you will
> notice the guard condition is always (sp->len == XFRM_MAX_DEPTH). This
> bug exists because in xfrm6_input.c, the greatest valid index is taken
> to be XFRM_MAX_DEPTH - 2 when it should be XFRM_MAX_DEPTH - 1.
> Therefore, The correct fix should be using the common guard not
> changing the guard to use >=
>
> On a tangential note, There is no guard present before the increment
> in xfrm_output.c which is probably another OOB bug
Nicholas, please have a look if you can update your patch based
on these comments.
Thanks!
^ permalink raw reply
* Re: [PATCH ipsec 1/2] xfrm: Wait for RCU readers during policy netns exit
From: Steffen Klassert @ 2026-04-07 8:16 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <ac5YaN5EJQwokOq6@strlen.de>
On Thu, Apr 02, 2026 at 01:52:08PM +0200, Florian Westphal wrote:
> Steffen Klassert <steffen.klassert@secunet.com> wrote:
> > xfrm_policy_fini() frees the policy_bydst hash tables after flushing the
> > policy work items and deleting all policies, but it does not wait for
> > concurrent RCU readers to leave their read-side critical sections first.
> >
> > The policy_bydst tables are published via rcu_assign_pointer() and are
> > looked up through rcu_dereference_check(), so netns teardown must also
> > wait for an RCU grace period before freeing the table memory.
> >
> > Fix this by adding synchronize_rcu() before freeing the policy hash tables.
> >
> > Fixes: e1e551bc5630 ("xfrm: policy: prepare policy_bydst hash for rcu lookups")
>
> Reviewed-by: Florian Westphal <fw@strlen.de>
This is now applied to the ipsec tree.
^ permalink raw reply
* Re: [PATCH v3] xfrm: hold dev ref until after transport_finish NF_HOOK
From: Steffen Klassert @ 2026-04-07 8:18 UTC (permalink / raw)
To: Qi Tang
Cc: Herbert Xu, Florian Westphal, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern, netdev,
stable
In-Reply-To: <20260402114401.62212-1-tpluszz77@gmail.com>
On Thu, Apr 02, 2026 at 07:44:01PM +0800, Qi Tang wrote:
> After async crypto completes, xfrm_input_resume() calls dev_put()
> immediately on re-entry before the skb reaches transport_finish.
> The skb->dev pointer is then used inside NF_HOOK and its okfn,
> which can race with device teardown.
>
> Remove the dev_put from the async resumption entry and instead
> drop the reference after the NF_HOOK call in transport_finish,
> using a saved device pointer since NF_HOOK may consume the skb.
> This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip
> the okfn.
>
> For non-transport exits (decaps, gro, drop) and secondary
> async return points, release the reference inline when
> async is set.
>
> Suggested-by: Florian Westphal <fw@strlen.de>
> Fixes: acf568ee859f ("xfrm: Reinject transport-mode packets through tasklet")
> Cc: stable@vger.kernel.org
> Signed-off-by: Qi Tang <tpluszz77@gmail.com>
Applied to the ipsec tree, thanks a lot!
^ permalink raw reply
* Re: [PATCH v2] net: sfp: add quirks for GPON ONT SFP sticks
From: Russell King (Oracle) @ 2026-04-07 8:18 UTC (permalink / raw)
To: John Pavlick
Cc: andrew, hkallweit1, davem, edumazet, kuba, pabeni, netdev,
linux-kernel, Marcin Nita
In-Reply-To: <20260406121716.69854-1-jspavlick@posteo.net>
On Mon, Apr 06, 2026 at 12:17:21PM +0000, John Pavlick wrote:
> Several GPON ONT SFP sticks based on Realtek RTL960x report
> 1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X.
> On hosts with serdes fixed at 2.5Gbase-X (e.g. Banana Pi R3 / MT7986),
> the kernel rejects them with 'no common interface modes'.
>
> Add quirks for:
> - Hisense-Leox LXT-010S-H
> - Hisense ZNID-GPON-2311NA
> - HSGQ HSGQ-XPON-Stick
>
> Each quirk advertises 2500base-X and ignores TX_FAULT during the
> module's ~40s Linux boot time.
>
> Tested on Banana Pi R3 (MT7986) with OpenWrt 25.12.1, confirmed
> 2.5Gbps link and full throughput with flow offloading.
>
> Suggested-by: Marcin Nita <marcin.nita@leolabs.pl>
> Signed-off-by: John Pavlick <jspavlick@posteo.net>
> ---
> Changes in v2:
> - Add Suggested-by tag for Marcin Nita <marcin.nita@leolabs.pl>, who
> suggested investigating sfp.c quirks as a solution rather than
> attempting to edit the EEPROM data directly on the module.
Please read the maintainer-netdev documentation, particularly on
submisison of patches. You need to specify the tree and also avoid
resending within 24 ours.
Patch looks fine.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Thanks!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net v2 1/1] af_unix: read UNIX_DIAG_VFS data under unix_state_lock
From: Jason Xing @ 2026-04-07 8:21 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, kuniyu, davem, edumazet, kuba, pabeni, horms, xemul,
yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z,
wangjiexun2025
In-Reply-To: <20260407080015.1744197-1-n05ec@lzu.edu.cn>
On Tue, Apr 7, 2026 at 4:01 PM Ren Wei <n05ec@lzu.edu.cn> wrote:
>
> From: Jiexun Wang <wangjiexun2025@gmail.com>
>
> Exact UNIX diag lookups hold a reference to the socket, but not to
> u->path. Meanwhile, unix_release_sock() clears u->path under
> unix_state_lock() and drops the path reference after unlocking.
>
> Read the inode and device numbers for UNIX_DIAG_VFS while holding
> unix_state_lock(), then emit the netlink attribute after dropping the
> lock.
>
> This keeps the VFS data stable while the reply is being built.
>
> Fixes: 5f7b0569460b ("unix_diag: Unix inode info NLA")
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Tested-by: Ren Wei <enjou1224z@gmail.com>
> Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Next time, please, you should obey the submission rules. One of them
is to at least wait ~24 hours before posting a new version, which
makes reviewers from all over the world have a chance to take a look
at your patch.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH net-next v2 9/9] net: dsa: lan9645x: add port statistics
From: Jens Emil Schulz Ostergaard @ 2026-04-07 8:25 UTC (permalink / raw)
To: Jakub Kicinski
Cc: UNGLinuxDriver, andrew, olteanv, davem, edumazet, pabeni, horms,
robh, krzk+dt, conor+dt, woojung.huh, linux, Steen.Hegelund,
daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260329195639.2789284-1-kuba@kernel.org>
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.
> ---
> net: dsa: lan9645x: add port statistics
>
> Add statistics support for the port counters. Chip registers are 32 bit,
> so this unit is responsible maintaining a 64bit software cache, and
> updating it frequently to handle overflows in hardware.
>
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > index 24a60f40f6b8..9a46c08dad59 100644
> > --- a/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_main.c
> [ ... ]
> > @@ -262,6 +264,12 @@ static int lan9645x_setup(struct dsa_switch *ds)
> > if (!lan9645x->owq)
> > return -ENOMEM;
> >
> > + err = lan9645x_stats_init(lan9645x);
> > + if (err) {
> > + dev_err(dev, "Failed to init stats.\n");
> > + goto owq_destroy;
> > + }
> > +
> [ ... ]
> > diff --git a/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c b/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c
> > index 000000000000..3e82a859f173
> > --- /dev/null
> > +++ b/drivers/net/dsa/microchip/lan9645x/lan9645x_stats.c
> [ ... ]
> > +static const struct lan9645x_ethtool_stat lan9645x_port_ethtool_stats[] = {
> > + { "rx_uc", SCNT_RX_UC },
> > + { "rx_cat_drop", SCNT_RX_CAT_DROP },
> [ ... ]
> > + { "tx_uc", SCNT_TX_UC },
> > + { "tx_drop", SCNT_TX_DROP },
> [ ... ]
> > +};
>
> Is it necessary to duplicate standard networking statistics in the driver
> private ethtool output?
>
> The networking subsystem guidelines state that stats possessing a standard UAPI
> representation, such as tx_dropped and rx_packets in struct rtnl_link_stats64,
> should not be duplicated in the ethtool -S output.
>
> Could these redundant strings be removed since the driver natively supports
> them via lan9645x_stats_get_stats64?
>
I do not think they are redundant. They are only available in an aggregated form
via rtnl_link_stats64, not directly. Information is lost if they are removed.
> [ ... ]
> > +static const struct lan9645x_view_stats lan9645x_view_stat_cfgs[] = {
> > + [LAN9645X_STAT_PORTS] = {
> > + .name = "ports",
> > + .type = LAN9645X_STAT_PORTS,
> > + .layout = lan9645x_port_stats_layout,
> > + .num_cnts = ARRAY_SIZE(lan9645x_port_stats_layout),
> > + .num_indexes = NUM_PHYS_PORTS,
> > + },
> > +};
> [ ... ]
> > +static u64 *lan9645x_stats_view_idx_update(struct lan9645x *lan9645x,
> > + enum lan9645x_view_stat_type vtype,
> > + int idx)
> > +{
> > + struct lan9645x_stats *s = lan9645x->stats;
> > +
> > + mutex_lock(&s->hw_lock);
> > + __lan9645x_stats_view_idx_update(lan9645x, vtype, idx);
> > + mutex_unlock(&s->hw_lock);
> > +
> > + return STAT_COUNTERS(lan9645x, vtype, idx);
> > +}
>
> Does this code overflow the allocated buffer when called for the CPU port?
>
> The stats buffer cnts is allocated using num_indexes, which is NUM_PHYS_PORTS
> (9). This covers ports 0 to 8. However, the CPU port is defined as index 9
> (CPU_PORT = 9).
>
> When the DSA core invokes stat callbacks like get_ethtool_stats or get_stats64
> for the CPU port, the idx argument is 9. While the helper
> __lan9645x_stats_view_idx_update skips the hardware read for out-of-bounds
> indices, lan9645x_stats_view_idx_update ignores that failure and returns the
> result of STAT_COUNTERS(lan9645x, vtype, idx).
>
> This computes a pointer past the end of the cnts array, which the callers then
> blindly dereference, potentially leaking kernel memory or causing a crash. Can
> bounds checking be added to the callers, or should the buffer be sized to
> include the CPU port?
>
No this is not called for the CPU port index 9.
> [ ... ]
> > +void lan9645x_stats_get_ethtool_stats(struct lan9645x *lan9645x, int port,
> > + u64 *data)
> > +{
> > + struct lan9645x_stats *stats = lan9645x->stats;
> > + u64 *c;
> > + int i;
> > +
> > + c = lan9645x_stats_view_idx_update(lan9645x, LAN9645X_STAT_PORTS, port);
> > +
> > + spin_lock(&stats->sw_lock);
> > + for (i = 0; i < ARRAY_SIZE(lan9645x_port_ethtool_stats); i++)
> > + *data++ = c[lan9645x_port_ethtool_stats[i].idx];
> > + spin_unlock(&stats->sw_lock);
> > +}
> [ ... ]
> > +/* Called in atomic context */
> > +void lan9645x_stats_get_stats64(struct lan9645x *lan9645x, int port,
> > + struct rtnl_link_stats64 *stats)
> > +{
> > + struct lan9645x_stats *s = lan9645x->stats;
> > + u64 *c;
> > +
> > + c = STAT_COUNTERS(lan9645x, LAN9645X_STAT_PORTS, port);
> > +
> > + spin_lock(&s->sw_lock);
>
> Can this code deadlock when a softirq interrupts a process holding the lock?
>
> The sw_lock spinlock protects the 64-bit software stats counters. In
> lan9645x_stats_get_stats64, which acts as the ndo_get_stats64 callback, this
> lock is acquired using a plain spin_lock. The code comment notes this function
> is called in atomic context (such as from NET_RX_SOFTIRQ via dev_get_stats).
>
> Concurrently, process context paths like lan9645x_stats_get_ethtool_stats and
> lan9645x_check_stats_work also acquire sw_lock using plain spin_lock. Because
> plain spin_lock does not disable softirqs, if a softirq preempts the execution
> on a CPU while process context holds sw_lock, the softirq will spin
> indefinitely waiting for the lock.
>
> Should the process-context acquisitions use spin_lock_bh instead?
>
As far as I can tell ndo_get_stats64 is not called from softirq. Ocelot also uses
a plain spin_lock here. Since no softirq path touches this lock, there is no
deadlock.
> [ ... ]
> > +int lan9645x_stats_init(struct lan9645x *lan9645x)
> > +{
> > + const struct lan9645x_view_stats *vs;
> > + struct lan9645x_stats *stats;
> > + int err, i;
> > +
> > + lan9645x->stats = devm_kzalloc(lan9645x->dev, sizeof(*stats),
> > + GFP_KERNEL);
>
> Will this memory be leaked when the DSA switch unbinds and rebinds?
>
> The lan9645x_stats_init function allocates lan9645x->stats, vstat->cnts, and
> vstat->buf using devm_kzalloc and devm_kcalloc. This function is called from
> lan9645x_setup, which is the DSA .setup callback.
>
> The DSA tree lifecycle is independent of the platform device lifecycle. If the
> master netdevice is unbound and bound again, the DSA switch's .teardown and
> .setup callbacks will be invoked multiple times. Because .teardown cannot free
> devres-managed memory, the memory tied to the platform device will be leaked
> on every setup cycle until the switch's platform device itself is destroyed.
>
> Could this use standard kzalloc allocations paired with kfree in teardown?
Similar comment as the devm_* comment for the .setup function. I do not think
this is a problem, since there can not be multiple setup/teardown cycles
during the device lifetime. dsa_tree_teardown is only called from
dsa_switch_remove which is called by the switch drivers .remove.
As far as I can tell both felix and ksz use device managed allocations in their
setup callback.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: Add schema for LAN75XX compatible USB Ethernet controllers
From: Thomas Richard @ 2026-04-07 8:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20260405-smoky-spectacular-koel-dbfcda@quoll>
Hello Krzysztof,
On 4/5/26 10:06 AM, Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 09:02:23PM +0200, Thomas Richard wrote:
>> Create schema for LAN75XX compatible USB Ethernet controllers. The smsc75xx
>> driver only supports LAN7500 and LAN7505 devices.
>>
>> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
>> ---
>> .../devicetree/bindings/net/microchip,lan75xx.yaml | 52 ++++++++++++++++++++++
>> 1 file changed, 52 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..b84022976044ffec2024cff9fc0aa5016723abed
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
>
> Rather microchip,lan7500.yaml. Wildcards don't really scale when you
> have 75yy coming which does not fit into this binding.
>
>
>> @@ -0,0 +1,52 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/net/microchip,lan75xx.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip LAN7500/LAN7505 USB Ethernet Controllers
>> +
>> +maintainers:
>> + - Thomas Richard <thomas.richard@bootlin.com>
>> +
>> +description:
>> + Device tree properties for LAN75XX compatible USB Ethernet controller.
>> +
>> +allOf:
>> + - $ref: ethernet-controller.yaml#
>> +
>> +properties:
>> + compatible:
>> + items:
>
> Drop items, that's enum directly.
>
>> + - enum:
>> + - usb424,7500
>> + - usb424,7505
>
> But you should notice that this is exactly the same as 95xx, so why it
> cannot go there? Because of the wildcard 95xx naming? That's not a
> reason.
Yes I noticed. I did not put them in 95xx because it is not the same
driver. Isn't that a valid reason?
Best Regards,
Thomas
^ permalink raw reply
* [PATCH net] atm: mpoa: fix mpc->dev refcount across mpoad restart
From: Shuvam Pandey @ 2026-04-07 8:35 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, netdev
Cc: linux-kernel, syzbot+5ec223ccb83b24ef982f
atm: mpoa: fix mpc->dev refcount across mpoad restart
mpoad_close() drops the reference held in mpc->dev with dev_put(), but
the mpoa_client stays alive and keeps the same device pointer.
A later mpoad attach reuses the existing mpoa_client without
reacquiring that reference, so the next close can hit the netdevice
refcount warning. Keep the LEC device reference with the mpoa_client
until the device unregisters or the client is torn down.
Reported-by: syzbot+5ec223ccb83b24ef982f@syzkaller.appspotmail.com
Link: https://groups.google.com/g/syzkaller-bugs/c/qhZ5MJfLBOE/m/UnotmgRdAQAJ
Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com>
---
net/atm/mpc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/atm/mpc.c b/net/atm/mpc.c
index ce8e9780373b..1e9b9c633e8b 100644
--- a/net/atm/mpc.c
+++ b/net/atm/mpc.c
@@ -886,7 +886,6 @@ static void mpoad_close(struct atm_vcc *vcc)
struct lec_priv *priv = netdev_priv(mpc->dev);
priv->lane2_ops->associate_indicator = NULL;
stop_mpc(mpc);
- dev_put(mpc->dev);
}
mpc->in_ops->destroy_cache(mpc);
@@ -1508,6 +1507,8 @@ static void __exit atm_mpoa_cleanup(void)
priv = netdev_priv(mpc->dev);
if (priv->lane2_ops != NULL)
priv->lane2_ops->associate_indicator = NULL;
+ dev_put(mpc->dev);
+ mpc->dev = NULL;
}
ddprintk("about to clear caches\n");
mpc->in_ops->destroy_cache(mpc);
--
2.50.0
^ permalink raw reply related
* Re: [PATCH 1/1] net: hsr: avoid learning nodes from ordinary PRP SAN traffic
From: Paolo Abeni @ 2026-04-07 8:40 UTC (permalink / raw)
To: Ao Zhou, netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Simon Horman,
Felix Maurer, Murali Karicheri, Shaurya Rane,
Sebastian Andrzej Siewior, Ingo Molnar, Kees Cook, Yifan Wu,
Juefei Pu, Yuan Tan, Xin Liu, Yuqi Xu
In-Reply-To: <9c88b4b7844f867d065e7a7aba28b2c026386168.1775056603.git.royenheart@outlook.com>
On 4/2/26 4:18 PM, Ao Zhou wrote:
> From: Haoze Xie <royenheart@gmail.com>
>
> PRP slave ports accept ordinary SAN traffic and forward it to the
> master device without needing a persistent node entry. Creating one
> node per previously unseen SAN source lets arbitrary source MAC floods
> grow node_db until the prune timer catches up.
>
> Keep the receive path for ordinary PRP SAN traffic, but stop learning a
> new node when the frame is untagged and does not carry a PRP trailer.
> Continue to deliver the frame locally and only keep node state for
> actual HSR/PRP senders or nodes that have already been learned.
It's not clear to me what prevents the rouge sender from always
including a valid PRP trailer, thus still causing the issue addressed
here. Some rationale needs to be included, or possibly limit the amount
of newly created nodes to some configurable maximum.
> Fixes: 451d8123f897 ("net: prp: add packet handling support")
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Tested-by: Yuqi Xu <xuyuqiabc@gmail.com>
> Signed-off-by: Haoze Xie <royenheart@gmail.com>
> Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
> ---
> net/hsr/hsr_forward.c | 14 ++++++++++----
> net/hsr/hsr_framereg.c | 16 +++++++++++++---
> 2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
> index aefc9b6936ba..5fbfc42997d2 100644
> --- a/net/hsr/hsr_forward.c
> +++ b/net/hsr/hsr_forward.c
> @@ -403,7 +403,8 @@ static void hsr_deliver_master(struct sk_buff *skb, struct net_device *dev,
> int res, recv_len;
>
> was_multicast_frame = (skb->pkt_type == PACKET_MULTICAST);
> - hsr_addr_subst_source(node_src, skb);
> + if (node_src)
> + hsr_addr_subst_source(node_src, skb);
> skb_pull(skb, ETH_HLEN);
> recv_len = skb->len;
> res = netif_rx(skb);
> @@ -699,8 +700,12 @@ static int fill_frame_info(struct hsr_frame_info *frame,
>
> frame->node_src = hsr_get_node(port, n_db, skb,
> frame->is_supervision, port->type);
> - if (!frame->node_src)
> - return -1; /* Unknown node and !is_supervision, or no mem */
> + if (IS_ERR(frame->node_src)) {
> + ret = PTR_ERR(frame->node_src);
> + if (ret != -ENOENT)
> + return ret;
> + frame->node_src = NULL;
> + }
>
> ethhdr = (struct ethhdr *)skb_mac_header(skb);
> frame->is_vlan = false;
> @@ -739,7 +744,8 @@ void hsr_forward_skb(struct sk_buff *skb, struct hsr_port *port)
> if (fill_frame_info(&frame, skb, port) < 0)
> goto out_drop;
>
> - hsr_register_frame_in(frame.node_src, port, frame.sequence_nr);
> + if (frame.node_src)
> + hsr_register_frame_in(frame.node_src, port, frame.sequence_nr);
> hsr_forward_do(&frame);
I *think* the hsr_forward_do() could unconditionally dereference
node_src in:
hsr->proto_ops->register_frame_out -> {prp,hsr}_register_frame_out ->
hsr_check_duplicate:
node = frame->node_src;
if (WARN_ON_ONCE(port_type >= node->seq_port_cnt))
/P
^ permalink raw reply
* [PATCH net v2] Revert "mptcp: add needs_id for netlink appending addr"
From: Matthieu Baerts (NGI0) @ 2026-04-07 8:41 UTC (permalink / raw)
To: Mat Martineau, Geliang Tang, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netdev, mptcp, linux-kernel, stable, Matthieu Baerts (NGI0)
This commit was originally adding the ability to add MPTCP endpoints
with ID 0 by accident. The in-kernel PM, handling MPTCP endpoints at the
net namespace level, is not supposed to handle endpoints with such ID,
because this ID 0 is reserved to the initial subflow, as mentioned in
the MPTCPv1 protocol [1], a per-connection setting.
Note that 'ip mptcp endpoint add id 0' stops early with an error, but
other tools might still request the in-kernel PM to create MPTCP
endpoints with this restricted ID 0.
In other words, it was wrong to call the mptcp_pm_has_addr_attr_id
helper to check whether the address ID attribute is set: if it was set
to 0, a new MPTCP endpoint would be created with ID 0, which is not
expected, and might cause various issues later.
Fixes: 584f38942626 ("mptcp: add needs_id for netlink appending addr")
Cc: stable@vger.kernel.org
Link: https://datatracker.ietf.org/doc/html/rfc8684#section-3.2-9 [1]
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
v2:
- The v1 has been sent to net-next with a different commit message:
https://lore.kernel.org/20260403-net-next-mptcp-msg_eor-misc-v1-4-b0b33bea3fed@kernel.org
---
net/mptcp/pm_kernel.c | 24 +++++-------------------
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c
index 82e59f9c6dd9..0ebf43be9939 100644
--- a/net/mptcp/pm_kernel.c
+++ b/net/mptcp/pm_kernel.c
@@ -720,7 +720,7 @@ static void __mptcp_pm_release_addr_entry(struct mptcp_pm_addr_entry *entry)
static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
struct mptcp_pm_addr_entry *entry,
- bool needs_id, bool replace)
+ bool replace)
{
struct mptcp_pm_addr_entry *cur, *del_entry = NULL;
int ret = -EINVAL;
@@ -779,7 +779,7 @@ static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
}
}
- if (!entry->addr.id && needs_id) {
+ if (!entry->addr.id) {
find_next:
entry->addr.id = find_next_zero_bit(pernet->id_bitmap,
MPTCP_PM_MAX_ADDR_ID + 1,
@@ -790,7 +790,7 @@ static int mptcp_pm_nl_append_new_local_addr(struct pm_nl_pernet *pernet,
}
}
- if (!entry->addr.id && needs_id)
+ if (!entry->addr.id)
goto out;
__set_bit(entry->addr.id, pernet->id_bitmap);
@@ -923,7 +923,7 @@ int mptcp_pm_nl_get_local_id(struct mptcp_sock *msk,
return -ENOMEM;
entry->addr.port = 0;
- ret = mptcp_pm_nl_append_new_local_addr(pernet, entry, true, false);
+ ret = mptcp_pm_nl_append_new_local_addr(pernet, entry, false);
if (ret < 0)
kfree(entry);
@@ -977,18 +977,6 @@ static int mptcp_nl_add_subflow_or_signal_addr(struct net *net,
return 0;
}
-static bool mptcp_pm_has_addr_attr_id(const struct nlattr *attr,
- struct genl_info *info)
-{
- struct nlattr *tb[MPTCP_PM_ADDR_ATTR_MAX + 1];
-
- if (!nla_parse_nested_deprecated(tb, MPTCP_PM_ADDR_ATTR_MAX, attr,
- mptcp_pm_address_nl_policy, info->extack) &&
- tb[MPTCP_PM_ADDR_ATTR_ID])
- return true;
- return false;
-}
-
/* Add an MPTCP endpoint */
int mptcp_pm_nl_add_addr_doit(struct sk_buff *skb, struct genl_info *info)
{
@@ -1037,9 +1025,7 @@ int mptcp_pm_nl_add_addr_doit(struct sk_buff *skb, struct genl_info *info)
goto out_free;
}
}
- ret = mptcp_pm_nl_append_new_local_addr(pernet, entry,
- !mptcp_pm_has_addr_attr_id(attr, info),
- true);
+ ret = mptcp_pm_nl_append_new_local_addr(pernet, entry, true);
if (ret < 0) {
GENL_SET_ERR_MSG_FMT(info, "too many addresses or duplicate one: %d", ret);
goto out_free;
---
base-commit: a9d4f4f6e65e0bf9bbddedecc84d67249991979c
change-id: 20260406-net-mptcp-revert-pm-needs-id-f1cbb7021f9e
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
^ permalink raw reply related
* [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
* [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-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 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] 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
* 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
* 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: [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 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 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 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: [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
* [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
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