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 69663C433DB for ; Thu, 25 Feb 2021 14:06:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A6F8064F10 for ; Thu, 25 Feb 2021 14:06:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6F8064F10 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 DED5F8D0001; Thu, 25 Feb 2021 09:06:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D9DAE6B0070; Thu, 25 Feb 2021 09:06:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB3D68D0001; Thu, 25 Feb 2021 09:06:48 -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 B86416B006C for ; Thu, 25 Feb 2021 09:06:48 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8793DD200 for ; Thu, 25 Feb 2021 14:06:48 +0000 (UTC) X-FDA: 77856966096.11.7F384E7 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf06.hostedemail.com (Postfix) with ESMTP id 4E0E1C0007DF for ; Thu, 25 Feb 2021 14:06:47 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 29AC264F1D for ; Thu, 25 Feb 2021 14:06:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614262005; bh=0sjikrwzMaPzLwlQVzVdjhVuB/wHbvv4ywEq3KaB7ho=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=PGJl+jt4MdkT/HYamMwOlW0AgFSV/58Hy/+P56aC82O4Y/lFuvDXsUEG78hYDdpsf Xgk0mv4lUY42beMHV7b0LKndq3jjCfW1zYOv/tzMiXBoF2nTFkrs6EjnSnslPrUXIJ COEreQQ7fVTM/QBo0TBixDuRsXkR0UiIjbReWg5GZaXeSkO1Y3uoDgcIs0X8LNKn9R LDm4pO9AlPgbFH0tMqQpj7waotNJ/XnjAjjilaJO9c0swJ9hndY24tiu1Ww3pBxY/Q f+WvZ7zm4jfQfzTaIh1m6fdDh00TZJfeRF6DCRYrmQ/Biym3Ulghk593gavpkNGnvA v8mK88+CCFmQA== Received: by mail-ot1-f51.google.com with SMTP id c16so5786916otp.0 for ; Thu, 25 Feb 2021 06:06:45 -0800 (PST) X-Gm-Message-State: AOAM532Gf19EfdHQv+1LcQ7za0XGOKzeLXnHqfu123RaBj/JzoNK36JC X0d9Io93vuXrWDCc+24b6VjCca+c4ZKu1tuEgWo= X-Google-Smtp-Source: ABdhPJxdQP5lt28Fr/qiSQBFp+gFXT8m/2LNqM9368PhfyJKaPmxkcUSlzQTeNPJHxfcGaCOYRzzB7tfNTaI79PjjNU= X-Received: by 2002:a9d:6b8b:: with SMTP id b11mr2415875otq.210.1614262004172; Thu, 25 Feb 2021 06:06:44 -0800 (PST) MIME-Version: 1.0 References: <20210225133808.2188581-1-arnd@kernel.org> <60989b76-1ae6-6be3-0277-df9f0cc8dc3e@redhat.com> In-Reply-To: <60989b76-1ae6-6be3-0277-df9f0cc8dc3e@redhat.com> From: Arnd Bergmann Date: Thu, 25 Feb 2021 15:06:27 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] memblock: fix section mismatch warning To: David Hildenbrand Cc: Mike Rapoport , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 4E0E1C0007DF X-Stat-Signature: 5n8737yezr1foqq1sia71b149fp8i73t Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614262007-220162 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 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: 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