From: Alison Schofield <alison.schofield@intel.com>
To: Guixin Liu <kanie@linux.alibaba.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
Jonathan Cameron <jic23@kernel.org>,
Dave Jiang <dave.jiang@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Dan Williams <djbw@kernel.org>, Ira Weiny <iweiny@kernel.org>,
Li Ming <ming.li@zohomail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Shaikh Kamaluddin <shaikhkamal2012@gmail.com>,
<linux-cxl@vger.kernel.org>, <driver-core@lists.linux.dev>
Subject: Re: [PATCH v4 2/2] cxl/memdev: Fix deadlock between poison debugfs and cxl_mem unbind
Date: Fri, 18 Sep 2026 12:30:00 -0700 [thread overview]
Message-ID: <aq2ROFJl-PHXIKL5@aschofie-mobl2.lan> (raw)
In-Reply-To: <20260916025453.3532614-3-kanie@linux.alibaba.com>
On Wed, Sep 16, 2026 at 10:54:53AM +0800, Guixin Liu wrote:
> The poison debugfs handlers take the memdev device lock so that the
> region lookup sees a stable cxlmd->dev.driver. debugfs holds a
> reference on the file across the handler, and cxl_mem unbind removes
> that file while holding the very same device lock, so a handler that
> waits for the lock deadlocks against a concurrent unbind.
>
> The trigger is any teardown that detaches cxl_mem from the memdev
> while a poison write is in flight: unbinding or unloading cxl_mem or
> cxl_pci, or removing the endpoint PCI device, including hot-remove.
>
> Both tasks then hang. The unbind side is uninterruptible, and it also
> blocks the memdev detach work, which runs on an ordered workqueue and so
> stalls every other CXL bus work item.
>
> Take the lock with the trylock guard and return -EBUSY instead of
> waiting. An unbind that wins the race removes the file first and the
> write fails with -ENOENT.
>
> The poison inject and clear files are a debug ABI for expert users,
> mostly device vendors, to test the poison capabilities of their
> devices. Mixing a poison write with cxl_mem teardown is not a supported
> use of the interface, but when it happens anyway the cost should be a
> failed write, not a hung kernel.
>
> Found by code inspection. Reproduced by writing inject_poison in a loop
> while unbinding and rebinding cxl_mem, and confirmed fixed by the same
> test. Also reproduced the same deadlock with those writes racing a
> pciehp hot-remove of the memdev; with this patch the hot-remove flow
> completes normally.
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
next prev parent reply other threads:[~2026-09-18 19:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 2:54 [PATCH v4 0/2] cxl/memdev: Fix poison debugfs vs unbind deadlock Guixin Liu
2026-09-16 2:54 ` [PATCH v4 1/2] driver core: Add conditional guard support for device_trylock() Guixin Liu
2026-09-16 2:54 ` [PATCH v4 2/2] cxl/memdev: Fix deadlock between poison debugfs and cxl_mem unbind Guixin Liu
2026-09-18 19:30 ` Alison Schofield [this message]
2026-09-18 15:26 ` [PATCH v4 0/2] cxl/memdev: Fix poison debugfs vs unbind deadlock Dave Jiang
2026-09-18 17:30 ` Greg Kroah-Hartman
2026-09-21 14:48 ` Dave Jiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aq2ROFJl-PHXIKL5@aschofie-mobl2.lan \
--to=alison.schofield@intel.com \
--cc=dakr@kernel.org \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=djbw@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=kanie@linux.alibaba.com \
--cc=linux-cxl@vger.kernel.org \
--cc=ming.li@zohomail.com \
--cc=rafael@kernel.org \
--cc=shaikhkamal2012@gmail.com \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.