All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Subject: Re: [BrownBag] drm/i915/gtt: Neuter the deferred unbind callback from gen6_ppgtt_cleanup
Date: Fri, 24 May 2019 09:23:40 +0100	[thread overview]
Message-ID: <784ff780-a9b2-b997-1e4f-ed47f313d280@linux.intel.com> (raw)
In-Reply-To: <155868585422.28319.13611154637326086125@skylake-alporthouse-com>


On 24/05/2019 09:17, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-05-24 09:13:14)
>>
>> On 24/05/2019 07:45, Chris Wilson wrote:
>>> Having deferred the vma destruction to a worker where we can acquire the
>>> struct_mutex, we have to avoid chasing back into the now destroyed
>>> ppgtt. The pd_vma is special in having a custom unbind function to scan
>>> for unused pages despite the VMA itself being notionally part of the
>>> GGTT. As such, we need to disable that callback to avoid a
>>> use-after-free.
>>>
>>> This unfortunately blew up so early during boot that CI declared the
>>> machine unreachable as opposed to being the major failure it was. Oops.
>>>
>>> Fixes: d3622099c76f ("drm/i915/gtt: Always acquire struct_mutex for gen6_ppgtt_cleanup")
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
>>> ---
>>>    drivers/gpu/drm/i915/i915_gem_gtt.c | 28 ++++++++++++++++++++++++++++
>>>    1 file changed, 28 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> index 8d8a4b0ad4d9..266baa11df64 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> @@ -1847,6 +1847,33 @@ static void gen6_ppgtt_cleanup_work(struct work_struct *wrk)
>>>        kfree(work);
>>>    }
>>>    
>>> +static int nop_set_pages(struct i915_vma *vma)
>>> +{
>>> +     return -ENODEV;
>>> +}
>>> +
>>> +static void nop_clear_pages(struct i915_vma *vma)
>>> +{
>>> +}
>>> +
>>> +static int nop_bind(struct i915_vma *vma,
>>> +                 enum i915_cache_level cache_level,
>>> +                 u32 unused)
>>> +{
>>> +     return -ENODEV;
>>> +}
>>> +
>>> +static void nop_unbind(struct i915_vma *vma)
>>> +{
>>> +}
>>> +
>>> +static const struct i915_vma_ops nop_vma_ops = {
>>> +     .set_pages = nop_set_pages,
>>> +     .clear_pages = nop_clear_pages,
>>> +     .bind_vma = nop_bind,
>>> +     .unbind_vma = nop_unbind,
>>> +};
>>> +
>>>    static void gen6_ppgtt_cleanup(struct i915_address_space *vm)
>>>    {
>>>        struct gen6_hw_ppgtt *ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
>>> @@ -1855,6 +1882,7 @@ static void gen6_ppgtt_cleanup(struct i915_address_space *vm)
>>>        /* FIXME remove the struct_mutex to bring the locking under control */
>>>        INIT_WORK(&work->base, gen6_ppgtt_cleanup_work);
>>>        work->vma = ppgtt->vma;
>>> +     work->vma->ops = &nop_vma_ops;
>>
>> Could we use some asserts before overriding the vma ops? Like
>> GEM_BUG_ON(vma->pages)? And something for still bound?
> 
> It technically still is bound as it is in the GGTT but currently
> unpinned -- that will be checked on destroy, it's just we also get an
> unbind callback. vma->pages doesn't exist for this (set to ERR_PTR).

If we are getting the unbind callback and we nop-ed it, who will 
actually do it's job?

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-05-24  8:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-24  6:45 [BrownBag] drm/i915/gtt: Neuter the deferred unbind callback from gen6_ppgtt_cleanup Chris Wilson
2019-05-24  8:13 ` Tvrtko Ursulin
2019-05-24  8:17   ` Chris Wilson
2019-05-24  8:23     ` Tvrtko Ursulin [this message]
2019-05-24  8:29       ` Chris Wilson
2019-05-24  8:31         ` Tvrtko Ursulin
2019-05-24  8:36           ` Chris Wilson
2019-05-24  8:51             ` Tvrtko Ursulin
2019-05-24  8:55               ` Chris Wilson
2019-05-24  8:57               ` Tvrtko Ursulin
2019-05-24  9:01                 ` Chris Wilson
2019-05-24  9:08                   ` Tvrtko Ursulin
2019-05-24  8:31 ` ✗ Fi.CI.BAT: failure for " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=784ff780-a9b2-b997-1e4f-ed47f313d280@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tomi.p.sarvela@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.