From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Stefan Agner <stefan@agner.ch>
Cc: p.zabel@pengutronix.de, airlied@linux.ie,
gregkh@linuxfoundation.org, rafael@kernel.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/imx: make sure to cleanup DRM before unbinding components
Date: Wed, 10 Oct 2018 11:38:29 +0100 [thread overview]
Message-ID: <20181010103829.GN30658@n2100.armlinux.org.uk> (raw)
In-Reply-To: <e08eff2ed53b441c8a6c41758c00c1c91dc48d2c.1539120077.git.stefan@agner.ch>
On Tue, Oct 09, 2018 at 11:30:49PM +0200, Stefan Agner wrote:
> In situations where a component fails to bind, a previously
> successfully bound component might already registered itself
> with the DRM framework (e.g. an encoder). When the master
> component then calls drm_mode_config_cleanup, we end up in a
> use after free sitution.
>
> Use the cleanup callback to make sure all framework level
> cleanup is done by the time we unbind components.
I'm not sure about this approach - the idea about the component bind
and unbind callbacks is that unbind undoes _everything_ that bind has
done, so everything is correctly ordered. If bind registers something,
unbind should unregister it.
What seems to be going on is that imx is registering stuff in bind()
but not unregistering it in unbind().
Since imx was one of the drivers that the component helper was
created for, if it's now crashing, that's a regression in the imx
driver. Looking at the commit log, I'd say:
commit 8e3b16e2117409625b89807de3912ff773aea354
Author: Lucas Stach <l.stach@pengutronix.de>
Date: Thu Aug 11 11:18:49 2016 +0200
drm/imx: don't destroy mode objects manually on driver unbind
Instead let drm_mode_config_cleanup() do the work when taking down
the master device. This requires all cleanup functions to be
properly hooked up to the mode object .destroy callback.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
is probably responsible for introducing this problem, since the
explicit calls were added by me when imx was stuck in staging due to
the problems that the component helper solved.
I think what we have here are different opinions on how cleanup
should be handled.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
next prev parent reply other threads:[~2018-10-10 10:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-09 21:30 [PATCH 1/2] component: add optional cleanup function Stefan Agner
2018-10-09 21:30 ` [PATCH 2/2] drm/imx: make sure to cleanup DRM before unbinding components Stefan Agner
2018-10-10 10:38 ` Russell King - ARM Linux [this message]
2018-10-10 11:02 ` Stefan Agner
2018-10-10 11:22 ` Russell King - ARM Linux
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=20181010103829.GN30658@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=rafael@kernel.org \
--cc=stefan@agner.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®