James Bottomley wrote: >> > scsi_add_device() returns an sdev on >> > success with the refcount bumped up for you. If you don't do a put, >> > you'll be stuck with a device you can't get rid of. >> > >> > However, all other users of scsi_add_device() make the same mistake ... [...] >> > I'll apply this patch and fix the API to return zero or error and not >> > bump the sdev refcount. [...] > I've cc'd you on the patch (and it fixes sbp2 as it currently stands in > the Linus tree, but it would conflict with the fix you have pending). I was just trying to adapt that fix and stumbled upon potential problems of my code. Two questions: 1. Is the following sequence safe? [connect to device] sdev = __scsi_add_device(); scsi_device_put(sdev); store sdev in sbp2's private data for later use [sbp2 .remove hook] scsi_remove_device(sdev); 2. Is this safe? [connect to device] sdev = __scsi_add_device(); scsi_device_put(sdev); [sbp2 .remove hook] scsi_remove_host(shost); I ask because scsi_remove_host will implicitly remove the device too. BTW, the following won't work: [connect to device] sdev = __scsi_add_device(); store sdev for later use [sbp2 .remove hook] scsi_remove_device(sdev); scsi_device_put(sdev); That way, "modprobe -r sbp2" would fail because sbp2 is "in use" until scsi_device_put. Thanks for advice, -- Stefan Richter -=====-=-=-= =--= -=-=- http://arcgraph.de/sr/ - : 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
