|
Message-ID: <CAEXv5_isZ__znAw5vvE_srdP+irJW=TnUy2jQZxM33ZCAg037A@mail.gmail.com>
Date: Thu, 1 Dec 2016 16:31:16 -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
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):
(Use
https://github.com/ereshetova/linux-stable/blob/hardened_atomic_next_stats
to view these snippets in context. Line numbers are accurate to within a
few lines).
include/linux/mm.h:2360:
extern atomic_long_wrap_t num_poisoned_pages;
include/linux/mmzone.h:695
atomic_long_wrap_t vm_stat[NR_VM_NODE_STAT_ITEMS];
mm/memory-failure.c:64:
atomic_long_wrap_t num_poisoned_pages __read_mostly =
ATOMIC_LONG_INIT(0);
... and several others. Note, these are only from stats_t conversions for
the mm subsystem.
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);
kernel/padata.c:58:
seq_nr = atomic_inc_return_wrap(&pd->seq_nr);
kernel/rcu/tree_trace.c:192:
s0 += atomic_long_read_wrap(&rdp->exp_workdone0);
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.
I haven't yet completed my audit of the entire kernel source tree in my
atomic_t-to-stats_t conversion efforts, so I don't yet have an exhaustive
list of non-supported functions, but will at some point soon.
Thanks,
David
On Thu, Dec 1, 2016 at 2:15 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, Nov 29, 2016 at 03:35:15PM +0000, Reshetova, Elena wrote:
> > but Hans will be finishing processing
>
> > > > The following functions are also needed quite commonly:
> > >
> > > > refcount_inc_return()
> > > > refcount_dec_return()
> > >
> > > What for? They don't typicaly make sense for refcounting? Other than
> the
> > > trivial pattern of dec_return() == 0, which is already well covered.
>
> Hans, could you point me to a few users of {inc,dec}_return() that I can
> audit for (in)sanity?
>
Content of type "text/html" skipped
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.