Re: [PATCH 1/2] cxl/region: Timeout auto region assembly waiting for endpoints

[<dan.j.williams@intel.com>]

Gregory Price wrote:
> On Thu, Jan 29, 2026 at 08:58:09PM -0800, dan.j.williams@intel.com wrote:
> > 
> > > Cancel the timeout when all expected endpoints attach or the region is
> > > unregistered for any reason.
> > 
> > Setting aside the above, this looks like policy, and every time I see
> > policy the first question is "can userspace do it?". It would be
> > straightforward for userspace to kick a 30 second watchdog upon each
> > region KOBJ_ADD event. Each time that fires go cleanup partially
> > assembled regions.
> > 
> > For example there is no automatic cleanup of partially assembled RAID
> > arrays. So, precedent leans towards letting userspace decide what
> > happens when composite devices fail assembly.
> 
> Sounds like there'll be a nasty race implied here.
> 
> Lets assume a kmem region that gets auto-onlined
> 
> 0) Region is waiting for a device
>    1) Final device arrives and starts probing, locking the region

"locking?". There is no IORESOURCE_BUSY contention until the final
driver attaches.

>    2) Userspace timeout occurs, firing a cleanup request
> 2) Region finishes probing
>    2a) this creates the dax region
>    2b) this creates the dax_kmem device
>    2c) this may auto-hotplug into ZONE_NORMAL
>    2d) kernel page gets allocated on the memory region
> 3) Userspace cleanup arrives to unbind
>    3a) dax_kmem is online and can't hot-unplug

Right, userspace needs to honor typical managed hotplug and not force
removal.

>    3b) dax_kmem abandons hope and leaves the memory online
>        (see dev_dax_kmem_remove and remove_memory)
>    3c) region cleans up
> 
> Final state: region can't be rebound because memory is left online
> and unassociated with any device

I do not see how we get into this situation. If dax_kmem comes up, then
there is nothing to clean up. Yes, these can race, but typical locking
should ensure full forward progress or cleanup.