[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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] kfree_call_rcu_nolock() is fundamentally broken on PREEMPT_RT when called from raw spinlock contexts, and the newly added comment falsely asserts that it is safe.

Pre-existing issues:
- [Critical] Lock recursion deadlock on !PREEMPT_RT due to __GFP_KSWAPD_RECLAIM allocation under scheduler locks in kvfree_call_rcu().
- [High] Lockdep 'Invalid wait context' warning on !PREEMPT_RT kernels due to acquiring `local_trylock` while holding a `raw_spinlock_t` in `kvfree_call_rcu()`.
--

commit 2bc8f43addec97fafa1e1eee6c2edf8016a0ff92
Author: Vlastimil Babka (SUSE) <vbabka@kernel.org>

mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

This partially reverts commit 2a8bb29ec9b2 to skip kfree_rcu_sheaf() on
PREEMPT_RT from kvfree_call_rcu(). It adds a comment explaining that
local_trylock() is unsafe on PREEMPT_RT when called under pi_lock.

Link: https://syzkaller.appspot.com/bug?extid=acf142088e0182172e58
Link: https://lore.kernel.org/all/20260807-kfree_nolock_kmalloc-v1-0-ba993cbf7a60@kernel.org/

> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index b19ba1b31484c..7223a7596dabb 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
[ ... ]
> @@ -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);

[Severity: Critical]
This is a pre-existing issue, but does passing SLAB_FREE_DEFAULT on
!PREEMPT_RT risk a lock recursion deadlock during low memory conditions?

When kfree_rcu_sheaf() forwards to __kfree_rcu_sheaf() with SLAB_FREE_DEFAULT,
it sets allow_spin to true. If the sheaf is empty, it calls:
    alloc_empty_sheaf(..., GFP_NOWAIT, ...)

GFP_NOWAIT implicitly includes __GFP_KSWAPD_RECLAIM. During high memory
pressure, this can trigger wakeup_kswapd(), which enters the scheduler via
try_to_wake_up() and acquires scheduler locks.

Since kvfree_call_rcu() is already called with task_struct::pi_lock held,
couldn't this allocation cause a lock recursion deadlock?

[ ... ]
> @@ -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;
>  

[Severity: High]
This isn't a bug introduced by this patch, but does executing
kfree_rcu_sheaf() on !PREEMPT_RT under pi_lock trigger a static wait-type
violation?

kvfree_rcu() is called while holding task_struct::pi_lock, which establishes
a RAW (LD_WAIT_SPIN) wait context. On !PREEMPT_RT, this code proceeds to
call kfree_rcu_sheaf(), which calls local_trylock() inside __kfree_rcu_sheaf().

Even though local_lock only disables preemption on non-RT, its lockdep map
declares an LD_WAIT_CONFIG (spinlock) wait-type. Since
CONFIG_PROVE_RAW_LOCK_NESTING statically checks declared wait-types rather
than runtime behavior, won't attempting to acquire an LD_WAIT_CONFIG lock
while holding an LD_WAIT_SPIN lock trigger an immediate "Invalid wait context"
warning on !PREEMPT_RT kernels?

> diff --git a/mm/slub.c b/mm/slub.c
> index f9b56cb439e70..7a7e906a0e44d 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.
>   *

[Severity: High]
Is the assertion in this comment that kfree_call_rcu_nolock() avoids the lock
nesting problem accurate for PREEMPT_RT?

Passing SLAB_FREE_NOLOCK to __kfree_rcu_sheaf() only prevents spinning, but
it still unconditionally calls local_trylock(&s->cpu_sheaves->lock). On
PREEMPT_RT, local_trylock() attempts to acquire a sleepable lock (rt_mutex),
which is an invalid wait context when held from NMI or raw spinlock contexts.

Given that kfree_call_rcu_nolock() is actively used and tested in hardirq/NMI
contexts (e.g., via test_nolock() in lib/tests/slub_kunit.c), won't this
cause a lockdep splat or kernel panic on PREEMPT_RT?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831-b4-kfree_rcu_hotfix-v1-1-4f0fb882638b@kernel.org?part=1

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

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

[Harry Yoo]

On Mon, Aug 31, 2026 at 06:02:38PM +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.
> 
> 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>
> ---

Looks good to me,
Reviewed-by: Harry Yoo (Meta) <harry@kernel.org>

-- 
Cheers,
Harry / Hyeonggon