Re: [PATCH 1/2] scsi: ufs: core: Release command resources instead of force-completing
From: Peter Wang
Date: Mon Sep 21 2026 - 23:07:51 EST
On Mon, 2026-09-21 at 09:51 -0700, Bart Van Assche wrote:
> > Agreed for the path where SCSI EH drove the reset. The case I am
> > unsure
> > about is the other caller: ufshcd_err_handler() also runs from
> > hba->eh_work, scheduled by ufshcd_check_errors() on UIC and
> > controller
> > errors. Those commands have not timed out and are not on
> > shost->eh_cmd_q, so SCSI EH never finishes them, and the handler
> > leaves
> > them to the reset path on purpose:
> >
> > /*
> > * if host reset is required then skip clearing the pending
> > * transfers forcefully because they will get cleared during
> > * host reset and restore
> > */
> >
> > Should those simply wait for the block layer timeout and come back
> > through SCSI EH?
>
> That sounds good to me.
>
> Thanks,
>
> Bart.
Hi Bart,
It appears unreasonable to wait for the entire 30 second timeout,
as many UIC errors recover promptly. The resulting 30 second stall
would manifest as a noticeable UI freeze. Maybe we shouldn’t let
eh_host_reset_handler call the EH handler at all?
Thanks
Peter