Op 30-11-12 10:04, Thomas Hellstrom schreef: > On 11/30/2012 09:05 AM, Maarten Lankhorst wrote: >> Just use the return error from ttm_mem_evict_first instead. >> >> Changes since v1: >> - Add warning if list is not empty, nothing else we can do here. > > Marten, when this function is called, all cross-device reservers have been > shut out with the TTM lock or whatever similar > mechanism is in place. It's a critical function that must succeed, unless > there is a hardware failure to evict. > > As mentioned in the comments on the previous patch, ttm_bo_evict_first() may > return 0 (OK) if it failed to reclaim the > trylock in cleanup_refs_and_unlock(), with the assumption that another > process will destroy the bo anyway > (possibly at a later time which we know nothing about). The lru list needs to > be empty when this function returns. > > This means we must either keep the while(list_empty) or perhaps better, retry > instead of WARN if list_empty() is detected at the end of list. As long as evict_first returns 0, that function is called over and over again.
But regarding the race.. Even if in this case it returns 0 early, that bo would no longer be on the lru list anyway, since I always take the reservation with lru lock held in the cleanup code, so either this is a cross-device reservation (needs more thought on how to handle that correctly), or that other function is inside the cleanup_memtype_use function, and has already taken the bo off all lists before dropping lru lock. Now it may seem that blocking on reservation can help in this case, maybe it would, but it doesn't close the race entirely..If another function also called ttm_bo_cleanup_refs_and_unlock from another context BEFORE ttm_mem_evict_first was called, at the time ttm_mem_evict_first gets the lru lock the buffer was already taken off the lru lists, and evict_first wouldn't know anything about it and return -EBUSY too. But the lru list is still empty in any of those cases, so the WARN wouldn't trigger.. ~Maarten
