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 C661FE65D29 for ; Fri, 22 Nov 2024 07:52:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F8128D0008; Fri, 22 Nov 2024 02:52:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A7928D0007; Fri, 22 Nov 2024 02:52:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 249638D0008; Fri, 22 Nov 2024 02:52:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 052FD8D0007 for ; Fri, 22 Nov 2024 02:52:10 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 737E3AE377 for ; Fri, 22 Nov 2024 07:52:10 +0000 (UTC) X-FDA: 82812960048.01.3020096 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf26.hostedemail.com (Postfix) with ESMTP id E94B1140010 for ; Fri, 22 Nov 2024 07:51:27 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HQKHdLc9; spf=pass (imf26.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@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=1732261777; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=D9p/amWDuKtYCK1WkCl/Fua58/N/1s7xV60ca3EpfR4=; b=b5ClJhej2n07Osb5M+OuX4QZD2wHjZcF5tFku9XlMajckvk3gBMAvtjOM0VYBF47qlNibY hscTElHFQJ/htedtLeFhuow8LJjs21e8MdoKT1X+sWl7CB8GgDSbZw9inR06Yw5J9yeJXt ExnzSb7xl7NX7yF5wBYWZAyZwhtq84M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732261777; a=rsa-sha256; cv=none; b=SyPOw/V+NHnxEiwcYS5C/z05X8sZRTCwtN+NU0VOWGyVHGhhZctKphxgfKWuldJSMrdq09 LPfdbiL0RS6FkWDBdWPkL7hfM+zq668ekJvabcxq9eBbHwE37NwA3r3BaqoPZjMUXLT9lF 4SjozFzWQGsE8ilY2mxoBAKv0QiREBQ= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HQKHdLc9; spf=pass (imf26.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@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=1732261927; 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: in-reply-to:in-reply-to:references:references; bh=D9p/amWDuKtYCK1WkCl/Fua58/N/1s7xV60ca3EpfR4=; b=HQKHdLc9qfiUHGJ788J6z/Ah4ubZLo8OtXSE2l++YX2Zg8a8Z+LRX1BJQ0U8bLTRZ7ZJ00 c6l4Qhum+uZSSiO6NdQN15QBohCMw/XaE2OZBdS1J3/EKxF1ig47qZ4FNp+1AkxRzStUG4 YE/0dUTMYmvwdmnWlUZ6wvqeNtkRk20= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-100-HBEew0p3NECkehH9sfpIIQ-1; Fri, 22 Nov 2024 02:52:04 -0500 X-MC-Unique: HBEew0p3NECkehH9sfpIIQ-1 X-Mimecast-MFC-AGG-ID: HBEew0p3NECkehH9sfpIIQ Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 53B6E1955F3D; Fri, 22 Nov 2024 07:52:01 +0000 (UTC) Received: from localhost (unknown [10.72.113.10]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4B9441955F43; Fri, 22 Nov 2024 07:51:59 +0000 (UTC) Date: Fri, 22 Nov 2024 15:51:54 +0800 From: Baoquan He To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-fsdevel@vger.kernel.org, kexec@lists.infradead.org, Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , Vivek Goyal , Dave Young , Thomas Huth , Cornelia Huck , Janosch Frank , Claudio Imbrenda , Eric Farman , Andrew Morton Subject: Re: [PATCH v1 07/11] fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel Message-ID: References: <20241025151134.1275575-1-david@redhat.com> <20241025151134.1275575-8-david@redhat.com> <4b07a3eb-aad6-4436-9591-289c6504bb92@redhat.com> <3ed18ba1-e4b1-461e-a3a7-5de2df59ca60@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E94B1140010 X-Stat-Signature: xhz5dqc9p5tjk9pxgnhx1mfzwzs4tgdb X-HE-Tag: 1732261887-203698 X-HE-Meta: U2FsdGVkX1/MLPMgvOR/vxIOmYkZ+atvsJd/lAJGXMmup4rNbQGRtJ+k+jTkCoX4PQHo2AEUZfOXdGMwoTjL/9iSM1QP6AO0b0PDyvjamZ8U3J246S347bd718BYUV8Zlxnu6RWxrSjl+4tzRmYwYaTEL61+chKrKzi2pojwqme/zIj07EEXALgqKvfCmacLtuaPO9ps3/6hDEg4T0PmY4TcF5YDWH0N/9YJlm+SbacQ6i9UStcX27NHlidMMhwJl8Utk55bIy6b0vUKGoNIkPIVvc7UXmGKQNgzPajSXuOfeXqM6+4638QISCE05w0lvvR/QD6MIcTPTFUeAjWHU5+CVLA64HgCkl9RAnYj8W4KSJ5Xv1u7t3zvOSrX06kAhPLJk+aXxHhdiakBSLtMBr8tc49+gUqMVwNv6Koq+N5qhTNMGEVnY4/nrllJNyHqPqwnKyFusx3INuaafKDsrJDz4Oqgf4chK8E+B8QXK8a3REyCVMyUrNIe4HP5zYrRjRAn6xHV3o0nMrJ9rDApg6S0FDcFaVP6aC07ODthKg+dq8AyB7Q/7mm7hG3zBmSKZ8L+Q4jyF685CtAGq8HUtxSy2gDawLqlkgw93I9eBU+LEmqlyuOvx3Sze5c49enpUcdGt5uV07zmDq8LNcZ29LOpaT9eFeI2bVygnlPydqvZBONt/n96GsjDNlL58wl/eU8z7gL8On+307lW18tRD0A6+Q1errq1eM8rJgtoVnSXUwTCmbTSk662DDU/VXtxFKsC7puif6EwTCnh+3rxVvGzXhlaKTi7tiiwswZigfB3ami8sCF4USvQwtR63gevu4Lxwb50NDjwsqH3QM7JtbHqvwL3G96qUXS0dLfj1KfTDemlO+RTgUF2H74GZJUz60A4HVrp3ondYyNQIZdL05JG6jhhcAY+dwBkuKp3ib9stGk527VWxeWZhdEnIxEMs4b8MkH8L5/cg5E0JmB KMEAWded AdGw0emAr/vOAz2Vdf7gYtN6w6sNtXoaNNXRtr28Bwyl+fIzS/RvW9Yw26W+FQXjPY241CvjVKFOJtB5ap4S96Ctz9fB2eKuhjEgFavxjKj4BN49mMGobz1Ho8lienfP+pTPy1IGfOjGRbd5wQaZb/1jRON2D6SMLPyBL48j2M+J3LctNW4gYbpM7OGTuh3Y3BI5MoI9+38UQhFmSN97/s3A2og2NgE87iZlsMhhZ3xhxtIiWBP12phgyDUAHzR3deHcd4KU0OHA/lCS/kQcywidv5unf+ePXDeU8jNbckIAC4/lveUMop8DiUSc+jOGAG19gusM99B3wa0F/OJndupkNqSviOtFY13tbPGb9WUu9NKkgj4G1RtVaZe55rrJwuM7mVU6/GDYR/1yoZAgPsPamyA== 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: List-Subscribe: List-Unsubscribe: On 11/21/24 at 08:47pm, David Hildenbrand wrote: > > > > > > That would work, but I don't completely like it. > > > > > > (a) I want s390x to select NEED_PROC_VMCORE_DEVICE_RAM instead. Staring at a > > > bunch of similar cases (git grep "config NEED" | grep Kconfig, git grep > > > "config ARCH_WANTS" | grep Kconfig), "select" is the common way to do it. > > > > > > So unless there is a pretty good reason, I'll keep > > > NEED_PROC_VMCORE_DEVICE_RAM as is. > > > > That's easy to satify, see below: > > Yes, this is mostly what I have right now, except > > > > > ============simple version===== > > fs/proc/Kconfig: > > config NEED_PROC_VMCORE_DEVICE_RAM > > def n > > using "bool" here like other code. (I assume you meant "def_bool n", "bool" > seems to achieve the same thing) Yes, you are right. I didn't check it carefully. > > > ...... > > =================== > > fs/proc/Kconfig: > > config PROVIDE_PROC_VMCORE_DEVICE_RAM > > def_bool n > > > > config NEED_PROC_VMCORE_DEVICE_RAM > > def_bool n > > > > config PROC_VMCORE_DEVICE_RAM > > def_bool y > > depends on PROC_VMCORE > > depends on NEED_PROC_VMCORE_DEVICE_RAM > > depends on PROVIDE_PROC_VMCORE_DEVICE_RAM > > > > drivers/virtio/Kconfig: > > config VIRTIO_MEM > > select PROVIDE_PROC_VMCORE_DEVICE_RAM if PROC_VMCORE > > ~~~~~~~~~~~~~~ > > > > arch/s390/Kconfig: > > config S390 > > select NEED_PROC_VMCORE_DEVICE_RAM if PROC_VMCORE > > ~~~~~~~~~~~~~~ > > ======================== > > > > One last thing I haven't got well, If PROC_VMCORE_DEVICE_RAM has had > > dependency on PROC_VMCORE, can we take off the ' if PROC_VMCORE' when > > select PROVIDE_PROC_VMCORE_DEVICE_RAM and NEED_PROC_VMCORE_DEVICE_RAM? > > We could; it would mean that in a .config file you would end up with > "NEED_PROC_VMCORE_DEVICE_RAM=y" with "#PROC_VMCORE" and no notion of > "PROC_VMCORE_DEVICE_RAM". Fair enough. I didn't think of this. Then keeping it is obvisouly better. Thanks. > > I don't particularly like that -- needing something that apparently does not > exist. Not sure if there is a best practice here, staring at some examples I > don't seem to find a consistent rule. I can just drop it, not the end of the > world. > > > Did you get to look at the other code changes in this patch set? Your > feedback would be highly appreciated! Will try. While I may not have valuable input about virtio-mem code.