From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Inki Dae <inki.dae@samsung.com>
Cc: kyungmin.park@samsung.com, sw0312.kim@samsung.com,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: fix drm_framebuffer cleanup.
Date: Fri, 9 Nov 2012 13:13:16 +0200 [thread overview]
Message-ID: <20121109111316.GY3791@intel.com> (raw)
In-Reply-To: <1352446770-28855-1-git-send-email-inki.dae@samsung.com>
On Fri, Nov 09, 2012 at 04:39:30PM +0900, Inki Dae wrote:
> This patch fixes access issue to invalid memory region.
>
> crtc had only one drm_framebuffer object so when framebuffer
> cleanup was requested after page flip, it'd try to disable
> hardware overlay to current crtc.
> But if current crtc points to another drm_framebuffer,
> This may induce invalid memory access.
>
> Assume that some application are doing page flip with two
> drm_framebuffer objects. At this time, if second drm_framebuffer
> is set to current crtc and the cleanup to first drm_framebuffer
> is requested once drm release is requested, then first
> drm_framebuffer would be cleaned up without disabling
> hardware overlay because current crtc points to second
> drm_framebuffer. After that, gem buffer to first drm_framebuffer
> would be released and this makes dma access invalid memory region.
>
> This patch adds drm_framebuffer to drm_crtc structure as member
That is exactly the reverse of what you're doing in the patch.
We already have crtc.fb, and you're adding fb.crtc.
> and makes drm_framebuffer_cleanup function check if fb->crtc is
> same as desired fb. And also when setcrtc and pageflip are
> requested, it makes each drm_framebuffer point to current crtc.
Looks like you're just setting the crtc.fb and fb.crtc pointers to
exactly mirror each other in the page flip ioctl. That can't fix
anything.
First of all multiple crtcs can scan out from the same fb, so a single
fb.crtc pointer is clearly not enough to represent the relationship
between fbs and crtcs.
Also you're not clearing the fb.crtc pointer anywhere, so now
destroying any framebuffer that was once used for scanout, would disable
some crtc.
So it looks like you're making things worse, not better.
Anyway I'll just nack the whole idea. What you need to do is track the
pending page flips, and make sure the old buffer is not freed too early.
Just grab a reference to the old gem object when issuing the page flip,
and unref it when you're sure the flip has occured. Or you could use the
new drm_framebuffer refcount, but personally I don't see much point in
that when you already have the gem object refcount at your disposal.
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2012-11-09 11:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-09 7:39 [PATCH] drm: fix drm_framebuffer cleanup Inki Dae
2012-11-09 8:49 ` Prathyush K
2012-11-09 9:21 ` Inki Dae
2012-11-09 11:13 ` Ville Syrjälä [this message]
2012-11-09 12:41 ` Inki Dae
2012-11-09 13:30 ` Ville Syrjälä
2012-11-09 14:04 ` Inki Dae
2012-11-09 14:29 ` Ville Syrjälä
2012-11-09 16:50 ` Inki Dae
2012-11-09 16:57 ` Rob Clark
2012-11-09 18:48 ` Ville Syrjälä
2012-11-10 1:09 ` Inki Dae
2012-11-12 12:28 ` Ville Syrjälä
2012-11-12 14:36 ` Inki Dae
2012-11-09 14:40 ` Rob Clark
2012-11-09 16:56 ` Inki Dae
2012-11-09 17:00 ` Rob Clark
2012-11-09 17:10 ` Rob Clark
2012-11-09 17:39 ` Inki Dae
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=20121109111316.GY3791@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=inki.dae@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=sw0312.kim@samsung.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.