Re: [PATCH 0/2] sg: fix races during device removal (v2)

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

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/