Re: [Intel-gfx] [PATCH] drm/i915: Release ctx->syncobj on final put, not on ctx close

2021-08-10 Thread Daniel Vetter
On Mon, Aug 09, 2021 at 08:47:14PM +0200, Daniel Vetter wrote: > On Sun, Aug 8, 2021 at 2:56 AM Jason Ekstrand wrote: > > > > On August 6, 2021 15:18:59 Daniel Vetter wrote: > > > >> gem context refcounting is another exercise in least locking design it > >> seems, where most things get

Re: [Intel-gfx] [PATCH] drm/i915: Release ctx->syncobj on final put, not on ctx close

2021-08-09 Thread Daniel Vetter
On Sun, Aug 8, 2021 at 2:56 AM Jason Ekstrand wrote: > > On August 6, 2021 15:18:59 Daniel Vetter wrote: > >> gem context refcounting is another exercise in least locking design it >> seems, where most things get destroyed upon context closure (which can >> race with anything really). Only the

Re: [Intel-gfx] [PATCH] drm/i915: Release ctx->syncobj on final put, not on ctx close

2021-08-07 Thread Jason Ekstrand
On August 6, 2021 15:18:59 Daniel Vetter wrote: gem context refcounting is another exercise in least locking design it seems, where most things get destroyed upon context closure (which can race with anything really). Only the actual memory allocation and the locks survive while holding a

[Intel-gfx] [PATCH] drm/i915: Release ctx->syncobj on final put, not on ctx close

2021-08-06 Thread Daniel Vetter
gem context refcounting is another exercise in least locking design it seems, where most things get destroyed upon context closure (which can race with anything really). Only the actual memory allocation and the locks survive while holding a reference. This tripped up Jason when reimplementing