Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Dave Airlie <airlied@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	john.c.harrison@intel.com
Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915: Do not define vma on stack
Date: Tue, 14 Sep 2021 08:36:56 -0700	[thread overview]
Message-ID: <20210914153656.GA23874@jons-linux-dev-box> (raw)
In-Reply-To: <CAPM=9tzHmYkf_y2W_1TO2MPeohFQ9MzkTD1s0gmpNgLcWbX1NA@mail.gmail.com>

On Tue, Sep 14, 2021 at 03:04:59PM +1000, Dave Airlie wrote:
> On Tue, 14 Sept 2021 at 14:55, Matthew Brost <matthew.brost@intel.com> wrote:
> >
> > From: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
> >
> > Defining vma on stack can cause stack overflow, if
> > vma gets populated with new fields.
> 
> Is there some higher level locking stopping that from getting trashed?
> or a guarantee that uc_fw_bind_ggtt is only entered by one thread at a
> time?
> 

I believe this function is only called during driver load (inherently
one thread) or during a GT reset (protected by reset mutex) so at most 1
thread can be executing this code at once, thus it is safe to use a
global dummy vma in this function.

Matt

> Dave.
> 
> >
> > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> >  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 18 +++++++++---------
> >  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |  2 ++
> >  2 files changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> > index 3a16d08608a5..f632dbd32b42 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> > @@ -413,20 +413,20 @@ static void uc_fw_bind_ggtt(struct intel_uc_fw *uc_fw)
> >  {
> >         struct drm_i915_gem_object *obj = uc_fw->obj;
> >         struct i915_ggtt *ggtt = __uc_fw_to_gt(uc_fw)->ggtt;
> > -       struct i915_vma dummy = {
> > -               .node.start = uc_fw_ggtt_offset(uc_fw),
> > -               .node.size = obj->base.size,
> > -               .pages = obj->mm.pages,
> > -               .vm = &ggtt->vm,
> > -       };
> > +       struct i915_vma *dummy = &uc_fw->dummy;
> > +
> > +       dummy->node.start = uc_fw_ggtt_offset(uc_fw);
> > +       dummy->node.size = obj->base.size;
> > +       dummy->pages = obj->mm.pages;
> > +       dummy->vm = &ggtt->vm;
> >
> >         GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
> > -       GEM_BUG_ON(dummy.node.size > ggtt->uc_fw.size);
> > +       GEM_BUG_ON(dummy->node.size > ggtt->uc_fw.size);
> >
> >         /* uc_fw->obj cache domains were not controlled across suspend */
> > -       drm_clflush_sg(dummy.pages);
> > +       drm_clflush_sg(dummy->pages);
> >
> > -       ggtt->vm.insert_entries(&ggtt->vm, &dummy, I915_CACHE_NONE, 0);
> > +       ggtt->vm.insert_entries(&ggtt->vm, dummy, I915_CACHE_NONE, 0);
> >  }
> >
> >  static void uc_fw_unbind_ggtt(struct intel_uc_fw *uc_fw)
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
> > index 99bb1fe1af66..693cc0ebcd63 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
> > @@ -10,6 +10,7 @@
> >  #include "intel_uc_fw_abi.h"
> >  #include "intel_device_info.h"
> >  #include "i915_gem.h"
> > +#include "i915_vma.h"
> >
> >  struct drm_printer;
> >  struct drm_i915_private;
> > @@ -75,6 +76,7 @@ struct intel_uc_fw {
> >         bool user_overridden;
> >         size_t size;
> >         struct drm_i915_gem_object *obj;
> > +       struct i915_vma dummy;
> >
> >         /*
> >          * The firmware build process will generate a version header file with major and
> > --
> > 2.32.0
> >

  reply	other threads:[~2021-09-14 15:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-14  4:49 [Intel-gfx] [PATCH 0/5] Enable GuC submission by default on DG1 Matthew Brost
2021-09-14  4:49 ` [Intel-gfx] [PATCH 1/5] drm/i915: Do not define vma on stack Matthew Brost
2021-09-14  5:04   ` Dave Airlie
2021-09-14 15:36     ` Matthew Brost [this message]
2021-09-14 20:05       ` Daniel Vetter
2021-09-14 21:10         ` Matthew Brost
2021-09-17 12:31           ` Daniel Vetter
2021-09-14  4:49 ` [Intel-gfx] [PATCH 2/5] drm/i915/guc: put all guc objects in lmem when available Matthew Brost
2021-09-14  4:49 ` [Intel-gfx] [PATCH 3/5] drm/i915/guc: Add DG1 GuC / HuC firmware defs Matthew Brost
2021-09-14  4:49 ` [Intel-gfx] [PATCH 4/5] drm/i915/guc: Enable GuC submission by default on DG1 Matthew Brost
2021-09-14  4:49 ` [Intel-gfx] [PATCH 5/5] drm/i915/guc: Use i915_gem_object_is_lmem in i915_gem_object_is_lmem Matthew Brost
2021-09-14  5:35 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable GuC submission by default on DG1 (rev5) Patchwork
2021-09-14  6:01 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-09-14 16:00 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable GuC submission by default on DG1 (rev6) Patchwork
2021-09-14 16:24 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2021-09-16 16:28 [Intel-gfx] [PATCH 0/5] Enable GuC submission by default on DG1 Matthew Brost
2021-09-16 16:28 ` [Intel-gfx] [PATCH 1/5] drm/i915: Do not define vma on stack Matthew Brost

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=20210914153656.GA23874@jons-linux-dev-box \
    --to=matthew.brost@intel.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=john.c.harrison@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox