linux-kernel - Re: [PATCH 2/2] cxl/core: Hold grandparent port lock while dport adding

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: <19c23ec6444.fa7d548e7409.6321851600706723924@zohomail.com>
Date: Tue, 03 Feb 2026 22:33:40 +0800
From: Li Ming <ming.li@...omail.com>
To: "Gregory Price" <gourry@...rry.net>
Cc: "dave" <dave@...olabs.net>,
	"jonathan.cameron" <jonathan.cameron@...wei.com>,
	"dave.jiang" <dave.jiang@...el.com>,
	"alison.schofield" <alison.schofield@...el.com>,
	"vishal.l.verma" <vishal.l.verma@...el.com>,
	"ira.weiny" <ira.weiny@...el.com>,
	"dan.j.williams" <dan.j.williams@...el.com>,
	"linux-cxl" <linux-cxl@...r.kernel.org>,
	"linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] cxl/core: Hold grandparent port lock while dport
 adding




From: Gregory Price <gourry@...rry.net>
To: "Li Ming"<ming.li@...omail.com>
Cc: <dave@...olabs.net>, <jonathan.cameron@...wei.com>, <dave.jiang@...el.com>, <alison.schofield@...el.com>, <vishal.l.verma@...el.com>, <ira.weiny@...el.com>, <dan.j.williams@...el.com>, <linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Date: Tue, 03 Feb 2026 00:31:45 +0800
Subject: Re: [PATCH 2/2] cxl/core: Hold grandparent port lock while dport adding

 > On Sun, Feb 01, 2026 at 05:30:02PM +0800, Li Ming wrote:
 > > When CXL subsystem adds a cxl port to a hierarchy, there is a small
 > > window where the new port becomes visible before it is bound to a
 > > driver. This happens because device_add() adds a device to bus device
 > > list before bus_probe_device() binds it to a driver.
 > > So if two cxl memdevs are trying to add a dport to a same port via
 > > devm_cxl_enumerate_ports(), the second cxl memdev may observe the port
 > > and attempt to add a dport, but fails because the port has not yet been
 > > attached to cxl port driver.
 > > the sequence is like:
 > > 
 > > CPU 0                    CPU 1
 > > devm_cxl_enumerate_ports()
 > >   # port not found, add it
 > >   add_port_attach_ep()
 > >     # hold the parent port lock
 > >     # to add the new port
 > >     devm_cxl_create_port()
 > >       device_add()
 > >     # Add dev to bus devs list
 > >     bus_add_device()
 > >                     devm_cxl_enumerate_ports()
 > >                     # found the port
 > >                     find_cxl_port_by_uport()
 > >                     # hold port lock to add a dport
 > >                     device_lock(the port)
 > >                     find_or_add_dport()
 > >                       cxl_port_add_dport()
 > >                         return -ENXIO because port->dev.driver is NULL
 > >                     device_unlock(the port)
 > >     bus_probe_device()
 > >       # hold the port lock
 > >       # for attaching
 > >       device_lock(the port)
 > >         attaching the new port
 > >       device_unlock(the port)
 > > 
 > > To fix this race, require that dport addition holds the parent port lock
 > > of the target port. The CXL subsystem already requires holding the
 > > parent port lock while attaching a new port. Therefore, successfully
 > > acquiring the parent port lock ganrantees that port attaching has
 > > completed.
 > > 
 > 
 > With just a a cursory look, I'm immediately concerned that you're fixing
 > a race condition with a lock inversion.
 > 
 > Can you guarantee the following is not happening
 > 
 >   Thread A         Thread B
 >   ----------------------------
 >   lock(parent)     lock(port)
 >   lock(port)       lock(parent)
 > 
 > ~Gregory
 > 
Hi Gregory,

I think no other scenario where driver needs to hold a child port lock together with its parent port lock than during a new port attaching or a port removal.
After re-reading a new port attaching and a port removal flows, I believe both operations acquire the parent port first before acquiring a child port lock. So I think the thread B case would not happen. If I miss something please correct me. Thanks

Ming