On Wed, Sep 28, 2016 at 01:31:36PM +0200, Rafael J. Wysocki wrote:
> On Wed, Sep 28, 2016 at 12:43 PM, Lukas Wunner <lu...@wunner.de> wrote:
> > On Tue, Sep 27, 2016 at 01:52:48PM +0200, Rafael J. Wysocki wrote:
> >> On Tue, Sep 27, 2016 at 10:54 AM, Lukas Wunner <lu...@wunner.de> wrote:
> >> > On Fri, Sep 16, 2016 at 02:33:55PM +0200, Rafael J. Wysocki wrote:
> >> >> +void device_links_unbind_consumers(struct device *dev)
> >> >> +{
> >> >> + struct device_link *link;
> >> >> + int idx;
> >> >> +
> >> >> + start:
> >> >> + idx = device_links_read_lock();
> >> >> +
> >> >> + list_for_each_entry_rcu(link, &dev->links_to_consumers, s_node) {
> >> >> + enum device_link_status status;
> >> >> +
> >> >> + if (link->flags & DEVICE_LINK_STATELESS)
> >> >> + continue;
> >> >> +
> >> >> + spin_lock(&link->lock);
> >> >> + status = link->status;
> >> >> + if (status == DEVICE_LINK_CONSUMER_PROBE) {
> >> >> + spin_unlock(&link->lock);
> >> >> +
> >> >> + device_links_read_unlock(idx);
> >> >> +
> >> >> + wait_for_device_probe();
> >> >> + goto start;
> >> >> + }
> >> >> + link->status = DEVICE_LINK_SUPPLIER_UNBIND;
> >> >
> >> > While revisiting this function it just occurred to me that there's
> >> > a theoretical infinite loop here if the consumer probes, is unbound
> >> > by the supplier, then reprobes again before the supplier had a chance
> >> > to update the link to DEVICE_LINK_SUPPLIER_UNBIND. Perhaps this isn't
> >> > a problem in practice, but noting anyway.
> >>
> >> But the consumer is unbound only after setting the link status to
> >> DEVICE_LINK_SUPPLIER_UNBIND and then it won't probe again.
> >
> > Sorry, looking at the code with a fresh pair of eyeballs I realize the
> > scenario for the infinite loop is different from what I've written above:
> > The infinite loop can occur if the consumer probes continuously but never
> > succeeds, e.g. due to some unfulfilled condition in its ->probe hook.
>
> I'm not sure how that can happen.
>
> If it doesn't succeed, the driver's ->probe() will return an error, so
> that driver is not going to be tried again, unless the error is
> -EPROBE_DEFER, but that will cause it to wait for another driver to
> probe successfully in the meantime.
You're right, it seems that the code is safe. Sorry for the noise. :)
Best regards,
Lukas
