From: Daniel Vetter <daniel@ffwll.ch>
To: Lukas Wunner <lukas@wunner.de>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v4 2/2] drm/i915: On fb alloc failure, unref gem object where it gets refed
Date: Mon, 6 Jul 2015 09:41:51 +0200 [thread overview]
Message-ID: <20150706074151.GC2156@phenom.ffwll.local> (raw)
In-Reply-To: <874c025b04129f1ca71a66be4568258fc5b6c133.1436041426.git.lukas@wunner.de>
On Sat, Jul 04, 2015 at 11:50:58AM +0200, Lukas Wunner wrote:
> Currently when allocating a framebuffer fails, the gem object gets
> unrefed at the bottom of the call chain in __intel_framebuffer_create,
> not where it gets refed, which is in intel_framebuffer_create_for_mode
> (via i915_gem_alloc_object) and in intel_user_framebuffer_create
> (via drm_gem_object_lookup).
>
> This invites mistakes: As discovered by Tvrtko Ursulin, a double unref
> has sneaked into intelfb_alloc (which calls __intel_framebuffer_create).
>
> As suggested by Ville Syrjälä, improve code clarity by moving the unref
> away from __intel_framebuffer_create to where the gem object gets refed.
>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Fixes: a8bb6818270c ("drm/i915: Fix error path leak in fbdev fb
> allocation")
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
Please keep a record of the changes you do to the patch so I know what to
look out for. Just reving the patch revision alone doesn't add much
information for reviewers/maintainers.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 21 ++++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 9079fcd..d597afa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8876,20 +8876,17 @@ __intel_framebuffer_create(struct drm_device *dev,
> int ret;
>
> intel_fb = kzalloc(sizeof(*intel_fb), GFP_KERNEL);
> - if (!intel_fb) {
> - drm_gem_object_unreference(&obj->base);
> + if (!intel_fb)
> return ERR_PTR(-ENOMEM);
> - }
>
> ret = intel_framebuffer_init(dev, intel_fb, mode_cmd, obj);
> if (ret)
> goto err;
>
> return &intel_fb->base;
> +
> err:
> - drm_gem_object_unreference(&obj->base);
> kfree(intel_fb);
> -
> return ERR_PTR(ret);
> }
>
> @@ -8929,6 +8926,7 @@ intel_framebuffer_create_for_mode(struct drm_device *dev,
> struct drm_display_mode *mode,
> int depth, int bpp)
> {
> + struct drm_framebuffer *fb;
> struct drm_i915_gem_object *obj;
> struct drm_mode_fb_cmd2 mode_cmd = { 0 };
>
> @@ -8943,7 +8941,11 @@ intel_framebuffer_create_for_mode(struct drm_device *dev,
> bpp);
> mode_cmd.pixel_format = drm_mode_legacy_fb_format(bpp, depth);
>
> - return intel_framebuffer_create(dev, &mode_cmd, obj);
> + fb = intel_framebuffer_create(dev, &mode_cmd, obj);
> + if (IS_ERR(fb))
> + drm_gem_object_unreference_unlocked(&obj->base);
> +
> + return fb;
> }
>
> static struct drm_framebuffer *
> @@ -13379,6 +13381,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
> struct drm_file *filp,
> struct drm_mode_fb_cmd2 *mode_cmd)
> {
> + struct drm_framebuffer *fb;
> struct drm_i915_gem_object *obj;
>
> obj = to_intel_bo(drm_gem_object_lookup(dev, filp,
> @@ -13386,7 +13389,11 @@ intel_user_framebuffer_create(struct drm_device *dev,
> if (&obj->base == NULL)
> return ERR_PTR(-ENOENT);
>
> - return intel_framebuffer_create(dev, mode_cmd, obj);
> + fb = intel_framebuffer_create(dev, mode_cmd, obj);
> + if (IS_ERR(fb))
> + drm_gem_object_unreference_unlocked(&obj->base);
> +
> + return fb;
> }
>
> static void intel_output_poll_changed(struct drm_device *dev)
> --
> 2.1.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-07-06 7:39 UTC|newest]
Thread overview: 17+ 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
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 [this message]
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
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=20150706074151.GC2156@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--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.