[PATCH] sched: Clarigy wake_up_process memory barrier semantic
From: Michal Hocko
Date: Thu Aug 27 2015 - 09:10:55 EST
wake_up_process unlike other wake up primitives based on __wake_up
implies the write memory barrier unconditionally because it relies
on try_to_wake_up directly.
Clarify this in the function comment and memory-barriers.txt because the
current doc is quite misleading.
Signed-off-by: Michal Hocko <mhocko@xxxxxxxx>
Documentation/memory-barriers.txt | 3 +++
kernel/sched/core.c | 3 +--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 13feb697271f..c4f180caf0ff 100644
@@ -2031,6 +2031,9 @@ something up. The barrier occurs before the task state is cleared, and so sits
<general barrier> STORE current->state
+Please note that wake_up_process is an exception here because it implies
+the write memory barrier unconditionally.
To repeat, this write memory barrier is present if and only if something
is actually awakened. To see this, consider the following sequence of
events, where X and Y are both initially zero:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 78b4bad10081..39583b76ad2c 100644
@@ -1967,8 +1967,7 @@ static void try_to_wake_up_local(struct task_struct *p)
* Return: 1 if the process was woken up, 0 if it was already running.
- * It may be assumed that this function implies a write memory barrier before
- * changing the task state if and only if any tasks are woken up.
+ * It may be assumed that this function implies a write memory barrier.
int wake_up_process(struct task_struct *p)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/