From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Intel-gfx@lists.freedesktop.org,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Subject: Re: [PATCH] tests/gem_userptr_blits: Race between object creation and multi-threaded mm ops
Date: Mon, 14 Jul 2014 11:44:26 +0100 [thread overview]
Message-ID: <53C3B48A.2050306@linux.intel.com> (raw)
In-Reply-To: <20140714103416.GB2319@nuc-i3427.alporthouse.com>
On 07/14/2014 11:34 AM, Chris Wilson wrote:
> On Mon, Jul 14, 2014 at 11:03:26AM +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> Userptr v23 was not thread safe against memory map operations and object
>> creation from separate threads. MMU notifier callback would get triggered
>> on a partially constructed object causing a NULL pointer dereference.
>>
>> This test excercises that path a bit. In my testing it would trigger it
>> every time and easily, but unfortunately a test pass here does not guarantee
>> the absence of the race.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> ---
>> tests/Makefile.am | 2 ++
>> tests/gem_userptr_blits.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 56 insertions(+)
>>
>> diff --git a/tests/Makefile.am b/tests/Makefile.am
>> index 2878624..e207509 100644
>> --- a/tests/Makefile.am
>> +++ b/tests/Makefile.am
>> @@ -65,6 +65,8 @@ prime_self_import_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
>> prime_self_import_LDADD = $(LDADD) -lpthread
>> gen7_forcewake_mt_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
>> gen7_forcewake_mt_LDADD = $(LDADD) -lpthread
>> +gem_userptr_blits_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
>> +gem_userptr_blits_LDADD = $(LDADD) -lpthread
>>
>> gem_wait_render_timeout_LDADD = $(LDADD) -lrt
>> kms_flip_LDADD = $(LDADD) -lrt -lpthread
>> diff --git a/tests/gem_userptr_blits.c b/tests/gem_userptr_blits.c
>> index 2eb127f..0213868 100644
>> --- a/tests/gem_userptr_blits.c
>> +++ b/tests/gem_userptr_blits.c
>> @@ -47,6 +47,7 @@
>> #include <sys/time.h>
>> #include <sys/mman.h>
>> #include <signal.h>
>> +#include <pthread.h>
>>
>> #include "drm.h"
>> #include "i915_drm.h"
>> @@ -1107,6 +1108,56 @@ static int test_unmap_cycles(int fd, int expected)
>> return 0;
>> }
>>
>> +static volatile int stop_mm_stress_thread;
>
>> +static void *mm_stress_thread(void *data)
>> +{
>> + void *ptr;
>> + int ret;
>> +
>> + while (!stop_mm_stress_thread) {
>> + ptr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE,
>> + MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
>> + assert(ptr != MAP_FAILED);
>> + ret = munmap(ptr, PAGE_SIZE);
>> + assert(ret == 0);
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +static int test_stress_mm(int fd)
>> +{
>> + int ret;
>> + pthread_t t;
>> + unsigned int loops = 100000;
>> + uint32_t handle;
>> + void *ptr;
>> +
>> + assert(posix_memalign(&ptr, PAGE_SIZE, PAGE_SIZE) == 0);
>> +
>> + ret = pthread_create(&t, NULL, mm_stress_thread, NULL);
>> + assert(ret == 0);
>> +
>> + while (loops--) {
>> + ret = gem_userptr(fd, ptr, PAGE_SIZE, 0, &handle);
>> + assert(ret == 0);
>> +
>> + gem_close(fd, handle);
>> + }
>> +
>> + stop_mm_stress_thread = 1;
>> +
>> + free(ptr);
>> +
>> + ret = pthread_cancel(t);
>
> You don't have any cancellation points in the loop. (mmap may or may not
> be, it is not required to be.)
>
> But rather than use a global, just pass a pointer to a local struct.
It doesn't need both a cancellation point and a flag. Should I just add
pthread_testcancel in the loop and not have any flag at all?
> Oh, and igt_assert. But kill the asserts in mm_stress_thread() first.
Why remove completely? My thinking was to use assert vs igt_assert to
distinguish between assumptions about system behaviour, and igt_assert
for assertions about tested functionality.
Tvrtko
next prev parent reply other threads:[~2014-07-14 10:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-14 10:03 [PATCH] tests/gem_userptr_blits: Race between object creation and multi-threaded mm ops Tvrtko Ursulin
2014-07-14 10:34 ` Chris Wilson
2014-07-14 10:44 ` Tvrtko Ursulin [this message]
2014-07-14 13:07 ` Chris Wilson
2014-07-14 13:13 ` Tvrtko Ursulin
2014-07-14 13:27 ` Chris Wilson
2014-07-18 9:20 ` Gore, Tim
2014-07-18 9:36 ` Tvrtko Ursulin
2014-07-14 13:19 ` Tvrtko Ursulin
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=53C3B48A.2050306@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=chris@chris-wilson.co.uk \
--cc=tvrtko.ursulin@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.