linux-kernel - Re: [PATCH] cxl/memdev: fix deadlock in 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: <aYu1M75-tV8-TLAC@gourry-fedora-PF4VCD3F>
Date: Tue, 10 Feb 2026 17:46:11 -0500
From: Gregory Price <gourry@...rry.net>
To: Ira Weiny <ira.weiny@...el.com>
Cc: linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel-team@...a.com, dave@...olabs.net,
	jonathan.cameron@...wei.com, dave.jiang@...el.com,
	alison.schofield@...el.com, vishal.l.verma@...el.com,
	dan.j.williams@...el.com
Subject: Re: [PATCH] cxl/memdev: fix deadlock in cxl_memdev_autoremove() on
 attach failure

On Tue, Feb 10, 2026 at 01:44:06PM -0600, Ira Weiny wrote:
> Gregory Price wrote:
> > 
> > diff --git a/drivers/cxl/core/memdev.c b/drivers/cxl/core/memdev.c
> > index af3d0cc65138..c0de767b24fb 100644
> > --- a/drivers/cxl/core/memdev.c
> > +++ b/drivers/cxl/core/memdev.c
> > @@ -1098,19 +1098,22 @@ static struct cxl_memdev *cxl_memdev_autoremove(struct cxl_memdev *cxlmd)
> >  	 * return. 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.
> > +	 *
> > +	 * Check under device_lock but unregister outside of it, as
> > +	 * cxl_memdev_unregister() will also take the device lock.
> >  	 */
> > -	guard(device)(&cxlmd->dev);
> > -	if (cxlmd->attach && !cxlmd->dev.driver) {
> > -		cxl_memdev_unregister(cxlmd);
> > -		return ERR_PTR(-ENXIO);
> > +	scoped_guard(device, &cxlmd->dev) {
> > +		if (cxlmd->attach && !cxlmd->dev.driver)
> > +			break;
> > +
> > +		rc = devm_add_action_or_reset(cxlmd->cxlds->dev,
> > +					      cxl_memdev_unregister, cxlmd);
> 
> This kind of threw me...  Won't this deadlock if
> devm_add_action_or_reset() fails as well?
> 
> Need to use devm_add_action() and drop out of the guard on failure.
> 

lol i pointed out that this patch was a claude recommendation on the
initial report - didn't look to hard because it fixed this specific
deadlock with:

	if (cxlmd->attach && !cxlmd->dev.driver)
		break;

so yeah, easy enough to fixup.

I can either v2 or Dave if you want to just make the oneline change
before pull let me know

~Gregory