Re: [PATCH v3 2/2] cxl/memdev: Fix deadlock between poison debugfs and cxl_mem unbind

[Jonathan Cameron <jic23@kernel.org>]

On Thu, 10 Sep 2026 13:58:28 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Thu, Sep 10, 2026 at 07:28:03PM +0800, Guixin Liu wrote:
> > 
> > 
> > 在 2026/9/10 17:52, Greg Kroah-Hartman 写道:  
> > > 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.  
> > Agreed, nobody should unbind cxl_mem in production. The sysfs unbind is
> > in the reproducer only because it's the cheapest trigger.
> > 
> > The window itself is not sysfs-unbind specific.
> > The debugfs directory is torn down from a devm action, so every path that
> > ends
> > in device_release_driver_internal() hits the same wait: rmmod cxl_mem, and
> > the
> > memdev detach work that PCI hot-remove schedules. That detach path is the
> > third
> > task in the reproducer stack, the one wedged on cxl_bus_wq.
> > A poison write racing an rmmod or a hot-remove is not root misbehaving,
> > and no taint flags it either.  
> 
> But how can cxl_mem ever be removed, it doesn't live on a bus that is
> hot-removable, does it?

It is effectively a child of cxl_pci and that lives on the pci bus and
definitely is hotpluggable.  Those flows should work fine so
I see this as a real if somewhat obscure bug to fix.

Jonathan



> 
> rmmod doesn't count either, that never happens except by developers.
> 
> thanks,
> 
> greg k-h