From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D48C8C433E0 for ; Fri, 8 Jan 2021 18:52:44 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 92B4A23A5E for ; Fri, 8 Jan 2021 18:52:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 92B4A23A5E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=AoiLjcLU3HLr3eSc5aMnbNcAXXUQda7ASWLYi8tBXqo=; b=3Nlde0F4aGY6IFEZUVFhWglPm NEm0BhYZ1NRnBZNNESbenoIP87lCGCWBpGSgLQyQ+kWCyhEi7saym5a1JN8K+gAXGRe/rnGWKuEE/ C7oq7Xorvak+KrCzJic9LyHz4XteYADsoHWVmU+m4cox1qAiJNspA3RM3mlzEq7DALw8MxiTo7TXz yGLv6xH7DRuDrcub6VuytZG1OZi7sRbK9UGP1w6kPOLuUyPJIeiM+tcflUIiwcAB6mKg78EsrWHpw 10rSTNBEyTov1/xCt/NnBowANGFNGD2cNN4gp4+zQeBDUYCq/0+RR6dhu7fn7wNFdVJghE7jFrPHj msmXsIGlA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxwqf-0001FF-Kd; Fri, 08 Jan 2021 18:50:57 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxwqc-0001EP-N1 for linux-arm-kernel@lists.infradead.org; Fri, 08 Jan 2021 18:50:55 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 872D223A5E; Fri, 8 Jan 2021 18:50:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610131854; bh=RxHYjy0i/3NdfUEI25BhLzl08/4GhcgWadzUU0CMeNA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aLtx7xVuEhy5VwNBckoCFCYHgJEGr0YsT376UXgphaHoHpDEcLJ49HvJT4OlMCDy0 5JOfpSLXzElCCI/zqCZNrcIaU2IzZvyYwX7YIbb1lPv4Sil24Ks5kQfTyXDT9RaFyF di0aC72bVybHu3K01V4UwGLVydGpun96XCGnBmSG8KYmGjIIlfT6qTk1sdLWvW/gWz 6iCQt48/bYkVA25XhOYx/010O+1WzHDP0cQzgSNOydLgN6KYO9bNTRHpwr/4xHHRLa QzEOCwnE5QZIKAs/MsRx8TTe19BeTu2CWpAB686aM/A3qfpcL7CHo5JXelIUzX0trs W6iyE+8BCrT7g== Date: Fri, 8 Jan 2021 18:50:48 +0000 From: Will Deacon To: Arnd Bergmann Subject: Re: [PATCH] arm64: make atomic helpers __always_inline Message-ID: <20210108185047.GB5457@willie-the-truck> References: <20210108092024.4034860-1-arnd@kernel.org> <20210108093258.GB4031@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210108_135054_895021_FD082BBC X-CRM114-Status: GOOD ( 27.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , linux-arch , Herbert Xu , Arnd Bergmann , Peter Zijlstra , Catalin Marinas , Boqun Feng , Nick Desaulniers , "linux-kernel@vger.kernel.org" , clang-built-linux , Nathan Chancellor , Thomas Gleixner , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jan 08, 2021 at 11:26:53AM +0100, Arnd Bergmann wrote: > On Fri, Jan 8, 2021 at 10:33 AM Will Deacon wrote: > > On Fri, Jan 08, 2021 at 10:19:56AM +0100, Arnd Bergmann wrote: > > > From: Arnd Bergmann > > > > > > With UBSAN enabled and building with clang, there are occasionally > > > warnings like > > > > > > WARNING: modpost: vmlinux.o(.text+0xc533ec): Section mismatch in reference from the function arch_atomic64_or() to the variable .init.data:numa_nodes_parsed > > > The function arch_atomic64_or() references > > > the variable __initdata numa_nodes_parsed. > > > This is often because arch_atomic64_or lacks a __initdata > > > annotation or the annotation of numa_nodes_parsed is wrong. > > > > > > for functions that end up not being inlined as intended but operating > > > on __initdata variables. Mark these as __always_inline, along with > > > the corresponding asm-generic wrappers. > > > > Hmm, I don't fully grok this. Why does it matter if a non '__init' function > > is called with a pointer to some '__initdata'? Or is the reference coming > > from somewhere else? (where?). > > There are (at least) three ways for gcc to deal with a 'static inline' > function: > > a) fully inline it as the __always_inline attribute does > b) not inline it at all, treating it as a regular static function > c) create a specialized version with different calling conventions > > In this case, clang goes with option c when it notices that all > callers pass the same constant pointer. This means we have a > synthetic > > static noinline long arch_atomic64_or(long i) > { > return __lse_ll_sc_body(atomic64_fetch_or, i, &numa_nodes_parsed); > } > > which is a few bytes shorter than option b as it saves a load in the > caller. This function definition however violates the kernel's rules > for section references, as the synthetic version is not marked __init. Ah, I was hoping the compiler would've sorted that out, but then again, how would it know? But doesn't this mean that whenever we get one caller passing something like an __initdata pointer to a function, then that function needs to be __always_inline for everybody? It feels like a slippery slope considering the incentive to go back and replace it with 'inline' if the caller goes away is very small. Didn't we used to #define inline as __always_inline to avoid this situation? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel