linux-kernel - Re: [PATCH 02/13] driver-core: defer all probes until late

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: <CAAObsKAMn6xSs4-NCmvXO=EccXxdhv_Y4+KeYJ0Wj3Q5NHsYRg@mail.gmail.com>
Date:	Tue, 23 Jun 2015 16:17:29 +0200
From:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Rob Herring <robherring2@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Alexander Holler <holler@...oftware.de>,
	Alexandre Courbot <gnurou@...il.com>,
	Andrzej Hajda <a.hajda@...sung.com>,
	Arnd Bergmann <arnd@...db.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Kumar Gala <galak@...eaurora.org>, Len Brown <lenb@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Lv Zheng <lv.zheng@...el.com>, Mark Brown <broonie@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	Robert Moore <robert.moore@...el.com>,
	Rob Herring <robh+dt@...nel.org>,
	Russell King <linux@....linux.org.uk>,
	Stephen Warren <swarren@...dotorg.org>,
	Terje Bergström <tbergstrom@...dia.com>,
	Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH 02/13] driver-core: defer all probes until late_initcall

On 23 June 2015 at 16:37, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> On Monday, June 22, 2015 07:07:08 PM Rob Herring wrote:
>> On Fri, Jun 19, 2015 at 6:20 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>> > On Friday, June 19, 2015 03:36:46 PM Tomeu Vizoso wrote:
>> >> On 18 June 2015 at 23:50, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>> >> > On Wednesday, June 17, 2015 03:42:12 PM Tomeu Vizoso wrote:
>> >> >> To decrease the chances of devices deferring their probes because of
>> >> >> dependencies not having probed yet because of their drivers not having
>> >> >> registered yet, delay all probing until the late initcall level.
>> >> >>
>> >> >> This will allow us to avoid deferred probes completely later by probing
>> >> >> dependencies on demand, or by probing them in dependency order.
>> >> >>
>> >> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@...labora.com>
>> >> >> ---
>> >> >>  drivers/base/dd.c | 8 +++++++-
>> >> >>  1 file changed, 7 insertions(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> >> >> index a638bbb..18438aa 100644
>> >> >> --- a/drivers/base/dd.c
>> >> >> +++ b/drivers/base/dd.c
>> >> >> @@ -407,6 +407,12 @@ int driver_probe_device(struct device_driver *drv, struct device *dev)
>> >> >>       if (!device_is_registered(dev))
>> >> >>               return -ENODEV;
>> >> >>
>> >> >> +     /* Defer all probes until we start processing the queue */
>> >> >> +     if (!driver_deferred_probe_enable) {
>> >> >> +             driver_deferred_probe_add(dev);
>> >> >
>> >> > Do I think correctly that this will effectively force everybody to use deferred
>> >> > probing?
>> >>
>> >> Guess it depends on the meaning of "using deferred probing". It will
>> >> defer the probe of the first device to late_initcall (which will
>> >> happen much earlier in time than before), but afterwards all built-in
>> >> drivers will be available and depending on the order in which we try
>> >> to probe devices, none may actually ask to defer its probe.
>> >
>> > So this will break things like the PNP system driver which relies on probing
>> > stuff at the fs_initcall stage for correctness.  It may also break other
>> > things with similar assumptions.
>>
>> Yes, but I think that this can be done for only OF based devices
>> rather than globally for all platform devices and solve that problem.
>> Matching is already dependent of the type of device.
>
> Well, the current patch is not OF-only, though.

Yeah, I'm currently looking at only delaying probing of devices
created from OF data.

Note that calculating dependencies and trying to probe them before
they are needed can be done independently of this patch, but it isn't
that useful because devices will still defer their probes because the
drivers of some dependencies won't have been registered until
late_initcall.

Regards,

Tomeu
--
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/