Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp784744imn; Sat, 30 Jul 2022 03:01:30 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sOjgL03VctvSngecuGkjyajNewGtE52qmyRfk88AHBeKq3FoLBl3eMzBETuFBzdML/3CnJ X-Received: by 2002:a05:6a00:2307:b0:52a:d2aa:2a9c with SMTP id h7-20020a056a00230700b0052ad2aa2a9cmr7251769pfh.11.1659175290108; Sat, 30 Jul 2022 03:01:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659175290; cv=none; d=google.com; s=arc-20160816; b=r6qFgkZ5JsOchxbuFzwYqPQyWqifLjMac2ffVVGkchnlumrp0wVuaIdVLwryqYNdoW njgWB732BqfVKz498pzdjJb3stszD/cTLY3F9512J50zgq46FFtwl47Gqu2b2CHij+i4 vwfOR6FyXo8ssl/mdHNxPlKBK0bygwS5m1Zc43nHETc5pG6P6n+YFV7h3YM5e3o6UIHd PD2AxX5m/vKdQG6gUwt3DjeT9P6Np7L7NI78ne5CdJkPlkoR07XTC9cXDfjkvwwIC7bK tUNGIf41o8SHWIAfjwIr/9bmfzUMiauQEMNC7TH8dl/S4mMtY0tdKiGPmIw7OIm+ZD/U QbiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=VQvaSdst3GlNtIz5gSEbzEWnw6iJp0dnfjX2/uw4Pi0=; b=VKvv1oy31hn/bZXs+rOGysYQomD3pcESJoNmFNxN930BZP2lE9ch0CyuQbqJ3rt3Jp 95vyy4l19MrZSFiOn5enEi0o9jn9vlnNxymPx1aDNDDwrG6cz1Di56YBShpJvxCMbtAm CxU6myM67o70KkqAdVuSTfQBfo2uQTB4goCSKmQQQ4IoCPO1JeEs27CVY7d7gZHOGaw+ ngzOl1VWlfrnZp5D7HTWM1IGqOWBpqfok/RHKuyxIwvH0EvhrhYmR9l0nj8CG0EvPH3j fbSZyOO11tbXgzdIQOM4WGGZQsfoegQ5YYZGHlaesqV/CSvtnkPta/kpnOH2ESd19k3k MBvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@landley-net.20210112.gappssmtp.com header.s=20210112 header.b=WwZeLQPH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q7-20020a170902dac700b0016d4411b360si5230520plx.450.2022.07.30.03.01.13; Sat, 30 Jul 2022 03:01:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@landley-net.20210112.gappssmtp.com header.s=20210112 header.b=WwZeLQPH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234533AbiG3JcI (ORCPT + 99 others); Sat, 30 Jul 2022 05:32:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234401AbiG3JcG (ORCPT ); Sat, 30 Jul 2022 05:32:06 -0400 Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 111A242AFC for ; Sat, 30 Jul 2022 02:32:05 -0700 (PDT) Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-10e6bdbe218so8326773fac.10 for ; Sat, 30 Jul 2022 02:32:05 -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=VQvaSdst3GlNtIz5gSEbzEWnw6iJp0dnfjX2/uw4Pi0=; b=WwZeLQPHVZMv7Tf/yzouYMy/N8ncJHBvNxrLWXHyVtWxdZ1PxHorwX/QP+bQZFNbY1 rFwGJtpccThotO8bEaWew5690F3KBLjHib7+tV2wpgxvsFLNez3D6LNChyTXqofSjLSL 3t6mL4NZhitq1h4tRWJkYont7aB4p6WDw3W2nbHcvT//xibau8r6KMdHFoQnG+SQ/3rI 3j0ybuxX0FIf2CU4lpJxYEwnn2Qs8McUF9hZQ8kDHVp4HHibCyHITaH7wbRaDD6Z8BOI nolUx7bNdTsURyp6dA0MSYRIyofqMVotGVXSojpI8bVNj+lPXZDKpcXfE/3CmYrakb10 Apmw== 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=VQvaSdst3GlNtIz5gSEbzEWnw6iJp0dnfjX2/uw4Pi0=; b=EDvRyqQ+miLWinW/UtthWEA62j79YDyVnVkpWg44ek9SDlX8pxNmCeblpTWRaRvwqr MzLGp58W2ZPaHJD19JHPOxGbj86/B2gH5hFe0ZVWj1AzZc7M3I59cDF6lGYqQgadZ860 UydXDaZuNSHqqh1P0NxY5ikuji1Xo8lz9siMSPbiTC6lEcoSCjoqOYmO0HDFnC26uhgm z0pd4iEasVNY6UyJNU/BXSf9ZBUDksmS1czF4kg4u/mevgludEk6FrS+Kwz1VTmOLjit 1q9AA4HGLyst4EMP+HHZBWovGKCY4VguRdnNu33D477NEPE2yHQPdsIalRWd9TeCVJZk lz9Q== X-Gm-Message-State: AJIora9svbpBPd5gakNXucEEYM9JGYfjIO7aIX20FMc1GteQ2lMWr3zz T31Dt998cL8py9WMpCjto2Tw0w== X-Received: by 2002:a05:6870:f2a0:b0:fe:29a0:4b48 with SMTP id u32-20020a056870f2a000b000fe29a04b48mr3309674oap.183.1659173524398; Sat, 30 Jul 2022 02:32:04 -0700 (PDT) Received: from ?IPV6:2607:fb90:c2d4:35df:6680:99ff:fe6f:cb54? ([2607:fb90:c2d4:35df:6680:99ff:fe6f:cb54]) by smtp.gmail.com with ESMTPSA id q16-20020a05683033d000b0061c29a38b3bsm1633168ott.33.2022.07.30.02.32.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Jul 2022 02:32:03 -0700 (PDT) Message-ID: Date: Sat, 30 Jul 2022 04:39:13 -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: Jim Baxter , Roberto Sassu , 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> <737ddf72-05f4-a47e-c901-fec5b1dfa7a6@mentor.com> <8e6a723874644449be99fcebb0905058@huawei.com> From: Rob Landley In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/29/22 05:37, Jim Baxter 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. You are >>>> probably using ramfs, which does not have xattr support. >>>> Oh, here's the actual tested version of the patch wiring up rootfstype=tmpfs to force rootfs to be tmpfs even when you specify root= diff --git a/init/do_mounts.c b/init/do_mounts.c index 7058e14ad5f7..dedf27fe9044 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -665,7 +665,7 @@ struct file_system_type rootfs_fs_type = { void __init init_rootfs(void) { - if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] && - (!root_fs_names || strstr(root_fs_names, "tmpfs"))) + if (IS_ENABLED(CONFIG_TMPFS) && (!root_fs_names ? !saved_root_name[0] : + !!strstr(root_fs_names, "tmpfs"))) is_tmpfs = true; } Signed-in-triplicate-by: Rob Landley No idea why nobody else has fixed that bug in the past 9 years, seems obvious? Anyway, here's the testing I did using mkroot (ala https://landley.net/toybox/faq.html#mkroot): $ (cd root/x86_64; KARGS='quiet root=potato HANDOFF="/bin/head -n 1 /proc/mounts"' ./run-qemu.sh) | tail -n 3 rootfs / rootfs rw 0 0 reboot: Restarting system $ (cd root/x86_64; KARGS='quiet HANDOFF="/bin/head -n 1 /proc/mounts"' ./run-qemu.sh) | tail -n 3 rootfs / rootfs rw,size=121828k,nr_inodes=30457 0 0 reboot: Restarting system $ (cd root/x86_64; KARGS='quiet rootfstype=tmpfs root=potato HANDOFF="/bin/head -n 1 /proc/mounts"' ./run-qemu.sh) | tail -n 3 rootfs / rootfs rw,size=121828k,nr_inodes=30457 0 0 reboot: Restarting system I.E. rootfstype=tmpfs neutralized the root= so it was still tmpfs despite the kernel being explicitly told you weren't going to stay on initramfs (which is still what root= means). With just root= it's still ramfs, with all the "my log file got too big and the system livelocked" and "querying available space always returns zero" that entails. > Can I clarify which filesystem type is supported with this patch series? > Is it tmpfs or perhaps a ramdisk? I believe both tmpfs and ramfs support xattrs? (I know tmpfs does, and fs/ramfs/file-mmu.c plugs simple_getattr() into ramfs_file_operations.setattr so it looks like that would too? Haven't tried it.) This isn't a modification to the filesystem code (ramfs/tmpfs), this is a modification to the boot-time loader (initramfs) that extracts a cpio.gz file into the filesystem. Ramdisks have supported xattrs for years: they fake up a block device out of a chunk of memory and them format it and mount some other filesystem on it, meaning the driver for the other filesystem handles the xattr support. But ramdisks don't use initramfs, they load an image of the preformatted filesystem into the ramdisk block device. Completely separate mechanism, sharing no code with initramfs, depending on the block layer, etc. >>> Thank you, I have tested that patch but the problem remained. Here is my >>> command line, I wonder if there is something wrong. >>> >>> Kernel command line: rw rootfstype=initramtmpfs root=/dev/ram0 >>> initrd=0x500000000 rootwait >> >> It is just initramtmpfs, without rootfstype=. The above patch does not go on top of that patch, it's instead of. Rob