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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
