2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
* Generic waiting primitives.
|
|
|
|
*
|
2012-12-06 16:39:54 +07:00
|
|
|
* (C) 2004 Nadia Yvette Chambers, Oracle
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
|
|
|
#include <linux/init.h>
|
2011-05-24 01:51:41 +07:00
|
|
|
#include <linux/export.h>
|
2017-02-03 01:15:33 +07:00
|
|
|
#include <linux/sched/signal.h>
|
2017-02-09 00:51:35 +07:00
|
|
|
#include <linux/sched/debug.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/wait.h>
|
|
|
|
#include <linux/hash.h>
|
2014-10-31 17:57:30 +07:00
|
|
|
#include <linux/kthread.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
void __init_waitqueue_head(struct wait_queue_head *wq_head, const char *name, struct lock_class_key *key)
|
2006-07-10 18:45:32 +07:00
|
|
|
{
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_lock_init(&wq_head->lock);
|
|
|
|
lockdep_set_class_and_name(&wq_head->lock, key, name);
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
INIT_LIST_HEAD(&wq_head->head);
|
2006-07-10 18:45:32 +07:00
|
|
|
}
|
2006-07-03 14:25:07 +07:00
|
|
|
|
2009-08-10 18:33:05 +07:00
|
|
|
EXPORT_SYMBOL(__init_waitqueue_head);
|
2006-07-03 14:25:07 +07:00
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
void add_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2017-03-05 16:33:16 +07:00
|
|
|
wq_entry->flags &= ~WQ_FLAG_EXCLUSIVE;
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_lock_irqsave(&wq_head->lock, flags);
|
|
|
|
__add_wait_queue_entry_tail(wq_head, wq_entry);
|
|
|
|
spin_unlock_irqrestore(&wq_head->lock, flags);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(add_wait_queue);
|
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
void add_wait_queue_exclusive(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2017-03-05 16:33:16 +07:00
|
|
|
wq_entry->flags |= WQ_FLAG_EXCLUSIVE;
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_lock_irqsave(&wq_head->lock, flags);
|
|
|
|
__add_wait_queue_entry_tail(wq_head, wq_entry);
|
|
|
|
spin_unlock_irqrestore(&wq_head->lock, flags);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(add_wait_queue_exclusive);
|
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
void remove_wait_queue(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_lock_irqsave(&wq_head->lock, flags);
|
|
|
|
__remove_wait_queue(wq_head, wq_entry);
|
|
|
|
spin_unlock_irqrestore(&wq_head->lock, flags);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(remove_wait_queue);
|
|
|
|
|
|
|
|
|
2013-10-04 22:24:35 +07:00
|
|
|
/*
|
|
|
|
* The core wakeup function. Non-exclusive wakeups (nr_exclusive == 0) just
|
|
|
|
* wake everything up. If it's an exclusive wakeup (nr_exclusive == small +ve
|
|
|
|
* number) then we wake all the non-exclusive tasks and one exclusive task.
|
|
|
|
*
|
|
|
|
* There are circumstances in which we can try to wake a task which has already
|
|
|
|
* started to run but is not in state TASK_RUNNING. try_to_wake_up() returns
|
|
|
|
* zero in this (rare) case, and we handle it by continuing to scan the queue.
|
|
|
|
*/
|
2017-03-05 17:10:18 +07:00
|
|
|
static void __wake_up_common(struct wait_queue_head *wq_head, unsigned int mode,
|
2013-10-04 22:24:35 +07:00
|
|
|
int nr_exclusive, int wake_flags, void *key)
|
|
|
|
{
|
2017-06-20 17:06:13 +07:00
|
|
|
wait_queue_entry_t *curr, *next;
|
2013-10-04 22:24:35 +07:00
|
|
|
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
list_for_each_entry_safe(curr, next, &wq_head->head, entry) {
|
2013-10-04 22:24:35 +07:00
|
|
|
unsigned flags = curr->flags;
|
|
|
|
|
|
|
|
if (curr->func(curr, mode, wake_flags, key) &&
|
|
|
|
(flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __wake_up - wake up threads blocked on a waitqueue.
|
2017-03-05 17:10:18 +07:00
|
|
|
* @wq_head: the waitqueue
|
2013-10-04 22:24:35 +07:00
|
|
|
* @mode: which threads
|
|
|
|
* @nr_exclusive: how many wake-one or wake-many threads to wake up
|
|
|
|
* @key: is directly passed to the wakeup function
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*/
|
2017-03-05 17:10:18 +07:00
|
|
|
void __wake_up(struct wait_queue_head *wq_head, unsigned int mode,
|
2013-10-04 22:24:35 +07:00
|
|
|
int nr_exclusive, void *key)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_lock_irqsave(&wq_head->lock, flags);
|
|
|
|
__wake_up_common(wq_head, mode, nr_exclusive, 0, key);
|
|
|
|
spin_unlock_irqrestore(&wq_head->lock, flags);
|
2013-10-04 22:24:35 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(__wake_up);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Same as __wake_up but called with the spinlock in wait_queue_head_t held.
|
|
|
|
*/
|
2017-03-05 17:10:18 +07:00
|
|
|
void __wake_up_locked(struct wait_queue_head *wq_head, unsigned int mode, int nr)
|
2013-10-04 22:24:35 +07:00
|
|
|
{
|
2017-03-05 17:10:18 +07:00
|
|
|
__wake_up_common(wq_head, mode, nr, 0, NULL);
|
2013-10-04 22:24:35 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__wake_up_locked);
|
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
void __wake_up_locked_key(struct wait_queue_head *wq_head, unsigned int mode, void *key)
|
2013-10-04 22:24:35 +07:00
|
|
|
{
|
2017-03-05 17:10:18 +07:00
|
|
|
__wake_up_common(wq_head, mode, 1, 0, key);
|
2013-10-04 22:24:35 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__wake_up_locked_key);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __wake_up_sync_key - wake up threads blocked on a waitqueue.
|
2017-03-05 17:10:18 +07:00
|
|
|
* @wq_head: the waitqueue
|
2013-10-04 22:24:35 +07:00
|
|
|
* @mode: which threads
|
|
|
|
* @nr_exclusive: how many wake-one or wake-many threads to wake up
|
|
|
|
* @key: opaque value to be passed to wakeup targets
|
|
|
|
*
|
|
|
|
* The sync wakeup differs that the waker knows that it will schedule
|
|
|
|
* away soon, so while the target thread will be woken up, it will not
|
|
|
|
* be migrated to another CPU - ie. the two threads are 'synchronized'
|
|
|
|
* with each other. This can prevent needless bouncing between CPUs.
|
|
|
|
*
|
|
|
|
* On UP it can prevent extra preemption.
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*/
|
2017-03-05 17:10:18 +07:00
|
|
|
void __wake_up_sync_key(struct wait_queue_head *wq_head, unsigned int mode,
|
2013-10-04 22:24:35 +07:00
|
|
|
int nr_exclusive, void *key)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
int wake_flags = 1; /* XXX WF_SYNC */
|
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
if (unlikely(!wq_head))
|
2013-10-04 22:24:35 +07:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (unlikely(nr_exclusive != 1))
|
|
|
|
wake_flags = 0;
|
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_lock_irqsave(&wq_head->lock, flags);
|
|
|
|
__wake_up_common(wq_head, mode, nr_exclusive, wake_flags, key);
|
|
|
|
spin_unlock_irqrestore(&wq_head->lock, flags);
|
2013-10-04 22:24:35 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__wake_up_sync_key);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* __wake_up_sync - see __wake_up_sync_key()
|
|
|
|
*/
|
2017-03-05 17:10:18 +07:00
|
|
|
void __wake_up_sync(struct wait_queue_head *wq_head, unsigned int mode, int nr_exclusive)
|
2013-10-04 22:24:35 +07:00
|
|
|
{
|
2017-03-05 17:10:18 +07:00
|
|
|
__wake_up_sync_key(wq_head, mode, nr_exclusive, NULL);
|
2013-10-04 22:24:35 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__wake_up_sync); /* For internal use only */
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
* Note: we use "set_current_state()" _after_ the wait-queue add,
|
|
|
|
* because we need a memory barrier there on SMP, so that any
|
|
|
|
* wake-function that tests for the wait-queue being active
|
|
|
|
* will be guaranteed to see waitqueue addition _or_ subsequent
|
|
|
|
* tests in this thread will see the wakeup having taken place.
|
|
|
|
*
|
|
|
|
* The spin_unlock() itself is semi-permeable and only protects
|
|
|
|
* one way (it only protects stuff inside the critical region and
|
|
|
|
* stops them from bleeding out - it would still allow subsequent
|
2007-05-09 13:57:56 +07:00
|
|
|
* loads to move into the critical region).
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2008-02-08 19:19:53 +07:00
|
|
|
void
|
2017-03-05 17:10:18 +07:00
|
|
|
prepare_to_wait(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry, int state)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2017-03-05 16:33:16 +07:00
|
|
|
wq_entry->flags &= ~WQ_FLAG_EXCLUSIVE;
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_lock_irqsave(&wq_head->lock, flags);
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
if (list_empty(&wq_entry->entry))
|
2017-03-05 17:10:18 +07:00
|
|
|
__add_wait_queue(wq_head, wq_entry);
|
2008-10-16 12:01:38 +07:00
|
|
|
set_current_state(state);
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_unlock_irqrestore(&wq_head->lock, flags);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(prepare_to_wait);
|
|
|
|
|
2008-02-08 19:19:53 +07:00
|
|
|
void
|
2017-03-05 17:10:18 +07:00
|
|
|
prepare_to_wait_exclusive(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry, int state)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
2017-03-05 16:33:16 +07:00
|
|
|
wq_entry->flags |= WQ_FLAG_EXCLUSIVE;
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_lock_irqsave(&wq_head->lock, flags);
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
if (list_empty(&wq_entry->entry))
|
2017-03-05 17:10:18 +07:00
|
|
|
__add_wait_queue_entry_tail(wq_head, wq_entry);
|
2008-10-16 12:01:38 +07:00
|
|
|
set_current_state(state);
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_unlock_irqrestore(&wq_head->lock, flags);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(prepare_to_wait_exclusive);
|
|
|
|
|
2017-03-05 16:33:16 +07:00
|
|
|
void init_wait_entry(struct wait_queue_entry *wq_entry, int flags)
|
2016-09-06 21:00:55 +07:00
|
|
|
{
|
2017-03-05 16:33:16 +07:00
|
|
|
wq_entry->flags = flags;
|
|
|
|
wq_entry->private = current;
|
|
|
|
wq_entry->func = autoremove_wake_function;
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
INIT_LIST_HEAD(&wq_entry->entry);
|
2016-09-06 21:00:55 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(init_wait_entry);
|
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
long prepare_to_wait_event(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry, int state)
|
2013-10-07 23:18:24 +07:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
2016-09-08 23:48:15 +07:00
|
|
|
long ret = 0;
|
2013-10-07 23:18:24 +07:00
|
|
|
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_lock_irqsave(&wq_head->lock, flags);
|
2016-09-08 23:48:15 +07:00
|
|
|
if (unlikely(signal_pending_state(state, current))) {
|
|
|
|
/*
|
|
|
|
* Exclusive waiter must not fail if it was selected by wakeup,
|
|
|
|
* it should "consume" the condition we were waiting for.
|
|
|
|
*
|
|
|
|
* The caller will recheck the condition and return success if
|
|
|
|
* we were already woken up, we can not miss the event because
|
2017-03-05 17:10:18 +07:00
|
|
|
* wakeup locks/unlocks the same wq_head->lock.
|
2016-09-08 23:48:15 +07:00
|
|
|
*
|
|
|
|
* But we need to ensure that set-condition + wakeup after that
|
|
|
|
* can't see us, it should wake up another exclusive waiter if
|
|
|
|
* we fail.
|
|
|
|
*/
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
list_del_init(&wq_entry->entry);
|
2016-09-08 23:48:15 +07:00
|
|
|
ret = -ERESTARTSYS;
|
|
|
|
} else {
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
if (list_empty(&wq_entry->entry)) {
|
2017-03-05 16:33:16 +07:00
|
|
|
if (wq_entry->flags & WQ_FLAG_EXCLUSIVE)
|
2017-03-05 17:10:18 +07:00
|
|
|
__add_wait_queue_entry_tail(wq_head, wq_entry);
|
2016-09-08 23:48:15 +07:00
|
|
|
else
|
2017-03-05 17:10:18 +07:00
|
|
|
__add_wait_queue(wq_head, wq_entry);
|
2016-09-08 23:48:15 +07:00
|
|
|
}
|
|
|
|
set_current_state(state);
|
2013-10-07 23:18:24 +07:00
|
|
|
}
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_unlock_irqrestore(&wq_head->lock, flags);
|
2013-10-07 23:18:24 +07:00
|
|
|
|
2016-09-08 23:48:15 +07:00
|
|
|
return ret;
|
2013-10-07 23:18:24 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(prepare_to_wait_event);
|
|
|
|
|
2017-03-08 06:33:14 +07:00
|
|
|
/*
|
|
|
|
* Note! These two wait functions are entered with the
|
|
|
|
* wait-queue lock held (and interrupts off in the _irq
|
|
|
|
* case), so there is no race with testing the wakeup
|
|
|
|
* condition in the caller before they add the wait
|
|
|
|
* entry to the wake queue.
|
|
|
|
*/
|
2017-06-20 17:06:13 +07:00
|
|
|
int do_wait_intr(wait_queue_head_t *wq, wait_queue_entry_t *wait)
|
2017-03-08 06:33:14 +07:00
|
|
|
{
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
if (likely(list_empty(&wait->entry)))
|
2017-06-20 17:06:13 +07:00
|
|
|
__add_wait_queue_entry_tail(wq, wait);
|
2017-03-08 06:33:14 +07:00
|
|
|
|
|
|
|
set_current_state(TASK_INTERRUPTIBLE);
|
|
|
|
if (signal_pending(current))
|
|
|
|
return -ERESTARTSYS;
|
|
|
|
|
|
|
|
spin_unlock(&wq->lock);
|
|
|
|
schedule();
|
|
|
|
spin_lock(&wq->lock);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(do_wait_intr);
|
|
|
|
|
2017-06-20 17:06:13 +07:00
|
|
|
int do_wait_intr_irq(wait_queue_head_t *wq, wait_queue_entry_t *wait)
|
2017-03-08 06:33:14 +07:00
|
|
|
{
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
if (likely(list_empty(&wait->entry)))
|
2017-06-20 17:06:13 +07:00
|
|
|
__add_wait_queue_entry_tail(wq, wait);
|
2017-03-08 06:33:14 +07:00
|
|
|
|
|
|
|
set_current_state(TASK_INTERRUPTIBLE);
|
|
|
|
if (signal_pending(current))
|
|
|
|
return -ERESTARTSYS;
|
|
|
|
|
|
|
|
spin_unlock_irq(&wq->lock);
|
|
|
|
schedule();
|
|
|
|
spin_lock_irq(&wq->lock);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(do_wait_intr_irq);
|
|
|
|
|
2010-10-27 04:17:25 +07:00
|
|
|
/**
|
2009-02-05 06:12:14 +07:00
|
|
|
* finish_wait - clean up after waiting in a queue
|
2017-03-05 17:10:18 +07:00
|
|
|
* @wq_head: waitqueue waited on
|
2017-03-05 16:33:16 +07:00
|
|
|
* @wq_entry: wait descriptor
|
2009-02-05 06:12:14 +07:00
|
|
|
*
|
|
|
|
* Sets current thread back to running state and removes
|
|
|
|
* the wait descriptor from the given waitqueue if still
|
|
|
|
* queued.
|
|
|
|
*/
|
2017-03-05 17:10:18 +07:00
|
|
|
void finish_wait(struct wait_queue_head *wq_head, struct wait_queue_entry *wq_entry)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
__set_current_state(TASK_RUNNING);
|
|
|
|
/*
|
|
|
|
* We can check for list emptiness outside the lock
|
|
|
|
* IFF:
|
|
|
|
* - we use the "careful" check that verifies both
|
|
|
|
* the next and prev pointers, so that there cannot
|
|
|
|
* be any half-pending updates in progress on other
|
|
|
|
* CPU's that we haven't seen yet (and that might
|
|
|
|
* still change the stack area.
|
|
|
|
* and
|
|
|
|
* - all other users take the lock (ie we can only
|
|
|
|
* have _one_ other CPU that looks at or modifies
|
|
|
|
* the list).
|
|
|
|
*/
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
if (!list_empty_careful(&wq_entry->entry)) {
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_lock_irqsave(&wq_head->lock, flags);
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
list_del_init(&wq_entry->entry);
|
2017-03-05 17:10:18 +07:00
|
|
|
spin_unlock_irqrestore(&wq_head->lock, flags);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(finish_wait);
|
|
|
|
|
2017-03-05 16:33:16 +07:00
|
|
|
int autoremove_wake_function(struct wait_queue_entry *wq_entry, unsigned mode, int sync, void *key)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2017-03-05 16:33:16 +07:00
|
|
|
int ret = default_wake_function(wq_entry, mode, sync, key);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
if (ret)
|
sched/wait: Disambiguate wq_entry->task_list and wq_head->task_list naming
So I've noticed a number of instances where it was not obvious from the
code whether ->task_list was for a wait-queue head or a wait-queue entry.
Furthermore, there's a number of wait-queue users where the lists are
not for 'tasks' but other entities (poll tables, etc.), in which case
the 'task_list' name is actively confusing.
To clear this all up, name the wait-queue head and entry list structure
fields unambiguously:
struct wait_queue_head::task_list => ::head
struct wait_queue_entry::task_list => ::entry
For example, this code:
rqw->wait.task_list.next != &wait->task_list
... is was pretty unclear (to me) what it's doing, while now it's written this way:
rqw->wait.head.next != &wait->entry
... which makes it pretty clear that we are iterating a list until we see the head.
Other examples are:
list_for_each_entry_safe(pos, next, &x->task_list, task_list) {
list_for_each_entry(wq, &fence->wait.task_list, task_list) {
... where it's unclear (to me) what we are iterating, and during review it's
hard to tell whether it's trying to walk a wait-queue entry (which would be
a bug), while now it's written as:
list_for_each_entry_safe(pos, next, &x->head, entry) {
list_for_each_entry(wq, &fence->wait.head, entry) {
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-20 17:06:46 +07:00
|
|
|
list_del_init(&wq_entry->entry);
|
2005-04-17 05:20:36 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(autoremove_wake_function);
|
|
|
|
|
2014-10-31 17:57:30 +07:00
|
|
|
static inline bool is_kthread_should_stop(void)
|
|
|
|
{
|
|
|
|
return (current->flags & PF_KTHREAD) && kthread_should_stop();
|
|
|
|
}
|
2014-09-24 15:18:47 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DEFINE_WAIT_FUNC(wait, woken_wake_func);
|
|
|
|
*
|
2017-03-05 17:10:18 +07:00
|
|
|
* add_wait_queue(&wq_head, &wait);
|
2014-09-24 15:18:47 +07:00
|
|
|
* for (;;) {
|
|
|
|
* if (condition)
|
|
|
|
* break;
|
|
|
|
*
|
|
|
|
* p->state = mode; condition = true;
|
|
|
|
* smp_mb(); // A smp_wmb(); // C
|
2017-03-05 16:33:16 +07:00
|
|
|
* if (!wq_entry->flags & WQ_FLAG_WOKEN) wq_entry->flags |= WQ_FLAG_WOKEN;
|
2014-09-24 15:18:47 +07:00
|
|
|
* schedule() try_to_wake_up();
|
|
|
|
* p->state = TASK_RUNNING; ~~~~~~~~~~~~~~~~~~
|
2017-03-05 16:33:16 +07:00
|
|
|
* wq_entry->flags &= ~WQ_FLAG_WOKEN; condition = true;
|
2014-09-24 15:18:47 +07:00
|
|
|
* smp_mb() // B smp_wmb(); // C
|
2017-03-05 16:33:16 +07:00
|
|
|
* wq_entry->flags |= WQ_FLAG_WOKEN;
|
2014-09-24 15:18:47 +07:00
|
|
|
* }
|
2017-03-05 17:10:18 +07:00
|
|
|
* remove_wait_queue(&wq_head, &wait);
|
2014-09-24 15:18:47 +07:00
|
|
|
*
|
|
|
|
*/
|
2017-03-05 16:33:16 +07:00
|
|
|
long wait_woken(struct wait_queue_entry *wq_entry, unsigned mode, long timeout)
|
2014-09-24 15:18:47 +07:00
|
|
|
{
|
|
|
|
set_current_state(mode); /* A */
|
|
|
|
/*
|
|
|
|
* The above implies an smp_mb(), which matches with the smp_wmb() from
|
|
|
|
* woken_wake_function() such that if we observe WQ_FLAG_WOKEN we must
|
|
|
|
* also observe all state before the wakeup.
|
|
|
|
*/
|
2017-03-05 16:33:16 +07:00
|
|
|
if (!(wq_entry->flags & WQ_FLAG_WOKEN) && !is_kthread_should_stop())
|
2014-09-24 15:18:47 +07:00
|
|
|
timeout = schedule_timeout(timeout);
|
|
|
|
__set_current_state(TASK_RUNNING);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The below implies an smp_mb(), it too pairs with the smp_wmb() from
|
|
|
|
* woken_wake_function() such that we must either observe the wait
|
|
|
|
* condition being true _OR_ WQ_FLAG_WOKEN such that we will not miss
|
|
|
|
* an event.
|
|
|
|
*/
|
2017-03-05 16:33:16 +07:00
|
|
|
smp_store_mb(wq_entry->flags, wq_entry->flags & ~WQ_FLAG_WOKEN); /* B */
|
2014-09-24 15:18:47 +07:00
|
|
|
|
|
|
|
return timeout;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(wait_woken);
|
|
|
|
|
2017-03-05 16:33:16 +07:00
|
|
|
int woken_wake_function(struct wait_queue_entry *wq_entry, unsigned mode, int sync, void *key)
|
2014-09-24 15:18:47 +07:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Although this function is called under waitqueue lock, LOCK
|
|
|
|
* doesn't imply write barrier and the users expects write
|
|
|
|
* barrier semantics on wakeup functions. The following
|
|
|
|
* smp_wmb() is equivalent to smp_wmb() in try_to_wake_up()
|
2015-05-12 15:51:55 +07:00
|
|
|
* and is paired with smp_store_mb() in wait_woken().
|
2014-09-24 15:18:47 +07:00
|
|
|
*/
|
|
|
|
smp_wmb(); /* C */
|
2017-03-05 16:33:16 +07:00
|
|
|
wq_entry->flags |= WQ_FLAG_WOKEN;
|
2014-09-24 15:18:47 +07:00
|
|
|
|
2017-03-05 16:33:16 +07:00
|
|
|
return default_wake_function(wq_entry, mode, sync, key);
|
2014-09-24 15:18:47 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(woken_wake_function);
|