All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Gregory Price" <gourry@gourry.net>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH] mm/memory_hotplug: factor out node_is_memoryless()
Date: Wed, 02 Sep 2026 20:08:25 +0000	[thread overview]
Message-ID: <20260902200826.308571F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260902195507.88655-1-gourry@gourry.net>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Low] Unused function warnings when CONFIG_MEMORY_HOTREMOVE is disabled.

Pre-existing issues:
- [High] Data race on `node_spanned_pages` between ACPI CPU hot-remove and ZONE_DEVICE memory hotplug due to missing memory hotplug lock.
--

commit 239875f97a26527846083c3d6ab82ee6b800ce0a
Author: Gregory Price <gourry@gourry.net>

mm/memory_hotplug: factor out node_is_memoryless()

A memoryless node neither spans present pages (populated or ZONE_DEVICE)
nor has an offline-but-added memory block still linked to it in sysfs.

try_offline_node() presently open-codes this memoryless check.

Pull that into a node_is_memoryless() helper and pull the existing
check_no_memblock_for_node_cb() helper ahead of the add/online path
so it's clearer what is happening here.

> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 226ab9cb078ad..d0e94057682af 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1491,6 +1491,36 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,
>  	return ret;
>  }
>  
> +static int check_no_memblock_for_node_cb(struct memory_block *mem, void *arg)
> +{
> +	int nid = *(int *)arg;
> +
> +	/*
> +	 * If a memory block belongs to multiple nodes, the stored nid is not
> +	 * reliable. However, such blocks are always online (e.g., cannot get
> +	 * offlined) and, therefore, are still spanned by the node.
> +	 */
> +	return mem->nid == nid ? -EEXIST : 0;
> +}
> +
> +/* Caller must hold the memory hotplug lock for this check. */
> +static bool node_is_memoryless(int nid)
> +{
> +	/*
> +	 * A node still spanning pages (especially ZONE_DEVICE) is not
> +	 * memoryless.  A node spans memory after move_pfn_range_to_zone(),
> +	 * e.g. once a memory block has been onlined.
> +	 */
> +	if (node_spanned_pages(nid))

[Severity: High]
This is a pre-existing issue and was not introduced by this patch, but can
this lockless read of node_spanned_pages() race with ZONE_DEVICE memory
hotplug?

The comment explicitly requires the memory hotplug lock, but the ACPI CPU
hot-remove path in drivers/acpi/acpi_processor.c:acpi_processor_post_eject()
calls try_offline_node() while holding only device_hotplug_lock():

drivers/acpi/acpi_processor.c:acpi_processor_post_eject() {
    ...
    cpus_write_unlock();
    cpu_maps_update_done();

    try_offline_node(cpu_to_node(pr->id));
}

Since ZONE_DEVICE memory hotplug (via memremap_pages()) modifies
node_spanned_pages under mem_hotplug_lock() without holding
device_hotplug_lock(), could this race result in a NUMA node with active
ZONE_DEVICE memory being erroneously offlined and unregistered from sysfs?

> +		return false;
> +	/*
> +	 * Offline memory blocks may not be spanned by the node yet, but they
> +	 * link to it in sysfs and can be onlined later, so the node is not
> +	 * memoryless while any remain.
> +	 */
> +	return !for_each_memory_block(&nid, check_no_memblock_for_node_cb);
> +}

[Severity: Low]
Does moving check_no_memblock_for_node_cb() and node_is_memoryless() outside
of the #ifdef CONFIG_MEMORY_HOTREMOVE block cause -Wunused-function warnings
when CONFIG_MEMORY_HOTREMOVE is disabled?

Their only caller, try_offline_node(), is conditionally compiled inside that
block, so these helpers would be unused in builds without it.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902195507.88655-1-gourry@gourry.net?part=1

  reply	other threads:[~2026-09-02 20:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 19:55 [PATCH] mm/memory_hotplug: factor out node_is_memoryless() Gregory Price
2026-09-02 20:08 ` sashiko-bot [this message]
2026-09-03  0:52 ` Gregory Price
2026-09-07 15:28 ` David Hildenbrand (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260902200826.308571F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=gourry@gourry.net \
    --cc=linux-cxl@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.