From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [GIT PULL] percpu fix for v4.10-rc6 Date: Tue, 31 Jan 2017 17:11:41 -0500 Message-ID: <20170131221141.GA5379@htj.duckdns.org> References: <20170131165537.GC23970@htj.duckdns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Linus Torvalds Cc: "linux-arch@vger.kernel.org" , Linux Kernel Mailing List , dougmill@linux.vnet.ibm.com List-Id: linux-arch.vger.kernel.org Hello, Linus. On Tue, Jan 31, 2017 at 01:41:17PM -0800, Linus Torvalds wrote: > On Tue, Jan 31, 2017 at 1:32 PM, Linus Torvalds > wrote: > > > > I've pulled this, but I really think it's papering over the real > > issue. Adding "linux-arch" mailing list to ask architecture > > maintainers to check their implementation of the atomic ops that > > return a truth value. Yeah, for sure. > For example, looking at the x86-32 version, I see this: > > static inline int atomic64_add_unless(atomic64_t *v, long long a, long long u) > ... > return (int)a; > > which looks really horribly wrong, but the assembly implementation > actually returns 0/1 in %eax so it ends up being right - just > confusingly so. > > Also, to make things more confusing, the underscore version > (__atomic_add_unless()) actually returns the old value, not the truth > value of the comparison. > > So this area definitely is messy. The x86-64 versions actually look > fairly clean and return nice boolean values. We have a similar mess with bitops too. x86 is cleaned up to have bool returns but the generic implementation and a lot of other archs return the tested bit instead of 1/0. It'd be great to make all the boolean functions actually return bool. Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f196.google.com ([209.85.192.196]:34389 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167AbdAaWLo (ORCPT ); Tue, 31 Jan 2017 17:11:44 -0500 Date: Tue, 31 Jan 2017 17:11:41 -0500 From: Tejun Heo Subject: Re: [GIT PULL] percpu fix for v4.10-rc6 Message-ID: <20170131221141.GA5379@htj.duckdns.org> References: <20170131165537.GC23970@htj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Linus Torvalds Cc: "linux-arch@vger.kernel.org" , Linux Kernel Mailing List , dougmill@linux.vnet.ibm.com Message-ID: <20170131221141.uYqv2ctnNDwlEvFE-W24hFQcUCXE76XgOnkUGTZFfXU@z> Hello, Linus. On Tue, Jan 31, 2017 at 01:41:17PM -0800, Linus Torvalds wrote: > On Tue, Jan 31, 2017 at 1:32 PM, Linus Torvalds > wrote: > > > > I've pulled this, but I really think it's papering over the real > > issue. Adding "linux-arch" mailing list to ask architecture > > maintainers to check their implementation of the atomic ops that > > return a truth value. Yeah, for sure. > For example, looking at the x86-32 version, I see this: > > static inline int atomic64_add_unless(atomic64_t *v, long long a, long long u) > ... > return (int)a; > > which looks really horribly wrong, but the assembly implementation > actually returns 0/1 in %eax so it ends up being right - just > confusingly so. > > Also, to make things more confusing, the underscore version > (__atomic_add_unless()) actually returns the old value, not the truth > value of the comparison. > > So this area definitely is messy. The x86-64 versions actually look > fairly clean and return nice boolean values. We have a similar mess with bitops too. x86 is cleaned up to have bool returns but the generic implementation and a lot of other archs return the tested bit instead of 1/0. It'd be great to make all the boolean functions actually return bool. Thanks. -- tejun