On 14-10-24 04:51 PM, Christoph Hellwig wrote:
On Tue, Oct 14, 2014 at 12:42:26PM -0400, Douglas Gilbert wrote:
I don't mind if you change it. However I plan to release
sg3_utils-1.40 in the next 2 or 3 weeks, so that would
be the earliest a revised sg_reset would be available for
distros. Improving error reports is something I always
like to do (so ENODEV for the "in progress" case seems a
bit strident).
Doug, are you fine with changing the error code to EAGAIN
similar to what we get elsewhere when a O_NONBLOCK open
would have to block? If that's something you can prepare
sg3_utils for I'd like to send a patch for it for the 3.19 merge
window.
Yes, that's fine.
Just expanded the sg_reset ioctl erorr processing to this:
switch (errno) {
case EBUSY:
fprintf(stderr, ME "BUSY, may be resetting now\n");
break;
case ENODEV:
fprintf(stderr, ME "'no device' error, may be temporary while "
"device is resetting\n");
break;
case EAGAIN:
fprintf(stderr, ME "try again later, may be resetting now\n");
break;
case EIO:
fprintf(stderr, ME "reset (for value=0x%x) may not be "
"available\n", k);
break;
case EPERM:
case EACCES:
fprintf(stderr, ME "reset requires CAP_SYS_ADMIN (root) "
"permission\n");
break;
case EINVAL:
fprintf(stderr, ME "SG_SCSI_RESET not supported (for "
"value=0x%x)\n", k);
default:
perror(ME "SG_SCSI_RESET failed");
break;
}
The ENODEV, EAGAIN and EPERM entries are new. In the sg_reset
implementation currently in the field they will drop down to
the default case and do a perror().
With the ioctl(SG_IO), it is sufficient to give a user permissions
on the device node (e.g. 'chmod 666 /dev/sg2; sg_turs /dev/sg2')
to pass through a command. However with ioctl(SG_SCSI_RESET),
another check is done by the ioctl and if it fails then it yields
EACCES .
Doug Gilbert
--
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
