Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Dec 2016 07:55:15 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Liljestrand Hans <ishkamiel@...il.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>, David Windsor <dwindsor@...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 Fri, Dec 16, 2016 at 12:10:21PM +0000, Reshetova, Elena wrote:
> 
> > Is it ok to add at least refcount_inc_if_zero() ?
> 
> Of course not.
> 
> > We already have refcount_dec_if_one(), reffcount_dec_not_one() and
> > refcount_inc_not_zero(), so this one is the only missing one and would
> > greatly help in couple of cases.
> 
> No, its absolutely insane. 0 means its freed, you cannot get another
> reference at that point.
> 
> If you have code that relies on that, its broken.

Well, again, you are right in theory, but in practice for example for struct sched_group { atomic_t ref; ... }:

http://lxr.free-electrons.com/source/kernel/sched/core.c#L6178

To me this is a refcounter that needs the protection.



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.