[Intel-gfx] [PATCH v2] drm/i915: Fix userptr deadlock with MAP_FIXED

Chris Wilson chris at chris-wilson.co.uk
Tue Jun 30 08:31:15 PDT 2015


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


More information about the Intel-gfx mailing list