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 <[email protected]> > > 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 <[email protected]> > Fixes: 60e93dc097f7 ("device-dax: add dis-contiguous resource support") > Signed-off-by: Davidlohr Bueso <[email protected]> > --- > 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 > >
