On Wed, Dec 21, 2022 at 4:59 PM Peter Wang (王信友) <peter.wang@xxxxxxxxxxxx> wrote: > But if without this patch when purge is onging, system IO will hang, > this is no better. Yes, that is why I am just pointing this out as a matter of fact, not as a bug. It is arguable if resetting the controller in the deadlock situation is a proper thing to do, but it might be the next best thing, so I don't argue that neither. > So, with current design, if purge initiator do not want to see rpm > EBUSY, then he should polling bPurgeStatus. > What do you think? I am actually not sure if management operations extend the timeout - they are going through bsg interface, and I am not sure it properly re-sets the timeouts on all possible nexus interfaces, need to check that. But even if it does, there are two problems: * If you make kernel be polling that parameter - it will actually make the application level to miss the completion code (since after querying completion once it will return Not Started afterwards). * And application polling is race prone. We set runtime suspend to 100ms - so depending on the scheduling quirks it may miss the event. --Daniil
