[Intel-gfx] [PATCH] tests/gem_userptr_blits: Race between object creation and multi-threaded mm ops
Chris Wilson
chris at chris-wilson.co.uk
Mon Jul 14 15:27:37 CEST 2014
On Mon, Jul 14, 2014 at 02:13:22PM +0100, Tvrtko Ursulin wrote:
> On 07/14/2014 02:07 PM, Chris Wilson wrote:
> >>>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?
> >
> >testcancel also neatly avoids the handwavely lack of mb().
>
> Barrier for what? But it doesn't matter, I'll re-spin with testcancel.
It just makes an assumption that the compiler and processor don't skip
the read. Since it so simple to be pedagolically correct, it seems
pointless to leave it using volatile.
> >>>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.
> >
> >If the assert fires you make the igt test runner angry. Might as well
> >report a test failure rather than break down completely.
>
> I am not familiar with the test runner, but if it cannot handle a
> test failing in a way other than it expects it so it deserves to be
> angry. :) But OK, I'll change it.
Actualy the SIGABRT will be delivered to the thread so you just get an
ugly assert and a PASS if you do not propagate the failure...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list