You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
futex: documentation: fix inconsistent description of futex list_op_pending
Strictly speaking list_op_pending points to the 'lock entry', not the
'lock word' (which is actually at 'offset' from 'lock entry'). We can
infer this based on reading the code in kernel/futex.c:
struct robust_list __user *entry, *next_entry, *pending;
...
if (fetch_robust_entry(&pending, &head->list_op_pending, &pip))
return;
...
if (pending)
handle_futex_death((void __user *)pending + futex_offset,
curr, pip);
Which is also consistent with the rest of the docs on robust futex lists.
Signed-off-by: Matt Helsley <matthltc@us.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linuxtronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
committed by
Linus Torvalds
parent
665c7741fb
commit
26c369dada
@@ -135,7 +135,7 @@ manipulating this list), the user code must observe the following
|
||||
protocol on 'lock entry' insertion and removal:
|
||||
|
||||
On insertion:
|
||||
1) set the 'list_op_pending' word to the address of the 'lock word'
|
||||
1) set the 'list_op_pending' word to the address of the 'lock entry'
|
||||
to be inserted,
|
||||
2) acquire the futex lock,
|
||||
3) add the lock entry, with its thread id (TID) in the bottom 29 bits
|
||||
@@ -143,7 +143,7 @@ On insertion:
|
||||
4) clear the 'list_op_pending' word.
|
||||
|
||||
On removal:
|
||||
1) set the 'list_op_pending' word to the address of the 'lock word'
|
||||
1) set the 'list_op_pending' word to the address of the 'lock entry'
|
||||
to be removed,
|
||||
2) remove the lock entry for this lock from the 'head' list,
|
||||
2) release the futex lock, and
|
||||
|
||||
Reference in New Issue
Block a user