[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Nov 2016 11:23:22 +1100
From: Alexey Kardashevskiy <aik@...abs.ru>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Reshetova, Elena" <elena.reshetova@...el.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>, 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 29/11/16 20:31, Peter Zijlstra wrote:
> On Tue, Nov 29, 2016 at 02:19:56PM +1100, Alexey Kardashevskiy wrote:
>> 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).
>>
>
> Thanks, we'll convert it to a 32bit refcount then.
I'd rather make it "long" as everything else in that struct is long (шюую
64ише) and having 32bit value in a middle won't save space but create an
useless gap.
--
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.
