Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6064609ybf; Thu, 5 Mar 2020 12:22:09 -0800 (PST) X-Google-Smtp-Source: ADFU+vvqhkwuUefM8mqVkOEnvY0ZHk21pJ7W5P/zub5Z1XvTtnM+5oo2NBA7THviSOCRgxFFGXRj X-Received: by 2002:a9d:3df6:: with SMTP id l109mr218368otc.284.1583439729764; Thu, 05 Mar 2020 12:22:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583439729; cv=none; d=google.com; s=arc-20160816; b=cfYEge01oQD6nQ3KO26c5BSuQoLt5FV1Bf7tRWfFlwm5aY8rr74hhILgym+kcm2lJd b28lqx9xabMpPlOSRw7+AUGDiYKo0m892hIvs2J82Ru3SYYw9V58vZynW/hz6bMRvHUc YqXUghGrVnttU4kE2zEomwSvbm7kxFf0S6tbqAQA/xg2zfWfAWENmB7iAFBVllBADzaE Dy5zEyw9EC8hGrJtPXd6hUiHrKYEoYMNkGlqQo4zy0xp1jEixeEc7P2mtOhDUmV0UZU8 rk2SEd9dgsRGMg0tJySQVaW3ccNl1KCCTssX/BNoXIfA67TzNzxPgfQ3xvMvSKYJ7SWP mtTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=C1c+UV55KSrdjNizWzSBqlLIBAjwNb2ra0rZYB/75kU=; b=h1lsuHi43nwKunY4PJK/yb7mNMa3gyQzoo6aRnjW9hLFeEsmwY3lETg7yA223E7sjt VTx5evQfuLhRB/3V0RCYJdHh+QcWc3/MmXjpAgS8fj7kozPo6EeyAdJ/ryLIqvJUFQh3 lvbITxWtFB1tO7JAFRSaqsM32QZ/QjTBdrvW9Ur5f+TRh2OZ1aHUuHe+AdXMw933c1/t b/ZKbpokyvRdmd/cSN+/squRvmUtTwH/xq92KPxZQWCu6i2yssfmWXlYTmQVjs8+Naa0 sNQ8kgO3uH5b3uCps/YvYB//OAIqhiEAidYuHBnUCFL5ZSe+E+hE2kTkeXQ0EXWVyNN6 h+BA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l63si22856oig.123.2020.03.05.12.21.55; Thu, 05 Mar 2020 12:22:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726178AbgCEUV0 (ORCPT + 99 others); Thu, 5 Mar 2020 15:21:26 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:49780 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726080AbgCEUV0 (ORCPT ); Thu, 5 Mar 2020 15:21:26 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1j9wzk-005u6z-JP; Thu, 05 Mar 2020 20:21:24 +0000 Date: Thu, 5 Mar 2020 20:21:24 +0000 From: Al Viro To: Ignat Korchagin Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@cloudflare.com Subject: Re: [PATCH] mnt: add support for non-rootfs initramfs Message-ID: <20200305202124.GV23230@ZenIV.linux.org.uk> References: <20200305193511.28621-1-ignat@cloudflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200305193511.28621-1-ignat@cloudflare.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 05, 2020 at 07:35:11PM +0000, Ignat Korchagin wrote: > The main need for this is to support container runtimes on stateless Linux > system (pivot_root system call from initramfs). > > Normally, the task of initramfs is to mount and switch to a "real" root > filesystem. However, on stateless systems (booting over the network) it is just > convenient to have your "real" filesystem as initramfs from the start. > > This, however, breaks different container runtimes, because they usually use > pivot_root system call after creating their mount namespace. But pivot_root does > not work from initramfs, because initramfs runs form rootfs, which is the root > of the mount tree and can't be unmounted. > > One can solve this problem from userspace, but it is much more cumbersome. We > either have to create a multilayered archive for initramfs, where the outer > layer creates a tmpfs filesystem and unpacks the inner layer, switches root and > does not forget to properly cleanup the old rootfs. Or we need to use keepinitrd > kernel cmdline option, unpack initramfs to rootfs, run a script to create our > target tmpfs root, unpack the same initramfs there, switch root to it and again > properly cleanup the old root, thus unpacking the same archive twice and also > wasting memory, because kernel stores compressed initramfs image indefinitely. > > With this change we can ask the kernel (by specifying nonroot_initramfs kernel > cmdline option) to create a "leaf" tmpfs mount for us and switch root to it > before the initramfs handling code, so initramfs gets unpacked directly into > the "leaf" tmpfs with rootfs being empty and no need to clean up anything. IDGI. Why not simply this as the first thing from your userland: mount("/", "/", NULL, MS_BIND | MS_REC, NULL); chdir("/.."); chroot("."); 3 syscalls and you should be all set...