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:11:17 -0700
From:	Frank Rowand <frowand.list@...il.com>
To:	Qing Huang <qing.huang@...cle.com>, linux-kernel@...r.kernel.org
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Grant Likely <grant.likely@...aro.org>,
	Santosh Shilimkar <santosh.shilimkar@...cle.com>
Subject: Re: [PATCH] device probe: add self triggered delayed work request

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.


> Thanks,
> -Qing

< snip >