[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <445b0d155b7a3cb84452aa7010669e293e8c37db@linux.dev>
Date: Thu, 20 Nov 2025 01:57:36 +0000
From: "Jiayuan Chen" <jiayuan.chen@...ux.dev>
To: "Tejun Heo" <tj@...nel.org>
Cc: cgroups@...r.kernel.org, hannes@...xchg.org, mkoutny@...e.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] cgroup: drop preemption_disabled checking
November 19, 2025 at 23:59, "Tejun Heo" <tj@...nel.org mailto:tj@...nel.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();
}
Powered by blists - more mailing lists