Re: [PATCH] SG_SCSI_RESET ioctl: add no_escalate values

2013-02-15 Thread Jeremy Linton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/15/2013 1: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.

Looks good, I will apply it here and try it out.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRHpCDAAoJEL5i86xrzcy7lvoIAK5pxe8rdx8WinxG/NqhLkRb
+537Ln3asshkWcH385gaa1JzizoWhiS1+H+tGcLdEwPDwvSSGGqtUAn/qtxB64cM
F5X0XqjS/XVup7GrkcoQ4ZzXG2rdI6Lb5gwbpb98QeCGzaVKfRMvJCCtXSIFuPXA
S7gL0Xl5d5KapPCWVRpucE05XVaAZq2vrxC3/8hDwB8+3HYUW4gUTcwSAM0pvcUb
d7w984jlcFHVxT3Yk+ZHuQ3QOKifbqWBE9WlsgqkPnGjlAK8Q19NQsD6/C9Q9wTg
OhMjj9HKHOlcBE65e/xKlcncTXjaa1qcLfa94hOukjSQBkf0vqJH3XeWuACESE0=
=Oqr2
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] SG_SCSI_RESET ioctl: add no_escalate values

2013-02-15 Thread Mike Christie
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 dgilb...@interlog.com

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?
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] SG_SCSI_RESET ioctl: add no_escalate values

2013-02-15 Thread Douglas Gilbert

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 dgilb...@interlog.com


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.

Doug Gilbert


--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] SG_SCSI_RESET ioctl: add no_escalate values

2013-02-15 Thread Michael Christie

On Feb 15, 2013, at 5:32 PM, Douglas Gilbert dgilb...@interlog.com 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 dgilb...@interlog.com
 
 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] SG_SCSI_RESET ioctl: add no_escalate values

2013-02-15 Thread Michael Christie

On Feb 15, 2013, at 11:45 PM, Michael Christie micha...@cs.wisc.edu wrote:
 Some drivers rely on more invasive eh callbacks to be called if they
 return FAILED in a eh callbacks.


 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.

Actually, I take those 2 comments back. I think it is just some drivers abort 
callbacks that might be issues, so we should be safe. I did not look at all 
drivers though.--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html