Re: buggy/weird behavior in ttm

[Thomas Hellstrom <thellstrom@vmware.com>]

On 10/12/2012 09:49 AM, Maarten Lankhorst wrote:
>
>>>>> I suppose there will stay a small race though,
>>>> Hmm, where?
>>> When you enter the ddestroy path, you drop the lock and hope the buffer doesn't reserved
>>> away from under you.
>> Yes, that code isn't fully correct, it's missing a check for still on ddestroy after a waiting
>> reserve. However, the only chance of a waiting reserve given that the buffer *IS* on the
>> ddestroy list is if the current reserver returned early because someone started an
>> accelerated eviction which can't happen currently. The code needs fixing up though.
> bo gets put on ddestroy list, delayed destroy handler gets reservation and we try to get a
> reservation at the same time in ttm_mem_evict_first, losing out.
>
> Unlikely? Yes, but I don't see how it is impossible.

Anyone getting the reservation will remove the buffer from the ddestroy 
list atomically,
That means that another caller that finds the buffer on the ddestroy 
list will get the
reservation without wait. The exeption is if *anyone* gets the 
reservation without
removing it from the ddestroy list. That would trigger catastrophic 
failure, but I don't
think that's possible with the current code.

So yes, the code is broken, but I don't think it breaks anything currently.

/Thomas