[PATCH] cxl: Force context lock during EEH flow

[Vaibhav Jain]

Frederic Barrat <fbarrat at linux.vnet.ibm.com> writes:

>>
>> +	/* forcibly take the context lock to prevent new context activation */
>> +	cxl_adapter_context_force_lock(adapter);
>> +
>
> I'm not a fan of the "force lock" call and I'm not convinced it's 
> needed. When an EEH is triggered, we'll force-detach all the contexts. 
> So that in itself should bring the counter of active contexts to 0. So 
> why not just add a cxl_adapter_context_lock() call at the end of 
> cxl_pci_error_detected()? The lock would be released in 
> cxl_configure_adapter when cxl_pci_slot_reset() is called, as is already 
> the case with the current code.
> (as a side note, I don't believe the code is racy and that we need to 
> add extra protection to avoid context activation while 
> cxl_pci_error_detected() is called. We can talk about it if needed)

Hi Fred,

Thanks for reviewing the patch.

Function cxl_adapter_context_force_lock is introduced to handle cases
where in we don't want any new contexts to be activated while we go ahead
and detach all the currently activated contexts. This usually is the
case in error paths when we are performing cleanups of existing contexts
(control flows with cxl_context_detach_all).

This is in contrast with cxl_adapter_context_lock which need to wait for
all the active contexts to be detached and during the wait other
contexts can be activated. The _force_lock variant provides guarantees
against this by not letting any context to be activated and still
letting existing contexts be cleaned up.

This behavior though can also be achieved by having a separate flag in
the adapter-struct and checking it before letting a context
activate. However with cxl_adapter_context_force_lock I tried to re-use
the existing infrastructure we have already put in place to prevent
context activation while we are doing card reset.

In retrospect this is a more generic issue that we may wish to address
in cxl where in we want to prevent certain ops like context activation
or reading config space and also let existing consumers of these ops to
complete. It would be also better if other contributers can also pitch
in and provide there feedback as to possibly solve this problem in a
more generic manner.

Thanks,
-- 
Vaibhav Jain <vaibhav at linux.vnet.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.