All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Guixin Liu <kanie@linux.alibaba.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
	Jonathan Cameron <jic23@kernel.org>,
	Dave Jiang <dave.jiang@intel.com>,
	Alison Schofield <alison.schofield@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>,
	"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 v3 2/2] cxl/memdev: Fix deadlock between poison debugfs and cxl_mem unbind
Date: Thu, 10 Sep 2026 11:52:17 +0200	[thread overview]
Message-ID: <2026091013-deepness-astronaut-471a@gregkh> (raw)
In-Reply-To: <20260910094017.4032170-3-kanie@linux.alibaba.com>

On Thu, Sep 10, 2026 at 05:40:17PM +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.
> 
> 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.
> 
> 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.

Why would anyone normally "unbind" cxl_mem at all?  That will taint
kernels soon, so you don't normally want to do that, right?

And debugfs is root-only, so this is a "root did something bad, and gets
to keep the mess", right?  This should not ever be a normal operation.

thanks,

greg k-h

  reply	other threads:[~2026-09-10  9:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10  9:40 [PATCH v3 0/2] cxl/memdev: Fix poison debugfs vs unbind deadlock Guixin Liu
2026-09-10  9:40 ` [PATCH v3 1/2] driver core: Add conditional guard support for device_trylock() Guixin Liu
2026-09-10 20:55   ` Jonathan Cameron
2026-09-10  9:40 ` [PATCH v3 2/2] cxl/memdev: Fix deadlock between poison debugfs and cxl_mem unbind Guixin Liu
2026-09-10  9:52   ` Greg Kroah-Hartman [this message]
2026-09-10 11:28     ` Guixin Liu
2026-09-10 11:58       ` Greg Kroah-Hartman
2026-09-10 20:52         ` Jonathan Cameron
2026-09-10 21:03   ` Jonathan Cameron
2026-09-11  3:04     ` Guixin Liu
2026-09-11 23:09       ` Jonathan Cameron

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=2026091013-deepness-astronaut-471a@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=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=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.