[PATCH] dax/kmem: account for partial dis-contiguous resource upon removal

[PATCH] dax/kmem: account for partial dis-contiguous resource upon removal

[Davidlohr Bueso]

When dev_dax_kmem_probe() partially succeeds (at least one range
is mapped) but a subsequent range fails request_mem_region()
or add_memory_driver_managed(), the probe silently continues,
ultimately returning success.

However, dev_dax_kmem_remove() iterates care free on all ranges
where that remove_memory() returns 0 for "never added memory";
as walk_memory_blocks() will never see it in the memory_blocks
xarray. So ultimately passing a nil pointer to remove_resource(),
which can go boom.

Fix this by skipping these ranges altogether, with the consideration
that these are considered success, such that the cleanup is still
reached when all actually-added ranges are successfully removed.

Fixes: 60e93dc097f7 ("device-dax: add dis-contiguous resource support")
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
---
 drivers/dax/kmem.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index c036e4d0b610..edd62e68ffb7 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -227,6 +227,12 @@ static void dev_dax_kmem_remove(struct dev_dax *dev_dax)
 		if (rc)
 			continue;
 
+		/* range was never added during probe */
+		if (!data->res[i]) {
+			success++;
+			continue;
+		}
+
 		rc = remove_memory(range.start, range_len(&range));
 		if (rc == 0) {
 			remove_resource(data->res[i]);
-- 
2.39.5

Re: [PATCH] dax/kmem: account for partial dis-contiguous resource upon removal

[Cheatham, Benjamin]

On 2/10/2026 4:46 PM, Davidlohr Bueso wrote:
> When dev_dax_kmem_probe() partially succeeds (at least one range
> is mapped) but a subsequent range fails request_mem_region()
> or add_memory_driver_managed(), the probe silently continues,
> ultimately returning success.

I would mention the range resource gets NULL'ed out here. I think it would
make the below easier to follow.

> 
> However, dev_dax_kmem_remove() iterates care free on all ranges
> where that remove_memory() returns 0 for "never added memory";
> as walk_memory_blocks() will never see it in the memory_blocks
> xarray. So ultimately passing a nil pointer to remove_resource(),
> which can go boom.

Bit confusing imo. Maybe something like:

"dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if the
underlying resource exists. When remove_memory() is called later it returns 0 because
the memory was never added which causes dev_dax_kmem_remove() to incorrectly assume the
(nonexistent) resource can be removed and attempts cleanup on a NULL pointer.

As for the actual fix:
Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>

> 
> Fix this by skipping these ranges altogether, with the consideration
> that these are considered success, such that the cleanup is still
> reached when all actually-added ranges are successfully removed.
> 
> Fixes: 60e93dc097f7 ("device-dax: add dis-contiguous resource support")
> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
> ---
>  drivers/dax/kmem.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index c036e4d0b610..edd62e68ffb7 100644
> --- a/drivers/dax/kmem.c
> +++ b/drivers/dax/kmem.c
> @@ -227,6 +227,12 @@ static void dev_dax_kmem_remove(struct dev_dax *dev_dax)
>  		if (rc)
>  			continue;
>  
> +		/* range was never added during probe */
> +		if (!data->res[i]) {
> +			success++;
> +			continue;
> +		}
> +
>  		rc = remove_memory(range.start, range_len(&range));
>  		if (rc == 0) {
>  			remove_resource(data->res[i]);