[PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[Vlastimil Babka (SUSE)]

This partially reverts commit 2a8bb29ec9b2 ("mm/slab: allow
kfree_rcu_sheaf() on PREEMPT_RT"). It was based on an assumption that
local_trylock() is safe on PREEMPT_RT from any context.

However kvfree_rcu() is also called by set_cpus_allowed_force() with
task_struct::pi_lock acquired and there it's not safe, as syzbot
has reported.

For the immediate fix, skip kfree_rcu_sheaf() on PREEMPT_RT again from
kvfree_call_rcu(). In theory, kfree_rcu_nolock() would have the same
problem when called from under pi_lock on PREEMPT_RT but that can
be addressed if such a caller is proposed.

Add an explanation comment, courtesy of Sebastian.

Reported-by: syzbot+acf142088e0182172e58@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=acf142088e0182172e58
Reported-by: ThangNN99 <ngocthang2710.1999@gmail.com>
Fixes: 2a8bb29ec9b2 ("mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT")
Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
---
Incidentally I have posted a RFC [1] that leads to replacing that
kfree_rcu() from set_cpus_allowed_force() but now after back from
vacation I need to check the feedback and based on this bug report I can
already see it makes the same bad assumption that trylock is fine.

[1] https://lore.kernel.org/all/20260807-kfree_nolock_kmalloc-v1-0-ba993cbf7a60@kernel.org/
---
 mm/slab_common.c | 18 ++++++++----------
 mm/slub.c        |  5 +++--
 2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/mm/slab_common.c b/mm/slab_common.c
index b19ba1b31484..7223a7596dab 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1667,14 +1667,6 @@ static bool kfree_rcu_sheaf(void *obj)
 {
 	struct kmem_cache *s;
 	struct slab *slab;
-	unsigned int free_flags = SLAB_FREE_DEFAULT;
-
-	/*
-	 * It is not safe to spin on PREEMPT_RT because the kernel might be
-	 * holding a raw spinlock and slab acquires sleeping locks.
-	 */
-	if (IS_ENABLED(CONFIG_PREEMPT_RT))
-		free_flags = SLAB_FREE_NOLOCK;
 
 	if (is_vmalloc_addr(obj))
 		return false;
@@ -1685,7 +1677,7 @@ static bool kfree_rcu_sheaf(void *obj)
 
 	s = slab->slab_cache;
 	if (likely(!IS_ENABLED(CONFIG_NUMA) || slab_nid(slab) == numa_mem_id()))
-		return __kfree_rcu_sheaf(s, obj, free_flags);
+		return __kfree_rcu_sheaf(s, obj, SLAB_FREE_DEFAULT);
 
 	return false;
 }
@@ -2034,7 +2026,13 @@ void kvfree_call_rcu(struct kvfree_rcu_head *head, void *ptr)
 	if (!head)
 		might_sleep();
 
-	if (kfree_rcu_sheaf(ptr))
+	/*
+	 * 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.
+	 */
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT) && kfree_rcu_sheaf(ptr))
 		return;
 
 	// Queue the object but don't yet schedule the batch.
diff --git a/mm/slub.c b/mm/slub.c
index f9b56cb439e7..7a7e906a0e44 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -6088,8 +6088,9 @@ static void rcu_free_sheaf(struct rcu_head *head)
 /*
  * kvfree_call_rcu() can be called while holding a raw_spinlock_t. Since
  * __kfree_rcu_sheaf() may acquire a spinlock_t (sleeping lock on PREEMPT_RT),
- * this would violate lock nesting rules. Therefore, kvfree_call_rcu() avoids
- * this problem by passing SLAB_FREE_NOLOCK on PREEMPT_RT.
+ * this would violate lock nesting rules. Therefore, kfree_call_rcu_nolock()
+ * avoids this problem by passing SLAB_FREE_NOLOCK. kvfree_call_rcu() is
+ * bypassing the sheaves layer completely on PREEMPT_RT.
  *
  * However, lockdep still complains that it is invalid to acquire spinlock_t
  * while holding raw_spinlock_t, even on !PREEMPT_RT where spinlock_t is a

---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260831-b4-kfree_rcu_hotfix-1d3dd315bff0

Re: [PATCH] mm/slab: don't use kfree_rcu_sheaf() on PREEMPT_RT again

[ThangNN99]

Thanks Vlastimil, this matches what I found and is functionally the
same fix I had in my v3. I built this exact logic (skip
kfree_rcu_sheaf() under CONFIG_PREEMPT_RT in kvfree_call_rcu(), same
dead-code removal in kfree_rcu_sheaf()) against commit 08dbfad3f504
with the syzbot .config and reproduced the original splat with
syzbot's C repro (writing "off" to
/sys/devices/system/cpu/smt/control to trigger the
__balance_push_cpu_stop -> select_fallback_rq ->
cpuset_cpus_allowed_fallback -> set_cpus_allowed_force ->
kvfree_call_rcu chain) — confirmed the exact same lockdep report as
syzbot, then rebuilt with the fix and confirmed the splat no longer
appears while the same code path still executes.

Feel free to add:

Tested-by: ThangNN99 <ngocthang2710.1999@gmail.com>

Thanks for picking this up and for the pi_lock/waitlock explanation,
that's a much more precise description than what I had.

ThangNN99

Re: [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[ThangNN99]

Thanks Vlastimil, this matches what I found and is functionally the
same fix I had in my v3. I built this exact logic (skip
kfree_rcu_sheaf() under CONFIG_PREEMPT_RT in kvfree_call_rcu(), same
dead-code removal in kfree_rcu_sheaf()) against commit 08dbfad3f504
with the syzbot .config and reproduced the original splat with
syzbot's C repro (writing "off" to
/sys/devices/system/cpu/smt/control to trigger the
__balance_push_cpu_stop -> select_fallback_rq ->
cpuset_cpus_allowed_fallback -> set_cpus_allowed_force ->
kvfree_call_rcu chain) — confirmed the exact same lockdep report as
syzbot, then rebuilt with the fix and confirmed the splat no longer
appears while the same code path still executes.

Feel free to add:

Tested-by: ThangNN99 <ngocthang2710.1999@gmail.com>

Thanks for picking this up and for the pi_lock/waitlock explanation,
that's a much more precise description than what I had.

ThangNN99

Re: [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[Sebastian Andrzej Siewior]

On 2026-08-31 18:02:38 [+0200], Vlastimil Babka (SUSE) wrote:
> This partially reverts commit 2a8bb29ec9b2 ("mm/slab: allow
> kfree_rcu_sheaf() on PREEMPT_RT"). It was based on an assumption that
> local_trylock() is safe on PREEMPT_RT from any context.
…
> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

> ---
> Incidentally I have posted a RFC [1] that leads to replacing that
> kfree_rcu() from set_cpus_allowed_force() but now after back from
> vacation I need to check the feedback and based on this bug report I can
> already see it makes the same bad assumption that trylock is fine.

free_to_pcs() has still this trylock.

What I am not so sure how good is that kfree_rcu_nolock() may allocate
memory for the sheaf if there is none around. It could have a pool of X
and if it runs out, it runs out and waits until the clean up process
feeds the used sheafs back. There is fallback and the run out is not the
usual case.

I do remember RCU tried the same thing but then it got to the case where
HEAD had to be supplied or it had to be preemptible so could wait for
grace period and free it. I just don't remember if it had a pool pages
to fill pointers to or allocated pages if it run out. And I am too lazy
to look atm.

Sebastian

Re: [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[Vlastimil Babka (SUSE)]

On 9/1/26 09:33, Sebastian Andrzej Siewior wrote:
> On 2026-08-31 18:02:38 [+0200], Vlastimil Babka (SUSE) wrote:
>> This partially reverts commit 2a8bb29ec9b2 ("mm/slab: allow
>> kfree_rcu_sheaf() on PREEMPT_RT"). It was based on an assumption that
>> local_trylock() is safe on PREEMPT_RT from any context.
> …
>> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> 
>> ---
>> Incidentally I have posted a RFC [1] that leads to replacing that
>> kfree_rcu() from set_cpus_allowed_force() but now after back from
>> vacation I need to check the feedback and based on this bug report I can
>> already see it makes the same bad assumption that trylock is fine.
> 
> free_to_pcs() has still this trylock.
> 
> What I am not so sure how good is that kfree_rcu_nolock() may allocate
> memory for the sheaf if there is none around.

Per sashiko review it's actually bad too under the pi_lock, because
GFP_NOWAIT means __GFP_KSWAPD_RECLAIM which can mean wakeup_kswapd() and
thus also need scheduler locks. And it's not a PREEMPT_RT-only issue...

> It could have a pool of X
> and if it runs out, it runs out and waits until the clean up process
> feeds the used sheafs back. There is fallback and the run out is not the
> usual case.

I'd rather not invent new pools, since there's fallback and the sheaf+barn
is already a pool. Could be enough to make sure the allocation attempt is
safe, i.e. use only __GFP_NOWARN.

> I do remember RCU tried the same thing but then it got to the case where
> HEAD had to be supplied or it had to be preemptible so could wait for
> grace period and free it. I just don't remember if it had a pool pages
> to fill pointers to or allocated pages if it run out. And I am too lazy
> to look atm.

Yeah.

> Sebastian

Re: [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[Harry Yoo]

On Tue, Sep 01, 2026 at 03:59:09PM +0200, Vlastimil Babka (SUSE) wrote:
> On 9/1/26 09:33, Sebastian Andrzej Siewior wrote:
> > On 2026-08-31 18:02:38 [+0200], Vlastimil Babka (SUSE) wrote:
> >> This partially reverts commit 2a8bb29ec9b2 ("mm/slab: allow
> >> kfree_rcu_sheaf() on PREEMPT_RT"). It was based on an assumption that
> >> local_trylock() is safe on PREEMPT_RT from any context.
> > …
> >> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> > Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > 
> >> ---
> >> Incidentally I have posted a RFC [1] that leads to replacing that
> >> kfree_rcu() from set_cpus_allowed_force() but now after back from
> >> vacation I need to check the feedback and based on this bug report I can
> >> already see it makes the same bad assumption that trylock is fine.
> > 
> > free_to_pcs() has still this trylock.
> > 
> > What I am not so sure how good is that kfree_rcu_nolock() may allocate
> > memory for the sheaf if there is none around.

At least it doesn't wake up kswapd... oh wait, but it does use trylock.
But that's not just kfree_rcu_nolock()'s problem?

_nolock() helpers can be called at any context, even under pi_lock
(at least in theory). re: we should fix can_spin_trylock() and use it
IMHO?

> Per sashiko review it's actually bad too under the pi_lock, because
> GFP_NOWAIT means __GFP_KSWAPD_RECLAIM which can mean wakeup_kswapd() and
> thus also need scheduler locks. And it's not a PREEMPT_RT-only issue...

Right. That's a pre-existing issue that has been around for a while...
I tried to reproduce it locally a while ago but it was quite tough.

> > It could have a pool of X
> > and if it runs out, it runs out and waits until the clean up process
> > feeds the used sheafs back. There is fallback and the run out is not the
> > usual case.
> 
> I'd rather not invent new pools, since there's fallback and the sheaf+barn
> is already a pool.

Agreed.

> Could be enough to make sure the allocation attempt is
> safe, i.e. use only __GFP_NOWARN.

in __kfree_rcu_sheaf(), yeah.

-- 
Cheers,
Harry / Hyeonggon

Re: [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[Sebastian Andrzej Siewior]

On 2026-09-01 15:59:09 [+0200], Vlastimil Babka (SUSE) wrote:
> On 9/1/26 09:33, Sebastian Andrzej Siewior wrote:
> > On 2026-08-31 18:02:38 [+0200], Vlastimil Babka (SUSE) wrote:
> >> This partially reverts commit 2a8bb29ec9b2 ("mm/slab: allow
> >> kfree_rcu_sheaf() on PREEMPT_RT"). It was based on an assumption that
> >> local_trylock() is safe on PREEMPT_RT from any context.
> > …
> >> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> > Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > 
> >> ---
> >> Incidentally I have posted a RFC [1] that leads to replacing that
> >> kfree_rcu() from set_cpus_allowed_force() but now after back from
> >> vacation I need to check the feedback and based on this bug report I can
> >> already see it makes the same bad assumption that trylock is fine.
> > 
> > free_to_pcs() has still this trylock.
> > 
> > What I am not so sure how good is that kfree_rcu_nolock() may allocate
> > memory for the sheaf if there is none around.
> 
> Per sashiko review it's actually bad too under the pi_lock, because
> GFP_NOWAIT means __GFP_KSWAPD_RECLAIM which can mean wakeup_kswapd() and
> thus also need scheduler locks. And it's not a PREEMPT_RT-only issue...

\o/

> > It could have a pool of X
> > and if it runs out, it runs out and waits until the clean up process
> > feeds the used sheafs back. There is fallback and the run out is not the
> > usual case.
> 
> I'd rather not invent new pools, since there's fallback and the sheaf+barn
> is already a pool. Could be enough to make sure the allocation attempt is
> safe, i.e. use only __GFP_NOWARN.

So we avoid the allocation and just add it to the sheaf+barn and this is
it?
 
Sebastian

Re: [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[Vlastimil Babka (SUSE)]

On 9/2/26 12:41, Sebastian Andrzej Siewior wrote:
> On 2026-09-01 15:59:09 [+0200], Vlastimil Babka (SUSE) wrote:
>> On 9/1/26 09:33, Sebastian Andrzej Siewior wrote:
>> > On 2026-08-31 18:02:38 [+0200], Vlastimil Babka (SUSE) wrote:
>> >> This partially reverts commit 2a8bb29ec9b2 ("mm/slab: allow
>> >> kfree_rcu_sheaf() on PREEMPT_RT"). It was based on an assumption that
>> >> local_trylock() is safe on PREEMPT_RT from any context.
>> > …
>> >> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
>> > Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> > 
>> >> ---
>> >> Incidentally I have posted a RFC [1] that leads to replacing that
>> >> kfree_rcu() from set_cpus_allowed_force() but now after back from
>> >> vacation I need to check the feedback and based on this bug report I can
>> >> already see it makes the same bad assumption that trylock is fine.
>> > 
>> > free_to_pcs() has still this trylock.
>> > 
>> > What I am not so sure how good is that kfree_rcu_nolock() may allocate
>> > memory for the sheaf if there is none around.
>> 
>> Per sashiko review it's actually bad too under the pi_lock, because
>> GFP_NOWAIT means __GFP_KSWAPD_RECLAIM which can mean wakeup_kswapd() and
>> thus also need scheduler locks. And it's not a PREEMPT_RT-only issue...
> 
> \o/

More like /o\

>> > It could have a pool of X
>> > and if it runs out, it runs out and waits until the clean up process
>> > feeds the used sheafs back. There is fallback and the run out is not the
>> > usual case.
>> 
>> I'd rather not invent new pools, since there's fallback and the sheaf+barn
>> is already a pool. Could be enough to make sure the allocation attempt is
>> safe, i.e. use only __GFP_NOWARN.
> 
> So we avoid the allocation and just add it to the sheaf+barn and this is
> it?

We don't need to avoid the allocation attempt if it's done in a safe way?
Note the new sheaf can be also served from its kmalloc slab almost
immediately, going all the way to page allocator should be very rare.
But if we stopped doing that sheaf allocation attemps completely, we could
easily end up having long bursts of all kfree_rcu() being deferred.

> Sebastian

Re: [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[Sebastian Andrzej Siewior]

On 2026-09-02 16:13:30 [+0200], Vlastimil Babka (SUSE) wrote:
> >> Per sashiko review it's actually bad too under the pi_lock, because
> >> GFP_NOWAIT means __GFP_KSWAPD_RECLAIM which can mean wakeup_kswapd() and
> >> thus also need scheduler locks. And it's not a PREEMPT_RT-only issue...
> > 
> > \o/
> 
> More like /o\

Yes, true. But it is not longer an RT-only issue.

> >> > It could have a pool of X
> >> > and if it runs out, it runs out and waits until the clean up process
> >> > feeds the used sheafs back. There is fallback and the run out is not the
> >> > usual case.
> >> 
> >> I'd rather not invent new pools, since there's fallback and the sheaf+barn
> >> is already a pool. Could be enough to make sure the allocation attempt is
> >> safe, i.e. use only __GFP_NOWARN.
> > 
> > So we avoid the allocation and just add it to the sheaf+barn and this is
> > it?
> 
> We don't need to avoid the allocation attempt if it's done in a safe way?

If it safe and does not not increase the free-latency too much then it
is fine.
Now that I look at the kvfree_call_rcu(), there a timer, hrtimer,
workqueue… Oh. And a __get_free_page().

> Note the new sheaf can be also served from its kmalloc slab almost
> immediately, going all the way to page allocator should be very rare.
> But if we stopped doing that sheaf allocation attemps completely, we could
> easily end up having long bursts of all kfree_rcu() being deferred.

Sure. If you have memory around then there is nothing wrong with using
it. In my naive thinking I assumed it should be enough to fill the
buffers and in times of bursts having plenty of RCU callbacks which are
throttled.

Sebastian