linux-kernel - Re: [PATCH] device probe: add self triggered delayed work request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <57A9833D.4080405@gmail.com>
Date:	Tue, 9 Aug 2016 00:16:13 -0700
From:	Frank Rowand <frowand.list@...il.com>
To:	Santosh Shilimkar <santosh.shilimkar@...cle.com>,
	Qing Huang <qing.huang@...cle.com>,
	linux-kernel@...r.kernel.org
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH] device probe: add self triggered delayed work request

On 08/08/16 18:15, Santosh Shilimkar wrote:
> 
> 
> On 8/8/2016 6:11 PM, Frank Rowand wrote:
>> On 08/08/16 14:51, Qing Huang wrote:
>>>
>>>
>>> On 08/08/2016 01:44 PM, Frank Rowand wrote:
>>>> On 07/29/16 22:39, Qing Huang wrote:
>>>>> In normal condition, the device probe requests kept in deferred
>>>>> queue would only be triggered for re-probing when another new device
>>>>> probe is finished successfully. This change will set up a delayed
>>>>> trigger work request if the current deferred probe being added is
>>>>> the only one in the queue. This delayed work request will try to
>>>>> reactivate any device from the deferred queue for re-probing later.
>>>>>
>>>>> By doing this, if the last device being probed in system boot process
>>>>> has a deferred probe error, this particular device will still be able
>>>>> to be probed again.
>>>> I am trying to understand the use case.
>>>>
>>>> Can you explain the scenario you are trying to fix?  If I understand
>>>> correctly, you expect that something will change such that a later
>>>> probe attempt will succeed.  How will that change occur and why
>>>> will the deferred probe list not be processed in this case?
>>>>
>>>> Why are you conditioning this on the deferred_probe_pending_list
>>>> being empty?
>>>>
>>>> -Frank
>>>
>>> It turns out one corner case which we worried about has already been
>>> solved in the really_probe() function by comparing
>>> 'deferred_trigger_count' values.
>>>
>>> Another use case we are investigating now: when we probe a device,
>>> the main thread returns EPROBE_DEFER from the driver after we spawn a
>>> child thread to do the actual init work. So we can initialize
>>> multiple similar devices at the same time. After the child thread
>>> finishes its task, we can call driver_deferred_probe_trigger()
>>> directly from child thread to re-probe the
>>> device(driver_deferred_probe_trigger() has to be exported though). Or
>>> we could rely on something in this patch to re-probe the deferred
>>> devices from the pending list...
>>> What do you suggest?
>>
>> See commit 735a7ffb739b6efeaeb1e720306ba308eaaeb20e for how multi-threaded
>> probes were intended to be handled.  I don't know if this approach is used
>> much or even usable, but that is the framework that was created.
>>
> That infrastructure got removed as part of below commit :-(
> 
> commit 5adc55da4a7758021bcc374904b0f8b076508a11
> Author: Adrian Bunk <bunk@...sta.de>
> Date:   Tue Mar 27 03:02:51 2007 +0200
> 
>     PCI: remove the broken PCI_MULTITHREAD_PROBE option
> 
>     This patch removes the PCI_MULTITHREAD_PROBE option that had already
>     been marked as broken.
> 
>     Signed-off-by: Adrian Bunk <bunk@...sta.de>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>

Hmmmm.  :-( indeed.

The *_initcall_sync defines are still there, but yep, the wait_for_probes()
part is gone.  Thanks for the info about the partial removal.