Re: [RFC PATCH] scsi: virtio_scsi: bound EH timer resets to avoid unkillable hang

[Hannes Reinecke <hare@suse.de>]

On 9/11/26 6:44 PM, Nguyen Ngoc Thang wrote:
> Thank you for the review -- the eh_host_reset_handler finding is correct,
> and the underlying mechanism is worse than a stale read.
> 
> Once virtscsi_eh_timed_out() lets SCSI EH run to completion on an
> unresponsive host, scsi_eh_bus_device_reset() leaves the command in
> work_q (device reset fails the same way abort does, via the same bounded
> virtscsi_tmf()), and since virtio_scsi implements neither
> eh_target_reset_handler, eh_bus_reset_handler nor eh_host_reset_handler,
> scsi_eh_target_reset()/scsi_eh_bus_reset()/scsi_eh_host_reset() all fail
> immediately (scsi_try_*_reset() return FAILED when the handler pointer is
> NULL) and the command falls through to scsi_eh_offline_sdevs(), which
> calls scsi_eh_finish_cmd() and frees the tag back to the block layer.
> 
[ .. ]
> 
> Happy to do the legwork on whichever direction you point at -- I have a
> QEMU virtio-scsi repro harness already wired up for the original hang
> (clearing PCI_COMMAND_MASTER mid-write) that I can extend to exercise
> the recovery path too.
> 
In short: you can't.
The linux kernel lacks the ability to abort an outstanding I/O from 
userspace; userspace (and that includes qemu) _has_ to wait for that
I/O to return.
Otherwise there is no guarantee that the DMA regions of that command
are ever freed, and the kernel can happily scribble over memory which
userspace already assumed to be free. As these DMA regions are mapped
into the qemu guest you essentially allow the kernel to overwrite guest
memory at any time.
Not a good idea.

In general: SCSI host_reset _is_ the bug hammer. If that doesn't work
(for whatever reason) you system is hosed as you can _never_ get the
memory and DMA regions of outstanding commands back to the system.
So the better fix would be to implement a host_reset() callback for
virtio-scsi which would reset the virtio setup, terminating all
outstanding commands and reset the queues.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich