[PATCH] component: remove device from master match list on failed add

[PATCH] component: remove device from master match list on failed add

[Daniel Stone]

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

Re: [PATCH] component: remove device from master match list on failed add

[Akshay Bhat]

Daniel Stone <daniels <at> collabora.com> writes:

> 
> Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8
> Signed-off-by: Daniel Stone <daniels <at> collabora.com>

Tested-by: Akshay Bhat <akshay.bhat@timesys.com>

Tested on imx6 processor based board where re-probe was broken after a
probe deferral.

Re: [PATCH] component: remove device from master match list on failed add

[Daniel Stone]

Russell,

On 12 February 2016 at 00:57, Akshay Bhat <akshay.bhat@timesys.com> wrote:
> Daniel Stone <daniels <at> collabora.com> writes:
>> Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8
>> Signed-off-by: Daniel Stone <daniels <at> collabora.com>
>
> Tested-by: Akshay Bhat <akshay.bhat@timesys.com>
>
> Tested on imx6 processor based board where re-probe was broken after a
> probe deferral.

One-week ping; this breaks quite a few drivers, even despite
57480484f9 already being present. Another option could just be to
revert the original match-array commit (and the subsequent two fixups)
until you can work out a fix.

Cheers,
Daniel

Re: [PATCH] component: remove device from master match list on failed add

[Russell King - ARM Linux]

On Mon, Feb 15, 2016 at 04:36:55PM +0000, Daniel Stone wrote:
> Russell,
> 
> On 12 February 2016 at 00:57, Akshay Bhat <akshay.bhat@timesys.com> wrote:
> > Daniel Stone <daniels <at> collabora.com> writes:
> >> Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8
> >> Signed-off-by: Daniel Stone <daniels <at> collabora.com>
> >
> > Tested-by: Akshay Bhat <akshay.bhat@timesys.com>
> >
> > Tested on imx6 processor based board where re-probe was broken after a
> > probe deferral.
> 
> One-week ping; this breaks quite a few drivers, even despite
> 57480484f9 already being present. Another option could just be to
> revert the original match-array commit (and the subsequent two fixups)
> until you can work out a fix.

I assume you haven't checked before sending out reminder emails...
it's in -rc4, and it's been in linux-next since last Thursday.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.