On Feb 15, 2013, at 5:32 PM, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote:
> On 13-02-15 04:48 PM, Mike Christie wrote:
>> On 02/15/2013 01:39 PM, Douglas Gilbert wrote:
>>> Further to the thread titled: "[PATCH] SG_SCSI_RESET ioctl should
>>> only perform requested operation" by Jeremy Linton a patch
>>> is presented that adds "no_escalate" versions to the existing
>>> ioctl. This should not break any existing code.
>>>
>>> This patches applies to lk 3.7.7 and lk 3.8.0-rc7 . I will extend
>>> sg_reset in the sg3_utils package to use it.
>>>
>>> ChangeLog:
>>> - modify SG_SCSI_RESET ioctl so the SG_SCSI_RESET_NO_ESCALATE
>>> value may be added to the existing values. If so the existing
>>> device->target->bus->host escalation does not occur.
>>> - modify scsi_reset_provider() in the scsi_error.c file in a
>>> similar way to support this new functionality.
>>>
>>> Signed-off-by: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>
>>
>> Some drivers rely on more invasive eh callbacks to be called if they
>> return FAILED in a eh callbacks. Is there a way for drivers to tell
>> scsi-ml it needs the old behavior?
>
> Mike,
> The old behaviour hasn't changed both at the
> ioctl(SG_SCSI_RESET) level and the underlying kernel
> scsi_reset_provider() function. In both cases extra
> values have been added: to third argument of the ioctl
> and the second argument ('flag') of the
> scsi_reset_provider() function. The existing values
> will do exactly the same thing (i.e. escalate) with
> the same return values.
>
> The only way it is different is that values that were
> previously errors (precisely 0x101 to 0x104) now cause a
> non-escalating device(LU)/target/bus reset.
Sorry for the confusion. I should have written is there a way for drivers to tell scsi-ml it only supports the old behavior and does not support the new calls? If not then I am guessing this is mandatory to support and we need to fix the drivers right?
If userspace sends a command that performs the non-escalting *reset to some drivers, it is going to leave them in a state where they may not process IO or will crash.--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
