From: Mark Rutland <email@example.com> To: Peter Zijlstra <firstname.lastname@example.org> Cc: Arnd Bergmann <email@example.com>, Qian Cai <firstname.lastname@example.org>, Jason Gunthorpe <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: Re: [PATCH] mm/debug: add a cast to u64 for atomic64_read() Date: Wed, 13 Mar 2019 14:35:53 +0000 [thread overview] Message-ID: <20190313143552.GA39315@lakrids.cambridge.arm.com> (raw) In-Reply-To: <20190313091844.GA24390@hirez.programming.kicks-ass.net> On Wed, Mar 13, 2019 at 10:18:44AM +0100, Peter Zijlstra wrote: > On Mon, Mar 11, 2019 at 03:20:04PM +0100, Arnd Bergmann wrote: > > On Mon, Mar 11, 2019 at 3:00 PM Qian Cai <firstname.lastname@example.org> wrote: > > > > > > On Mon, 2019-03-11 at 12:21 +0000, Jason Gunthorpe wrote: > > > > On Sun, Mar 10, 2019 at 08:58:15PM -0700, Davidlohr Bueso wrote: > > > > > On Sun, 10 Mar 2019, Qian Cai wrote: > > > > > > > > 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. > > s64 if anything, atomic stuff is signed (although since we have -fwrapv > it doesn't matter one whit). > > > > A bit of history here, > > > > > > https://patchwork.kernel.org/patch/7344011/#15495901 > > > > Ah, I had already forgotten about that discussion. > > > > At least the atomic_long part we discussed there has been resolved now > > as part of commit b5d47ef9ea5c ("locking/atomics: Switch to generated > > atomic-long"). > > > > Adding Mark Rutland to Cc, maybe he has some ideas of how to use > > the infrastructure he added to use consistent types for atomic64() > > on the remaining 64-bit architectures. > > A quick count shows there's only 5 definitions of atomic64_t in the > tree, it would be trivial to align them on type. > > $ git grep "} atomic64_t" > arch/arc/include/asm/atomic.h:} atomic64_t; > arch/arm/include/asm/atomic.h:} atomic64_t; > arch/x86/include/asm/atomic64_32.h:} atomic64_t; > include/asm-generic/atomic64.h:} atomic64_t; > include/linux/types.h:} atomic64_t; > > Note that the one used in _most_ cases, is the one from linux/types.h, > and that is using 'long'. The others, all typically on ILP32 platforms, > obviously must use long long. > > I have no objection to changing the types.h one to long long or all of > them to s64. It really shouldn't matter at all. I think that using s64 consistently (with any necessary alignment annotation) makes the most sense. That's unambigious, and what the common headers now use. Now that the scripted atomics are merged, I'd like to move arches over to arch_atomic_*(), so the argument and return types will become s64 everywhere. Thanks, Mark.
next prev parent reply other threads:[~2019-03-13 14:36 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-10 18:30 Qian Cai 2019-03-11 3:58 ` Davidlohr Bueso 2019-03-11 12:21 ` Jason Gunthorpe 2019-03-11 14:00 ` Qian Cai 2019-03-11 14:00 ` Qian Cai 2019-03-11 14:20 ` Arnd Bergmann 2019-03-11 14:20 ` Arnd Bergmann 2019-03-13 9:18 ` Peter Zijlstra 2019-03-13 13:46 ` Arnd Bergmann 2019-03-13 13:46 ` Arnd Bergmann 2019-03-13 14:21 ` Peter Zijlstra 2019-03-13 14:24 ` Peter Zijlstra 2019-03-13 14:35 ` Mark Rutland [this message] 2019-03-13 14:57 ` Arnd Bergmann 2019-03-13 14:57 ` Arnd Bergmann 2019-03-13 16:29 ` Mark Rutland 2019-03-11 14:00 ` Arnd Bergmann 2019-03-11 14:00 ` Arnd Bergmann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190313143552.GA39315@lakrids.cambridge.arm.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] mm/debug: add a cast to u64 for atomic64_read()' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.