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