[igt-dev] [PATCH i-g-t] i915: Exercise I915_CONTEXT_PARAM_RINGSIZE

[Chris Wilson]

Quoting Janusz Krzysztofik (2020-02-21 13:57:26)
> Hi Chris,
> 
> On Friday, February 21, 2020 10:43:21 AM CET Chris Wilson wrote:
> > +static unsigned int measure_inflight(int i915, unsigned int engine, int timeout)
> > +{
> > +     IGT_CORK_FENCE(cork);
> > +     struct drm_i915_gem_exec_object2 obj = {
> > +             .handle = batch_create(i915)
> > +     };
> > +     struct drm_i915_gem_execbuffer2 execbuf = {
> > +             .buffers_ptr = to_user_pointer(&obj),
> > +             .buffer_count = 1,
> > +             .flags = engine | I915_EXEC_FENCE_IN,
> > +             .rsvd2 = igt_cork_plug(&cork, i915),
> > +     };
> > +     unsigned int count;
> > +     int err;
> > +
> > +     fcntl(i915, F_SETFL, fcntl(i915, F_GETFL) | O_NONBLOCK);
> > +     igt_set_timeout(timeout, "execbuf blocked!");
> > +
> > +     gem_execbuf(i915, &execbuf);
> > +     for (count = 1; (err = __execbuf(i915, &execbuf)) == 0; count++)
> > +             ;
> > +     igt_assert_eq(err, -EWOULDBLOCK);
> > +     close(execbuf.rsvd2);
> > +
> > +     igt_reset_timeout();
> 
> Why not right after the 'for' loop is exited?  Don't we unnecessarily risk 
> a race condition?

Just style, I like the grouping of the extended gem_execbuf() into a
single visual block. Either way it's a few instructions, negligible in
the grand scheme of unserialised code. We need a considerable safety
factor in any case, and yet small enough that we don't accidentally pass
with a random hangcheck.
-Chris