Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 Nov 2016 14:19:56 +1100
From: Alexey Kardashevskiy <aik@...abs.ru>
To: Peter Zijlstra <peterz@...radead.org>,
 "Reshetova, Elena" <elena.reshetova@...el.com>
Cc: "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>,
 Hans Liljestrand <ishkamiel@...il.com>, David Windsor <dwindsor@...il.com>,
 david@...son.dropbear.id.au
Subject: Re: Conversion from atomic_t to refcount_t: summary of issues

On 28/11/16 23:13, Peter Zijlstra wrote:
> On Mon, Nov 28, 2016 at 11:56:17AM +0000, Reshetova, Elena wrote:
>> First, about the types. 
>> We do have a number of instances of atomic_long_t used as refcounters, see below:
> 
> Right, those were expected. We could do long_refcount_t I suppose.
> 
>> And yes, we *do* have at least one instance (again not 100% finished,
>> more might show up) of atomic64_t used as refcounter:
>>
>> arch/powerpc/mm/mmu_context_iommu.c:
>> struct mm_iommu_table_group_mem_t {
>> ...
>>     atomic64_t mapped;
>> ...
>> }
> 
> *urgh*, Alexey does that really need to be atomic64_t ? Wouldn't
> atomic_long_t work for you?


It would, this code only works in 64bit where long==64bit anyway (in fact
even 32bit variant would do).



-- 
Alexey

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.