Re: [PATCH v2 05/15] cxl: fix use of resource_contains

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Fri, 16 Aug 2024 15:37:14 +0100
Alejandro Lucero Palau <alucerop@amd.com> wrote:

> On 8/4/24 18:25, Jonathan Cameron wrote:
> > On Mon, 15 Jul 2024 18:28:25 +0100
> > <alejandro.lucero-palau@amd.com> wrote:
> >  
> >> From: Alejandro Lucero <alucerop@amd.com>
> >>
> >> For a resource defined with size zero, resource contains will also
> >> return true.
> >>
> >> Add resource size check before using it.
> >>
> >> Signed-off-by: Alejandro Lucero <alucerop@amd.com>  
> > If this can happen in existing type 3 case the fixes tag
> > and send it separately from this series.  
> 
> 
> I have been looking at this possibility and although not with 100% 
> certainty, I would say it is not for Type3.
> 
> "Type3 regions" are (usually) created from user space, and:
> 
> 1) if it is RAM, dax code is invoked for creating the region
> 
> 2) if it is pmem, pmem region creation code is invoked.
> 
> None of these possibilities use the affected code in this patch.
> 
> There exist two options where that code could be used by Type3, which 
> are confusing:
> 
> 1) regions created during device initialization, but for that the 
> decoder needs to be committed and it is not expected for Type3 without 
> user space intervention.

More than possible a bios already set them up.

> 
> 2) when emulating an hdm decoder, what I think it is not possible for 
> Type3 since it is mandatory.

HDM Decoders are not mandatory for older devices and not mandatory for
bios to have used them.  Papering over that gap is what the emulation code
is there for.

> 
> 
> Finally we have code when sysfs dpa_size file is written, which I'm not 
> familiar with.

That's an early part of the userspace bringing up the memory if it
wasn't set up by bios or from pmem lsa data.

Not sure any that helps though ;)

Jonathan

> 
> 
> 
> > If there is no path due to some external code, then
> > drop the word fix from the title and call it
> >
> > cxl: harden resource_contains checks to handle zero size resources  
> 
> 
> After the explanation above, I will do as you say.
> 
> Thanks!
> 
> 
> > Avoids it getting backported into stable / distros picking it
> > up if there isn't a real issue before this series.
> >
> > Thanks,
> >
> > Jonathan
> >  
> >> ---
> >>   drivers/cxl/core/hdm.c | 7 +++++--
> >>   1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/cxl/core/hdm.c b/drivers/cxl/core/hdm.c
> >> index 3df10517a327..4af9225d4b59 100644
> >> --- a/drivers/cxl/core/hdm.c
> >> +++ b/drivers/cxl/core/hdm.c
> >> @@ -327,10 +327,13 @@ static int __cxl_dpa_reserve(struct cxl_endpoint_decoder *cxled,
> >>   	cxled->dpa_res = res;
> >>   	cxled->skip = skipped;
> >>   
> >> -	if (resource_contains(&cxlds->pmem_res, res))
> >> +	if ((resource_size(&cxlds->pmem_res)) && (resource_contains(&cxlds->pmem_res, res))) {
> >> +		printk("%s: resource_contains CXL_DECODER_PMEM\n", __func__);
> >>   		cxled->mode = CXL_DECODER_PMEM;
> >> -	else if (resource_contains(&cxlds->ram_res, res))
> >> +	} else if ((resource_size(&cxlds->ram_res)) && (resource_contains(&cxlds->ram_res, res))) {
> >> +		printk("%s: resource_contains CXL_DECODER_RAM\n", __func__);
> >>   		cxled->mode = CXL_DECODER_RAM;
> >> +	}
> >>   	else {
> >>   		dev_warn(dev, "decoder%d.%d: %pr mixed mode not supported\n",
> >>   			 port->id, cxled->cxld.id, cxled->dpa_res);