Re: Investigating potential flaw in scsi error handling

[Elias Oltmanns <eo@nebensachen.de>]

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> On Sun, 2008-02-10 at 16:29 +0100, Elias Oltmanns wrote:
>> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
[...]
>> > No.  We have a fix for this, it's called setting device_max_blocked to 2
>> > or greater.  All your patch does is make this seem to be the case, plus
>> > it eliminates the instant reissue case for drivers with queuecommands
>> > that do obey all the rules.
>> >
>> > If you can prove that IDE doesn't obey the rules (no defer returns)
>> 
>> In fact, I can prove that scsi midlayer itself doesn't exactly comply
>> with this rule by design. The comment explaining the SDEV_BLOCK state in
>> scsi_device.h suggests that the low level driver is supposed to control
>> whether a device is switched to or from SDEV_BLOCK. However, with
>> max_device_blocked set to 1 we have an infinite loop where the low level
>> driver never gets even called since scsi_dispatch_cmd will requeue the
>> request instantly.
>> 
>> IDE doesn't obey the rule either but this can be fixed easily. So, what
>> about SDEV_BLOCK?
>
> Well, nothing.  It's an API a HBA may not use (per previous rule) if it
> wants to set max_device_blocked to 1.

Right. Thanks for the clarification.

Regards,

Elias