Received: by 2002:a17:90a:37e8:0:0:0:0 with SMTP id v95csp8818549pjb; Tue, 1 Oct 2019 04:42:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqxYNnFLKkb8pbBTItSLduNpGO4XAiUSeklCFG0R6b4pzLLTTsXcecFnCO3lnIztLbebueXL X-Received: by 2002:a50:a557:: with SMTP id z23mr24357447edb.99.1569930168792; Tue, 01 Oct 2019 04:42:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569930168; cv=none; d=google.com; s=arc-20160816; b=QWVBjDUInVYpoTEyfLbQVQa1zSrdTJWqoN+g6nbRIO1cC7qu6YEmu7mVzPZJhLcomg ibrbOj1R/jVOx2PPzrrDJbsEFwxrzltln7yHunxg1knFMyzn8XIBLBKZI8IoNvisYJHH 76OJR3XCFsw4DJOxxXB7YPl/M69Avjw1OBTGm04TAmr9YUYINJ6HlZW80//EgviOdAQ7 HxblQxm39KmYvJhOVIv7yLL1r0msiOh8yg0u1fbIBimsXwcullstLVGfS+Dpdg/1i4O0 fR6NuE+cZAqaNEmv6VRdGP8d9UPKhyqobg7RlyEvl/l4/ut2a50Kgvx9X1P86s5e81ab zgvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=+zixLV8WFbEs95/MoHSEqbJUlG44sjsHGTm5v1DLAdI=; b=jI2H24KgQOZLARk1EtbgHEaWekqPhOx4VpG0gRPJqsPE2L8orxvBx6wSUo42En2sRR T0k/PkJeLVAEqP3vpw8fme8S1IRfo7EWCY8USFm2bR9UxgkYmhOv7kcTvaQNIsbQq6qw DpAUrPab66ApkMZAUswS2uzJMqyDiPiczFyLN68eCu+5Lh/RnSpVVMK3SeMbyXPQaPxt GxvQ/UDL5Z2Vr+QuV9uaHLOaks7K7/7SxqQZ2GxtBW4eVQVULk4UZkwniNwseccBxBJZ sCrlt2xE6pSjxUd77R0ts+iK/Ih7RduzJsXDpDMCbtK78Q8/nqhHjHmxqfGqS/j9x+YO G9iA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ym1si5858415ejb.263.2019.10.01.04.42.24; Tue, 01 Oct 2019 04:42:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387738AbfJALli (ORCPT + 99 others); Tue, 1 Oct 2019 07:41:38 -0400 Received: from foss.arm.com ([217.140.110.172]:47532 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387715AbfJALld (ORCPT ); Tue, 1 Oct 2019 07:41:33 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5CAAC337; Tue, 1 Oct 2019 04:41:32 -0700 (PDT) Received: from localhost (unknown [10.37.6.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C85B53F706; Tue, 1 Oct 2019 04:41:31 -0700 (PDT) Date: Tue, 1 Oct 2019 12:41:30 +0100 From: Andrew Murray To: Will Deacon Cc: Masahiro Yamada , Arnd Bergmann , Catalin Marinas , Russell King , Linux Kernel Mailing List , linux-arm-kernel , Linus Torvalds , Nicolas Saenz Julienne Subject: Re: [PATCH] Partially revert "compiler: enable CONFIG_OPTIMIZE_INLINING forcibly" Message-ID: <20191001114129.GL42880@e119886-lin.cambridge.arm.com> References: <20190930114540.27498-1-will@kernel.org> <20191001104253.fci7s3sn5ov3h56d@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191001104253.fci7s3sn5ov3h56d@willie-the-truck> User-Agent: Mutt/1.10.1+81 (426a6c1) (2018-08-26) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 01, 2019 at 11:42:54AM +0100, Will Deacon wrote: > On Tue, Oct 01, 2019 at 06:40:26PM +0900, Masahiro Yamada wrote: > > On Mon, Sep 30, 2019 at 8:45 PM Will Deacon wrote: > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > > > index 93d97f9b0157..c37c72adaeff 100644 > > > --- a/lib/Kconfig.debug > > > +++ b/lib/Kconfig.debug > > > @@ -312,6 +312,7 @@ config HEADERS_CHECK > > > > > > config OPTIMIZE_INLINING > > > def_bool y > > > + depends on !(ARM || ARM64) # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91111 > > > > > > This is a too big hammer. > > It matches the previous default behaviour! > > > For ARM, it is not a compiler bug, so I am trying to fix the kernel code. > > > > For ARM64, even if it is a compiler bug, you can add __always_inline > > to the functions in question. > > (arch_atomic64_dec_if_positive in this case). > > > > You do not need to force __always_inline globally. > > So you'd prefer I do something like the diff below? I mean, it's a start, > but I do worry that we're hanging arch/arm/ out to dry. If I've understood one part of this issue correctly - and using the c2p_unsupported build failure as an example [1], there are instances in the kernel where it is assumed that the compiler will optimise out a call to an undefined function, and also assumed that the compiler will know at compile time that the function will never get called. It's common to satisfy this assumption when the calling function is inlined. But I suspect there may be other cases similar to c2p_unsupported which are still lurking. For example the following functions are called but non-existent, and thus may be an area worth investigating: __buggy_use_of_MTHCA_PUT, __put_dbe_unknown, __cmpxchg_wrong_size, __bad_percpu_size, __put_user_bad, __get_user_unknown, __bad_unaligned_access_size, __bad_xchg But more generally, as this is a common pattern - isn't there a benefit here for changing all of these to BUILD_BUG? (So they can be found easily). Or to avoid this class of issues, change them to BUG or unreachable - but lose the benefit of compile time detection? Thanks, Andrew Murray [1] https://lore.kernel.org/patchwork/patch/1122097/ > > Will > > --->8 > > diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h > index c6bd87d2915b..574808b9df4c 100644 > --- a/arch/arm64/include/asm/atomic_lse.h > +++ b/arch/arm64/include/asm/atomic_lse.h > @@ -321,7 +321,8 @@ static inline s64 __lse_atomic64_dec_if_positive(atomic64_t *v) > } > > #define __CMPXCHG_CASE(w, sfx, name, sz, mb, cl...) \ > -static inline u##sz __lse__cmpxchg_case_##name##sz(volatile void *ptr, \ > +static __always_inline u##sz \ > +__lse__cmpxchg_case_##name##sz(volatile void *ptr, \ > u##sz old, \ > u##sz new) \ > { \ > @@ -362,7 +363,8 @@ __CMPXCHG_CASE(x, , mb_, 64, al, "memory") > #undef __CMPXCHG_CASE > > #define __CMPXCHG_DBL(name, mb, cl...) \ > -static inline long __lse__cmpxchg_double##name(unsigned long old1, \ > +static __always_inline long \ > +__lse__cmpxchg_double##name(unsigned long old1, \ > unsigned long old2, \ > unsigned long new1, \ > unsigned long new2, \ > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel