[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160929103603.GA6550@wunner.de>
Date: Thu, 29 Sep 2016 12:36:03 +0200
From: Lukas Wunner <lukas@...ner.de>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Linux PM list <linux-pm@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alan Stern <stern@...land.harvard.edu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Tomeu Vizoso <tomeu.vizoso@...labora.com>,
Mark Brown <broonie@...nel.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Kevin Hilman <khilman@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
"Luis R. Rodriguez" <mcgrof@...e.com>
Subject: Re: [Update][RFC/RFT][PATCH v3 2/5] driver core: Functional
dependencies tracking support
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 <lukas@...ner.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 <lukas@...ner.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
Powered by blists - more mailing lists