cxl <-> udev deadlock?

[Marc Herbert <Marc.Herbert@linux.intel.com>]

On 2025-05-14 04:20, ruansy.fnst wrote:
> 
> Now that cxl_wait_probe() has been added[1] to wait for udev queue
> empty, the `udevadm settle` here is no longer necessary.
> 
> [1] b231603 cxl/lib: Add cxl_wait_probe()
> 
> Signed-off-by: Ruan Shiyang <ruansy.fnst@fujitsu.com>
> 
> ===
> Question to Dan:
> 
> I understand how cxl_wait_probe() work, but I have some questions about
> the motivation of adding this function:  Firstly, is it function added
> for simply waiting for new added CXL device been ready before cxl
> command does the actual work?  Just for replacing `udevadm settle`'s
> work?
> 
> Now I am facing a problem that cxl command takes a long time to complete
> when I run it in a udev rule(do some configuration when CXL memdev is
> added).  I found it is caused by this function: waitting for udev
> queue's endding but itself is in the queue.  The cxl_wait_probe()
> function does not seem to allow me to do that.  So, the 2nd question is:
> is it against the spec to run cxl command in a udev rule?

cxl waits for udev which waits for cxl... this looks like an interesting
deadlock!?

When you write "a long time to complete", do you mean "aborted after the
default, 180s udev timeout?"

https://www.freedesktop.org/software/systemd/man/latest/systemd-udevd.service.html

udev is not designed to start long-running processes BUT udev is designed
to communicate with systemd which is the correct manager for all
long-running processes:

https://www.freedesktop.org/software/systemd/man/latest/systemd.device.html

You can find examples on your system like this:

  grep -r SYSTEMD_.*WANT /usr/lib/udev/

Now, I think you are not interested in running anything for _long_. But,
the same technique and indirection should also break the deadlock (if any)
because udev messages to systemd are "fire and forget".

Also, systemd is designed to collect and report logs, exit status
etc. which is very useful when something goes wrong. udev does not
do that.