* Re: [PATCH net v3] net/smc: fix out-of-bounds read when sk_user_data holds a sk_psock
From: Paolo Abeni @ 2026-07-01 15:27 UTC (permalink / raw)
To: Sechang Lim, D . Wythe, Dust Li, Sidraya Jayagond, Wenjia Zhang,
David S . Miller, Eric Dumazet, Jakub Kicinski
Cc: Jiayuan Chen, Mahanta Jambigi, Tony Lu, Wen Gu, Simon Horman,
Karsten Graul, Guvenc Gulce, Ursula Braun, linux-rdma, linux-s390,
netdev, linux-kernel, bpf
In-Reply-To: <20260629095140.679754-1-rhkrqnwk98@gmail.com>
On 6/29/26 11:51 AM, Sechang Lim wrote:
> A passive-open child inherits the listener's smc_clcsock_data_ready().
> sk_clone_lock() clears its sk_user_data to NULL because the listener tagged
> it SK_USER_DATA_NOCOPY. Until accept restores the callback, a BPF sock_ops
> program can add the established child to a sockmap, and sk_psock_init()
> installs a sk_psock into the NULL sk_user_data. The inherited callback then
> reads it back through smc_clcsock_user_data(), which strips only NOCOPY,
> takes the sk_psock for an smc_sock, and dereferences a clcsk_* field past
> its end:
>
> BUG: KASAN: slab-out-of-bounds in smc_clcsock_data_ready+0x84/0x200 net/smc/af_smc.c:2637
> Read of size 8 at addr ffff8880013b8674 by task syz.6.12484/67930
> <IRQ>
> smc_clcsock_data_ready+0x84/0x200 net/smc/af_smc.c:2637
> tcp_urg+0x24d/0x360 net/ipv4/tcp_input.c:6264
> tcp_rcv_state_process+0x280d/0x4940 net/ipv4/tcp_input.c:7336
> tcp_child_process+0x371/0xa50 net/ipv4/tcp_minisocks.c:1002
> tcp_v4_rcv+0x1eaa/0x2a00 net/ipv4/tcp_ipv4.c:2186
> [...]
> </IRQ>
>
> Allocated by task 67930:
> sk_psock_init+0x142/0x740 net/core/skmsg.c:766
> sock_hash_update_common+0xd3/0x990 net/core/sock_map.c:1010
> bpf_sock_hash_update+0x114/0x170 net/core/sock_map.c:1229
> __cgroup_bpf_run_filter_sock_ops+0x74/0xa0 kernel/bpf/cgroup.c:1727
> tcp_init_transfer+0x1085/0x1100 net/ipv4/tcp_input.c:6693
> [...]
>
> Resolve the conflict on the write path. Reserve the child's sk_user_data
> with a NULL pointer tagged SK_USER_DATA_NOCOPY so sk_psock_init() returns
> -EBUSY, and release it at accept. smc_clcsock_user_data() still strips the
> tag to NULL, so the inherited callback stays a no-op.
>
> Fixes: a60a2b1e0af1 ("net/smc: reduce active tcp_listen workers")
> Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
> ---
> v3:
> - reserve sk_user_data on the write path instead of the read-side check (D. Wythe)
>
> v2:
> - https://lore.kernel.org/netdev/20260619150342.3626224-1-rhkrqnwk98@gmail.com/
>
> v1:
> - https://lore.kernel.org/netdev/20260614120931.4041687-1-rhkrqnwk98@gmail.com/
>
> net/smc/af_smc.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index b5db69073e20..78f162344fe3 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -154,7 +154,11 @@ static struct sock *smc_tcp_syn_recv_sock(const struct sock *sk,
> own_req, opt_child_init);
> /* child must not inherit smc or its ops */
> if (child) {
> - rcu_assign_sk_user_data(child, NULL);
> + /* reserve sk_user_data so sockmap cannot claim the slot */
> + write_lock_bh(&child->sk_callback_lock);
> + __rcu_assign_sk_user_data_with_flags(child, NULL,
> + SK_USER_DATA_NOCOPY);
> + write_unlock_bh(&child->sk_callback_lock);
>
> /* v4-mapped sockets don't inherit parent ops. Don't restore. */
> if (inet_csk(child)->icsk_af_ops == inet_csk(sk)->icsk_af_ops)
> @@ -1773,6 +1777,7 @@ static int smc_clcsock_accept(struct smc_sock *lsmc, struct smc_sock **new_smc)
> /* new clcsock has inherited the smc listen-specific sk_data_ready
> * function; switch it back to the original sk_data_ready function
> */
> + write_lock_bh(&new_clcsock->sk->sk_callback_lock);
> new_clcsock->sk->sk_data_ready = lsmc->clcsk_data_ready;
>
> /* if new clcsock has also inherited the fallback-specific callback
> @@ -1786,6 +1791,9 @@ static int smc_clcsock_accept(struct smc_sock *lsmc, struct smc_sock **new_smc)
> if (lsmc->clcsk_error_report)
> new_clcsock->sk->sk_error_report = lsmc->clcsk_error_report;
> }
> + /* release the slot reserved in smc_tcp_syn_recv_sock() */
> + rcu_assign_sk_user_data(new_clcsock->sk, NULL);
> + write_unlock_bh(&new_clcsock->sk->sk_callback_lock);
Sashiko reports that this still cause problem on fallback.
@Wythe, I understand from previous discussion that you would prefer to
address such issues separately (and thus you are fine with the patch in
the current form). Could you please confirm?
/P
>
> (*new_smc)->clcsock = new_clcsock;
> out:
^ permalink raw reply
* Re: [PATCH 5/9] ax88179_178a: Add support for ethtool pause parameter configuration
From: Andrew Lunn @ 2026-07-01 15:08 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Birger Koblitz, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <587499ee-d87e-4056-8d2a-8fda2ef3f0f1@bootlin.com>
> > +static void ax88179a_get_pauseparam(struct net_device *net, struct ethtool_pauseparam *pause)
> > +{
> > + struct usbnet *dev = netdev_priv(net);
> > + struct ax88179_data *data;
> > + u16 bmcr, lcladv, rmtadv;
> > + u8 cap;
> > +
> > + data = dev->driver_priv;
> > +
> > + if (data->chip_version < AX_VERSION_AX88179A)
> > + return;
> > +
> > + bmcr = ax88179_mdio_read(net, dev->mii.phy_id, MII_BMCR);
> > + lcladv = ax88179_mdio_read(net, dev->mii.phy_id, MII_ADVERTISE);
> > + rmtadv = ax88179_mdio_read(net, dev->mii.phy_id, MII_LPA);
> > +
> > + if (!(bmcr & BMCR_ANENABLE)) {
> > + pause->autoneg = 0;
> > + pause->rx_pause = 0;
> > + pause->tx_pause = 0;
> The best way to have this correct is to use phylink, but for that you'd need to
> have a proper PHY driver instead of using the mii_ API here.
I said the some to one of the other patches.
Do we know what PHYs are being used? Can register 2 and 3 be read to
get the PHY IDs?
Andrew
^ permalink raw reply
* Re: [PATCH bpf-next v5 1/3] bpf: Add BPF_FIB_LOOKUP_VLAN flag to bpf_fib_lookup() helper
From: David Ahern @ 2026-07-01 15:08 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Avinash Duduskar, ast, daniel,
andrii
Cc: eddyz87, memxor, martin.lau, song, yonghong.song, jolsa, emil,
john.fastabend, sdf, davem, edumazet, kuba, pabeni, horms, shuah,
hawk, yatsenko, leon.hwang, kpsingh, a.s.protopopov, ameryhung,
rongtao, eyal.birger, bpf, netdev, linux-kernel, linux-kselftest
In-Reply-To: <87y0fv0y79.fsf@toke.dk>
On 7/1/26 5:02 AM, Toke Høiland-Jørgensen wrote:
> David Ahern <dsahern@kernel.org> writes:
>> Seems to me the fib_lookup for xdp needs to return the bottom device,
>> not the vlan device, for forwarding to work. That's why I added the
>> fields to the struct. That allows the program to push the vlan header if
>> required. My preference (dream?) was that Tx path had support to tell
>> the redirect the vlan and h/w added it on send.
>
> Sure, returning the bottom device index with the VLAN tag makes sense,
> and that's basically what this series does (but bails out on stacked
> VLANs). However, that's not what the helper does today, which is why the
> flag is there, to opt-in to the new behaviour. I don't think we can just
> change the ifindex without breaking existing applications (as noted
> up-thread).
I do not see it as breaking existing programs which is why I chimed in
on the thread.
>
>> But really, once stacked devices come into play, I just wanted to make
>> sure thought is given to different use cases. As you know the lookup
>> struct if hard bound to 64B and it is trying to cover a lot of use cases.
>
> Agreed, I don't think we can handle stacked devices in this helper. But
> we could split it out into a new one. Something like:
>
> struct lower_device_info {
> enum device_type type;
> struct {
> __be16 h_vlan_proto;
> __be16 h_vlan_TCI;
> } vlan;
> /* add other types here */
> };
>
> int xdp_get_lower_device(int ifindex, struct lower_device_info *info);
>
> called like:
>
> int xdp_program(struct xdp_md *ctx)
> {
> struct lower_device_info dev_info = {};
> int ifindex, ret;
>
> ifindex = find_destination(ctx); /* does fib lookup, or something else */
>
> while ((ret = xdp_get_lower_device_info(ifindex, &dev_info)) > 0) {
> if (dev_info.type == VLAN) {
> push_vlan_tag(ctx, &dev_info.vlan);
> ifindex = ret;
> } else {
> return XDP_PASS; /* we only handle VLAN devices */
> }
> }
>
> return bpf_redirect(ifindex, 0);
> }
>
>
> With a helper like this, we obviously don't strictly speaking need to
> change the fib lookup helper at all. However, for the single-tagged VLAN
> case, I think supporting it directly in the fib lookup could still have
> value, as an optimisation: it saves an extra call for resolving the
> ifindex, and the fields are already there. So I think my preference
> would be to merge this series as-is, and then follow up with a new kfunc
> to handle the stacked case. But we could also just drop this series and
> go straight to the new kfunc.
>
> WDYT?
no preference. I only chimed in because of the added flag to the uapi
which I do not see as needed. If the consensus is that it is in fact
needed, all good then.
^ permalink raw reply
* Re: [PATCH] net: fman: guard IRQ handlers against pre-init interrupt
From: Paolo Abeni @ 2026-07-01 15:06 UTC (permalink / raw)
To: ZhaoJinming, horms, andrew, madalin.bucur
Cc: andrew+netdev, davem, edumazet, kuba, linux-kernel, netdev,
sean.anderson
In-Reply-To: <20260629084529.3709393-1-zhaojinming@uniontech.com>
On 6/29/26 10:45 AM, ZhaoJinming wrote:
> read_dts_node() registers shared interrupt handlers via
> devm_request_irq() with fman as the dev_id, passing it to fman_irq()
> and fman_err_irq(). At registration time, fman is only partially
> initialized -- kzalloc_obj() zero-initializes all fields, so
> fman->cfg and fman->fpm_regs are NULL.
>
> The handlers guard against incomplete initialization via:
>
> if (!is_init_done(fman->cfg))
> return IRQ_NONE;
>
> However, is_init_done(NULL) returns true (intended to indicate that
> fman_init() has completed and cfg has been freed). This means when
> cfg is NULL before fman_config() allocates it, the guard does not
> take effect:
>
> is_init_done(NULL) -> returns true
> !true -> false
> guard skipped -> proceeds to dereference NULL fpm_regs
>
> If another device on the same shared IRQ line fires during the window
> between devm_request_irq() and fman_init(), the handler accesses
> NULL fman->fpm_regs via ioread32be(), causing a crash. The window
> includes of_platform_populate() which can be slow.
>
> Add an irq_ready flag to struct fman that is set to true only after
> fman_init() completes in fman_probe(). Check this flag at the start
> of fman_irq() and fman_err_irq() before any register access.
>
> Use READ_ONCE()/WRITE_ONCE() for the flag accesses since it is a
> cross-context shared variable written in process context and read
> in interrupt context.
>
> This issue was identified in code review during the discussion of a
> separate IRQF_SHARED UAF fix patch:
> https://lore.kernel.org/netdev/20260626162323.GE1310988@horms.kernel.org/
>
> Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
> ---
> drivers/net/ethernet/freescale/fman/fman.c | 5 +++++
> drivers/net/ethernet/freescale/fman/fman.h | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
> index 013273a2de32..f14cb02d85a4 100644
> --- a/drivers/net/ethernet/freescale/fman/fman.c
> +++ b/drivers/net/ethernet/freescale/fman/fman.c
> @@ -2510,6 +2510,8 @@ static irqreturn_t fman_err_irq(int irq, void *handle)
> struct fman_fpm_regs __iomem *fpm_rg;
> irqreturn_t single_ret, ret = IRQ_NONE;
>
> + if (!READ_ONCE(fman->irq_ready))
> + return IRQ_NONE;
Sashiko noted that on weakly ordered arch this could not be enough:
https://sashiko.dev/#/patchset/20260629084529.3709393-1-zhaojinming%40uniontech.com
Also I have the feeling this is papering over the real issue. Why
initializing the irq when the driver is not yet ready? Why don't move
IRQ initialization later?
/P
^ permalink raw reply
* Re: [PATCH v2 02/19] driver core: platform: provide platform_device_set_of_node()
From: Manuel Ebner @ 2026-07-01 15:05 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-kernel, netdev, linux-arm-msm, linux-sound, driver-core,
devicetree, linuxppc-dev, linux-i2c, iommu, linux-pm, imx,
linux-arm-kernel, intel-xe, dri-devel, linux-usb, linux-mips,
platform-driver-x86, Bartosz Golaszewski, Lee Jones,
Thierry Reding, Sebastian Hesselbarth, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Andy Shevchenko,
Joerg Roedel, Will Deacon, Robin Murphy, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Matthew Brost, Thomas Hellström, Rodrigo Vivi,
David Airlie, Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu,
Philipp Zabel, Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt
In-Reply-To: <CAMRc=MdQURjypSn+QjSDJfEiOMC8bbEZmZLgjpt=EquAM1Q1pw@mail.gmail.com>
On Tue, 2026-06-30 at 09:22 -0400, Bartosz Golaszewski wrote:
> On Tue, 30 Jun 2026 13:37:54 +0200, Manuel Ebner <manuelebner@mailbox.org> said:
> > On Mon, 2026-06-29 at 11:12 +0200, Bartosz Golaszewski wrote:
> > > [...]
> > >
> > > +/**
> > > + * platform_device_set_of_node - assign an OF node to device
> > > + * @pdev: platform device to add the node for
> > > + * @np: new device node
> > > + *
> > > + * Assign an OF node to this platform device. Internally keep track of the
> > > + * reference count. Devices created with platform_device_alloc() must use this
> > > + * function instead of assigning the node manually.
> >
> > Doesn't it make sense to add a remark to the kernel doc of platform_device_alloc()?
> >
> > Thanks
> > Manuel
> >
> > > [...]
> >
>
> Sure, will do in the next iteration.
then you can add
Reviewed-by: Manuel Ebner <manuelebner@mailbox.org>
Manuel
>
> Bart
^ permalink raw reply
* Re: [PATCH 2/9] ax88179_178a: Add HW support for AX179A-based chips
From: Andrew Lunn @ 2026-07-01 15:05 UTC (permalink / raw)
To: Birger Koblitz
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <20260701-ax88179a-v1-2-13685df67515@birger-koblitz.de>
> #include <linux/usb/usbnet.h>
> #include <uapi/linux/mdio.h>
> #include <linux/mdio.h>
> +#include <linux/if_vlan.h>
Does this patch require this header?
> @@ -414,7 +570,6 @@ static int ax88179_suspend(struct usb_interface *intf, pm_message_t message)
>
> usbnet_suspend(intf, message);
>
> - /* Enable WoL */
> if (priv->wolopts) {
Please try to avoid changes like this.
> /* Force bulk-in zero length */
> ax88179_read_cmd(dev, AX_ACCESS_MAC, AX_PHYPWR_RSTCTL,
> - 2, 2, &tmp16);
> + 2, 2, &tmp16);
>
> tmp16 |= AX_PHYPWR_RSTCTL_BZ | AX_PHYPWR_RSTCTL_IPRL;
> ax88179_write_cmd(dev, AX_ACCESS_MAC, AX_PHYPWR_RSTCTL,
> - 2, 2, &tmp16);
> + 2, 2, &tmp16);
Please put white space changes in another patch.
> + /* Initialize MII structure */
> + dev->mii.dev = dev->net;
> + dev->mii.mdio_read = ax88179_mdio_read;
> + dev->mii.mdio_write = ax88179_mdio_write;
> + dev->mii.phy_id_mask = 0xff;
> + dev->mii.reg_num_mask = 0xff;
> + dev->mii.phy_id = 0x03;
If this device is going to have a long term future, it really should
move to phylink.
Andrew
^ permalink raw reply
* Re: [PATCH 1/9] ax88179_178a: Fix endianness of pause watermark register
From: Andrew Lunn @ 2026-07-01 14:57 UTC (permalink / raw)
To: Birger Koblitz
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <20260701-ax88179a-v1-1-13685df67515@birger-koblitz.de>
On Wed, Jul 01, 2026 at 07:42:47AM +0200, Birger Koblitz wrote:
> The 16-bit pause watermark register is little endian as
> described in the ASIX 4.1.0 out-of-tree driver. Correct the
> register byte sequence but also swap the configuration values
> used in the code in order to keep the current behaviour.
>
> The endianness is relevant for 16-bit writes to the register.
Is this a Fix which should be back ported in stable?
Andrew
^ permalink raw reply
* Re: [PATCH] net: stmmac: recalibrate CBS idle slope when EST is enabled
From: Andrew Lunn @ 2026-07-01 14:54 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: netdev, kuba, davem, edumazet, pabeni, rmk+kernel,
maxime.chevallier
In-Reply-To: <20260701053244.17172-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Tue, Jun 30, 2026 at 10:32:44PM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Hi Nazim
Please take a read of
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
It would be good to get the Subject line correct, and there are maybe
a few other things in there you currently don't know.
> + /* If EST is not enabled, no need to recalibrate idle slope */
> + if (!priv->est)
> + goto config_cbs;
> + if (!priv->est->enable)
> + goto config_cbs;
> +
> + cycle_time_ns = (priv->est->ctr[1] * NSEC_PER_SEC) +
> + priv->est->ctr[0];
> + if (!cycle_time_ns)
> + goto config_cbs;
The use of goto like this suggests it is time to refactor this code
into some helpers, so making the structure clearer. Otherwise this is
going to turning into spaghetti.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v3] xsk: fix memory corruptions in net/core/xdp.c
From: Paolo Abeni @ 2026-07-01 14:52 UTC (permalink / raw)
To: Clement Lecigne, Fijalkowski, Maciej
Cc: Lobakin, Aleksander, edumazet@google.com, netdev@vger.kernel.org,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
kuba@kernel.org, sdf@fomichev.me, horms@kernel.org,
john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net
In-Reply-To: <CAHuCGd=KJqrem_WTdZ6LSeTpdaSauw1JXe9EB3x6QRtVvFbTLg@mail.gmail.com>
On 6/29/26 1:15 PM, Clement Lecigne wrote:
> On Mon, Jun 29, 2026 at 12:34 PM Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com> wrote:
>>
>>>
>>> From: Clément Lecigne <clecigne@google.com>
>>>
>>> Commit 560d958c6c68 ("xsk: add generic XSk &xdp_buff -> skb conversion")
>>> introduced a vulnerability in the handling of XDP_PASS for AF_XDP zero-copy
>>> frames.
>>>
>>> Note: Currently, this specific AF_XDP zero-copy conversion path is only
>>> reachable from the drivers/net/ethernet/intel/ice and
>>> drivers/net/ethernet/intel/idpf drivers.
>>>
>>> When building an skb, xdp_build_skb_from_zc() uses the chunk size
>>> (xdp->frame_sz) for the allocation. However, napi_build_skb() automatically
>>> reserves space at the end of the allocation for the skb_shared_info
>>> structure.
>>>
>>> Most high performance UMEM applications use 4K chunks, where the
>>> corruption cannot happen. However, if the UMEM is configured with 2KB
>>> chunks (a very common configuration to maximize packet density in memory),
>>> a standard 1500 MTU packet will trigger the corruption because the required
>>> space exceeds the 2048 byte chunk size:
>>>
>>> Headroom (256) + Packet (1514) + skb_shared_info (320) = 2090 bytes
>>>
>>> Because 2090 bytes > 2048 bytes and __skb_put() does not perform bounds
>>> checking, the memcpy() writes past the available linear data area and
>>> corrupts the skb_shared_info structure. This can lead to arbitrary code
>>> execution if pointers like destructor_arg are overwritten.
>>>
>>> Additionally, in xdp_copy_frags_from_zc(), the allocation size is set
>>> strictly to the fragment size (len), but the subsequent memcpy() uses
>>> LARGEST_ALIGN(len). This mismatch results in an out-of-bounds write of
>>> up to 7 bytes, which triggers KASAN warnings and is unsafe despite typical
>>> page pool allocator padding.
>>>
>>> Fix the skb allocation in xdp_build_skb_from_zc() by dynamically
>>> calculating the exact truesize required using SKB_HEAD_ALIGN() to
>>> properly account for the headroom, the LARGEST_ALIGN(len), and the
>>> skb_shared_info overhead.
>>>
>>> Fix the out-of-bounds write in xdp_copy_frags_from_zc() by rounding up
>>> the allocation request using LARGEST_ALIGN(len) to match the copy
>>> operation.
>>>
>>> Fixes: 560d958c6c68 ("xsk: add generic XSk &xdp_buff -> skb conversion")
>>> CC: Alexander Lobakin <aleksander.lobakin@intel.com>
>>> CC: Eric Dumazet <edumazet@google.com>
>>> Signed-off-by: Clément Lecigne <clecigne@google.com>
>>
>> Hi Clement,
>>
>> Do you have a reproducer for mentioned issue or is it only a fix from
>> theoretical POV?
>>
>> To be clear, we were addressing headroom issues in this series:
>> https://lore.kernel.org/bpf/20260402154958.562179-1-maciej.fijalkowski@intel.com/
>>
>> so I wanted to ask if you are able to have this malformed setup for
>> 2k chunk size. That series should not allow for that.
>
> I didn't manage to build a malformed setup and only used a LKM to reproduce
> the issue artificially.
Note that we don't accept patches addressing issue for OoT modules. I
read you reply as the critical setup can't be obtained with the vanilla
tree.
Please clarify otherwise.
/P
^ permalink raw reply
* [PATCH] qede: Prevent possible snprintf() truncation by bounding %s string format
From: Baran Tuna @ 2026-07-01 14:47 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Baran Tuna, Breno Leitao,
open list:QLOGIC QL4xxx ETHERNET DRIVER, open list
GCC warning shows that formatted strings may
exceed the fixed-size destination buffers.
Bounding the %s string format
so the maximum formatted output always fits.
This eliminates the -Wformat-truncation warning.
Signed-off-by: Baran Tuna <barant@fastmail.com>
---
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index 647f30a16a94..5428f53150a0 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -618,10 +618,10 @@ static void qede_get_drvinfo(struct net_device *ndev,
if ((strlen(storm) + strlen("[storm]")) <
sizeof(info->version))
snprintf(info->version, sizeof(info->version),
- "[storm %s]", storm);
+ "[storm %.16s]", storm);
else
snprintf(info->version, sizeof(info->version),
- "%s", storm);
+ "%.16s", storm);
if (edev->dev_info.common.mbi_version) {
snprintf(mbi, ETHTOOL_FWVERS_LEN, "%d.%d.%d",
@@ -632,10 +632,10 @@ static void qede_get_drvinfo(struct net_device *ndev,
(edev->dev_info.common.mbi_version &
QED_MBI_VERSION_0_MASK) >> QED_MBI_VERSION_0_OFFSET);
snprintf(info->fw_version, sizeof(info->fw_version),
- "mbi %s [mfw %s]", mbi, mfw);
+ "mbi %.10s [mfw %.10s]", mbi, mfw);
} else {
snprintf(info->fw_version, sizeof(info->fw_version),
- "mfw %s", mfw);
+ "mfw %.16s", mfw);
}
strscpy(info->bus_info, pci_name(edev->pdev), sizeof(info->bus_info));
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next v2 1/1] net: rnpgbe: fix mailbox endianness and remove pointer casts
From: Andrew Lunn @ 2026-07-01 14:47 UTC (permalink / raw)
To: Dong Yibo
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, vadim.fedorenko,
netdev, linux-kernel, yaojun
In-Reply-To: <20260701032208.1843156-2-dong100@mucse.com>
On Wed, Jul 01, 2026 at 11:22:08AM +0800, Dong Yibo wrote:
> The rnpgbe mailbox exchanges data through 32-bit MMIO registers in
> little-endian wire format. The original code had two problems:
>
> 1. FW structs (with __le16/__le32 fields) were cast to (u32 *)
> before reaching the mailbox transport, hiding the endian
> annotations from sparse.
>
> 2. No cpu_to_le32()/le32_to_cpu() conversion was done between
> CPU-endian MMIO values and the little-endian payload, causing
> data corruption on big-endian systems.
>
> Fix by adding the missing byte-order conversions in the transport
> layer and introducing union wrappers (mbx_fw_cmd_req_u,
> mbx_fw_cmd_reply_u) that overlay each FW struct with a __le32
> dwords[] array. Callers fill named fields using cpu_to_le16/32(),
> then pass dwords[] to the transport, which now takes explicit
> __le32 * instead of u32 *. This eliminates all pointer casts on
> the mailbox data path and lets sparse verify the conversions.
>
> Fixes: 4543534c3ef5 ("net: rnpgbe: Add basic mbx ops support")
> Signed-off-by: Dong Yibo <dong100@mucse.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net v3] net: usb: lan78xx: disable VLAN filter in promiscuous mode
From: Enrico Pozzobon via B4 Relay @ 2026-07-01 14:47 UTC (permalink / raw)
To: Thangaraj Samynathan, Rengarajan Sundararajan, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Woojung.Huh
Cc: netdev, linux-usb, linux-kernel, Enrico Pozzobon
From: Enrico Pozzobon <enrico.pozzobon@dissecto.com>
The hardware VLAN filter (RFE_CTL_VLAN_FILTER_) drops VLAN-tagged frames
whose VID has not been registered via lan78xx_vlan_rx_add_vid(). It is
left enabled in promiscuous mode, so packet capture (e.g. tcpdump or
Wireshark) does not see tagged frames for unregistered VIDs.
Clear the filter while the interface is promiscuous and restore it from
NETIF_F_HW_VLAN_CTAG_FILTER otherwise. Enforce the same condition in
lan78xx_set_features() so netdev_update_features() cannot re-enable the
filter while promiscuous.
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Enrico Pozzobon <enrico.pozzobon@dissecto.com>
---
Currently, on microchip lan7801, enabling promiscuous mode does not
result in VLAN tagged packets being captured. This patch fixes this,
forcing the RFE_CTL_VLAN_FILTER_ flag to be off when promiscuous mode is
enabled.
---
Changes in v3:
- EDITME: describe what is new in this series revision.
- EDITME: use bulletpoints and terse descriptions.
- Link to v2: https://patch.msgid.link/20260701-lan78xx-vlan-promisc-v2-1-fe3b18066728@dissecto.com
Changes in v2:
- moved VLAN filter logic into lan78xx_update_vlan_filter()
- Link to v1: https://patch.msgid.link/20260630-lan78xx-vlan-promisc-v1-1-fbf0f903bd8f@dissecto.com
To: Thangaraj Samynathan <Thangaraj.S@microchip.com>
To: Rengarajan Sundararajan <Rengarajan.S@microchip.com>
To: UNGLinuxDriver@microchip.com
To: Andrew Lunn <andrew+netdev@lunn.ch>
To: "David S. Miller" <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Woojung.Huh@microchip.com
Cc: netdev@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/usb/lan78xx.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index c4cebacabcb5..cb782d81d84f 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1499,6 +1499,17 @@ static void lan78xx_deferred_multicast_write(struct work_struct *param)
return;
}
+static void lan78xx_update_vlan_filter(struct lan78xx_priv *pdata,
+ struct net_device *netdev,
+ netdev_features_t features)
+{
+ if ((features & NETIF_F_HW_VLAN_CTAG_FILTER) &&
+ !(netdev->flags & IFF_PROMISC))
+ pdata->rfe_ctl |= RFE_CTL_VLAN_FILTER_;
+ else
+ pdata->rfe_ctl &= ~RFE_CTL_VLAN_FILTER_;
+}
+
static void lan78xx_set_multicast(struct net_device *netdev)
{
struct lan78xx_net *dev = netdev_priv(netdev);
@@ -1533,6 +1544,8 @@ static void lan78xx_set_multicast(struct net_device *netdev)
}
}
+ lan78xx_update_vlan_filter(pdata, dev->net, dev->net->features);
+
if (netdev_mc_count(dev->net)) {
struct netdev_hw_addr *ha;
int i;
@@ -3074,10 +3087,7 @@ static int lan78xx_set_features(struct net_device *netdev,
else
pdata->rfe_ctl &= ~RFE_CTL_VLAN_STRIP_;
- if (features & NETIF_F_HW_VLAN_CTAG_FILTER)
- pdata->rfe_ctl |= RFE_CTL_VLAN_FILTER_;
- else
- pdata->rfe_ctl &= ~RFE_CTL_VLAN_FILTER_;
+ lan78xx_update_vlan_filter(pdata, netdev, features);
spin_unlock_irqrestore(&pdata->rfe_ctl_lock, flags);
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260623-lan78xx-vlan-promisc-83af8a48a7ec
Best regards,
--
Enrico Pozzobon <enrico.pozzobon@dissecto.com>
^ permalink raw reply related
* Re: [PATCH net-next v11 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: Maciej Fijalkowski @ 2026-07-01 14:45 UTC (permalink / raw)
To: Dipayaan Roy
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
kuba, pabeni, leon, longli, kotaranov, horms, shradhagupta,
ssengar, ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, dipayanroy, leitao, kees,
john.fastabend, hawk, bpf, daniel, ast, sdf, yury.norov,
pavan.chebbi
In-Reply-To: <20260701141808.461554-1-dipayanroy@linux.microsoft.com>
On Wed, Jul 01, 2026 at 07:15:44AM -0700, Dipayaan Roy wrote:
> On some ARM64 platforms with 4K PAGE_SIZE, utilizing page_pool
> fragments for allocation in the RX refill path (~2kB buffer per fragment)
> causes 15-20% throughput regression under high connection counts
> (>16 TCP streams at 180+ Gbps). Using full-page buffers on these
> platforms shows no regression and restores line-rate performance.
>
> This behavior is observed on a single platform; other platforms
> perform better with page_pool fragments, indicating this is not a
> page_pool issue but platform-specific.
>
> This series adds an ethtool private flag "full-page-rx" to let the
> user opt in to one RX buffer per page:
>
> ethtool --set-priv-flags eth0 full-page-rx on
>
> There is no behavioral change by default. The flag can be persisted
> via udev rule for affected platforms.
Were you able to track down what is the actual bottleneck on the 'broken'
platform? What is the performance of full-page approach on healthy
platforms? On changelog below you mention the frag approach 'outperforms'
the full-page one.
>
> This series depends on the following fixes now merged in net-next:
> commit 17bfe0a8c014 ("net: mana: Add NULL guards in teardown path to prevent panic on attach failure")
> commit 5b05aa36ee24 ("net: mana: Skip redundant detach on already-detached port")
>
> Changes in v11:
> - Rebased on net-next
> Changes in v10:
> - Rebased on net-next which now includes the prerequisite fixes.
> - Recovery logic in mana_set_priv_flags() leverages the idempotent
> mana_detach() from the merged fixes.
> Changes in v9:
> - Added correct tree.
> Changes in v8:
> - Fixed queue_reset_work recovery by restoring port_is_up before
> scheduling reset so the handler can properly re-attach.
> - Simplified "err && schedule_port_reset" to "schedule_port_reset".
> Changes in v7:
> - Rebased onto net-next.
> - Retained private flag approach after David Wei's testing on
> Grace (ARM64) confirmed that fragment mode outperforms
> full-page mode on other platforms, validating this is a
> single-platform workaround rather than a generic issue.
> Changes in v6:
> - Added missed maintainers.
> Changes in v5:
> - Split prep refactor into separate patch (patch 1/2)
> Changes in v4:
> - Dropping the smbios string parsing and add ethtool priv flag
> to reconfigure the queues with full page rx buffers.
> Changes in v3:
> - changed u8* to char*
> Changes in v2:
> - separate reading string index and the string, remove inline.
>
> Dipayaan Roy (2):
> net: mana: refactor mana_get_strings() and mana_get_sset_count() to
> use switch
> net: mana: force full-page RX buffers via ethtool private flag
>
> drivers/net/ethernet/microsoft/mana/mana_en.c | 22 ++-
> .../ethernet/microsoft/mana/mana_ethtool.c | 178 +++++++++++++++---
> include/net/mana/mana.h | 8 +
> 3 files changed, 177 insertions(+), 31 deletions(-)
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Andrew Lunn @ 2026-07-01 14:43 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: dinguyen, maxime.chevallier, rmk+kernel, krzk+dt, conor+dt, robh,
davem, edumazet, kuba, pabeni, andrew+netdev, devicetree,
linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20260630133108.27244-4-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Tue, Jun 30, 2026 at 06:31:08AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
> use phy_interface") replaced mac_interface with phy_interface in
> socfpga_get_plat_phymode(), noting that no upstream DTS files set the
> "mac-mode" property, making the two values identical.
>
> The Agilex5 SoCDK TSN Config2 board is an exception: its gmac1 TSN
> port uses GMII internally in the MAC while the PHY-side interface is
> RGMII, so mac-mode and phy-mode differ. Without restoring mac_interface
> support, the MAC is configured with RGMII instead of GMII, causing
> connectivity failures on this board.
>
> Add socfpga_of_get_mac_mode() to read the optional "mac-mode" DT
> property and store it in a new mac_interface field. When the property
> is absent, mac_interface falls back to phy_interface, preserving
> the existing behaviour for all other boards.
I don't actually see a need for mac-mode. From what you are saying,
there is no choice. The MAC is hard wired to the converter block. So
you can just look at the compatible. You are going to need to use the
compatible anyway, to mask the phy-mode to handle the "MAC" doing the
RGMII delays.
Andrew
^ permalink raw reply
* Re: [PATCH net] net/mlx5: HWS, fix matcher leak on resize target setup failure
From: Paolo Abeni @ 2026-07-01 14:38 UTC (permalink / raw)
To: saeedm, tariqt, mbloch, leon
Cc: andrew+netdev, davem, edumazet, kuba, kliteyn, vdogaru, horms,
kees, stable, netdev, linux-rdma, linux-kernel, jianhao.xu, zilin,
Dawei Feng
In-Reply-To: <20260629064049.3852759-1-dawei.feng@seu.edu.cn>
On 6/29/26 8:40 AM, Dawei Feng wrote:
> hws_bwc_matcher_move() allocates a replacement matcher before setting it
> as the resize target. If mlx5hws_matcher_resize_set_target() fails, the
> replacement matcher is not attached anywhere and is leaked.
>
> Fix the leak by destroying the replacement matcher before returning from
> the resize-target failure path.
>
> The bug was first flagged by an experimental analysis tool we are
> developing for kernel memory-management bugs while analyzing
> v6.13-rc1. The tool is still under development and is not yet publicly
> available. Manual inspection confirms that the bug is still
> present in v7.1.1.
>
> An x86_64 allyesconfig build showed no new warnings. As we do not have a
> mlx5 HWS-capable device to test with, no runtime testing was able to be
> performed.
>
> Fixes: 2111bb970c78 ("net/mlx5: HWS, added backward-compatible API handling")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
@nvidia team, double checking I did not miss any relevant communication.
The last process update I recall is that one of the people listed in
maintainer file will ack patches for us to merge directly into the
net/net-next trees.
Should we consider any ack from @nvidia sufficient to take over?
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net-next v2] ice: use dev_err_probe() in ice_probe()
From: Maciej Fijalkowski @ 2026-07-01 14:37 UTC (permalink / raw)
To: Rongguang Wei
Cc: netdev, intel-wired-lan, aleksandr.loktionov, przemyslaw.kitszel,
anthony.l.nguyen, andrew+netdev, Rongguang Wei
In-Reply-To: <20260701013618.29934-1-clementwei90@163.com>
On Wed, Jul 01, 2026 at 09:36:18AM +0800, Rongguang Wei wrote:
> From: Rongguang Wei <weirongguang@kylinos.cn>
>
> dev_err_probe() logs the error and returns the supplied error code, which
> allows probe error paths to be written more compactly.
>
> Use dev_err_probe() in ice_probe() for error paths that currently print an
> error message and immediately return the same error code. This keeps the
> existing error handling semantics while reducing open-coded logging and
> return sequences.
>
> Signed-off-by: Rongguang Wei <weirongguang@kylinos.cn>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> v2:
> - Fix commit message per Aleksandr Loktionov's recommendation.
> v1: https://lore.kernel.org/netdev/20260630032537.42605-1-clementwei90@163.com/T/#t
> ---
> drivers/net/ethernet/intel/ice/ice_main.c | 24 ++++++++---------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
Could we also address rest of sites within driver at this very same
commit?
drivers/net/ethernet/intel/ice/ice_dcb_lib.c-873- dev_err(dev, "DCB init failed\n");
drivers/net/ethernet/intel/ice/ice_dcb_lib.c:874: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-4482- dev_warn(dev, "Failed to initialize hardware after applying Tx scheduling configuration.\n");
drivers/net/ethernet/intel/ice/ice_main.c:4483: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-4543- dev_err(dev, "Fail during requesting FW: %d\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:4544: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-4961- dev_err(dev, "ice_init_pf failed: %d\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:4962: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-5192- dev_err(dev, "BAR0 I/O map error %d\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:5193: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-5206- dev_err(dev, "DMA configuration failed: 0x%x\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:5207: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-5244- dev_err(dev, "ice_init_hw failed: %d\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:5245: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-9627- netdev_err(netdev, "Failed to get link info, error %d\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:9628: return err;
--
drivers/net/ethernet/intel/ice/devlink/devlink.c-1244- dev_err(dev, "ice_init_hw failed: %d\n", err);
drivers/net/ethernet/intel/ice/devlink/devlink.c:1245: return err;
--
drivers/net/ethernet/intel/ice/ice_ptp.c-1935- dev_err(ice_pf_to_dev(pf), "PTP failed to set time %d\n", err);
drivers/net/ethernet/intel/ice/ice_ptp.c:1936: return err;
--
drivers/net/ethernet/intel/ice/ice_ptp.c-2000- dev_err(dev, "PTP failed to adjust time, err %d\n", err);
drivers/net/ethernet/intel/ice/ice_ptp.c:2001: return err;
--
drivers/net/ethernet/intel/ice/ice_sriov.c-829- dev_err(dev, "Failed to enable SR-IOV: %d\n", err);
drivers/net/ethernet/intel/ice/ice_sriov.c:830: return err;
--
drivers/net/ethernet/intel/ice/ice_eswitch_br.c-314- dev_info(dev, "Bridge port lookup failed (vsi=%u)\n", vsi_idx);
drivers/net/ethernet/intel/ice/ice_eswitch_br.c:315: return ERR_PTR(-EINVAL);
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index e2fd2dab03e3..31aa42f8e6d3 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -5161,10 +5161,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
> struct ice_hw *hw;
> int err;
>
> - if (pdev->is_virtfn) {
> - dev_err(dev, "can't probe a virtual function\n");
> - return -EINVAL;
> - }
> + if (pdev->is_virtfn)
> + return dev_err_probe(dev, -EINVAL, "can't probe a virtual function\n");
>
> /* when under a kdump kernel initiate a reset before enabling the
> * device in order to clear out any pending DMA transactions. These
> @@ -5188,10 +5186,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
> return err;
>
> err = pcim_iomap_regions(pdev, BIT(ICE_BAR0), dev_driver_string(dev));
> - if (err) {
> - dev_err(dev, "BAR0 I/O map error %d\n", err);
> - return err;
> - }
> + if (err)
> + return dev_err_probe(dev, err, "BAR0 I/O map error %d\n", err);
>
> pf = ice_allocate_pf(dev);
> if (!pf)
> @@ -5202,10 +5198,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
>
> /* set up for high or low DMA */
> err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
> - if (err) {
> - dev_err(dev, "DMA configuration failed: 0x%x\n", err);
> - return err;
> - }
> + if (err)
> + return dev_err_probe(dev, err, "DMA configuration failed: 0x%x\n", err);
>
> pci_set_master(pdev);
> pf->pdev = pdev;
> @@ -5240,10 +5234,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
> return ice_probe_recovery_mode(pf);
>
> err = ice_init_hw(hw);
> - if (err) {
> - dev_err(dev, "ice_init_hw failed: %d\n", err);
> - return err;
> - }
> + if (err)
> + return dev_err_probe(dev, err, "ice_init_hw failed: %d\n", err);
>
> ice_init_dev_hw(pf);
>
> --
> 2.25.1
>
>
^ permalink raw reply
* Re: [PATCH iproute2-next v2 2/2] devlink: support u64-array values in devlink param show/set
From: David Ahern @ 2026-07-01 14:34 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: stephen, kuba, linux-kernel, netdev, andrew+netdev, edumazet,
pabeni, jiri
In-Reply-To: <akR7g8aWfws3h2jx@rkannoth-OptiPlex-7090>
On 6/30/26 8:29 PM, Ratheesh Kannoth wrote:
> On 2026-06-30 at 20:06:17, David Ahern (dsahern@kernel.org) wrote:
>> On 6/29/26 7:50 PM, Ratheesh Kannoth wrote:
>>> diff --git a/devlink/devlink.c b/devlink/devlink.c
>>> index 9372e92f..3c29601d 100644
>>> --- a/devlink/devlink.c
>>> +++ b/devlink/devlink.c
>>> @@ -3496,13 +3496,115 @@ static const struct param_val_conv param_val_conv[] = {
>>> };
>>>
>>> #define PARAM_VAL_CONV_LEN ARRAY_SIZE(param_val_conv)
>>> +#define DEVLINK_PARAM_MAX_ARRAY_SIZE 32
>>
>> Why 32? Is that based on current code?
> Yes, this aligns with the current kernel-side limits. See:
> https://lore.kernel.org/all/20260609040453.711932-5-rkannoth@marvell.com/
>
>> How does the kernel side handle
>> the number of parameters? What happens if the kernel sends more than 32
>> parameters - from a user's perspective, not this code and processing the
>> output?
> The kernel strictly validates and restricts the number of parameters. To be safe, this patch
> adds an explicit bounds check to prevent userspace issues if that threshold is ever crossed.
>
> Ideally, since "union devlink_param_value" is omitted from the UAPI, we have to define
> DEVLINK_PARAM_MAX_ARRAY_SIZE here. Moving the underlying structures to the UAPI in the
> future would allow us to share a single definition and avoid this hardcoded value in userspace.
iproute2 needs to be backward and forward compatible. As it stands, a
new kernel can allow more than 32 entries and an older iproute2 will not
display all of them. That is wrong.
Let's make the limit part of the uapi. If you do not want to do that
now, then iproute2 code needs to handle a larger size.
^ permalink raw reply
* Re: [PATCH net] net: phy: motorcomm: read EEE abilities in yt8521_get_features()
From: Andrew Lunn @ 2026-07-01 14:32 UTC (permalink / raw)
To: Clark Wang
Cc: Breno Leitao, Clark Wang (OSS), Frank.Sae@motor-comm.com,
hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev
In-Reply-To: <GV2PR04MB12213F4758648CD71F5D5B3B7F3F62@GV2PR04MB12213.eurprd04.prod.outlook.com>
On Wed, Jul 01, 2026 at 08:16:13AM +0000, Clark Wang wrote:
> > > In phy_probe(), genphy_c45_read_eee_abilities() is only called when a
> > > driver uses phydrv->features. Drivers that implement .get_features are
> > > responsible for reading the EEE abilities themselves.
> > >
> > > yt8521_get_features() does not do this, so phydev->supported_eee stays
> > > empty for YT8521/YT8531S and "ethtool --show-eee" reports "EEE status:
> > > not supported", even though the PHY has the standard EEE capability
> > > registers.
> > >
> > > Call genphy_c45_read_eee_abilities() at the end of
> > > yt8521_get_features() to populate supported_eee.
> > >
> > > Fixes: 70479a40954c ("net: phy: Add driver for Motorcomm yt8521
> > > gigabit ethernet phy")
> > > Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
> > > ---
> > > drivers/net/phy/motorcomm.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/net/phy/motorcomm.c
> > b/drivers/net/phy/motorcomm.c
> > > index b49897500a59..46efa3406841 100644
> > > --- a/drivers/net/phy/motorcomm.c
> > > +++ b/drivers/net/phy/motorcomm.c
> > > @@ -2439,6 +2439,9 @@ static int yt8521_get_features(struct phy_device
> > *phydev)
> > > /* add fiber's features to phydev->supported */
> > > yt8521_prepare_fiber_features(phydev, phydev->supported);
> > > }
> > > +
> > > + genphy_c45_read_eee_abilities(phydev);
> >
> > Don't you want to return error if genphy_c45_read_eee_abilities() fails?
>
> EEE is an optional functionality, and the call in genphy_read_abilities() has the following comment. Therefore, I do not return its error here either.
> "
> /* This is optional functionality. If not supported, we may get an error
> * which should be ignored.
> */
> "
This conversation then raises the question, should this be a void
function?
Andrew
^ permalink raw reply
* Re: [PATCH net-next v10 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: Dipayaan Roy @ 2026-07-01 14:29 UTC (permalink / raw)
To: Jakub Kicinski
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, leon, longli, kotaranov, horms, shradhagupta, ssengar,
ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, dipayanroy, leitao, kees,
john.fastabend, hawk, bpf, daniel, ast, sdf, yury.norov,
pavan.chebbi
In-Reply-To: <20260615173314.677c33a8@kernel.org>
On Mon, Jun 15, 2026 at 05:33:14PM -0700, Jakub Kicinski wrote:
> On Mon, 15 Jun 2026 17:21:54 -0700 Dipayaan Roy wrote:
> > On Mon, Jun 15, 2026 at 01:42:47PM -0700, Jakub Kicinski wrote:
> > > On Mon, 15 Jun 2026 12:25:53 -0700 Dipayaan Roy wrote:
> > > > Just a gentle ping on this series. The approach was agreed upon, and it
> > > > has picked up a few Reviewed-by tags as well.
> > > >
> > > > Please let me know if you need anything else from me, or if I should
> > > > resend it to collect the tags.
> > >
> > > Don't recall now what the exact sequence was but pretty sure this
> > > no longer applied after some other mana series was merged.
> >
> > I see, the net-next is closed now, I will rebase and resend this
> > once it opens on June 29th.
>
> Sorry for not flagging this sooner, IDK how it escaped the reply.
> Maybe some mix of Jake's comments plus it not being applicable
> later.
>
> Not to deflect blame but y'all should coordinate better, the "no longer
> applies" situation happens in mana a lot more often than with other
> drivers :(
Hi Jakub,
I have rebased and sent a v11:
https://lore.kernel.org/all/20260701141808.461554-1-dipayanroy@linux.microsoft.com/
Thank you for all the support.
Regards
Dipayaan Roy
^ permalink raw reply
* Re: [PATCH] net: phylink: reject unsupported speed/duplex in ksettings_set() with PHY
From: Andrew Lunn @ 2026-07-01 14:27 UTC (permalink / raw)
To: Maxime Chevallier
Cc: muhammad.nazim.amirul.nazle.asmade, linux, hkallweit1, davem,
edumazet, kuba, pabeni, netdev, linux-kernel
In-Reply-To: <37005060-acfb-4791-aa2c-caa3710d4450@bootlin.com>
> I think rejecting these settings makes sense, I'm however wondering
> wether this is a fix or not, as this will change user-visible behaviour.
> I'd err to the side of caution and send that to net-next, but maybe
> Andrew will have more insight :)
net-next seems reasonable.
Andrew
^ permalink raw reply
* Re: [PATCH v3 1/1] bus: mhi: pci_generic: fix Rolling Wireless RW135R-GL and RW151 support
From: Loic Poulain @ 2026-07-01 14:27 UTC (permalink / raw)
To: zwq2226404116
Cc: mhi, linux-arm-msm, netdev, mani, ryazanov.s.a, andrew+netdev,
davem, kuba, Wanquan Zhong
In-Reply-To: <20260701095344.309409-1-zwq2226404116@163.com>
On Wed, Jul 1, 2026 at 11:54 AM <zwq2226404116@163.com> wrote:
>
> From: Wanquan Zhong <wanquan.zhong@fibocom.com>
>
> bus: mhi: pci_generic: fix Rolling Wireless RW135R-GL and RW151 support
>
> - Increase RW151 MBIM channel ring size from 4 to 32
Why? What is the problem today? If they don’t address the same issue,
they should be split into two separate patches.
>
> On HP and Lenovo laptop platforms the device probes successfully and
> WWAN ports are created, but pci_generic enables runtime autosuspend
> (PCI D3hot/M3) after a short idle period. Resume from runtime PM leaves
> the modem in MHI SYS ERROR; driver recovery (reset) fails and the device
> becomes inaccessible (PCIe config space reads as 0x7f). The failure is not
> self-recoverable while runtime PM remains enabled; keeping power/control=on
> avoids the issue.
>
> Set no_m3 on RW135R-GL and RW151 so probe does not enable runtime M3
> autosuspend for these modules.
>
> Power management testing (separate from runtime PM above):
> - Suspend-to-RAM (S3/mem): tested on RW135R-GL and RW151; MHI/MBIM/wwan
> function after wake.
> - Suspend-to-disk (hibernate): not available on the test platforms
> (/sys/power/state lacks "disk", ENODEV).
>
> Signed-off-by: Wanquan Zhong <wanquan.zhong@fibocom.com>
>
> ---
> v2 -> v3: RW151 MBIM ring size 32; disable runtime M3 (no_m3)
> drivers/bus/mhi/host/pci_generic.c | 4 +++-
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
> index d598bb3b3981..d0fee7e3ba3a 100644
> --- a/drivers/bus/mhi/host/pci_generic.c
> +++ b/drivers/bus/mhi/host/pci_generic.c
> @@ -942,6 +942,7 @@ static const struct mhi_pci_dev_info mhi_rolling_rw135r_info = {
> .bar_num = MHI_PCI_DEFAULT_BAR_NUM,
> .dma_data_width = 32,
> .sideband_wake = false,
> + .no_m3 = true,
> .mru_default = 32768,
> .edl_trigger = true,
> };
> @@ -949,8 +950,8 @@ static const struct mhi_pci_dev_info mhi_rolling_rw135r_info = {
> static const struct mhi_channel_config mhi_rolling_rw151_channels[] = {
> MHI_CHANNEL_CONFIG_UL(4, "DIAG", 16, 1),
> MHI_CHANNEL_CONFIG_DL(5, "DIAG", 16, 1),
> - MHI_CHANNEL_CONFIG_UL(12, "MBIM", 4, 0),
> - MHI_CHANNEL_CONFIG_DL(13, "MBIM", 4, 0),
> + MHI_CHANNEL_CONFIG_UL(12, "MBIM", 32, 0),
> + MHI_CHANNEL_CONFIG_DL(13, "MBIM", 32, 0),
> MHI_CHANNEL_CONFIG_UL(14, "NMEA", 32, 0),
> MHI_CHANNEL_CONFIG_DL(15, "NMEA", 32, 0),
> MHI_CHANNEL_CONFIG_UL(32, "DUN", 32, 0),
> @@ -986,6 +987,7 @@ static const struct mhi_pci_dev_info mhi_rolling_rw151_info = {
> .bar_num = MHI_PCI_DEFAULT_BAR_NUM,
> .dma_data_width = 32,
> .sideband_wake = false,
> + .no_m3 = true,
> .mru_default = 32768,
> .edl_trigger = true,
> };
>
> --
> 2.50.0
>
^ permalink raw reply
* Re: [PATCH net] bnx2x: fix null pointer dereference in bnx2x_free_mem_bp()
From: Maciej Fijalkowski @ 2026-07-01 14:20 UTC (permalink / raw)
To: Abdun Nihaal
Cc: skalluru, manishc, andrew+netdev, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, horms, stable
In-Reply-To: <20260701065030.381836-1-nihaal@cse.iitm.ac.in>
On Wed, Jul 01, 2026 at 12:20:26PM +0530, Abdun Nihaal wrote:
> In one of the error path in bnx2x_alloc_mem_bp(), bnx2x_free_mem_bp()
> may be called with bp->fp uninitialized. And so, there could be a null
> pointer dereference in bnx2x_free_mem_bp(). Fix that by adding a null
> check before the only dereference of bp->fp in the function.
>
> The issue was reported by Sashiko AI review.
>
> Fixes: c3146eb676e7 ("bnx2x: Correct memory preparation and release")
> Cc: stable@vger.kernel.org
> Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
> ---
> Compile tested only.
> Thanks to Simon Horman for pointing out the Sashiko review.
Should we include Reported-by tag given to Sashiko? I did that in my last
changes, I guess it would be good to track the amount of things fixed that
originated from Sashiko review.
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
>
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> index 5b2640bd31c3..25ee45cb7f3f 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
> @@ -4712,8 +4712,9 @@ void bnx2x_free_mem_bp(struct bnx2x *bp)
> {
> int i;
>
> - for (i = 0; i < bp->fp_array_size; i++)
> - kfree(bp->fp[i].tpa_info);
> + if (bp->fp)
> + for (i = 0; i < bp->fp_array_size; i++)
> + kfree(bp->fp[i].tpa_info);
> kfree(bp->fp);
> kfree(bp->sp_objs);
> kfree(bp->fp_stats);
> --
> 2.43.0
>
>
^ permalink raw reply
* [PATCH net-next v11 2/2] net: mana: force full-page RX buffers via ethtool private flag
From: Dipayaan Roy @ 2026-07-01 14:15 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
kuba, pabeni, leon, longli, kotaranov, horms, shradhagupta,
ssengar, ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, dipayanroy, leitao, kees,
john.fastabend, hawk, bpf, daniel, ast, sdf, yury.norov,
pavan.chebbi
In-Reply-To: <20260701141808.461554-1-dipayanroy@linux.microsoft.com>
On some ARM64 platforms with 4K PAGE_SIZE, page_pool fragment
allocation in the RX refill path can cause 15-20% throughput
regression under high connection counts (>16 TCP streams).
Add an ethtool private flag "full-page-rx" that allows the user to
force one RX buffer per page, bypassing the page_pool fragment path.
This restores line-rate (180+ Gbps) performance on affected platforms.
Usage:
ethtool --set-priv-flags eth0 full-page-rx on
There is no behavioral change by default. The flag must be explicitly
enabled by the user or udev rule.
The existing single-buffer-per-page logic for XDP and jumbo frames is
consolidated into a new helper mana_use_single_rxbuf_per_page() which
is now the single decision point for both the automatic and
user-controlled paths.
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
---
drivers/net/ethernet/microsoft/mana/mana_en.c | 22 +++-
.../ethernet/microsoft/mana/mana_ethtool.c | 103 ++++++++++++++++++
include/net/mana/mana.h | 8 ++
3 files changed, 131 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index 26aef21c6c2c..4bd83c782ea3 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -755,6 +755,25 @@ static void *mana_get_rxbuf_pre(struct mana_rxq *rxq, dma_addr_t *da)
return va;
}
+static bool
+mana_use_single_rxbuf_per_page(struct mana_port_context *apc, u32 mtu)
+{
+ /* On some platforms with 4K PAGE_SIZE, page_pool fragment allocation
+ * in the RX refill path (~2kB buffer) can cause significant throughput
+ * regression under high connection counts. Allow user to force one RX
+ * buffer per page via ethtool private flag to bypass the fragment
+ * path.
+ */
+ if (apc->priv_flags & BIT(MANA_PRIV_FLAG_USE_FULL_PAGE_RXBUF))
+ return true;
+
+ /* For xdp and jumbo frames make sure only one packet fits per page. */
+ if (mtu + MANA_RXBUF_PAD > PAGE_SIZE / 2 || mana_xdp_get(apc))
+ return true;
+
+ return false;
+}
+
/* Get RX buffer's data size, alloc size, XDP headroom based on MTU */
static void mana_get_rxbuf_cfg(struct mana_port_context *apc,
int mtu, u32 *datasize, u32 *alloc_size,
@@ -765,8 +784,7 @@ static void mana_get_rxbuf_cfg(struct mana_port_context *apc,
/* Calculate datasize first (consistent across all cases) */
*datasize = mtu + ETH_HLEN;
- /* For xdp and jumbo frames make sure only one packet fits per page */
- if (mtu + MANA_RXBUF_PAD > PAGE_SIZE / 2 || mana_xdp_get(apc)) {
+ if (mana_use_single_rxbuf_per_page(apc, mtu)) {
if (mana_xdp_get(apc)) {
*headroom = XDP_PACKET_HEADROOM;
*alloc_size = PAGE_SIZE;
diff --git a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
index fa9c49592828..3c498a222965 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
@@ -133,6 +133,10 @@ static const struct mana_stats_desc mana_phy_stats[] = {
{ "hc_tc7_tx_pause_phy", offsetof(struct mana_ethtool_phy_stats, tx_pause_tc7_phy) },
};
+static const char mana_priv_flags[MANA_PRIV_FLAG_MAX][ETH_GSTRING_LEN] = {
+ [MANA_PRIV_FLAG_USE_FULL_PAGE_RXBUF] = "full-page-rx"
+};
+
static int mana_get_sset_count(struct net_device *ndev, int stringset)
{
struct mana_port_context *apc = netdev_priv(ndev);
@@ -144,6 +148,10 @@ static int mana_get_sset_count(struct net_device *ndev, int stringset)
ARRAY_SIZE(mana_phy_stats) +
ARRAY_SIZE(mana_hc_stats) +
num_queues * (MANA_STATS_RX_COUNT + MANA_STATS_TX_COUNT);
+
+ case ETH_SS_PRIV_FLAGS:
+ return MANA_PRIV_FLAG_MAX;
+
default:
return -EINVAL;
}
@@ -192,6 +200,14 @@ static void mana_get_strings_stats(struct mana_port_context *apc, u8 **data)
}
}
+static void mana_get_strings_priv_flags(u8 **data)
+{
+ int i;
+
+ for (i = 0; i < MANA_PRIV_FLAG_MAX; i++)
+ ethtool_puts(data, mana_priv_flags[i]);
+}
+
static void mana_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
{
struct mana_port_context *apc = netdev_priv(ndev);
@@ -200,6 +216,9 @@ static void mana_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
case ETH_SS_STATS:
mana_get_strings_stats(apc, &data);
break;
+ case ETH_SS_PRIV_FLAGS:
+ mana_get_strings_priv_flags(&data);
+ break;
default:
break;
}
@@ -611,6 +630,88 @@ static int mana_get_link_ksettings(struct net_device *ndev,
return 0;
}
+static u32 mana_get_priv_flags(struct net_device *ndev)
+{
+ struct mana_port_context *apc = netdev_priv(ndev);
+
+ return apc->priv_flags;
+}
+
+static int mana_set_priv_flags(struct net_device *ndev, u32 priv_flags)
+{
+ struct mana_port_context *apc = netdev_priv(ndev);
+ u32 changed = apc->priv_flags ^ priv_flags;
+ u32 old_priv_flags = apc->priv_flags;
+ bool schedule_port_reset = false;
+ int err = 0;
+
+ if (!changed)
+ return 0;
+
+ /* Reject unknown bits */
+ if (priv_flags & ~GENMASK(MANA_PRIV_FLAG_MAX - 1, 0))
+ return -EINVAL;
+
+ if (changed & BIT(MANA_PRIV_FLAG_USE_FULL_PAGE_RXBUF)) {
+ apc->priv_flags = priv_flags;
+
+ if (!apc->port_is_up) {
+ /* Port is down, flag updated to apply on next up
+ * so just return.
+ */
+ return 0;
+ }
+
+ /* Pre-allocate buffers to prevent failure in mana_attach
+ * later
+ */
+ err = mana_pre_alloc_rxbufs(apc, ndev->mtu, apc->num_queues);
+ if (err) {
+ netdev_err(ndev,
+ "Insufficient memory for new allocations\n");
+ apc->priv_flags = old_priv_flags;
+ return err;
+ }
+
+ err = mana_detach(ndev, false);
+ if (err) {
+ netdev_err(ndev, "mana_detach failed: %d\n", err);
+ apc->priv_flags = old_priv_flags;
+
+ /* Port is in an inconsistent state. Restore
+ * 'port_is_up' so that queue reset work handler
+ * can properly detach and re-attach.
+ */
+ apc->port_is_up = true;
+ schedule_port_reset = true;
+ goto out;
+ }
+
+ err = mana_attach(ndev);
+ if (err) {
+ netdev_err(ndev, "mana_attach failed: %d\n", err);
+ apc->priv_flags = old_priv_flags;
+
+ /* Restore 'port_is_up' so the reset work handler
+ * can properly detach/attach. Without this,
+ * the handler sees port_is_up=false and skips
+ * queue allocation, leaving the port dead.
+ */
+ apc->port_is_up = true;
+ schedule_port_reset = true;
+ }
+ }
+
+out:
+ mana_pre_dealloc_rxbufs(apc);
+
+ if (schedule_port_reset)
+ queue_work(apc->ac->per_port_queue_reset_wq,
+ &apc->queue_reset_work);
+
+ return err;
+}
+
const struct ethtool_ops mana_ethtool_ops = {
.supported_coalesce_params = ETHTOOL_COALESCE_RX_CQE_FRAMES,
.op_needs_rtnl = ETHTOOL_OP_NEEDS_RTNL_SCHANNELS |
@@ -631,4 +732,6 @@ const struct ethtool_ops mana_ethtool_ops = {
.set_ringparam = mana_set_ringparam,
.get_link_ksettings = mana_get_link_ksettings,
.get_link = ethtool_op_get_link,
+ .get_priv_flags = mana_get_priv_flags,
+ .set_priv_flags = mana_set_priv_flags,
};
diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h
index 13c87baf018e..8dc496f05938 100644
--- a/include/net/mana/mana.h
+++ b/include/net/mana/mana.h
@@ -30,6 +30,12 @@ enum TRI_STATE {
TRI_STATE_TRUE = 1
};
+/* MANA ethtool private flag bit positions */
+enum mana_priv_flag_bits {
+ MANA_PRIV_FLAG_USE_FULL_PAGE_RXBUF = 0,
+ MANA_PRIV_FLAG_MAX,
+};
+
/* Number of entries for hardware indirection table must be in power of 2 */
#define MANA_INDIRECT_TABLE_MAX_SIZE 512
#define MANA_INDIRECT_TABLE_DEF_SIZE 64
@@ -532,6 +538,8 @@ struct mana_port_context {
u32 rxbpre_headroom;
u32 rxbpre_frag_count;
+ u32 priv_flags;
+
struct bpf_prog *bpf_prog;
/* Create num_queues EQs, SQs, SQ-CQs, RQs and RQ-CQs, respectively. */
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v11 1/2] net: mana: refactor mana_get_strings() and mana_get_sset_count() to use switch
From: Dipayaan Roy @ 2026-07-01 14:15 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
kuba, pabeni, leon, longli, kotaranov, horms, shradhagupta,
ssengar, ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, dipayanroy, leitao, kees,
john.fastabend, hawk, bpf, daniel, ast, sdf, yury.norov,
pavan.chebbi
In-Reply-To: <20260701141808.461554-1-dipayanroy@linux.microsoft.com>
Refactor mana_get_strings() and mana_get_sset_count() from if/else to
switch statements in preparation for adding ethtool private flags
support which requires handling ETH_SS_PRIV_FLAGS.
No functional change.
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
---
.../ethernet/microsoft/mana/mana_ethtool.c | 75 ++++++++++++-------
1 file changed, 46 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
index 94e658d07a27..fa9c49592828 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_ethtool.c
@@ -138,53 +138,70 @@ static int mana_get_sset_count(struct net_device *ndev, int stringset)
struct mana_port_context *apc = netdev_priv(ndev);
unsigned int num_queues = apc->num_queues;
- if (stringset != ETH_SS_STATS)
+ switch (stringset) {
+ case ETH_SS_STATS:
+ return ARRAY_SIZE(mana_eth_stats) +
+ ARRAY_SIZE(mana_phy_stats) +
+ ARRAY_SIZE(mana_hc_stats) +
+ num_queues * (MANA_STATS_RX_COUNT + MANA_STATS_TX_COUNT);
+ default:
return -EINVAL;
-
- return ARRAY_SIZE(mana_eth_stats) + ARRAY_SIZE(mana_phy_stats) + ARRAY_SIZE(mana_hc_stats) +
- num_queues * (MANA_STATS_RX_COUNT + MANA_STATS_TX_COUNT);
+ }
}
-static void mana_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
+static void mana_get_strings_stats(struct mana_port_context *apc, u8 **data)
{
- struct mana_port_context *apc = netdev_priv(ndev);
unsigned int num_queues = apc->num_queues;
int i, j;
- if (stringset != ETH_SS_STATS)
- return;
for (i = 0; i < ARRAY_SIZE(mana_eth_stats); i++)
- ethtool_puts(&data, mana_eth_stats[i].name);
+ ethtool_puts(data, mana_eth_stats[i].name);
for (i = 0; i < ARRAY_SIZE(mana_hc_stats); i++)
- ethtool_puts(&data, mana_hc_stats[i].name);
+ ethtool_puts(data, mana_hc_stats[i].name);
for (i = 0; i < ARRAY_SIZE(mana_phy_stats); i++)
- ethtool_puts(&data, mana_phy_stats[i].name);
+ ethtool_puts(data, mana_phy_stats[i].name);
for (i = 0; i < num_queues; i++) {
- ethtool_sprintf(&data, "rx_%d_packets", i);
- ethtool_sprintf(&data, "rx_%d_bytes", i);
- ethtool_sprintf(&data, "rx_%d_xdp_drop", i);
- ethtool_sprintf(&data, "rx_%d_xdp_tx", i);
- ethtool_sprintf(&data, "rx_%d_xdp_redirect", i);
- ethtool_sprintf(&data, "rx_%d_pkt_len0_err", i);
+ ethtool_sprintf(data, "rx_%d_packets", i);
+ ethtool_sprintf(data, "rx_%d_bytes", i);
+ ethtool_sprintf(data, "rx_%d_xdp_drop", i);
+ ethtool_sprintf(data, "rx_%d_xdp_tx", i);
+ ethtool_sprintf(data, "rx_%d_xdp_redirect", i);
+ ethtool_sprintf(data, "rx_%d_pkt_len0_err", i);
for (j = 0; j < MANA_RXCOMP_OOB_NUM_PPI - 1; j++)
- ethtool_sprintf(&data, "rx_%d_coalesced_cqe_%d", i, j + 2);
+ ethtool_sprintf(data,
+ "rx_%d_coalesced_cqe_%d",
+ i,
+ j + 2);
}
for (i = 0; i < num_queues; i++) {
- ethtool_sprintf(&data, "tx_%d_packets", i);
- ethtool_sprintf(&data, "tx_%d_bytes", i);
- ethtool_sprintf(&data, "tx_%d_xdp_xmit", i);
- ethtool_sprintf(&data, "tx_%d_tso_packets", i);
- ethtool_sprintf(&data, "tx_%d_tso_bytes", i);
- ethtool_sprintf(&data, "tx_%d_tso_inner_packets", i);
- ethtool_sprintf(&data, "tx_%d_tso_inner_bytes", i);
- ethtool_sprintf(&data, "tx_%d_long_pkt_fmt", i);
- ethtool_sprintf(&data, "tx_%d_short_pkt_fmt", i);
- ethtool_sprintf(&data, "tx_%d_csum_partial", i);
- ethtool_sprintf(&data, "tx_%d_mana_map_err", i);
+ ethtool_sprintf(data, "tx_%d_packets", i);
+ ethtool_sprintf(data, "tx_%d_bytes", i);
+ ethtool_sprintf(data, "tx_%d_xdp_xmit", i);
+ ethtool_sprintf(data, "tx_%d_tso_packets", i);
+ ethtool_sprintf(data, "tx_%d_tso_bytes", i);
+ ethtool_sprintf(data, "tx_%d_tso_inner_packets", i);
+ ethtool_sprintf(data, "tx_%d_tso_inner_bytes", i);
+ ethtool_sprintf(data, "tx_%d_long_pkt_fmt", i);
+ ethtool_sprintf(data, "tx_%d_short_pkt_fmt", i);
+ ethtool_sprintf(data, "tx_%d_csum_partial", i);
+ ethtool_sprintf(data, "tx_%d_mana_map_err", i);
+ }
+}
+
+static void mana_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
+{
+ struct mana_port_context *apc = netdev_priv(ndev);
+
+ switch (stringset) {
+ case ETH_SS_STATS:
+ mana_get_strings_stats(apc, &data);
+ break;
+ default:
+ break;
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH net-next v11 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: Dipayaan Roy @ 2026-07-01 14:15 UTC (permalink / raw)
To: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
kuba, pabeni, leon, longli, kotaranov, horms, shradhagupta,
ssengar, ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, dipayanroy, leitao, kees,
john.fastabend, hawk, bpf, daniel, ast, sdf, yury.norov,
pavan.chebbi
On some ARM64 platforms with 4K PAGE_SIZE, utilizing page_pool
fragments for allocation in the RX refill path (~2kB buffer per fragment)
causes 15-20% throughput regression under high connection counts
(>16 TCP streams at 180+ Gbps). Using full-page buffers on these
platforms shows no regression and restores line-rate performance.
This behavior is observed on a single platform; other platforms
perform better with page_pool fragments, indicating this is not a
page_pool issue but platform-specific.
This series adds an ethtool private flag "full-page-rx" to let the
user opt in to one RX buffer per page:
ethtool --set-priv-flags eth0 full-page-rx on
There is no behavioral change by default. The flag can be persisted
via udev rule for affected platforms.
This series depends on the following fixes now merged in net-next:
commit 17bfe0a8c014 ("net: mana: Add NULL guards in teardown path to prevent panic on attach failure")
commit 5b05aa36ee24 ("net: mana: Skip redundant detach on already-detached port")
Changes in v11:
- Rebased on net-next
Changes in v10:
- Rebased on net-next which now includes the prerequisite fixes.
- Recovery logic in mana_set_priv_flags() leverages the idempotent
mana_detach() from the merged fixes.
Changes in v9:
- Added correct tree.
Changes in v8:
- Fixed queue_reset_work recovery by restoring port_is_up before
scheduling reset so the handler can properly re-attach.
- Simplified "err && schedule_port_reset" to "schedule_port_reset".
Changes in v7:
- Rebased onto net-next.
- Retained private flag approach after David Wei's testing on
Grace (ARM64) confirmed that fragment mode outperforms
full-page mode on other platforms, validating this is a
single-platform workaround rather than a generic issue.
Changes in v6:
- Added missed maintainers.
Changes in v5:
- Split prep refactor into separate patch (patch 1/2)
Changes in v4:
- Dropping the smbios string parsing and add ethtool priv flag
to reconfigure the queues with full page rx buffers.
Changes in v3:
- changed u8* to char*
Changes in v2:
- separate reading string index and the string, remove inline.
Dipayaan Roy (2):
net: mana: refactor mana_get_strings() and mana_get_sset_count() to
use switch
net: mana: force full-page RX buffers via ethtool private flag
drivers/net/ethernet/microsoft/mana/mana_en.c | 22 ++-
.../ethernet/microsoft/mana/mana_ethtool.c | 178 +++++++++++++++---
include/net/mana/mana.h | 8 +
3 files changed, 177 insertions(+), 31 deletions(-)
--
2.43.0
^ 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