On Tue, 14 Jun 2005, James Bottomley wrote: > On Tue, 2005-06-14 at 17:27 -0400, Alan Stern wrote: > > Can you or anyone else please explain what scsi_target_reap() and > > especially what scsi_target.reap_ref are for? What's the point of this > > home-brewed reference counting scheme when there's already a perfectly > > useful embedded struct device inside scsi_target? Why isn't > > scsi_target_reap() simply the release routine for the embedded device? > > Look at how scsi_target_reap works: it's the decider for visibility > removal, not actual release, that's why we can't use the device > reference, which is the decider for release. I could have used a kref, > but, given the special locking conventions and the tying to the __target > list, the call would have had to be wrappered anyway, so there didn't > seem to to be much point. > > A target is basically a self destroying entity which is why the > complexity. > __target entries are removed when the target goes invisible (and for > this to happen, all the devices have to be already gone). __devices > when the device is released. This means that scsi_target_reap can be called and the __targets list changed essentially at any time (subject only to the host_lock). Hence it is impossible for scsi_forget_host to iterate through the list of targets belonging to the host: While it is working to remove one target, the next target on the list (stored in the tmp variable) might be removed by another thread. In fact there doesn't seem to be any safe way to remove all the targets from a host. And what's to prevent scsi_target_reap being called twice for the same target? 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
