Commit 9c40365a authored by Jann Horn's avatar Jann Horn Committed by Thomas Gleixner

threads: Update PID limit comment according to futex UAPI change

The futex UAPI changed back in commit 76b81e2b ("[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: default avatarJann Horn <jannh@google.com>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20200302112939.8068-1-jannh@google.com
parent 6c8116c9
...@@ -61,8 +61,8 @@ setup that list. ...@@ -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. ...@@ -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: ...@@ -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: ...@@ -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: ...@@ -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 @@ ...@@ -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))
......
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