Re: [PATCH] sched_ext: serialize concurrent cpu.max writers in scx_group_set_bandwidth()
From: Changwoo Min
Date: Fri Aug 21 2026 - 23:21:24 EST
Hello,
On 8/22/26 4:13 AM, Tejun Heo wrote:
On Fri, Aug 21, 2026 at 07:35:19PM +0900, Changwoo Min wrote:
Concurrent writes to a cgroup's cpu.max are not serialized by the cgroup or
kernfs layer -- cgroup_file_write() calls cft->write without cgroup_mutex, and
kernfs only serializes per open file -- so two writers to the same cgroup
through separate open files can reach tg_set_bandwidth() concurrently.
tg_set_cfs_bandwidth() serializes the CFS side under cfs_constraints_mutex,
but scx_group_set_bandwidth() runs afterwards with only
percpu_down_read(&scx_cgroup_ops_rwsem) held, a read lock, so it does not
serialize concurrent writers.
The ops.cgroup_set_bandwidth() callback and the cached tg->scx.bw_* stores can
then interleave between writers:
CPU1 (writer A) CPU2 (writer B)
scx_group_set_bandwidth()
SCX_CALL_OP(...) /* A */
scx_group_set_bandwidth()
SCX_CALL_OP(...) /* B */
tg->scx.bw_* = B
tg->scx.bw_* = A
The scheduler's cgroup_set_bandwidth() op is invoked out of order and the cached
state is left inconsistent with the last writer; the 64-bit bw_* stores can also
tear on 32-bit.
Serialize the SCX-side update with a new scx_cgroup_set_bw_mutex held across the
callback and the stores, so each writer applies its update atomically and in one
order -- the SCX counterpart to cfs_constraints_mutex on the CFS side.
Reported-by: Sashiko <sashiko-bot@xxxxxxxxxx>
Link: https://lore.kernel.org/sched-ext/20260817172131.BCDA51F000E9@xxxxxxxxxxxxxxx/
Signed-off-by: Changwoo Min <changwoo@xxxxxxxxxx>
I think the following is a better way to resolve this:
http://lkml.kernel.org/r/20260821140818.1559100-1-michalblk@xxxxxxxxxx
Thanks for pointing this out. I missed the Michal's patch. Will take a look.
Regards,
Changwoo Min