From: Daniel Stone <daniels@collabora.com>
To: linux-kernel@vger.kernel.org
Cc: Russell King <rmk+kernel@arm.linux.org.uk>,
Thierry Reding <treding@nvidia.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: [PATCH] component: remove device from master match list on failed add
Date: Mon, 8 Feb 2016 21:12:58 +0000 [thread overview]
Message-ID: <1454965978-2846-1-git-send-email-daniels@collabora.com> (raw)
Calling component_add() may result in the completion of a set of
devices, which will try to bring up a master. In bringing the master
up, we populate its match array with the current set of children.
If binding any of the devices fails, component_add() itself will fail,
free the struct component entry, and return to the caller. The
now-freed entry is never removed from the master's match array, and
will later be used in a futile attempt to bind to freed memory.
Bring component_add's behaviour on failure to bring up a master into
line with component_del by removing the (to-be-freed) component from
the master's match array.
The specific case which broke was:
- rockchip_drm_drv adds a component master
- dwhdmi_rockchip adds a child component in probe (master incomplete)
- rockchip_drm_vop adds two children in probe, which completes the
set
- inside component_add, we try to bring up the master, having
populated the master's match array, and fail with EPROBE_DEFER from
dwhdmi_rockchip; we delete the putative component
- rockchip_drm_vop's probe fails and returns EPROBE_DEFER
- we later re-probe rockchip_drm_vop and add the component; the
master is complete, so we attempt to bring it up again
- walking the match array, we find the previous child, whose master
pointer doesn't match (as it has been freed in the meantime)
- rockchip_drm_vop probe fails, and will never be attempted again
Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/base/component.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 2738039..04a1582 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -491,6 +491,8 @@ int component_add(struct device *dev, const struct component_ops *ops)
ret = try_to_bring_up_masters(component);
if (ret < 0) {
+ if (component->master)
+ remove_component(component->master, component);
list_del(&component->node);
kfree(component);
--
2.5.0
next reply other threads:[~2016-02-08 21:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-08 21:12 Daniel Stone [this message]
2016-02-12 0:57 ` Akshay Bhat
2016-02-15 16:36 ` Daniel Stone
2016-02-15 16:41 ` 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=1454965978-2846-1-git-send-email-daniels@collabora.com \
--to=daniels@collabora.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=treding@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome