]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
sched_ext: Use WRITE_ONCE() for the write side of dsq->seq update
authorzhidao su <soolaugust@gmail.com>
Wed, 4 Mar 2026 05:37:30 +0000 (13:37 +0800)
committerTejun Heo <tj@kernel.org>
Wed, 4 Mar 2026 17:01:18 +0000 (07:01 -1000)
commit7a8464555d2e5f038758bb19e72ab4710b79e9cd
tree68210a5e906bff3f97e19948df013ae52ff59b0a
parent0031c06807cfa8aa51a759ff8aa09e1aa48149af
sched_ext: Use WRITE_ONCE() for the write side of dsq->seq update

bpf_iter_scx_dsq_new() reads dsq->seq via READ_ONCE() without holding
any lock, making dsq->seq a lock-free concurrently accessed variable.
However, dispatch_enqueue(), the sole writer of dsq->seq, uses a plain
increment without the matching WRITE_ONCE() on the write side:

    dsq->seq++;
    ^^^^^^^^^^^
    plain write -- KCSAN data race

The KCSAN documentation requires that if one accessor uses READ_ONCE()
or WRITE_ONCE() on a variable to annotate lock-free access, all other
accesses must also use the appropriate accessor. A plain write leaves
the pair incomplete and will trigger KCSAN warnings.

Fix by using WRITE_ONCE() for the write side of the update:

    WRITE_ONCE(dsq->seq, dsq->seq + 1);

This is consistent with bpf_iter_scx_dsq_new() and makes the
concurrent access annotation complete and KCSAN-clean.

Signed-off-by: zhidao su <suzhidao@xiaomi.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
kernel/sched/ext.c