linux-kernel - Re: [PATCH 6/6] cxl/mem: Introduce a memdev creation ->probe() operation

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: <03ec6e1f-bb7d-42e2-a887-70c18dbf4749@amd.com>
Date: Thu, 4 Dec 2025 13:10:05 -0600
From: "Cheatham, Benjamin" <benjamin.cheatham@....com>
To: Dan Williams <dan.j.williams@...el.com>, <dave.jiang@...el.com>
CC: <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>, <Jonathan.Cameron@...wei.com>, Alejandro Lucero
	<alucerop@....com>
Subject: Re: [PATCH 6/6] cxl/mem: Introduce a memdev creation ->probe()
 operation

[snip]

> +static struct cxl_memdev *cxl_memdev_autoremove(struct cxl_memdev *cxlmd)
> +{
> +	struct cxl_memdev *ret = cxlmd;
> +	int rc;
> +
> +	/*
> +	 * If ops is provided fail if the driver is not attached upon
> +	 * return. The ->endpoint ERR_PTR may have a more precise error
> +	 * code to convey. Note that failure here could be the result of
> +	 * a race to teardown the CXL port topology. I.e.
> +	 * cxl_mem_probe() could have succeeded and then cxl_mem unbound
> +	 * before the lock is acquired.
> +	 */
> +	guard(device)(&cxlmd->dev);
> +	if (cxlmd->ops && !cxlmd->dev.driver) {
> +		ret = ERR_PTR(-ENXIO);
> +		if (IS_ERR(cxlmd->endpoint))
> +			ret = ERR_CAST(cxlmd->endpoint);
> +		cxl_memdev_unregister(cxlmd);
> +		return ret;
> +	}

Two minor gripes here:

1. The cxlmd->endpoint portion of this is unused. I think the idea is since this is prep work for
Alejandro's set to just put in here, but I would argue it should be introduced in his set since that's
where it's actually used.

2. I don't particularly like drivers having to provide a cxlmd->ops to automatically unregister the device on
cxl_mem probe failure. It's probably not likely, but it possible that a driver wouldn't have any extra set up
to do for CXL.mem but still needs to fallback to PCIe mode if it can't be properly set up.

I don't want to nit-pick without alternatives, so my first thought was a flag passed into devm_cxl_add_memdev()
(and eventually this function) that dictates whether failure to attach to cxl_mem is a failure condition. Then
that flag replaces the cxlmd->ops check. It may not be worth adding that degree of versatility before anyone
wants it though, so I'm fine with the above approach if you feel it's the way to go.

Thanks,
Ben