[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41C15583@IRSMSX102.ger.corp.intel.com>
Date: Mon, 21 Nov 2016 15:39:19 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: David Windsor <dwindsor@...il.com>
CC: Alexei Starovoitov <alexei.starovoitov@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
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()
> 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.
Also, simple atomic_dec() is used pretty much everywhere for counters, which we don’t have a straight match in refcount_t API.
Powered by blists - more mailing lists