All of lore.kernel.org
 help / color / mirror / Atom feed
* Did the "TASK_WAKING" condition really need to be examine in "__set_cpus_allowed_ptr“ function?
@ 2020-12-21 11:08 seiya seiya
  0 siblings, 0 replies; only message in thread
From: seiya seiya @ 2020-12-21 11:08 UTC (permalink / raw)
  To: linux-kernel

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!

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-12-21 11:09 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-21 11:08 Did the "TASK_WAKING" condition really need to be examine in "__set_cpus_allowed_ptr“ function? seiya seiya

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.