* [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_exec: Exercise execution along context while closing it
@ 2020-12-03 9:57 Chris Wilson
2020-12-03 9:59 ` Chris Wilson
0 siblings, 1 reply; 6+ messages in thread
From: Chris Wilson @ 2020-12-03 9:57 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev, Chris Wilson
Race the execution and interrupt handlers along a context, while
closing it at a random time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
tests/i915/gem_ctx_exec.c | 59 +++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/tests/i915/gem_ctx_exec.c b/tests/i915/gem_ctx_exec.c
index 194191def..f885f7fa3 100644
--- a/tests/i915/gem_ctx_exec.c
+++ b/tests/i915/gem_ctx_exec.c
@@ -336,6 +336,62 @@ static void nohangcheck_hostile(int i915)
close(i915);
}
+static void close_race(int i915)
+{
+ const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
+ uint32_t *contexts;
+
+ contexts = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+ igt_assert(contexts != MAP_FAILED);
+
+ for (int child = 0; child < ncpus; child++)
+ contexts[child] = gem_context_clone_with_engines(i915, 0);
+
+ igt_fork(child, ncpus) {
+ igt_spin_t *spin;
+
+ spin = igt_spin_new(i915, .flags = IGT_SPIN_POLL_RUN);
+ igt_spin_end(spin);
+
+ while (!READ_ONCE(contexts[ncpus])) {
+ int64_t timeout = 1;
+
+ igt_spin_reset(spin);
+ igt_assert(!igt_spin_has_started(spin));
+
+ spin->execbuf.rsvd1 = READ_ONCE(contexts[child]);
+ if (__gem_execbuf(i915, &spin->execbuf))
+ continue;
+
+ igt_assert(gem_bo_busy(i915, spin->handle));
+ gem_wait(i915, spin->handle, &timeout); /* prime irq */
+ igt_spin_busywait_until_started(spin);
+
+ igt_spin_end(spin);
+ gem_sync(i915, spin->handle);
+ }
+
+ igt_spin_free(i915, spin);
+ }
+
+ igt_until_timeout(5) {
+ for (int child = 0; child < ncpus; child++) {
+ gem_context_destroy(i915, contexts[child]);
+ contexts[child] =
+ gem_context_clone_with_engines(i915, 0);
+ }
+ usleep(1000);
+ }
+
+ contexts[ncpus] = 1;
+ igt_waitchildren();
+
+ for (int child = 0; child < ncpus; child++)
+ gem_context_destroy(i915, contexts[child]);
+
+ munmap(contexts, 4096);
+}
+
igt_main
{
const uint32_t batch[2] = { 0, MI_BATCH_BUFFER_END };
@@ -380,6 +436,9 @@ igt_main
igt_subtest("basic-nohangcheck")
nohangcheck_hostile(fd);
+ igt_subtest("basic-close-race")
+ close_race(fd);
+
igt_subtest("reset-pin-leak") {
int i;
--
2.29.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 6+ messages in thread* [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_exec: Exercise execution along context while closing it
2020-12-03 9:57 [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_exec: Exercise execution along context while closing it Chris Wilson
@ 2020-12-03 9:59 ` Chris Wilson
2020-12-04 10:52 ` [Intel-gfx] [igt-dev] " Tvrtko Ursulin
2020-12-04 11:27 ` [Intel-gfx] " Chris Wilson
0 siblings, 2 replies; 6+ messages in thread
From: Chris Wilson @ 2020-12-03 9:59 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev, Chris Wilson
Race the execution and interrupt handlers along a context, while
closing it at a random time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
tests/i915/gem_ctx_exec.c | 60 +++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/tests/i915/gem_ctx_exec.c b/tests/i915/gem_ctx_exec.c
index 194191def..18d5d1217 100644
--- a/tests/i915/gem_ctx_exec.c
+++ b/tests/i915/gem_ctx_exec.c
@@ -336,6 +336,63 @@ static void nohangcheck_hostile(int i915)
close(i915);
}
+static void close_race(int i915)
+{
+ const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
+ uint32_t *contexts;
+
+ contexts = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+ igt_assert(contexts != MAP_FAILED);
+
+ for (int child = 0; child < ncpus; child++)
+ contexts[child] = gem_context_clone_with_engines(i915, 0);
+
+ igt_fork(child, ncpus) {
+ igt_spin_t *spin;
+
+ spin = igt_spin_new(i915, .flags = IGT_SPIN_POLL_RUN);
+ igt_spin_end(spin);
+ gem_sync(i915, spin->handle);
+
+ while (!READ_ONCE(contexts[ncpus])) {
+ int64_t timeout = 1;
+
+ igt_spin_reset(spin);
+ igt_assert(!igt_spin_has_started(spin));
+
+ spin->execbuf.rsvd1 = READ_ONCE(contexts[child]);
+ if (__gem_execbuf(i915, &spin->execbuf))
+ continue;
+
+ igt_assert(gem_bo_busy(i915, spin->handle));
+ gem_wait(i915, spin->handle, &timeout); /* prime irq */
+ igt_spin_busywait_until_started(spin);
+
+ igt_spin_end(spin);
+ gem_sync(i915, spin->handle);
+ }
+
+ igt_spin_free(i915, spin);
+ }
+
+ igt_until_timeout(5) {
+ for (int child = 0; child < ncpus; child++) {
+ gem_context_destroy(i915, contexts[child]);
+ contexts[child] =
+ gem_context_clone_with_engines(i915, 0);
+ }
+ usleep(1000);
+ }
+
+ contexts[ncpus] = 1;
+ igt_waitchildren();
+
+ for (int child = 0; child < ncpus; child++)
+ gem_context_destroy(i915, contexts[child]);
+
+ munmap(contexts, 4096);
+}
+
igt_main
{
const uint32_t batch[2] = { 0, MI_BATCH_BUFFER_END };
@@ -380,6 +437,9 @@ igt_main
igt_subtest("basic-nohangcheck")
nohangcheck_hostile(fd);
+ igt_subtest("basic-close-race")
+ close_race(fd);
+
igt_subtest("reset-pin-leak") {
int i;
--
2.29.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_exec: Exercise execution along context while closing it
2020-12-03 9:59 ` Chris Wilson
@ 2020-12-04 10:52 ` Tvrtko Ursulin
2020-12-04 11:13 ` Chris Wilson
2020-12-04 11:27 ` [Intel-gfx] " Chris Wilson
1 sibling, 1 reply; 6+ messages in thread
From: Tvrtko Ursulin @ 2020-12-04 10:52 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: igt-dev
On 03/12/2020 09:59, Chris Wilson wrote:
> Race the execution and interrupt handlers along a context, while
> closing it at a random time.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
> tests/i915/gem_ctx_exec.c | 60 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
>
> diff --git a/tests/i915/gem_ctx_exec.c b/tests/i915/gem_ctx_exec.c
> index 194191def..18d5d1217 100644
> --- a/tests/i915/gem_ctx_exec.c
> +++ b/tests/i915/gem_ctx_exec.c
> @@ -336,6 +336,63 @@ static void nohangcheck_hostile(int i915)
> close(i915);
> }
>
> +static void close_race(int i915)
> +{
> + const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
> + uint32_t *contexts;
> +
> + contexts = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
> + igt_assert(contexts != MAP_FAILED);
> +
> + for (int child = 0; child < ncpus; child++)
> + contexts[child] = gem_context_clone_with_engines(i915, 0);
> +
> + igt_fork(child, ncpus) {
> + igt_spin_t *spin;
> +
> + spin = igt_spin_new(i915, .flags = IGT_SPIN_POLL_RUN);
> + igt_spin_end(spin);
> + gem_sync(i915, spin->handle);
> +
> + while (!READ_ONCE(contexts[ncpus])) {
> + int64_t timeout = 1;
> +
> + igt_spin_reset(spin);
> + igt_assert(!igt_spin_has_started(spin));
> +
> + spin->execbuf.rsvd1 = READ_ONCE(contexts[child]);
> + if (__gem_execbuf(i915, &spin->execbuf))
> + continue;
> +
> + igt_assert(gem_bo_busy(i915, spin->handle));
I've seen this line fail in CI results - any idea how that can happen?
> + gem_wait(i915, spin->handle, &timeout); /* prime irq */
Is this depending on implementation specific behaviour, that we will
leave the irq on after the waiter had exited?
> + igt_spin_busywait_until_started(spin);
> +
> + igt_spin_end(spin);
> + gem_sync(i915, spin->handle);
> + }
> +
> + igt_spin_free(i915, spin);
> + }
> +
> + igt_until_timeout(5) {
> + for (int child = 0; child < ncpus; child++) {
> + gem_context_destroy(i915, contexts[child]);
> + contexts[child] =
> + gem_context_clone_with_engines(i915, 0);
Right so deliberate attempt to occasionally make the child use closed
context. Presumably, well according to the CI results, it does manage to
consistently hit it, which surprises me a bit. A comment here would be good.
> + }
> + usleep(1000);
Maybe add some randomness here? Or even a random busy loop within the
child loop? I haven't looked at the i915 patch yet to know where the
race actually is..
> + }
> +
> + contexts[ncpus] = 1;
> + igt_waitchildren();
> +
> + for (int child = 0; child < ncpus; child++)
> + gem_context_destroy(i915, contexts[child]);
> +
> + munmap(contexts, 4096);
> +}
> +
> igt_main
> {
> const uint32_t batch[2] = { 0, MI_BATCH_BUFFER_END };
> @@ -380,6 +437,9 @@ igt_main
> igt_subtest("basic-nohangcheck")
> nohangcheck_hostile(fd);
>
> + igt_subtest("basic-close-race")
> + close_race(fd);
> +
> igt_subtest("reset-pin-leak") {
> int i;
>
>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_exec: Exercise execution along context while closing it
2020-12-04 10:52 ` [Intel-gfx] [igt-dev] " Tvrtko Ursulin
@ 2020-12-04 11:13 ` Chris Wilson
0 siblings, 0 replies; 6+ messages in thread
From: Chris Wilson @ 2020-12-04 11:13 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx; +Cc: igt-dev
Quoting Tvrtko Ursulin (2020-12-04 10:52:23)
>
> On 03/12/2020 09:59, Chris Wilson wrote:
> > Race the execution and interrupt handlers along a context, while
> > closing it at a random time.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > ---
> > tests/i915/gem_ctx_exec.c | 60 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 60 insertions(+)
> >
> > diff --git a/tests/i915/gem_ctx_exec.c b/tests/i915/gem_ctx_exec.c
> > index 194191def..18d5d1217 100644
> > --- a/tests/i915/gem_ctx_exec.c
> > +++ b/tests/i915/gem_ctx_exec.c
> > @@ -336,6 +336,63 @@ static void nohangcheck_hostile(int i915)
> > close(i915);
> > }
> >
> > +static void close_race(int i915)
> > +{
> > + const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
> > + uint32_t *contexts;
> > +
> > + contexts = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
> > + igt_assert(contexts != MAP_FAILED);
> > +
> > + for (int child = 0; child < ncpus; child++)
> > + contexts[child] = gem_context_clone_with_engines(i915, 0);
> > +
> > + igt_fork(child, ncpus) {
> > + igt_spin_t *spin;
> > +
> > + spin = igt_spin_new(i915, .flags = IGT_SPIN_POLL_RUN);
> > + igt_spin_end(spin);
> > + gem_sync(i915, spin->handle);
> > +
> > + while (!READ_ONCE(contexts[ncpus])) {
> > + int64_t timeout = 1;
> > +
> > + igt_spin_reset(spin);
> > + igt_assert(!igt_spin_has_started(spin));
> > +
> > + spin->execbuf.rsvd1 = READ_ONCE(contexts[child]);
> > + if (__gem_execbuf(i915, &spin->execbuf))
> > + continue;
> > +
> > + igt_assert(gem_bo_busy(i915, spin->handle));
>
> I've seen this line fail in CI results - any idea how that can happen?
Yes. The presumption we have in this test is that if gem_execbuf
succeeds, the request will execute.
However, see
drm/i915/gem: Propagate error from cancelled submit due to context closure
https://patchwork.freedesktop.org/patch/405392/?series=84531&rev=1
we are cancelling the request if we detect the context is closed before
the request is submitted, but still returned success (with an async
error).
I think the test makes a fair assumption, and it's easier than I was
thinking to return the error for the closed context, which makes the
gem_execbuf solid for this race.
> > + gem_wait(i915, spin->handle, &timeout); /* prime irq */
>
> Is this depending on implementation specific behaviour, that we will
> leave the irq on after the waiter had exited?
It's the best I can do. Nothing in the uAPI should ever govern exactly
the HW details.
And since this can be used to trick the machine into locking up under
irq pressure... Maybe not the best.
> > + igt_spin_busywait_until_started(spin);
> > +
> > + igt_spin_end(spin);
> > + gem_sync(i915, spin->handle);
> > + }
> > +
> > + igt_spin_free(i915, spin);
> > + }
> > +
> > + igt_until_timeout(5) {
> > + for (int child = 0; child < ncpus; child++) {
> > + gem_context_destroy(i915, contexts[child]);
> > + contexts[child] =
> > + gem_context_clone_with_engines(i915, 0);
>
> Right so deliberate attempt to occasionally make the child use closed
> context. Presumably, well according to the CI results, it does manage to
> consistently hit it, which surprises me a bit. A comment here would be good.
>
> > + }
> > + usleep(1000);
>
> Maybe add some randomness here? Or even a random busy loop within the
> child loop? I haven't looked at the i915 patch yet to know where the
> race actually is..
The CPU scheduler is great at providing randomness :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_exec: Exercise execution along context while closing it
2020-12-03 9:59 ` Chris Wilson
2020-12-04 10:52 ` [Intel-gfx] [igt-dev] " Tvrtko Ursulin
@ 2020-12-04 11:27 ` Chris Wilson
2020-12-04 13:53 ` [Intel-gfx] [igt-dev] " Tvrtko Ursulin
1 sibling, 1 reply; 6+ messages in thread
From: Chris Wilson @ 2020-12-04 11:27 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev, Chris Wilson
Race the execution and interrupt handlers along a context, while
closing it at a random time.
v2: Some comments to handwave away the knowledge of internal
implementation details.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
tests/i915/gem_ctx_exec.c | 84 +++++++++++++++++++++++++++++++++++++++
1 file changed, 84 insertions(+)
diff --git a/tests/i915/gem_ctx_exec.c b/tests/i915/gem_ctx_exec.c
index 194191def..5c6109237 100644
--- a/tests/i915/gem_ctx_exec.c
+++ b/tests/i915/gem_ctx_exec.c
@@ -43,6 +43,7 @@
#include "i915/gem.h"
#include "igt.h"
#include "igt_dummyload.h"
+#include "igt_rand.h"
#include "igt_sysfs.h"
#include "sw_sync.h"
@@ -336,6 +337,86 @@ static void nohangcheck_hostile(int i915)
close(i915);
}
+static void close_race(int i915)
+{
+ const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
+ uint32_t *contexts;
+
+ contexts = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+ igt_assert(contexts != MAP_FAILED);
+
+ for (int child = 0; child < ncpus; child++)
+ contexts[child] = gem_context_clone_with_engines(i915, 0);
+
+ igt_fork(child, ncpus) {
+ igt_spin_t *spin;
+
+ spin = igt_spin_new(i915, .flags = IGT_SPIN_POLL_RUN);
+ igt_spin_end(spin);
+ gem_sync(i915, spin->handle);
+
+ while (!READ_ONCE(contexts[ncpus])) {
+ int64_t timeout = 1;
+
+ igt_spin_reset(spin);
+ igt_assert(!igt_spin_has_started(spin));
+
+ spin->execbuf.rsvd1 = READ_ONCE(contexts[child]);
+ if (__gem_execbuf(i915, &spin->execbuf))
+ continue;
+
+ /*
+ * One race we are particularly interested in is the
+ * handling of interrupt signaling along a closed
+ * context. We want to see if we can catch the kernel
+ * freeing the context while using it in the interrupt
+ * handler.
+ *
+ * There's no API to mandate that the interrupt is
+ * generate for a wait, nor that the implementation
+ * details of the kernel will not change to remove
+ * context access during interrupt processing. But
+ * for now, this should be interesting.
+ *
+ * Even if the signaling implementation is changed,
+ * racing context closure versus execbuf and looking
+ * at the outcome is very useful.
+ */
+
+ igt_assert(gem_bo_busy(i915, spin->handle));
+ gem_wait(i915, spin->handle, &timeout); /* prime irq */
+ igt_spin_busywait_until_started(spin);
+
+ igt_spin_end(spin);
+ gem_sync(i915, spin->handle);
+ }
+
+ igt_spin_free(i915, spin);
+ }
+
+ igt_until_timeout(5) {
+ /*
+ * Recreate all the contexts while they are in active use
+ * by the children. This may race with any of their ioctls
+ * and the kernel's context/request handling.
+ */
+ for (int child = 0; child < ncpus; child++) {
+ gem_context_destroy(i915, contexts[child]);
+ contexts[child] =
+ gem_context_clone_with_engines(i915, 0);
+ }
+ usleep(1000 + hars_petruska_f54_1_random_unsafe() % 2000);
+ }
+
+ contexts[ncpus] = 1;
+ igt_waitchildren();
+
+ for (int child = 0; child < ncpus; child++)
+ gem_context_destroy(i915, contexts[child]);
+
+ munmap(contexts, 4096);
+}
+
igt_main
{
const uint32_t batch[2] = { 0, MI_BATCH_BUFFER_END };
@@ -380,6 +461,9 @@ igt_main
igt_subtest("basic-nohangcheck")
nohangcheck_hostile(fd);
+ igt_subtest("basic-close-race")
+ close_race(fd);
+
igt_subtest("reset-pin-leak") {
int i;
--
2.29.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_ctx_exec: Exercise execution along context while closing it
2020-12-04 11:27 ` [Intel-gfx] " Chris Wilson
@ 2020-12-04 13:53 ` Tvrtko Ursulin
0 siblings, 0 replies; 6+ messages in thread
From: Tvrtko Ursulin @ 2020-12-04 13:53 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: igt-dev
On 04/12/2020 11:27, Chris Wilson wrote:
> Race the execution and interrupt handlers along a context, while
> closing it at a random time.
>
> v2: Some comments to handwave away the knowledge of internal
> implementation details.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
> tests/i915/gem_ctx_exec.c | 84 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 84 insertions(+)
>
> diff --git a/tests/i915/gem_ctx_exec.c b/tests/i915/gem_ctx_exec.c
> index 194191def..5c6109237 100644
> --- a/tests/i915/gem_ctx_exec.c
> +++ b/tests/i915/gem_ctx_exec.c
> @@ -43,6 +43,7 @@
> #include "i915/gem.h"
> #include "igt.h"
> #include "igt_dummyload.h"
> +#include "igt_rand.h"
> #include "igt_sysfs.h"
> #include "sw_sync.h"
>
> @@ -336,6 +337,86 @@ static void nohangcheck_hostile(int i915)
> close(i915);
> }
>
> +static void close_race(int i915)
> +{
> + const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
> + uint32_t *contexts;
> +
> + contexts = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
> + igt_assert(contexts != MAP_FAILED);
> +
> + for (int child = 0; child < ncpus; child++)
> + contexts[child] = gem_context_clone_with_engines(i915, 0);
> +
> + igt_fork(child, ncpus) {
> + igt_spin_t *spin;
> +
> + spin = igt_spin_new(i915, .flags = IGT_SPIN_POLL_RUN);
> + igt_spin_end(spin);
> + gem_sync(i915, spin->handle);
> +
> + while (!READ_ONCE(contexts[ncpus])) {
> + int64_t timeout = 1;
> +
> + igt_spin_reset(spin);
> + igt_assert(!igt_spin_has_started(spin));
> +
> + spin->execbuf.rsvd1 = READ_ONCE(contexts[child]);
> + if (__gem_execbuf(i915, &spin->execbuf))
> + continue;
> +
> + /*
> + * One race we are particularly interested in is the
> + * handling of interrupt signaling along a closed
> + * context. We want to see if we can catch the kernel
> + * freeing the context while using it in the interrupt
> + * handler.
> + *
> + * There's no API to mandate that the interrupt is
> + * generate for a wait, nor that the implementation
> + * details of the kernel will not change to remove
> + * context access during interrupt processing. But
> + * for now, this should be interesting.
> + *
> + * Even if the signaling implementation is changed,
> + * racing context closure versus execbuf and looking
> + * at the outcome is very useful.
> + */
> +
> + igt_assert(gem_bo_busy(i915, spin->handle));
> + gem_wait(i915, spin->handle, &timeout); /* prime irq */
> + igt_spin_busywait_until_started(spin);
> +
> + igt_spin_end(spin);
> + gem_sync(i915, spin->handle);
> + }
> +
> + igt_spin_free(i915, spin);
> + }
> +
> + igt_until_timeout(5) {
> + /*
> + * Recreate all the contexts while they are in active use
> + * by the children. This may race with any of their ioctls
> + * and the kernel's context/request handling.
> + */
> + for (int child = 0; child < ncpus; child++) {
> + gem_context_destroy(i915, contexts[child]);
> + contexts[child] =
> + gem_context_clone_with_engines(i915, 0);
> + }
> + usleep(1000 + hars_petruska_f54_1_random_unsafe() % 2000);
> + }
> +
> + contexts[ncpus] = 1;
> + igt_waitchildren();
> +
> + for (int child = 0; child < ncpus; child++)
> + gem_context_destroy(i915, contexts[child]);
> +
> + munmap(contexts, 4096);
> +}
> +
> igt_main
> {
> const uint32_t batch[2] = { 0, MI_BATCH_BUFFER_END };
> @@ -380,6 +461,9 @@ igt_main
> igt_subtest("basic-nohangcheck")
> nohangcheck_hostile(fd);
>
> + igt_subtest("basic-close-race")
> + close_race(fd);
> +
> igt_subtest("reset-pin-leak") {
> int i;
>
>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-12-04 13:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-12-03 9:57 [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_exec: Exercise execution along context while closing it Chris Wilson
2020-12-03 9:59 ` Chris Wilson
2020-12-04 10:52 ` [Intel-gfx] [igt-dev] " Tvrtko Ursulin
2020-12-04 11:13 ` Chris Wilson
2020-12-04 11:27 ` [Intel-gfx] " Chris Wilson
2020-12-04 13:53 ` [Intel-gfx] [igt-dev] " Tvrtko Ursulin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox