Make NVME shutdown two-pass - Version 6

[Jeremy Allison]

On Thu, Feb 08, 2024 at 01:02:37PM -0500, David Jeffery wrote:
>
>Hi Jeremy,
>
>I'm fine with merging our efforts. From reviewing your patch set, the
>main problem I have is with the core patch compared to my initial 2
>patches. Yours runs shutdown_wait calls after shutdown for all
>devices. This design won't work for example with the scsi system sd
>async shutdown. Scsi HBA shutdown calls may stop the HBA or firmware,
>leaving the async flush for sd in an unknowable state as to if the
>command succeeded or even made it to storage. My patches by ensuring
>all shutdown for child devices is finished before a parent device's
>shutdown may be called allows the ordering to work.
>
>I'm not attached to a particular async API. If nvme and core devs are
>fine with the shutdown_wait api, I can alter my core shutdown and
>scsi/sd patches to match.
>
>David Jeffery

Great point David, thanks ! I wasn't testing with the scsi system
shutdown, only PCI nvme. I didn't know the scsi system suffered
from slow shutdown also.

As I've already done the work to get the bus driver and nvme devs
to agree on the shutdown()/shutdown_wait() two-pass interface
(and they have already signed off on that), I'd suggest keeping
that interface.

Looks like the key change is the addition of the ability of
a device to mark its parent as busy to keep the parent-child
ordering.

If you're willing to merge your patches and required fixes
for the scsi system on top of the new agreed on API then I'll
be happy to help review and test any updated patchsets to make
sure my nvme PCI case gets fixed too. It might be easiest to
add in the scsi changes needed on top of my existing working
code for nvme/PCI (I've already had confirmation from an nvme
list user that my patchset improves his shutdown times
significantly) but I'll let you make the decisions on that.
I'm not wedded to any specific code :-).

Thanks for collaborating on this.

Cheers,

	Jeremy.