On 10/11/24 18:38, Dan Williams wrote:
Alejandro Lucero Palau wrote:
Hi Dan,
I think this is the same issue one of the patches in type2 support tries
to deal with:
https://lore.kernel.org/linux-cxl/20240907081836.5801-1-alejandro.lucero-palau@xxxxxxx/T/#m9357a559c1a3cc7869ecce44a1801d51518d106e
If this fixes that situation, I guess I can drop that one from v4 which
is ready to be sent.
The other problem I try to fix in that patch, the endpoint not being
there when that code tries to use it, it is likely not needed either,
although I have a trivial fix for it now instead of that ugly loop with
delays. The solution is to add PROBE_FORCE_SYNCHRONOUS as probe_type for
the cxl_mem_driver which implies the device_add will only return when
the device is really created. Maybe that is worth it for other potential
situations suffering the delayed creation.
I am skeptical that PROBE_FORCE_SYNCRONOUS is a fix for any
device-readiness bug. Some other assumption is violated if that is
required.
But that problem is not about device readiness but just how the device
model works. In this case the memdev creation is adding devices, no real
ones but those abstractions we use from the device model, and that
device creation is done asynchronously. When the code creating the
memdev, a Type2 driver in my case, is going to work with such a device
abstraction just after the memdev creation, it is not there yet. It is
true that clx_mem_probe will interact with the real device, but the fact
is such a function is not invoked by the device model synchronously, so
the code using such a device abstraction needs to wait until it is
there. With this flag the waiting is implicit to device creation.
Without that flag other "nasty dancing" with delays and checks needs to
be done as the code in v3 did.
For the type-2 case I did have an EPROBE_DEFER in my initial RFC on the
assumption that an accelerator driver might want to wait until CXL is
initialized before the base accelerator proceeds. However, if
accelerator drivers behave the same as the cxl_pci driver and are ok
with asynchronus arrival of CXL functionality then no deferral is
needed.
I think deferring the accel driver makes sense. In the sfc driver case,
it could work without CXL and then change to use it once the CXL kernel
support is fully initialised, but I guess other accel drivers will rely
on CXL with no other option, and even with the sfc driver, supporting
such a change will make the code far more complex.
Otherwise, the only motivation for synchronous probing I can think of
would be to have more predictable naming of kernel objects. So yes, I
would be curious to understand what scenarios probe deferral is still
needed.
OK. I will keep that patch with the last change in the v4. Let's discuss
this further with that patch as a reference.
Thanks.
