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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 8 Aug 2016 18:15:49 -0700
From:	Santosh Shilimkar <santosh.shilimkar@...cle.com>
To:	Frank Rowand <frowand.list@...il.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 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>