On Tue, Jun 30, 2015 at 03:52:52PM +0100, Tvrtko Ursulin wrote: > I think this deadlock is reproducible without MAP_FIXED, so commit > message should be probably reworded to allow for the more generic > case. Ok, but it is still aliasing the address range, MAP_FIXED is the easiest way to demonstrate that. > I reproduced it like this: > > 1. mmap, gem_userptr, munmap > 2. Create a normal bo. > 3. Loop a bit mmapping the above until it hits the same address as userptr. > 4. Write to the BO mmap to set fault_mappable. > 5. set_tiling on normal bo handle. > > I am still thinking about this active flag in the above scenario. > > userptr->get_pages hasn't been called above so active == false. If > between steps 4 and 5 we trigger get_pages, userptr transitions to > active and set_tiling deadlocks. Or I still missing something? That suggests MAP_FIXED is special in invalidating the range unlike a normal mmap(). This is arguing that we must always make any access after invalidate_range be EFAULT. The danger here is that I am not sure if there are any circumstances where invalidate_range is called and the vma survives. Looking again at mm/, I can't see any place where we can legally be expecting to reuse the same address for a userptr after the invalidate. I'm sure you have a testcase waiting for igt :) -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html