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: <6982653bdfcbc_68d310065@dwillia2-mobl4.notmuch>
Date: Tue, 3 Feb 2026 13:14:35 -0800
From: <dan.j.williams@...el.com>
To: Li Ming <ming.li@...omail.com>, Jonathan Cameron
	<jonathan.cameron@...wei.com>
CC: dave <dave@...olabs.net>, 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

Li Ming wrote:
[..]
>  > > -            scoped_guard(device, &port->dev) {
>  > > +            scoped_guard(device, &parent_port_of(port)->dev) {
>  > I'm nervous about whether this is the right lock. For unregister_port()
>  > (which is easier to track down that the add path locking) the lock
>  > taken depends on where the port is that is being unregistered.
>  > Specifically root ports are unregistered under parent->uport_dev, not
>  > parent->dev.
> You are right.
> When cxl acpi driver attempts to add a cxl host bridge port, it will hold cxl_root->uport_dev.
> Otherwide, hold parent_port->dev lock for the new port addition.
> So I think it is possible that memdev can observe a cxl host bridge port but it has not been attach yet.
> Maybe I should hold the lock of the new port's host.
> Let's see if other reviewers have more comments on that.

So, I think current code is ok, if cxl_mem_probe() races
cxl_acpi_probe() in the same way that case is already caught by the
cxl_bus_rescan() at the end of cxl_acpi_probe().