linux-kernel - Re: [PATCH v8 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] [day] [month] [year] [list]

Message-ID: <eca45ac5fc08572038bb5d842de6bf7d6dc3821b.camel@intel.com>
Date:   Fri, 3 Nov 2023 19:09:03 +0000
From:   "Verma, Vishal L" <vishal.l.verma@...el.com>
To:     "nifan.cxl@...il.com" <nifan.cxl@...il.com>
CC:     "david@...hat.com" <david@...hat.com>,
        "Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.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>,
        "Huang, Ying" <ying.huang@...el.com>,
        "nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>,
        "aneesh.kumar@...ux.ibm.com" <aneesh.kumar@...ux.ibm.com>,
        "Hocko, Michal" <mhocko@...e.com>,
        "jmoyer@...hat.com" <jmoyer@...hat.com>,
        "linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>
Subject: Re: [PATCH v8 2/3] mm/memory_hotplug: split memmap_on_memory requests
 across memblocks

On Fri, 2023-11-03 at 09:43 -0700, fan wrote:
> On Wed, Nov 01, 2023 at 04:51:52PM -0600, Vishal Verma wrote:
> > 
[..]
> >  
> > +static void __ref remove_memory_blocks_and_altmaps(u64 start, u64 size)
> > +{
> > +       unsigned long memblock_size = memory_block_size_bytes();
> > +       u64 cur_start;
> > +
> > +       /*
> > +        * For memmap_on_memory, the altmaps were added on a per-memblock
> > +        * basis; we have to process each individual memory block.
> > +        */
> > +       for (cur_start = start; cur_start < start + size;
> > +            cur_start += memblock_size) {
> > +               struct vmem_altmap *altmap = NULL;
> > +               struct memory_block *mem;
> > +
> > +               mem = find_memory_block(pfn_to_section_nr(PFN_DOWN(cur_start)));
> > +               WARN_ON_ONCE(!mem);
> > +               if (!mem)
> > +                       continue;
> > +
> > +               altmap = mem->altmap;
> > +               mem->altmap = NULL;
> > +
> > +               remove_memory_block_devices(cur_start, memblock_size);
> 
> Is cur_start always aligned to memory_block_size_bytes? If not, the
> above function will return directly, is that a issue?
> 
Hi Fan,

Thanks for taking a look and the review (btw v9 is the latest revision
of these).

I think we're okay because the create side would've adding this memory
in the first place as it too does an alignment check for
memory_block_size_bytes.

Thanks
Vishal