Mike:
In your first patch, you don't allow transitions from SHOST_RECOVERY to
SHOST_CANCEL nor the other way around. So this section of the patch looks
suspicious:
@@ -60,12 +136,11 @@ static void scsi_host_cancel(struct Scsi
{
struct scsi_device *sdev;
- set_bit(SHOST_CANCEL, &shost->shost_state);
+ scsi_host_set_state(shost, SHOST_CANCEL);
shost_for_each_device(sdev, shost) {
scsi_device_cancel(sdev, recovery);
}
- wait_event(shost->host_wait, (!test_bit(SHOST_RECOVERY,
- &shost->shost_state)));
+ wait_event(shost->host_wait, (shost->shost_state != SHOST_RECOVERY));
}
In fact there are lots of places in the patch where scsi_host_set_state
is called and the return value is not checked. They may end up causing
trouble.
Also, is it a good idea to allow write access to the shost_state
attribute? For debugging, yes, okay, but in general it doesn't seem like
a good thing.
Alan Stern
-
: 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
