Stefan Richter wrote: > Greg KH wrote: > >> On Wed, Jan 14, 2009 at 03:31:15PM -0500, Tony Battersby wrote: >> >>> 4) Add a variation of kref_get() that uses atomic_inc_not_zero(). >>> >> Ick. >> > > I missed the most part of this thread. But in the grandparent post, > Tony wrote: > > >>> Fujita, your patch results in simpler code than my version 2 patch, >>> but it still leaves some subtle races and other problems. The crux >>> of the problem is that kref_put() needs do be done while holding a >>> lock if there is still a way for some other CPU to find a reference >>> to the object in between the time the refcount drops to 0 and the >>> time the destructor is called. >>> > > This sounds bogus to me. If "some other CPU can find a reference to the > object" after the reference count dropped to zero, then the problem is > IMO clear and simple: > > Some site did not increase the refcount when it should. > The original code makes it possible to find the object and get information about it right up until the point that the destructor is called. However, adding a reference just for this purpose would prevent the object from ever being freed. Removing the ability to get information about closed fds or deleted devices that still have outstanding commands changes the user-visible behavior, which I didn't want to do in a patch that is just trying to fix a bunch of oopses. However, if the solution that I have proposed isn't acceptable, then that is exactly what will have to happen. I can live with that if that is the consensus, but I was trying to avoid it. Tony -- 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
