Re: [PATCH v2 1/2] ata: libata-eh: correctly handle deferred qc timeouts

[Niklas Cassel <cassel@kernel.org>]

On Fri, Mar 06, 2026 at 09:59:38AM +0900, Damien Le Moal wrote:
> On 3/6/26 09:11, Damien Le Moal wrote:
> >>> Could this mistakenly intercept a command that completed normally after a
> >>> SCSI timeout, returning a timeout error instead of success? Would this
> >>> also incorrectly clear `ap->deferred_qc`, dropping the deferred command?
> >>
> >> I think the AI is partially wrong here.
> >>
> >> If you read the comment below it if (), we know that ap->deferred_qc is only
> >> set until that command has been issued. So if it is set, that qc has not
> >> been issued, so it can't have successfully completed.
> > 
> > The request for the qc/scsi command was started from the block layer perspective
> > and so can still timeout. So this is all valid.
> > 
> > BUT ATA_MAX_QUEUE qc (last in the loop if there is no match) is the one reserved
> > for internal commands issued from EH. Internal QCs do not go through the
> > deferred issue path, so even without checking for the index when there is no
> > match, we have:
> >  - qc is still a valid pointer (the array of QCs is ATA_MAX_QUEUE + 1 sized)
> >  - We can never have qc == ap->deferred_qc.
> 
> This second part of my comment is obviously wrong. I need more coffee :)
> 
> The first part stands: a deferred qc that has not been issued can timeout.

Yes, did someone claim otherwise?


Kind regards,
Niklas