[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Jul 2019 18:55:47 +0200
From: Jann Horn <jannh@...gle.com>
To: Kees Cook <keescook@...omium.org>
Cc: Ondrej Mosnacek <omosnace@...hat.com>, NitinGote <nitin.r.gote@...el.com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>, Paul Moore <paul@...l-moore.com>,
Stephen Smalley <sds@...ho.nsa.gov>, Eric Paris <eparis@...isplace.org>,
SElinux list <selinux@...r.kernel.org>,
Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] selinux: convert struct sidtab count to refcount_t
On Wed, Jul 24, 2019 at 5:54 PM Kees Cook <keescook@...omium.org> wrote:
> On Wed, Jul 24, 2019 at 04:28:31PM +0200, Jann Horn wrote:
> > On Wed, Jul 24, 2019 at 12:17 AM Kees Cook <keescook@...omium.org> wrote:
> > > Perhaps we need a "statistics" counter type for these kinds of counters?
> > > "counter_t"? I bet there are a lot of atomic_t uses that are just trying
> > > to be counters. (likely most of atomic_t that isn't now refcount_t ...)
> >
> > This isn't a statistics counter though; this thing needs ordered
> > memory accesses, which you wouldn't need for statistics.
>
> Okay, it'd be a "very accurate" counter type? It _could_ be used for
> statistics. I guess what I mean is that there are a lot of places using
> atomic_t just for upward counting that don't care about wrapping, etc.
(Accurate) statistics counters need RMW ops, don't need memory
ordering, usually can't be locked against writes, and may not care
about wrapping.
This thing doesn't need RMW ops, does need memory ordering, can be
locked against writes, and definitely shouldn't wrap.
I agree that there are a bunch of statistics counters in the kernel,
and it's not necessarily a bad idea to use a separate type for them;
but this is not a statistics counter.
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.
