Re: [PATCH v5 6/8] mm/slab: introduce struct kvfree_rcu_head for kvfree_rcu batching

[email protected] Wed, 29 Jul 2026 08:40:10 +0000
Newsgroups dev.linux.lists.linux-rt-devel,org.kernel.vger.bpf,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [High] Exposing local_trylock() to lockdep wait-type checking on PREEMPT_=
RT triggers an 'Invalid wait context' splat.
--

--- Patch [6]: [PATCH v5 6/8] mm/slab: introduce struct kvfree_rcu_head for=
 kvfree_rcu batching ---
commit f07807d65d1f49531b5a23f93da3e184960e8332
Author: Harry Yoo (Oracle) <[email protected]>

mm/slab: introduce struct kvfree_rcu_head for kvfree_rcu batching

This commit introduces struct kvfree_rcu_head to optimize kvfree_rcu()
batching. It replaces the use of rcu_head with a single-pointer linked
list when batched, reducing overhead.

> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 9c2cca9add893..691ce6db4519c 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
[ ... ]
> @@ -1979,7 +1979,7 @@ void __init kfree_rcu_scheduler_running(void)
>   * be free'd in workqueue context. This allows us to: batch requests tog=
ether to
>   * reduce the number of grace periods during heavy kfree_rcu()/kvfree_rc=
u() load.
>   */
> -void kvfree_call_rcu(struct rcu_head *head, void *ptr)
> +void kvfree_call_rcu(struct kvfree_rcu_head *head, void *ptr)

[Severity: High]
Does this code path expose local_trylock() to lockdep wait-type checking on
PREEMPT_RT, triggering an 'Invalid wait context' splat?

When kvfree_call_rcu() is called under a raw spinlock or in hardirq context,
it can reach __kfree_rcu_sheaf():

mm/slub.c:__kfree_rcu_sheaf() {
	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
		lock_map_acquire_try(&kfree_rcu_sheaf_map);

	if (!local_trylock(&s->cpu_sheaves->lock))
		goto fail;
	...
}

On PREEMPT_RT, local_lock maps to a sleepable spinlock_t (wait type
LD_WAIT_CONFIG). CONFIG_PROVE_RAW_LOCK_NESTING checks declared wait-types
regardless of runtime behavior or trylock usage.

If the patch series removes the short-circuit in __kfree_rcu_sheaf() that
protected this path, does the subsequent local_trylock() execution violate
raw lock nesting rules?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260729-kfree_rcu_=
[email protected]?part=3D6