linux-kernel - Re: [PATCH v6 21/22] driver core: Start processing deferred probes earlier

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]

Message-ID: <CAL_JsqKBKSsvEuoufc=xesSvcA1bf-X43O0YOvuntUJE5NYCJA@mail.gmail.com>
Date:	Mon, 5 Oct 2015 21:49:38 -0500
From:	Rob Herring <robherring2@...il.com>
To:	Frank Rowand <frowand.list@...il.com>
Cc:	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Javier Martinez Canillas <javier@....samsung.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mark Brown <broonie@...nel.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Alan Stern <stern@...land.harvard.edu>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v6 21/22] driver core: Start processing deferred probes earlier

On Mon, Oct 5, 2015 at 6:52 PM, Frank Rowand <frowand.list@...il.com> wrote:
> On 9/21/2015 7:03 AM, Tomeu Vizoso wrote:
>> Some initcalls in the late level assume that some devices will have
>> already probed without explicitly checking for that.
>>
>> After the recent move to defer most device probes when they are
>> registered, pressure increased in the late initcall level.
>>
>> By starting the processing of the deferred queue in device_initcall_sync
>> we increase the chances that the initcalls mentioned before will find
>> the devices they depend on to have already probed.
>>
>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@...labora.com>
>> ---
>>
>> Changes in v4:
>> - Start processing deferred probes in device_initcall_sync
>>
>>  drivers/base/dd.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index 269ea76c1a4f..f0ef9233fcd6 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -176,7 +176,7 @@ static void driver_deferred_probe_trigger(void)
>>   *
>>   * We don't want to get in the way when the bulk of drivers are getting probed.
>>   * Instead, this initcall makes sure that deferred probing is delayed until
>> - * late_initcall time.
>> + * device_initcall_sync time.
>
> This is a misuse of the *_sync initcall level.
>
> If a deferred probe created a thread and expected a wait at the
> following *_sync level then the wait would not occur because
> there is no subsequent *_sync level.  This is not a problem today
> because (as far as I know) there are no threads in the probe
> functions.  But there has been interest in adding parallel
> probing and that could expose this problem.
>
> The purpose of the *_sync initcall levels is to allow the corresponding
> initcall level to use multiple threads of execution instead of a single
> thread.  The *_sync level provides a location for a wait for all of the
> threads at the corresponding init level to complete.  This is better
> explained in the git log:

The things I was worried about like clk and regulator disabling are
actually late_initcall_sync, so maybe late_initcall is fine here after
all.

However, looking at other *_initcall_sync users, I'm not so sure they
are doing the same abuse.

Rob

>
> commit 735a7ffb739b6efeaeb1e720306ba308eaaeb20e
> Author: Andrew Morton <akpm@...l.org>
> Date:   Fri Oct 27 11:42:37 2006 -0700
>
>     [PATCH] drivers: wait for threaded probes between initcall levels
>
>     The multithreaded-probing code has a problem: after one initcall level (eg,
>     core_initcall) has been processed, we will then start processing the next
>     level (postcore_initcall) while the kernel threads which are handling
>     core_initcall are still executing.  This breaks the guarantees which the
>     layered initcalls previously gave us.
>
>     IOW, we want to be multithreaded _within_ an initcall level, but not between
>     different levels.
>
>     Fix that up by causing the probing code to wait for all outstanding probes at
>     one level to complete before we start processing the next level.
>
>>   */
>>  static int deferred_probe_initcall(void)
>>  {
>> @@ -190,7 +190,7 @@ static int deferred_probe_initcall(void)
>>       flush_workqueue(deferred_wq);
>>       return 0;
>>  }
>> -late_initcall(deferred_probe_initcall);
>> +device_initcall_sync(deferred_probe_initcall);
>>
>>  static void driver_bound(struct device *dev)
>>  {
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/