netdev - Re: [PATCH v17 02/22] sfc: add cxl support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250630170713.00001f72@huawei.com>
Date: Mon, 30 Jun 2025 17:07:13 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Alejandro Lucero Palau <alucerop@....com>
CC: <alejandro.lucero-palau@....com>, <linux-cxl@...r.kernel.org>,
	<netdev@...r.kernel.org>, <dan.j.williams@...el.com>, <edward.cree@....com>,
	<davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<edumazet@...gle.com>, <dave.jiang@...el.com>, "Edward Cree"
	<ecree.xilinx@...il.com>, Alison Schofield <alison.schofield@...el.com>
Subject: Re: [PATCH v17 02/22] sfc: add cxl support

On Mon, 30 Jun 2025 15:55:39 +0100
Alejandro Lucero Palau <alucerop@....com> wrote:

> On 6/30/25 15:52, Alejandro Lucero Palau wrote:
> >
> > On 6/25/25 17:37, Jonathan Cameron wrote:  
> >> On Tue, 24 Jun 2025 15:13:35 +0100
> >> <alejandro.lucero-palau@....com> wrote:
> >>  
> >>> From: Alejandro Lucero <alucerop@....com>
> >>>
> >>> Add CXL initialization based on new CXL API for accel drivers and make
> >>> it dependent on kernel CXL configuration.
> >>>
> >>> Signed-off-by: Alejandro Lucero <alucerop@....com>
> >>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> >>> Acked-by: Edward Cree <ecree.xilinx@...il.com>
> >>> Reviewed-by: Alison Schofield <alison.schofield@...el.com>  
> >> Hi Alejandro,
> >>
> >> I think I'm missing something with respect to the relative life times.
> >> Throwing one devm_ call into the middle of a probe is normally a recipe
> >> for at least hard to read code, if not actual bugs.  It should be done
> >> with care and accompanied by at least a comment.  
> >
> >
> > Hi Jonathan,
> >
> >
> > I agree devm_* being harder in general and prone to some subtle 
> > problems, but I can not see an issue here apart from the objects kept 
> > until device unbinding. But I think adding some comment can help.
> >
> >
> > <snip>
> >  
> >> +
> >> +    dvsec = pci_find_dvsec_capability(pci_dev, PCI_VENDOR_ID_CXL,
> >> +                      CXL_DVSEC_PCIE_DEVICE);
> >> +    if (!dvsec)
> >> +        return 0;
> >> +
> >> +    pci_dbg(pci_dev, "CXL_DVSEC_PCIE_DEVICE capability found\n");
> >> +
> >> +    /* Create a cxl_dev_state embedded in the cxl struct using cxl 
> >> core api
> >> +     * specifying no mbox available.
> >> +     */
> >> +    cxl = devm_cxl_dev_state_create(&pci_dev->dev, CXL_DEVTYPE_DEVMEM,
> >> +                    pci_dev->dev.id, dvsec, struct efx_cxl,
> >> +                    cxlds, false);
> >> The life time of this will outlast everything else in the efx driver.
> >> Is that definitely safe to do?  Mostly from a reviewability and 
> >> difficulty
> >> of reasoning we avoid such late releasing of resources.
> >>
> >> Perhaps add to the comment before this call what you are doing to 
> >> ensure that
> >> it is fine to release this after everything in efx_pci_remove()
> >>
> >> Or wrap it up in a devres group and release that group in 
> >> efx_cxl_exit().
> >>
> >> See devres_open_group(), devres_release_group()
> >>
> >>  
> >
> > As I said above, I can not see a problem here, but maybe to explicitly 
> > managed those resources with a devres group makes it simpler, so I 
> > think it is a good advice to follow.
> >
> >
> > Thanks!
> >
> >  
> 
> FWIW, I just want to add that although I agree with this, it is somehow 
> counterintuitive to me as the goal of devm is to avoid to care about 
> when to release those allocations.

In my view not quite.  It's to enforce that those allocations are released
in the reverse order of the devm setup calls - which is almost always
the right thing to do as long as whole driver is using devm.

There are uses like you describe though so it's not a universal case
of one or the other.  One advantage of the devres group thing is that
folk who are not keen on devm can effectively have normal manual release
flows.

Jonathan