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=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 B8774C433E6 for ; Thu, 25 Feb 2021 20:59:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3003C64E4D for ; Thu, 25 Feb 2021 20:59:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3003C64E4D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A9B9E6B0005; Thu, 25 Feb 2021 15:59:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A4A8E6B0006; Thu, 25 Feb 2021 15:59:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 961026B006C; Thu, 25 Feb 2021 15:59:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0064.hostedemail.com [216.40.44.64]) by kanga.kvack.org (Postfix) with ESMTP id 809996B0005 for ; Thu, 25 Feb 2021 15:59:19 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 405CC8248068 for ; Thu, 25 Feb 2021 20:59:19 +0000 (UTC) X-FDA: 77858005638.22.57C0AA5 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf22.hostedemail.com (Postfix) with ESMTP id 391F3C0007D3 for ; Thu, 25 Feb 2021 20:59:15 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 3712D64DA3; Thu, 25 Feb 2021 20:59:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614286757; bh=eV1kJaWfevV6RouK8LRLTU3ZuWjF9BEgVywj5uj8o6Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SGtJ0wvdv7iWICnifbRB9ajKhBV1vF/UjYU9qAnPikX4mRlJw3Kipi7kFBjUOTsz5 22dHxT8QzrP/KE7GmhTzY1gobQr/51iaTYjazU6/9mDt4zBvsMUaQ0OZtu7ROQQsCy XKLdR1uRqIW48YGCOv+ohHnHNdvgYIkS8/SCuTNgRolnhbJaamXHXJkGlFyKmxQ4W3 kqaRYIFV+XTMVQElQPc63YRc8TVVRUcRq7qfIj3rtLX+u/X/QQzmx9GohC/L+e12oT PqcZxjlcHx8rYMRnkHkgX2ydCqeOgkkvXNu+DTTBPOwvdS406ljHSvUxAxXpe04viZ 3QI6GUp43wZYw== Date: Thu, 25 Feb 2021 22:59:08 +0200 From: Mike Rapoport To: Arnd Bergmann Cc: Nathan Chancellor , Nick Desaulniers , Faiyaz Mohammed , Arnd Bergmann , Andrew Morton , Baoquan He , Thomas Bogendoerfer , David Hildenbrand , Aslan Bakirov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Re: [PATCH] memblock: fix section mismatch warning Message-ID: <20210225205908.GM1447004@kernel.org> References: <20210225133808.2188581-1-arnd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210225133808.2188581-1-arnd@kernel.org> X-Stat-Signature: ae6b17yeoz6nxxsagmezn3sxbuywe4ra X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 391F3C0007D3 Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf22; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614286755-703425 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 25, 2021 at 02:38:00PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > The inlining logic in clang-13 is rewritten to often not inline > some functions that were inlined by all earlier compilers. > > In case of the memblock interfaces, this exposed a harmless bug > of a missing __init annotation: > > WARNING: modpost: vmlinux.o(.text+0x507c0a): Section mismatch in reference from the function memblock_bottom_up() to the variable .meminit.data:memblock > The function memblock_bottom_up() references > the variable __meminitdata memblock. > This is often because memblock_bottom_up lacks a __meminitdata > annotation or the annotation of memblock is wrong. > > Interestingly, these annotations were present originally, but got removed > with the explanation that the __init annotation prevents the function > from getting inlined. I checked this again and found that while this > is the case with clang, gcc (version 7 through 10, did not test others) > does inline the functions regardless. > > As the previous change was apparently intended to help the clang > builds, reverting it to help the newer clang versions seems appropriate > as well. gcc builds don't seem to care either way. > > Fixes: 5bdba520c1b3 ("mm: memblock: drop __init from memblock functions to make it inline") > Reference: 2cfb3665e864 ("include/linux/memblock.h: add __init to memblock_set_bottom_up()") > Signed-off-by: Arnd Bergmann I thought it'll go via memblock tree but since Andrew has already took it Reviewed-by: Mike Rapoport > --- > include/linux/memblock.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h > index c88bc24e31aa..d13e3cd938b4 100644 > --- a/include/linux/memblock.h > +++ b/include/linux/memblock.h > @@ -460,7 +460,7 @@ static inline void memblock_free_late(phys_addr_t base, phys_addr_t size) > /* > * Set the allocation direction to bottom-up or top-down. > */ > -static inline void memblock_set_bottom_up(bool enable) > +static inline __init void memblock_set_bottom_up(bool enable) > { > memblock.bottom_up = enable; > } > @@ -470,7 +470,7 @@ static inline void memblock_set_bottom_up(bool enable) > * if this is true, that said, memblock will allocate memory > * in bottom-up direction. > */ > -static inline bool memblock_bottom_up(void) > +static inline __init bool memblock_bottom_up(void) > { > return memblock.bottom_up; > } > -- > 2.29.2 > -- Sincerely yours, Mike.