On 06/29/2015 03:25 PM, Chris Wilson wrote:
On Mon, Jun 29, 2015 at 03:15:12PM +0100, Tvrtko Ursulin wrote:
On 06/29/2015 03:07 PM, Chris Wilson wrote:
On Mon, Jun 29, 2015 at 03:01:12PM +0100, Tvrtko Ursulin wrote:
On 06/29/2015 11:59 AM, Michał Winiarski wrote:
When the the memory backing the userptr object is freed by the user, it's
possible to trigger recursive deadlock caused by operations done on
different BO mapped in that region, triggering invalidate.
Signed-off-by: Michał Winiarski <michal.winiarski@xxxxxxxxx>
---
tests/gem_userptr_blits.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 83 insertions(+)
diff --git a/tests/gem_userptr_blits.c b/tests/gem_userptr_blits.c
index 1f2cc96..3fe8f90 100644
--- a/tests/gem_userptr_blits.c
+++ b/tests/gem_userptr_blits.c
@@ -640,6 +640,80 @@ static void test_forked_access(int fd)
free(ptr2);
}
+static int test_map_fixed_invalidate(int fd, bool overlap)
+{
+ void *ptr;
+ void *map;
+ int i;
+ int num_handles = overlap ? 2 : 1;
+ uint32_t handle[num_handles];
+ uint32_t mmap_handle;
+ struct drm_i915_gem_mmap_gtt mmap_arg;
+
+ igt_assert(posix_memalign(&ptr, PAGE_SIZE, PAGE_SIZE) == 0);
+ for (i=0; i<num_handles; i++)
+ igt_assert(gem_userptr(fd, ptr, PAGE_SIZE, 0, &handle[i]) == 0);
+ free(ptr);
I am not sure we can rely on free triggering munmap(2) here, I think
this is just glibc implementation detail. So I would suggest
allocating with mmap and freeing with munmap.
The MAP_FIXED itself should be sufficient to invalidate any prior vma at
that address, so we don't depend upon the free() here to zap
Yeah, but does the free trigger an invalidate, or does it not? Or in
other words, is the one from MAP_FIXED the first one, or not? Better
to be explicit than undefined in the test case, that was my point.
Yes. But I would prefer MAP_FIXED to be the first invalidate, but that
looks like we then need to leak the ptr.
If it used mmap instead of posix_memalign and no free then what would it
leak? MAP_FIXED would be guaranteed first invalidate and it would
discard the mapping.
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
