[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Dec 2016 09:48:27 -0500
From: David Windsor <dwindsor@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Boqun Feng <boqun.feng@...il.com>, Kees Cook <keescook@...omium.org>,
"Reshetova, Elena" <elena.reshetova@...el.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Greg KH <gregkh@...uxfoundation.org>,
"will.deacon@....com" <will.deacon@....com>, Hans Liljestrand <ishkamiel@...il.com>,
"aik@...abs.ru" <aik@...abs.ru>, "david@...son.dropbear.id.au" <david@...son.dropbear.id.au>
Subject: Re: Conversion from atomic_t to refcount_t: summary of issues
On Wed, Dec 7, 2016 at 2:03 PM, David Windsor <dwindsor@...il.com> wrote:
> On Wed, Dec 7, 2016 at 8:24 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>> On Fri, Dec 02, 2016 at 03:25:42PM -0500, David Windsor wrote:
>>> On Thu, Dec 1, 2016 at 8:17 PM, Boqun Feng <boqun.feng@...il.com> wrote:
>>
>>> > So we currently don't have a clear semantics for stats_t, do we?
>>>
>>> We had a discussion about the stats_t API in another thread. We
>>> agreed upon add(), sub(), inc(), dec(), read() and set().
>>>
>>> > What kind of atomic_t should be replaced with stats_t?
>>>
>>> stats_t is used for those cases in which an atomic variable is
>>> required, but the overflow of this variable isn't of much concern.
>>> Typically, these types of variables are counters of some kind (rx/tx
>>> counts, etc), but not always. Perhaps "stats_t" isn't the best type
>>> name. We actually used "atomic_wrap_t" in previous iterations.
>>
>> And atomic_wrap_t is a horrid trainwreck. Please as to explain the
>> semantics of atomic_wrap_cmpxchg(). How does wrapping apply to something
>> that doesn't do sign bits.
>>
>
> atomic_wrap_t grew out of a desire to fix an already broken system for
> doing reference counting. atomic_t is being widely used for both
> reference counting (which should not overflow), non-reference
> counting, and other operations. atomic_wrap_t provides the semantics
> of the "original" atomic_t: atomic operations with no overflow
> protection. Thus, atomic_wrap_cmpxchg(): the cmpxchg operation for
> atomic_wrap_t types. Abominations like this sometimes exist in RFC
> series. In this case, we came up with the atomic_wrap API by mostly
> creating an atomic_wrap-ified version of each atomic_t API function.
>
After giving this some more thought, I feel I should mention that
kernel reference counting is obviously not "broken" as stated above.
I was just referring to the fact that a single type is used for both
reference counting and non-reference counting, so any protection (and
added performance hit) added to atomic_t will be picked up in the
non-reference counter cases as well.
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.
