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 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 69D65C433DB for ; Thu, 25 Feb 2021 16:12:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C38DE64E7A for ; Thu, 25 Feb 2021 16:12:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C38DE64E7A 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 465BF6B0005; Thu, 25 Feb 2021 11:12:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 39FF06B0070; Thu, 25 Feb 2021 11:12:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 267AD6B0072; Thu, 25 Feb 2021 11:12:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0168.hostedemail.com [216.40.44.168]) by kanga.kvack.org (Postfix) with ESMTP id 0E8956B0005 for ; Thu, 25 Feb 2021 11:12:27 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id CF3EDC5CC for ; Thu, 25 Feb 2021 16:12:26 +0000 (UTC) X-FDA: 77857282692.04.2DDBDCA Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf29.hostedemail.com (Postfix) with ESMTP id 3E8A43506 for ; Thu, 25 Feb 2021 16:12:24 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 765D964F1E for ; Thu, 25 Feb 2021 16:12:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614269541; bh=6a6+Lo7ZD5NJqz85anc9huPjV9zOLA0n8oW58t+rASI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=g2xHbCzS7K5oeElbqa8lJS6EIMGvw7gud8LeoZQHkofQtzZ+D8Z1Jum+9vnKozsSA toCYrhfXzPgTSDHOyZrlSsghEPPBHw7rhyK3D1dDJF/+QDZU5lst6wACGfVhA6KZHb jqzt1zacWpAtgIhHGuyNlmB5zsW/kFYENUtJmWmdZWB414B9hh2v7MymyL2tVHvO+p zayc+RAvf/Aprfw008Xjaq/qXu2X5p5hEO/ycpFJUKK6yW4siACoRvbqAmggPhC+lx ZEsxZ0WKF9W67IOQas9q4TsXz+wxLEMKIhv5b3TFW1hkC40+uYnUlR75uepSIB6U5J iIqGJ2ObSTe9Q== Received: by mail-oi1-f180.google.com with SMTP id j1so6583077oiw.3 for ; Thu, 25 Feb 2021 08:12:21 -0800 (PST) X-Gm-Message-State: AOAM531fbTf6iuZMBHOeMyybwZWK7gQX3qhPVBpcYFIwevX4mLqALkL0 xrfSo6TDCitAaX8WxaCtQUglBalSt3vmOqhQV7c= X-Google-Smtp-Source: ABdhPJz7vXBtHKuL54uoi+53wDxQ9XweckJQCH12YtjWdIo7GdigmprZ5jbWbaHOYJLwr7bOjyu3pbe/mPEKbXXEDiE= X-Received: by 2002:aca:4a47:: with SMTP id x68mr2254102oia.67.1614269540490; Thu, 25 Feb 2021 08:12:20 -0800 (PST) MIME-Version: 1.0 References: <20210225133808.2188581-1-arnd@kernel.org> <60989b76-1ae6-6be3-0277-df9f0cc8dc3e@redhat.com> <20210225150757.GK1447004@kernel.org> In-Reply-To: <20210225150757.GK1447004@kernel.org> From: Arnd Bergmann Date: Thu, 25 Feb 2021 17:12:04 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] memblock: fix section mismatch warning To: Mike Rapoport 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 Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: nc4hwrims8jge9hrnnjai7mg98saxcuc X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3E8A43506 Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614269544-497299 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 4:08 PM Mike Rapoport wrote: > 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: > > > > > > (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 suppose the relocation names like "R_X86_64_32S" and the command line I used should could have told me the same ;-) > I wonder what happens with other memblock inline APIs, particularly with > alloc wrappers. Do they still get inlined? Trying the same configuration here, with all the allocation functions marked __init again, they all get inlined by clang, regardless of the '__init' and 'inline' and '__always_inline' tags. With gcc-7 and gcc-10 one instance of the plain 'memblock_alloc' does not get fully inlined if I revert the __always_inline back to plain inline: .type memblock_alloc.constprop.0, @function memblock_alloc.constprop.0: .LASANPC4090: pushq %rbp # # include/linux/memblock.h:407: static inline __init void *memblock_alloc(phys_addr_t size, phys_addr_t align) movq %rdi, %rbp # tmp84, size # include/linux/memblock.h:409: return memblock_alloc_try_nid(size, align, MEMBLOCK_LOW_LIMIT, call __sanitizer_cov_trace_pc # movq %rbp, %rdi # size, orl $-1, %r8d #, xorl %ecx, %ecx # xorl %edx, %edx # movl $4096, %esi #, # include/linux/memblock.h:411: } popq %rbp # # include/linux/memblock.h:409: return memblock_alloc_try_nid(size, align, MEMBLOCK_LOW_LIMIT, jmp memblock_alloc_try_nid # .size memblock_alloc.constprop.0, .-memblock_alloc.constprop.0 Apparently, this is an optimization for code size, as there are multiple callers in kernel/dma/swiotlb.c and it can move the call to __sanitizer_cov_trace_pc into a single place here. Arnd