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.