Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Dec 2016 17:26:18 +0100
From: Peter Zijlstra <>
To: David Windsor <>
Cc: Liljestrand Hans <>,
	"Reshetova, Elena" <>,
	"" <>,
	Greg KH <>,
	Kees Cook <>,
	"" <>,
	Boqun Feng <>, "" <>,
	"" <>
Subject: Re: Conversion from atomic_t to refcount_t: summary of issues

On Wed, Dec 07, 2016 at 10:59:47AM -0500, David Windsor wrote:
> On Wed, Dec 7, 2016 at 8:52 AM, Peter Zijlstra <> wrote:

> > All in all I'm not inclined to add {add,,dec}_return() to
> > refcount, as previously stated, they don't make sense.
> Is the plan now to audit all {add,sub,inc,dec}_return() call sites?
> This should probably happen anyway, due to the amount of funkiness
> uncovered by Hans' mini-audit. Then we can rewrite actual reference
> counting code that calls the unsupported {add,sub,inc,dec}_return() to
> use something else?

The ip_vs_dest cache thing would receive 2 patches, one doing the global
+1, the second conversion to refcount_t.

For BPF we'd need to talk to Alexei to see if the custom limit still
makes sense, but I'd be inclined to simply drop that in the refcount_t

As to the tty and usb-gadget ones, those constructs are actually racy,
but I'm not sure the races matter. But I would certainly prefer to
rework then to be race-free.

But I wouldn't go so far as to audit all *_return calls, just those that
pop up while hunting refcounts.

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.