All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v4 2/6] drm/i915: tidy up initialisation failure paths (GEM & LRC)
Date: Mon, 1 Feb 2016 09:45:25 +0000	[thread overview]
Message-ID: <56AF2935.1040409@intel.com> (raw)
In-Reply-To: <20160130112818.GV24534@nuc-i3427.alporthouse.com>

On 30/01/16 11:28, Chris Wilson wrote:
> On Sat, Jan 30, 2016 at 10:56:27AM +0000, Chris Wilson wrote:
>> On Fri, Jan 29, 2016 at 07:19:27PM +0000, Dave Gordon wrote:
>>> 1. add call to i915_gem_context_fini() to deallocate the default
>>>     context(s) if the call to init_rings() fails, so that we don't
>>>     leak the context in that situation.
>>>
>>> 2. remove useless code in intel_logical_ring_cleanup(), presumably
>>>     copypasted from legacy ringbuffer version at creation.
>>>
>>> Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/i915_gem.c  |  5 ++++-
>>>   drivers/gpu/drm/i915/intel_lrc.c | 10 ++--------
>>>   2 files changed, 6 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>>> index a928823..5a4d468 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>> @@ -4986,8 +4986,11 @@ int i915_gem_init(struct drm_device *dev)
>>>   		goto out_unlock;
>>>
>>>   	ret = dev_priv->gt.init_rings(dev);
>>> -	if (ret)
>>> +	if (ret) {
>>> +		i915_gem_context_fini(dev);
>>> +		/* XXX: anything else to be undone here? */
>>
>> Yes. Make this a separate patch and begin the onion unwind.
>
> Hmm. Actually, we have to make sure that we can still modeset if this
> function fails - that is anything but utter catastrophe should just
> result in loss of functionality (no stolen, no GEM execution etc) but we
> can still drive the displays so the user can see how bad the damage is.
> -Chris

Yes, Mika said that's why (he thought) there wasn't a complete reversal 
of everything the driver has done up to this point.

The addition of the context_fini() seems reasonable, that's going to 
make it leak a bit less, while still leaving basic framebuffer working.

Could be a separate patch if you like, but hardly seems worth splitting 
from the other chunk, which after all only replaces unreachable code 
with a WARNing.

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

  reply	other threads:[~2016-02-01  9:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29 19:19 [PATCH v4 0/6] A collection of cleanups, version 4 Dave Gordon
2016-01-29 19:19 ` [PATCH v4 1/6] drm/i915: tidy up initialisation failure paths (legacy) Dave Gordon
2016-01-30 10:50   ` Chris Wilson
2016-02-01  9:38     ` Dave Gordon
2016-02-11 13:35       ` Chris Wilson
2016-01-29 19:19 ` [PATCH v4 2/6] drm/i915: tidy up initialisation failure paths (GEM & LRC) Dave Gordon
2016-01-30 10:56   ` Chris Wilson
2016-01-30 11:28     ` Chris Wilson
2016-02-01  9:45       ` Dave Gordon [this message]
2016-02-11  8:47         ` Daniel Vetter
2016-02-15 11:55           ` Dave Gordon
2016-01-29 19:19 ` [PATCH v4 3/6] drm/i915: unmap the correct page in intel_logical_ring_cleanup() Dave Gordon
2016-01-30 11:01   ` Chris Wilson
2016-01-29 19:19 ` [PATCH v4 4/6] drm/i915: consolidate LRC mode HWSP setup & teardown Dave Gordon
2016-01-30 11:11   ` Chris Wilson
2016-01-29 19:19 ` [PATCH v4 5/6] drm/i915: HWSP should be unmapped earlier in LRC teardown sequence Dave Gordon
2016-01-30 11:13   ` Chris Wilson
2016-01-29 19:19 ` [PATCH v4 6/6] drm/i915: fix context/engine cleanup order Dave Gordon
2016-01-30 11:17   ` Chris Wilson
2016-02-11 13:36     ` Chris Wilson
2016-02-11 15:02       ` Mika Kuoppala
2016-02-15 12:00         ` Dave Gordon
2016-02-15 13:43       ` Dave Gordon
2016-02-01  8:59 ` ✓ Fi.CI.BAT: success for A collection of cleanups, version 4 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=56AF2935.1040409@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.