From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Lubomir Rintel <lkundrak@v3.sk>,
DRI Development <dri-devel@lists.freedesktop.org>,
Liviu Dudau <Liviu.Dudau@arm.com>, Peter Rosin <peda@axentia.se>
Subject: Re: Armada DRM: bridge with componentized devices
Date: Tue, 8 Jan 2019 10:23:14 +0000 [thread overview]
Message-ID: <20190108102314.GR11171@n2100.armlinux.org.uk> (raw)
In-Reply-To: <d8585e6f-e44a-bd3e-0026-49dd298014dd@samsung.com>
On Tue, Jan 08, 2019 at 10:22:06AM +0100, Andrzej Hajda wrote:
> What part of drm core disallows it? As I remember discussions about
> drm_bridge design there were voices that they should be
> hot(un)pluggable, and they are IMO, of course if they are not active.
Even if they are not active, once the DRM master device has used
of_drm_find_bridge(), it has a reference on struct drm_bridge.
Normally, that is allocated using something like devm_kzalloc()
in the bridge drivers probe function.
When the bridge driver is unbound, that memory will be freed, but
there is no notification to the DRM master that this structure is
no longer valid (unless you have something implemented in exynos
between the exynos core and the bridge driver(s) that specifically
deals with that.) Note that there is nothing in drm_bridge_remove()
that does anything beyond removing the bridge from the global list
of bridges.
Any further accesses by the DRM master to that struct drm_bridge
will be a use-after-free of that memory.
--
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-01-08 10:23 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-03 9:47 Armada DRM: bridge with componentized devices Lubomir Rintel
2019-01-03 13:11 ` Russell King - ARM Linux
2019-01-07 10:45 ` Daniel Vetter
2019-01-07 11:26 ` Andrzej Hajda
2019-01-07 16:08 ` Daniel Vetter
2019-01-07 16:27 ` Andrzej Hajda
2019-01-07 21:56 ` Daniel Vetter
2019-01-08 8:35 ` Andrzej Hajda
2019-01-08 8:47 ` Daniel Vetter
2019-01-08 9:22 ` Andrzej Hajda
2019-01-08 10:23 ` Russell King - ARM Linux [this message]
2019-01-08 10:32 ` Andrzej Hajda
2019-01-08 10:24 ` Daniel Vetter
2019-01-08 11:25 ` Andrzej Hajda
2019-01-08 11:38 ` Russell King - ARM Linux
2019-01-08 12:27 ` Andrzej Hajda
2019-01-08 13:21 ` Russell King - ARM Linux
2019-01-08 13:34 ` Daniel Vetter
2019-01-08 14:33 ` Andrzej Hajda
2019-01-08 15:07 ` Russell King - ARM Linux
2019-01-08 18:07 ` Daniel Vetter
2019-01-09 9:12 ` Andrzej Hajda
2019-01-09 9:24 ` Rafael J. Wysocki
2019-01-09 9:30 ` Russell King - ARM Linux
2019-01-11 14:20 ` Daniel Vetter
2019-01-11 14:26 ` Rafael J. Wysocki
2019-01-11 14:32 ` Russell King - ARM Linux
2019-01-11 14:36 ` Daniel Vetter
2019-01-11 14:40 ` Rafael J. Wysocki
2019-01-11 14:36 ` Rafael J. Wysocki
2019-01-11 14:49 ` Russell King - ARM Linux
2019-01-14 12:32 ` Rafael J. Wysocki
2019-01-15 0:04 ` Rafael J. Wysocki
2019-01-15 22:47 ` Rafael J. Wysocki
2019-01-16 18:42 ` Daniel Vetter
2019-01-16 22:43 ` Rafael J. Wysocki
2019-01-17 12:20 ` Daniel Vetter
2019-01-18 9:36 ` Lucas Stach
2019-01-18 10:03 ` Rafael J. Wysocki
2019-01-18 11:06 ` Daniel Vetter
2019-01-18 11:17 ` Rafael J. Wysocki
2019-01-18 11:37 ` Rafael J. Wysocki
2019-01-18 12:57 ` Daniel Vetter
2019-01-24 11:00 ` Rafael J. Wysocki
2019-01-17 17:26 ` Russell King - ARM Linux admin
2019-01-17 22:43 ` Rafael J. Wysocki
2019-01-18 11:07 ` Linus Walleij
2019-01-08 10:16 ` Russell King - ARM Linux
2019-01-08 10:31 ` Daniel Vetter
2019-01-07 16:12 ` Russell King - ARM Linux
2019-01-07 21:55 ` Daniel Vetter
2019-01-08 0:39 ` Russell King - ARM Linux
2019-01-08 14:29 ` Liviu Dudau
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=20190108102314.GR11171@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=Liviu.Dudau@arm.com \
--cc=a.hajda@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=lkundrak@v3.sk \
--cc=peda@axentia.se \
/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