From: "Jiayuan Chen" <jiayuan.chen@linux.dev>
To: "Tejun Heo" <tj@kernel.org>
Cc: cgroups@vger.kernel.org, hannes@cmpxchg.org, mkoutny@suse.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] cgroup: drop preemption_disabled checking
Date: Thu, 20 Nov 2025 01:57:36 +0000 [thread overview]
Message-ID: <445b0d155b7a3cb84452aa7010669e293e8c37db@linux.dev> (raw)
In-Reply-To: <aR3paXRgyxdeO4sC@slm.duckdns.org>
November 19, 2025 at 23:59, "Tejun Heo" <tj@kernel.org mailto:tj@kernel.org?to=%22Tejun%20Heo%22%20%3Ctj%40kernel.org%3E > wrote:
>
> Hello,
>
> On Wed, Nov 19, 2025 at 07:14:01PM +0800, Jiayuan Chen wrote:
>
> >
> > BPF programs do not disable preemption, they only disable migration.
> > Therefore, when running the cgroup_hierarchical_stats selftest, a
> > warning [1] is generated.
> >
> > The css_rstat_updated() function is lockless and reentrant, so checking
> > for disabled preemption is unnecessary (please correct me if I'm wrong).
> >
> While it won't crash the kernel to schedule while running the function,
> there are timing considerations here. If the thread which wins the lnode
> competition gets scheduled out, there can be significant unexpected delays
> for others that lost against it. Maybe just update the caller to disable
> preemption?
>
> Thanks.
>
> --
> tejun
>
Since css_rstat_updated() can be called from BPF where preemption is not
disabled by its framework, we can simply add preempt_disable()/preempt_enable()
around the call, like this:
void css_rstat_updated()
{
preempt_disable();
__css_rstat_updated();
preempt_enable();
}
prev parent reply other threads:[~2025-11-20 1:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 11:14 [PATCH v1] cgroup: drop preemption_disabled checking Jiayuan Chen
2025-11-19 15:59 ` Tejun Heo
2025-11-20 1:57 ` Jiayuan Chen [this message]
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=445b0d155b7a3cb84452aa7010669e293e8c37db@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=tj@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.