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  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:   Wed, 8 Apr 2020 10:29:20 +0000
From:   Yoshihiro Shimoda <>
To:     John Stultz <>,
        lkml <>
CC:     "David S. Miller" <>,
        Alexey Kuznetsov <>,
        Hideaki YOSHIFUJI <>,
        Jakub Kicinski <>,
        Greg Kroah-Hartman <>,
        "Rafael J . Wysocki" <>,
        Rob Herring <>,
        Geert Uytterhoeven <>,
        netdev <>,
        "" <>
Subject: RE: [RFC][PATCH v2 2/2] driver core: Ensure wait_for_device_probe()
 waits until the deferred_probe_timeout fires

Hi John,

> From: John Stultz, Sent: Wednesday, April 8, 2020 4:27 PM
> In commit c8c43cee29f6 ("driver core: Fix
> driver_deferred_probe_check_state() logic"), we set the default
> driver_deferred_probe_timeout value to 30 seconds to allow for
> drivers that are missing dependencies to have some time so that
> the dependency may be loaded from userland after initcalls_done
> is set.
> However, Yoshihiro Shimoda reported that on his device that
> expects to have unmet dependencies (due to "optional links" in
> its devicetree), was failing to mount the NFS root.
> In digging further, it seemed the problem was that while the
> device properly probes after waiting 30 seconds for any missing
> modules to load, the ip_auto_config() had already failed,
> resulting in NFS to fail. This was due to ip_auto_config()
> calling wait_for_device_probe() which doesn't wait for the
> driver_deferred_probe_timeout to fire.
> This patch tries to fix the issue by creating a waitqueue
> for the driver_deferred_probe_timeout, and calling wait_event()
> to make sure driver_deferred_probe_timeout is zero in
> wait_for_device_probe() to make sure all the probing is
> finished.
> The downside to this solution is that kernel functionality that
> uses wait_for_device_probe(), will block until the
> driver_deferred_probe_timeout fires, regardless of if there is
> any missing dependencies.
> However, the previous patch reverts the default timeout value to
> zero, so this side-effect will only affect users who specify a
> driver_deferred_probe_timeout= value as a boot argument, where
> the additional delay would be beneficial to allow modules to
> load later during boot.
> Thanks to Geert for chasing down that ip_auto_config was why NFS
> was failing in this case!
> Cc: "David S. Miller" <>
> Cc: Alexey Kuznetsov <>
> Cc: Hideaki YOSHIFUJI <>
> Cc: Jakub Kicinski <>
> Cc: Greg Kroah-Hartman <>
> Cc: Rafael J. Wysocki <>
> Cc: Rob Herring <>
> Cc: Geert Uytterhoeven <>
> Cc: Yoshihiro Shimoda <>
> Cc: netdev <>
> Cc:
> Reported-by: Yoshihiro Shimoda <>
> Fixes: c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic")
> Signed-off-by: John Stultz <>
> ---
> * v2: Split patch, and apply it as a follow-on to setting
>       the driver_deferred_probe_timeout defalt back to zero
> ---

Thank you for the patch! This patch doesn't cause any side
effect on my environment (the value of driver_deferred_probe_timeout is 0).

Tested-by: Yoshihiro Shimoda <>

Best regards,
Yoshihiro Shimoda

Powered by blists - more mailing lists