[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Mar 2020 14:57:40 +0100
From: Jann Horn <jannh@...gle.com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Will Deacon <will@...nel.org>, Kees Cook <keescook@...omium.org>,
Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
kernel list <linux-kernel@...r.kernel.org>, Elena Reshetova <elena.reshetova@...el.com>,
Hanjun Guo <guohanjun@...wei.com>, Jan Glauber <jglauber@...vell.com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH v2] lib/refcount: Document interaction with PID_MAX_LIMIT
On Tue, Mar 3, 2020 at 2:07 PM Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
> On Tue, 3 Mar 2020 at 11:54, Jann Horn <jannh@...gle.com> wrote:
> >
> > Document the circumstances under which refcount_t's saturation mechanism
> > works deterministically.
> >
> > Signed-off-by: Jann Horn <jannh@...gle.com>
>
> I /think/ the main point of Kees's suggestion was that FUTEX_TID_MASK
> is UAPI, so unlikely to change.
Yeah, but it has already changed three times in git history:
76b81e2b0e224 ("[PATCH] lightweight robust futexes updates 2"):
0x1fffffff -> 0x3fffffff
d0aa7a70bf03b ("futex_requeue_pi optimization"): 0x3fffffff -> 0x0fffffff
bd197234b0a6 ("Revert "futex_requeue_pi optimization""): 0x0fffffff ->
0x3fffffff
I just sent a patch to fix up a comment that still claimed the mask
was 0x1fffffff... so I didn't want to explicitly write the new value
here.
While making the value *bigger* would probably be a bit hard (and
unnecessary), making it smaller would be fairly easy here - the field
is populated by userspace, so even though the mask is 0x3fffffff,
userspace will never set the upper bits, so they're effectively
reserved bits with value 0.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
