intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>,
	Oscar Mateo <oscar.mateo@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/guc: Add onion teardown to the GuC setup
Date: Mon, 20 Feb 2017 12:39:59 +0200	[thread overview]
Message-ID: <1487587199.3454.23.camel@linux.intel.com> (raw)
In-Reply-To: <26795911-b14f-bd35-841e-75549c312f95@intel.com>

On pe, 2017-02-17 at 15:06 -0800, Daniele Ceraolo Spurio wrote:
> 
> On 16/02/17 06:18, Oscar Mateo wrote:
> > 
> > Starting with intel_guc_loader, down to intel_guc_submission
> > and finally to intel_guc_log.
> > 
> > Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>

<SNIP>

> > @@ -835,14 +841,11 @@ static void guc_addon_create(struct intel_guc *guc)
> >  			sizeof(struct guc_mmio_reg_state) +
> >  			GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE;
> > 
> > -	vma = guc->ads_vma;
> > -	if (!vma) {
> 
> I believe the if was here to avoid re-allocating the vma if this 
> function was called after a GPU reset. I agree that the check should be 
> outside this function (and it already is), but we might want to still 
> add here something like:
> 
> 	if (WARN_ON(guc->ads_vma))
> 		return 0;

GEM_BUG_ON(guc->ads_vma); and then make sure we have sufficient
I-G-T/selftest coverage.

> > +void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
> > +{
> > +	struct intel_guc *guc = &dev_priv->guc;
> > +
> 
> if I'm not missing anything, this function is called from 
> intel_guc_fini(), which can in turn be called from the onion unwinding 
> of i915_load_modeset_init() before intel_guc_init() is ever called, so 
> we need to either fix that unwinding or add some kind of guard here.

Proper unwinding to the rescue!

<SNIP>

> > +int intel_guc_log_create(struct intel_guc *guc)
> > +{
> > +	struct i915_vma *vma;
> > +	unsigned long offset;
> > +	uint32_t size, flags;
> > +	int ret;
> > +
> 
> If we expect this to not be called if the log already exists, for safety 
> we could add something like:
> 
> 	if (WARN_ON(guc->log.vma))
> 		return 0;
> 
> To make sure we don't mess this up if we keep the object alive across 
> resets.

GEM_BUG_ON(guc->log.vma);

> > @@ -653,6 +663,7 @@ void i915_guc_log_unregister(struct drm_i915_private *dev_priv)
> >  		return;
> > 
> >  	mutex_lock(&dev_priv->drm.struct_mutex);
> > -	guc_log_cleanup(&dev_priv->guc);
> > +	gen9_disable_guc_interrupts(dev_priv);
> > +	intel_guc_log_destroy(&dev_priv->guc);
> 
> OCD nitpick: i915_guc_log_unregister is not simmetric with 
> i915_guc_log_register after this change, because intel_guc_log_destroy() 
> is destroying the vma, which was not created by guc_log_late_setup().

Yeah, destroy should be hoisted to calling function. And not so much
OCD, this is what we get double-free errors for all the time :)

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-02-20 10:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-09 10:24 [PATCH] drm/i915/guc: In the submission cleanup, do not bail out if there is no execbuf_client Oscar Mateo
2017-02-09 19:22 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-02-10 12:04 ` [PATCH] " Chris Wilson
2017-02-13 15:55   ` Oscar Mateo
2017-02-14 14:20     ` Joonas Lahtinen
2017-02-16 14:18       ` [PATCH] drm/i915/guc: Add onion teardown to the GuC setup Oscar Mateo
2017-02-16 14:21         ` Oscar Mateo
2017-02-17 23:06         ` Daniele Ceraolo Spurio
2017-02-20 10:39           ` Joonas Lahtinen [this message]
2017-02-20 10:52         ` Joonas Lahtinen

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=1487587199.3454.23.camel@linux.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=oscar.mateo@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;
as well as URLs for NNTP newsgroup(s).