* [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 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
* 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 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: [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 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 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 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 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 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 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
* [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] xfrm: fix memory leak in xfrm_add_policy()
From: Sabrina Dubroca @ 2026-04-13 14:34 UTC (permalink / raw)
To: Deepanshu Kartikey
Cc: steffen.klassert, herbert, davem, edumazet, kuba, pabeni, horms,
leon, netdev, linux-kernel, syzbot+901d48e0b95aed4a2548
In-Reply-To: <CADhLXY5a7QCdp7NXC07fma905O8YJ4jPcbbdK0=kFgD3d2AF-A@mail.gmail.com>
2026-04-13, 19:58:53 +0530, Deepanshu Kartikey wrote:
> On Mon, Apr 13, 2026 at 7:03 PM Sabrina Dubroca <sd@queasysnail.net> wrote:
> >
>
> > What is missing in the current code? "we have a better way to do this"
> > is not a bugfix, it's a clean up. The kmemleak report says that we're
> > leaking the xfrm_policy struct on this codepath, which doesn't make
> > sense, that's covered by the existing kfree(xp).
> >
> > Also, please use "PATCH ipsec" for fixes to net/xfrm and the rest of
> > the IPsec implementation.
> >
> > --
> > Sabrina
>
> Hi Sabrina,
>
> Thanks for the review!
>
> You are right, the existing kfree(xp) already covers the struct
> itself, so my commit message was incorrect in claiming a memory
> leak fix. I will resend this as a cleanup patch to replace the
> open-coded manual cleanup with xfrm_policy_destroy(), which is
> more consistent with xfrm_policy_construct() error handling.
Ok. Then you should wait 2 weeks until the merge window is over:
https://lore.kernel.org/netdev/20260412142250.131bf997@kernel.org/
and use "[PATCH ipsec-next]" as prefix for the cleanup patch (+ drop
the syzbot references).
> I am also separately investigating the root cause of the actual
> kmemleak report and will send a proper fix once identified.
Ok, thanks.
--
Sabrina
^ permalink raw reply
* Re: [GIT PULL] bluetooth-next 2026-04-13
From: Paolo Abeni @ 2026-04-13 14:34 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <CABBYNZK5mMbuzvjAquy49vSk0pLRnk_s8oqEut1se4DToURn9A@mail.gmail.com>
On 4/13/26 4:11 PM, Luiz Augusto von Dentz 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?
That's the problem with PR: AFAIK we can just pull whatever the
submitter published. To do any edit, including dropping patches, we must
not do a git pull, and instead applying the patches individually
(meaning they will get the net maintainer SoB, too, which in turn will
make little sense).
/P
^ permalink raw reply
* Re: [PATCH net 1/2] netfilter: skip recording stale or retransmitted INIT
From: Florian Westphal @ 2026-04-13 14:23 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, davem, kuba, Eric Dumazet, Paolo Abeni,
Simon Horman, Marcelo Ricardo Leitner, Yi Chen
In-Reply-To: <CADvbK_f1Cvqx0_-J1jGaT865eWiW2ZHsJT8EkN6kr21j88Y9kQ@mail.gmail.com>
Xin Long <lucien.xin@gmail.com> wrote:
> On Sat, Apr 11, 2026 at 4:16 PM Florian Westphal <fw@strlen.de> wrote:
> > Xin Long <lucien.xin@gmail.com> wrote:
> >
> > > diff --git a/net/netfilter/nf_conntrack_proto_sctp.c b/net/netfilter/nf_conntrack_proto_sctp.c
> > > index 645d2c43ebf7..7e10fa65cbdd 100644
> > > --- a/net/netfilter/nf_conntrack_proto_sctp.c
> > > +++ b/net/netfilter/nf_conntrack_proto_sctp.c
> > > @@ -466,9 +466,13 @@ int nf_conntrack_sctp_packet(struct nf_conn *ct,
> > > if (!ih)
> > > goto out_unlock;
> > >
> > > - if (ct->proto.sctp.init[dir] && ct->proto.sctp.init[!dir])
> > > - ct->proto.sctp.init[!dir] = 0;
> > > - ct->proto.sctp.init[dir] = 1;
> > > + /* Do not record INIT matching peer vtag (stale or retransmitted INIT). */
> > > + if (old_state == SCTP_CONNTRACK_NONE ||
> > > + ct->proto.sctp.vtag[!dir] != ih->init_tag) {
> >
> > Should ct->proto.sctp.vtag[!dir] == ih->init_tag case also
> > set ignore = true?
>
> It should for a stale INIT, but not for a retransmitted one. At this point,
> though, we don't reliably distinguish between the two.
>
> Also, as this patch only aims to prevent updating ct->proto.sctp.init[]
> (introduced in 8e56b063c865) in this scenario, it’s safer to avoid
> changing other behavior.
Alright. I'm fine with this going in via net directly:
Acked-by: Florian Westphal <fw@strlen.de>
^ permalink raw reply
* Re: [PATCH] xfrm: fix memory leak in xfrm_add_policy()
From: Deepanshu Kartikey @ 2026-04-13 14:28 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: steffen.klassert, herbert, davem, edumazet, kuba, pabeni, horms,
leon, netdev, linux-kernel, syzbot+901d48e0b95aed4a2548
In-Reply-To: <adzwiKOPptwbNp7Y@krikkit>
On Mon, Apr 13, 2026 at 7:03 PM Sabrina Dubroca <sd@queasysnail.net> wrote:
>
> What is missing in the current code? "we have a better way to do this"
> is not a bugfix, it's a clean up. The kmemleak report says that we're
> leaking the xfrm_policy struct on this codepath, which doesn't make
> sense, that's covered by the existing kfree(xp).
>
> Also, please use "PATCH ipsec" for fixes to net/xfrm and the rest of
> the IPsec implementation.
>
> --
> Sabrina
Hi Sabrina,
Thanks for the review!
You are right, the existing kfree(xp) already covers the struct
itself, so my commit message was incorrect in claiming a memory
leak fix. I will resend this as a cleanup patch to replace the
open-coded manual cleanup with xfrm_policy_destroy(), which is
more consistent with xfrm_policy_construct() error handling.
I am also separately investigating the root cause of the actual
kmemleak report and will send a proper fix once identified.
Sorry for the noise and thanks again for the guidance.
Deepanshu
^ permalink raw reply
* Re: [syzbot] [mptcp?] possible deadlock in mptcp_pm_nl_set_flags
From: Matthieu Baerts @ 2026-04-13 14:26 UTC (permalink / raw)
To: syzbot
Cc: davem, edumazet, geliang, horms, kuba, linux-kernel, martineau,
mptcp, netdev, pabeni, syzkaller-bugs
In-Reply-To: <69d90c16.050a0220.adfb3.000a.GAE@google.com>
Hello,
On 10/04/2026 16:41, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 591cd656a1bf Linux 7.0-rc7
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1779ce06580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=5a3e5e8c17cc174e
> dashboard link: https://syzkaller.appspot.com/bug?extid=dfa28bb6444d8f169cbb
> compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-591cd656.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/3e99d0e29df0/vmlinux-591cd656.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/5877fee0a056/bzImage-591cd656.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+dfa28bb6444d8f169cbb@syzkaller.appspotmail.com
>
> netlink: 8 bytes leftover after parsing attributes in process `syz.8.6915'.
> netlink: 8 bytes leftover after parsing attributes in process `syz.8.6915'.
> ======================================================
> WARNING: possible circular locking dependency detected
> syzkaller #0 Tainted: G L
> ------------------------------------------------------
> syz.8.6915/29783 is trying to acquire lock:
> ffffffff8e9ab8a0 (fs_reclaim){+.+.}-{0:0}, at: might_alloc include/linux/sched/mm.h:317 [inline]
> ffffffff8e9ab8a0 (fs_reclaim){+.+.}-{0:0}, at: slab_pre_alloc_hook mm/slub.c:4489 [inline]
> ffffffff8e9ab8a0 (fs_reclaim){+.+.}-{0:0}, at: slab_alloc_node mm/slub.c:4843 [inline]
> ffffffff8e9ab8a0 (fs_reclaim){+.+.}-{0:0}, at: kmem_cache_alloc_lru_noprof+0x51/0x6e0 mm/slub.c:4885
>
> but task is already holding lock:
> ffff888034761ae0 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1709 [inline]
> ffff888034761ae0 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1482 [inline]
> ffff888034761ae0 (sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_pm_nl_set_flags+0x605/0xd30 net/mptcp/pm_kernel.c:1551
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #6 (sk_lock-AF_INET){+.+.}-{0:0}:
> lock_sock_nested+0x41/0xf0 net/core/sock.c:3780
> lock_sock include/net/sock.h:1709 [inline]
> inet_shutdown+0x67/0x410 net/ipv4/af_inet.c:919
> nbd_mark_nsock_dead+0xae/0x5c0 drivers/block/nbd.c:318
> recv_work+0x5fb/0x8c0 drivers/block/nbd.c:1021
> process_one_work+0xa23/0x19a0 kernel/workqueue.c:3276
> process_scheduled_works kernel/workqueue.c:3359 [inline]
> worker_thread+0x5ef/0xe50 kernel/workqueue.c:3440
> kthread+0x370/0x450 kernel/kthread.c:436
> ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>
> -> #5 (&nsock->tx_lock){+.+.}-{4:4}:
> __mutex_lock_common kernel/locking/mutex.c:614 [inline]
> __mutex_lock+0x1a2/0x1b90 kernel/locking/mutex.c:776
> nbd_handle_cmd drivers/block/nbd.c:1143 [inline]
> nbd_queue_rq+0x428/0x1080 drivers/block/nbd.c:1207
> blk_mq_dispatch_rq_list+0x422/0x1e70 block/blk-mq.c:2148
> __blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
> blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
> __blk_mq_sched_dispatch_requests+0xcea/0x1620 block/blk-mq-sched.c:307
> blk_mq_sched_dispatch_requests+0xd7/0x1c0 block/blk-mq-sched.c:329
> blk_mq_run_hw_queue+0x23c/0x670 block/blk-mq.c:2386
> blk_mq_dispatch_list+0x51d/0x1360 block/blk-mq.c:2949
> blk_mq_flush_plug_list block/blk-mq.c:2997 [inline]
> blk_mq_flush_plug_list+0x130/0x600 block/blk-mq.c:2969
> __blk_flush_plug+0x2c4/0x4b0 block/blk-core.c:1230
> blk_finish_plug block/blk-core.c:1257 [inline]
> __submit_bio+0x584/0x6c0 block/blk-core.c:649
> __submit_bio_noacct_mq block/blk-core.c:722 [inline]
> submit_bio_noacct_nocheck+0x562/0xc10 block/blk-core.c:753
> submit_bio_noacct+0xd17/0x2010 block/blk-core.c:884
> blk_crypto_submit_bio include/linux/blk-crypto.h:203 [inline]
> submit_bh_wbc+0x59c/0x770 fs/buffer.c:2821
> submit_bh fs/buffer.c:2826 [inline]
> block_read_full_folio+0x4c8/0x8e0 fs/buffer.c:2458
> filemap_read_folio+0xfc/0x3b0 mm/filemap.c:2501
> do_read_cache_folio+0x2d7/0x6b0 mm/filemap.c:4101
> read_mapping_folio include/linux/pagemap.h:1017 [inline]
> read_part_sector+0xd1/0x370 block/partitions/core.c:723
> adfspart_check_ICS+0x93/0x910 block/partitions/acorn.c:360
> check_partition block/partitions/core.c:142 [inline]
> blk_add_partitions block/partitions/core.c:590 [inline]
> bdev_disk_changed+0x7f8/0xc80 block/partitions/core.c:694
> blkdev_get_whole+0x187/0x290 block/bdev.c:764
> bdev_open+0x2c7/0xe40 block/bdev.c:973
> blkdev_open+0x34e/0x4f0 block/fops.c:697
> do_dentry_open+0x6d8/0x1660 fs/open.c:949
> vfs_open+0x82/0x3f0 fs/open.c:1081
> do_open fs/namei.c:4677 [inline]
> path_openat+0x208c/0x31a0 fs/namei.c:4836
> do_file_open+0x20e/0x430 fs/namei.c:4865
> do_sys_openat2+0x10d/0x1e0 fs/open.c:1366
> do_sys_open fs/open.c:1372 [inline]
> __do_sys_openat fs/open.c:1388 [inline]
> __se_sys_openat fs/open.c:1383 [inline]
> __x64_sys_openat+0x12d/0x210 fs/open.c:1383
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> -> #4 (&cmd->lock){+.+.}-{4:4}:
> __mutex_lock_common kernel/locking/mutex.c:614 [inline]
> __mutex_lock+0x1a2/0x1b90 kernel/locking/mutex.c:776
> nbd_queue_rq+0xba/0x1080 drivers/block/nbd.c:1199
> blk_mq_dispatch_rq_list+0x422/0x1e70 block/blk-mq.c:2148
> __blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
> blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
> __blk_mq_sched_dispatch_requests+0xcea/0x1620 block/blk-mq-sched.c:307
> blk_mq_sched_dispatch_requests+0xd7/0x1c0 block/blk-mq-sched.c:329
> blk_mq_run_hw_queue+0x23c/0x670 block/blk-mq.c:2386
> blk_mq_dispatch_list+0x51d/0x1360 block/blk-mq.c:2949
> blk_mq_flush_plug_list block/blk-mq.c:2997 [inline]
> blk_mq_flush_plug_list+0x130/0x600 block/blk-mq.c:2969
> __blk_flush_plug+0x2c4/0x4b0 block/blk-core.c:1230
> blk_finish_plug block/blk-core.c:1257 [inline]
> __submit_bio+0x584/0x6c0 block/blk-core.c:649
> __submit_bio_noacct_mq block/blk-core.c:722 [inline]
> submit_bio_noacct_nocheck+0x562/0xc10 block/blk-core.c:753
> submit_bio_noacct+0xd17/0x2010 block/blk-core.c:884
> blk_crypto_submit_bio include/linux/blk-crypto.h:203 [inline]
> submit_bh_wbc+0x59c/0x770 fs/buffer.c:2821
> submit_bh fs/buffer.c:2826 [inline]
> block_read_full_folio+0x4c8/0x8e0 fs/buffer.c:2458
> filemap_read_folio+0xfc/0x3b0 mm/filemap.c:2501
> do_read_cache_folio+0x2d7/0x6b0 mm/filemap.c:4101
> read_mapping_folio include/linux/pagemap.h:1017 [inline]
> read_part_sector+0xd1/0x370 block/partitions/core.c:723
> adfspart_check_ICS+0x93/0x910 block/partitions/acorn.c:360
> check_partition block/partitions/core.c:142 [inline]
> blk_add_partitions block/partitions/core.c:590 [inline]
> bdev_disk_changed+0x7f8/0xc80 block/partitions/core.c:694
> blkdev_get_whole+0x187/0x290 block/bdev.c:764
> bdev_open+0x2c7/0xe40 block/bdev.c:973
> blkdev_open+0x34e/0x4f0 block/fops.c:697
> do_dentry_open+0x6d8/0x1660 fs/open.c:949
> vfs_open+0x82/0x3f0 fs/open.c:1081
> do_open fs/namei.c:4677 [inline]
> path_openat+0x208c/0x31a0 fs/namei.c:4836
> do_file_open+0x20e/0x430 fs/namei.c:4865
> do_sys_openat2+0x10d/0x1e0 fs/open.c:1366
> do_sys_open fs/open.c:1372 [inline]
> __do_sys_openat fs/open.c:1388 [inline]
> __se_sys_openat fs/open.c:1383 [inline]
> __x64_sys_openat+0x12d/0x210 fs/open.c:1383
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> -> #3 (set->srcu){.+.+}-{0:0}:
> srcu_lock_sync include/linux/srcu.h:199 [inline]
> __synchronize_srcu+0xa2/0x300 kernel/rcu/srcutree.c:1481
> blk_mq_wait_quiesce_done block/blk-mq.c:284 [inline]
> blk_mq_wait_quiesce_done block/blk-mq.c:281 [inline]
> blk_mq_quiesce_queue block/blk-mq.c:304 [inline]
> blk_mq_quiesce_queue+0x149/0x1c0 block/blk-mq.c:299
> elevator_switch+0x17b/0x7e0 block/elevator.c:576
> elevator_change+0x352/0x530 block/elevator.c:681
> elevator_set_default+0x29e/0x360 block/elevator.c:754
> blk_register_queue+0x412/0x590 block/blk-sysfs.c:946
> __add_disk+0x73f/0xe40 block/genhd.c:528
> add_disk_fwnode+0x118/0x5c0 block/genhd.c:597
> add_disk include/linux/blkdev.h:785 [inline]
> nbd_dev_add+0x77a/0xb10 drivers/block/nbd.c:1984
> nbd_init+0x291/0x2b0 drivers/block/nbd.c:2692
> do_one_initcall+0x11d/0x760 init/main.c:1382
> do_initcall_level init/main.c:1444 [inline]
> do_initcalls init/main.c:1460 [inline]
> do_basic_setup init/main.c:1479 [inline]
> kernel_init_freeable+0x6e5/0x7a0 init/main.c:1692
> kernel_init+0x1f/0x1e0 init/main.c:1582
> ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>
> -> #2 (&q->elevator_lock){+.+.}-{4:4}:
> __mutex_lock_common kernel/locking/mutex.c:614 [inline]
> __mutex_lock+0x1a2/0x1b90 kernel/locking/mutex.c:776
> elevator_change+0x1bc/0x530 block/elevator.c:679
> elevator_set_none+0x92/0xf0 block/elevator.c:769
> blk_mq_elv_switch_none block/blk-mq.c:5110 [inline]
> __blk_mq_update_nr_hw_queues block/blk-mq.c:5155 [inline]
> blk_mq_update_nr_hw_queues+0x4c1/0x15f0 block/blk-mq.c:5220
> nbd_start_device+0x1a6/0xbd0 drivers/block/nbd.c:1489
> nbd_genl_connect+0xff2/0x1a40 drivers/block/nbd.c:2239
> genl_family_rcv_msg_doit+0x214/0x300 net/netlink/genetlink.c:1114
> genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
> genl_rcv_msg+0x560/0x800 net/netlink/genetlink.c:1209
> netlink_rcv_skb+0x159/0x420 net/netlink/af_netlink.c:2550
> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
> netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344
> netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1894
> sock_sendmsg_nosec net/socket.c:727 [inline]
> __sock_sendmsg net/socket.c:742 [inline]
> ____sys_sendmsg+0x9e1/0xb70 net/socket.c:2592
> ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646
> __sys_sendmsg+0x170/0x220 net/socket.c:2678
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> -> #1 (&q->q_usage_counter(io)#51){++++}-{0:0}:
> blk_alloc_queue+0x610/0x790 block/blk-core.c:461
> blk_mq_alloc_queue+0x174/0x290 block/blk-mq.c:4429
> __blk_mq_alloc_disk+0x29/0x120 block/blk-mq.c:4476
> nbd_dev_add+0x492/0xb10 drivers/block/nbd.c:1954
> nbd_init+0x291/0x2b0 drivers/block/nbd.c:2692
> do_one_initcall+0x11d/0x760 init/main.c:1382
> do_initcall_level init/main.c:1444 [inline]
> do_initcalls init/main.c:1460 [inline]
> do_basic_setup init/main.c:1479 [inline]
> kernel_init_freeable+0x6e5/0x7a0 init/main.c:1692
> kernel_init+0x1f/0x1e0 init/main.c:1582
> ret_from_fork+0x754/0xd80 arch/x86/kernel/process.c:158
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>
> -> #0 (fs_reclaim){+.+.}-{0:0}:
> check_prev_add kernel/locking/lockdep.c:3165 [inline]
> check_prevs_add kernel/locking/lockdep.c:3284 [inline]
> validate_chain kernel/locking/lockdep.c:3908 [inline]
> __lock_acquire+0x14b8/0x2630 kernel/locking/lockdep.c:5237
> lock_acquire kernel/locking/lockdep.c:5868 [inline]
> lock_acquire+0x1cf/0x380 kernel/locking/lockdep.c:5825
> __fs_reclaim_acquire mm/page_alloc.c:4348 [inline]
> fs_reclaim_acquire+0xc4/0x100 mm/page_alloc.c:4362
> might_alloc include/linux/sched/mm.h:317 [inline]
> slab_pre_alloc_hook mm/slub.c:4489 [inline]
> slab_alloc_node mm/slub.c:4843 [inline]
> kmem_cache_alloc_lru_noprof+0x51/0x6e0 mm/slub.c:4885
> sock_alloc_inode+0x25/0x1c0 net/socket.c:322
> alloc_inode+0x68/0x250 fs/inode.c:347
> new_inode_pseudo include/linux/fs.h:3003 [inline]
> sock_alloc+0x44/0x280 net/socket.c:637
> __sock_create+0xc2/0x860 net/socket.c:1569
> mptcp_subflow_create_socket+0xec/0xa30 net/mptcp/subflow.c:1790
> __mptcp_subflow_connect+0x3c6/0x1480 net/mptcp/subflow.c:1631
> mptcp_pm_create_subflow_or_signal_addr+0xc3e/0x18d0 net/mptcp/pm_kernel.c:416
> mptcp_pm_nl_fullmesh net/mptcp/pm_kernel.c:1460 [inline]
> mptcp_pm_nl_set_flags_all net/mptcp/pm_kernel.c:1487 [inline]
> mptcp_pm_nl_set_flags+0x814/0xd30 net/mptcp/pm_kernel.c:1551
> mptcp_pm_set_flags net/mptcp/pm_netlink.c:277 [inline]
> mptcp_pm_nl_set_flags_doit+0x1b0/0x290 net/mptcp/pm_netlink.c:282
> genl_family_rcv_msg_doit+0x214/0x300 net/netlink/genetlink.c:1114
> genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
> genl_rcv_msg+0x560/0x800 net/netlink/genetlink.c:1209
> netlink_rcv_skb+0x159/0x420 net/netlink/af_netlink.c:2550
> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
> netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344
> netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1894
> sock_sendmsg_nosec net/socket.c:727 [inline]
> __sock_sendmsg net/socket.c:742 [inline]
> ____sys_sendmsg+0x9e1/0xb70 net/socket.c:2592
> ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646
> __sys_sendmsg+0x170/0x220 net/socket.c:2678
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> other info that might help us debug this:
>
> Chain exists of:
> fs_reclaim --> &nsock->tx_lock --> sk_lock-AF_INET
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(sk_lock-AF_INET);
> lock(&nsock->tx_lock);
> lock(sk_lock-AF_INET);
> lock(fs_reclaim);
>
> *** DEADLOCK ***
Same here, if I'm not mistaken, it looks like this issue is also due to
nbd introducing a lockdep dependency between reclaim and af_socket, and
this is similar to a previous report:
#syz dup: [syzbot] [mptcp?] possible deadlock in mptcp_subflow_create_socket (2)
If that's not correct, please induplicate it.
I'm not sure how MPTCP is being involved here, I guess it should not and
a simple fix is to forbid it. But maybe this issue is not specific to
MPTCP?
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* Re: [PATCH v3 net-next 13/15] net/sched: sch_cake: annotate data-races in cake_dump_stats()
From: Toke Høiland-Jørgensen @ 2026-04-13 14:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Jamal Hadi Salim, Jiri Pirko, netdev, eric.dumazet
In-Reply-To: <CANn89iJbFUm5NF1Q6WnB17Ufdg8PyFX4msJLVVs4PKRz6XW6yw@mail.gmail.com>
Eric Dumazet <edumazet@google.com> writes:
> On Mon, Apr 13, 2026 at 5:07 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Eric Dumazet <edumazet@google.com> writes:
>>
>> > cake_dump_stats() and cake_dump_class_stats() run without qdisc
>> > spinlock being held.
>> >
>> > Add READ_ONCE()/WRITE_ONCE() annotations.
>> >
>> > Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc")
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>> > Cc: "Toke Høiland-Jørgensen" <toke@toke.dk>
>> > ---
>> > net/sched/sch_cake.c | 404 ++++++++++++++++++++++++-------------------
>> > 1 file changed, 225 insertions(+), 179 deletions(-)
>>
>> One of these diffstats is not like the others - thanks for tackling this :)
>>
>> A few nits below:
>>
>> > diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
>> > index 32e672820c00a88c6d8fe77a6308405e016525ea..f523f0aa4d830e9d3ec4d43bb123e1dc4f8f289d 100644
>> > --- a/net/sched/sch_cake.c
>> > +++ b/net/sched/sch_cake.c
>> > @@ -399,14 +399,14 @@ static void cake_configure_rates(struct Qdisc *sch, u64 rate, bool rate_adjust);
>> > * Here, invsqrt is a fixed point number (< 1.0), 32bit mantissa, aka Q0.32
>> > */
>> >
>> > -static void cobalt_newton_step(struct cobalt_vars *vars)
>> > +static void cobalt_newton_step(struct cobalt_vars *vars, u32 count)
>> > {
>> > u32 invsqrt, invsqrt2;
>> > u64 val;
>> >
>> > invsqrt = vars->rec_inv_sqrt;
>> > invsqrt2 = ((u64)invsqrt * invsqrt) >> 32;
>> > - val = (3LL << 32) - ((u64)vars->count * invsqrt2);
>> > + val = (3LL << 32) - ((u64)count * invsqrt2);
>> >
>> > val >>= 2; /* avoid overflow in following multiply */
>> > val = (val * invsqrt) >> (32 - 2 + 1);
>> > @@ -414,12 +414,12 @@ static void cobalt_newton_step(struct cobalt_vars *vars)
>> > vars->rec_inv_sqrt = val;
>> > }
>> >
>> > -static void cobalt_invsqrt(struct cobalt_vars *vars)
>> > +static void cobalt_invsqrt(struct cobalt_vars *vars, u32 count)
>> > {
>> > - if (vars->count < REC_INV_SQRT_CACHE)
>> > - vars->rec_inv_sqrt = inv_sqrt_cache[vars->count];
>> > + if (count < REC_INV_SQRT_CACHE)
>> > + vars->rec_inv_sqrt = inv_sqrt_cache[count];
>> > else
>> > - cobalt_newton_step(vars);
>> > + cobalt_newton_step(vars, count);
>> > }
>> >
>> > static void cobalt_vars_init(struct cobalt_vars *vars)
>> > @@ -449,16 +449,19 @@ static bool cobalt_queue_full(struct cobalt_vars *vars,
>> > bool up = false;
>> >
>> > if (ktime_to_ns(ktime_sub(now, vars->blue_timer)) > p->target) {
>> > - up = !vars->p_drop;
>> > - vars->p_drop += p->p_inc;
>> > - if (vars->p_drop < p->p_inc)
>> > - vars->p_drop = ~0;
>> > - vars->blue_timer = now;
>> > - }
>> > - vars->dropping = true;
>> > - vars->drop_next = now;
>> > + u32 p_drop = vars->p_drop;
>> > +
>> > + up = !p_drop;
>> > + p_drop += p->p_inc;
>> > + if (p_drop < p->p_inc)
>> > + p_drop = ~0;
>> > + WRITE_ONCE(vars->p_drop, p_drop);
>> > + WRITE_ONCE(vars->blue_timer, now);
>> > + }
>> > + WRITE_ONCE(vars->dropping, true);
>> > + WRITE_ONCE(vars->drop_next, now);
>> > if (!vars->count)
>> > - vars->count = 1;
>> > + WRITE_ONCE(vars->count, 1);
>> >
>> > return up;
>> > }
>> > @@ -474,21 +477,25 @@ static bool cobalt_queue_empty(struct cobalt_vars *vars,
>> >
>> > if (vars->p_drop &&
>> > ktime_to_ns(ktime_sub(now, vars->blue_timer)) > p->target) {
>> > - if (vars->p_drop < p->p_dec)
>> > - vars->p_drop = 0;
>> > + u32 p_drop = vars->p_drop;
>> > +
>> > + if (p_drop < p->p_dec)
>> > + p_drop = 0;
>> > else
>> > - vars->p_drop -= p->p_dec;
>> > - vars->blue_timer = now;
>> > - down = !vars->p_drop;
>> > + p_drop -= p->p_dec;
>> > + WRITE_ONCE(vars->p_drop, p_drop);
>> > + WRITE_ONCE(vars->blue_timer, now);
>> > + down = !p_drop;
>> > }
>> > - vars->dropping = false;
>> > + WRITE_ONCE(vars->dropping, false);
>> >
>> > if (vars->count && ktime_to_ns(ktime_sub(now, vars->drop_next)) >= 0) {
>> > - vars->count--;
>> > - cobalt_invsqrt(vars);
>> > - vars->drop_next = cobalt_control(vars->drop_next,
>> > - p->interval,
>> > - vars->rec_inv_sqrt);
>> > + WRITE_ONCE(vars->count, vars->count - 1);
>> > + cobalt_invsqrt(vars, vars->count);
>> > + WRITE_ONCE(vars->drop_next,
>> > + cobalt_control(vars->drop_next,
>> > + p->interval,
>> > + vars->rec_inv_sqrt));
>> > }
>> >
>> > return down;
>> > @@ -507,6 +514,7 @@ static enum qdisc_drop_reason cobalt_should_drop(struct cobalt_vars *vars,
>> > bool next_due, over_target;
>> > ktime_t schedule;
>> > u64 sojourn;
>> > + u32 count;
>> >
>> > /* The 'schedule' variable records, in its sign, whether 'now' is before or
>> > * after 'drop_next'. This allows 'drop_next' to be updated before the next
>> > @@ -528,45 +536,50 @@ static enum qdisc_drop_reason cobalt_should_drop(struct cobalt_vars *vars,
>> > over_target = sojourn > p->target &&
>> > sojourn > p->mtu_time * bulk_flows * 2 &&
>> > sojourn > p->mtu_time * 4;
>> > - next_due = vars->count && ktime_to_ns(schedule) >= 0;
>> > + count = vars->count;
>> > + next_due = count && ktime_to_ns(schedule) >= 0;
>> >
>> > vars->ecn_marked = false;
>> >
>> > if (over_target) {
>> > if (!vars->dropping) {
>> > - vars->dropping = true;
>> > - vars->drop_next = cobalt_control(now,
>> > - p->interval,
>> > - vars->rec_inv_sqrt);
>> > + WRITE_ONCE(vars->dropping, true);
>> > + WRITE_ONCE(vars->drop_next,
>> > + cobalt_control(now,
>> > + p->interval,
>> > + vars->rec_inv_sqrt));
>> > }
>> > - if (!vars->count)
>> > - vars->count = 1;
>> > + if (!count)
>> > + count = 1;
>> > } else if (vars->dropping) {
>> > - vars->dropping = false;
>> > + WRITE_ONCE(vars->dropping, false);
>> > }
>> >
>> > if (next_due && vars->dropping) {
>> > /* Use ECN mark if possible, otherwise drop */
>> > - if (!(vars->ecn_marked = INET_ECN_set_ce(skb)))
>> > + vars->ecn_marked = INET_ECN_set_ce(skb);
>> > + if (!vars->ecn_marked)
>> > reason = QDISC_DROP_CONGESTED;
>> >
>> > - vars->count++;
>> > - if (!vars->count)
>> > - vars->count--;
>> > - cobalt_invsqrt(vars);
>> > - vars->drop_next = cobalt_control(vars->drop_next,
>> > - p->interval,
>> > - vars->rec_inv_sqrt);
>> > + count++;
>> > + if (!count)
>> > + count--;
>> > + cobalt_invsqrt(vars, count);
>> > + WRITE_ONCE(vars->drop_next,
>> > + cobalt_control(vars->drop_next,
>> > + p->interval,
>> > + vars->rec_inv_sqrt));
>> > schedule = ktime_sub(now, vars->drop_next);
>> > } else {
>> > while (next_due) {
>> > - vars->count--;
>> > - cobalt_invsqrt(vars);
>> > - vars->drop_next = cobalt_control(vars->drop_next,
>> > - p->interval,
>> > - vars->rec_inv_sqrt);
>> > + count--;
>> > + cobalt_invsqrt(vars, count);
>> > + WRITE_ONCE(vars->drop_next,
>> > + cobalt_control(vars->drop_next,
>> > + p->interval,
>> > + vars->rec_inv_sqrt));
>> > schedule = ktime_sub(now, vars->drop_next);
>> > - next_due = vars->count && ktime_to_ns(schedule) >= 0;
>> > + next_due = count && ktime_to_ns(schedule) >= 0;
>> > }
>> > }
>> >
>> > @@ -575,11 +588,12 @@ static enum qdisc_drop_reason cobalt_should_drop(struct cobalt_vars *vars,
>> > get_random_u32() < vars->p_drop)
>> > reason = QDISC_DROP_FLOOD_PROTECTION;
>> >
>> > + WRITE_ONCE(vars->count, count);
>> > /* Overload the drop_next field as an activity timeout */
>> > - if (!vars->count)
>> > - vars->drop_next = ktime_add_ns(now, p->interval);
>> > + if (count)
>>
>> This seems to reverse the conditional?
>
> Ah right, thanks !
>
>>
>> > + WRITE_ONCE(vars->drop_next, ktime_add_ns(now, p->interval));
>> > else if (ktime_to_ns(schedule) > 0 && reason == QDISC_DROP_UNSPEC)
>> > - vars->drop_next = now;
>> > + WRITE_ONCE(vars->drop_next, now);
>> >
>> > return reason;
>> > }
>> > @@ -813,7 +827,7 @@ static u32 cake_hash(struct cake_tin_data *q, const struct sk_buff *skb,
>> > i++, k = (k + 1) % CAKE_SET_WAYS) {
>> > if (q->tags[outer_hash + k] == flow_hash) {
>> > if (i)
>> > - q->way_hits++;
>> > + WRITE_ONCE(q->way_hits, q->way_hits + 1);
>> >
>> > if (!q->flows[outer_hash + k].set) {
>> > /* need to increment host refcnts */
>> > @@ -831,7 +845,7 @@ static u32 cake_hash(struct cake_tin_data *q, const struct sk_buff *skb,
>> > for (i = 0; i < CAKE_SET_WAYS;
>> > i++, k = (k + 1) % CAKE_SET_WAYS) {
>> > if (!q->flows[outer_hash + k].set) {
>> > - q->way_misses++;
>> > + WRITE_ONCE(q->way_misses, q->way_misses + 1);
>> > allocate_src = cake_dsrc(flow_mode);
>> > allocate_dst = cake_ddst(flow_mode);
>> > goto found;
>> > @@ -841,7 +855,7 @@ static u32 cake_hash(struct cake_tin_data *q, const struct sk_buff *skb,
>> > /* With no empty queues, default to the original
>> > * queue, accept the collision, update the host tags.
>> > */
>> > - q->way_collisions++;
>> > + WRITE_ONCE(q->way_collisions, q->way_collisions + 1);
>> > allocate_src = cake_dsrc(flow_mode);
>> > allocate_dst = cake_ddst(flow_mode);
>> >
>> > @@ -875,7 +889,8 @@ static u32 cake_hash(struct cake_tin_data *q, const struct sk_buff *skb,
>> > q->flows[reduced_hash].srchost = srchost_idx;
>> >
>> > if (q->flows[reduced_hash].set == CAKE_SET_BULK)
>> > - cake_inc_srchost_bulk_flow_count(q, &q->flows[reduced_hash], flow_mode);
>> > + cake_inc_srchost_bulk_flow_count(q, &q->flows[reduced_hash],
>> > + flow_mode);
>> > }
>> >
>> > if (allocate_dst) {
>> > @@ -899,7 +914,8 @@ static u32 cake_hash(struct cake_tin_data *q, const struct sk_buff *skb,
>> > q->flows[reduced_hash].dsthost = dsthost_idx;
>> >
>> > if (q->flows[reduced_hash].set == CAKE_SET_BULK)
>> > - cake_inc_dsthost_bulk_flow_count(q, &q->flows[reduced_hash], flow_mode);
>> > + cake_inc_dsthost_bulk_flow_count(q, &q->flows[reduced_hash],
>> > + flow_mode);
>> > }
>> > }
>> >
>> > @@ -1379,9 +1395,9 @@ static u32 cake_calc_overhead(struct cake_sched_data *qd, u32 len, u32 off)
>> > len -= off;
>> >
>> > if (qd->max_netlen < len)
>> > - qd->max_netlen = len;
>> > + WRITE_ONCE(qd->max_netlen, len);
>> > if (qd->min_netlen > len)
>> > - qd->min_netlen = len;
>> > + WRITE_ONCE(qd->min_netlen, len);
>> >
>> > len += q->rate_overhead;
>> >
>> > @@ -1401,9 +1417,9 @@ static u32 cake_calc_overhead(struct cake_sched_data *qd, u32 len, u32 off)
>> > }
>> >
>> > if (qd->max_adjlen < len)
>> > - qd->max_adjlen = len;
>> > + WRITE_ONCE(qd->max_adjlen, len);
>> > if (qd->min_adjlen > len)
>> > - qd->min_adjlen = len;
>> > + WRITE_ONCE(qd->min_adjlen, len);
>> >
>> > return len;
>> > }
>> > @@ -1416,7 +1432,7 @@ static u32 cake_overhead(struct cake_sched_data *q, const struct sk_buff *skb)
>> > u16 segs = qdisc_pkt_segs(skb);
>> > u32 len = qdisc_pkt_len(skb);
>> >
>> > - q->avg_netoff = cake_ewma(q->avg_netoff, off << 16, 8);
>> > + WRITE_ONCE(q->avg_netoff, cake_ewma(q->avg_netoff, off << 16, 8));
>> >
>> > if (segs == 1)
>> > return cake_calc_overhead(q, len, off);
>> > @@ -1590,16 +1606,17 @@ static unsigned int cake_drop(struct Qdisc *sch, struct sk_buff **to_free)
>> > }
>> >
>> > if (cobalt_queue_full(&flow->cvars, &b->cparams, now))
>> > - b->unresponsive_flow_count++;
>> > + WRITE_ONCE(b->unresponsive_flow_count,
>> > + b->unresponsive_flow_count + 1);
>> >
>> > len = qdisc_pkt_len(skb);
>> > q->buffer_used -= skb->truesize;
>> > - b->backlogs[idx] -= len;
>> > - b->tin_backlog -= len;
>> > + WRITE_ONCE(b->backlogs[idx], b->backlogs[idx] - len);
>> > + WRITE_ONCE(b->tin_backlog, b->tin_backlog - len);
>> > qstats_backlog_sub(sch, len);
>> >
>> > - flow->dropped++;
>> > - b->tin_dropped++;
>> > + WRITE_ONCE(flow->dropped, flow->dropped + 1);
>> > + WRITE_ONCE(b->tin_dropped, b->tin_dropped + 1);
>> >
>> > if (q->config->rate_flags & CAKE_FLAG_INGRESS)
>> > cake_advance_shaper(q, b, skb, now, true);
>> > @@ -1795,7 +1812,7 @@ static s32 cake_enqueue(struct sk_buff *skb, struct Qdisc *sch,
>> > }
>> >
>> > if (unlikely(len > b->max_skblen))
>> > - b->max_skblen = len;
>> > + WRITE_ONCE(b->max_skblen, len);
>> >
>> > if (qdisc_pkt_segs(skb) > 1 && q->config->rate_flags & CAKE_FLAG_SPLIT_GSO) {
>> > struct sk_buff *segs, *nskb;
>> > @@ -1819,13 +1836,13 @@ static s32 cake_enqueue(struct sk_buff *skb, struct Qdisc *sch,
>> > numsegs++;
>> > slen += segs->len;
>> > q->buffer_used += segs->truesize;
>> > - b->packets++;
>>
>> Right above this hunk we do sch->q.qlen++; - does that need changing as
>> well?
>
> This was changed to qdisc_qlen_inc() in a prior commit in this series.
> ( net/sched: add qdisc_qlen_inc() and qdisc_qlen_dec() )
Ah, right, missed that; sorry!
>>
>> > }
>> >
>> > /* stats */
>> > - b->bytes += slen;
>> > - b->backlogs[idx] += slen;
>> > - b->tin_backlog += slen;
>> > + WRITE_ONCE(b->bytes, b->bytes + slen);
>> > + WRITE_ONCE(b->packets, b->packets + numsegs);
>> > + WRITE_ONCE(b->backlogs[idx], b->backlogs[idx] + slen);
>> > + WRITE_ONCE(b->tin_backlog, b->tin_backlog + slen);
>> > qstats_backlog_add(sch, slen);
>> > q->avg_window_bytes += slen;
>> >
>> > @@ -1843,10 +1860,10 @@ static s32 cake_enqueue(struct sk_buff *skb, struct Qdisc *sch,
>> > ack = cake_ack_filter(q, flow);
>> >
>> > if (ack) {
>> > - b->ack_drops++;
>> > + WRITE_ONCE(b->ack_drops, b->ack_drops + 1);
>> > qdisc_qstats_drop(sch);
>> > ack_pkt_len = qdisc_pkt_len(ack);
>> > - b->bytes += ack_pkt_len;
>> > + WRITE_ONCE(b->bytes, b->bytes + ack_pkt_len);
>> > q->buffer_used += skb->truesize - ack->truesize;
>> > if (q->config->rate_flags & CAKE_FLAG_INGRESS)
>> > cake_advance_shaper(q, b, ack, now, true);
>> > @@ -1859,10 +1876,10 @@ static s32 cake_enqueue(struct sk_buff *skb, struct Qdisc *sch,
>> > }
>> >
>> > /* stats */
>> > - b->packets++;
>> > - b->bytes += len - ack_pkt_len;
>> > - b->backlogs[idx] += len - ack_pkt_len;
>> > - b->tin_backlog += len - ack_pkt_len;
>> > + WRITE_ONCE(b->packets, b->packets + 1);
>> > + WRITE_ONCE(b->bytes, b->bytes + len - ack_pkt_len);
>> > + WRITE_ONCE(b->backlogs[idx], b->backlogs[idx] + len - ack_pkt_len);
>> > + WRITE_ONCE(b->tin_backlog, b->tin_backlog + len - ack_pkt_len);
>> > qstats_backlog_add(sch, len - ack_pkt_len);
>> > q->avg_window_bytes += len - ack_pkt_len;
>> > }
>> > @@ -1894,9 +1911,9 @@ static s32 cake_enqueue(struct sk_buff *skb, struct Qdisc *sch,
>> > u64 b = q->avg_window_bytes * (u64)NSEC_PER_SEC;
>> >
>> > b = div64_u64(b, window_interval);
>> > - q->avg_peak_bandwidth =
>> > - cake_ewma(q->avg_peak_bandwidth, b,
>> > - b > q->avg_peak_bandwidth ? 2 : 8);
>> > + WRITE_ONCE(q->avg_peak_bandwidth,
>> > + cake_ewma(q->avg_peak_bandwidth, b,
>> > + b > q->avg_peak_bandwidth ? 2 : 8));
>> > q->avg_window_bytes = 0;
>> > q->avg_window_begin = now;
>> >
>> > @@ -1917,27 +1934,30 @@ static s32 cake_enqueue(struct sk_buff *skb, struct Qdisc *sch,
>> > if (!flow->set) {
>> > list_add_tail(&flow->flowchain, &b->new_flows);
>> > } else {
>> > - b->decaying_flow_count--;
>> > + WRITE_ONCE(b->decaying_flow_count,
>> > + b->decaying_flow_count - 1);
>> > list_move_tail(&flow->flowchain, &b->new_flows);
>> > }
>> > flow->set = CAKE_SET_SPARSE;
>> > - b->sparse_flow_count++;
>> > + WRITE_ONCE(b->sparse_flow_count,
>> > + b->sparse_flow_count + 1);
>> >
>> > - flow->deficit = cake_get_flow_quantum(b, flow, q->config->flow_mode);
>> > + WRITE_ONCE(flow->deficit,
>> > + cake_get_flow_quantum(b, flow, q->config->flow_mode));
>> > } else if (flow->set == CAKE_SET_SPARSE_WAIT) {
>> > /* this flow was empty, accounted as a sparse flow, but actually
>> > * in the bulk rotation.
>> > */
>> > flow->set = CAKE_SET_BULK;
>> > - b->sparse_flow_count--;
>> > - b->bulk_flow_count++;
>> > + WRITE_ONCE(b->sparse_flow_count, b->sparse_flow_count - 1);
>> > + WRITE_ONCE(b->bulk_flow_count, b->bulk_flow_count + 1);
>> >
>> > cake_inc_srchost_bulk_flow_count(b, flow, q->config->flow_mode);
>> > cake_inc_dsthost_bulk_flow_count(b, flow, q->config->flow_mode);
>> > }
>> >
>> > if (q->buffer_used > q->buffer_max_used)
>> > - q->buffer_max_used = q->buffer_used;
>> > + WRITE_ONCE(q->buffer_max_used, q->buffer_used);
>> >
>> > if (q->buffer_used <= q->buffer_limit)
>> > return NET_XMIT_SUCCESS;
>> > @@ -1976,8 +1996,8 @@ static struct sk_buff *cake_dequeue_one(struct Qdisc *sch)
>> > if (flow->head) {
>> > skb = dequeue_head(flow);
>> > len = qdisc_pkt_len(skb);
>> > - b->backlogs[q->cur_flow] -= len;
>> > - b->tin_backlog -= len;
>> > + WRITE_ONCE(b->backlogs[q->cur_flow], b->backlogs[q->cur_flow] - len);
>> > + WRITE_ONCE(b->tin_backlog, b->tin_backlog - len);
>> > qstats_backlog_sub(sch, len);
>> > q->buffer_used -= skb->truesize;
>> > qdisc_qlen_dec(sch);
>> > @@ -2042,7 +2062,7 @@ static struct sk_buff *cake_dequeue(struct Qdisc *sch)
>> >
>> > cake_configure_rates(sch, new_rate, true);
>> > q->last_checked_active = now;
>> > - q->active_queues = num_active_qs;
>> > + WRITE_ONCE(q->active_queues, num_active_qs);
>> > }
>> >
>> > begin:
>> > @@ -2149,8 +2169,10 @@ static struct sk_buff *cake_dequeue(struct Qdisc *sch)
>> > */
>> > if (flow->set == CAKE_SET_SPARSE) {
>> > if (flow->head) {
>> > - b->sparse_flow_count--;
>> > - b->bulk_flow_count++;
>> > + WRITE_ONCE(b->sparse_flow_count,
>> > + b->sparse_flow_count - 1);
>> > + WRITE_ONCE(b->bulk_flow_count,
>> > + b->bulk_flow_count + 1);
>> >
>> > cake_inc_srchost_bulk_flow_count(b, flow, q->config->flow_mode);
>> > cake_inc_dsthost_bulk_flow_count(b, flow, q->config->flow_mode);
>> > @@ -2165,7 +2187,8 @@ static struct sk_buff *cake_dequeue(struct Qdisc *sch)
>> > }
>> > }
>> >
>> > - flow->deficit += cake_get_flow_quantum(b, flow, q->config->flow_mode);
>> > + WRITE_ONCE(flow->deficit,
>> > + flow->deficit + cake_get_flow_quantum(b, flow, q->config->flow_mode));
>> > list_move_tail(&flow->flowchain, &b->old_flows);
>> >
>> > goto retry;
>> > @@ -2177,7 +2200,8 @@ static struct sk_buff *cake_dequeue(struct Qdisc *sch)
>> > if (!skb) {
>> > /* this queue was actually empty */
>> > if (cobalt_queue_empty(&flow->cvars, &b->cparams, now))
>> > - b->unresponsive_flow_count--;
>> > + WRITE_ONCE(b->unresponsive_flow_count,
>> > + b->unresponsive_flow_count - 1);
>> >
>> > if (flow->cvars.p_drop || flow->cvars.count ||
>> > ktime_before(now, flow->cvars.drop_next)) {
>> > @@ -2187,16 +2211,22 @@ static struct sk_buff *cake_dequeue(struct Qdisc *sch)
>> > list_move_tail(&flow->flowchain,
>> > &b->decaying_flows);
>> > if (flow->set == CAKE_SET_BULK) {
>> > - b->bulk_flow_count--;
>> > + WRITE_ONCE(b->bulk_flow_count,
>> > + b->bulk_flow_count - 1);
>> >
>> > - cake_dec_srchost_bulk_flow_count(b, flow, q->config->flow_mode);
>> > - cake_dec_dsthost_bulk_flow_count(b, flow, q->config->flow_mode);
>> > + cake_dec_srchost_bulk_flow_count(b, flow,
>> > + q->config->flow_mode);
>> > + cake_dec_dsthost_bulk_flow_count(b, flow,
>> > + q->config->flow_mode);
>>
>> These seem like unnecessary whitespace changes?
>
> Line length was 105 ... a bit over the recommended limit.
Right, do realise that, but I personally find the one-liners more
readable even if they are a bit long. Won't insist, though; it's just
whitespace, after all :)
-Toke
^ permalink raw reply
* Re: [GIT PULL] bluetooth-next 2026-04-13
From: Luiz Augusto von Dentz @ 2026-04-13 14:17 UTC (permalink / raw)
To: Paolo Abeni; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <CABBYNZK5mMbuzvjAquy49vSk0pLRnk_s8oqEut1se4DToURn9A@mail.gmail.com>
Hi,
On Mon, Apr 13, 2026 at 10:11 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Paolo,
>
> 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?
> > Thanks,
> >
> > /P
> >
>
>
> --
> Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [GIT PULL] bluetooth-next 2026-04-13
From: Luiz Augusto von Dentz @ 2026-04-13 14:11 UTC (permalink / raw)
To: Paolo Abeni; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <580f7972-56d5-4968-9dcc-32adc31e0673@redhat.com>
Hi Paolo,
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?
> Thanks,
>
> /P
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH net] ice: Fix missing 1's complement negation in GCS raw checksum
From: Simon Horman @ 2026-04-13 14:11 UTC (permalink / raw)
To: Matt Fleming
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel, kernel-team, Matt Fleming
In-Reply-To: <20260408190214.1287708-1-matt@readmodwrite.com>
On Wed, Apr 08, 2026 at 08:02:14PM +0100, Matt Fleming wrote:
> From: Matt Fleming <mfleming@cloudflare.com>
>
> Commit 905d1a220e8d ("ice: Add E830 checksum offload support") added
> Generic Checksum (GCS) support for E830 NICs but omitted the 1's
> complement negation (~) when converting the hardware raw_csum to
> skb->csum for CHECKSUM_COMPLETE.
>
> Without the negation, every CHECKSUM_COMPLETE packet fails the
> fast-path validation in nf_ip_checksum() and falls through to software
> checksumming via __skb_checksum_complete(), which triggers the
> rate-limited "hw csum failure" warning. Packets are still accepted
> (the software recheck passes) but hardware checksum offload is
> effectively disabled and the warning floods dmesg on systems running
> nf_conntrack on VLAN sub-interfaces.
>
> Multiple other drivers (idpf, ehea, iwlwifi, cassini, sunhme, enetc)
> also apply ~ for CHECKSUM_COMPLETE. The ice driver was the only in-tree
> user of csum_unfold() for CHECKSUM_COMPLETE that omitted it.
>
> Fixes: 905d1a220e8d ("ice: Add E830 checksum offload support")
> Signed-off-by: Matt Fleming <mfleming@cloudflare.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH iwl-net v2 6/6] ixgbe: fix integer overflow and wrong bit position in ixgbe_validate_rtr()
From: Simon Horman @ 2026-04-13 14:03 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: 'Simon Horman', intel-wired-lan, anthony.l.nguyen, netdev,
stable
In-Reply-To: <20260408131154.2661818-7-aleksandr.loktionov@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
---
ixgbe: fix integer overflow and wrong bit position in ixgbe_validate_rtr()
This commit fixes two bugs in ixgbe_validate_rtr() by masking the
traffic-class field properly before assigning it to a u8, and correctly
shifting the mask for clearing out-of-bounds entries.
Cc: stable@vger.kernel.org
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 5ff462a848feb..8ebf717ce4017 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -9782,11 +9782,12 @@ static void ixgbe_validate_rtr(struct ixgbe_adapter *adapter, u8 tc)
> rsave = reg;
>
> for (i = 0; i < MAX_TRAFFIC_CLASS; i++) {
> - u8 up2tc = reg >> (i * IXGBE_RTRUP2TC_UP_SHIFT);
> + u8 up2tc = (reg >> (i * IXGBE_RTRUP2TC_UP_SHIFT)) &
> + IXGBE_RTRUP2TC_UP_MASK;
>
> /* If up2tc is out of bounds default to zero */
> if (up2tc > tc)
This wasn't introduced by this patch, but is there a pre-existing off-by-one
error in this bounds check?
If tc represents the number of enabled traffic classes (e.g., 4), the valid TC
indices would be 0 through tc - 1. If up2tc equals tc, it would be out of
bounds, but the condition up2tc > tc will evaluate to false and the invalid
mapping won't be cleared.
Could this allow an invalid UP-to-TC mapping to persist in the hardware
register, potentially causing received packets to be mis-steered to an
uninitialized or non-existent traffic class queue?
Should the condition be corrected to ensure up2tc is strictly less than tc
when tc > 0?
> - reg &= ~(0x7 << IXGBE_RTRUP2TC_UP_SHIFT);
> + reg &= ~(IXGBE_RTRUP2TC_UP_MASK << (i * IXGBE_RTRUP2TC_UP_SHIFT));
> }
^ permalink raw reply
* Re: [PATCH iwl-net v2 6/6] ixgbe: fix integer overflow and wrong bit position in ixgbe_validate_rtr()
From: Simon Horman @ 2026-04-13 14:02 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260413134334.GP469338@kernel.org>
On Mon, Apr 13, 2026 at 02:43:34PM +0100, Simon Horman wrote:
> On Wed, Apr 08, 2026 at 03:11:54PM +0200, Aleksandr Loktionov wrote:
> > Two bugs in the same loop in ixgbe_validate_rtr():
> >
> > 1. The 3-bit traffic-class field was extracted by shifting a u32 and
> > assigning the result directly to a u8. For user priority 0 this is
> > harmless; for UP[5..7] the shift leaves bits [15..21] in the u32
> > which are then silently truncated when stored in u8. Mask with
> > IXGBE_RTRUP2TC_UP_MASK before the assignment so only the intended
> > 3 bits are kept.
> >
> > 2. When clearing an out-of-bounds entry the mask was always shifted by
> > the fixed constant IXGBE_RTRUP2TC_UP_SHIFT (== 3), regardless of
> > which loop iteration was being processed. This means only UP1 (bit
> > position 3) was ever cleared; UP0,2..7 (positions 0, 6, 9, ..., 21)
> > were left unreset, so invalid TC mappings persisted in hardware and
> > could mis-steer received packets to the wrong traffic class.
> > Use i * IXGBE_RTRUP2TC_UP_SHIFT to target the correct 3-bit field
> > for each iteration.
> >
> > Swap the operand order in the mask expression to place the constant
> > on the right per kernel coding style (noted by David Laight).
> >
> > Fixes: e7589eab9291 ("ixgbe: consolidate, setup for multiple traffic classes")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > ---
> > v1 -> v2:
> > - Add Fixes: tag; reroute to iwl-net (wrong bit positions cause packet
> > mis-steering); swap to (reg >> ...) & MASK operand order per David
> > Laight.
>
> Reviewed-by: Simon Horman <horms@kernel.org>
Sorry, I was a little too hasty there.
AI generated code review points out that the cited commit
doesn't seem to have introduced the code being fixed,
and that perhaps this Fixes tag would be more appropriate.
Fixes: 8b1c0b24d9af ("ixgbe: configure minimal packet buffers to support TC")
I will also forward on a review from Sashiko, although it
is for an existing bug and thus is strictly FYI.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Mark Brown @ 2026-04-13 13:50 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, Paolo Abeni, Networking
Cc: Fernando Fernandez Mancera, Jesper Dangaard Brouer,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
include/net/sch_generic.h
between commit:
a6bd339dbb351 ("net_sched: fix skb memory leak in deferred qdisc drops")
from the net tree and commit:
ff2998f29f390 ("net: sched: introduce qdisc-specific drop reason tracing")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc include/net/sch_generic.h
index 5fc0b1ebaf25c,5af262ec4bbd2..0000000000000
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@@ -1168,24 -1185,14 +1185,24 @@@ static inline void tcf_kfree_skb_list(s
}
static inline void qdisc_dequeue_drop(struct Qdisc *q, struct sk_buff *skb,
- enum skb_drop_reason reason)
+ enum qdisc_drop_reason reason)
{
+ struct Qdisc *root;
+
DEBUG_NET_WARN_ON_ONCE(!(q->flags & TCQ_F_DEQUEUE_DROPS));
DEBUG_NET_WARN_ON_ONCE(q->flags & TCQ_F_NOLOCK);
- tcf_set_qdisc_drop_reason(skb, reason);
- skb->next = q->to_free;
- q->to_free = skb;
+ rcu_read_lock();
+ root = qdisc_root_sleeping(q);
+
+ if (root->flags & TCQ_F_DEQUEUE_DROPS) {
- tcf_set_drop_reason(skb, reason);
++ tcf_set_qdisc_drop_reason(skb, reason);
+ skb->next = root->to_free;
+ root->to_free = skb;
+ } else {
+ kfree_skb_reason(skb, (enum skb_drop_reason)reason);
+ }
+ rcu_read_unlock();
}
/* Instead of calling kfree_skb() while root qdisc lock is held,
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [patch 14/38] slub: Use prandom instead of get_cycles()
From: Vlastimil Babka (SUSE) @ 2026-04-13 13:45 UTC (permalink / raw)
To: hu.shengming, harry
Cc: tglx, linux-kernel, linux-mm, arnd, x86, baolu.lu, iommu,
m.grzeschik, netdev, linux-wireless, herbert, linux-crypto, dwmw2,
bernie, linux-fbdev, tytso, linux-ext4, akpm, urezki, elver,
dvyukov, kasan-dev, ryabinin.a.a, t.sailer, linux-hams, Jason,
richard.henderson, linux-alpha, linux, linux-arm-kernel,
catalin.marinas, chenhuacai, loongarch, geert, linux-m68k,
dinguyen, jonas, linux-openrisc, deller, linux-parisc, mpe,
linuxppc-dev, pjw, linux-riscv, hca, linux-s390, davem,
sparclinux, hao.li, cl, rientjes, roman.gushchin
In-Reply-To: <20260413210252672ZfdcegJLJtyvlYdFAUBlr@zte.com.cn>
On 4/13/26 15:02, hu.shengming@zte.com.cn wrote:
> Harry wrote:
>> [Resending after fixing broken email headers]
>>
>> On Fri, Apr 10, 2026 at 02:19:37PM +0200, Thomas Gleixner wrote:
>> > The decision whether to scan remote nodes is based on a 'random' number
>> > retrieved via get_cycles(). get_cycles() is about to be removed.
>> >
>> > There is already prandom state in the code, so use that instead.
>> >
>> > Signed-off-by: Thomas Gleixner <tglx@kernel.org>
>> > Cc: Vlastimil Babka <vbabka@kernel.org>
>> > Cc: linux-mm@kvack.org
>> > ---
>>
>> Acked-by: Harry Yoo (Oracle) <harry@kernel.org>
>>
>> Is this for this merge window?
I'd say it's not intended for 7.1 as it's not in -next and v1 was posted
just before the merge window.
>> This may conflict with upcoming changes on freelist shuffling [1]
>> (not queued for slab/for-next yet though), but it should be easy to
>> resolve.
Indeed, it's a simple conflict.
>
> Hi Harry,
>
> Would you like me to wait for this patch to land linux-next and then
> rebase and send v6 on top?
Just send it now based same as previously so we can finish the reviews, and
we'll deal with it after rc1.
^ 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