All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Fix failure paths around initial fbdev allocation
Date: Thu, 02 Jul 2015 14:59:24 +0100	[thread overview]
Message-ID: <559543BC.9030307@linux.intel.com> (raw)
In-Reply-To: <20150702133728.GA5176@intel.com>


On 07/02/2015 02:37 PM, Ville Syrjälä wrote:
> On Tue, Jun 30, 2015 at 10:06:27AM +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> We had three failure modes here:
>>
>> 1.
>> Deadlock in intelfb_alloc failure path where it calls
>> drm_framebuffer_remove, which grabs the struct mutex and intelfb_create
>> (caller of intelfb_alloc) was already holding it.
>>
>> 2.
>> Double unreference on the object if __intel_framebuffer_create fails
>> since both it and the caller (intelfb_alloc) do the unreference.
>>
>> 3.
>> Deadlock in intelfb_create failure path where it calls
>> drm_framebuffer_unreference, which grabs the struct mutex and
>> intelfb_create was already holding it.
>>
>> v2:
>>     * Reformat commit msg to 72 chars. (Lukas Wunner)
>>     * Added third failure mode. (Lukas Wunner)
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Fixes: 60a5ca015ffd2aacfe5674b5a401cd2a37159e07
>> Reported-By: Lukas Wunner <lukas@wunner.de>
>> Tested-By: Lukas Wunner <lukas@wunner.de>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Lukas Wunner <lukas@wunner.de>
>> ---
>> Ville, you suggested some changes earlier;
>>
>> """
>> I suggest removing the unref from __intel_framebuffer_create().
>> """
>>
>> Do you view that as an improvement in code clarity/organisation,
>> or you think my version is actually wrong for some reason?
>
> I find it rather unexpected that the function drops the passed
> reference on error. My usual rule is: do nothing on error, if possible.

I just don't have time at the moment to evaluate the other call sites 
etc. So from my point of view it boils down to whether this patch 
improves things without making anything worse. If it does R-B would be 
cool. If it doesn't then it will have to make for free time to appear. 
Or someone is free to take it over.

Regards,

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

  reply	other threads:[~2015-07-02 13:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30  9:06 [PATCH] drm/i915: Fix failure paths around initial fbdev allocation Tvrtko Ursulin
2015-06-30  9:13 ` shuang.he
2015-06-30 10:23 ` Jani Nikula
2015-07-02 13:23 ` Lukas Wunner
2015-07-02 13:37 ` Ville Syrjälä
2015-07-02 13:59   ` Tvrtko Ursulin [this message]
2015-06-30  9:06     ` [PATCH v3 1/2] " Lukas Wunner
2015-07-04  9:50       ` [PATCH v3 2/2] drm/i915: On fb alloc failure, unref gem object where it gets refed Lukas Wunner
2015-07-04 12:31         ` Chris Wilson
2015-06-30  9:06           ` [PATCH v4 1/2] drm/i915: Fix failure paths around initial fbdev allocation Lukas Wunner
2015-07-04  9:50             ` [PATCH v4 2/2] drm/i915: On fb alloc failure, unref gem object where it gets refed Lukas Wunner
2015-07-06  7:41               ` Daniel Vetter
2015-07-06 12:59                 ` Lukas Wunner
2015-07-06 13:55                   ` Daniel Vetter
2015-07-05 16:49           ` [PATCH v3 " Lukas Wunner
2015-07-05 17:31             ` Chris Wilson
2015-07-04 12:48     ` [PATCH] drm/i915: Fix failure paths around initial fbdev allocation Lukas Wunner
  -- strict thread matches above, loose matches on Subject: below --
2015-06-15 10:49 Tvrtko Ursulin
2015-06-15 11:22 ` Ville Syrjälä
2015-06-29  7:03 ` shuang.he
2015-06-29 14:39 ` Lukas Wunner
2015-06-29 15:15   ` Tvrtko Ursulin
2015-06-29 17:48     ` Lukas Wunner

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=559543BC.9030307@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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.