* Re: [PATCH net 1/2] net: bcmgenet: fix leaking free_bds
From: Jakub Kicinski @ 2026-03-28 4:11 UTC (permalink / raw)
To: justin.chen
Cc: netdev, pabeni, edumazet, davem, andrew+netdev,
bcm-kernel-feedback-list, florian.fainelli, opendmb, nb
In-Reply-To: <20260326184529.1393438-2-justin.chen@brodcom.com>
On Thu, 26 Mar 2026 11:45:28 -0700 justin.chen@broadcom.com wrote:
> From: Justin Chen <justin.chen@broadcom.com>
>
> While reclaiming the tx queue we fast forward the write pointer to
> drop any data in flight. These dropped frames are not added back
> to the pool of free bds. We also need to tell the netdev that we
> are dropping said data.
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index 482a31e7b72b..3e1fc3bb8297 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -1985,6 +1985,7 @@ static unsigned int bcmgenet_tx_reclaim(struct net_device *dev,
> drop = (ring->prod_index - ring->c_index) & DMA_C_INDEX_MASK;
> released += drop;
> ring->prod_index = ring->c_index & DMA_C_INDEX_MASK;
> + ring->free_bds += drop;
> while (drop--) {
> cb_ptr = bcmgenet_put_txcb(priv, ring);
> skb = cb_ptr->skb;
> @@ -1996,6 +1997,7 @@ static unsigned int bcmgenet_tx_reclaim(struct net_device *dev,
> }
> if (skb)
> dev_consume_skb_any(skb);
> + netdev_tx_reset_queue(netdev_get_tx_queue(dev, ring->index));
> bcmgenet_tdma_ring_writel(priv, ring->index,
> ring->prod_index, TDMA_PROD_INDEX);
> wr_ptr = ring->write_ptr * WORDS_PER_BD(priv);
AI says you may be off by one here?
Does this loop miss the oldest dropped descriptor and leak its SKB and
DMA mapping?
Since bcmgenet_get_txcb() increments write_ptr after a transmission,
write_ptr always points to the next available empty slot.
When this loops backwards drop times, the first iteration retrieves that
empty descriptor (where cb->skb is NULL), and the loop will finish before
reaching the oldest uncompleted descriptor at c_index.
When write_ptr is rolled back to c_index, won't subsequent transmissions
overwrite the descriptor at c_index and permanently leak the unmapped DMA
buffer and SKB memory?
^ permalink raw reply
* Re: [PATCH net-next v4 0/2] net: stmmac: Disable EEE on i.MX
From: patchwork-bot+netdevbpf @ 2026-03-28 4:10 UTC (permalink / raw)
To: Laurent Pinchart
Cc: netdev, imx, andrew+netdev, davem, edumazet, festevam,
francesco.dolcini, Frank.Li, kuba, joy.zou, kieran.bingham,
m.felsch, pabeni, kernel, rmk+kernel, stefan.klug,
linux-arm-kernel
In-Reply-To: <20260325210003.2752013-1-laurent.pinchart@ideasonboard.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 25 Mar 2026 23:00:01 +0200 you wrote:
> Hello,
>
> This small patch series fixes a long-standing interrupt storm issue with
> stmmac on NXP i.MX platforms.
>
> The initial attempt to fix^Wwork around the problem in DT ([1]) was
> painfully but rightfully rejected by Russell, who helped me investigate
> the issue in depth. It turned out that the root cause is a mistake in
> how interrupts are wired in the SoC, a hardware bug that has been
> replicated in all i.MX SoCs that integrate an stmmac. The only viable
> solution is to disable EEE on those devices.
>
> [...]
Here is the summary with links:
- [net-next,v4,1/2] net: stmmac: provide flag to disable EEE
https://git.kernel.org/netdev/net-next/c/187b00a26679
- [net-next,v4,2/2] net: stmmac: imx: Disable EEE
https://git.kernel.org/netdev/net-next/c/394863097e36
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] vrf: A few cleanups
From: patchwork-bot+netdevbpf @ 2026-03-28 4:10 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev, davem, kuba, pabeni, edumazet, dsahern, andrew+netdev,
petrm, lirongqing
In-Reply-To: <20260326203233.1128554-1-idosch@nvidia.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 26 Mar 2026 22:32:30 +0200 you wrote:
> Perform a few cleanups in the VRF driver. Noticed these while reviewing
> a recent patch [1]. See individual patches for more details.
>
> [1] https://lore.kernel.org/netdev/20260310105331.2371-1-lirongqing@baidu.com/
>
> v2:
> * In patch #3, remove RCU protection around dst entries instead of just
> the synchronize_rcu() calls.
>
> [...]
Here is the summary with links:
- [net-next,v2,1/3] vrf: Remove unnecessary NULL check
https://git.kernel.org/netdev/net-next/c/ae3cdfd4e0b8
- [net-next,v2,2/3] vrf: Use dst_dev_put() instead of using loopback device
https://git.kernel.org/netdev/net-next/c/50504e2579c1
- [net-next,v2,3/3] vrf: Remove unnecessary RCU protection around dst entries
https://git.kernel.org/netdev/net-next/c/075196489a37
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2] net: mana: Use at least SZ_4K in doorbell ID range check
From: patchwork-bot+netdevbpf @ 2026-03-28 4:00 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, horms, shradhagupta, kotaranov,
dipayanroy, yury.norov, kees, linux-hyperv, netdev, linux-kernel
In-Reply-To: <20260325180423.1923060-1-ernis@linux.microsoft.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 25 Mar 2026 11:04:17 -0700 you wrote:
> mana_gd_ring_doorbell() accesses offsets up to DOORBELL_OFFSET_EQ
> (0xFF8) + 8 bytes = 4KB within each doorbell page. A db_page_size
> smaller than SZ_4K is fundamentally incompatible with the driver:
> doorbell pages would overlap and the device cannot function correctly.
>
> Validate db_page_size at the source and fail the
> probe early if the value is below SZ_4K. This ensures the doorbell ID
> range check in mana_gd_register_device() can rely on db_page_size
> being valid.
>
> [...]
Here is the summary with links:
- [net-next,v2] net: mana: Use at least SZ_4K in doorbell ID range check
https://git.kernel.org/netdev/net-next/c/fb4b4a05aeeb
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] mlx5: shd: Gracefully avoid shared devlink creation when no usable SN is found
From: patchwork-bot+netdevbpf @ 2026-03-28 4:00 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, edumazet, kuba, pabeni, andrew+netdev, saeedm,
leon, tariqt, mbloch, admiyo, ben.copeland
In-Reply-To: <20260325152801.236343-1-jiri@resnulli.us>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 25 Mar 2026 16:28:01 +0100 you wrote:
> From: Jiri Pirko <jiri@nvidia.com>
>
> On some HW, not even fall-back "SERIALNO" is found in VPD data. Unify
> the behavior with the case there are no VPD data at all and avoid
> creation of shared devlink instance.
>
> Fixes: 2a8c8a03f306 ("net/mlx5: Add a shared devlink instance for PFs on same chip")
> Reported-by: Adam Young <admiyo@amperemail.onmicrosoft.com>
> Closes: https://lore.kernel.org/all/bab5b6bc-aa42-4af1-80d1-e56bcef06bc2@amperemail.onmicrosoft.com/
> Reported-by: Ben Copeland <ben.copeland@linaro.org>
> Closes: https://lore.kernel.org/all/20260324151014.860376-1-ben.copeland@linaro.org/
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>
> [...]
Here is the summary with links:
- [net-next] mlx5: shd: Gracefully avoid shared devlink creation when no usable SN is found
https://git.kernel.org/netdev/net-next/c/b8f9410aefc1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: sfp: Fix Ubiquiti U-Fiber Instant SFP module on mvneta
From: patchwork-bot+netdevbpf @ 2026-03-28 4:00 UTC (permalink / raw)
To: =?utf-8?q?Marek_Beh=C3=BAn_=3Ckabel=40kernel=2Eorg=3E?=
Cc: netdev, linux, pabeni, kuba, edumazet, davem, hkallweit1, andrew,
maxime.chevallier
In-Reply-To: <20260326122038.2489589-1-kabel@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 26 Mar 2026 13:20:38 +0100 you wrote:
> In commit 8110633db49d7de2 ("net: sfp-bus: allow SFP quirks to override
> Autoneg and pause bits") we moved the setting of Autoneg and pause bits
> before the call to SFP quirk when parsing SFP module support.
>
> Since the quirk for Ubiquiti U-Fiber Instant SFP module zeroes the
> support bits and sets 1000baseX_Full only, the above mentioned commit
> changed the overall computed support from
> 1000baseX_Full, Autoneg, Pause, Asym_Pause
> to just
> 1000baseX_Full.
>
> [...]
Here is the summary with links:
- [net] net: sfp: Fix Ubiquiti U-Fiber Instant SFP module on mvneta
https://git.kernel.org/netdev/net/c/eeee5a710f26
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 net 0/2] net: enetc: add more checks to enetc_set_rxfh()
From: patchwork-bot+netdevbpf @ 2026-03-28 4:00 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, alexandru.marginean, netdev,
linux-kernel, imx
In-Reply-To: <20260326075233.3628047-1-wei.fang@nxp.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 26 Mar 2026 15:52:31 +0800 you wrote:
> ENETC only supports Toeplitz algorithm, and VFs do not support setting
> the RSS key, but enetc_set_rxfh() does not check these constraints and
> silently accepts unsupported configurations. This may mislead users or
> tools into believing that the requested RSS settings have been
> successfully applied. So add checks to reject unsupported hash functions
> and RSS key updates on VFs, and return "-EOPNOTSUPP" to user space.
>
> [...]
Here is the summary with links:
- [v2,net,1/2] net: enetc: check whether the RSS algorithm is Toeplitz
https://git.kernel.org/netdev/net/c/d389954a6cae
- [v2,net,2/2] net: enetc: do not allow VF to configure the RSS key
https://git.kernel.org/netdev/net/c/a142d139168c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: sfp: add quirk for ZOERAX SFP-2.5G-T
From: Jakub Kicinski @ 2026-03-28 3:50 UTC (permalink / raw)
To: Jan Hoffmann
Cc: Russell King, Andrew Lunn, Heiner Kallweit, David S. Miller,
Eric Dumazet, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <20260325164034.1542787-1-jan@3e8.eu>
On Wed, 25 Mar 2026 17:35:58 +0100 Jan Hoffmann wrote:
> This is a 2.5G copper module which appears to be based on a Motorcomm
> YT8821 PHY. There doesn't seem to be a usable way to to access the PHY
> (I2C address 0x56 provides only read-only C22 access, and Rollball is
> also not working).
>
> The module does not report the correct extended compliance code for
> 2.5GBase-T, and instead claims to support SONET OC-48 and Fibre Channel:
>
> Identifier : 0x03 (SFP)
> Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
> Connector : 0x07 (LC)
> Transceiver codes : 0x00 0x01 0x00 0x00 0x40 0x40 0x04 0x00 0x00
> Transceiver type : FC: Multimode, 50um (M5)
> Encoding : 0x05 (SONET Scrambled)
> BR Nominal : 2500MBd
>
> Despite this, the kernel still sets 2500Base-X as interface mode based
> on the (incorrect) nominal signaling rate.
>
> However, it is also necessary to disable auto-negotiation for the module
> to actually work. Thus, create a SFP quirk to do this.
>
> Signed-off-by: Jan Hoffmann <jan@3e8.eu>
> ---
> Note: I'm not quite sure "sfp_quirk_disable_autoneg" is enough here, or
> if it would be appropriate to use the full "sfp_quirk_oem_2_5g" quirk
> due to the not really correct compliance code / nominal signaling rate.
I'm no SFP expert but just going by the naming I strongly suspect that
the module is the same hardware as "SFP-2.5G-T" from "FS", so keeping
quirks consistent makes sense?
^ permalink raw reply
* Re: [PATCH net v3 1/2] net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()
From: patchwork-bot+netdevbpf @ 2026-03-28 3:50 UTC (permalink / raw)
To: Xiang Mei
Cc: security, netdev, pabeni, jhs, jiri, davem, edumazet, kuba, horms,
bestswngs
In-Reply-To: <20260326204310.1549327-1-xmei5@asu.edu>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 26 Mar 2026 13:43:09 -0700 you wrote:
> m2sm() converts a u32 slope to a u64 scaled value. For large inputs
> (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores
> the difference of two such u64 values in a u32 variable `dsm` and
> uses it as a divisor. When the difference is exactly 2^32 the
> truncation yields zero, causing a divide-by-zero oops in the
> concave-curve intersection path:
>
> [...]
Here is the summary with links:
- [net,v3,1/2] net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()
https://git.kernel.org/netdev/net/c/4576100b8cd0
- [net,v3,2/2] selftests/tc-testing: add test for HFSC divide-by-zero in rtsc_min()
https://git.kernel.org/netdev/net/c/5d17af9eb2dd
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 0/2] Fix page fragment handling when PAGE_SIZE > 4K
From: patchwork-bot+netdevbpf @ 2026-03-28 3:40 UTC (permalink / raw)
To: Dimitri Daskalakis
Cc: davem, alexanderduyck, kuba, edumazet, pabeni, andrew+netdev,
horms, mike.marciniszyn, lee, jacob.e.keller, mohsin.bashr,
almasrymina, netdev, kernel-team
In-Reply-To: <20260324195123.3486219-1-dimitri.daskalakis1@gmail.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 24 Mar 2026 12:51:21 -0700 you wrote:
> From: Dimitri Daskalakis <daskald@meta.com>
>
> FBNIC operates on fixed size descriptors (4K). When the OS supports pages
> larger than 4K, we fragment the page across multiple descriptors.
>
> While performance testing, I found several issues with our page fragment
> handling, resulting in low throughput and potential RX stalls.
>
> [...]
Here is the summary with links:
- [net,1/2] eth: fbnic: Account for page fragments when updating BDQ tail
https://git.kernel.org/netdev/net/c/b38c55320bf8
- [net,2/2] eth: fbnic: Fix debugfs output for BDQ's with page frags
https://git.kernel.org/netdev/net/c/f3567dd428b2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 0/3] bridge/vxlan: harden ND option parsing paths
From: patchwork-bot+netdevbpf @ 2026-03-28 3:40 UTC (permalink / raw)
To: Yang Yang
Cc: davem, edumazet, kuba, pabeni, razor, idosch, andrew+netdev,
horms, florian.fainelli, roopa, dlstevens, nb, netdev, bridge,
linux-kernel, yifanwucs, tomapufckgml, tanyuan98, bird
In-Reply-To: <20260326034441.2037420-1-n05ec@lzu.edu.cn>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 26 Mar 2026 03:44:38 +0000 you wrote:
> Hi,
>
> This series hardens ND option parsing in bridge and vxlan paths.
>
> Patch 1 linearizes the request skb in br_nd_send() before walking ND
> options. Patch 2 adds explicit ND option length validation in
> br_nd_send(). Patch 3 adds matching ND option length validation in
> vxlan_na_create().
>
> [...]
Here is the summary with links:
- [net,1/3] bridge: br_nd_send: linearize skb before parsing ND options
https://git.kernel.org/netdev/net/c/a01aee7cafc5
- [net,2/3] bridge: br_nd_send: validate ND option lengths
https://git.kernel.org/netdev/net/c/850837965af1
- [net,3/3] vxlan: validate ND option lengths in vxlan_na_create
https://git.kernel.org/netdev/net/c/afa9a05e6c49
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 net] ptr_ring: disable KCSAN warnings
From: patchwork-bot+netdevbpf @ 2026-03-28 3:30 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, bpf, simon.schippers, willemdebruijn.kernel,
jasowang, andrew+netdev, davem, kuba, pabeni, eperezma, leiyang,
stephen, jon, tim.gebauer, netdev, kvm, virtualization, edumazet
In-Reply-To: <dd3984b3bce9df3591927f927668cb31cc7ecf34.1774460059.git.mst@redhat.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 25 Mar 2026 13:36:00 -0400 you wrote:
> Eric Dumazet reported KCSAN warnings:
>
> BUG: KCSAN: data-race in pfifo_fast_dequeue / pfifo_fast_enqueue
>
> write to 0xffff88811d5ccc00 of 8 bytes by interrupt on cpu 0:
> __ptr_ring_zero_tail include/linux/ptr_ring.h:259 [inline]
> __ptr_ring_discard_one include/linux/ptr_ring.h:291 [inline]
> __ptr_ring_consume include/linux/ptr_ring.h:311 [inline]
> __skb_array_consume include/linux/skb_array.h:98 [inline]
> pfifo_fast_dequeue+0x770/0x8f0 net/sched/sch_generic.c:770
> dequeue_skb net/sched/sch_generic.c:297 [inline]
> qdisc_restart net/sched/sch_generic.c:402 [inline]
> __qdisc_run+0x189/0xc80 net/sched/sch_generic.c:420
> qdisc_run include/net/pkt_sched.h:120 [inline]
> net_tx_action+0x379/0x590 net/core/dev.c:5793
> handle_softirqs+0xb9/0x280 kernel/softirq.c:622
> do_softirq+0x45/0x60 kernel/softirq.c:523
> __local_bh_enable_ip+0x70/0x80 kernel/softirq.c:450
> local_bh_enable include/linux/bottom_half.h:33 [inline]
> bpf_test_run+0x2db/0x620 net/bpf/test_run.c:426
> bpf_prog_test_run_skb+0x9a4/0xef0 net/bpf/test_run.c:1159
> bpf_prog_test_run+0x204/0x340 kernel/bpf/syscall.c:4721
> __sys_bpf+0x52e/0x7e0 kernel/bpf/syscall.c:6246
> __do_sys_bpf kernel/bpf/syscall.c:6341 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:6339 [inline]
> __x64_sys_bpf+0x41/0x50 kernel/bpf/syscall.c:6339
> x64_sys_call+0x10cb/0x3020 arch/x86/include/generated/asm/syscalls_64.h:322
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x12c/0x370 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> [...]
Here is the summary with links:
- [v2,net] ptr_ring: disable KCSAN warnings
https://git.kernel.org/netdev/net-next/c/d748047af135
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()
From: patchwork-bot+netdevbpf @ 2026-03-28 3:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, dsahern, netdev, eric.dumazet, idosch,
oskar.kjos
In-Reply-To: <20260326202608.2976021-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 26 Mar 2026 20:26:08 +0000 you wrote:
> Sashiko AI-review observed:
>
> In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet
> where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2
> and passed to icmp6_send(), it uses IP6CB(skb2).
>
> IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso
> offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm
> at offset 18.
>
> [...]
Here is the summary with links:
- [net] ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()
https://git.kernel.org/netdev/net/c/86ab3e55673a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 net] ip6_tunnel: clear skb2->cb[] in ip4ip6_err()
From: patchwork-bot+netdevbpf @ 2026-03-28 3:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, dsahern, netdev, eric.dumazet,
oskar.kjos, idosch
In-Reply-To: <20260326155138.2429480-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 26 Mar 2026 15:51:38 +0000 you wrote:
> Oskar Kjos reported the following problem.
>
> ip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written
> by the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes
> IPCB(skb2) to __ip_options_echo(), which interprets that cb[] region
> as struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff
> at offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr
> value. __ip_options_echo() then reads optlen from attacker-controlled
> packet data at sptr[rr+1] and copies that many bytes into dopt->__data,
> a fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE).
>
> [...]
Here is the summary with links:
- [v2,net] ip6_tunnel: clear skb2->cb[] in ip4ip6_err()
https://git.kernel.org/netdev/net/c/2edfa31769a4
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 0/2] Fix page fragment handling when PAGE_SIZE > 4K
From: Jakub Kicinski @ 2026-03-28 3:29 UTC (permalink / raw)
To: Dimitri Daskalakis
Cc: David S . Miller, Alexander Duyck, Eric Dumazet, Paolo Abeni,
Andrew Lunn, Simon Horman, Mike Marciniszyn, Lee Trager,
Jacob Keller, Mohsin Bashir, Mina Almasry, netdev, kernel-team
In-Reply-To: <20260324195123.3486219-1-dimitri.daskalakis1@gmail.com>
On Tue, 24 Mar 2026 12:51:21 -0700 Dimitri Daskalakis wrote:
> FBNIC operates on fixed size descriptors (4K). When the OS supports pages
> larger than 4K, we fragment the page across multiple descriptors.
>
> While performance testing, I found several issues with our page fragment
> handling, resulting in low throughput and potential RX stalls.
Google AI reviewer points out that we will also be toast if someone
configures the ring size to just 16 descriptors. Can you check what
is the min size that doesn't wedge w/ 64kB pages and let's just set
the min to that instead of the current 16?
^ permalink raw reply
* [PATCH v2] net: stmmac: avoid repeated devm_gpiod_get_optional in mdio
From: Liu Xiang @ 2026-03-28 3:25 UTC (permalink / raw)
To: netdev; +Cc: andrew+netdev, davem, edumazet, kuba, pabeni, Liu Xiang
During system resume, stmmac_resume() calls stmmac_mdio_reset().
This results in repeated calls to devm_gpiod_get_optional() for the same
GPIO. The second invocation returns an error since the GPIO descriptor has
already been obtained.
Signed-off-by: Liu Xiang <liu.xiang@zlingsmart.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 ++
.../net/ethernet/stmicro/stmmac/stmmac_mdio.c | 18 +++++++++---------
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 33667a267..34ebc6f3a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -372,6 +372,8 @@ struct stmmac_priv {
struct bpf_prog *xdp_prog;
struct devlink *devlink;
+
+ struct gpio_desc *reset_gpio;
};
enum stmmac_state {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index a7c2496b3..d85cfb044 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -386,15 +386,15 @@ int stmmac_mdio_reset(struct mii_bus *bus)
#ifdef CONFIG_OF
if (priv->device->of_node) {
- struct gpio_desc *reset_gpio;
u32 delays[3] = { 0, 0, 0 };
- reset_gpio = devm_gpiod_get_optional(priv->device,
- "snps,reset",
- GPIOD_OUT_LOW);
- if (IS_ERR(reset_gpio))
- return PTR_ERR(reset_gpio);
-
+ if (IS_ERR_OR_NULL(priv->reset_gpio)) {
+ priv->reset_gpio = devm_gpiod_get_optional(priv->device,
+ "snps,reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(priv->reset_gpio))
+ return PTR_ERR(priv->reset_gpio);
+ }
device_property_read_u32_array(priv->device,
"snps,reset-delays-us",
delays, ARRAY_SIZE(delays));
@@ -402,11 +402,11 @@ int stmmac_mdio_reset(struct mii_bus *bus)
if (delays[0])
msleep(DIV_ROUND_UP(delays[0], 1000));
- gpiod_set_value_cansleep(reset_gpio, 1);
+ gpiod_set_value_cansleep(priv->reset_gpio, 1);
if (delays[1])
msleep(DIV_ROUND_UP(delays[1], 1000));
- gpiod_set_value_cansleep(reset_gpio, 0);
+ gpiod_set_value_cansleep(priv->reset_gpio, 0);
if (delays[2])
msleep(DIV_ROUND_UP(delays[2], 1000));
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next v6] selftests: net: add tests for PPP
From: Jakub Kicinski @ 2026-03-28 3:19 UTC (permalink / raw)
To: Qingfang Deng
Cc: Shuah Khan, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Felix Maurer, Sebastian Andrzej Siewior,
Antonio Quartulli, Petr Machata, linux-kernel, linux-kselftest,
linux-ppp, netdev, Paul Mackerras
In-Reply-To: <20260327033438.125135-1-dqfext@gmail.com>
On Fri, 27 Mar 2026 11:34:19 +0800 Qingfang Deng wrote:
> v6: fix SC2329 scope
> https://lore.kernel.org/netdev/20260327024202.111655-1-dqfext@gmail.com/
At most one version every 24h, please:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr
--
pv-bot: cr
^ permalink raw reply
* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: fengchengwen @ 2026-03-28 2:21 UTC (permalink / raw)
To: Zhiping Zhang, Jason Gunthorpe, Leon Romanovsky, Bjorn Helgaas,
linux-rdma, linux-pci, netdev, dri-devel, Keith Busch,
Yochai Cohen, Yishai Hadas
Cc: Bjorn Helgaas
In-Reply-To: <20260324234615.3731237-2-zhipingz@meta.com>
Hi Zhiping,
On 3/25/2026 7:46 AM, Zhiping Zhang wrote:
> This patch adds a callback to get the tph info on DMA buffer exporters.
> The tph info includes both the steering tag and the process hint (ph).
>
> The steering tag and ph are encoded in the flags field of
> vfio_device_feature_dma_buf instead of adding new fields to the uapi
> struct, to preserve ABI compatibility.
>
> Signed-off-by: Zhiping Zhang <zhipingz@meta.com>
> ---
> drivers/vfio/pci/vfio_pci_dmabuf.c | 26 ++++++++++++++++++++++++--
> include/linux/dma-buf.h | 30 ++++++++++++++++++++++++++++++
> include/uapi/linux/vfio.h | 9 +++++++--
> 3 files changed, 61 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> index 478beafc6ac3..c45cb3884b85 100644
> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> @@ -17,6 +17,8 @@ struct vfio_pci_dma_buf {
> struct phys_vec *phys_vec;
> struct p2pdma_provider *provider;
> u32 nr_ranges;
> + u16 steering_tag;
> + u8 ph;
> u8 revoked : 1;
> };
>
> @@ -60,6 +62,15 @@ vfio_pci_dma_buf_map(struct dma_buf_attachment *attachment,
> priv->size, dir);
> }
>
> +static int vfio_pci_dma_buf_get_tph(struct dma_buf *dmabuf, u16 *steering_tag,
> + u8 *ph)
> +{
> + struct vfio_pci_dma_buf *priv = dmabuf->priv;
> + *steering_tag = priv->steering_tag;
> + *ph = priv->ph;
If the dmabuf exporter don't provide st&ph, this ops should return error
> + return 0;
> +}
> +
> static void vfio_pci_dma_buf_unmap(struct dma_buf_attachment *attachment,
> struct sg_table *sgt,
> enum dma_data_direction dir)
> @@ -90,6 +101,7 @@ static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
> .unpin = vfio_pci_dma_buf_unpin,
> .attach = vfio_pci_dma_buf_attach,
> .map_dma_buf = vfio_pci_dma_buf_map,
> + .get_tph = vfio_pci_dma_buf_get_tph,
> .unmap_dma_buf = vfio_pci_dma_buf_unmap,
> .release = vfio_pci_dma_buf_release,
> };
> @@ -228,7 +240,10 @@ int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags,
> if (copy_from_user(&get_dma_buf, arg, sizeof(get_dma_buf)))
> return -EFAULT;
>
> - if (!get_dma_buf.nr_ranges || get_dma_buf.flags)
> + if (!get_dma_buf.nr_ranges ||
> + (get_dma_buf.flags & ~(VFIO_DMABUF_FL_TPH |
> + VFIO_DMABUF_TPH_PH_MASK |
> + VFIO_DMABUF_TPH_ST_MASK)))
> return -EINVAL;
>
> /*
> @@ -285,7 +300,14 @@ int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags,
> ret = PTR_ERR(priv->dmabuf);
> goto err_dev_put;
> }
> -
> + if (get_dma_buf.flags & VFIO_DMABUF_FL_TPH) {
> + priv->steering_tag = (get_dma_buf.flags &
> + VFIO_DMABUF_TPH_ST_MASK) >>
> + VFIO_DMABUF_TPH_ST_SHIFT;
> + priv->ph = (get_dma_buf.flags &
> + VFIO_DMABUF_TPH_PH_MASK) >>
> + VFIO_DMABUF_TPH_PH_SHIFT;
> + }
> /* dma_buf_put() now frees priv */
> INIT_LIST_HEAD(&priv->dmabufs_elm);
> down_write(&vdev->memory_lock);
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 133b9e637b55..26705c83ad80 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -113,6 +113,36 @@ struct dma_buf_ops {
> */
> void (*unpin)(struct dma_buf_attachment *attach);
>
> + /**
> + * @get_tph:
> + *
> + * Get the TPH (TLP Processing Hints) for this DMA buffer.
> + *
> + * This callback allows DMA buffer exporters to provide TPH including
> + * both the steering tag and the process hints (ph), which can be used
> + * to optimize peer-to-peer (P2P) memory access. The TPH info is typically
> + * used in scenarios where:
> + * - A PCIe device (e.g., RDMA NIC) needs to access memory on another
> + * PCIe device (e.g., GPU),
> + * - The system supports TPH and can use steering tags / ph to optimize
> + * cache placement and memory access patterns,
> + * - The memory is exported via DMABUF for cross-device sharing.
> + *
> + * @dmabuf: [in] The DMA buffer for which to retrieve TPH
> + * @steering_tag: [out] Pointer to store the 16-bit TPH steering tag value
> + * @ph: [out] Pointer to store the 8-bit TPH processing-hint value
> + *
> + * Returns:
> + * * 0 - Success, steering tag stored in @steering_tag
> + * * -EOPNOTSUPP - TPH steering tags not supported for this buffer
> + * * -EINVAL - Invalid parameters
> + *
> + * This callback is optional. If not implemented, the buffer does not
> + * support TPH.
It seemed already impl...
> + *
> + */
> + int (*get_tph)(struct dma_buf *dmabuf, u16 *steering_tag, u8 *ph);
> +
> /**
> * @map_dma_buf:
> *
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index bb7b89330d35..e2a8962641d2 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -1505,8 +1505,13 @@ struct vfio_region_dma_range {
> struct vfio_device_feature_dma_buf {
> __u32 region_index;
> __u32 open_flags;
> - __u32 flags;
> - __u32 nr_ranges;
> + __u32 flags;
> +#define VFIO_DMABUF_FL_TPH (1U << 0) /* TPH info is present */
> +#define VFIO_DMABUF_TPH_PH_SHIFT 1 /* bits 1-2: PH (2-bit) */
> +#define VFIO_DMABUF_TPH_PH_MASK 0x6U
> +#define VFIO_DMABUF_TPH_ST_SHIFT 16 /* bits 16-31: steering tag */
> +#define VFIO_DMABUF_TPH_ST_MASK 0xffff0000U
> + __u32 nr_ranges;
> struct vfio_region_dma_range dma_ranges[] __counted_by(nr_ranges);
> };
Another question:
1\ PCIE protocol define 8bit and 16bit ST
2\ In host-device ST impl, the ACPI will provide 8bit and 16bit ST, the choice of which
one to use depends on the minimum supported range of the device and the RP.
3\ So in this P2P scene, although exporter (e.g. GPU) support 16bit ST, but the consumer
(e.g. RDMA NIC) only support 8bit this may lead to mis-match
>
> --
> 2.52.0
>
>
>
^ permalink raw reply
* Re: [PATCH v8 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-03-28 0:42 UTC (permalink / raw)
To: David Laight
Cc: Borislav Petkov, x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin,
Josh Poimboeuf, David Kaplan, Sean Christopherson, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
Andy Lutomirski, Thomas Gleixner, Ingo Molnar, David Ahern,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, Stanislav Fomichev, Hao Luo, Paolo Bonzini,
Jonathan Corbet, linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf,
netdev, linux-doc
In-Reply-To: <20260326202931.wlggnd3nfj6hngpb@desk>
On Thu, Mar 26, 2026 at 01:29:31PM -0700, Pawan Gupta wrote:
> On Thu, Mar 26, 2026 at 10:45:57AM +0000, David Laight wrote:
> > On Thu, 26 Mar 2026 11:01:20 +0100
> > Borislav Petkov <bp@alien8.de> wrote:
> >
> > > On Thu, Mar 26, 2026 at 01:39:34AM -0700, Pawan Gupta wrote:
> > > > I believe the equivalent for cpu_feature_enabled() in asm is the
> > > > ALTERNATIVE. Please let me know if I am missing something.
> > >
> > > Yes, you are.
> > >
> > > The point is that you don't want to stick those alternative calls inside some
> > > magic bhb_loop function but hand them in from the outside, as function
> > > arguments.
> > >
> > > Basically what I did.
> > >
> > > Then you were worried about this being C code and it had to be noinstr... So
> > > that outer function can be rewritten in asm, I think, and still keep it well
> > > separate.
> > >
> > > I'll try to rewrite it once I get a free minute, and see how it looks.
> > >
> >
> > I think someone tried getting C code to write the values to global data
> > and getting the asm to read them.
> > That got discounted because it spilt things between two largely unrelated files.
>
>
> The implementation with global variables wasn't that bad, let me revive it.
>
> This part which ties sequence to BHI mitigation, which is not ideal,
> (because VMSCAPE also uses it) it does seems a cleaner option.
>
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -2095,6 +2095,11 @@ static void __init bhi_select_mitigation(void)
>
> static void __init bhi_update_mitigation(void)
> {
> + if (!cpu_feature_enabled(X86_FEATURE_BHI_CTRL)) {
> + bhi_seq_outer_loop = 5;
> + bhi_seq_inner_loop = 5;
> + }
> +
>
> I believe this can be moved to somewhere common to all mitigations.
>
> > I think the BPF code would need significant refactoring to call a C function.
>
> Ya, true. Will use globals and keep clear_bhb_loop() in asm.
While testing this approach, I noticed that syscalls were suffering an 8%
regression on ICX for Native BHI mitigation:
$ perf bench syscall basic -l 100000000
Bisection pointed to the change for using 8-bit registers (al/ah replacing
eax/ecx) as the main contributor to the regression. (Global variables added
a bit, but within noise).
Further digging revealed a strange behavior, using %ah for the inner loop
was causing the regression, interchanging %al and %ah in the loops
(for movb and sub) eliminated the regression.
<clear_bhb_loop_nofence>:
movb bhb_seq_outer_loop(%rip), %al
call 1f
jmp 5f
1: call 2f
.Lret1: RET
2: movb bhb_seq_inner_loop(%rip), %ah
3: jmp 4f
nop
4: sub $1, %ah <---- No regression with %al here
jnz 3b
sub $1, %al
jnz 1b
My guess is, "sub $1, %al" is faster than "sub $1, %ah". Using %al in the
inner loop, which is executed more number of times is likely making the
difference. A perf profile is needed to confirm this.
Never imagined a register selection can make an 8% difference in
performance! Anyways, will update the patch with this finding.
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH net-next v2] net: mana: Set default number of queues to 16
From: Long Li @ 2026-03-28 0:41 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Konstantin Taranov, David S . Miller, Paolo Abeni, Eric Dumazet,
Andrew Lunn, Jason Gunthorpe, Leon Romanovsky, Haiyang Zhang,
KY Srinivasan, Wei Liu, Dexuan Cui, Simon Horman,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260327165512.08f7b6f9@kernel.org>
> On Fri, 27 Mar 2026 04:00:31 +0000 Long Li wrote:
> > We considered netif_get_num_default_rss_queues() but chose a fixed
> default based on our performance testing. On Azure VMs, typical
> > workloads plateau at around 16 queues - adding more queues beyond that
> doesn't improve throughput but increases memory usage and
> > interrupt overhead.
> >
> > netif_get_num_default_rss_queues() would return 32-64 on large VMs
> (64-128 vCPUs), which wastes resources without benefit.
> >
> > That said, I agree that completely ignoring the core-based heuristic isn't
> ideal for consistency. One option is to use
> > netif_get_num_default_rss_queues() but clamp it to a maximum of
> MANA_DEF_NUM_QUEUES (16), so small VMs still get enough queues and
> > large VMs don't over-allocate. Something like:
> >
> > apc->num_queues = min(netif_get_num_default_rss_queues(),
> MANA_DEF_NUM_QUEUES);
> > apc->num_queues = min(apc->num_queues, gc->max_num_queues);
> >
> > For reference, it seems mlx4 does something similar - it caps at
> DEF_RX_RINGS (16) regardless of core count.
>
> mlx4 is a bit ancient. And mlx5 does the wrong thing, which is why I'm so
> sensitive to this issue :(
>
> > Do you want me to send a v2?
>
> Please send a follow up, let's leave this patch be and make an incremental
> change.
>
> Thanks!
I will send a follow-up patch.
Thanks,
Long
^ permalink raw reply
* Re: [PATCH net] net/x25: Fix overflow when accumulating packets
From: Jakub Kicinski @ 2026-03-28 0:33 UTC (permalink / raw)
To: Martin Schiller
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Yiming Qian,
linux-x25, netdev, linux-kernel, security
In-Reply-To: <b2099069e5dce49a0bc068a8d318f3a2@dev.tdt.de>
On Fri, 27 Mar 2026 09:36:00 +0100 Martin Schiller wrote:
> > + /* make sure we don't overflow */
> > + if (x25->fraglen + skb->len > sizeof(x25->fraglen)) {
>
> Please ignore this patch. I'll send a V2 without that
> "sizeof()" nonsense in a moment.
We ask that submitters wait 24h before reposting:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr
--
pv-bot: 24h
^ permalink raw reply
* Re: [PATCH net-next v6 0/6] TLS read_sock performance scalability
From: Jakub Kicinski @ 2026-03-28 0:26 UTC (permalink / raw)
To: Chuck Lever
Cc: john.fastabend, Sabrina Dubroca, netdev, kernel-tls-handshake,
Chuck Lever, Hannes Reinecke, Alistair Francis
In-Reply-To: <722ffab1-f3d8-4309-afa0-482d64ae3a33@app.fastmail.com>
On Fri, 27 Mar 2026 09:35:09 -0400 Chuck Lever wrote:
> On Thu, Mar 26, 2026, at 8:54 PM, Jakub Kicinski wrote:
> > On Thu, 26 Mar 2026 09:50:45 -0400 Chuck Lever wrote:
> >> I'd like to encourage in-kernel kTLS consumers (i.e., NFS and
> >> NVMe/TCP) to coalesce on the use of read_sock. When I suggested
> >> this to Hannes, he reported a number of nagging performance
> >> scalability issues with read_sock. This series is an attempt to
> >> run these issues down and get them fixed before we convert the
> >> above sock_recvmsg consumers over to read_sock.
> >>
> >> Batch async decryption and its submit/deliver scaffolding were
> >> dropped from this series because async_capable is always false
> >> for TLS 1.3, which NFS and NVMe/TCP both require. Async crypto
> >> support for TLS 1.3 is a prerequisite for revisiting that work.
> >
> > Please repost the remaining 5 patches
>
> To make sure I understand your request, do you mean the TLS-related
> patches that are pre-requisites for Alistair's KeyUpdate series?
Oh, no, sorry, we merged patch 1 as a Fix and shipped it to Linus.
I meant to ask for you to fetch net-next, rebase and repost.
Patch 1 should "disappear" (unless I messed something up)
^ permalink raw reply
* Re: [PATCH net-next v4 00/10] selftests: drivers: bash support for remote traffic generators
From: Jakub Kicinski @ 2026-03-28 0:24 UTC (permalink / raw)
To: Ioana Ciornei
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, linux-kernel, petrm, willemb, linux-kselftest
In-Reply-To: <5cuoazp2svgjja5h663zc34dafkuqa2grrm7lzpuunvrjogydf@43mryp77gq2q>
On Fri, 27 Mar 2026 09:32:22 +0200 Ioana Ciornei wrote:
> On Thu, Mar 26, 2026 at 12:03:42PM -0700, Jakub Kicinski wrote:
> > On Thu, 26 Mar 2026 15:28:18 +0200 Ioana Ciornei wrote:
> > > This patch set aims to add the necessary support so that bash written
> > > selftests are also able to easily run with a remote traffic generator
> > > system, either be it in another netns or one accessible through ssh.
> > >
> > > This patch set is a result of the discussion from v1:
> > > https://lore.kernel.org/all/20260303084330.340b6459@kernel.org/
> > > Even though the python infrastructure is already established, some
> > > things are easier in bash and it would be a shame to leave behind the
> > > bash tests that we already have.
> >
> > I think this introduces a bunch of regressions, eg:
> >
> > https://netdev-ctrl.bots.linux.dev/logs/vmksft/forwarding/results/575622/4-local-termination-sh/stdout
> >
> > https://netdev-ctrl.bots.linux.dev/logs/vmksft/netdevsim/results/575802/18-netcons-resume-sh/stdout
>
> I cannot reproduce this unfortunately. For example, local_termination.sh
> gives me the following result with the exact patches that I submitted.
> Any idea on what might be the difference?
Hm, the system that runs this on our end is:
# cat /etc/redhat-release
Fedora release 43 (Forty Three)
And it has this added on top of default install:
# cat /etc/systemd/network/99-default.link
[Match]
OriginalName=*
[Link]
NamePolicy=keep kernel database onboard slot path
AlternativeNamesPolicy=database onboard slot path mac
MACAddressPolicy=none
^ permalink raw reply
* Re: [PATCH v1 net-next] tun: Ignore tun in netdev_lock_pos().
From: Eric Dumazet @ 2026-03-28 0:19 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Kuniyuki Iwashima, David S. Miller, Jakub Kicinski, Paolo Abeni,
Jason Wang, Andrew Lunn, Simon Horman, Kuniyuki Iwashima, netdev
In-Reply-To: <willemdebruijn.kernel.64bceda776b2@gmail.com>
On Fri, Mar 27, 2026 at 4:16 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> Kuniyuki Iwashima wrote:
> > On Fri, Mar 27, 2026 at 2:48 PM Eric Dumazet <edumazet@google.com> wrote:
> > >
> > > On Fri, Mar 27, 2026 at 2:34 PM Kuniyuki Iwashima <kuniyu@google.com> wrote:
> > > >
> > > > dev->type could be any value on tun due to TUNSETLINK.
> > > >
> > > > Let's not warn about it in netdev_lock_pos().
> > > >
> > > > Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
> > >
> > > Hmmm... should we instead have a list of supported types ?
> > >
> > > And reject user space requests for unsupported ones ?
> >
> > I chose a safer way but maybe we could reuse tun_get_addr_len()
> > and define the default case there as unsupported ?
> >
> > I guess it's okay even if it breaks userspace because we can
> > just add a single line to restore the support.
>
> We shouldn't risk breaking userspace, over such a sanity check.
The thing is : this check makes sure that each type has a different
lockdep class.
>
> Presumably any truly newly added type will have a non-zero addr_len.
> While tun sets this to zero for weird inputs. Maybe just filter on
> that in the WARN_ONCE?
Then we might hit some lockdep issues...
Perhaps use lockdep_register_key() on each tun device...
^ permalink raw reply
* Re: [PATCH net] bridge: mrp: reject zero test interval to avoid OOM panic
From: Jakub Kicinski @ 2026-03-28 0:19 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Simon Horman, Xiang Mei, netdev, bridge, idosch, davem, edumazet,
pabeni, bestswngs
In-Reply-To: <f7fea291-bde9-4f95-8a59-1b209407ee27@blackwall.org>
On Fri, 27 Mar 2026 13:46:39 +0200 Nikolay Aleksandrov wrote:
> On 27/03/2026 13:34, Simon Horman wrote:
> > On Wed, Mar 25, 2026 at 08:24:38PM -0700, Xiang Mei wrote:
> >> br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
> >> interval value from netlink without validation. When interval is 0,
> >> usecs_to_jiffies(0) yields 0, causing the delayed work
> >> (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
> >> itself with zero delay. This creates a tight loop on system_percpu_wq
> >> that allocates and transmits MRP test frames at maximum rate, exhausting
> >> all system memory and causing a kernel panic via OOM deadlock.
> >
> > I would suspect the primary outcome of this problem is high CPU consumption
> > rather than memory exhaustion. Is there a reason to expect that
> > the transmitted fames can't be consumed as fast as they are created?
>
> +1
> More so with CAP_NET_ADMIN you can cause all sorts of OOM and high-cpu usage
> conditions. This is a configuration error and OOM doesn't lead to panic unless
> instructed to. I don't think this is worth changing at all.
Then again if there's no practical use for 0 we should consider
the risk of getting this sort of submission over and over again?
Dunno..
^ 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