* [PATCH ipsec v2] xfrm: cleanup error path in xfrm_add_policy()
From: Deepanshu Kartikey @ 2026-04-13 14:35 UTC (permalink / raw)
To: steffen.klassert, herbert, davem, edumazet, kuba, pabeni, horms,
sd
Cc: netdev, linux-kernel, Deepanshu Kartikey,
syzbot+901d48e0b95aed4a2548
Replace the open-coded manual cleanup in the error path of
xfrm_add_policy() with xfrm_policy_destroy(), which already
handles all the necessary cleanup internally. This is consistent
with how xfrm_policy_construct() handles its own error paths.
The walk.dead flag must be set before calling xfrm_policy_destroy()
as required by BUG_ON(!policy->walk.dead).
Tested-by: syzbot+901d48e0b95aed4a2548@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
v2:
- Reworded commit message to reflect cleanup rather than bugfix
as suggested by Sabrina Dubroca
- Removed incorrect Fixes: and Closes: tags
- Corrected subject prefix to "PATCH ipsec"
---
net/xfrm/xfrm_user.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index d56450f61669..ae144d1e4a65 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2267,9 +2267,8 @@ static int xfrm_add_policy(struct sk_buff *skb, struct nlmsghdr *nlh,
if (err) {
xfrm_dev_policy_delete(xp);
- xfrm_dev_policy_free(xp);
- security_xfrm_policy_free(xp->security);
- kfree(xp);
+ xp->walk.dead = 1;
+ xfrm_policy_destroy(xp);
return err;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] net/sched: sch_cake: fix NAT destination port not being updated in cake_update_flowkeys
From: Toke Høiland-Jørgensen @ 2026-04-13 14:40 UTC (permalink / raw)
To: Dudu Lu, netdev; +Cc: jhs, jiri, Dudu Lu
In-Reply-To: <20260413110041.44704-1-phx0fer@gmail.com>
Dudu Lu <phx0fer@gmail.com> writes:
> cake_update_flowkeys() is supposed to update the flow dissector keys
> with the NAT-translated addresses and ports from conntrack, so that
> CAKE's per-flow fairness correctly identifies post-NAT flows as
> belonging to the same connection.
>
> For the source port, this works correctly:
> keys->ports.src = port;
>
> But for the destination port, the assignment is reversed:
> port = keys->ports.dst;
>
> This means the NAT destination port is never updated in the flow keys.
> As a result, when multiple connections are NATed to the same destination,
> CAKE treats them as separate flows because the original (pre-NAT)
> destination ports differ. This breaks CAKE's NAT-aware flow isolation
> when using the "nat" mode.
>
> The bug was introduced in commit b0c19ed6088a ("sch_cake: Take advantage
> of skb->hash where appropriate") which refactored the original direct
> assignment into a compare-and-conditionally-update pattern, but wrote
> the destination port update backwards.
>
> Fix by reversing the assignment direction to match the source port
> pattern.
>
> Fixes: b0c19ed6088a ("sch_cake: Take advantage of skb->hash where appropriate")
> Signed-off-by: Dudu Lu <phx0fer@gmail.com>
Thank you for the fix!
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
^ permalink raw reply
* Re: [PATCH 5.10.y] Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold
From: Greg KH @ 2026-04-13 14:43 UTC (permalink / raw)
To: Jianqiang kang
Cc: stable, imv4bel, patches, linux-kernel, marcel, johan.hedberg,
luiz.dentz, davem, kuba, linux-bluetooth, netdev, luiz.von.dentz
In-Reply-To: <20260409074429.740279-1-jianqkang@sina.cn>
On Thu, Apr 09, 2026 at 03:44:29PM +0800, Jianqiang kang wrote:
> From: Hyunwoo Kim <imv4bel@gmail.com>
>
> [ Upstream commit 598dbba9919c5e36c54fe1709b557d64120cb94b ]
>
> sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately
> releases the lock without holding a reference to the socket. A concurrent
> close() can free the socket between the lock release and the subsequent
> sk->sk_state access, resulting in a use-after-free.
>
> Other functions in the same file (sco_sock_timeout(), sco_conn_del())
> correctly use sco_sock_hold() to safely hold a reference under the lock.
>
> Fix by using sco_sock_hold() to take a reference before releasing the
> lock, and adding sock_put() on all exit paths.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> Signed-off-by: Jianqiang kang <jianqkang@sina.cn>
> ---
> net/bluetooth/sco.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
This breaks the build, how was it tested?
confused,
greg k-h
^ permalink raw reply
* Re: [patch 32/38] powerpc/spufs: Use mftb() directly
From: Arnd Bergmann @ 2026-04-13 14:43 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Michael Ellerman, linuxppc-dev, x86, Baolu Lu, iommu,
Michael Grzeschik, Netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka (SUSE), linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Ts'o, linux-ext4,
Andrew Morton, Uladzislau Rezki (Sony), Marco Elver,
Dmitry Vyukov, kasan-dev, Andrey Ryabinin, Thomas Sailer,
linux-hams, Jason A . Donenfeld, Richard Henderson, linux-alpha,
Russell King, linux-arm-kernel, Catalin Marinas, Huacai Chen,
loongarch, Geert Uytterhoeven, linux-m68k, Dinh Nguyen,
Jonas Bonn, linux-openrisc@vger.kernel.org, Helge Deller,
linux-parisc, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390, David S . Miller, sparclinux
In-Reply-To: <20260410120319.723429844@kernel.org>
On Fri, Apr 10, 2026, at 14:21, Thomas Gleixner wrote:
> There is no reason to indirect via get_cycles(), which is about to be
> removed.
>
> Use mftb() directly.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [patch 38/38] treewide: Remove asm/timex.h includes from generic code
From: Arnd Bergmann @ 2026-04-13 14:45 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: x86, Baolu Lu, iommu, Michael Grzeschik, Netdev, linux-wireless,
Herbert Xu, linux-crypto, Vlastimil Babka (SUSE), linux-mm,
David Woodhouse, Bernie Thompson, linux-fbdev, Theodore Ts'o,
linux-ext4, Andrew Morton, Uladzislau Rezki (Sony), Marco Elver,
Dmitry Vyukov, kasan-dev, Andrey Ryabinin, Thomas Sailer,
linux-hams, Jason A . Donenfeld, Richard Henderson, linux-alpha,
Russell King, linux-arm-kernel, Catalin Marinas, Huacai Chen,
loongarch, Geert Uytterhoeven, linux-m68k, Dinh Nguyen,
Jonas Bonn, linux-openrisc@vger.kernel.org, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S . Miller,
sparclinux
In-Reply-To: <20260410120320.163559629@kernel.org>
On Fri, Apr 10, 2026, at 14:21, Thomas Gleixner wrote:
> asm/timex.h does not provide any functionality for non-architecture code
> anymore.
>
> Remove the asm-generic fallback and all references in include and source
> files along with the random_get_entropy() #ifdeffery in timex.h.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> ---
> include/asm-generic/Kbuild | 1 -
> include/asm-generic/timex.h | 15 ---------------
> include/linux/random.h | 3 +++
> include/linux/timex.h | 26 --------------------------
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v4] net/mlx5: Fix OOB access and stack information leak in PTP event handling
From: Leon Romanovsky @ 2026-04-13 14:46 UTC (permalink / raw)
To: Prathamesh Deshpande
Cc: Carolina Jubran, Saeed Mahameed, Richard Cochran, Tariq Toukan,
Mark Bloch, netdev, linux-rdma, linux-kernel
In-Reply-To: <20260412000418.8415-1-prathameshdeshpande7@gmail.com>
On Sun, Apr 12, 2026 at 01:04:10AM +0100, Prathamesh Deshpande wrote:
> In mlx5_pps_event(), several critical issues were identified:
>
> 1. The 'pin' index from the hardware event was used without bounds
> checking to index 'pin_config' and 'pps_info->start'. Check against
> MAX_PIN_NUM to prevent out-of-bounds access.
You were told more than once that this is impossible.
<...>
> + if (WARN_ON_ONCE(pin >= MAX_PIN_NUM))
> + return NOTIFY_OK;
Let's not add useless checks in fast path.
Thanks
^ permalink raw reply
* Re: [PATCH net v1 1/2] nexthop: fix IPv6 route referencing IPv4 nexthop
From: David Ahern @ 2026-04-13 14:46 UTC (permalink / raw)
To: Jiayuan Chen, netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan, linux-kernel, linux-kselftest
In-Reply-To: <20260413114522.147784-1-jiayuan.chen@linux.dev>
On 4/13/26 5:45 AM, Jiayuan Chen wrote:
> syzbot reported a panic [1] [2].
>
> When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag
> of all groups containing this nexthop is not updated. This is because
> nh_group_v4_update is only called when replacing AF_INET to AF_INET6,
> but the reverse direction (AF_INET6 to AF_INET) is missed.
>
> This allows a stale has_v4=false to bypass fib6_check_nexthop, causing
> IPv6 routes to be attached to groups that effectively contain only AF_INET
> members. Subsequent route lookups then call nexthop_fib6_nh() which
> returns NULL for the AF_INET member, leading to a NULL pointer
> dereference.
>
> Fix by calling nh_group_v4_update whenever the family changes, not just
> AF_INET to AF_INET6.
>
> Reproducer:
> # AF_INET6 blackhole
> ip -6 nexthop add id 1 blackhole
> # group with has_v4=false
> ip nexthop add id 100 group 1
> # replace with AF_INET (no -6), has_v4 stays false
> ip nexthop replace id 1 blackhole
> # pass stale has_v4 check
> ip -6 route add 2001:db8::/64 nhid 100
> # panic
> ping -6 2001:db8::1
>
> [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0
> [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3
> Fixes: 7bf4796dd099 ("nexthops: add support for replace")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
> net/ipv4/nexthop.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: [patch 17/38] ext4: Replace get_cycles() usage with ktime_get()
From: Arnd Bergmann @ 2026-04-13 14:46 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Theodore Ts'o, linux-ext4, x86, Baolu Lu, iommu,
Michael Grzeschik, Netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka (SUSE), linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Andrew Morton,
Uladzislau Rezki (Sony), Marco Elver, Dmitry Vyukov, kasan-dev,
Andrey Ryabinin, Thomas Sailer, linux-hams, Jason A . Donenfeld,
Richard Henderson, linux-alpha, Russell King, linux-arm-kernel,
Catalin Marinas, Huacai Chen, loongarch, Geert Uytterhoeven,
linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc@vger.kernel.org, Helge Deller, linux-parisc,
Michael Ellerman, linuxppc-dev, Paul Walmsley, linux-riscv,
Heiko Carstens, linux-s390, David S . Miller, sparclinux
In-Reply-To: <20260410120318.727211419@kernel.org>
On Fri, Apr 10, 2026, at 14:19, Thomas Gleixner wrote:
> get_cycles() is not guaranteed to be functional on all systems/platforms
> and the values returned are unitless and not easy to map to something
> useful.
>
> Use ktime_get() instead, which provides nanosecond timestamps and is
> functional everywhere.
>
> This is part of a larger effort to limit get_cycles() usage to low level
> architecture code.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: "Theodore Ts'o" <tytso@mit.edu>
> Cc: linux-ext4@vger.kernel.org
I think this is technically an ABI chance, since the time
difference gets exported through procfs, but the new version
is clearly the right thing to do since it replaces a hardware
specific value with a portable one.
Arnd
^ permalink raw reply
* Re: [PATCH net v1 2/2] selftests: fib_nexthops: test stale has_v4 on nexthop replace
From: David Ahern @ 2026-04-13 14:47 UTC (permalink / raw)
To: Jiayuan Chen, netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Shuah Khan, linux-kernel, linux-kselftest
In-Reply-To: <20260413114522.147784-2-jiayuan.chen@linux.dev>
On 4/13/26 5:45 AM, Jiayuan Chen wrote:
> Add test cases that exercise the scenario where an IPv6 nexthop is
> replaced with an IPv4 nexthop while being part of a group. The group's
> has_v4 flag must be updated so that subsequent IPv6 route additions are
> properly rejected.
>
> Two cases are covered:
> 1. Gateway nexthop replaced across families with an existing IPv6
> route on the group (rejected by fib6_check_nh_list).
> 2. Blackhole nexthop replaced across families with no existing IPv6
> route on the group (fib6_check_nh_list returns early) — this is
> the path that triggers a NULL ptr deref without the kernel fix.
>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
> tools/testing/selftests/net/fib_nexthops.sh | 22 +++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: [GIT PULL] bluetooth-next 2026-04-13
From: Paolo Abeni @ 2026-04-13 14:56 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <CABBYNZ+7zr1jQ7a-2p88zNqMdvn6MAB5NAZ7b4OW=P56DcMT5g@mail.gmail.com>
On 4/13/26 4:17 PM, Luiz Augusto von Dentz wrote:
> On Mon, Apr 13, 2026 at 10:11 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> On Mon, Apr 13, 2026 at 9:41 AM Paolo Abeni <pabeni@redhat.com> wrote:
>>>
>>> On 4/13/26 3:22 PM, Luiz Augusto von Dentz wrote:
>>>> The following changes since commit 42f9b4c6ef19e71d2c7d9bfd3c5037d4fe434ad7:
>>>>
>>>> tools: ynl: tests: fix leading space on Makefile target (2026-04-09 20:41:40 -0700)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git tags/for-net-next-2026-04-13
>>>>
>>>> for you to fetch changes up to c347ca17d62a32c25564fee0ca3a2a7bc2d5fd6f:
>>>>
>>>> Bluetooth: hci_qca: Fix missing wakeup during SSR memdump handling (2026-04-13 09:19:42 -0400)
>>>>
>>>> ----------------------------------------------------------------
>>>> bluetooth-next pull request for net-next:
>>>
>>> Net-next is closed for the merge window. I guess Jakub could still
>>> consider merging this, but unless you want it very, very badly, I hope
>>> it can just be postponed, as the PW queue is already long.
>>
>> This update includes quite a few new hardware supports. This is a
>> resend because the last one was dropped due to an invalid 'Fixes' tag.
>>
>> Btw, I don't know why the entire PR needs to be dropped if only a few
>> items have invalid tags? Can't we just dropped those?
>
> Maybe Im doing something wrong in my side, the issue with the Fixes
> that is that sometimes they become invalid once I rebase on top of
> net-next, which, afaik, is necessary to detect already applied
> patches. Or is rebasing is not really necessary and should only be
> done once when rc1 is tagged?
AFAICT, rebasing is needed if you have local patches not present in the
tree that you are pulling from.
If you e.g. send a PR to net-next, including all the patches present in
your devel tree ATM, you could avoid the later rebase not applying any
patch in your tree until you merge net-next back.
Would that doable for you?
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH iwl-next 1/1] igc: add support for forcing link speed without autonegotiation
From: Simon Horman @ 2026-04-13 14:52 UTC (permalink / raw)
To: khai.wen.tan
Cc: 'Simon Horman', anthony.l.nguyen, przemyslaw.kitszel,
andrew+netdev, davem, edumazet, kuba, pabeni, intel-wired-lan,
netdev, linux-kernel, faizal.abdul.rahim, hector.blanco.alcaine,
hong.aun.looi, khai.wen.tan, faizal.abdul.rahim
In-Reply-To: <20260409072747.217836-1-khai.wen.tan@linux.intel.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
igc: add support for forcing link speed without autonegotiation
This commit allows forcing 10/100 Mb/s link speed and duplex settings via
ethtool when autonegotiation is disabled. It configures the MAC CTRL and
PHY registers to bypass autonegotiation and apply the requested settings.
> diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c
> index 0122009bedd03..e14771532dad8 100644
> --- a/drivers/net/ethernet/intel/igc/igc_ethtool.c
> +++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c
[ ... ]
> +static int igc_handle_autoneg_disabled(struct net_device *netdev, u32 speed,
> + u8 duplex)
> +{
> + struct igc_adapter *adapter = netdev_priv(netdev);
> + struct igc_mac_info *mac = &adapter->hw.mac;
> + enum igc_forced_speed_duplex forced_speed_duplex;
>
> + switch (speed) {
> + case SPEED_10:
> + forced_speed_duplex = (duplex == DUPLEX_FULL) ? IGC_FORCED_10F : IGC_FORCED_10H;
> + break;
> + case SPEED_100:
> + forced_speed_duplex = (duplex == DUPLEX_FULL) ? IGC_FORCED_100F : IGC_FORCED_100H;
> + break;
Does forcing a half-duplex configuration here also require setting flow
control to none (e.g., hw->fc.requested_mode = igc_fc_none)?
> diff --git a/drivers/net/ethernet/intel/igc/igc_mac.c b/drivers/net/ethernet/intel/igc/igc_mac.c
> index 7ac6637f8db73..16b0f2db06896 100644
> --- a/drivers/net/ethernet/intel/igc/igc_mac.c
> +++ b/drivers/net/ethernet/intel/igc/igc_mac.c
> @@ -452,7 +452,7 @@ s32 igc_config_fc_after_link_up(struct igc_hw *hw)
> * so we had to force link. In this case, we need to force the
> * configuration of the MAC to match the "fc" parameter.
> */
> - if (mac->autoneg_failed)
> + if (mac->autoneg_failed || !mac->autoneg_enabled)
> ret_val = igc_force_mac_fc(hw);
If mac->autoneg_enabled is false, igc_force_mac_fc() will configure the MAC
using the existing hw->fc.current_mode. If current_mode defaults to full flow
control, this will enable PAUSE frames.
Since autonegotiation is disabled, the MII status check further down in this
same function will fail and return early:
drivers/net/ethernet/intel/igc/igc_mac.c:igc_config_fc_after_link_up() {
...
if (!(mii_status_reg & MII_SR_AUTONEG_COMPLETE)) {
hw_dbg("Copper PHY and Auto Neg has not completed.\n");
goto out;
}
...
}
This early return skips the half-duplex safety check at the end of
igc_config_fc_after_link_up() which would normally clear the flow control
settings:
drivers/net/ethernet/intel/igc/igc_mac.c:igc_config_fc_after_link_up() {
...
if (duplex == HALF_DUPLEX)
hw->fc.current_mode = igc_fc_none;
ret_val = igc_force_mac_fc(hw);
...
}
Does this leave the MAC incorrectly configured to send and receive PAUSE
frames on a half-duplex link, violating the IEEE 802.3 specification?
^ permalink raw reply
* [PATCH] wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit
From: Shardul Bankar @ 2026-04-13 15:00 UTC (permalink / raw)
To: Jason, kuniyu
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, wireguard, netdev,
linux-kernel, janak, kalpan.jani, shardulsb08, Shardul Bankar,
syzbot+pFBD3bslSSshiJCd3rxy
wg_netns_pre_exit() manually acquires rtnl_lock() inside the
pernet .pre_exit callback. This causes a hung task when another
thread holds rtnl_mutex - the cleanup_net workqueue (or the
setup_net failure rollback path) blocks indefinitely in
wg_netns_pre_exit() waiting to acquire the lock.
Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net:
Add ->exit_rtnl() hook to struct pernet_operations."), where the
framework already holds RTNL and batches all callbacks under a
single rtnl_lock()/rtnl_unlock() pair, eliminating the contention
window.
The rcu_assign_pointer(wg->creating_net, NULL) is safe to move
from .pre_exit to .exit_rtnl (which runs after synchronize_rcu())
because all RCU readers of creating_net either use maybe_get_net()
- which returns NULL for a dying namespace with zero refcount - or
access net->user_ns which remains valid throughout the entire
ops_undo_list sequence.
Reported-by: syzbot+pFBD3bslSSshiJCd3rxy@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?id=cb64c22a492202ca929e18262fdb8cb89e635c70
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
---
drivers/net/wireguard/device.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index 46a71ec36af8..eb854c5294a3 100644
--- a/drivers/net/wireguard/device.c
+++ b/drivers/net/wireguard/device.c
@@ -411,12 +411,11 @@ static struct rtnl_link_ops link_ops __read_mostly = {
.newlink = wg_newlink,
};
-static void wg_netns_pre_exit(struct net *net)
+static void wg_netns_exit_rtnl(struct net *net, struct list_head *dev_kill_list)
{
struct wg_device *wg;
struct wg_peer *peer;
- rtnl_lock();
list_for_each_entry(wg, &device_list, device_list) {
if (rcu_access_pointer(wg->creating_net) == net) {
pr_debug("%s: Creating namespace exiting\n", wg->dev->name);
@@ -429,11 +428,10 @@ static void wg_netns_pre_exit(struct net *net)
mutex_unlock(&wg->device_update_lock);
}
}
- rtnl_unlock();
}
static struct pernet_operations pernet_ops = {
- .pre_exit = wg_netns_pre_exit
+ .exit_rtnl = wg_netns_exit_rtnl
};
int __init wg_device_init(void)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit
From: syzbot @ 2026-04-13 15:01 UTC (permalink / raw)
To: shardul.b
Cc: andrew, davem, edumazet, janak, jason, kalpan.jani, kuba, kuniyu,
linux-kernel, netdev, pabeni, shardul.b, shardulsb08, wireguard
In-Reply-To: <20260413150024.1003490-1-shardul.b@mpiricsoftware.com>
> wg_netns_pre_exit() manually acquires rtnl_lock() inside the
> pernet .pre_exit callback. This causes a hung task when another
> thread holds rtnl_mutex - the cleanup_net workqueue (or the
> setup_net failure rollback path) blocks indefinitely in
> wg_netns_pre_exit() waiting to acquire the lock.
>
> Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net:
> Add ->exit_rtnl() hook to struct pernet_operations."), where the
> framework already holds RTNL and batches all callbacks under a
> single rtnl_lock()/rtnl_unlock() pair, eliminating the contention
> window.
>
> The rcu_assign_pointer(wg->creating_net, NULL) is safe to move
> from .pre_exit to .exit_rtnl (which runs after synchronize_rcu())
> because all RCU readers of creating_net either use maybe_get_net()
> - which returns NULL for a dying namespace with zero refcount - or
> access net->user_ns which remains valid throughout the entire
> ops_undo_list sequence.
>
> Reported-by: syzbot+pFBD3bslSSshiJCd3rxy@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?id=cb64c22a492202ca929e18262fdb8cb89e635c70
> Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
> ---
> drivers/net/wireguard/device.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
> index 46a71ec36af8..eb854c5294a3 100644
> --- a/drivers/net/wireguard/device.c
> +++ b/drivers/net/wireguard/device.c
> @@ -411,12 +411,11 @@ static struct rtnl_link_ops link_ops __read_mostly = {
> .newlink = wg_newlink,
> };
>
> -static void wg_netns_pre_exit(struct net *net)
> +static void wg_netns_exit_rtnl(struct net *net, struct list_head *dev_kill_list)
> {
> struct wg_device *wg;
> struct wg_peer *peer;
>
> - rtnl_lock();
> list_for_each_entry(wg, &device_list, device_list) {
> if (rcu_access_pointer(wg->creating_net) == net) {
> pr_debug("%s: Creating namespace exiting\n", wg->dev->name);
> @@ -429,11 +428,10 @@ static void wg_netns_pre_exit(struct net *net)
> mutex_unlock(&wg->device_update_lock);
> }
> }
> - rtnl_unlock();
> }
>
> static struct pernet_operations pernet_ops = {
> - .pre_exit = wg_netns_pre_exit
> + .exit_rtnl = wg_netns_exit_rtnl
> };
>
> int __init wg_device_init(void)
> --
> 2.34.1
>
I see the command but can't find the corresponding bug.
The email is sent to syzbot+HASH@syzkaller.appspotmail.com address
but the HASH does not correspond to any known bug.
Please double check the address.
^ permalink raw reply
* [PATCH v2] wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit
From: Shardul Bankar @ 2026-04-13 15:12 UTC (permalink / raw)
To: Jason, kuniyu
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, wireguard, netdev,
linux-kernel, janak, kalpan.jani, shardulsb08, Shardul Bankar,
syzbot+f2fbf7478a35a94c8b7c
wg_netns_pre_exit() manually acquires rtnl_lock() inside the
pernet .pre_exit callback. This causes a hung task when another
thread holds rtnl_mutex - the cleanup_net workqueue (or the
setup_net failure rollback path) blocks indefinitely in
wg_netns_pre_exit() waiting to acquire the lock.
Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net:
Add ->exit_rtnl() hook to struct pernet_operations."), where the
framework already holds RTNL and batches all callbacks under a
single rtnl_lock()/rtnl_unlock() pair, eliminating the contention
window.
The rcu_assign_pointer(wg->creating_net, NULL) is safe to move
from .pre_exit to .exit_rtnl (which runs after synchronize_rcu())
because all RCU readers of creating_net either use maybe_get_net()
- which returns NULL for a dying namespace with zero refcount - or
access net->user_ns which remains valid throughout the entire
ops_undo_list sequence.
Reported-by: syzbot+f2fbf7478a35a94c8b7c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?id=cb64c22a492202ca929e18262fdb8cb89e635c70
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
---
v2: Fix incorrect Reported-by email address
drivers/net/wireguard/device.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index 46a71ec36af8..eb854c5294a3 100644
--- a/drivers/net/wireguard/device.c
+++ b/drivers/net/wireguard/device.c
@@ -411,12 +411,11 @@ static struct rtnl_link_ops link_ops __read_mostly = {
.newlink = wg_newlink,
};
-static void wg_netns_pre_exit(struct net *net)
+static void wg_netns_exit_rtnl(struct net *net, struct list_head *dev_kill_list)
{
struct wg_device *wg;
struct wg_peer *peer;
- rtnl_lock();
list_for_each_entry(wg, &device_list, device_list) {
if (rcu_access_pointer(wg->creating_net) == net) {
pr_debug("%s: Creating namespace exiting\n", wg->dev->name);
@@ -429,11 +428,10 @@ static void wg_netns_pre_exit(struct net *net)
mutex_unlock(&wg->device_update_lock);
}
}
- rtnl_unlock();
}
static struct pernet_operations pernet_ops = {
- .pre_exit = wg_netns_pre_exit
+ .exit_rtnl = wg_netns_exit_rtnl
};
int __init wg_device_init(void)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/5] selftests: net: add multithread client support to iou-zcrx
From: Juanlu Herrero @ 2026-04-13 15:19 UTC (permalink / raw)
To: David Wei; +Cc: netdev
In-Reply-To: <8fa08d73-28a3-4521-bcfb-ec81869c24f3@davidwei.uk>
On Thu, Apr 09, 2026 at 08:51:11AM -0600, David Wei wrote:
> On 2026-04-08 09:38, Juanlu Herrero wrote:
> > Add pthreads to the iou-zcrx client so that multiple connections can be
> > established simultaneously. Each client thread connects to the server
> > and sends its payload independently.
> >
> > Introduce struct thread_ctx and the -t option to control the number of
> > threads (default 1), preserving backwards compatibility with existing
> > tests.
> >
> > Signed-off-by: Juanlu Herrero <juanlu@fastmail.com>
> > ---
> > .../testing/selftests/drivers/net/hw/Makefile | 2 +-
> > .../selftests/drivers/net/hw/iou-zcrx.c | 46 +++++++++++++++++--
> > 2 files changed, 44 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/testing/selftests/drivers/net/hw/Makefile b/tools/testing/selftests/drivers/net/hw/Makefile
> > index deeca3f8d080..227adfec706c 100644
> > --- a/tools/testing/selftests/drivers/net/hw/Makefile
> > +++ b/tools/testing/selftests/drivers/net/hw/Makefile
> > @@ -80,5 +80,5 @@ include ../../../net/ynl.mk
> > include ../../../net/bpf.mk
> > ifeq ($(HAS_IOURING_ZCRX),y)
> > -$(OUTPUT)/iou-zcrx: LDLIBS += -luring
> > +$(OUTPUT)/iou-zcrx: LDLIBS += -luring -lpthread
> > endif
> > diff --git a/tools/testing/selftests/drivers/net/hw/iou-zcrx.c b/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> > index 334985083f61..de2eea78a5b6 100644
> > --- a/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> > +++ b/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> > @@ -4,6 +4,7 @@
> > #include <error.h>
> > #include <fcntl.h>
> > #include <limits.h>
> > +#include <pthread.h>
> > #include <stdbool.h>
> > #include <stdint.h>
> > #include <stdio.h>
> > @@ -85,8 +86,14 @@ static int cfg_send_size = SEND_SIZE;
> > static struct sockaddr_in6 cfg_addr;
> > static unsigned int cfg_rx_buf_len;
> > static bool cfg_dry_run;
> > +static int cfg_num_threads = 1;
> > static char *payload;
> > +
> > +struct thread_ctx {
> > + int thread_id;
>
> This is set here and in patch 4 but I don't see it being used.
Makes sense, will remove from v2.
^ permalink raw reply
* Re: [patch 10/38] arcnet: Remove function timing code
From: David Woodhouse @ 2026-04-13 15:29 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Michael Grzeschik, netdev, Arnd Bergmann, x86, Lu Baolu, iommu,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390, David S. Miller, sparclinux
In-Reply-To: <20260410120318.253872322@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
On Fri, 2026-04-10 at 14:19 +0200, Thomas Gleixner wrote:
> ARCNET is a museums piece and the function timing can be done with
> ftrace. Remove the cruft.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
> Cc: netdev@vger.kernel.org
> ---
> drivers/net/arcnet/arc-rimi.c | 4 ++--
> drivers/net/arcnet/arcdevice.h | 20 +-------------------
> drivers/net/arcnet/com20020.c | 6 ++----
> drivers/net/arcnet/com90io.c | 6 ++----
> drivers/net/arcnet/com90xx.c | 4 ++--
> 5 files changed, 9 insertions(+), 31 deletions(-)
Acked-by: David Woodhouse <dwmw2@infradead.org>
By coincidence, I took the last of my ARCNET cards to the tip just this
morning...
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [net,PATCH v2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Marek Vasut @ 2026-04-13 15:31 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Jakub Kicinski
Cc: netdev, stable, David S. Miller, Andrew Lunn, Eric Dumazet,
Nicolai Buchwitz, Paolo Abeni, Ronald Wahl, Yicong Hui,
linux-kernel, Thomas Gleixner
In-Reply-To: <20260413125744.TVKkZcEK@linutronix.de>
On 4/13/26 2:57 PM, Sebastian Andrzej Siewior wrote:
> On 2026-04-12 10:51:25 [-0700], Jakub Kicinski wrote:
>>> Does the backtrace make the problem clearer, with the annotation above ?
>>
>> Sebastian, do you have any recommendation here? tl;dr is that the driver does
> …
>
> What about this:
>
> --- a/drivers/net/ethernet/micrel/ks8851_par.c
> +++ b/drivers/net/ethernet/micrel/ks8851_par.c
> @@ -63,7 +63,7 @@ static void ks8851_lock_par(struct ks8851_net *ks, unsigned long *flags)
> {
> struct ks8851_net_par *ksp = to_ks8851_par(ks);
>
> - spin_lock_irqsave(&ksp->lock, *flags);
> + spin_lock_bh(&ksp->lock);
> }
>
> /**
> @@ -77,7 +77,7 @@ static void ks8851_unlock_par(struct ks8851_net *ks, unsigned long *flags)
> {
> struct ks8851_net_par *ksp = to_ks8851_par(ks);
>
> - spin_unlock_irqrestore(&ksp->lock, *flags);
> + spin_unlock_bh(&ksp->lock);
> }
>
> /**
>
>
> I don't see why it needs to disable interrupts.
Because when the lock is held, the PAR code shouldn't be interrupted by
an interrupt, otherwise it would completely mess up the state of the
KS8851 MAC. The spinlock does not protect only the IRQ handler, it
protects also ks8851_start_xmit_par() and ks8851_write_mac_addr() and
ks8851_read_mac_addr() and ks8851_net_open() and ks8851_net_stop() and
other sites which call ks8851_lock()/ks8851_unlock() which cannot be
executed concurrently, but where BHs can be enabled.
> ? This seems to be used by
> the _par driver and the _common part. The comments refer to DMA but I
> see only FIFO access.
The KS8851 does its own internal DMA into the SRAM, from which the data
are copied by the driver into system DRAM.
> And while at it, I would recommend to
>
> diff --git a/drivers/net/ethernet/micrel/ks8851_common.c b/drivers/net/ethernet/micrel/ks8851_common.c
> index 8048770958d60..f1c662887646c 100644
> --- a/drivers/net/ethernet/micrel/ks8851_common.c
> +++ b/drivers/net/ethernet/micrel/ks8851_common.c
> @@ -378,9 +378,12 @@ static irqreturn_t ks8851_irq(int irq, void *_ks)
> if (status & IRQ_LCI)
> mii_check_link(&ks->mii);
>
> - if (status & IRQ_RXI)
> + if (status & IRQ_RXI) {
> + local_bh_disable();
> while ((skb = __skb_dequeue(&rxq)))
> netif_rx(skb);
> + local_bh_enable();
> + }
>
> return IRQ_HANDLED;
> }
>
> Because otherwise it will kick-off backlog NAPI after every packet if
> multiple packets are available.
I think this patch will do the same, but the above should be done for
the SPI part ?
^ permalink raw reply
* Re: [patch 15/38] ptp: ptp_vmclock: Replace get_cycles() usage
From: David Woodhouse @ 2026-04-13 15:33 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390, David S. Miller, sparclinux
In-Reply-To: <20260410120318.592237447@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Fri, 2026-04-10 at 14:19 +0200, Thomas Gleixner wrote:
> get_cycles() is not really well defined and similar to other usaage of the
> underlying hardware CPU counters the PTP vmclock should use an explicit
> interface as well.
>
> Implement ptp_vmclock_read_cpu_counter() in arm64 and x86 and simplify the
> Kconfig selection while at it.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: David Woodhouse <dwmw2@infradead.org>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Although I might follow up with a change to make this...
> +static inline u64 ptp_vmclock_read_cpu_counter(void)
> +{
> + return cpu_feature_enabled(X86_FEATURE_TSC) ? rdtsc() : 0;
> +}
> +
... depend on TSC_RELIABLE¹, since if the guest doesn't believe that it
is, then the guest shouldn't be trying to use it as the basis for
precise timing.
¹ (Or... one of the other zoo of TSC flags for the gradually reducing
brokenness over the years...)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [net-next PATCH v5 1/4] octeontx2-af: npa: cn20k: Add NPA Halo support
From: Alexander Lobakin @ 2026-04-13 15:32 UTC (permalink / raw)
To: Subbaraya Sundeep
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, sgoutham, gakula,
bbhushan2, netdev, linux-kernel, Linu Cherian
In-Reply-To: <20260410101150.GA1783722@kernel-ep2>
From: Subbaraya Sundeep <sbhatta@marvell.com>
Date: Fri, 10 Apr 2026 15:41:50 +0530
> On 2026-04-10 at 15:06:56, Alexander Lobakin (aleksander.lobakin@intel.com) wrote:
>> From: Subbaraya Sundeep <sbhatta@marvell.com>
>> Date: Fri, 10 Apr 2026 15:05:36 +0530
>>
>>> On 2026-04-09 at 20:39:02, Alexander Lobakin (aleksander.lobakin@intel.com) wrote:
>>>> From: Subbaraya Sundeep <sbhatta@marvell.com>
>>>> Date: Thu, 9 Apr 2026 15:23:21 +0530
>>>>
>>>>> From: Linu Cherian <lcherian@marvell.com>
>>>>>
>>>>> CN20K silicon implements unified aura and pool context
>>>>> type called Halo for better resource usage. Add support to
>>>>> handle Halo context type operations.
>>>>>
>>>>> Signed-off-by: Linu Cherian <lcherian@marvell.com>
>>>>> Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/struct.h b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/struct.h
>>>>> index 763f6cabd7c2..2364bafd329d 100644
>>>>> --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/struct.h
>>>>> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/struct.h
>>>>> @@ -377,4 +377,85 @@ struct npa_cn20k_pool_s {
>>>>>
>>>>> static_assert(sizeof(struct npa_cn20k_pool_s) == NIX_MAX_CTX_SIZE);
>>>>>
>>>>> +struct npa_cn20k_halo_s {
>>>>> + u64 stack_base : 64;
>>>>
>>>> It's redundant to add : 64 to a 64-bit field.
>>> Agreed. But this is for readability, it helps when checking HRM. For
>>> instance HRM says [703:640] and we define as u64 reserved_640_703 : 64;
>>> so that we do not have to count bits in mind.
>>>> Moreover, on 32-bit systems, the compilers sometimes complain on
>>>> bitfields > 32 bits.
>>> This driver depends on 64BIT.
>>>>
>>>>> + u64 ena : 1;
>>>>> + u64 nat_align : 1;
>>>>> + u64 reserved_66_67 : 2;
>>>>> + u64 stack_caching : 1;
>>>>> + u64 reserved_69_71 : 3;
>>>>> + u64 aura_drop_ena : 1;
>>>>> + u64 reserved_73_79 : 7;
>>>>> + u64 aura_drop : 8;
>>>>> + u64 buf_offset : 12;
>>>>> + u64 reserved_100_103 : 4;
>>>>> + u64 buf_size : 12;
>>>>> + u64 reserved_116_119 : 4;
>>>>> + u64 ref_cnt_prof : 3;
>>>>> + u64 reserved_123_127 : 5;
>>>>> + u64 stack_max_pages : 32;
>>>>> + u64 stack_pages : 32;
>>>>> + u64 bp_0 : 7;
>>>>> + u64 bp_1 : 7;
>>>>> + u64 bp_2 : 7;
>>>>> + u64 bp_3 : 7;
>>>>> + u64 bp_4 : 7;
>>>>> + u64 bp_5 : 7;
>>>>> + u64 bp_6 : 7;
>>>>> + u64 bp_7 : 7;
>>>>> + u64 bp_ena_0 : 1;
>>>>> + u64 bp_ena_1 : 1;
>>>>> + u64 bp_ena_2 : 1;
>>>>> + u64 bp_ena_3 : 1;
>>>>> + u64 bp_ena_4 : 1;
>>>>> + u64 bp_ena_5 : 1;
>>>>> + u64 bp_ena_6 : 1;
>>>>> + u64 bp_ena_7 : 1;
>>>>> + u64 stack_offset : 4;
>>>>> + u64 reserved_260_263 : 4;
>>>>> + u64 shift : 6;
>>>>> + u64 reserved_270_271 : 2;
>>>>> + u64 avg_level : 8;
>>>>> + u64 avg_con : 9;
>>>>> + u64 fc_ena : 1;
>>>>> + u64 fc_stype : 2;
>>>>> + u64 fc_hyst_bits : 4;
>>>>> + u64 fc_up_crossing : 1;
>>>>> + u64 reserved_297_299 : 3;
>>>>> + u64 update_time : 16;
>>>>> + u64 reserved_316_319 : 4;
>>>>> + u64 fc_addr : 64;
>>>>> + u64 ptr_start : 64;
>>>>> + u64 ptr_end : 64;
>>>>> + u64 bpid_0 : 12;
>>>>> + u64 reserved_524_535 : 12;
>>>>> + u64 err_int : 8;
>>>>> + u64 err_int_ena : 8;
>>>>> + u64 thresh_int : 1;
>>>>> + u64 thresh_int_ena : 1;
>>>>> + u64 thresh_up : 1;
>>>>> + u64 reserved_555 : 1;
>>>>> + u64 thresh_qint_idx : 7;
>>>>> + u64 reserved_563 : 1;
>>>>> + u64 err_qint_idx : 7;
>>>>> + u64 reserved_571_575 : 5;
>>>>> + u64 thresh : 36;
>>>>> + u64 reserved_612_615 : 4;
>>>>> + u64 fc_msh_dst : 11;
>>>>> + u64 reserved_627_630 : 4;
>>>>> + u64 op_dpc_ena : 1;
>>>>> + u64 op_dpc_set : 5;
>>>>> + u64 reserved_637_637 : 1;
>>>>> + u64 stream_ctx : 1;
>>>>> + u64 unified_ctx : 1;
>>>>> + u64 reserved_640_703 : 64;
>>>>> + u64 reserved_704_767 : 64;
>>>>> + u64 reserved_768_831 : 64;
>>>>> + u64 reserved_832_895 : 64;
>>>>> + u64 reserved_896_959 : 64;
>>>>> + u64 reserved_960_1023 : 64;
>>>>> +};
>>>>> +
>>>>> +static_assert(sizeof(struct npa_cn20k_halo_s) == NIX_MAX_CTX_SIZE);
>>>>
>>>> Now the main question:
>>>>
>>>> Is mailbox's Endianness fixed (LE/BE)? Or is it always the same as the
>>>> host's ones (I doubt so)?
>>>> If not, these need to be __le{8,16,32,64} (or __be if it's Big Endian)
>>>> and you need to handle the conversions manually.
>>>>
>>> Yes endianness is LE and fixed. This is NOT a host side driver for an
>>> endpoint card. This is driver for on chip PCI device of CN20K soc.
>>> Hope I answered your question wrt host.
>>
>> But the mailbox is shared between the SoC and the host or HW or not? Is
> In hardware it is just shared DDR region between two on chip devices and both
> devices access shared region using their BARs.
>> it possible that one client of the mailbox will have LE and the second
>> will have BE?
> No not possible.
Okay, so seems like it's safe to use Endianness-agnostic types without
messing with `__le`/`__be`, thanks for explaining.
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH 2/5] selftests: net: add multithread client support to iou-zcrx
From: Juanlu Herrero @ 2026-04-13 15:44 UTC (permalink / raw)
To: David Wei; +Cc: netdev
In-Reply-To: <8fa08d73-28a3-4521-bcfb-ec81869c24f3@davidwei.uk>
On Thu, Apr 09, 2026 at 08:51:11AM -0600, David Wei wrote:
> On 2026-04-08 09:38, Juanlu Herrero wrote:
> > Add pthreads to the iou-zcrx client so that multiple connections can be
> > established simultaneously. Each client thread connects to the server
> > and sends its payload independently.
> >
> > Introduce struct thread_ctx and the -t option to control the number of
> > threads (default 1), preserving backwards compatibility with existing
> > tests.
> >
> > Signed-off-by: Juanlu Herrero <juanlu@fastmail.com>
> > ---
> > .../testing/selftests/drivers/net/hw/Makefile | 2 +-
> > .../selftests/drivers/net/hw/iou-zcrx.c | 46 +++++++++++++++++--
> > 2 files changed, 44 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/testing/selftests/drivers/net/hw/Makefile b/tools/testing/selftests/drivers/net/hw/Makefile
> > index deeca3f8d080..227adfec706c 100644
> > --- a/tools/testing/selftests/drivers/net/hw/Makefile
> > +++ b/tools/testing/selftests/drivers/net/hw/Makefile
> > @@ -80,5 +80,5 @@ include ../../../net/ynl.mk
> > include ../../../net/bpf.mk
> > ifeq ($(HAS_IOURING_ZCRX),y)
> > -$(OUTPUT)/iou-zcrx: LDLIBS += -luring
> > +$(OUTPUT)/iou-zcrx: LDLIBS += -luring -lpthread
> > endif
> > diff --git a/tools/testing/selftests/drivers/net/hw/iou-zcrx.c b/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> > index 334985083f61..de2eea78a5b6 100644
> > --- a/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> > +++ b/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> > @@ -4,6 +4,7 @@
> > #include <error.h>
> > #include <fcntl.h>
> > #include <limits.h>
> > +#include <pthread.h>
> > #include <stdbool.h>
> > #include <stdint.h>
> > #include <stdio.h>
> > @@ -85,8 +86,14 @@ static int cfg_send_size = SEND_SIZE;
> > static struct sockaddr_in6 cfg_addr;
> > static unsigned int cfg_rx_buf_len;
> > static bool cfg_dry_run;
> > +static int cfg_num_threads = 1;
> > static char *payload;
> > +
> > +struct thread_ctx {
> > + int thread_id;
>
> This is set here and in patch 4 but I don't see it being used.
Makes sense, will remove in v2.
^ permalink raw reply
* Re: [net,PATCH v2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Jakub Kicinski @ 2026-04-13 15:44 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Marek Vasut, netdev, stable, David S. Miller, Andrew Lunn,
Eric Dumazet, Nicolai Buchwitz, Paolo Abeni, Ronald Wahl,
Yicong Hui, linux-kernel, Thomas Gleixner
In-Reply-To: <20260413125744.TVKkZcEK@linutronix.de>
On Mon, 13 Apr 2026 14:57:44 +0200 Sebastian Andrzej Siewior wrote:
> On 2026-04-12 10:51:25 [-0700], Jakub Kicinski wrote:
> > > Does the backtrace make the problem clearer, with the annotation above ?
> >
> > Sebastian, do you have any recommendation here? tl;dr is that the driver does
> …
>
> What about this:
Thanks for taking a look (according to you auto-reply immediately after
a vacation ;))
TBH changing the driver feels like a workaround / invitation for a
whack-a-mole game. I'd prefer to fix the skb allocation.
Is there any way we can check if any locks which were _irq() on non-RT
are held?
^ permalink raw reply
* Re: [PATCH iwl-next v2] igb: use ktime_get_real helpers in igb_ptp_reset()
From: Simon Horman @ 2026-04-13 15:50 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Jacob Keller,
Paul Menzel
In-Reply-To: <20260409075523.3728506-1-aleksandr.loktionov@intel.com>
On Thu, Apr 09, 2026 at 09:55:23AM +0200, Aleksandr Loktionov wrote:
> Replace ktime_to_ns(ktime_get_real()) with the direct equivalent
> ktime_get_real_ns() and ktime_to_timespec64(ktime_get_real()) with
> ktime_get_real_ts64() in igb_ptp_reset(). Using the combined helpers
> makes the intent clearer.
>
> Suggested-by: Jacob Keller <jacob.e.keller@intel.com>
> Suggested-by: Simon Horman <horms@kernel.org>
> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next] ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()
From: Romanowski, Rafal @ 2026-04-13 15:51 UTC (permalink / raw)
To: Simon Horman, Loktionov, Aleksandr
Cc: intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L,
netdev@vger.kernel.org, Dawid Osuchowski
In-Reply-To: <20260403115255.GA60103@horms.kernel.org>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Simon
> Horman
> Sent: Friday, April 3, 2026 1:57 PM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; netdev@vger.kernel.org; Dawid Osuchowski
> <dawid.osuchowski@linux.intel.com>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next] ice: fix FDIR CTRL VSI resource
> leak in ice_reset_all_vfs()
>
> On Fri, Mar 27, 2026 at 08:22:32AM +0100, Aleksandr Loktionov wrote:
> > From: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
> >
> > Resetting all VFs causes resource leak on VFs with FDIR filters
> > enabled as CTRL VSIs are only invalidated and not freed. Fix by using
> > ice_vf_ctrl_vsi_release() instead of ice_vf_ctrl_invalidate_vsi()
> > which aligns behavior with the ice_reset_vf() function.
> >
> > Reproduction:
> > echo 1 > /sys/class/net/$pf/device/sriov_numvfs
> > ethtool -N $vf flow-type ether proto 0x9000 action 0
> > echo 1 > /sys/class/net/$pf/device/reset
> >
> > Fixes: da62c5ff9dcd ("ice: Add support for per VF ctrl VSI enabling")
> > Signed-off-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
> > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>
> Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net] ice: fix NULL pointer dereference in ice_reset_all_vfs()
From: Romanowski, Rafal @ 2026-04-13 15:53 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Kitszel, Przemyslaw, Brett Creeley, Eric Dumazet,
linux-kernel@vger.kernel.org, Andrew Lunn, Nguyen, Anthony L,
intel-wired-lan@lists.osuosl.org, Jakub Kicinski, Paolo Abeni,
David S. Miller
In-Reply-To: <20260401110937.83497-1-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr
> Oros
> Sent: Wednesday, April 1, 2026 1:10 PM
> To: netdev@vger.kernel.org
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Brett Creeley
> <brett.creeley@intel.com>; Eric Dumazet <edumazet@google.com>; linux-
> kernel@vger.kernel.org; Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; intel-wired-lan@lists.osuosl.org;
> Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S.
> Miller <davem@davemloft.net>
> Subject: [Intel-wired-lan] [PATCH iwl-net] ice: fix NULL pointer dereference in
> ice_reset_all_vfs()
>
> ice_reset_all_vfs() ignores the return value of ice_vf_rebuild_vsi().
> When the VSI rebuild fails (e.g. during NVM firmware update via nvmupdate64e),
> ice_vsi_rebuild() tears down the VSI on its error path, leaving txq_map and
> rxq_map as NULL. The subsequent unconditional call to ice_vf_post_vsi_rebuild()
> leads to a NULL pointer dereference in
> ice_ena_vf_q_mappings() when it accesses vsi->txq_map[0].
>
> The single-VF reset path in ice_reset_vf() already handles this correctly by
> checking the return value of ice_vf_reconfig_vsi() and skipping
> ice_vf_post_vsi_rebuild() on failure.
>
> Apply the same pattern to ice_reset_all_vfs(): check the return value of
> ice_vf_rebuild_vsi() and skip ice_vf_post_vsi_rebuild() and
> ice_eswitch_attach_vf() on failure. The VF is left safely disabled
> (ICE_VF_STATE_INIT not set, VFGEN_RSTAT not set to VFACTIVE) and can be
> recovered via a VFLR triggered by a PCI reset of the VF (sysfs reset or driver
> rebind).
>
> Note that this patch does not prevent the VF VSI rebuild from failing during NVM
> update — the underlying cause is firmware being in a transitional state while the
> EMP reset is processed, which can cause Admin Queue commands (ice_add_vsi,
> ice_cfg_vsi_lan) to fail. This patch only prevents the subsequent NULL pointer
> dereference that crashes the kernel when the rebuild does fail.
>
> crash> bt
> PID: 50795 TASK: ff34c9ee708dc680 CPU: 1 COMMAND:
> "kworker/u512:5"
> #0 [ff72159bcfe5bb50] machine_kexec at ffffffffaa8850ee
> #1 [ff72159bcfe5bba8] __crash_kexec at ffffffffaaa15fba
> #2 [ff72159bcfe5bc68] crash_kexec at ffffffffaaa16540
> #3 [ff72159bcfe5bc70] oops_end at ffffffffaa837eda
> #4 [ff72159bcfe5bc90] page_fault_oops at ffffffffaa893997
> #5 [ff72159bcfe5bce8] exc_page_fault at ffffffffab528595
> #6 [ff72159bcfe5bd10] asm_exc_page_fault at ffffffffab600bb2
> [exception RIP: ice_ena_vf_q_mappings+0x79]
> RIP: ffffffffc0a85b29 RSP: ff72159bcfe5bdc8 RFLAGS: 00010206
> RAX: 00000000000f0000 RBX: ff34c9efc9c00000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff34c9efc9c00000
> RBP: ff34c9efc27d4828 R8: 0000000000000093 R9: 0000000000000040
> R10: ff34c9efc27d4828 R11: 0000000000000040 R12: 0000000000100000
> R13: 0000000000000010 R14: R15:
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> #7 [ff72159bcfe5bdf8] ice_sriov_post_vsi_rebuild at ffffffffc0a85e2e [ice]
> #8 [ff72159bcfe5be08] ice_reset_all_vfs at ffffffffc0a920b4 [ice]
> #9 [ff72159bcfe5be48] ice_service_task at ffffffffc0a31519 [ice]
> #10 [ff72159bcfe5be88] process_one_work at ffffffffaa93dca4
> #11 [ff72159bcfe5bec8] worker_thread at ffffffffaa93e9de
> #12 [ff72159bcfe5bf18] kthread at ffffffffaa946663
> #13 [ff72159bcfe5bf50] ret_from_fork at ffffffffaa8086b9
>
> The panic occurs attempting to dereference the NULL pointer in RDX at
> ice_sriov.c:294, which loads vsi->txq_map (offset 0x4b8 in ice_vsi).
>
> The faulting VSI is an allocated slab object but not fully initialized after a failed
> ice_vsi_rebuild():
>
> crash> struct ice_vsi 0xff34c9efc27d4828
> netdev = 0x0,
> rx_rings = 0x0,
> tx_rings = 0x0,
> q_vectors = 0x0,
> txq_map = 0x0,
> rxq_map = 0x0,
> alloc_txq = 0x10,
> num_txq = 0x10,
> alloc_rxq = 0x10,
> num_rxq = 0x10,
>
> The nvmupdate64e process was performing NVM firmware update:
>
> crash> bt 0xff34c9edd1a30000
> PID: 49858 TASK: ff34c9edd1a30000 CPU: 1 COMMAND: "nvmupdate64e"
> #0 [ff72159bcd617618] __schedule at ffffffffab5333f8
> #4 [ff72159bcd617750] ice_sq_send_cmd at ffffffffc0a35347 [ice]
> #5 [ff72159bcd6177a8] ice_sq_send_cmd_retry at ffffffffc0a35b47 [ice]
> #6 [ff72159bcd617810] ice_aq_send_cmd at ffffffffc0a38018 [ice]
> #7 [ff72159bcd617848] ice_aq_read_nvm at ffffffffc0a40254 [ice]
> #8 [ff72159bcd6178b8] ice_read_flat_nvm at ffffffffc0a4034c [ice]
> #9 [ff72159bcd617918] ice_devlink_nvm_snapshot at ffffffffc0a6ffa5 [ice]
>
> dmesg:
> ice 0000:13:00.0: firmware recommends not updating fw.mgmt, as it
> may result in a downgrade. continuing anyways
> ice 0000:13:00.1: ice_init_nvm failed -5
> ice 0000:13:00.1: Rebuild failed, unload and reload driver
>
> Fixes: 12bb018c538c ("ice: Refactor VF reset")
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/net/ethernet/intel/ice/ice_vf_lib.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> index c8bc952f05cdb5..51259a4fdda4b9 100644
> --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> @@ -804,7 +804,12 @@ void ice_reset_all_vfs(struct ice_pf *pf)
> ice_vf_ctrl_invalidate_vsi(vf);
>
> ice_vf_pre_vsi_rebuild(vf);
> - ice_vf_rebuild_vsi(vf);
> + if (ice_vf_rebuild_vsi(vf)) {
> + dev_err(dev, "VF %u VSI rebuild failed, leaving VF
> disabled\n",
> + vf->vf_id);
> + mutex_unlock(&vf->cfg_lock);
> + continue;
> + }
> ice_vf_post_vsi_rebuild(vf);
>
> ice_eswitch_attach_vf(pf, vf);
> --
> 2.52.0
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* Re: [PATCH 5/5] selftests: net: add rss_multiqueue test variant to iou-zcrx
From: Juanlu Herrero @ 2026-04-13 16:01 UTC (permalink / raw)
To: David Wei; +Cc: netdev
In-Reply-To: <d3777e86-2859-491d-8071-77871df13c08@davidwei.uk>
On Fri, Apr 10, 2026 at 03:26:54PM -0600, David Wei wrote:
> On 2026-04-08 09:38, Juanlu Herrero wrote:
> > Add multi-port support to the iou-zcrx test binary and a new
> > rss_multiqueue Python test variant that exercises multi-queue zero-copy
> > receive with per-port flow rule steering.
> >
> > In multi-port mode, the server creates N listening sockets on
> > consecutive ports (cfg_port, cfg_port+1, ...) and uses epoll to accept
> > one connection per socket. Each client thread connects to its
> > corresponding port. Per-port ntuple flow rules steer traffic to
> > different NIC hardware queues, each with its own zcrx instance.
> >
> > For single-thread mode (the default), behavior is unchanged: one socket
> > on cfg_port, one thread, one queue.
> >
> > Signed-off-by: Juanlu Herrero <juanlu@fastmail.com>
> > ---
> > .../selftests/drivers/net/hw/iou-zcrx.c | 81 ++++++++++++++-----
> > .../selftests/drivers/net/hw/iou-zcrx.py | 45 ++++++++++-
> > 2 files changed, 104 insertions(+), 22 deletions(-)
> >
> > diff --git a/tools/testing/selftests/drivers/net/hw/iou-zcrx.c b/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> > index 646682167bb0..1f33d7127185 100644
> > --- a/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> > +++ b/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
>
> Please make all changes in iou-zcrx.c in a single patch. Then patch 5
> only changes the Python selftest.
>
> [...]
> > @@ -397,12 +410,36 @@ static void run_server(void)
> > if (cfg_dry_run)
> > goto join;
> > + epfd = epoll_create1(0);
> > + if (epfd < 0)
> > + error(1, 0, "epoll_create1()");
> > +
> > for (i = 0; i < cfg_num_threads; i++) {
> > - ctxs[i].connfd = accept(fd, NULL, NULL);
> > - if (ctxs[i].connfd < 0)
> > - error(1, 0, "accept()");
> > + ev.events = EPOLLIN;
> > + ev.data.u32 = i;
> > + if (epoll_ctl(epfd, EPOLL_CTL_ADD, fds[i], &ev) < 0)
> > + error(1, 0, "epoll_ctl()");
> > }
> > + accepted = 0;
> > + while (accepted < cfg_num_threads) {
>
> You're using epoll here but it is still accepting a fixed nr of
> connections. The server should be able to accept an arbitrary nr of
> connections, dispatching them to the server worker threads.
>
> Also with multiple queues, connections must be dispatched according to
> their NAPI IDs to the correct server workers.
>
> > + nfds = epoll_wait(epfd, events, 64, 5000);
> > + if (nfds < 0)
> > + error(1, 0, "epoll_wait()");
> > + if (nfds == 0)
> > + error(1, 0, "epoll_wait() timeout");
> > +
> > + for (i = 0; i < nfds; i++) {
> > + int idx = events[i].data.u32;
> > +
> > + ctxs[idx].connfd = accept(fds[idx], NULL, NULL);
> > + if (ctxs[idx].connfd < 0)
> > + error(1, 0, "accept()");
> > + accepted++;
> > + }
> > + }
> > +
> > + close(epfd);
> > pthread_barrier_wait(&barrier);
> > join:
Makes sense, I will re-work the patches and address the epoll & NAPI
id feedback. Thanks!
^ 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