From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A06FCCA481 for ; Tue, 19 Jul 2022 10:53:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237406AbiGSKxS (ORCPT ); Tue, 19 Jul 2022 06:53:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237293AbiGSKxQ (ORCPT ); Tue, 19 Jul 2022 06:53:16 -0400 Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F138402E1 for ; Tue, 19 Jul 2022 03:53:14 -0700 (PDT) Received: by mail-oo1-xc2e.google.com with SMTP id j8-20020a4ac548000000b00435a8dd31a2so607819ooq.5 for ; Tue, 19 Jul 2022 03:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=ra5x2/muxSeeSQ3tlCgpeqbladVRxJnxCPl4bJq3p34=; b=2lKKxFzSTFfoAqHkPQJOZzk9NSwhvMVfz9AI6037udC8exCOdgmjJTCzLfGNh8TiZR juF5/5iF/lwpY0I4eBxOM7ch26XEY1pzvru00V28d56VKmfDdmUC/dvbNUXfD/GneoTj e62bDsHZKQ06qjQfN6BdAPe8q7wMqzTya9y9Oxq/85+9tv+FEcRChm48xzwJ+vVtJutJ ocu7WYAHxW+9letk5IuqILyJfJ0omA9TYCGqGI3ZW12BP0J1uMrdUw4g3mf6Dnq9iC2d KIoG/xTswyWySLrhFnRZ2Qa4cNrCubzn949cy5pGWP6ba+vFmgIdE/fnF+KPaKPeGBQd k/Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=ra5x2/muxSeeSQ3tlCgpeqbladVRxJnxCPl4bJq3p34=; b=YZxCuIoaD4JNRqasUtVmOg0E5pF6SzCErL5gLG35Ja7ALeYoGPUDdd9IS+iQVz81Ot G9TI3bNHfjfO7ZywCu2qlqW80GVbr/fJrmca68UYknKDukSHs3u+vg6SmvxjOtEO5xjz KcR2vmp1lh2JBAApfGsD5WM7ZXKIEAsinFWDPmVtR4XJcaOqh/9cLIGJ6kbEIdgQI6y8 2QIcltogCUEGC/hkWF6eFsuFbfSHs9XzfK83WBsC7kLc8tdIzUX8E9QWyDlsiHgHrTpr J3S5toycowWG6mtwtXjKDf/E0sR4NyHxNzJKMjrf2cmGucgU3+N4MqzCsQt9qePCCUoW 3TCg== X-Gm-Message-State: AJIora+XddSD5QzvYKWuVR49nlA5HBRYgpIZIkNCrkIdtEs0FsxF4ChO IugSgnUcoYYm+qb7hH8pVXfkoQ== X-Google-Smtp-Source: AGRyM1skx4r10nH77MIc8HT+KMfyvuczcqHU0I1yhcm68ijpwQjC9CRg6tXM26btMYm29jvYGotkYg== X-Received: by 2002:a4a:864b:0:b0:425:71ed:ada7 with SMTP id w11-20020a4a864b000000b0042571edada7mr10923632ooh.92.1658227993382; Tue, 19 Jul 2022 03:53:13 -0700 (PDT) Received: from [192.168.86.210] ([136.62.38.22]) by smtp.gmail.com with ESMTPSA id cg4-20020a056830630400b0061c7ac52b75sm5901958otb.26.2022.07.19.03.53.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Jul 2022 03:53:12 -0700 (PDT) Message-ID: <99ae4aa6-b55a-55a9-e836-b0b483a358d6@landley.net> Date: Tue, 19 Jul 2022 06:00:04 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v4 0/3] initramfs: add support for xattrs in the initial ram disk Content-Language: en-US To: Roberto Sassu , Jim Baxter , Eugeniu Rosca Cc: "hpa@zytor.com" , Masahiro Yamada , Arvind Sankar , Mimi Zohar , "viro@zeniv.linux.org.uk" , "linux-security-module@vger.kernel.org" , "linux-integrity@vger.kernel.org" , "initramfs@vger.kernel.org" , "linux-api@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "bug-cpio@gnu.org" , "zohar@linux.vnet.ibm.com" , Silviu Vlasceanu , Dmitry Kasatkin , "takondra@cisco.com" , "kamensky@cisco.com" , "arnd@arndb.de" , "james.w.mcmechan@gmail.com" , "linux-kbuild@vger.kernel.org" , Dirk Behme , Eugeniu Rosca References: <33cfb804-6a17-39f0-92b7-01d54e9c452d@huawei.com> <1561909199.3985.33.camel@linux.ibm.com> <45164486-782f-a442-e442-6f56f9299c66@huawei.com> <1561991485.4067.14.camel@linux.ibm.com> <0c17bf9e-9b0b-b067-cf18-24516315b682@huawei.com> <20220609102627.GA3922@lxhi-065> <21b3aeab20554a30b9796b82cc58e55b@huawei.com> <20220610153336.GA8881@lxhi-065> <4bc349a59e4042f7831b1190914851fe@huawei.com> <20220615092712.GA4068@lxhi-065> <032ade35-6eb8-d698-ac44-aa45d46752dd@mentor.com> From: Rob Landley In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: On 7/18/22 11:49, Roberto Sassu wrote: > Uhm, I guess this could be solved with: > > https://github.com/openeuler-mirror/kernel/commit/18a502f7e3b1de7b9ba0c70896ce08ee13d052da > > and adding initramtmpfs to the kernel command line. It's initmpfs. You can argue about whether it should have two t's (I was consistent naming it in the patch series adding it), but ramfs and tmpfs are two different things and saying "initramtmpfs" is like saying "mount -t ext4btrfs". > You are probably using ramfs, which does not have xattr support. Do not specify root= in your kernel command line. If you specify root= you're saying "switch off of initramfs to a different root filesystem", so it doesn't make the overmounted filesystem tmpfs because you told it you wouldn't be using it. (The decision of what to mount has to be made before it examines the cpio.gz contents, so root= is used to signal "we are not keeping this initramfs" because that's literally what root= means. Your root filesystem is not initramfs, it is instead this thing to be mounted over initramfs.) You can tell which you're using via /proc/mounts having a line: rootfs / rootfs rw,size=121832k,nr_inodes=30458 0 0 If it's got the size= then it's tmpfs: ramfs basically doesn't have bounds checking and "cat /dev/null > filename" on ramfs will lock your system solid due to unpinnable memory exhaustion. If you don't have a "rootfs" line at ALL then root= was used to overmount and part of the gratuitously magic behavior of root= is it hides the rootfs line from /proc/mounts even though the filesystem is actually still there, which is not something it does for ANY OTHER OVERMOUNT: $ mkdir sub $ mount -t proc proc sub $ mount -t ramfs sub sub $ grep sub /proc/mounts proc /sub proc rw,relatime 0 0 sub /sub ramfs rw,relatime 0 0 I've never understood why they added that gratuitous special case to hide how the system actually works, but it's a land mine you have to be told about after you've stepped on it in order to understand what's going on. Part of the reason people think initramfs is so "magic" when PID 1 isn't, we don't HIDE the fact that PID 1 is always there but we hide the fact initramfs is... Rob