From: Harry Yoo <harry@kernel.org>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Clark Williams <clrkwllms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Alexei Starovoitov <ast@kernel.org>, Hao Li <hao.li@linux.dev>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev,
syzbot+acf142088e0182172e58@syzkaller.appspotmail.com,
ThangNN99 <ngocthang2710.1999@gmail.com>,
puranjay@kernel.org
Subject: Re: [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again
Date: Wed, 2 Sep 2026 11:24:32 +0100 [thread overview]
Message-ID: <apfwshahN_C6jBSn@nixos> (raw)
In-Reply-To: <47aa459f-27d5-4b2f-9eb9-36ebca63d890@kernel.org>
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
next prev parent reply other threads:[~2026-09-02 10:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 16:02 [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again Vlastimil Babka (SUSE)
2026-08-31 16:21 ` [PATCH] mm/slab: don't use " ThangNN99
2026-08-31 16:24 ` [PATCH] mm/slab: disallow " ThangNN99
2026-09-01 7:33 ` Sebastian Andrzej Siewior
2026-09-01 13:59 ` Vlastimil Babka (SUSE)
2026-09-02 10:24 ` Harry Yoo [this message]
2026-09-02 10:41 ` Sebastian Andrzej Siewior
2026-09-02 14:13 ` Vlastimil Babka (SUSE)
2026-09-03 8:33 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apfwshahN_C6jBSn@nixos \
--to=harry@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=cl@gentwo.org \
--cc=clrkwllms@kernel.org \
--cc=hao.li@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=ngocthang2710.1999@gmail.com \
--cc=peterz@infradead.org \
--cc=puranjay@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=syzbot+acf142088e0182172e58@syzkaller.appspotmail.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox