drivers/dax/bus.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
The dax_region resource conflict in alloc_dax_region() indicates a
serious configuration problem — two subsystems (e.g. dax_hmem and
dax_cxl) are attempting to register overlapping address ranges. This is
not a transient or debug-level condition; it represents a genuine
resource conflict that an administrator needs to be aware of.
Switch from request_resource() + dev_dbg() to
request_resource_conflict() + dev_err() so that the conflict is visible
by default and the colliding resource is identified in the message.
Suggested-by: Dan Williams <dan.j.williams@intel.com>
Link: https://lore.kernel.org/linux-cxl/69c1a8d1c0fa9_7ee3100a1@dwillia2-mobl4.notmuch/
Signed-off-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
---
drivers/dax/bus.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
index 68437c05e21d..66413c6c2ba0 100644
--- a/drivers/dax/bus.c
+++ b/drivers/dax/bus.c
@@ -637,7 +637,7 @@ struct dax_region *alloc_dax_region(struct device *parent, int region_id,
unsigned long flags)
{
struct dax_region *dax_region;
- int rc;
+ struct resource *conflict;
/*
* The DAX core assumes that it can store its private data in
@@ -670,10 +670,11 @@ struct dax_region *alloc_dax_region(struct device *parent, int region_id,
.flags = IORESOURCE_MEM | flags,
};
- rc = request_resource(&dax_regions, &dax_region->res);
- if (rc) {
- dev_dbg(parent, "dax_region resource conflict for %pR\n",
- &dax_region->res);
+ conflict = request_resource_conflict(&dax_regions, &dax_region->res);
+ if (conflict) {
+ dev_err(parent,
+ "dax_region: can't claim %pR: address conflict with %s %pR\n",
+ &dax_region->res, conflict->name, conflict);
goto err_res;
}
--
2.47.3
On Tue, May 19, 2026, at 3:18 AM, Tomasz Wolski wrote:
> The dax_region resource conflict in alloc_dax_region() indicates a
> serious configuration problem — two subsystems (e.g. dax_hmem and
> dax_cxl) are attempting to register overlapping address ranges. This is
> not a transient or debug-level condition; it represents a genuine
> resource conflict that an administrator needs to be aware of.
>
> Switch from request_resource() + dev_dbg() to
> request_resource_conflict() + dev_err() so that the conflict is visible
> by default and the colliding resource is identified in the message.
>
> Suggested-by: Dan Williams <dan.j.williams@intel.com>
> Link:
> https://lore.kernel.org/linux-cxl/69c1a8d1c0fa9_7ee3100a1@dwillia2-mobl4.notmuch/
> Signed-off-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
> ---
> drivers/dax/bus.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 68437c05e21d..66413c6c2ba0 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -637,7 +637,7 @@ struct dax_region *alloc_dax_region(struct device
> *parent, int region_id,
> unsigned long flags)
> {
> struct dax_region *dax_region;
> - int rc;
> + struct resource *conflict;
>
> /*
> * The DAX core assumes that it can store its private data in
> @@ -670,10 +670,11 @@ struct dax_region *alloc_dax_region(struct device
> *parent, int region_id,
> .flags = IORESOURCE_MEM | flags,
> };
>
> - rc = request_resource(&dax_regions, &dax_region->res);
> - if (rc) {
> - dev_dbg(parent, "dax_region resource conflict for %pR\n",
> - &dax_region->res);
> + conflict = request_resource_conflict(&dax_regions, &dax_region->res);
Just report the request_resource() failure. This case does not warrant exporting request_resource _conflict(). Historically one driver can not mess with another driver's resource beyond conflict detection.
Hi Tomasz, kernel test robot noticed the following build errors: [auto build test ERROR on cxl/next] [also build test ERROR on linus/master v7.1-rc4 next-20260519] [cannot apply to cxl/pending] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Tomasz-Wolski/dax-bus-Upgrade-resource-conflict-message-to-dev_err-in-alloc_dax_region/20260519-182401 base: https://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl.git next patch link: https://lore.kernel.org/r/20260519101832.31988-1-tomasz.wolski%40fujitsu.com patch subject: [PATCH v2] dax/bus: Upgrade resource conflict message to dev_err() in alloc_dax_region() config: s390-randconfig-r072-20260520 (https://download.01.org/0day-ci/archive/20260520/202605200842.i0s39151-lkp@intel.com/config) compiler: s390-linux-gcc (GCC) 9.5.0 smatch: v0.5.0-9185-gbcc58b9c reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260520/202605200842.i0s39151-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202605200842.i0s39151-lkp@intel.com/ All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "request_resource_conflict" [drivers/dax/dax.ko] undefined! -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
On Wed, May 20, 2026 at 08:14:43AM +0800, kernel test robot wrote: > Hi Tomasz, > > kernel test robot noticed the following build errors: > > [auto build test ERROR on cxl/next] > [also build test ERROR on linus/master v7.1-rc4 next-20260519] > [cannot apply to cxl/pending] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: https://github.com/intel-lab-lkp/linux/commits/Tomasz-Wolski/dax-bus-Upgrade-resource-conflict-message-to-dev_err-in-alloc_dax_region/20260519-182401 > base: https://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl.git next > patch link: https://lore.kernel.org/r/20260519101832.31988-1-tomasz.wolski%40fujitsu.com > patch subject: [PATCH v2] dax/bus: Upgrade resource conflict message to dev_err() in alloc_dax_region() > config: s390-randconfig-r072-20260520 (https://download.01.org/0day-ci/archive/20260520/202605200842.i0s39151-lkp@intel.com/config) > compiler: s390-linux-gcc (GCC) 9.5.0 > smatch: v0.5.0-9185-gbcc58b9c > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260520/202605200842.i0s39151-lkp@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot <lkp@intel.com> > | Closes: https://lore.kernel.org/oe-kbuild-all/202605200842.i0s39151-lkp@intel.com/ > > All errors (new ones prefixed by >>, old ones prefixed by <<): > > >> ERROR: modpost: "request_resource_conflict" [drivers/dax/dax.ko] undefined! > Sorry Tomasz - I thought request_resource_conflict() looked sweet, but apparently it's only available to built-in kernel code and not to modules. I'd probably try a prep patch exporting it, based on looking at its kernel doc comment and neighbots in kernel/resource.c that are exported. -- Alison > -- > 0-DAY CI Kernel Test Service > https://github.com/intel/lkp-tests/wiki >
On Tue, 19 May 2026 12:18:32 +0200
Tomasz Wolski <tomasz.wolski@fujitsu.com> wrote:
> The dax_region resource conflict in alloc_dax_region() indicates a
> serious configuration problem — two subsystems (e.g. dax_hmem and
> dax_cxl) are attempting to register overlapping address ranges. This is
> not a transient or debug-level condition; it represents a genuine
> resource conflict that an administrator needs to be aware of.
>
> Switch from request_resource() + dev_dbg() to
> request_resource_conflict() + dev_err() so that the conflict is visible
> by default and the colliding resource is identified in the message.
>
> Suggested-by: Dan Williams <dan.j.williams@intel.com>
> Link: https://lore.kernel.org/linux-cxl/69c1a8d1c0fa9_7ee3100a1@dwillia2-mobl4.notmuch/
> Signed-off-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
Seems reasonable to me
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
> ---
> drivers/dax/bus.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 68437c05e21d..66413c6c2ba0 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -637,7 +637,7 @@ struct dax_region *alloc_dax_region(struct device *parent, int region_id,
> unsigned long flags)
> {
> struct dax_region *dax_region;
> - int rc;
> + struct resource *conflict;
>
> /*
> * The DAX core assumes that it can store its private data in
> @@ -670,10 +670,11 @@ struct dax_region *alloc_dax_region(struct device *parent, int region_id,
> .flags = IORESOURCE_MEM | flags,
> };
>
> - rc = request_resource(&dax_regions, &dax_region->res);
> - if (rc) {
> - dev_dbg(parent, "dax_region resource conflict for %pR\n",
> - &dax_region->res);
> + conflict = request_resource_conflict(&dax_regions, &dax_region->res);
> + if (conflict) {
> + dev_err(parent,
> + "dax_region: can't claim %pR: address conflict with %s %pR\n",
> + &dax_region->res, conflict->name, conflict);
> goto err_res;
> }
>
On Tue, May 19, 2026 at 12:31:12PM +0800, Jonathan Cameron wrote:
> On Tue, 19 May 2026 12:18:32 +0200
> Tomasz Wolski <tomasz.wolski@fujitsu.com> wrote:
>
> > The dax_region resource conflict in alloc_dax_region() indicates a
> > serious configuration problem — two subsystems (e.g. dax_hmem and
> > dax_cxl) are attempting to register overlapping address ranges. This is
> > not a transient or debug-level condition; it represents a genuine
> > resource conflict that an administrator needs to be aware of.
> >
> > Switch from request_resource() + dev_dbg() to
> > request_resource_conflict() + dev_err() so that the conflict is visible
> > by default and the colliding resource is identified in the message.
> >
> > Suggested-by: Dan Williams <dan.j.williams@intel.com>
> > Link: https://lore.kernel.org/linux-cxl/69c1a8d1c0fa9_7ee3100a1@dwillia2-mobl4.notmuch/
> > Signed-off-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
> Seems reasonable to me
> Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Reviewed-by: Richard Cheng <icheng@nvidia.com>
Best regards,
Richard Cheng.
> > ---
> > drivers/dax/bus.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> > index 68437c05e21d..66413c6c2ba0 100644
> > --- a/drivers/dax/bus.c
> > +++ b/drivers/dax/bus.c
> > @@ -637,7 +637,7 @@ struct dax_region *alloc_dax_region(struct device *parent, int region_id,
> > unsigned long flags)
> > {
> > struct dax_region *dax_region;
> > - int rc;
> > + struct resource *conflict;
> >
> > /*
> > * The DAX core assumes that it can store its private data in
> > @@ -670,10 +670,11 @@ struct dax_region *alloc_dax_region(struct device *parent, int region_id,
> > .flags = IORESOURCE_MEM | flags,
> > };
> >
> > - rc = request_resource(&dax_regions, &dax_region->res);
> > - if (rc) {
> > - dev_dbg(parent, "dax_region resource conflict for %pR\n",
> > - &dax_region->res);
> > + conflict = request_resource_conflict(&dax_regions, &dax_region->res);
> > + if (conflict) {
> > + dev_err(parent,
> > + "dax_region: can't claim %pR: address conflict with %s %pR\n",
> > + &dax_region->res, conflict->name, conflict);
> > goto err_res;
> > }
> >
>
© 2016 - 2026 Red Hat, Inc.