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

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.

> > In the link David  pointed out, there are a few cases where a
> > stats_t is put on a correctness-related variable. I don't think
> > that's a good place to use stats_t.
> >
> Yeah, I just grabbed a few examples I noted during my stats_t
> conversion work.  The drivers/ tree is littered with stats_t
> instances.

Not sure how to respond to this, if you're converting all that to
stats_t then you're doing it wrong.

Most of what you showed should very emphatically not be stats_t.

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.