linux-kernel - Re: [PATCH v2 6/6] cxl/mem: Introduce cxl_memdev

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: <6942d9d46e09e_1cee10089@dwillia2-mobl4.notmuch>
Date: Wed, 17 Dec 2025 08:27:00 -0800
From: <dan.j.williams@...el.com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>, Dan Williams
	<dan.j.williams@...el.com>
CC: <dave.jiang@...el.com>, <linux-cxl@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <Smita.KoralahalliChannabasappa@....com>,
	<alison.schofield@...el.com>, <terry.bowman@....com>,
	<alejandro.lucero-palau@....com>, <linux-pci@...r.kernel.org>, Ben Cheatham
	<benjamin.cheatham@....com>, Alejandro Lucero <alucerop@....com>
Subject: Re: [PATCH v2 6/6] cxl/mem: Introduce cxl_memdev_attach for
 CXL-dependent operation

Jonathan Cameron wrote:
> On Mon, 15 Dec 2025 16:56:16 -0800
> Dan Williams <dan.j.williams@...el.com> wrote:
> 
> > Unlike the cxl_pci class driver that opportunistically enables memory
> > expansion with no other dependent functionality, CXL accelerator drivers
> > have distinct PCIe-only and CXL-enhanced operation states. If CXL is
> > available some additional coherent memory/cache operations can be enabled,
> > otherwise traditional DMA+MMIO over PCIe/CXL.io is a fallback.
> > 
> > Allow for a driver to pass a routine to be called in cxl_mem_probe()
> > context. This ability is inspired by and mirrors the semantics of
> > faux_device_create(). It allows for the caller to run CXL-topology
> > attach-dependent logic on behalf of the caller.
> 
> This seems confusing. 

Is faux_device_create() confusing?

> The caller is running logic for the caller?  It can do that whenever
> it likes!  One of those is presumably callee

No, it cannot execute CXL topology attach dependendent functionality in
the device's initial probe context synchronous with the device-attach
event "whenever it likes".

> > The probe callback runs after the port topology is successfully attached
> > for the given memdev.
> > 
> > Additionally the presence of @cxlmd->attach indicates that the accelerator
> > driver be detached when CXL operation ends. This conceptually makes a CXL
> > link loss event mirror a PCIe link loss event which results in triggering
> > the ->remove() callback of affected devices+drivers. A driver can re-attach
> > to recover back to PCIe-only operation. Live recovery, i.e. without a
> > ->remove()/->probe() cycle, is left as a future consideration.  
> > 
> > Cc: Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>
> > Reviewed-by: Ben Cheatham <benjamin.cheatham@....com>
> > Reviewed-by: Dave Jiang <dave.jiang@...el.com> (✓ DKIM/intel.com)
> 
> Have we started adding DKIM stuff to tags?

No, just a copy/paste typo that I did not catch.

> > Tested-by: Alejandro Lucero <alucerop@....com> (✓ DKIM/amd.com)
> > Signed-off-by: Dan Williams <dan.j.williams@...el.com>
> One trivial thing on function naming inline.  Either way.
> Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>
> 
> To me this looks good to start building the other stuff on top of.
> Thanks for unblocking this stuff (hopefully)
> 
> Jonathan
> 
> > ---
> >  drivers/cxl/cxlmem.h         | 12 ++++++++++--
> >  drivers/cxl/core/memdev.c    | 33 +++++++++++++++++++++++++++++----
> >  drivers/cxl/mem.c            | 20 ++++++++++++++++----
> >  drivers/cxl/pci.c            |  2 +-
> >  tools/testing/cxl/test/mem.c |  2 +-
> >  5 files changed, 57 insertions(+), 12 deletions(-)
> 
> > diff --git a/drivers/cxl/core/memdev.c b/drivers/cxl/core/memdev.c
> > index 63da2bd4436e..3ab4cd8f19ed 100644
> > --- a/drivers/cxl/core/memdev.c
> > +++ b/drivers/cxl/core/memdev.c
> 
> 
> > @@ -1081,6 +1093,18 @@ static struct cxl_memdev *cxl_memdev_autoremove(struct cxl_memdev *cxlmd)
> >  {
> >  	int rc;
> >  
> > +	/*
> 
> The general approach is fine but is the function name appropriate for this
> new stuff?  Naturally I'm not suggesting the bikeshed should be any particular
> alternative color just maybe not the current blue.

The _autoremove() verb appears multiple times in the subsystem, not sure
why it is raising bikeshed concerns now. Please send a new proposal if
"autoremove" is not jibing.