Re: [PATCH v2 2/3] init/do_cmounts.c: introduce 'user_root' for initramfs
From: Luis Chamberlain
Date: Wed May 26 2021 - 05:03:28 EST
On Wed, May 26, 2021 at 04:33:00PM +0800, Menglong Dong wrote:
> On Wed, May 26, 2021 at 12:33 PM Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote:
> > On Tue, May 25, 2021 at 10:23:09PM -0500, Eric W. Biederman wrote:
> > > If we are going to do this something that is so small and clean it can
> > > be done unconditionally always.
> > [...]
> > > The net request as I understand it: Make the filesystem the initramfs
> > > lives in be an ordinary filesystem so it can just be used as the systems
> > > primary filesystem.
> > Including the ability to pivot_root it away, which seems like the main
> > sticking point.
> > If this can be done without any overhead, that seems fine, but if this
> > involves mounting an extra filesystem, that may add an appreciable
> > amount of boot time for systems trying to boot in milliseconds. (Such
> > systems would not use an initramfs if they're going to go on and boot a
> > separate root filesystem, but they can use an initramfs as their *only*
> > filesystem.)
> Compared to the time the unpacking spent, a mounting seems nothing. In the
> scene above, this change can be disabled by kconfig, if pivot_root
> is not needed in initramfs.
I asked for the kconfig entry. And it would be good to document then
also the worst case expected on boot for what this could do to you. I
mean, we are opening a different evil universe. So that's why the
kconfig exists. How bad and evil can this be?
I don't think anyone has clarified that yet.