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.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 89A10C4724C for ; Thu, 30 Apr 2020 15:41:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6E5F12076D for ; Thu, 30 Apr 2020 15:41:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727886AbgD3Pl1 (ORCPT ); Thu, 30 Apr 2020 11:41:27 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:50172 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726745AbgD3Pl0 (ORCPT ); Thu, 30 Apr 2020 11:41:26 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUBJT-0008Qi-7v; Thu, 30 Apr 2020 09:41:23 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jUBJS-0002Fp-2k; Thu, 30 Apr 2020 09:41:22 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, virtio-dev@lists.oasis-open.org, virtualization@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org, linux-nvdimm@lists.01.org, linux-hyperv@vger.kernel.org, linux-s390@vger.kernel.org, xen-devel@lists.xenproject.org, Michal Hocko , Andrew Morton , "Michael S . Tsirkin" , Michal Hocko , Pankaj Gupta , Wei Yang , Baoquan He References: <20200430102908.10107-1-david@redhat.com> <20200430102908.10107-3-david@redhat.com> Date: Thu, 30 Apr 2020 10:38:04 -0500 In-Reply-To: <20200430102908.10107-3-david@redhat.com> (David Hildenbrand's message of "Thu, 30 Apr 2020 12:29:07 +0200") Message-ID: <87pnbp2dcz.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1jUBJS-0002Fp-2k;;;mid=<87pnbp2dcz.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18EJxut0ZMAzA6GiTlXjw55Di06eL/sNkE= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Hildenbrand writes: > Some devices/drivers that add memory via add_memory() and friends (e.g., > dax/kmem, but also virtio-mem in the future) don't want to create entries > in /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the firmware memmap as System > RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is > wrong: > "kexec needs the raw firmware-provided memory map to setup the > parameter segment of the kernel that should be booted with > kexec. Also, the raw memory map is useful for debugging. For > that reason, /sys/firmware/memmap is an interface that provides > the raw memory map to userspace." [1] > > We don't have to worry about firmware_map_remove() on the removal path. > If there is no entry, it will simply return with -EINVAL. > > [1] > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap You know what this justification is rubbish, and I have previously explained why it is rubbish. Nacked-by: "Eric W. Biederman" This needs to be based on weather the added memory is ultimately normal ram or is something special. At least when we are talking memory resources. Keeping it out of the firmware map that is fine. If the hotplugged memory is the result of plugging a stick of ram into the kernel and can and should used be like any other memory it should be treated like any normal memory. If the hotplugged memory is something special it should be treated as something special. Justifying behavior by documentation that does not consider memory hotplug is bad thinking. > Cc: Andrew Morton > Cc: Michal Hocko > Cc: Pankaj Gupta > Cc: Wei Yang > Cc: Baoquan He > Cc: Eric Biederman > Signed-off-by: David Hildenbrand > --- > include/linux/memory_hotplug.h | 8 ++++++++ > mm/memory_hotplug.c | 3 ++- > 2 files changed, 10 insertions(+), 1 deletion(-) > > diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h > index 0151fb935c09..4ca418a731eb 100644 > --- a/include/linux/memory_hotplug.h > +++ b/include/linux/memory_hotplug.h > @@ -68,6 +68,14 @@ struct mhp_params { > pgprot_t pgprot; > }; > > +/* Flags used for add_memory() and friends. */ > + > +/* > + * Don't create entries in /sys/firmware/memmap/. The memory is detected and > + * added via a device driver, not via the initial (firmware) memmap. > + */ > +#define MHP_NO_FIRMWARE_MEMMAP 1 > + > /* > * Zone resizing functions > * > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index c01be92693e3..e94ede9cad00 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resource *res, > BUG_ON(ret); > > /* create new memmap entry */ > - firmware_map_add_hotplug(start, start + size, "System RAM"); > + if (!(flags & MHP_NO_FIRMWARE_MEMMAP)) > + firmware_map_add_hotplug(start, start + size, "System RAM"); > > /* device_online() will take the lock when calling online_pages() */ > mem_hotplug_done();