linux-kernel - Re: [PATCH v2 2/3] mm/memory_hotplug: split memmap_on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <abe41c22f72ad600541c6f2b199180b1cbcbb780.camel@intel.com>
Date:   Wed, 2 Aug 2023 06:08:20 +0000
From:   "Verma, Vishal L" <vishal.l.verma@...el.com>
To:     "Huang, Ying" <ying.huang@...el.com>
CC:     "david@...hat.com" <david@...hat.com>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "osalvador@...e.de" <osalvador@...e.de>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
        "nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>,
        "aneesh.kumar@...ux.ibm.com" <aneesh.kumar@...ux.ibm.com>,
        "jmoyer@...hat.com" <jmoyer@...hat.com>,
        "linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>
Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: split memmap_on_memory requests
 across memblocks

On Mon, 2023-07-24 at 13:54 +0800, Huang, Ying wrote:
> Vishal Verma <vishal.l.verma@...el.com> writes:
> 
> > 
> > @@ -2035,12 +2056,38 @@ void try_offline_node(int nid)
> >  }
> >  EXPORT_SYMBOL(try_offline_node);
> >  
> > -static int __ref try_remove_memory(u64 start, u64 size)
> > +static void __ref __try_remove_memory(int nid, u64 start, u64 size,
> > +                                    struct vmem_altmap *altmap)
> >  {
> > -       struct vmem_altmap mhp_altmap = {};
> > -       struct vmem_altmap *altmap = NULL;
> > -       unsigned long nr_vmemmap_pages;
> > -       int rc = 0, nid = NUMA_NO_NODE;
> > +       /* remove memmap entry */
> > +       firmware_map_remove(start, start + size, "System RAM");
> 
> If mhp_supports_memmap_on_memory(), we will call
> firmware_map_add_hotplug() for whole range.  But here we may call
> firmware_map_remove() for part of range.  Is it OK?
> 

Good point, this is a discrepancy in the add vs remove path. Can the
firmware memmap entries be moved up a bit in the add path, and is it
okay to create these for each memblock? Or should these be for the
whole range? I'm not familiar with the implications. (I've left it as
is for v3 for now, but depending on the direction I can update in a
future rev).