The problem is, breaking out of the shost_for_each_device requires a put on the device and we can no longer use it as an argument to scsi_remove_device. And if we decided to do so, what other race condition are we going to trigger? Sincerely -- Mark Salyzyn -----Original Message----- From: Mark Haverkamp [mailto:markh@xxxxxxxx] Sent: Monday, September 19, 2005 1:57 PM To: Salyzyn, Mark Cc: James Bottomley; Christoph Hellwig; linux-scsi Subject: RE: [PATCH 3/8] aacraid: handle AIF hotplug events 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
