[Intel-gfx] [PATCH] drm/i915/gem: Delay tracking the GEM context until it is registered
Mika Kuoppala
mika.kuoppala at linux.intel.com
Fri Jul 24 12:31:00 UTC 2020
Chris Wilson <chris at chris-wilson.co.uk> writes:
> Quoting Mika Kuoppala (2020-07-24 12:55:39)
>> Chris Wilson <chris at chris-wilson.co.uk> writes:
>>
>> > Quoting Chris Wilson (2020-07-23 19:33:48)
>> >> Avoid exposing a partially constructed context by deferring the
>> >> list_add() from the initial construction to the end of registration.
>> >> Otherwise, if we peek into the list of contexts from inside debugfs, we
>> >> may see the partially constructed context and change down some dangling
>> >
>> > s/change/chase/
>>
>> that.
>>
>> Are you sure about the fixes as it is not the commit that
>> actually introduces the registration into context.list?
>>
>> For me it looks like it is a4e7ccdac38e.
>
> The one I picked was where we started adding more context setup after
> the final step of list_add in __create_context(). More apropos would be
> 3aa9945a528e ("drm/i915: Separate GEM context construction and registration to userspace")
> in the same kernel.
Ok, thanks for clearing that out.
The i915_perf iteration seems to not get hurt either so,
Reviewed-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>
>
> In the other direction, we have
> f6e8aa387171 ("drm/i915: Report the number of closed vma held by each context in debugfs")
> where we start using the contexts.list in debugfs.
>
> In a4e7ccdac38e we are only moving the list_add(&ctx->link) around in
> __create_context().
> -Chris
More information about the Intel-gfx
mailing list