mirror of https://gitee.com/openkylin/linux.git
threads: Update PID limit comment according to futex UAPI change
The futex UAPI changed back in commit 76b81e2b0e
("[PATCH] lightweight
robust futexes updates 2"), which landed in v2.6.17: FUTEX_TID_MASK is now
0x3fffffff instead of 0x1fffffff. Update the corresponding comment in
include/linux/threads.h.
Documentation mentions that only the lower 29 bits are available for TID
storage, but as the UAPI header released the bit already via
FUTEX_TID_MASK, this is moot as well. Fix it up.
[ tglx: Fixed up documentation ]
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20200302112939.8068-1-jannh@google.com
This commit is contained in:
parent
6c8116c914
commit
9c40365a65
|
@ -61,8 +61,8 @@ setup that list.
|
||||||
address of the associated 'lock entry', plus or minus, of what will
|
address of the associated 'lock entry', plus or minus, of what will
|
||||||
be called the 'lock word', from that 'lock entry'. The 'lock word'
|
be called the 'lock word', from that 'lock entry'. The 'lock word'
|
||||||
is always a 32 bit word, unlike the other words above. The 'lock
|
is always a 32 bit word, unlike the other words above. The 'lock
|
||||||
word' holds 3 flag bits in the upper 3 bits, and the thread id (TID)
|
word' holds 2 flag bits in the upper 2 bits, and the thread id (TID)
|
||||||
of the thread holding the lock in the bottom 29 bits. See further
|
of the thread holding the lock in the bottom 30 bits. See further
|
||||||
below for a description of the flag bits.
|
below for a description of the flag bits.
|
||||||
|
|
||||||
The third word, called 'list_op_pending', contains transient copy of
|
The third word, called 'list_op_pending', contains transient copy of
|
||||||
|
@ -128,7 +128,7 @@ that thread's robust_futex linked lock list a given time.
|
||||||
A given futex lock structure in a user shared memory region may be held
|
A given futex lock structure in a user shared memory region may be held
|
||||||
at different times by any of the threads with access to that region. The
|
at different times by any of the threads with access to that region. The
|
||||||
thread currently holding such a lock, if any, is marked with the threads
|
thread currently holding such a lock, if any, is marked with the threads
|
||||||
TID in the lower 29 bits of the 'lock word'.
|
TID in the lower 30 bits of the 'lock word'.
|
||||||
|
|
||||||
When adding or removing a lock from its list of held locks, in order for
|
When adding or removing a lock from its list of held locks, in order for
|
||||||
the kernel to correctly handle lock cleanup regardless of when the task
|
the kernel to correctly handle lock cleanup regardless of when the task
|
||||||
|
@ -141,7 +141,7 @@ On insertion:
|
||||||
1) set the 'list_op_pending' word to the address of the 'lock entry'
|
1) set the 'list_op_pending' word to the address of the 'lock entry'
|
||||||
to be inserted,
|
to be inserted,
|
||||||
2) acquire the futex lock,
|
2) acquire the futex lock,
|
||||||
3) add the lock entry, with its thread id (TID) in the bottom 29 bits
|
3) add the lock entry, with its thread id (TID) in the bottom 30 bits
|
||||||
of the 'lock word', to the linked list starting at 'head', and
|
of the 'lock word', to the linked list starting at 'head', and
|
||||||
4) clear the 'list_op_pending' word.
|
4) clear the 'list_op_pending' word.
|
||||||
|
|
||||||
|
@ -155,7 +155,7 @@ On removal:
|
||||||
|
|
||||||
On exit, the kernel will consider the address stored in
|
On exit, the kernel will consider the address stored in
|
||||||
'list_op_pending' and the address of each 'lock word' found by walking
|
'list_op_pending' and the address of each 'lock word' found by walking
|
||||||
the list starting at 'head'. For each such address, if the bottom 29
|
the list starting at 'head'. For each such address, if the bottom 30
|
||||||
bits of the 'lock word' at offset 'offset' from that address equals the
|
bits of the 'lock word' at offset 'offset' from that address equals the
|
||||||
exiting threads TID, then the kernel will do two things:
|
exiting threads TID, then the kernel will do two things:
|
||||||
|
|
||||||
|
@ -180,7 +180,5 @@ any point:
|
||||||
future kernel configuration changes) elements.
|
future kernel configuration changes) elements.
|
||||||
|
|
||||||
When the kernel sees a list entry whose 'lock word' doesn't have the
|
When the kernel sees a list entry whose 'lock word' doesn't have the
|
||||||
current threads TID in the lower 29 bits, it does nothing with that
|
current threads TID in the lower 30 bits, it does nothing with that
|
||||||
entry, and goes on to the next entry.
|
entry, and goes on to the next entry.
|
||||||
|
|
||||||
Bit 29 (0x20000000) of the 'lock word' is reserved for future use.
|
|
||||||
|
|
|
@ -29,7 +29,7 @@
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* A maximum of 4 million PIDs should be enough for a while.
|
* A maximum of 4 million PIDs should be enough for a while.
|
||||||
* [NOTE: PID/TIDs are limited to 2^29 ~= 500+ million, see futex.h.]
|
* [NOTE: PID/TIDs are limited to 2^30 ~= 1 billion, see FUTEX_TID_MASK.]
|
||||||
*/
|
*/
|
||||||
#define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \
|
#define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 : \
|
||||||
(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
|
(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
|
||||||
|
|
Loading…
Reference in New Issue