[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161121154915.GB3124@twins.programming.kicks-ass.net>
Date: Mon, 21 Nov 2016 16:49:15 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
Cc: David Windsor <dwindsor@...il.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Kees Cook <keescook@...omium.org>,
Greg KH <gregkh@...uxfoundation.org>,
Will Deacon <will.deacon@....com>,
Arnd Bergmann <arnd@...db.de>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>,
Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [RFC][PATCH 2/7] kref: Add kref_read()
On Mon, Nov 21, 2016 at 03:39:19PM +0000, Reshetova, Elena wrote:
> > By the way, there are several sites where the use of
> > atomic_t/atomic_wrap_t as a counter ventures beyond the standard (inc,
> > dec, add, sub, read, set) operations we're planning on implementing
> > for both refcount_t and stats_t.
>
> Speaking of non-fitting patterns. This one is quite common in
> networking code for refcounters:
>
> if (atomic_cmpxchg(&cur->refcnt, 1, 0) == 1) {} This is from
> net/netfilter/nfnetlink_acct.c, but there are similar ones in other
> places.
Cute, but weird it doesn't actually decrement if not 1.
> Also, simple atomic_dec() is used pretty much everywhere for counters,
> which we don’t have a straight match in refcount_t API.
WARN_ON(refcount_dec_and_test(refs));
And seeing how I've implememented refcount_inc() in similar terms:
WARN_ON(!refcount_inc_not_zero(refs));
It might make sense to actually provide that.
Powered by blists - more mailing lists