linux-kernel - [Patch] select_idle_sibling v.s. DELAYED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABcWv99ui2moYy0=jU2UwCm==m=h_YjaJeoTQs+J+r3v7r0Bwg@mail.gmail.com>
Date: Sat, 22 Nov 2025 22:04:39 -0600
From: Tingjia Cao <tjcao980311@...il.com>
To: peterz@...radead.org, Vincent Guittot <vincent.guittot@...aro.org>, mingo@...hat.com, 
	juri.lelli@...hat.com, dietmar.eggemann@....com, linux-kernel@...r.kernel.org
Subject: [Patch] select_idle_sibling v.s. DELAYED_DEQUEUE

Recently, we encountered an issue that sync wakeup kthread didn't choose
the current CPU though the waker is the only runnable task. It is caused by
a conflict between delayed dequeue feature and select_idle_sibling function.

With the DELAYED_DEQUEUE mechanism enabled, a task that goes to sleep may
not be removed from the runqueue immediately. As a result, nr_running may
overcount the number of runnable tasks. Inside select_idle_sibling, there
is a special case for sync wakeup:

if (is_per_cpu_kthread(current) &&
    in_task() &&
    prev == smp_processor_id() &&
    this_rq()->nr_running <= 1 &&
    asym_fits_cpu(...)) {
    return prev;
}

For "this_rq()->nr_running <= 1": we should use the real running-tasks rq
to check whether to place the wake-up task to the current cpu.

To fix this (patch attached), we can use the true number of runnable tasks
by subtracting the delayed-dequeue count:

        this_rq()->nr_running - cfs_h_nr_delayed(this_rq()) <= 1

Best,
Tingjia

Content of type "text/html" skipped

Download attachment "fix-select_idle_sibling-vs-DELAYED_DEQUEUE.patch" of type "application/octet-stream" (823 bytes)