Hi,

在 2026/2/11 0:28, Daniel Wagner 写道:

On Tue, Feb 10, 2026 at 09:01:14AM -0700, Keith Busch wrote:

quoted

On Tue, Feb 10, 2026 at 04:41:08PM +0100, Christoph Hellwig wrote:

quoted

On Tue, Feb 10, 2026 at 08:09:08AM -0700, Keith Busch wrote:

quoted

If you leave the queue quiesced, pending IO will form requests that are
entered and waiting in the block layer. You can't freeze a queue with
entered requests.

We unquiesce first to flush any pending IO that had entered during the
prior reset. It's not the best way to handle this situation. It would be
smarter to steal the bio's from all the entered requests, then end those
requests, then resubmit the bios after the hw queues are initialized. We
don't do that because no one's really complained, probably because the
queue counts don't usually change after a reset.

FYI, Daniel Wagner had been thinking about doing this reinsert for
something (I forgot what exactly),

This feature would solve a tricky problem with isolation patches:

https://lore.kernel.org/linux-nvme/87cy7vrbc4.ffs@tglx/ (local)

Currently, it's not possible to take the cpu hotplug lock which would
prevent races in the cpu-queue mapping. The current logic depends on
making progress in the error case. If it would be possible to fail the
in-flight request in the error handler and reinsert them in the block
layer, progress could be guaranteed when holding the cpu hotplug lock.

Unfortunatly, haven't found time to implement and test this idea so far.
Sorry.

Thanks all!

If I understand this correctly, it seems fine to make progress with this set,
currently IO can return error during the race window, and this can be finally
fixed with this reinsert.

-- 
Thansk,
Kuai