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

[Guixin Liu <kanie@linux.alibaba.com>]

在 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.

Best Regards,
Guixin Liu
> thanks,
>
> greg k-h