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.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT 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 2391FC433E0 for ; Thu, 25 Feb 2021 13:38:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9466264F03 for ; Thu, 25 Feb 2021 13:38:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9466264F03 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 EAF186B006C; Thu, 25 Feb 2021 08:38:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E60DE8D0002; Thu, 25 Feb 2021 08:38:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D27338D0001; Thu, 25 Feb 2021 08:38:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0042.hostedemail.com [216.40.44.42]) by kanga.kvack.org (Postfix) with ESMTP id B84806B006C for ; Thu, 25 Feb 2021 08:38:17 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 813081801AB47 for ; Thu, 25 Feb 2021 13:38:17 +0000 (UTC) X-FDA: 77856894234.03.1204C4D Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf14.hostedemail.com (Postfix) with ESMTP id 7B81EC0007C2 for ; Thu, 25 Feb 2021 13:38:09 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 5C71264EFA; Thu, 25 Feb 2021 13:38:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614260295; bh=lr8SL9gD1RWyjVOW25vxn/w4nEZ3HcF0RQApW0bE4+0=; h=From:To:Cc:Subject:Date:From; b=fh37CZa/Bs2ZEjyMs1wmFwPp0jkA0MMlfdDvyK+PmqWcEN3BM6/zqBbvWcNxi6F37 bYZ+xK8yf0GkALDlHwbSnjlYgApDuc6US3VIXJxtoq8Yzea6M9SiJFZTnzK3qc45gZ liOhe4uX/RJfju5omkj5rKHECq9yjpSqZYbM0r55CEdn+6c7ESl05Yn/7opxRJpm9I u2gArH99Y47woV/TxubtTzXK639iQ66G/GJ8TEahg6EOE1CiBWibIZk22LDjrFJl8A bN06OcxTYEE90VA8pfBPD5BZU0veRnZvph+JG2+KZP85vQF+UcpH7BFy8nTuMeD61s 8d1/vnCpLmknw== From: Arnd Bergmann To: Mike Rapoport , Nathan Chancellor , Nick Desaulniers , Faiyaz Mohammed Cc: 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: [PATCH] memblock: fix section mismatch warning Date: Thu, 25 Feb 2021 14:38:00 +0100 Message-Id: <20210225133808.2188581-1-arnd@kernel.org> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 X-Stat-Signature: eu8xegbbooc16zmmdmgx3z8z6pha1chz X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7B81EC0007C2 Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614260289-853496 Content-Transfer-Encoding: quoted-printable 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: 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 referenc= e from the function memblock_bottom_up() to the variable .meminit.data:me= mblock 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 t= o make it inline") Reference: 2cfb3665e864 ("include/linux/memblock.h: add __init to membloc= k_set_bottom_up()") Signed-off-by: Arnd Bergmann --- 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 bas= e, 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 =3D 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; } --=20 2.29.2