[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Dec 2016 14:36:21 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Kees Cook <keescook@...omium.org>
Cc: David Windsor <dwindsor@...il.com>,
"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>,
Boqun Feng <boqun.feng@...il.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 Thu, Dec 01, 2016 at 03:20:29PM -0800, Kees Cook wrote:
> There doesn't seem to be a good reason NOT to have stats_t, beyond the
> work needed to create it and audit the places it should be used.
API proliferation is a negative. Esp. if you have APIs that provide
overlapping / redundant functionality.
Its why I currently detest kref, and why I never used it (and actively
moved people away from it for code that I work on). Its daft wrappery
(and I know Greg disagrees).
Sure, you can add atomic_stats_t or whatever name gets decided upon (I
think Boqun had a good point in that there's plenty stats that are
!atomic -- also, I don't see you proposing to split "int" into separate
types per use-case), but don't expect me to use it for the code that I
write.
refcount_t makes sense in that it has clearly defined semantics that are
not elsewhere provided and doesn't provide operations that defeat those
semantics or the use-case.
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.
