[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Nov 2016 15:48:52 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Mark Rutland <mark.rutland@....com>,
kernel-hardening@...ts.openwall.com,
Kees Cook <keescook@...omium.org>,
Greg KH <gregkh@...uxfoundation.org>,
Will Deacon <will.deacon@....com>,
Elena Reshetova <elena.reshetova@...el.com>,
Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <h.peter.anvin@...el.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC
On Fri, Nov 11, 2016 at 03:39:05PM +0100, Thomas Gleixner wrote:
> On Fri, 11 Nov 2016, Peter Zijlstra wrote:
> > A wee bit like so...
> > +
> > +static inline bool refcount_sub_and_test(int i, refcount_t *r)
>
> Why would we want to expose that at all? refcount_inc() and
> refcount_dec_and_test() is what is required for refcounting.
>
> I know there are a few users of kref_sub() in tree, but that's all
> undocumented voodoo, which should not be proliferated.
I tend to agree. There are a few other sites that do multiple get/put as
well using atomic_t.
So supporting them using refcount_t is trivial -- simply match the
atomic*() functions in semantics with added wrappery tests, but you're
right in that having these encourages 'creative' use which we would be
better off without.
Ideally the audit would include sanitizing this. Moreover, there really
is only a handfull of these creative user, so maybe we could just leave
them be.
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.
