component_unbind_all() splat..

Russell King - ARM Linux linux at arm.linux.org.uk
Wed May 6 11:52:01 PDT 2015


On Wed, May 06, 2015 at 12:45:04PM -0400, Rob Clark wrote:
> On Wed, May 6, 2015 at 12:01 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Wed, May 06, 2015 at 10:22:22AM -0400, Rob Clark wrote:
> >> Hey Russell,
> >>
> >> I just noticed a splat triggered by component_unbind_all() called from
> >> ->bind()..  any opinions about whether component stuff should handle
> >> that case, or whether I should rearrange my error cleanup path to not
> >> component_unbind_all() in this case?
> >
> > Essentially, if component_bind_all() returned an error, you should not
> > call component_unbind_all() - component_bind_all() has the effect that
> > it's either successful and all components have been bound, or when it
> > fails, no components are bound.
> >
> > component_unbind_all() assumes that the components were previously
> > successfully bound.
> >
> > When I look at the MSM code, I can see why this happens, and it's
> > basically because of broken error cleanup handling caused by this
> > commit:
> 
> Right, what to do to fix it in msm is clear enough.. what I was
> (trying to) get at was, since error paths are perpetually undertested,
> would it make more sense to handle component_unbind_all() called from
> ->bind().. (although I also didn't go audit the other component users
> yet to see if any might have the same issue)

You can call it from ->bind() provided the preceding component_bind_all()
call succeeded.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.


More information about the dri-devel mailing list