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, but with the corresponding range
resource NULL'ed out.

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.

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

Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
Fixes: 60e93dc097f7 ("device-dax: add dis-contiguous resource support")
Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
---
Changes from v1: reword some of the changelog (Ben)

 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

ping? Unless any concerns, can this be picked up?

Thanks,
Davidlohr

On Mon, 23 Feb 2026, 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, but with the corresponding range
>resource NULL'ed out.
>
>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.
>
>Fix this by skipping these ranges altogether, noting that these
>cases are considered success, such that the cleanup is still
>reached when all actually-added ranges are successfully removed.
>
>Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
>Fixes: 60e93dc097f7 ("device-dax: add dis-contiguous resource support")
>Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
>---
>Changes from v1: reword some of the changelog (Ben)
>
> 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
>

On Mon, Feb 23, 2026 at 12:15:16PM -0800, 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, but with the corresponding range
> resource NULL'ed out.
> 
> 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.

Do you have a failure signature w Call Trace to paste here?
If not, maybe just insert the expected signature for grepping:
"BUG: unable to handle kernel NULL pointer dereference"

Reviewed-by: Alison Schofield <alison.schofield@intel.com>

> 
> Fix this by skipping these ranges altogether, noting that these
> cases are considered success, such that the cleanup is still
> reached when all actually-added ranges are successfully removed.
> 
> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
> Fixes: 60e93dc097f7 ("device-dax: add dis-contiguous resource support")
> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
> ---
> Changes from v1: reword some of the changelog (Ben)
> 
>  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
> 
>

On Wed, 25 Feb 2026, Alison Schofield wrote:

>Do you have a failure signature w Call Trace to paste here?

No, I have no splat, this was found while getting more acquianted
with dax code while looking at dcd topics.

>If not, maybe just insert the expected signature for grepping:
>"BUG: unable to handle kernel NULL pointer dereference"

I don't think this doesn't really adds much to the changelog. Not
worth a v2.

Thanks,
Davidlohr

On Wed, 25 Feb 2026 21:01:08 -0800
Alison Schofield <alison.schofield@intel.com> wrote:

> On Mon, Feb 23, 2026 at 12:15:16PM -0800, 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, but with the corresponding range
> > resource NULL'ed out.
> > 
> > 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.  
> 
> Do you have a failure signature w Call Trace to paste here?
> If not, maybe just insert the expected signature for grepping:
> "BUG: unable to handle kernel NULL pointer dereference"
> 
> Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>