Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Dec 2016 09:48:27 -0500
From: David Windsor <>
To: Peter Zijlstra <>
Cc: Boqun Feng <>, Kees Cook <>, 
	"Reshetova, Elena" <>, 
	"" <>, Greg KH <>, 
	"" <>, Hans Liljestrand <>, 
	"" <>, "" <>
Subject: Re: Conversion from atomic_t to refcount_t: summary of issues

On Wed, Dec 7, 2016 at 2:03 PM, David Windsor <> wrote:
> On Wed, Dec 7, 2016 at 8:24 AM, Peter Zijlstra <> 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 <> 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.