lkml.org 
[lkml]   [2021]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 2/3] init/do_cmounts.c: introduce 'user_root' for initramfs
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@joshtriplett.org> 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.

Luis

\
 
 \ /
  Last update: 2021-05-26 11:04    [W:0.072 / U:1.712 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site