[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41C220DD@IRSMSX102.ger.corp.intel.com>
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.
