Hi Shreeya,
On Wed, Aug 16, 2023 at 11:39 AM Shreeya Patel shreeya.patel@collabora.com wrote:
On 13/06/22 15:40, Greg Kroah-Hartman wrote:
From: Saravana Kannansaravanak@google.com
[ Upstream commit 5ee76c256e928455212ab759c51d198fedbe7523 ]
Mounting NFS rootfs was timing out when deferred_probe_timeout was non-zero [1]. This was because ip_auto_config() initcall times out waiting for the network interfaces to show up when deferred_probe_timeout was non-zero. While ip_auto_config() calls wait_for_device_probe() to make sure any currently running deferred probe work or asynchronous probe finishes, that wasn't sufficient to account for devices being deferred until deferred_probe_timeout.
Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires") tried to fix that by making sure wait_for_device_probe() waits for deferred_probe_timeout to expire before returning.
However, if wait_for_device_probe() is called from the kernel_init() context:
Before deferred_probe_initcall() [2], it causes the boot process to hang due to a deadlock.
After deferred_probe_initcall() [3], it blocks kernel_init() from continuing till deferred_probe_timeout expires and beats the point of deferred_probe_timeout that's trying to wait for userspace to load modules.
Neither of this is good. So revert the changes to wait_for_device_probe().
[1] -https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01M... [2] -https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/ [3] -https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/
Hi Saravana, Greg,
KernelCI found this patch causes the baseline.bootrr.deferred-probe-empty test to fail on r8a77960-ulcb, see the following details for more information.
Commit 9be4cbd09da820a2 ("driver core: Set default deferred_probe_timeout back to 0.") in v5.19 contains a reference to the same commit as mentioned in the Fixes tag. Does backporting that help?
Gr{oetje,eeting}s,
Geert