[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1PpgjRKFemEi7mLuECh1srs8bbzoc07RSrFsx+febjaQ@mail.gmail.com>
Date: Mon, 11 Mar 2019 15:00:50 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Jason Gunthorpe <jgg@...lanox.com>
Cc: Qian Cai <cai@....pw>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm/debug: add a cast to u64 for atomic64_read()
On Mon, Mar 11, 2019 at 1:21 PM Jason Gunthorpe <jgg@...lanox.com> wrote:
> On Sun, Mar 10, 2019 at 08:58:15PM -0700, Davidlohr Bueso wrote:
> > On Sun, 10 Mar 2019, Qian Cai wrote:
> >
> > Acked-by: Davidlohr Bueso <dbueso@...e.de>
>
> Not saying this patch shouldn't go ahead..
>
> But is there a special reason the atomic64*'s on ppc don't use the u64
> type like other archs? Seems like a better thing to fix than adding
> casts all over the place.
Agreed in principle, but I'd note that it's not just ppc64, but almost all
64-bit architectures. x86-64 and arm64 changed over last year
from returning 'long' to 'long long', apparently as an unintended
side effect of commits 8bf705d13039 ("locking/atomic/x86: Switch
atomic.h to use atomic-instrumented.h") and c0df10812835 ("arm64,
locking/atomics: Use instrumented atomics").
It would be nice to just do the instrumented atomics on all 64-bit
architectures for consistency, but that would be a lot of work, and
would not actually give us additional instrumentation on most of them,
since they don't support KASAN (except s390).
Arnd
Powered by blists - more mailing lists