All of lore.kernel.org
 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 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.