Re: [PATCH] tests/gem_userptr_blits: subtests for MAP_FIXED mappings of regular bo

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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@intel.com>
> ---
>   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.

> +
> +	mmap_handle = gem_create(fd, PAGE_SIZE);
> +
> +	memset(&mmap_arg, 0, sizeof(mmap_arg));
> +	mmap_arg.handle = mmap_handle;
> +	do_ioctl(fd, DRM_IOCTL_I915_GEM_MMAP_GTT, &mmap_arg);
> +	map = mmap(ptr, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED,
> +			fd, mmap_arg.offset);
> +	igt_assert(map != MAP_FAILED);
> +
> +	*(uint32_t*)map = 0xdead;
> +	gem_set_tiling(fd, mmap_handle, 2, 512 * 4);
> +	munmap(map, PAGE_SIZE);
> +
> +	for (i=0; i<num_handles; i++)
> +		gem_close(fd, handle[i]);
> +
> +	return 0;
> +}
> +
> +static int test_map_fixed_partial_overlap(int fd)
> +{
> +	void *ptr;
> +	void *map;
> +	uint32_t handle;
> +	uint32_t mmap_handle;
> +	struct drm_i915_gem_mmap_gtt mmap_arg;
> +	struct drm_i915_gem_set_domain set_domain;
> +
> +	igt_assert(posix_memalign(&ptr, PAGE_SIZE, sizeof(linear)) == 0);
> +	handle = create_userptr(fd, 0, ptr);
> +	copy(fd, handle, handle, 0);
> +
> +	mmap_handle = gem_create(fd, PAGE_SIZE);
> +
> +	memset(&mmap_arg, 0, sizeof(mmap_arg));
> +	mmap_arg.handle = mmap_handle;
> +	do_ioctl(fd, DRM_IOCTL_I915_GEM_MMAP_GTT, &mmap_arg);
> +	map = mmap(ptr, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED,
> +			fd, mmap_arg.offset);
> +	igt_assert(map != MAP_FAILED);
> +
> +	*(uint32_t*)map = 0xdead;
> +
> +	memset(&set_domain, 0, sizeof(set_domain));
> +	set_domain.handle = handle;
> +	set_domain.read_domains = I915_GEM_DOMAIN_GTT;
> +	set_domain.write_domain = I915_GEM_DOMAIN_GTT;
> +	igt_assert((drmIoctl(fd, DRM_IOCTL_I915_GEM_SET_DOMAIN, &set_domain) != 0) &&
> +			errno == EFAULT);
> +
> +	free(ptr);
> +	munmap(map, PAGE_SIZE);
> +
> +	gem_close(fd, handle);
> +	gem_close(fd, mmap_handle);
> +
> +	return 0;
> +}
> +
>   static int test_forbidden_ops(int fd)
>   {
>   	struct drm_i915_gem_pread gem_pread;
> @@ -1489,6 +1563,15 @@ int main(int argc, char **argv)
>   	igt_subtest("stress-mm-invalidate-close-overlap")
>   		test_invalidate_close_race(fd, true);
>
> +	igt_subtest("map-fixed-invalidate")
> +		test_map_fixed_invalidate(fd, false);
> +
> +	igt_subtest("map-fixed-invalidate-overlap")
> +		test_map_fixed_invalidate(fd, true);
> +
> +	igt_subtest("map-fixed-partial-overlap")
> +		test_map_fixed_partial_overlap(fd);
> +

It is a bit confusing how overlap means two different things between 
subtests. In one it is two userptr objects that are overlapping and in 
another it is the mmap of a normal GEM bo overlapping the userptr range. 
I mean, in all subtests mmap always overlap the userptr.

Also, should there be a subtest which mmaps the userptr bo itself with 
MAP_FIXED, to the same or overlapping range?


Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx