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=-12.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 BACABC433E0 for ; Thu, 25 Feb 2021 14:58:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2C82A64EDC for ; Thu, 25 Feb 2021 14:58:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C82A64EDC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AA8018D0002; Thu, 25 Feb 2021 09:58:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A55418D0001; Thu, 25 Feb 2021 09:58:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 945598D0002; Thu, 25 Feb 2021 09:58:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0162.hostedemail.com [216.40.44.162]) by kanga.kvack.org (Postfix) with ESMTP id 79AF78D0001 for ; Thu, 25 Feb 2021 09:58:52 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 450CF18068C72 for ; Thu, 25 Feb 2021 14:58:52 +0000 (UTC) X-FDA: 77857097304.08.CE1AD90 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 7BC43132 for ; Thu, 25 Feb 2021 14:58:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614265130; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8bvA3joDxtGwPdmhV+qc0G7SWpdH/9IEUumaO+ZmZvA=; b=hSe01fAKcdrixqs27bS3YB8NzIckSa3KOkfH2Bqi4/GxsUhX1s1VMxWFjJTwaTsp41s/Ll 7eDHCez6BB+gCcBm/iohCjwP6ACpPYmGepOm0TBs+TL9cfQdyrrL4GDYmaK87qLCLaavTN 5w/O5T25jce9yPiRlbHxseGrtdQTrWI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-218-lb9ELSTvP6yQZUv6UXS15w-1; Thu, 25 Feb 2021 09:58:48 -0500 X-MC-Unique: lb9ELSTvP6yQZUv6UXS15w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9AE33107ACF3; Thu, 25 Feb 2021 14:58:46 +0000 (UTC) Received: from [10.36.114.58] (ovpn-114-58.ams2.redhat.com [10.36.114.58]) by smtp.corp.redhat.com (Postfix) with ESMTP id E14DE1346D; Thu, 25 Feb 2021 14:58:43 +0000 (UTC) Subject: Re: [PATCH] memblock: fix section mismatch warning To: Arnd Bergmann 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 References: <20210225133808.2188581-1-arnd@kernel.org> <60989b76-1ae6-6be3-0277-df9f0cc8dc3e@redhat.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <269fdc41-3ac8-8919-1330-d87b32689e89@redhat.com> Date: Thu, 25 Feb 2021 15:58:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Stat-Signature: n96gafc4h37xpag9fo4bim38414rfmb5 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7BC43132 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=63.128.21.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614265131-701700 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 25.02.21 15:06, 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: > > 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. It's not like if there are a lot of call sites: $ git grep memblock_bottom_up arch/x86/mm/init.c: if (memblock_bottom_up()) { include/linux/memblock.h:static inline bool memblock_bottom_up(void) mm/cma.c: if (!memblock_bottom_up() && memblock_end >= SZ_4G + size) { mm/memblock.c: if (memblock_bottom_up()) Similarly for memblock_set_bottom_up() within a kernel image. But it's not like this is performance-sensitive code :) Thanks! Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb