Frederic Barrat <fbarrat@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> Linux Technology Center, IBM India Pvt. Ltd. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html