Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
To:     Luis Chamberlain <mcgrof@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>
Cc:     Jessica Yu <jeyu@kernel.org>, Borislav Petkov <bp@alien8.de>,
        Jonathan Corbet <corbet@lwn.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org,
        Nick Desaulniers <ndesaulniers@google.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: [PATCH v3 0/2] background initramfs unpacking, and CONFIG_MODPROBE_PATH
Date:   Sat, 13 Mar 2021 22:25:26 +0100
Message-Id: <20210313212528.2956377-1-linux@rasmusvillemoes.dk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

These two patches are independent, but better-together.

The second is a rather trivial patch that simply allows the developer
to change "/sbin/modprobe" to something else - e.g. the empty string,
so that all request_module() during early boot return -ENOENT early,
without even spawning a usermode helper, needlessly synchronizing with
the initramfs unpacking.

The first patch delegates decompressing the initramfs to a worker
thread, allowing do_initcalls() in main.c to proceed to the device_
and late_ initcalls without waiting for that decompression (and
populating of rootfs) to finish. Obviously, some of those later calls
may rely on the initramfs being available, so I've added
synchronization points in the firmware loader and usermodehelper paths
- there might be other places that would need this, but so far no one
has been able to think of any places I have missed.

There's not much to win if most of the functionality needed during
boot is only available as modules. But systems with a custom-made
.config and initramfs can boot faster, partly due to utilizing more
than one cpu earlier, partly by avoiding known-futile modprobe calls
(which would still trigger synchronization with the initramfs
unpacking, thus eliminating most of the first benefit).

Routing-wise, I hope akpm can handle both patches. Andrew, Luis?


v2 at <https://lore.kernel.org/lkml/20210309211700.2011017-1-linux@rasmusvillemoes.dk/>

Changes in v3:

- Make it asynchronous by default, and drop the CONFIG_ knob (Linus) -
  the command line parameter escape hatch is still there.

  With that change, it doesn't make sense to have wait_for_initramfs()
  contain a micro-optimization in the form of an early return when
  !initramfs_async.

  I've opted to always push the work to the async machinery, but then
  just do a wait_for_initramfs() in populate_rootfs when
  !initramfs_async.

  I did consider changing the name and sense of the command line
  parameter to "initramfs_sync", but decided to keep the async, since
  that's also the name of the subsystem being used.

- Add A-b, R-b to patch 2.


Rasmus Villemoes (2):
  init/initramfs.c: do unpacking asynchronously
  modules: add CONFIG_MODPROBE_PATH

 .../admin-guide/kernel-parameters.txt         | 12 ++++++
 drivers/base/firmware_loader/main.c           |  2 +
 include/linux/initrd.h                        |  2 +
 init/Kconfig                                  | 12 ++++++
 init/initramfs.c                              | 38 ++++++++++++++++++-
 init/main.c                                   |  1 +
 kernel/kmod.c                                 |  2 +-
 kernel/umh.c                                  |  2 +
 8 files changed, 69 insertions(+), 2 deletions(-)

-- 
2.29.2