Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1492539

Re: [Update][RFC/RFT][PATCH v3 2/5] driver core: Functional dependencies tracking support

Show all headers | View raw

On Wed, Sep 28, 2016 at 12:43 PM, Lukas Wunner <lukas@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 <lukas@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.

Or do you have any particular example in which things work differently in mind?

Thanks,
Rafael

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [Update][RFC/RFT][PATCH v3 2/5] driver core: Functional  dependencies tracking support Lukas Wunner <lukas@wunner.de> - 2016-09-27 11:00 +0200
  Re: [Update][RFC/RFT][PATCH v3 2/5] driver core: Functional  dependencies tracking support "Rafael J. Wysocki" <rafael@kernel.org> - 2016-09-27 14:00 +0200
    Re: [Update][RFC/RFT][PATCH v3 2/5] driver core: Functional  dependencies tracking support Lukas Wunner <lukas@wunner.de> - 2016-09-28 12:50 +0200
      Re: [Update][RFC/RFT][PATCH v3 2/5] driver core: Functional  dependencies tracking support "Rafael J. Wysocki" <rafael@kernel.org> - 2016-09-28 13:40 +0200
        Re: [Update][RFC/RFT][PATCH v3 2/5] driver core: Functional  dependencies tracking support Lukas Wunner <lukas@wunner.de> - 2016-09-29 12:40 +0200

csiph-web