Re: [PATCH] sched: Serialize cgroup updates to prevent CFS/SCX state divergence
Tejun Heo <[email protected]>
| Newsgroups | dev.linux.lists.sched-ext,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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? Thanks. -- tejun