Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Dec 2016 09:13:58 +0000
From: "Reshetova, Elena" <>
To: Peter Zijlstra <>
CC: Liljestrand Hans <>,
	"" <>,
	Greg KH <>, Kees Cook <>,
	"" <>, Boqun Feng
	<>, David Windsor <>, ""
	<>, "" <>
Subject: RE: Conversion from atomic_t to refcount_t: summary of issues

> On Mon, Dec 19, 2016 at 07:55:15AM +0000, Reshetova, Elena wrote:
> > Well, again, you are right in theory, but in practice for example for struct
> sched_group { atomic_t ref; ... }:
> >
> >
> >
> > To me this is a refcounter that needs the protection.
> Only if you have more than UINT_MAX CPUs or something like that.
> And if you really really want to use refcount_t there, you could +1 the
> scheme and it'd work again.

Well, yes, probably, but there are many cases like this in practice, so we would need to have a good plan how to get it all submitted and tested properly. The current patch set is already bigger than what we had before and it is only growing. 
Hans will provide more info later today based on his testing, which shows many places in kernel core where we DO actually have increment on zero happening in practice and whole kernel doesn't even boot with the strictest approach (refusing to inc on zero). And we are only able to test for x86.... 

Given the massive amount of changes, it would be good to merge this at least in couple of stages: 

1) first soft version of refcount_t API which at least allows increment on zero and all atomic_t used as refcounter occurrences that don't require reference counter scheme change (+1 or other)
2) patch set that fixes all problematic places (potentially with code rewrite) 
3) patch that removes possibility of inc on zero from refcount_t

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.