On Fri, 13 Dec 2013, James Bottomley wrote: > > Sorry, but you're wrong. starget->reap_ref is _not_ incremented every > > time we add a device to the target. That's one of the things we need to > > fix. > > Well, then we would have a pretty astonishing cockup in the code. The > found case of scsi_alloc_target increments the reference each time it's > called, so scsi_add_device() definitely behaves like this. You forgot that __scsi_add_device() calls scsi_target_reap() at the end. So the reference count is incremented and then decremented again. It's easy enough to check that the scsi_probe_and_add_lun pathway doesn't elevate the refcount. Print out the value of starget->reap_ref just after __scsi_add_device() calls scsi_alloc_target() and just before it calls scsi_target_reap(). > I suppose > it's possible the list_empty() check is covering a miscount in some of > the other probing routines, but that would mean we have stale targets > for a lot of our use cases. I'll audit the code. That's probably right; whenever a target has more than one LUN we must end up leaking the target. In the common case of one LUN it works out, because the list is empty by the time the scsi_device is released. Alan Stern -- To unsubscribe from this list: 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
