LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] threads: Update PID limit comment according to futex UAPI change
@ 2020-03-02 11:29 Jann Horn
2020-03-03 10:25 ` Peter Zijlstra
2020-03-21 16:50 ` [tip: sched/core] " tip-bot2 for Jann Horn
0 siblings, 2 replies; 4+ messages in thread
From: Jann Horn @ 2020-03-02 11:29 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar
Cc: Andrew Morton, Peter Zijlstra, Darren Hart, linux-kernel
The futex UAPI changed back in commit 76b81e2b0e22 ("[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.
Signed-off-by: Jann Horn <jannh@google.com>
---
include/linux/threads.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/threads.h b/include/linux/threads.h
index 3086dba525e20..18d5a74bcc3dd 100644
--- a/include/linux/threads.h
+++ b/include/linux/threads.h
@@ -29,7 +29,7 @@
/*
* 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 : \
(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
--
2.25.0.265.gbab2e86ba0-goog
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] threads: Update PID limit comment according to futex UAPI change
2020-03-02 11:29 [PATCH] threads: Update PID limit comment according to futex UAPI change Jann Horn
@ 2020-03-03 10:25 ` Peter Zijlstra
2020-03-03 14:12 ` Thomas Gleixner
2020-03-21 16:50 ` [tip: sched/core] " tip-bot2 for Jann Horn
1 sibling, 1 reply; 4+ messages in thread
From: Peter Zijlstra @ 2020-03-03 10:25 UTC (permalink / raw)
To: Jann Horn
Cc: Thomas Gleixner, Ingo Molnar, Andrew Morton, Darren Hart, linux-kernel
On Mon, Mar 02, 2020 at 12:29:39PM +0100, Jann Horn wrote:
> The futex UAPI changed back in commit 76b81e2b0e22 ("[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.
>
> Signed-off-by: Jann Horn <jannh@google.com>
> ---
> include/linux/threads.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/threads.h b/include/linux/threads.h
> index 3086dba525e20..18d5a74bcc3dd 100644
> --- a/include/linux/threads.h
> +++ b/include/linux/threads.h
> @@ -29,7 +29,7 @@
>
> /*
> * 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 : \
> (sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
I just noticed another mention of this in Documentation/robust-futex-ABI.txt
There it states that bit-29 is reserved for future use.
Thomas, do we want to release that bit and update all this?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] threads: Update PID limit comment according to futex UAPI change
2020-03-03 10:25 ` Peter Zijlstra
@ 2020-03-03 14:12 ` Thomas Gleixner
0 siblings, 0 replies; 4+ messages in thread
From: Thomas Gleixner @ 2020-03-03 14:12 UTC (permalink / raw)
To: Peter Zijlstra, Jann Horn
Cc: Ingo Molnar, Andrew Morton, Darren Hart, linux-kernel
Peter Zijlstra <peterz@infradead.org> writes:
> On Mon, Mar 02, 2020 at 12:29:39PM +0100, Jann Horn wrote:
>> The futex UAPI changed back in commit 76b81e2b0e22 ("[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.
>>
>> Signed-off-by: Jann Horn <jannh@google.com>
>> ---
>> include/linux/threads.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/threads.h b/include/linux/threads.h
>> index 3086dba525e20..18d5a74bcc3dd 100644
>> --- a/include/linux/threads.h
>> +++ b/include/linux/threads.h
>> @@ -29,7 +29,7 @@
>>
>> /*
>> * 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 : \
>> (sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
>
> I just noticed another mention of this in Documentation/robust-futex-ABI.txt
> There it states that bit-29 is reserved for future use.
>
> Thomas, do we want to release that bit and update all this?
In fact we've released it long ago:
include/uapi/linux/futex.h:
#define FUTEX_TID_MASK 0x3fffffff
Thanks,
tglx
^ permalink raw reply [flat|nested] 4+ messages in thread
* [tip: sched/core] threads: Update PID limit comment according to futex UAPI change
2020-03-02 11:29 [PATCH] threads: Update PID limit comment according to futex UAPI change Jann Horn
2020-03-03 10:25 ` Peter Zijlstra
@ 2020-03-21 16:50 ` tip-bot2 for Jann Horn
1 sibling, 0 replies; 4+ messages in thread
From: tip-bot2 for Jann Horn @ 2020-03-21 16:50 UTC (permalink / raw)
To: linux-tip-commits; +Cc: Jann Horn, Thomas Gleixner, x86, LKML
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 9c40365a65d62d7c06a95fb331b3442cb02d2fd9
Gitweb: https://git.kernel.org/tip/9c40365a65d62d7c06a95fb331b3442cb02d2fd9
Author: Jann Horn <jannh@google.com>
AuthorDate: Mon, 02 Mar 2020 12:29:39 +01:00
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Sat, 21 Mar 2020 17:48:13 +01:00
threads: Update PID limit comment according to futex UAPI change
The futex UAPI changed back in commit 76b81e2b0e22 ("[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
---
Documentation/robust-futex-ABI.txt | 14 ++++++--------
include/linux/threads.h | 2 +-
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/Documentation/robust-futex-ABI.txt b/Documentation/robust-futex-ABI.txt
index 8a5d34a..f24904f 100644
--- a/Documentation/robust-futex-ABI.txt
+++ b/Documentation/robust-futex-ABI.txt
@@ -61,8 +61,8 @@ setup that list.
address of the associated 'lock entry', plus or minus, of what will
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
- word' holds 3 flag bits in the upper 3 bits, and the thread id (TID)
- of the thread holding the lock in the bottom 29 bits. See further
+ word' holds 2 flag bits in the upper 2 bits, and the thread id (TID)
+ of the thread holding the lock in the bottom 30 bits. See further
below for a description of the flag bits.
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
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
-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
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'
to be inserted,
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
4) clear the 'list_op_pending' word.
@@ -155,7 +155,7 @@ On removal:
On exit, the kernel will consider the address stored in
'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
exiting threads TID, then the kernel will do two things:
@@ -180,7 +180,5 @@ any point:
future kernel configuration changes) elements.
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.
-
-Bit 29 (0x20000000) of the 'lock word' is reserved for future use.
diff --git a/include/linux/threads.h b/include/linux/threads.h
index 3086dba..18d5a74 100644
--- a/include/linux/threads.h
+++ b/include/linux/threads.h
@@ -29,7 +29,7 @@
/*
* 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 : \
(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-03-21 16:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-02 11:29 [PATCH] threads: Update PID limit comment according to futex UAPI change Jann Horn
2020-03-03 10:25 ` Peter Zijlstra
2020-03-03 14:12 ` Thomas Gleixner
2020-03-21 16:50 ` [tip: sched/core] " tip-bot2 for Jann Horn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).