Re: [PATCH v3] mm/slab: don't use kfree_rcu sheaves on PREEMPT_RT in kvfree_call_rcu()
From: Sebastian Andrzej Siewior
Date: Mon Aug 31 2026 - 15:51:27 EST
On 2026-08-31 20:32:22 [+0700], ThangNN99 wrote:
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -2034,7 +2027,14 @@ void kvfree_call_rcu(struct kvfree_rcu_head *head, void *ptr)
> if (!head)
> might_sleep();
>
> - if (kfree_rcu_sheaf(ptr))
> + /*
> + * Callers may hold a raw_spinlock_t here on PREEMPT_RT (e.g.
> + * set_cpus_allowed_force(), whose callers all hold
> + * task_struct::pi_lock), and the sheaf/barn locks are also taken
> + * as blocking locks elsewhere, so trying them here creates a
> + * lockdep-visible ordering conflict. Skip sheaves on PREEMPT_RT.
> + */
You mix up things. A raw_spinlock_t should work in general and should
not cause a problem. The task_struct::pi_lock is special: It used during
wakes and the inner waitlock of the rtmutex acquires it even during a
trylock. For PREEMPT_RT we don't want to acquire any locks while the
pi_lock is held.
What about
kvfree_rcu() is called by set_cpus_allowed_force() with
task_struct::pi_lock acquired. On PREEMPT_RT the local_trylock()
usage below will acquire the waitlock which must be avoided.
Therefore avoid it on PREEMPT_RT.
Vlastimil?
> + if (!IS_ENABLED(CONFIG_PREEMPT_RT) && kfree_rcu_sheaf(ptr))
> return;
>
> // Queue the object but don't yet schedule the batch.
Sebastian