From: sashiko-bot@kernel.org
To: "Gregory Price" <gourry@gourry.net>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH v4 7/9] dax/kmem: extract hotplug/hotremove helper functions
Date: Fri, 05 Jun 2026 21:36:01 +0000 [thread overview]
Message-ID: <20260605213602.10D1E1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260605211911.2160954-8-gourry@gourry.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dax_kmem_do_hotplug() unconditionally attempts to add memory for all ranges, missing a check for successfully reserved I/O resources, leading to unsafe hotplug and a permanent memory leak on removal.
--
commit 9aae29a4ee0b2d84bab7e3e062cb31c70f75bf67
Author: Gregory Price <gourry@gourry.net>
dax/kmem: extract hotplug/hotremove helper functions
Refactor kmem _probe() _remove() by extracting init, cleanup, hotplug,
and hot-remove logic into separate helper functions.
> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index 41ccb618a1464..5bf36ab73f867 100644
> --- a/drivers/dax/kmem.c
> +++ b/drivers/dax/kmem.c
[ ... ]
> @@ -63,14 +63,195 @@ static void kmem_put_memory_types(void)
> mt_put_memory_types(&kmem_memory_types);
> }
>
> +/**
> + * dax_kmem_do_hotplug - hotplug memory for dax kmem device
[ ... ]
> +static int dax_kmem_do_hotplug(struct dev_dax *dev_dax,
> + struct dax_kmem_data *data,
> + int online_type)
> +{
> + struct device *dev = &dev_dax->dev;
> + int i, rc, onlined = 0;
> + mhp_t mhp_flags;
> +
> + for (i = 0; i < dev_dax->nr_range; i++) {
> + struct range range;
> +
> + rc = dax_kmem_range(dev_dax, i, &range);
> + if (rc)
> + continue;
> +
> + mhp_flags = MHP_NID_IS_MGID;
> + if (dev_dax->memmap_on_memory)
> + mhp_flags |= MHP_MEMMAP_ON_MEMORY;
> +
> + /*
> + * Ensure that future kexec'd kernels will not treat
> + * this as RAM automatically.
> + */
> + rc = __add_memory_driver_managed(data->mgid, range.start,
> + range_len(&range), kmem_name, mhp_flags,
> + online_type);
[Severity: High]
Should this loop verify if the resource was actually reserved before
adding the memory?
In dax_kmem_init_resources(), if request_mem_region() fails for a range
but a previous range succeeded (mapped > 0), the failure is bypassed and
data->res[i] is left as NULL.
If we don't check for !data->res[i] here, does this unconditionally call
__add_memory_driver_managed() and hot-add memory for physical ranges that
failed reservation?
> +
> + if (rc) {
> + dev_warn(dev, "mapping%d: %#llx-%#llx memory add failed\n",
[ ... ]
> +static int dax_kmem_init_resources(struct dev_dax *dev_dax,
> + struct dax_kmem_data *data)
> +{
[ ... ]
> + /* Region is permanently reserved if hotremove fails. */
> + res = request_mem_region(range.start, range_len(&range),
> + data->res_name);
> + if (!res) {
> + dev_warn(dev, "mapping%d: %#llx-%#llx could not reserve region\n",
> + i, range.start, range.end);
> + /*
> + * Once some memory has been onlined we can't
> + * assume that it can be un-onlined safely.
> + */
> + if (mapped)
> + continue;
> + return -EBUSY;
> + }
> + data->res[i] = res;
[ ... ]
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +/**
> + * dax_kmem_do_hotremove - hot-remove memory for dax kmem device
[ ... ]
> +static int dax_kmem_do_hotremove(struct dev_dax *dev_dax,
> + struct dax_kmem_data *data)
> +{
> + struct device *dev = &dev_dax->dev;
> + int i, success = 0;
> +
> + for (i = 0; i < dev_dax->nr_range; i++) {
> + struct range range;
> + int rc;
> +
> + rc = dax_kmem_range(dev_dax, i, &range);
> + if (rc)
> + continue;
> +
> + /* range was never added during probe, count as removed */
> + if (!data->res[i]) {
> + success++;
> + continue;
> + }
[Severity: High]
If dax_kmem_do_hotplug() erroneously added memory for a range with a
NULL data->res[i], will this check cause us to skip remove_memory()
for that range?
Does this strand the memory block online permanently?
> +
> + rc = remove_memory(range.start, range_len(&range));
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260605211911.2160954-1-gourry@gourry.net?part=7
next prev parent reply other threads:[~2026-06-05 21:36 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 21:19 [PATCH v4 0/9] dax/kmem: atomic whole-device hotplug via sysfs Gregory Price
2026-06-05 21:19 ` [PATCH v4 1/9] mm/memory: add memory_block_aligned_range() helper Gregory Price
2026-06-09 9:50 ` David Hildenbrand (Arm)
2026-06-05 21:19 ` [PATCH v4 2/9] mm/memory_hotplug: pass online_type to online_memory_block() via arg Gregory Price
2026-06-05 21:19 ` [PATCH v4 3/9] mm/memory_hotplug: export mhp_get_default_online_type Gregory Price
2026-06-05 21:29 ` sashiko-bot
2026-06-05 21:43 ` Gregory Price
2026-06-09 9:52 ` David Hildenbrand (Arm)
2026-06-09 15:11 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 4/9] mm/memory_hotplug: add __add_memory_driver_managed() with online_type arg Gregory Price
2026-06-09 9:55 ` David Hildenbrand (Arm)
2026-06-09 15:12 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 5/9] mm/memory_hotplug: add multi-range hotunplug Gregory Price
2026-06-05 21:30 ` sashiko-bot
2026-06-09 10:06 ` David Hildenbrand (Arm)
2026-06-09 15:15 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 6/9] dax: plumb hotplug online_type through dax Gregory Price
2026-06-05 21:31 ` sashiko-bot
2026-06-05 21:54 ` Gregory Price
2026-06-09 10:21 ` David Hildenbrand (Arm)
2026-06-09 15:33 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 7/9] dax/kmem: extract hotplug/hotremove helper functions Gregory Price
2026-06-05 21:36 ` sashiko-bot [this message]
2026-06-05 22:03 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 8/9] dax/kmem: add sysfs interface for atomic hotplug Gregory Price
2026-06-05 21:37 ` sashiko-bot
2026-06-09 10:26 ` David Hildenbrand (Arm)
2026-06-09 15:35 ` Gregory Price
2026-06-09 18:11 ` David Hildenbrand (Arm)
2026-06-09 18:19 ` Gregory Price
2026-06-09 18:22 ` David Hildenbrand (Arm)
2026-06-09 18:33 ` Gregory Price
2026-06-05 21:19 ` [PATCH v4 9/9] selftests/dax: add dax/kmem hotplug sysfs regression test Gregory Price
2026-06-05 21:34 ` sashiko-bot
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=20260605213602.10D1E1F00893@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.