From: Luis Chamberlain <mcgrof@kernel.org>
To: Menglong Dong <menglong8.dong@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Jens Axboe <axboe@kernel.dk>,
hare@suse.de, gregkh@linuxfoundation.org, tj@kernel.org,
Menglong Dong <dong.menglong@zte.com.cn>,
song@kernel.org, neilb@suse.de,
Andrew Morton <akpm@linux-foundation.org>,
wangkefeng.wang@huawei.com, f.fainelli@gmail.com, arnd@arndb.de,
Barret Rhoden <brho@google.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
mhiramat@kernel.org, Steven Rostedt <rostedt@goodmis.org>,
Kees Cook <keescook@chromium.org>,
vbabka@suse.cz, Alexander Potapenko <glider@google.com>,
pmladek@suse.com, Chris Down <chris@chrisdown.name>,
ebiederm@xmission.com, jojing64@gmail.com,
LKML <linux-kernel@vger.kernel.org>,
palmerdabbelt@google.com, linux-fsdevel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH RESEND] init/initramfs.c: make initramfs support pivot_root
Date: Fri, 21 May 2021 15:50:20 +0000 [thread overview]
Message-ID: <20210521155020.GW4332@42.do-not-panic.com> (raw)
In-Reply-To: <CADxym3axowrQWz3OgimK4iGqP-RbO8U=HPODEhJRrcXUAsWXew@mail.gmail.com>
On Fri, May 21, 2021 at 08:41:55AM +0800, Menglong Dong wrote:
> Hello!
>
> Thanks for your reply!
>
> On Fri, May 21, 2021 at 5:41 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > Can't docker instead allow to create containers prior to creating
> > your local docker network namespace? Not that its a great solution,
> > but just worth noting.
> >
>
> That's a solution, but I don't think it is feasible. Users may create many
> containers, and you can't make docker create all the containers first
> and create network namespace later, as you don't know if there are any
> containers to create later.
It doesn't seem impossible, but worth noting why inside the commit log
this was not a preferred option.
> > > struct file_system_type rootfs_fs_type = {
> > > .name = "rootfs",
> > > - .init_fs_context = rootfs_init_fs_context,
> > > + .init_fs_context = ramfs_init_fs_context,
> >
> > Why is this always static now? Why is that its correct
> > now for init_mount_tree() always to use the ramfs context?
>
> Because the root mount in init_mount_tree() is not used as rootfs any more.
We still have:
start_kernel() --> vfs_caches_init() --> mnt_init() -->
mnt_init()
{
...
shmem_init();
init_rootfs();
init_mount_tree();
}
You've now modified init_rootfs() to essentially just set the new user_root,
and that's it. But we stil call init_mount_tree() even if we did set the
rootfs to use tmpfs.
> In do_populate_ro
> tmpfs, and that's the real rootfs for initramfs. And I call this root
> as 'user_root',
> because it is created for user space.
>
> int __init mount_user_root(void)
> {
> return do_mount_root(user_root->dev_name,
> user_root->fs_name,
> root_mountflags,
> root_mount_data);
> }
>
> In other words, I moved the realization of 'rootfs_fs_type' here to
> do_populate_rootfs(), and fixed this 'rootfs_fs_type' with
> ramfs_init_fs_context, as it is a fake root now.
do_populate_rootfs() is called from populate_rootfs() and that in turn
is a:
rootfs_initcall(populate_rootfs);
In fact the latest changes have made this to schedule asynchronously as
well. And so indeed, init_mount_tree() always kicks off first. So its
still unclear to me why the first mount now always has a fs context of
ramfs_init_fs_context, even if we did not care for a ramdisk.
Are you suggesting it can be arbitrary now?
> Now, the rootfs that user space used is separated with the init_task,
> and that's exactly what a block root file system does.
The secondary effort is a bit clearer, its the earlier part that is not
so clear yet to me at least.
Regardless, to help make the changes easier to review, I wonder if it
makes sense to split up your work into a few patches. First do what you
have done for init_rootfs() and the structure you added to replace the
is_tmpfs bool, and let initialization use it and the context. And then
as a second patch introduce the second mount effort.
Luis
next prev parent reply other threads:[~2021-05-21 15:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-20 15:42 [PATCH RESEND] init/initramfs.c: make initramfs support pivot_root menglong8.dong
2021-05-20 21:41 ` Luis Chamberlain
2021-05-21 0:41 ` Menglong Dong
2021-05-21 15:50 ` Luis Chamberlain [this message]
2021-05-22 4:09 ` Menglong Dong
2021-05-24 22:58 ` Luis Chamberlain
2021-05-25 0:55 ` Menglong Dong
2021-05-25 1:43 ` Luis Chamberlain
2021-05-25 6:09 ` Menglong Dong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210521155020.GW4332@42.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=brho@google.com \
--cc=chris@chrisdown.name \
--cc=dong.menglong@zte.com.cn \
--cc=ebiederm@xmission.com \
--cc=f.fainelli@gmail.com \
--cc=glider@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hare@suse.de \
--cc=jack@suse.cz \
--cc=jojing64@gmail.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=menglong8.dong@gmail.com \
--cc=mhiramat@kernel.org \
--cc=neilb@suse.de \
--cc=palmerdabbelt@google.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=wangkefeng.wang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).