On Thu, Nov 17, 2016 at 10:02:02AM -0500, robert.foss@xxxxxxxxxxxxx wrote: > From: Rafael Antognolli <rafael.antognolli@xxxxxxxxx> > > This test creates an already expired fence, then creates a merged fence > out of that expired one (passed twice to the merge operation), and > finally closes the merged fence. It shows that if the refcounts are > wrong on the original expired fence, it might get freed while still in > use. Usually a kernel panick will follow. > > Signed-off-by: Rafael Antognolli <rafael.antognolli@xxxxxxxxx> > Signed-off-by: Robert Foss <robert.foss@xxxxxxxxxxxxx> > --- > tests/sw_sync.c | 28 ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/tests/sw_sync.c b/tests/sw_sync.c > index 4e52f48..65416ad 100644 > --- a/tests/sw_sync.c > +++ b/tests/sw_sync.c > @@ -582,6 +582,31 @@ static void test_sync_multi_producer_single_consumer(void) > pthread_join(threads[i], NULL); > } > > +static void test_sync_expired_merge(void) > +{ > + int iterations = 1 << 20; > + int timeline; > + int i; > + int fence_expired, fence_merged; > + > + timeline = sw_sync_timeline_create(); > + > + sw_sync_timeline_inc(timeline, 100); > + fence_expired = sw_sync_fence_create(timeline, 1); igt_assert(sync_wait(fence_expired, 0) == 1); or igt_assert(fence_signaled(fence_expired)); Both illustrative of the setup, and tests them. > + fence_merged = sync_merge(fence_expired, fence_expired); > + close(fence_merged); > + > + for (i = 0; i < iterations; i++) { > + int fence = sync_merge(fence_expired, fence_expired); > + > + igt_assert_f(sync_wait(fence, -1) == 0, > + "Failure waiting on fence\n"); > + close(fence); Is the millionth iteration more likely to fail than iteration 0? There's no change in code coverage, so is it worth the extra iterations? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx