Re: [PATCH v8 2/3] cxl/hdm: Allow zero sized HDM decoders

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] cxl_dpa_free() silently early-returns on zero-sized decoders, failing to release the DPA tracking resource and permanently locking port->hdm_end, breaking LIFO teardown.
--

--- Patch [2]: [PATCH v8 2/3] cxl/hdm: Allow zero sized HDM decoders ---
commit d92ffa9b7fbe4708b46c314f7b9ca98c30df149a
Author: Richard Cheng <[email protected]>

cxl/hdm: Allow zero sized HDM decoders

This commit updates the CXL core to allow committing an HDM decoder
with a size of 0, treating them as first-class decoders backed by a
kmalloc'd resource. It updates accounting and guards various paths
that an empty decoder cannot serve.

> diff --git a/drivers/cxl/core/hdm.c b/drivers/cxl/core/hdm.c
> index 0c80b76a5f9b4..3b3cfa0f25074 100644
> --- a/drivers/cxl/core/hdm.c
> +++ b/drivers/cxl/core/hdm.c

[ ... ]

> @@ -545,7 +572,7 @@ int cxl_dpa_free(struct cxl_endpoint_decoder *cxled)
>  	struct device *dev = &cxled->cxld.dev;
>  
>  	guard(rwsem_write)(&cxl_rwsem.dpa);
> -	if (!cxled->dpa_res)
> +	if (cxled_empty(cxled))
>  		return 0;

[Severity: High]
Does this early return leak the zero-sized DPA reservation and break the
LIFO teardown order?

When a zero-sized decoder is initialized, __cxl_dpa_reserve() allocates a
zero-sized resource and increments port->hdm_end.

If a user later attempts to free this DPA (for example, by writing 0 to the
dpa_size sysfs attribute), cxled_empty() will evaluate to true here because
the resource size is 0. This bypasses devm_cxl_dpa_release(), meaning the
kmalloc'd resource is never freed and port->hdm_end is never decremented.

Since port->hdm_end remains stuck on this decoder, does this permanently
block the freeing of any prior decoders on the same port due to the strict
LIFO teardown requirements?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2