public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Chris Wilson" <chris@chris-wilson.co.uk>,
	"Michał Winiarski" <michal.winiarski@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] tests/gem_userptr_blits: subtests for MAP_FIXED mappings of regular bo
Date: Mon, 29 Jun 2015 15:15:12 +0100	[thread overview]
Message-ID: <559152F0.6030705@linux.intel.com> (raw)
In-Reply-To: <20150629140742.GG15506@nuc-i3427.alporthouse.com>


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

> userptr->pages. In this instance userptr->pages doesn't get populated
> before the MAP_FIXED anyway.

Hmmm... did not even think about that. Why does MAP_FIXED trigger get_pages?

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

  reply	other threads:[~2015-06-29 14:15 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-29 10:59 [PATCH] tests/gem_userptr_blits: subtests for MAP_FIXED mappings of regular bo Michał Winiarski
2015-06-29 11:09 ` [PATCH] drm/i915: Fix userptr deadlock with MAP_FIXED Chris Wilson
2015-06-29 11:17   ` [PATCH v2] " Chris Wilson
2015-06-29 15:57     ` Michał Winiarski
2015-06-30 14:52       ` Tvrtko Ursulin
2015-06-30 15:31         ` [Intel-gfx] " Chris Wilson
2015-06-30 15:47           ` Chris Wilson
2015-06-29 14:01 ` [PATCH] tests/gem_userptr_blits: subtests for MAP_FIXED mappings of regular bo Tvrtko Ursulin
2015-06-29 14:07   ` Chris Wilson
2015-06-29 14:15     ` Tvrtko Ursulin [this message]
2015-06-29 14:25       ` Chris Wilson
2015-06-29 14:56         ` Tvrtko Ursulin
2015-06-29 15:03           ` Chris Wilson
2015-06-30 15:01 ` [PATCH v2] tests/gem_userptr_blits: subtests for MAP_FIXED mappings of regular BO Michał Winiarski
2015-06-30 16:55   ` [PATCH 1/3] drm/i915: Only update the current userptr worker Chris Wilson
2015-06-30 16:55     ` [PATCH 2/3] drm/i915: Fix userptr deadlock with MAP_FIXED Chris Wilson
2015-07-01 11:14       ` Tvrtko Ursulin
2015-07-01 11:29         ` [Intel-gfx] " Chris Wilson
2015-06-30 16:55     ` [PATCH 3/3] drm/i915: Use a task to cancel the userptr on invalidate_range Chris Wilson
2015-07-01 12:56       ` Tvrtko Ursulin
2015-07-03 11:00         ` Chris Wilson
2015-07-02 16:40       ` shuang.he
2015-07-03 11:03       ` [PATCH] " Chris Wilson
2015-07-01  9:48     ` [PATCH 1/3] drm/i915: Only update the current userptr worker Tvrtko Ursulin
2015-07-01  9:59       ` Chris Wilson
2015-07-01 10:58         ` Tvrtko Ursulin
2015-07-01 11:09           ` Chris Wilson
2015-07-01 12:26             ` Tvrtko Ursulin
2015-07-01 13:11               ` Chris Wilson
2015-07-03 10:48     ` Michał Winiarski
2015-07-03 10:53       ` Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=559152F0.6030705@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michal.winiarski@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox