Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 Dec 2016 16:31:16 -0500
From: David Windsor <>
To: Peter Zijlstra <>
Cc: "Reshetova, Elena" <>, 
	"" <>, Greg KH <>, 
	Kees Cook <>, "" <>, 
	Boqun Feng <>, Hans Liljestrand <>, 
	"" <>, "" <>
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):

to view these snippets in context.  Line numbers are accurate to within a
few lines).

    extern atomic_long_wrap_t num_poisoned_pages;

    atomic_long_wrap_t      vm_stat[NR_VM_NODE_STAT_ITEMS];

    atomic_long_wrap_t num_poisoned_pages __read_mostly =

... 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:

   if (uid_valid(loginuid))
        sessionid = (unsigned int)atomic_inc_return_wrap(&session_id);

    seq_nr = atomic_inc_return_wrap(&pd->seq_nr);

    s0 += atomic_long_read_wrap(&rdp->exp_workdone0);

    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.


On Thu, Dec 1, 2016 at 2:15 PM, Peter Zijlstra <> 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.