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.