Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4879611pxj; Tue, 25 May 2021 19:52:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwoCX+MKnNXv398+b3NnvBr6ou1gkMJZbORQ7MAb2a2x67RhGCknMxbzJfXscytYkrclhC X-Received: by 2002:a05:6402:4414:: with SMTP id y20mr36045470eda.41.1621997567280; Tue, 25 May 2021 19:52:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621997567; cv=none; d=google.com; s=arc-20160816; b=eksq0oqpBZ0BCHpTbAybcVO8NFSHOmQYjatW+QnaWdhWCrJ1Ud+a5SFsYhsSbVRhVt NPhxPdl4nNXK1l1v6c1kc4vU+jgXeQfLCqD7xgOofLMuYLpugnF0+eRvA/gIoaAm9Gf9 fOE87IAG1yZhI7yBiEyCQGJDcKSbcB0MYId8gLq+2+b2XoQrL4FfkDmH89cKjEMTYgH9 eOx2ghaW4ChRxts9mI7CYJHS/tMxLd1JKpRXM9W7JKXpjGEX+LzX0sSC6siu5YD5zgyT 0Vk02w0DXJ7tc9Qg4KnEaLfmnSIIZ7X0G2DABv6wLA2EQiup0zUfLK2/6fXBWPB7+lAW IFiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=UAxjsIBVH89CD1bUGFbnmD6O+wclffTpv+v2E/nicMs=; b=bjFCxMjqhRLURVeuMSfTKV4LNIMRpgZpP4F5yknzg/W1XGMGZ+7/7iNxsAphoxOet0 O6gNwLdpg5yhV02tI2QcDSpCQv/6Lc7nh7rr7UlKBJOvl8jLN96DYTywV+tLKgtLBBe0 tLThcIZFIqnjVJk9zinMX7jo4LX4ylbgytPVL0EOFRy1eIQxYa89HcBNDr59tHIbPMZq w8vJonOJIfR/LGRIQiDQ4mJJ4vK0R3VPIK0cXPf2aS/xrHNVncWRy1uB6/Y12i2ertQ2 h6qKmjWjH6QiNjotVXGhKTKZxFa1kIcbNKwxSRW+IlzpG+NtPR33XkUcLH4O1JQrfjis zaXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gA1FwHT0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e9si19657301edc.514.2021.05.25.19.52.24; Tue, 25 May 2021 19:52:47 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gA1FwHT0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232895AbhEZBxN (ORCPT + 99 others); Tue, 25 May 2021 21:53:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229978AbhEZBxJ (ORCPT ); Tue, 25 May 2021 21:53:09 -0400 Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6266DC061756; Tue, 25 May 2021 18:51:37 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id i22so30670lfl.10; Tue, 25 May 2021 18:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UAxjsIBVH89CD1bUGFbnmD6O+wclffTpv+v2E/nicMs=; b=gA1FwHT0jeTJ0wJ4xQ5M/P0uoCjTonGA1/xGpROefOUJRc/Js/yQvprSfFeuNfZSbq PVt/rFt/tna1GV6/6LdMCkBEWTJEPuTOKZN8qTK2n4RuQdipL5r+qbZsB6cuc/SViiid Fw83Qf6QE/wxUEmGcu4FPgRYrE95cqtmNzNQIYq+VCB4FQgXe31E7FZqxxWLp/JQ5f3C xd7tric3D7RrCzwC3HCtx5oQzSHtPEdZdfXwRRATsTWolGgZIUafUfGBAnaI7WGfEkbE gm3Nub50jQ4BuM+vaAKsukyUGu1L899NhSQD2lwIE9TYJihsdgU4v8GUsQgT/5cipFwJ It9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UAxjsIBVH89CD1bUGFbnmD6O+wclffTpv+v2E/nicMs=; b=Q1S1OcYLi4uYdAnYb23Uh/8lISUjcpMjSXQz2/nAuAjxIhQJ8TV28cEyvaln+G/qKr K4T5W76jIeAN+yRJocVYoSO30GG0u/IXRz6iv9HGZzoVRwRhMQq9QlAzkHr7QMrrbcxQ NjTUOTmuUe/O/qF5i7t4+/7/SuDeEoWJDjG+XX9ZbDDjxt+xATkbzJ2q1Wz9hzSVDpjM RQuNAYvOPHZTd6GIqolevOe3B7mHWRp8sOa1KKhXpjl6YZ8f+Jlm70YZDkH7dOFzeRg+ i8RupvI5SxypsjSDNI3Z/2o0pNLBwkSyTkp5w37iSletV5zDTHWzWDKKV91r93vxwJTz rMwg== X-Gm-Message-State: AOAM531OEIunkQKOkPpvJTsnOlQ9g6cC/wT91u72GH5By5LSODu9EBJz Of3J+T5bpTltN7uB3JO7atGR4uF+gS+ez638vB4= X-Received: by 2002:ac2:48ba:: with SMTP id u26mr403087lfg.108.1621993894963; Tue, 25 May 2021 18:51:34 -0700 (PDT) MIME-Version: 1.0 References: <20210525141524.3995-1-dong.menglong@zte.com.cn> <20210525141524.3995-3-dong.menglong@zte.com.cn> In-Reply-To: From: Menglong Dong Date: Wed, 26 May 2021 09:51:22 +0800 Message-ID: Subject: Re: [PATCH v2 2/3] init/do_cmounts.c: introduce 'user_root' for initramfs To: "Eric W. Biederman" Cc: Luis Chamberlain , Josh Triplett , Alexander Viro , Kees Cook , Sami Tolvanen , ojeda@kernel.org, johan@kernel.org, Bjorn Helgaas , masahiroy@kernel.org, Menglong Dong , joe@perches.com, Jens Axboe , hare@suse.de, Jan Kara , tj@kernel.org, gregkh@linuxfoundation.org, song@kernel.org, NeilBrown , Andrew Morton , f.fainelli@gmail.com, arnd@arndb.de, Rasmus Villemoes , wangkefeng.wang@huawei.com, Barret Rhoden , mhiramat@kernel.org, Steven Rostedt , vbabka@suse.cz, Alexander Potapenko , pmladek@suse.com, Chris Down , jojing64@gmail.com, terrelln@fb.com, geert@linux-m68k.org, mingo@kernel.org, linux-fsdevel@vger.kernel.org, LKML , jeyu@kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 26, 2021 at 2:50 AM Eric W. Biederman wrote: > ...... > > What is the flow where docker uses an initramfs? > > Just thinking about this I am not being able to connect the dots. > > The way I imagine the world is that an initramfs will be used either > when a linux system boots for the first time, or an initramfs would > come from the distribution you are running inside a container. In > neither case do I see docker being in a position to add functionality > to the initramfs as docker is not responsible for it. > > Is docker doing something creating like running a container in a VM, > and running some directly out of the initramfs, and wanting that code > to exactly match the non-VM case? > > If that is the case I think the easy solution would be to actually use > an actual ramdisk where pivot_root works. In fact, nowadays, initramfs is widely used by embedded devices in the production environment, which makes the whole system run in ram. That make sense. First, running in ram will speed up the system. The size of the system won't be too large for embedded devices, which makes this idea work. Second, this will reduce the I/O of disk devices, which can extend the life of the disk. Third, RAM is getting cheaper. So in this scene, Docker runs directly in initramfs. > > I really don't see why it makes sense for docker to be a special > snowflake and require kernel features that no other distribution does. > > It might make sense to create a completely empty filesystem underneath > an initramfs, and use that new rootfs as the unchanging root of the > mount tree, if it can be done with a trivial amount of code, and > generally make everything cleaner. > > As this change sits it looks like a lot of code to handle a problem > in the implementation of docker. Which quite frankly will be a pain > to have to maintain if this is not a clean general feature that > other people can also use. > I don't think that it's all for docker, pivot_root may be used by other users in the above scene. It may work to create an empty filesystem, as you mentioned above. But I don't think it's a good idea to make all users, who want to use pivot_root, do that. After all, it's not friendly to users. As for the code, it may look a lot, but it's not complex. Maybe a clean up for the code I add can make it better? Thanks! Menglong Dong