linux-kernel - Did the "TASK_WAKING" condition really need to be examine in "__set_cpus_allowed

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>] [day] [month] [year] [list]

Date:   Mon, 21 Dec 2020 19:08:38 +0800
From:   seiya seiya <seiyaquestions@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: Did the "TASK_WAKING" condition really need to be examine in "__set_cpus_allowed_ptr“ function?

Hi folks:

        I use linux kernel v5.3.1 version, i think all recent version
may be same  on the spot i methion below,
In function "__set_cpus_allowed_ptr".
file:linux-stable/kernel/sched/core.c
function: __set_cpus_allowed_ptr
1562         if (task_running(rq, p) || p->state == TASK_WAKING) {
1563                 struct migration_arg arg = { p, dest_cpu };
1564                 /* Need help from migration thread: drop lock and wait. */
1565                 task_rq_unlock(rq, p, &rf);
1566                 stop_one_cpu(cpu_of(rq), migration_cpu_stop, &arg);
1567                 return 0;
1568          }

you see here are examining the "p->state" equals " TASK_WAKING ", but
from the whole kernel code, i found  only one place set the "p->state"
to " TASK_WAKING ", which is in the same file function,
the function is  try_to_wake_up, below is that:
file:linux-stable/kernel/sched/core.c
function: try_to_wake_up
2506         p->sched_contributes_to_load = !!task_contributes_to_load(p);
2507         p->state = TASK_WAKING;
2508
2509         if (p->in_iowait) {
2510                 delayacct_blkio_end(p);
2511                 atomic_dec(&task_rq(p)->nr_iowait);
2512         }

so, this is the single place that set the p ->state = TASK_WAKING, and
 with the procedure going on in "try_to_wake_up", the p->state would
be set to  "TASK_RUNNING" in "ttwu_do_wakeup".
file : linux-stable/kernel/sched/core.c
function:ttwu_do_wakeup
2100         check_preempt_curr(rq, p, wake_flags);
2101         p->state = TASK_RUNNING;
2102         trace_sched_wakeup(p);

so,   TASK_WAKING is an intermediate state for the task to be woken.
but, which strange to me, both the sequence of   p->state =
TASK_WAKING; and   p->state = TASK_RUNNING; are protected by
"p->pi_lock"
it seems like that:
try_to_wake_up( ... )
    raw_spin_lock_irqsave(&p->pi_lock, flags);
   。。。。。。。。。。
     p->state = TASK_WAKING;
    。。。。。。
   p->state = TASK_RUNNING;
  。。。。。。。。。
 raw_spin_unlock_irqrestore(&p->pi_lock, flags);

and, also, the "p->state == TASK_WAKING" check  in function
__set_cpus_allowed_ptr protected by the same "p->pi_lock" in
"task_rq_lock".

so it seems like that:

 __set_cpus_allowed_ptr(...)
{
   raw_spin_lock_irqsave(&p->pi_lock, flags);
   。。。。。。。。。。。
   if (task_running(rq, p) || p->state == TASK_WAKING) {

。。。。。。。。。。。。。。。
   raw_spin_unlock_irqrestore(&p->pi_lock, flags);
}

so, my puzzle is: how did the core see the intermediate state of "
p->state == TASK_WAKING" at runtime? because the two places are all
protected by the same spinlock (p->pi_lock). and there only one place
to set the p->state to TASK_WAKEING?

In which scenario the  "p->state == TASK_WAKING" of function
__set_cpus_allowed_ptr success?

thank you!