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.
Sincerely -- Mark Salyzyn
-
: 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
