[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 Dec 2016 18:20:55 -0500
From: David Windsor <dwindsor@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Reshetova, Elena" <elena.reshetova@...el.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Greg KH <gregkh@...uxfoundation.org>,
Kees Cook <keescook@...omium.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 1, 2016 at 6:03 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Thu, Dec 01, 2016 at 04:31:16PM -0500, David Windsor wrote:
> > Also, I'd like to point out that while identifying stats_t instances, I
> > have found a similar distribution of non-standard functions (as agreed upon
> > for the stats_t API).
>
> > First, usage of atomic_long_wrap_t (there currently isn't a stats_long_t
> > planned for implementation):
>
> There isn't even a stats_t planned. I'm still very much not convinced
> stats_t is needed or even makes sense.
>
> It wouldn't have any different semantics from atomic_t, and the only
> argument Kees made was that reduced atomic_t usage would make it easier
> to spot refcounts, but you're already building tools to find those.
>
Then are we decided that overflow protection is going to be opt-in?
If atomic_t isn't protected by default (opt-in case), then yes, new
users will have no need to use a type other than atomic_t for their
shared statistical counters.
> Once the tools work, who cares.
>
> > Next, API calls outside of the proposed stats_t API:
> >
> > kernel/auditsc.c:2029:
> > if (uid_valid(loginuid))
> > sessionid = (unsigned int)atomic_inc_return_wrap(&session_id);
>
> This is _NOT_ a statistic counter and should not be stats_t
>
> > kernel/padata.c:58:
> > seq_nr = atomic_inc_return_wrap(&pd->seq_nr);
>
> Idem
>
> > kernel/rcu/tree_trace.c:192:
> > s0 += atomic_long_read_wrap(&rdp->exp_workdone0);
>
> Don't get the point, this one is actually trivial.
>
> > kernel/trace/trace_mmiotrace.c:123
> > atomic_xchg_wrap(&dropped_count, 0);
> >
> > ... and several others. Note, these are only from stats_t conversions in
> > the kernel/ directory.
>
> And while that thing counts, its not actually a statistics thing.
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.
