[Intel-gfx] [PATCH v2] drm/i915/gem: Use GEM context tracking for i915_gem_objects

Chris Wilson chris at chris-wilson.co.uk
Mon Jan 18 11:03:51 UTC 2021

Quoting Tvrtko Ursulin (2021-01-18 10:38:23)
> On 15/01/2021 13:05, Chris Wilson wrote:
> > Rather than take an indirect jump to the drm midlayer (that introduces a
> > use-after-free in reading the ctx->file backpointer) to find all the vma
> > on objects associated with the ctx->file, walk the LUT table stored in
> > the context that tracks all the objects in use with the context.
> > 
> > The improper serialisation with device closure resulting in a
> > use-after-free is a much older issue, we have also introduced a new
> > incorrect list iteration due to commit a4e7ccdac38e ("drm/i915: Move
> > context management under GEM") as the link is no longer guarded by the
> > context's reference context.
> > 
> > Fixes: a4e7ccdac38e ("drm/i915: Move context management under GEM")
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > Cc: CQ Tang <cq.tang at intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi at intel.com>
> > Cc: stable at kernel.org
> Not sure it needs to go to stable since it is only debugfs after all.

I know, but chromeos keeps on hitting bugs in i915_gem_objects.
A quick google only shows the debug capture. Ah, it appeared (once upon
a time, at least) in chrome://system!

> Also, even though it looks fine, given how it is replacing one a bit 
> confusing dump with another, do we really need this data or we could 
> remove it just as well?

I thought per-client was useful at the time, and the overlay tries to
parse it to get the allocations in each context. But that is some
information that I've never focused on and it's utility is
underdeveloped. The binding event tracepoints were more interesting
than overall consumption.

There is a certain appeal to removing it. That would leave just the
number of shrinkable objects being reported.

I think for the moment I'd like to keep client info in there, but I'll
float the alternative patch to remove it for discussion.

More information about the Intel-gfx mailing list