Tony Battersby wrote: > Stefan Richter wrote: >> 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. No, why? There is a list or idr with pointers to your objects? As long as the list contains a pointer to object A, this list needs to own one reference count to A. Right after A was deregistered from the list, A's reference count is decremented on behalf of the list. If some site looks objects up in that list and uses the objects, it increases the refcount of such an object while it accesses the list. When done with the object, it decrements the object's refcount on this site's behalf. Eventually, some site will have been the last one to put away a pointer to the object. Then, and only then, the kref goes down to zero and the destructor is executed. > Removing the ability to get > information about closed fds or deleted devices that still have > outstanding commands changes the user-visible behavior, I'm not saying you are to remove such an ability; I'm just saying that as long as any site is ably to get to an object, the refcount of the object can't be zero. Bring it down to zero _after_ you made the object invisible to others. -- Stefan Richter -=====-==--= ---= -==== http://arcgraph.de/sr/ -- 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
