All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Wanwu Li" <liwanwu@kylinos.cn>
Cc: sched-ext@lists.linux.dev
Subject: Re: [PATCH 1/3] tools/sched_ext: Increment nr_queued when a task is queued to user space
Date: Thu, 24 Sep 2026 14:47:53 +0000	[thread overview]
Message-ID: <20260924144753.9D22E1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260924143659.268595-2-liwanwu@kylinos.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: lost wakeup in scx_userland due to nr_queued TOCTOU race
--

commit 58872b4f72d7bfd3655086348da64ace07a2573a
Author: Wanwu Li <liwanwu@kylinos.cn>

tools/sched_ext: Increment nr_queued when a task is queued to user space

userland_update_idle() decides whether a CPU going idle must wake the
user-space scheduler with "if (nr_queued || nr_scheduled)", where
nr_queued is documented to be incremented when a task is queued. But
enqueue_task_in_user_space() never increments it, so tasks sitting in the
enqueued map are invisible to a CPU going idle.

Fixes: cc4448d0856d ("tools/sched_ext: add scx_userland scheduler")
Signed-off-by: Wanwu Li <liwanwu@kylinos.cn>

> diff --git a/tools/sched_ext/scx_userland.bpf.c b/tools/sched_ext/scx_userland.bpf.c
> index f29862b89386b..648c6bd230eb2 100644
> --- a/tools/sched_ext/scx_userland.bpf.c
> +++ b/tools/sched_ext/scx_userland.bpf.c
> @@ -197,6 +197,7 @@ static void enqueue_task_in_user_space(struct task_struct *p, u64 enq_flags)
>  		scx_bpf_dsq_insert(p, SCX_DSQ_GLOBAL, SCX_SLICE_DFL, enq_flags);
>  	} else {
>  		__sync_fetch_and_add(&nr_user_enqueues, 1);
> +		__sync_fetch_and_add(&nr_queued, 1);

[Severity: High]
Will this introduce a race condition with the user-space scheduler that 
leads to a lost wakeup?

When the kernel atomically increments nr_queued here, the user-space
scheduler unconditionally clobbers it without any synchronization:

tools/sched_ext/scx_userland.c:drain_enqueued_map() {
    ...
    if (bpf_map_lookup_and_delete_elem(enqueued_fd, NULL, &task)) {
        skel->bss->nr_queued = 0;
        ...
}

If drain_enqueued_map() finds the map empty, but just before it runs
skel->bss->nr_queued = 0, a concurrent kernel BPF program enqueues a new
task and increments nr_queued to 1, the user space code will overwrite
it back to 0.

Since both nr_queued and usersched_needed would end up cleared, could this
cause idle CPUs to fail to wake the scheduler, leaving the newly enqueued
task stranded?

>  		set_usersched_needed();
>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924143659.268595-1-liwanwu@kylinos.cn?part=1

  reply	other threads:[~2026-09-24 14:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 14:36 [PATCH 0/3] tools/sched_ext: Fix three example scheduler bugs Wanwu Li
2026-09-24 14:36 ` [PATCH 1/3] tools/sched_ext: Increment nr_queued when a task is queued to user space Wanwu Li
2026-09-24 14:47   ` sashiko-bot [this message]
2026-09-24 14:36 ` [PATCH 2/3] tools/sched_ext: scx_pair: Drain task queue on cgroup exit Wanwu Li
2026-09-24 14:36 ` [PATCH 3/3] tools/sched_ext: scx_pair: Verify task cgroup before dispatch Wanwu Li
2026-09-24 14:50   ` sashiko-bot
2026-09-24 16:17 ` [PATCH 0/3] tools/sched_ext: Fix three example scheduler bugs Tejun Heo
2026-09-24 22:35   ` liwanwu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260924144753.9D22E1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=liwanwu@kylinos.cn \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sched-ext@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.