Commit 0699fd94 authored by Darren Hart's avatar Darren Hart Committed by Thomas Gleixner

futex: Correct futex_q woken state commentary

Use kernel-doc format to describe struct futex_q.

Correct the wakeup definition to eliminate the statement about
waking the waiter between the plist_del() and the q->lock_ptr = 0.

Note in the comment that PI futexes have a different definition of
the woken state.
Signed-off-by: default avatarDarren Hart <dvhltc@us.ibm.com>
Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Dinakar Guniguntala <dino@in.ibm.com>
Cc: John Stultz <johnstul@us.ibm.com>
LKML-Reference: <20090922053029.8717.62798.stgit@Aeon>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
parent 29b33bb7
...@@ -89,36 +89,36 @@ struct futex_pi_state { ...@@ -89,36 +89,36 @@ struct futex_pi_state {
union futex_key key; union futex_key key;
}; };
/* /**
* We use this hashed waitqueue instead of a normal wait_queue_t, so * struct futex_q - The hashed futex queue entry, one per waiting task
* @task: the task waiting on the futex
* @lock_ptr: the hash bucket lock
* @key: the key the futex is hashed on
* @pi_state: optional priority inheritance state
* @rt_waiter: rt_waiter storage for use with requeue_pi
* @requeue_pi_key: the requeue_pi target futex key
* @bitset: bitset for the optional bitmasked wakeup
*
* We use this hashed waitqueue, instead of a normal wait_queue_t, so
* we can wake only the relevant ones (hashed queues may be shared). * we can wake only the relevant ones (hashed queues may be shared).
* *
* A futex_q has a woken state, just like tasks have TASK_RUNNING. * A futex_q has a woken state, just like tasks have TASK_RUNNING.
* It is considered woken when plist_node_empty(&q->list) || q->lock_ptr == 0. * It is considered woken when plist_node_empty(&q->list) || q->lock_ptr == 0.
* The order of wakup is always to make the first condition true, then * The order of wakup is always to make the first condition true, then
* wake up q->waiter, then make the second condition true. * the second.
*
* PI futexes are typically woken before they are removed from the hash list via
* the rt_mutex code. See unqueue_me_pi().
*/ */
struct futex_q { struct futex_q {
struct plist_node list; struct plist_node list;
/* Waiter reference */
struct task_struct *task;
/* Which hash list lock to use: */ struct task_struct *task;
spinlock_t *lock_ptr; spinlock_t *lock_ptr;
/* Key which the futex is hashed on: */
union futex_key key; union futex_key key;
/* Optional priority inheritance state: */
struct futex_pi_state *pi_state; struct futex_pi_state *pi_state;
/* rt_waiter storage for requeue_pi: */
struct rt_mutex_waiter *rt_waiter; struct rt_mutex_waiter *rt_waiter;
/* The expected requeue pi target futex key: */
union futex_key *requeue_pi_key; union futex_key *requeue_pi_key;
/* Bitset for the optional bitmasked wakeup */
u32 bitset; u32 bitset;
}; };
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment