| 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
| ||
|
Date: Fri, 6 Oct 2023 14:52:14 +0200
From: David Hildenbrand <david@...hat.com>
To: Vishal Verma <vishal.l.verma@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Oscar Salvador <osalvador@...e.de>,
Dan Williams <dan.j.williams@...el.com>,
Dave Jiang <dave.jiang@...el.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
nvdimm@...ts.linux.dev, linux-cxl@...r.kernel.org,
Huang Ying <ying.huang@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
Michal Hocko <mhocko@...e.com>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Jeff Moyer <jmoyer@...hat.com>
Subject: Re: [PATCH v5 1/2] mm/memory_hotplug: split memmap_on_memory requests
across memblocks
On 05.10.23 20:31, Vishal Verma wrote:
> The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to
> 'memblock_size' chunks of memory being added. Adding a larger span of
> memory precludes memmap_on_memory semantics.
>
> For users of hotplug such as kmem, large amounts of memory might get
> added from the CXL subsystem. In some cases, this amount may exceed the
> available 'main memory' to store the memmap for the memory being added.
> In this case, it is useful to have a way to place the memmap on the
> memory being added, even if it means splitting the addition into
> memblock-sized chunks.
>
> Change add_memory_resource() to loop over memblock-sized chunks of
> memory if caller requested memmap_on_memory, and if other conditions for
> it are met. Teach try_remove_memory() to also expect that a memory
> range being removed might have been split up into memblock sized chunks,
> and to loop through those as needed.
>
Maybe add that this implies that we're not making use of PUD mappings in
the direct map yet, and link to the proposal on how we could optimize
that eventually in the future.
[...]
>
> -static int __ref try_remove_memory(u64 start, u64 size)
> +static void __ref remove_memory_block_and_altmap(int nid, u64 start, u64 size)
You shouldn't need the nid, right?
> {
> + int rc = 0;
> struct memory_block *mem;
> - int rc = 0, nid = NUMA_NO_NODE;
> struct vmem_altmap *altmap = NULL;
>
> + rc = walk_memory_blocks(start, size, &mem, test_has_altmap_cb);
> + if (rc) {
> + altmap = mem->altmap;
> + /*
> + * Mark altmap NULL so that we can add a debug
> + * check on memblock free.
> + */
> + mem->altmap = NULL;
> + }
> +
> + /*
> + * Memory block device removal under the device_hotplug_lock is
> + * a barrier against racing online attempts.
> + */
> + remove_memory_block_devices(start, size);
We're now calling that under the memory hotplug lock. I assume this is
fine, but I remember some ugly lockdep details ...should be alright I guess.
> +
> + arch_remove_memory(start, size, altmap);
> +
> + /* Verify that all vmemmap pages have actually been freed. */
> + if (altmap) {
> + WARN(altmap->alloc, "Altmap not fully unmapped");
> + kfree(altmap);
> + }
> +}
> +
> +static int __ref try_remove_memory(u64 start, u64 size)
> +{
> + int rc, nid = NUMA_NO_NODE;
> +
> BUG_ON(check_hotplug_memory_range(start, size));
>
> /*
> @@ -2167,47 +2221,28 @@ static int __ref try_remove_memory(u64 start, u64 size)
> if (rc)
> return rc;
>
> + mem_hotplug_begin();
> +
> /*
> - * We only support removing memory added with MHP_MEMMAP_ON_MEMORY in
> - * the same granularity it was added - a single memory block.
> + * For memmap_on_memory, the altmaps could have been added on
> + * a per-memblock basis. Loop through the entire range if so,
> + * and remove each memblock and its altmap.
> */
> if (mhp_memmap_on_memory()) {
> - rc = walk_memory_blocks(start, size, &mem, test_has_altmap_cb);
> - if (rc) {
> - if (size != memory_block_size_bytes()) {
> - pr_warn("Refuse to remove %#llx - %#llx,"
> - "wrong granularity\n",
> - start, start + size);
> - return -EINVAL;
> - }
> - altmap = mem->altmap;
> - /*
> - * Mark altmap NULL so that we can add a debug
> - * check on memblock free.
> - */
> - mem->altmap = NULL;
> - }
> + unsigned long memblock_size = memory_block_size_bytes();
> + u64 cur_start;
> +
> + for (cur_start = start; cur_start < start + size;
> + cur_start += memblock_size)
> + remove_memory_block_and_altmap(nid, cur_start,
> + memblock_size);
> + } else {
> + remove_memory_block_and_altmap(nid, start, size);
Better call remove_memory_block_devices() and arch_remove_memory(start,
size, altmap) here explicitly instead of using
remove_memory_block_and_altmap() that really can only handle a single
memory block with any inputs.
> }
>
> /* remove memmap entry */
> firmware_map_remove(start, start + size, "System RAM");
Can we continue doing that in the old order? (IOW before taking the lock?).
>
> - /*
> - * Memory block device removal under the device_hotplug_lock is
> - * a barrier against racing online attempts.
> - */
> - remove_memory_block_devices(start, size);
> -
> - mem_hotplug_begin();
> -
> - arch_remove_memory(start, size, altmap);
> -
> - /* Verify that all vmemmap pages have actually been freed. */
> - if (altmap) {
> - WARN(altmap->alloc, "Altmap not fully unmapped");
> - kfree(altmap);
> - }
> -
> if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) {
> memblock_phys_free(start, size);
> memblock_remove(start, size);
> @@ -2219,6 +2254,7 @@ static int __ref try_remove_memory(u64 start, u64 size)
> try_offline_node(nid);
>
> mem_hotplug_done();
> +
Unrelated change.
> return 0;
> }
>
>
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists