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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26E09EB64DD for ; Thu, 13 Jul 2023 09:08:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BE578D0002; Thu, 13 Jul 2023 05:08:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66E088D0001; Thu, 13 Jul 2023 05:08:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50F0C8D0002; Thu, 13 Jul 2023 05:08:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3DAB08D0001 for ; Thu, 13 Jul 2023 05:08:31 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id EEE6F12017E for ; Thu, 13 Jul 2023 09:08:30 +0000 (UTC) X-FDA: 81006012780.12.7055009 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 953BCC0007 for ; Thu, 13 Jul 2023 09:08:28 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dGFM2TjC; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689239308; h=from:from:sender: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:dkim-signature; bh=Sxdu/stClx226UmcIVBi+jl7HR8O+7PiCl/kTpcKiVU=; b=OU1B/73C7cY1LekKbg7U43x4MRM9C98o/NPL83UP5K8NlrZc7T3dT3vCug+rZyjY7KDlTh p03ST1R+DYm7x2ZeP8Md6HGBSlNqn4zuj/yOwQs5vAE9aazKLsxUu5IZ90Qpri1USuypCX 46mmFbpNtJEZBaSipXUsfU8QH6L9enA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689239308; a=rsa-sha256; cv=none; b=g+lA6ro0lo/ukgNLXKpks1qX8kMziXM7wyLinkRL2EUF3vRrHuVgyX8deJpY0uJV0y4qpa 2hj35wJcztGoKBwdjt44aVVWJDcBriW/IVD621HlYMCSn8e63qLoGSmTHO0dIhBTEvKqPb KqtfiBJBDRvVbNclHfh482myNJHf74Q= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dGFM2TjC; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689239307; 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=Sxdu/stClx226UmcIVBi+jl7HR8O+7PiCl/kTpcKiVU=; b=dGFM2TjCTLyniBwFizY7LaK94g33KA3rFhJDcKub/eLnTt9JmV3gfDiLrN7J/fLfXTAvSE 4VaxFCYygVpBkQcJuLMCnVAjy1ogrZyS7ilSLO8x6aGsBop8CjsUSB5DLtaxWzrJjXq+e5 zI7T4alM8RHkE/qpOv+Di66WzhMfo/w= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-441-BUqGtrd1NQCP1KZF8J7vDw-1; Thu, 13 Jul 2023 05:08:26 -0400 X-MC-Unique: BUqGtrd1NQCP1KZF8J7vDw-1 Received: by mail-lj1-f199.google.com with SMTP id 38308e7fff4ca-2b70c46f121so4449511fa.1 for ; Thu, 13 Jul 2023 02:08:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689239305; x=1691831305; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Sxdu/stClx226UmcIVBi+jl7HR8O+7PiCl/kTpcKiVU=; b=N1C+Yic7MfQfaLZoP6CXnZyX1N5sn3yj3zZ7ZnFxymHJr/GVIrDhL2PNzTZi50srFz AtCllNSyXIoaDRu8U82QP/GWsNtxxsJK3PIGjJiMJif+OSaxNUrJ901/3ah/+XqR7boA oQVAJPsfU+3/eW7UG+vruNada6SX2EKbQUagVa+Pu0ozBp5z1drE7O+qrL9mYo1fXFuN QwhRb51JIHYVgDTKNLs5HcyMxaTR9iifGesXn5zomY7ilK38kjdWlabQFCQQoA6hUu0D qhk6YWTERviXWhi/DS+O+xjXhiuljx0+PSlI7ROkP+IFBYBmU1gogCiFDAH9h8iLxrVW y1EQ== X-Gm-Message-State: ABy/qLYWLhQ9Qo6YFVv8JTQna/NezwuxBy+pKuFbM5fSTU5wwkdhbnCB gcap+ZhF62dRhtur3aCg9D+GPc3iJfdwnvRfjbZH05yiE+K9uTLkgP5vrqeOVYlkggkDhe/Ymwc 2IIEnRCko/CM= X-Received: by 2002:a2e:9695:0:b0:2b7:1c0f:f20f with SMTP id q21-20020a2e9695000000b002b71c0ff20fmr790218lji.7.1689239304881; Thu, 13 Jul 2023 02:08:24 -0700 (PDT) X-Google-Smtp-Source: APBJJlFGMi1mJY7wH5j8EOil7zMuc3d0wZzihxSUm2Gw2/vrKM2KT50pGGqwUPyfOFSnHmKH1vwpbw== X-Received: by 2002:a2e:9695:0:b0:2b7:1c0f:f20f with SMTP id q21-20020a2e9695000000b002b71c0ff20fmr790195lji.7.1689239304346; Thu, 13 Jul 2023 02:08:24 -0700 (PDT) Received: from ?IPV6:2003:cb:c717:6100:2da7:427e:49a5:e07? (p200300cbc71761002da7427e49a50e07.dip0.t-ipconnect.de. [2003:cb:c717:6100:2da7:427e:49a5:e07]) by smtp.gmail.com with ESMTPSA id q13-20020a05600000cd00b00314367cf43asm7328487wrx.106.2023.07.13.02.08.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Jul 2023 02:08:23 -0700 (PDT) Message-ID: <5801c81e-cae4-2ba1-ec93-562fd8255423@redhat.com> Date: Thu, 13 Jul 2023 11:08:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 To: John Hubbard , Aneesh Kumar K V , linux-mm@kvack.org, akpm@linux-foundation.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, npiggin@gmail.com, christophe.leroy@csgroup.eu Cc: Oscar Salvador , Michal Hocko , Vishal Verma References: <20230711044834.72809-1-aneesh.kumar@linux.ibm.com> <20230711044834.72809-4-aneesh.kumar@linux.ibm.com> <6f6764f6-4b5a-dfa8-c409-ba4f2828891f@redhat.com> <176cee16-f926-ab3b-92fe-98bebf79d43d@linux.ibm.com> <641a4276-cfb9-bd1b-36a8-cb4bcae408f6@redhat.com> <89d500a4-b639-bf00-ea65-6f2690c74867@nvidia.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v3 3/7] mm/hotplug: Allow architecture to override memmap on memory support check In-Reply-To: <89d500a4-b639-bf00-ea65-6f2690c74867@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: m34eywgr58r6x7nqkwmk46g1tkc9nr4e X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 953BCC0007 X-Rspam-User: X-HE-Tag: 1689239308-976862 X-HE-Meta: U2FsdGVkX1/85Jdpc/FdXIkG9n86w5DkWfkbQ8sbPm0VvH8mvhQjbrgCsmkYST2buqHxLddPR+4OXuEgw3QN2IT153a4JO75HPZma8J6UvUpzxGVRGwOc0rBo1tD0ZBIvDFpE1yEwqIARBHtflvUXmLoEG0DDcuf61R/Iz8R+C8tuXIC7BE+1PjZRd4LaxEy5WSC3mi1t2ct500CXi3ylmWhu5mHLkmcgcSsFWtzp2M1PLnzDswo7dE2r+8zJtJM9n7t0FwJUZPHESArggkCa/Pku4TbaT2G9yrpje0UZmeoRVZZFjv3bHA/NGS+R4eAa8zrXkUx0T1fLTTnS1BGniUPkiEu4SIZdhRp0NtEfm1TDc7JOh08uEZ9G9hApq3ezSiORCxM8eJMf8CRHymDm+QsFJ2lycjCGns95BpERgW3szMdyEun64XyQ9ks0I/rxH0i7eKAbjm5ipvmRhX7KqOEz9SNXg93fjLkJYUR7vG0w3xM1X38s1oJW4DzTzBzphUpOER55F1MJovSLIz285UFycWkffEVOnhkFaOOIE/TktnPW/I8H4DpEEmR+o5JF4gv8thKuHbhKbbboqNuSYNQeR5ltkVzifTwRjnMwwzFRZZ5wVlLQriIf2T/WajYM02u7RQgk0wnyu7UETQmdiD6W0wmUSSyJx8mOb2scwoXhWU98700k3EETJV1DD4KAu7ToAqA89Eb0eUz/tDdEOnhvHcMShqJWrtvNDfCJZiN/fxZR/ix6+FLgsTIBlnu/Y5XSIizyqTtakByqO+PhZZtld/Y2ufm8ZqXtugBdV247xoaZncUbx42XYLfLEBdAw05JMuO1YJA9LtSDG9Ka/I8Tmn5oJG6kZ7LDByYCwgz2acTUmztCAbeqvDbrsgQOJhHeAWXrqDfvelfNIcZaiZ1ZDK4w71bsiwWM/JllbmkJOQ5vb1O44H4bD9OB2FWYBVa+LQ/kakL41CsxSC cNQZZqcU To4jvNEKD3Ie+x3F29AR9143lKdUbECgtUi8bTQLW3gt5XuiKICZhzPEblqw7RnBzACBCShYfQguZk+P/j/VdBXP7/R0oV8PBwteEKbb9S4weCgWdVcA8/E8MRGblqQ5rU4UV15WfHSUeY8/+d7xAu0CMkY/edoAa34g2NljVrVxUOY75HJigIkksW3LETTVXu2gTInk9REvPDrl8ElTFy0ZzIpJjGl4XuErBSXmp1rNpVwf2RpXJLyQKGLQFoEfa7LTfYEFrSIuaiN5Sje9IcvXWxYbK//9uM/xFfD0ieK8VZlOsbXyboVZv3AZaM4+vu3Z7q3YCTermMh5qdZqoTzSxzsgttx9L9+3NqJV1+D0XpJVlAvstH540fPRQ5u4dEoDCBgWYTdOslyjbzI9o4b4qDm2SMRj+ttzXFzVyv1Veaau7MxGCevf4KgnbrH3sNQIsXbXCwQfDfaZ3bNaEUrjUdZjw7Z3NIU+3eQS8vky9rUK1/OsYaaBh6yiQFhw7rh7v0PydqRtlfNjFSh+Zd/3MqhPuxpXBmrF4UuDQWZPaSCzj61Rcx48ahgtSPnT7WbAss8jPiblYziCYXb464H3PZuR/gYUguDrnSOg1Xr8MtR+fp+XGafSYb8azODtJFkGIRQROxj3zTpo= 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 12.07.23 22:07, John Hubbard wrote: > On 7/11/23 09:09, David Hildenbrand wrote: > ... >>>> Can we make that a __weak function instead? >>> >>> We can. It is confusing because we do have these two patterns within the kernel where we use >>> >>> #ifndef x >>> #endif >>> >>> vs >>> >>> __weak x >>> >>> What is the recommended way to override ? I have mostly been using #ifndef for most of the arch overrides till now. >>> >> >> I think when placing the implementation in a C file, it's __weak. But don't ask me :) >> >> We do this already for arch_get_mappable_range() in mm/memory_hotplug.c and IMHO it looks quite nice. >> > > It does look nice. I always forget which parts are supposed to be > __weak, so I went to check Documentation/ , and it was quite > entertaining. There are only two search hits: one trivial reference in > Documentation/conf.py, and the other in checkpatch.rst, which says: > > **WEAK_DECLARATION** > Using weak declarations like __attribute__((weak)) or __weak > can have unintended link defects. Avoid using them. > > ...which seems deeply out of touch with how arch layers work these days, > doesn't it? (This is not rhetorical; I'm asking in order to get an > opinion or two on the topic.) Did some digging: commit 65d9a9a60fd71be964effb2e94747a6acb6e7015 Author: Naveen N. Rao Date: Fri Jul 1 13:04:04 2022 +0530 kexec_file: drop weak attribute from functions As requested (http://lkml.kernel.org/r/87ee0q7b92.fsf@email.froward.int.ebiederm.org), this series converts weak functions in kexec to use the #ifdef approach. Quoting the 3e35142ef99fe ("kexec_file: drop weak attribute from arch_kexec_apply_relocations[_add]") changelog: : Since commit d1bcae833b32f1 ("ELF: Don't generate unused section symbols") : [1], binutils (v2.36+) started dropping section symbols that it thought : were unused. This isn't an issue in general, but with kexec_file.c, gcc : is placing kexec_arch_apply_relocations[_add] into a separate : .text.unlikely section and the section symbol ".text.unlikely" is being : dropped. Due to this, recordmcount is unable to find a non-weak symbol in : .text.unlikely to generate a relocation record against. This patch (of 2); Drop __weak attribute from functions in kexec_file.c: - arch_kexec_kernel_image_probe() - arch_kimage_file_post_load_cleanup() - arch_kexec_kernel_image_load() - arch_kexec_locate_mem_hole() - arch_kexec_kernel_verify_sig() arch_kexec_kernel_image_load() calls into kexec_image_load_default(), so drop the static attribute for the latter. arch_kexec_kernel_verify_sig() is not overridden by any architecture, so drop the __weak attribute. Link: https://lkml.kernel.org/r/cover.1656659357.git.naveen.n.rao@linux.vnet.ibm.com Link: https://lkml.kernel.org/r/2cd7ca1fe4d6bb6ca38e3283c717878388ed6788.1656659357.git.naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Naveen N. Rao Suggested-by: Eric Biederman Signed-off-by: Andrew Morton Signed-off-by: Mimi Zohar So, in general, it's use seems to be fine (unless some tool actually bails out). https://lore.kernel.org/all/87ee0q7b92.fsf@email.froward.int.ebiederm.org/T/#u Also mentions that__weak and non __weak variants ending up in the vmlinux. Did not check if that's actually (still) the case. -- Cheers, David / dhildenb