From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Fix failure paths around initial fbdev allocation
Date: Mon, 29 Jun 2015 16:15:08 +0100 [thread overview]
Message-ID: <559160FC.1070605@linux.intel.com> (raw)
In-Reply-To: <20150629143925.GA7955@wunner.de>
Hi,
On 06/29/2015 03:39 PM, Lukas Wunner wrote:
> Hi,
>
> On Mon, Jun 15, 2015 at 11:49:52AM +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> We had two 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.
>
> s/intelfb_alloc/intelfb_create/
> s/(caller of intelfb_alloc)//
I looked again and don't see that I made a mistake with regards to this?
>> 2.
>> Double unreference on the object if __intel_framebuffer_create fails since
>> both it and the caller (intelfb_alloc) do the unreference.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Fixes: 60a5ca015ffd2aacfe5674b5a401cd2a37159e07
> Reported-By: Lukas Wunner <lukas@wunner.de>
Sorry probably my oversight, don't remember now how it all came about.
>> @@ -183,15 +186,18 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
>> goto out_fb;
>> }
>>
>> + mutex_unlock(&dev->struct_mutex);
>> +
>> ifbdev->fb = to_intel_framebuffer(fb);
>>
>> return 0;
>>
>> out_fb:
>> - drm_framebuffer_remove(fb);
>> -out_unref:
>> drm_gem_object_unreference(&obj->base);
>> out:
>> + mutex_unlock(&dev->struct_mutex);
>> + if (fb)
>> + drm_framebuffer_remove(fb);
>
> Hm, the order of drm_gem_object_unreference() and drm_framebuffer_remove()
> is reversed now, could this cause any issues?
No, that is fine.
> Apart from that,
>
> Reviewed-By: Lukas Wunner <lukas@wunner.de>
>
> I will also test the patch and report back in a bit.
That will be very useful. I did not test it extensively myself, just
fired it off quickly since I was briefly hitting this failure path myself.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-06-29 15:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 10:49 [PATCH] drm/i915: Fix failure paths around initial fbdev allocation 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 [this message]
2015-06-29 17:48 ` Lukas Wunner
-- strict thread matches above, loose matches on Subject: below --
2015-06-30 9:06 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
2015-07-04 12: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=559160FC.1070605@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=lukas@wunner.de \
/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.