[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <698278b96e1be_55fa10072@dwillia2-mobl4.notmuch>
Date: Tue, 3 Feb 2026 14:37:45 -0800
From: <dan.j.williams@...el.com>
To: Li Ming <ming.li@...omail.com>, danjwilliams <dan.j.williams@...el.com>
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>, linux-cxl <linux-cxl@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] cxl/core: Set cxlmd->endpoint to NULL by default
Li Ming wrote:
[..]
> Hi Dan,
>
> Thanks for your proposal, I think your change can solve this problem too.
> But the change is a lot, and need more time to review all driver code
> to confirm if there are other places needed such checking. (I found
> that cxl_reset_done also needs some changes like you mentioned) Maybe
> we can consider my change as a quick fix? Then I can prepare a new
> patchset for the consolidation.
I am not convinced that it is a fix. The fact that you say the bug
disappears when patch2 is applied leads me to believe that is
potentially the only bug.
I.e. it may be the case that cxl_dpa_to_region() is safe to assume that
a valid ->endpoint pointer will remain valid once the port
bus_add_device() vs bus_probe_device() hole is plugged.
I would say start with patch2 by itself. Then circle back to prove
that a mere NULL check is a fix or just makes the vulnerability window
smaller and the locking rework is needed.
Powered by blists - more mailing lists