On Mon, 2005-09-19 at 13:28 -0400, Salyzyn, Mark wrote:
> The construct:
>
> shost_for_each_device(device, dev->scsi_host_ptr) {
> if (!(the_device_that_is_to_be_changed))
> continue;
> . . .
> switch (device_config_needed) {
> . . .
> case DELETE:
> scsi_remove_device(device);
> break;
> }
> }
>
> Under intensive testing by an OEM client is proving to be 'unstable'.
> Apparently the expectation of locking/usage count that is part of the
> shost_for_each_device() call is not immune to the call to
> scsi_remove_device() and can cause a panic in __scsi_iterate_devices ()
> in 1 out of between 100 to 1000 tries.
>
> Any suggestions? Pulling scsi_remove_device call(s) out of the loop only
> serves to open up a race condition. This patch has yet to migrate into
> scsi-misc-2.6, probably wise to hold off until the root cause can be
> dealt with.
It looks like you only want to process one device. Wouldn't you want to
break out of the shost_for_each_device after processing the
scsi_remove_device? That way __scsi_iterate_devices() wouldn't get
called again after the device removal.
shost_for_each_device() {
if ()
continue;
switch () {
case DELETE:
scsi_remove_device();
break;
}
break;
}
--
Mark Haverkamp <markh@xxxxxxxx>
-
: 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
