- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] bpf: Avoid RCU context warning when unpinning htab with internal structs
by Luo Gengkun 24 Nov '25

24 Nov '25

From: KaFai Wan <kafai.wan(a)linux.dev> stable inclusion from stable-v6.6.113 commit b6e9645be9eb93f7aff3ca887f8edb6f1d63358f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID8BLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit 4f375ade6aa9f37fd72d7a78682f639772089eed ] When unpinning a BPF hash table (htab or htab_lru) that contains internal structures (timer, workqueue, or task_work) in its values, a BUG warning is triggered: BUG: sleeping function called from invalid context at kernel/bpf/hashtab.c:244 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 14, name: ksoftirqd/0 ... The issue arises from the interaction between BPF object unpinning and RCU callback mechanisms: 1. BPF object unpinning uses ->free_inode() which schedules cleanup via call_rcu(), deferring the actual freeing to an RCU callback that executes within the RCU_SOFTIRQ context. 2. During cleanup of hash tables containing internal structures, htab_map_free_internal_structs() is invoked, which includes cond_resched() or cond_resched_rcu() calls to yield the CPU during potentially long operations. However, cond_resched() or cond_resched_rcu() cannot be safely called from atomic RCU softirq context, leading to the BUG warning when attempting to reschedule. Fix this by changing from ->free_inode() to ->destroy_inode() and rename bpf_free_inode() to bpf_destroy_inode() for BPF objects (prog, map, link). This allows direct inode freeing without RCU callback scheduling, avoiding the invalid context warning. Reported-by: Le Chen <tom2cat(a)sjtu.edu.cn> Closes: https://lore.kernel.org/all/1444123482.1827743.1750996347470.JavaMail.zimbr… Fixes: 68134668c17f ("bpf: Add map side support for bpf timers.") Suggested-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: KaFai Wan <kafai.wan(a)linux.dev> Acked-by: Yonghong Song <yonghong.song(a)linux.dev> Link: https://lore.kernel.org/r/20251008102628.808045-2-kafai.wan@linux.dev Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/bpf/inode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c index 99d0625b6c82..9a9630adcba4 100644 --- a/kernel/bpf/inode.c +++ b/kernel/bpf/inode.c @@ -607,7 +607,7 @@ static int bpf_show_options(struct seq_file *m, struct dentry *root) return 0; } -static void bpf_free_inode(struct inode *inode) +static void bpf_destroy_inode(struct inode *inode) { enum bpf_type type; @@ -622,7 +622,7 @@ static const struct super_operations bpf_super_ops = { .statfs = simple_statfs, .drop_inode = generic_delete_inode, .show_options = bpf_show_options, - .free_inode = bpf_free_inode, + .destroy_inode = bpf_destroy_inode, }; enum { -- 2.34.1

2 1

[PATCH OLK-6.6] sunrpc: fix null pointer dereference on zero-length checksum
by Wang Liang 24 Nov '25

24 Nov '25

From: Lei Lu <llfamsec(a)gmail.com> stable inclusion from stable-v6.6.112 commit 81cec07d303186d0d8c623ef8b5ecd3b81e94cf6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID6B5E CVE: CVE-2025-40129 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 6df164e29bd4e6505c5a2e0e5f1e1f6957a16a42 upstream. In xdr_stream_decode_opaque_auth(), zero-length checksum.len causes checksum.data to be set to NULL. This triggers a NPD when accessing checksum.data in gss_krb5_verify_mic_v2(). This patch ensures that the value of checksum.len is not less than XDR_UNIT. Fixes: 0653028e8f1c ("SUNRPC: Convert gss_verify_header() to use xdr_stream") Cc: stable(a)kernel.org Signed-off-by: Lei Lu <llfamsec(a)gmail.com> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Liang <wangliang74(a)huawei.com> --- net/sunrpc/auth_gss/svcauth_gss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c index cf30bd649e27..d063b63516f8 100644 --- a/net/sunrpc/auth_gss/svcauth_gss.c +++ b/net/sunrpc/auth_gss/svcauth_gss.c @@ -724,7 +724,7 @@ svcauth_gss_verify_header(struct svc_rqst *rqstp, struct rsc *rsci, rqstp->rq_auth_stat = rpc_autherr_badverf; return SVC_DENIED; } - if (flavor != RPC_AUTH_GSS) { + if (flavor != RPC_AUTH_GSS || checksum.len < XDR_UNIT) { rqstp->rq_auth_stat = rpc_autherr_badverf; return SVC_DENIED; } -- 2.34.1

2 1

[PATCH OLK-5.10] bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}
by Wang Liang 24 Nov '25

24 Nov '25

From: Daniel Borkmann <daniel(a)iogearbox.net> stable inclusion from stable-v5.10.246 commit 3fba965a9aac0fa3cbd8138436a37af9ab466d79 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID6BVH CVE: CVE-2025-40183 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 23f3770e1a53e6c7a553135011f547209e141e72 ] Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster. The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing. The issue was that vxlan allocates the metadata_dst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpf_redirect_neigh() was merely setting the new dst entry via skb_dst_set() without dropping an existing one first. Fixes: b4ab31414970 ("bpf: Add redirect_neigh helper as redirect drop-in") Reported-by: Yusuke Suzuki <yusuke.suzuki(a)isovalent.com> Reported-by: Julian Wiedmann <jwi(a)isovalent.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Cc: Martin KaFai Lau <martin.lau(a)kernel.org> Cc: Jakub Kicinski <kuba(a)kernel.org> Cc: Jordan Rife <jrife(a)google.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Jordan Rife <jrife(a)google.com> Reviewed-by: Jakub Kicinski <kuba(a)kernel.org> Reviewed-by: Martin KaFai Lau <martin.lau(a)kernel.org> Link: https://lore.kernel.org/r/20251003073418.291171-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Liang <wangliang74(a)huawei.com> --- net/core/filter.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/core/filter.c b/net/core/filter.c index d3e64273b3c4..adacca9ee505 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -2256,6 +2256,7 @@ static int __bpf_redirect_neigh_v6(struct sk_buff *skb, struct net_device *dev, if (IS_ERR(dst)) goto out_drop; + skb_dst_drop(skb); skb_dst_set(skb, dst); } else if (nh->nh_family != AF_INET6) { goto out_drop; @@ -2371,6 +2372,7 @@ static int __bpf_redirect_neigh_v4(struct sk_buff *skb, struct net_device *dev, goto out_drop; } + skb_dst_drop(skb); skb_dst_set(skb, &rt->dst); } -- 2.34.1

2 1

[PATCH OLK-6.6] bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}
by Wang Liang 24 Nov '25

24 Nov '25

From: Daniel Borkmann <daniel(a)iogearbox.net> stable inclusion from stable-v6.6.113 commit b6bfe44b6dbb14a31d86c475cdc9c7689534fb09 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID6BVH CVE: CVE-2025-40183 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 23f3770e1a53e6c7a553135011f547209e141e72 ] Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster. The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing. The issue was that vxlan allocates the metadata_dst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpf_redirect_neigh() was merely setting the new dst entry via skb_dst_set() without dropping an existing one first. Fixes: b4ab31414970 ("bpf: Add redirect_neigh helper as redirect drop-in") Reported-by: Yusuke Suzuki <yusuke.suzuki(a)isovalent.com> Reported-by: Julian Wiedmann <jwi(a)isovalent.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Cc: Martin KaFai Lau <martin.lau(a)kernel.org> Cc: Jakub Kicinski <kuba(a)kernel.org> Cc: Jordan Rife <jrife(a)google.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Jordan Rife <jrife(a)google.com> Reviewed-by: Jakub Kicinski <kuba(a)kernel.org> Reviewed-by: Martin KaFai Lau <martin.lau(a)kernel.org> Link: https://lore.kernel.org/r/20251003073418.291171-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Liang <wangliang74(a)huawei.com> --- net/core/filter.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/core/filter.c b/net/core/filter.c index 8e5803fbf16e..eee64a67df40 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -2272,6 +2272,7 @@ static int __bpf_redirect_neigh_v6(struct sk_buff *skb, struct net_device *dev, if (IS_ERR(dst)) goto out_drop; + skb_dst_drop(skb); skb_dst_set(skb, dst); } else if (nh->nh_family != AF_INET6) { goto out_drop; @@ -2381,6 +2382,7 @@ static int __bpf_redirect_neigh_v4(struct sk_buff *skb, struct net_device *dev, goto out_drop; } + skb_dst_drop(skb); skb_dst_set(skb, &rt->dst); } -- 2.34.1

2 1

[PATCH OLK-6.6] net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()
by Wang Liang 24 Nov '25

24 Nov '25

From: Alexandr Sapozhnikov <alsp705(a)gmail.com> stable inclusion from stable-v6.6.113 commit c21f45cfa4a9526b34d76b397c9ef080668b6e73 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID6BVQ CVE: CVE-2025-40187 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 2f3119686ef50319490ccaec81a575973da98815 ] If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0 and sctp_ulpevent_make_authkey() returns 0, then the variable ai_ev remains zero and the zero will be dereferenced in the sctp_ulpevent_free() function. Signed-off-by: Alexandr Sapozhnikov <alsp705(a)gmail.com> Acked-by: Xin Long <lucien.xin(a)gmail.com> Fixes: 30f6ebf65bc4 ("sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT") Link: https://patch.msgid.link/20251002091448.11-1-alsp705@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Liang <wangliang74(a)huawei.com> --- net/sctp/sm_statefuns.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c index 808863e047e0..2d88654e8d8e 100644 --- a/net/sctp/sm_statefuns.c +++ b/net/sctp/sm_statefuns.c @@ -884,7 +884,8 @@ enum sctp_disposition sctp_sf_do_5_1D_ce(struct net *net, return SCTP_DISPOSITION_CONSUME; nomem_authev: - sctp_ulpevent_free(ai_ev); + if (ai_ev) + sctp_ulpevent_free(ai_ev); nomem_aiev: sctp_ulpevent_free(ev); nomem_ev: -- 2.34.1

2 1

[PATCH OLK-6.6] sctp: Fix MAC comparison to be constant-time
by Wang Liang 24 Nov '25

24 Nov '25

From: Eric Biggers <ebiggers(a)kernel.org> stable inclusion from stable-v6.6.113 commit ed3044b9c810c5c24eb2830053fbfe5fd134c5d4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID6BW6 CVE: CVE-2025-40204 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit dd91c79e4f58fbe2898dac84858033700e0e99fb upstream. To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> Link: https://patch.msgid.link/20250818205426.30222-3-ebiggers@kernel.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Liang <wangliang74(a)huawei.com> --- net/sctp/sm_make_chunk.c | 3 ++- net/sctp/sm_statefuns.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index 08527d882e56..eb2ed7db3fe1 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -31,6 +31,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include <crypto/hash.h> +#include <crypto/utils.h> #include <linux/types.h> #include <linux/kernel.h> #include <linux/ip.h> @@ -1796,7 +1797,7 @@ struct sctp_association *sctp_unpack_cookie( } } - if (memcmp(digest, cookie->signature, SCTP_SIGNATURE_SIZE)) { + if (crypto_memneq(digest, cookie->signature, SCTP_SIGNATURE_SIZE)) { *error = -SCTP_IERROR_BAD_SIG; goto fail; } diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c index 808863e047e0..34b257d88b65 100644 --- a/net/sctp/sm_statefuns.c +++ b/net/sctp/sm_statefuns.c @@ -30,6 +30,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt +#include <crypto/utils.h> #include <linux/types.h> #include <linux/kernel.h> #include <linux/ip.h> @@ -4415,7 +4416,7 @@ static enum sctp_ierror sctp_sf_authenticate( sh_key, GFP_ATOMIC); /* Discard the packet if the digests do not match */ - if (memcmp(save_digest, digest, sig_len)) { + if (crypto_memneq(save_digest, digest, sig_len)) { kfree(save_digest); return SCTP_IERROR_BAD_SIG; } -- 2.34.1

2 1

[PATCH OLK-5.10] NFSv4: Fix deadlock during the running of state manager
by Li Lingfeng 24 Nov '25

24 Nov '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBAFF1 -------------------------------- Unlinking file may cause the following deadlock in state manager: [root@localhost test]# cat /proc/2943/stack [<0>] rpc_wait_bit_killable+0x1a/0x90 [<0>] _nfs4_proc_delegreturn+0x60f/0x760 [<0>] nfs4_proc_delegreturn+0x13d/0x2a0 [<0>] nfs_do_return_delegation+0xba/0x110 [<0>] nfs_end_delegation_return+0x32c/0x620 [<0>] nfs_complete_unlink+0xc7/0x290 [<0>] nfs_dentry_iput+0x36/0x50 [<0>] __dentry_kill+0xaa/0x250 [<0>] dput.part.0+0x26c/0x4d0 [<0>] __put_nfs_open_context+0x1d9/0x260 [<0>] nfs4_open_reclaim+0x77/0xa0 [<0>] nfs4_do_reclaim+0x385/0xf40 [<0>] nfs4_state_manager+0x762/0x14e0 [<0>] nfs4_run_state_manager+0x181/0x330 [<0>] kthread+0x1a7/0x1f0 [<0>] ret_from_fork+0x34/0x60 [<0>] ret_from_fork_asm+0x1a/0x30 [root@localhost test]# It can be reproduced by following steps: 1) client: open file 2) client: unlink file 3) server: service restart(trigger state manager in client) 4) client: close file(in nfs4_open_reclaim, between nfs4_do_open_reclaim and put_nfs_open_context) Since the file has been open, unlinking will just set DCACHE_NFSFS_RENAMED for the dentry like this: nfs_unlink nfs_sillyrename nfs_async_unlink // set DCACHE_NFSFS_RENAMED Restarting service will trigger state manager in client. (1) NFS4_SLOT_TBL_DRAINING will be set to nfs4_slot_table since session has been reset. (2) DCACHE_NFSFS_RENAMED is detected in nfs_dentry_iput. Therefore, nfs_complete_unlink is called to trigger delegation return. (3) Due to the slot table being in draining state and sa_privileged being 0, the delegation return will be queued and wait. nfs4_state_manager nfs4_reset_session nfs4_begin_drain_session nfs4_drain_slot_tbl // set NFS4_SLOT_TBL_DRAINING (1) nfs4_do_reclaim nfs4_open_reclaim __put_nfs_open_context __dentry_kill nfs_dentry_iput // check DCACHE_NFSFS_RENAMED (2) nfs_complete_unlink nfs_end_delegation_return nfs_do_return_delegation nfs4_proc_delegreturn _nfs4_proc_delegreturn rpc_run_task ... nfs4_delegreturn_prepare nfs4_setup_sequence nfs4_slot_tbl_draining // check NFS4_SLOT_TBL_DRAINING // and sa_privileged is 0 (3) rpc_sleep_on // set queued and add to slot_tbl_waitq // rpc_task is async and wait in __rpc_execute rpc_wait_for_completion_task __rpc_wait_for_completion_task out_of_line_wait_on_bit rpc_wait_bit_killable // wait for rpc_task to complete <-------- can not get here to wake up rpc_task --------> nfs4_end_drain_session nfs4_end_drain_slot_table nfs41_wake_slot_table On the one hand, the state manager is blocked by the unfinished delegation return. As a result, nfs4_end_drain_session cannot be invoked to clear NFS4_SLOT_TBL_DRAINING and wake up waiting tasks. On the other hand, since NFS4_SLOT_TBL_DRAINING is not cleared, delegation return can only wait in the queue, resulting in a deadlock. Fix it by turning the delegation return into a privileged operation for the case where the nfs_client is in NFS4CLNT_RECLAIM_REBOOT state. Fixes: 977fcc2b0b41 ("NFS: Add a delegation return into nfs4_proc_unlink_setup()") Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfs/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 349994e18fd6..35c15d20a84e 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -6571,7 +6571,7 @@ static int _nfs4_proc_delegreturn(struct inode *inode, const struct cred *cred, } } - if (!data->inode) + if (!data->inode || test_bit(NFS4CLNT_RECLAIM_REBOOT, &server->nfs_client->cl_state)) nfs4_init_sequence(&data->args.seq_args, &data->res.seq_res, 1, 1); else -- 2.46.1

2 1

[PATCH OLK-6.6] NFSv4: Fix deadlock during the running of state manager
by Li Lingfeng 24 Nov '25

24 Nov '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBAFF1 -------------------------------- Unlinking file may cause the following deadlock in state manager: [root@localhost test]# cat /proc/2943/stack [<0>] rpc_wait_bit_killable+0x1a/0x90 [<0>] _nfs4_proc_delegreturn+0x60f/0x760 [<0>] nfs4_proc_delegreturn+0x13d/0x2a0 [<0>] nfs_do_return_delegation+0xba/0x110 [<0>] nfs_end_delegation_return+0x32c/0x620 [<0>] nfs_complete_unlink+0xc7/0x290 [<0>] nfs_dentry_iput+0x36/0x50 [<0>] __dentry_kill+0xaa/0x250 [<0>] dput.part.0+0x26c/0x4d0 [<0>] __put_nfs_open_context+0x1d9/0x260 [<0>] nfs4_open_reclaim+0x77/0xa0 [<0>] nfs4_do_reclaim+0x385/0xf40 [<0>] nfs4_state_manager+0x762/0x14e0 [<0>] nfs4_run_state_manager+0x181/0x330 [<0>] kthread+0x1a7/0x1f0 [<0>] ret_from_fork+0x34/0x60 [<0>] ret_from_fork_asm+0x1a/0x30 [root@localhost test]# It can be reproduced by following steps: 1) client: open file 2) client: unlink file 3) server: service restart(trigger state manager in client) 4) client: close file(in nfs4_open_reclaim, between nfs4_do_open_reclaim and put_nfs_open_context) Since the file has been open, unlinking will just set DCACHE_NFSFS_RENAMED for the dentry like this: nfs_unlink nfs_sillyrename nfs_async_unlink // set DCACHE_NFSFS_RENAMED Restarting service will trigger state manager in client. (1) NFS4_SLOT_TBL_DRAINING will be set to nfs4_slot_table since session has been reset. (2) DCACHE_NFSFS_RENAMED is detected in nfs_dentry_iput. Therefore, nfs_complete_unlink is called to trigger delegation return. (3) Due to the slot table being in draining state and sa_privileged being 0, the delegation return will be queued and wait. nfs4_state_manager nfs4_reset_session nfs4_begin_drain_session nfs4_drain_slot_tbl // set NFS4_SLOT_TBL_DRAINING (1) nfs4_do_reclaim nfs4_open_reclaim __put_nfs_open_context __dentry_kill nfs_dentry_iput // check DCACHE_NFSFS_RENAMED (2) nfs_complete_unlink nfs_end_delegation_return nfs_do_return_delegation nfs4_proc_delegreturn _nfs4_proc_delegreturn rpc_run_task ... nfs4_delegreturn_prepare nfs4_setup_sequence nfs4_slot_tbl_draining // check NFS4_SLOT_TBL_DRAINING // and sa_privileged is 0 (3) rpc_sleep_on // set queued and add to slot_tbl_waitq // rpc_task is async and wait in __rpc_execute rpc_wait_for_completion_task __rpc_wait_for_completion_task out_of_line_wait_on_bit rpc_wait_bit_killable // wait for rpc_task to complete <-------- can not get here to wake up rpc_task --------> nfs4_end_drain_session nfs4_end_drain_slot_table nfs41_wake_slot_table On the one hand, the state manager is blocked by the unfinished delegation return. As a result, nfs4_end_drain_session cannot be invoked to clear NFS4_SLOT_TBL_DRAINING and wake up waiting tasks. On the other hand, since NFS4_SLOT_TBL_DRAINING is not cleared, delegation return can only wait in the queue, resulting in a deadlock. Fix it by turning the delegation return into a privileged operation for the case where the nfs_client is in NFS4CLNT_RECLAIM_REBOOT state. Fixes: 977fcc2b0b41 ("NFS: Add a delegation return into nfs4_proc_unlink_setup()") Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfs/nfs4proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index c140427e322c..e197bea6c6a9 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -6725,7 +6725,7 @@ static int _nfs4_proc_delegreturn(struct inode *inode, const struct cred *cred, } } - if (!data->inode) + if (!data->inode || test_bit(NFS4CLNT_RECLAIM_REBOOT, &server->nfs_client->cl_state)) nfs4_init_sequence(&data->args.seq_args, &data->res.seq_res, 1, 1); else -- 2.46.1

2 1

[openeuler:OLK-6.6 3313/3313] block/genhd.c:100:6: warning: no previous prototype for function 'part_stat_read_all'
by kernel test robot 24 Nov '25

24 Nov '25

Hi GONG, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: f75af043f61c1e2311edf9edd2c5e0987e5ab3c9 commit: 89fa7dcff5e533bd14396601f40c388cfb6c1e59 [3313/3313] bpf-rvi: block: Add diskstats iterator target config: loongarch-allnoconfig (https://download.01.org/0day-ci/archive/20251124/202511241700.GqFsj3QM-lkp@…) compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9e9fe08b16ea2c4d9867fb4974edf2a3776d6ece) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251124/202511241700.GqFsj3QM-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202511241700.GqFsj3QM-lkp@intel.com/ All warnings (new ones prefixed by >>): >> block/genhd.c:100:6: warning: no previous prototype for function 'part_stat_read_all' [-Wmissing-prototypes] 100 | void part_stat_read_all(struct block_device *part, struct disk_stats *stat) | ^ block/genhd.c:100:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 100 | void part_stat_read_all(struct block_device *part, struct disk_stats *stat) | ^ | static 1 warning generated. vim +/part_stat_read_all +100 block/genhd.c 99 > 100 void part_stat_read_all(struct block_device *part, struct disk_stats *stat) 101 { 102 int cpu; 103 104 memset(stat, 0, sizeof(struct disk_stats)); 105 for_each_possible_cpu(cpu) { 106 struct disk_stats *ptr = per_cpu_ptr(part->bd_stats, cpu); 107 int group; 108 109 for (group = 0; group < NR_STAT_GROUPS; group++) { 110 stat->nsecs[group] += ptr->nsecs[group]; 111 stat->sectors[group] += ptr->sectors[group]; 112 stat->ios[group] += ptr->ios[group]; 113 stat->merges[group] += ptr->merges[group]; 114 } 115 116 stat->io_ticks += ptr->io_ticks; 117 } 118 } 119 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10] sbitmap: fix infinite loop caused by negative wait_cnt
by Li Lingfeng 24 Nov '25

24 Nov '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID5F52 -------------------------------- A race condition in sbitmap_queue_wake_up() can cause an infinite loop when multiple CPUs concurrently decrement the same wait_cnt, resulting in a negative value that still satisfies the original condition check. The race scenario: CPU20 (in ioctl context): - Calls __sbq_wake_up() and selects ws based on wake_index CPU3 (in softirq): - Concurrently selects the same ws (wake_index unchanged) - Decrements wait_cnt from 1 to 0 CPU20 (interrupted by softirq): - Selects the same ws again (wake_index still unchanged) - Decrements wait_cnt from 0 to -1 - Returns true because (wait_cnt < 0) - Enters infinite loop in while(__sbq_wake_up(sbq)) The root cause is that sbq_wake_ptr() returns the wait_state when atomic_read(&ws->wait_cnt) is non-zero, which includes negative values. Since wake_index is never updated when the same ws is repeatedly selected, multiple CPUs can race on the same wait_state, driving wait_cnt increasingly negative and triggering the infinite loop condition. Fix this by explicitly checking that wait_cnt is positive (> 0) in sbq_wake_ptr(), preventing selection of wait_states with negative counts and breaking the infinite loop condition. Fixes: 084cd94d0b2a ("sbitmap: fix possible io hung due to lost wakeup") Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- lib/sbitmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/sbitmap.c b/lib/sbitmap.c index 9fe2aebc13da..dbe4e3bc6b33 100644 --- a/lib/sbitmap.c +++ b/lib/sbitmap.c @@ -554,7 +554,7 @@ static struct sbq_wait_state *sbq_wake_ptr(struct sbitmap_queue *sbq) for (i = 0; i < SBQ_WAIT_QUEUES; i++) { struct sbq_wait_state *ws = &sbq->ws[wake_index]; - if (waitqueue_active(&ws->wait) && atomic_read(&ws->wait_cnt)) { + if (waitqueue_active(&ws->wait) && (atomic_read(&ws->wait_cnt) > 0)) { if (wake_index != atomic_read(&sbq->wake_index)) atomic_set(&sbq->wake_index, wake_index); return ws; -- 2.46.1

2 1