Re: [PATCH] sched: Serialize cgroup updates to prevent CFS/SCX state divergence

On Thu, Aug 20, 2026 at 07:21:01AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Thu, Aug 20, 2026 at 04:09:56PM +0000, Michal Blaszczyk wrote:
> > Concurrent writes to cgroup control files (such as cpu.shares or
> > cpu.weight) can lead to state divergence between CFS and SCX.
> > 
> > For instance, in cpu_shares_write_u64(), the CFS update is serialized
> > by shares_mutex (internal to fair.c), but this lock is dropped before
> > scx_group_set_weight() is called. The latter only acquires a read
> > semaphore (scx_cgroup_ops_rwsem), allowing multiple threads to evaluate
> > and act on the sched_ext update concurrently.
> > 
> > This serialization gap allows concurrent writes to interleave.
> > As a result, the recorded state in CFS, the SCX internal bookkeeping
> > (e.g., tg->scx.weight), and the BPF scheduler itself can end up operating
> > on completely distinct parameters (pairwise distinct values).
> > 
> > Similar races are present in tg_set_bandwidth(), cpu_idle_write_s64(),
> > cpu_weight_write_u64(), and cpu_weight_nice_write_s64().
> > 
> > Fix this by introducing scx_cgroup_mutex in kernel/sched/core.c to
> > serialize these file write operations.
> 
> I wonder whether a better way to do this is just taking out fair's
> cpu.weight and .max locking into the core layer so that both callbacks are
> called under the same locking. Peter, what do you think?

Yeah, makes sense, no point in fair having an extra/superfluous layer of
locking if it is (also) needed in core.