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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 F3AE4C433DB for ; Thu, 25 Feb 2021 15:08:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6D20E64F0D for ; Thu, 25 Feb 2021 15:08:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D20E64F0D 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 B03E68D0001; Thu, 25 Feb 2021 10:08:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AB3386B0073; Thu, 25 Feb 2021 10:08:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A39E8D0001; Thu, 25 Feb 2021 10:08:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0047.hostedemail.com [216.40.44.47]) by kanga.kvack.org (Postfix) with ESMTP id 83C166B0070 for ; Thu, 25 Feb 2021 10:08:14 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 463CABA07 for ; Thu, 25 Feb 2021 15:08:14 +0000 (UTC) X-FDA: 77857120908.13.5984356 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf28.hostedemail.com (Postfix) with ESMTP id 4D9562000D8A for ; Thu, 25 Feb 2021 15:08:12 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id C375864F16; Thu, 25 Feb 2021 15:08:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614265686; bh=sw9r/XkgRGj1X8ebA7DvUakvpeKnwKaw37udTz7RsaA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R2TgcnKqy5z2UhA2TfIy6qWUNLv1CXh8IS1MDXvA5ZESNoobgE1QTRShds2RQefVI /0ePfP8oUbJF+1eVzWcEp4+AVJHWRwGjwRc3pDwVf66nyGNoRRQmJG8GB6xA456kNd LU9oQBICBqqaHlx8KowKPBsAdsG9yj9/s/TEvSSgYFvjTYo3nh53tr+kfjyz5aL0wv UvnfpHhQdK1dbWlL0K+ZS8vL7ku8OZSALoULiE8ZEKWPuUfZAr3lP0gTdVvWusx9wZ ZGlYyv47xZeeR53EcQ8gKDudkXOLXsphmSp38c4/h1LdYesxyIgZRLfMg/b0yZ0KbP +CTjlQXmBQgfA== Date: Thu, 25 Feb 2021 17:07:57 +0200 From: Mike Rapoport To: Arnd Bergmann Cc: David Hildenbrand , Nathan Chancellor , Nick Desaulniers , Faiyaz Mohammed , Arnd Bergmann , Andrew Morton , Baoquan He , Thomas Bogendoerfer , Aslan Bakirov , Linux-MM , "linux-kernel@vger.kernel.org" , clang-built-linux Subject: Re: [PATCH] memblock: fix section mismatch warning Message-ID: <20210225150757.GK1447004@kernel.org> References: <20210225133808.2188581-1-arnd@kernel.org> <60989b76-1ae6-6be3-0277-df9f0cc8dc3e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: nimu88gtq7npnzkx8ya83rbnrehy874f X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4D9562000D8A Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614265692-602508 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 03:06:27PM +0100, Arnd Bergmann wrote: > On Thu, Feb 25, 2021 at 2:47 PM David Hildenbrand wrote: > > > > On 25.02.21 14:38, 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. > > > > Did I understand correctly, that with this change it will not get > > inlined with any version of clang? Maybe __always_inline is more > > appropriate then. > > > > (I don't see why to not inline that function, but I am obviously not a > > compiler person :) ) > > Looking at the assembler output in the arm64 build that triggered the > warning, I see this code: "push %rbp" seems more x86 for me, but that's not really important :) I wonder what happens with other memblock inline APIs, particularly with alloc wrappers. Do they still get inlined? > 0000000000000a40 : > a40: 55 push %rbp > a41: 48 89 e5 mov %rsp,%rbp > a44: 41 56 push %r14 > a46: 53 push %rbx > a47: e8 00 00 00 00 call a4c > a48: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 > a4c: 48 c7 c7 00 00 00 00 mov $0x0,%rdi > a4f: R_X86_64_32S memblock > a53: e8 00 00 00 00 call a58 > a54: R_X86_64_PLT32 __asan_load1_noabort-0x4 > a58: 44 0f b6 35 00 00 00 movzbl 0x0(%rip),%r14d # a60 > > a5f: 00 > a5c: R_X86_64_PC32 memblock-0x4 > a60: bf 02 00 00 00 mov $0x2,%edi > a65: 44 89 f6 mov %r14d,%esi > a68: e8 00 00 00 00 call a6d > a69: R_X86_64_PLT32 > __sanitizer_cov_trace_const_cmp1-0x4 > a6d: 41 83 fe 01 cmp $0x1,%r14d > a71: 77 20 ja a93 > a73: e8 00 00 00 00 call a78 > a74: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 > a78: 44 89 f3 mov %r14d,%ebx > a7b: 80 e3 01 and $0x1,%bl > a7e: 41 83 e6 01 and $0x1,%r14d > a82: 31 ff xor %edi,%edi > a84: 44 89 f6 mov %r14d,%esi > a87: e8 00 00 00 00 call a8c > a88: R_X86_64_PLT32 > __sanitizer_cov_trace_const_cmp1-0x4 > a8c: 89 d8 mov %ebx,%eax > a8e: 5b pop %rbx > a8f: 41 5e pop %r14 > a91: 5d pop %rbp > a92: c3 ret > a93: e8 00 00 00 00 call a98 > a94: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4 > a98: 48 c7 c7 00 00 00 00 mov $0x0,%rdi > a9b: R_X86_64_32S .data+0x3c0 > a9f: 4c 89 f6 mov %r14,%rsi > aa2: e8 00 00 00 00 call aa7 > aa3: R_X86_64_PLT32 > __ubsan_handle_load_invalid_value-0x4 > aa7: eb cf jmp a78 > aa9: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) > ab0: 00 00 00 > ab3: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) > aba: 00 00 00 > abd: 0f 1f 00 nopl (%rax) > > This means that the sanitiers added a lot of extra checking around what > would have been a trivial global variable access otherwise. In this case, > not inlining would be a reasonable decision. > > Arnd -- Sincerely yours, Mike.