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
