On Tue, 2005-07-26 at 10:27 -0400, Alan Stern wrote: > This patch (as545) fixes the list traversals in __scsi_remove_target and > scsi_forget_host. In each case the existing code list_for_each_entry_safe > in an _unsafe_ manner, because the list was not protected from outside > modification while the iteration was running. Yes, but all you're doing is trying to close a race between add and remove by trying the remove until there's nothing left. That still won't close the race window. The solution is to enforce the state model: Once the host goes into cancel or del, no further additions may be made to the host list and if we add the other patch to enforce the state model on removal then only one process could be in remove as well. > The new scsi_forget_host routine takes the moderately controversial step > of iterating over devices for removal rather than iterating over targets. > This makes more sense to me because the current scheme treats targets as > second-class citizens, created and removed on demand, rather than as > objects corresponding to actual hardware. (Also I couldn't figure out any > safe way to iterate over the target list, since it's not so easy to tell > when a target has already been removed.) Actually, in doing that, the target now never gets reaped, which would leave us with dangling target objects. James - : 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
