Skip to contentSkip to conversation

sched: Assign !p->on_cpu to the second parameter of smp_cond_load_acquire()

PATCH In review T.Zhou 2 participants 2 messages Jul 1, 2016 Scheduler

lore
Share & tools
lore

T.Zhou

author
#0 lore raw

PATCH 1/1 sched: Assign !p->on_cpu to the second parameter of smp_cond_load_acquire()

The second parameter of smp_cond_load_acquire() should be !p->on_cpu cause remote wakeup need to ensure that: if the task is running on prev cpu, it should be descheduled before doing the actual wakeup.

Signed-off-by T.Zhou <[email protected]>
---
 kernel/sched/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched/core.c +1 -1
index 3387e4f..8e6fef6 100644
@@ -2047,7 +2047,7 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
 	 * This ensures that tasks getting woken will be fully ordered against
 	 * their previous state and preserve Program Order.
 	 */
-	smp_cond_load_acquire(&p->on_cpu, !VAL);
+	smp_cond_load_acquire(&p->on_cpu, !p->on_cpu);
 
 	p->sched_contributes_to_load = !!task_contributes_to_load(p);
 	p->state = TASK_WAKING;
Signature · 1 line
2.7.3
maintainer
#1 lore raw

kernel/sched/core.c try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags) · line 2050

Quoted 2 lines · T.Zhou
kernel/sched/core.c +1 -1
-	smp_cond_load_acquire(&p->on_cpu, !VAL);
+	smp_cond_load_acquire(&p->on_cpu, !p->on_cpu);

Huh, what?! No, the second parameter should very much include VAL, which gets assigned the value of *(&p->on_cpu).

Go read the macro, it even has a comment on.