Message-ID: <ca661616-f5bf-d92f-9173-172792797b16@ti.com>
Date:   Thu, 26 Mar 2020 11:45:18 +0200
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Saravana Kannan <saravanak@...gle.com>
CC:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>,
        Felipe Balbi <balbi@...nel.org>,
        Mark Brown <broonie@...nel.org>, Ferry Toth <fntoth@...il.com>,
        <grant.likely@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH v3] driver core: Break infinite loop when deferred probe
 can't be satisfied

Hi,

On 26/03/2020 10.39, Rafael J. Wysocki wrote:
> On Wed, Mar 25, 2020 at 11:09 PM Saravana Kannan <saravanak@...gle.com> wrote:
>>
>> On Wed, Mar 25, 2020 at 5:51 AM Andy Shevchenko
>> <andriy.shevchenko@...ux.intel.com> wrote:
>>>
> 
> [cut]
> 
>>>
>>> Yes, it's (unlikely) possible (*), but it will give one more iteration per such
>>> case. It's definitely better than infinite loop. Do you agree?
>>
>> Sorry I wasn't being clear (I was in a rush). I'm saying this patch
>> can reintroduce the bug where the deferred probe isn't triggered when
>> it should be.
>>
>> Let's take a simple execution flow.
>>
>> probe_okay is at 10.
>>
>> Thread-A
>>   really_probe(Device-A)
>>     local_probe_okay_count = 10
>>     Device-A probe function is running...
>>
>> Thread-B
>>   really_probe(Device-B)
>>     Device-B probes successfully.
>>     probe_okay incremented to 11
>>
>> Thread-C
>>   Device-C (which had bound earlier) is unbound (say module is
>> unloaded or a million other reasons).
>>   probe_okay is decremented to 10.
>>
>> Thread-A continues
>>   Device-A probe function returns -EPROBE_DEFER
>>   driver_deferred_probe_add_trigger() doesn't do anything because
>>     local_probe_okay_count == probe_okay
>>   But Device-A might have deferred probe waiting on Device-B.
>>   Device-A never probes.
>>
>>> *) It means during probe you have _intensive_ removing, of course you may keep
>>> kernel busy with iterations, but it has no practical sense. DoS attacks more
>>> effective in different ways.
>>
>> I wasn't worried about DoS attacks. More of a functional correctness
>> issue what I explained above.
> 
> The code is functionally incorrect as is already AFAICS.
> 
>> Anyway, if your issue and similar issues can be handles in driver core
>> in a clean way without breaking other cases, I don't have any problem
>> with that. Just that, I think the current solution breaks other cases.
> 
> OK, so the situation right now is that commit 58b116bce136 has
> introduced a regression and so it needs to be fixed or reverted.  The
> cases that were previously broken and were unbroken by that commit
> don't matter here, so you cannot argue that they would be "broken".

commit 58b116bce136 is from 2014 and the whole ULPI support for dwc3
came in a year later.
While I agree that 58b116bce136 fail to handle came a year later, but
technically it did not introduced a regression.

The revert on the other hand is going to introduce a regression as
things were working fine since 2014. Not sure why the dwc3 issue got
this long to be noticed as the 58b116bce136 was already in kernel when
the ULPI support was added...

> It looks to me like the original issue fixed by the commit in question
> needs to be addressed differently, so I would vote for reverting it
> and starting over.

Fwiw my original approach was a bit different:
https://lore.kernel.org/patchwork/patch/454800/

Greg changed it to what ended up in the kernel:
https://lore.kernel.org/patchwork/cover/454799/

>> As an alternate solution, assuming "linux,extcon-name" is coming
>> from some firmware, you might want to look into the fw_devlink
>> feature.
> 
> That would be a workaround for a driver core issue, though, wouldn't it?
> 
>> That feature allows driver core to add device links from firmware
>> information. If you can get that feature to create device links from
>> your dwc3.0.auto (or its parent pci_dev?) to the extcon supplier
>> device, all of this can be sidestepped and your dwc3.0.auto's (or the
>> dwc pci_dev's) probe will be triggered only after extcon is probed.
>>
>> I have very little familiarity with PCI/ACPI. I spent about an hour or
>> two poking at ACPI scan/property code. The relationship between a
>> pci_dev and an acpi_device is a bit confusing to me because I see:
>>
>> static int dwc3_pci_probe(struct pci_dev *pci, const struct pci_device_id *id)
>> {
>>         struct property_entry *p = (struct property_entry *)id->driver_data;
>>         struct dwc3_pci         *dwc;
>>         struct resource         res[2];
>>         int                     ret;
>>         struct device           *dev = &pci->dev;
>> ....
>>         dwc->dwc3 = platform_device_alloc("dwc3", PLATFORM_DEVID_AUTO);
>> ....
>>         ACPI_COMPANION_SET(&dwc->dwc3->dev, ACPI_COMPANION(dev));
>>
>> And ACPI_COMPANION returns an acpi_device by looking at dev->fwnode.
>> So how the heck is a pci_device.dev.fwnode pointing to an
>> acpi_device.fwnode?
> 
> acpi_device is an of_node counterpart (or it is an fwnode itself if you will).
> 
> Thanks!
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Powered by blists - more mailing lists