lkml.org 
[lkml]   [2020]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC][PATCH] driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires
    Hi John,

    On Tue, Apr 7, 2020 at 9:50 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
    > On Tue, Apr 7, 2020 at 9:06 AM John Stultz <john.stultz@linaro.org> wrote:
    > > 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.
    > >
    > > NOTE: I'm not 100% sure this won't have other unwanted side
    > > effects (I don't have failing hardware myself to validate),
    > > so I'd apprecate testing and close review.
    > >
    > > If this approach doesn't work, I'll simply set the default
    > > driver_deferred_probe_timeout value back to zero, to avoid any
    > > behavioral change from before.
    > >
    > > Thanks to Geert for chasing down that ip_auto_config was why NFS
    > > was failing in this case!
    > >
    > > Cc: "David S. Miller" <davem@davemloft.net>
    > > Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
    > > Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
    > > Cc: Jakub Kicinski <kuba@kernel.org>
    > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    > > Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
    > > Cc: Rob Herring <robh@kernel.org>
    > > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    > > Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    > > Cc: netdev <netdev@vger.kernel.org>
    > > Cc: linux-pm@vger.kernel.org
    > > Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    > > Fixes: c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic")
    > > Signed-off-by: John Stultz <john.stultz@linaro.org>
    >
    > Thanks, this fixes the issue for me!
    >
    > Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

    Unfortunately this adds another delay of ca. 30 s to mounting NFS root
    when using a kernel config that does include IOMMU and MODULES
    support.

    Gr{oetje,eeting}s,

    Geert

    --
    Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

    In personal conversations with technical people, I call myself a hacker. But
    when I'm talking to journalists I just say "programmer" or something like that.
    -- Linus Torvalds

    \
     
     \ /
      Last update: 2020-04-07 18:47    [W:3.456 / U:0.300 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site