[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161110213952.GB3117@twins.programming.kicks-ass.net>
Date: Thu, 10 Nov 2016 22:39:52 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: David Windsor <dave@...gbits.org>
Cc: kernel-hardening@...ts.openwall.com, Will Deacon <will.deacon@....com>,
Greg KH <gregkh@...uxfoundation.org>,
Elena Reshetova <elena.reshetova@...el.com>,
Arnd Bergmann <arnd@...db.de>, Thomas Gleixner <tglx@...utronix.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 Thu, Nov 10, 2016 at 04:23:08PM -0500, David Windsor wrote:
> Discussions have been occurring since KSPP has begun: do we need a
Note that I was not included in any of that. If you hide in a corner on
the intartubes don't be surprised people have no clue what you're on
about.
> specialized type for reference counters? Oh, wait, we do: kref.
> Wait! kref is implemented with atomic_t.
>
> So, what? We obviously need an atomicity for a reference counter
> type. So, do we simply implement the HARDENED_ATOMIC protected
> version of atomic_t "inside" of kref and leave atomic_t alone?
But you could provide a small subset of the atomic_t API for that, under
a different type.
That way you don't get utter shite like atomic_cmpxchg_wrap() for
instance.
>From what I can see only all the add/sub variants have overflow checks,
but all the operations get _wrap() prefixes, even where it doesn't make
any bloody sense. _wrap() on bitops?, _wrap() on cmpxchg(). You must be
bloody joking right?
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.
