Message ID | 20231031154417.621742-1-stefanb@linux.ibm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b90f:0:b0:403:3b70:6f57 with SMTP id t15csp330869vqg; Tue, 31 Oct 2023 08:44:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFeog5Ly2ZAH5rbrcW9tr1Hl0AxWvwLGPkhqbX9TgDsbCXgOT2H+giOw47tmhfoE/H0ZHtX X-Received: by 2002:a05:6a00:2d94:b0:6be:4228:698b with SMTP id fb20-20020a056a002d9400b006be4228698bmr11468141pfb.20.1698767091660; Tue, 31 Oct 2023 08:44:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698767091; cv=none; d=google.com; s=arc-20160816; b=BB+6iGLEX4Bd5LCjP1UTrk29NhNznhdWUVt9L7Bh5auOWRQ1WwiEcg8U5byUyXsFiC pZ/tqpXOCaoasJNthlQiyGh3T8f3j8Hk90hQHq38G7nCpst39oPpFy4nENXVeCU8GbvJ dybbbpPw6tIEBDT9RoF+AkdGddLoqKm8+bqTzfAYqHPfvF5NPm0YIJhYKYy6HNUQ0mkD mgDzcHqhFqubwSxBuLd6wBhkg137V8yNf56VVp9UqU+StZtC2fYndq07GOonhKcbAeza eWurY3CfWM1FWlJ9A0Z0DmaDaKfO+LUwUVgQMJR8OZrWA9W5DJsHOcYWIDGw5XS/o+MH 41kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=hcPfPdzQdn3iAnwDyKZq0p0knBZPODiqUl2zgguD4uU=; fh=OWz0Rs/F8UfwO7UIHv4rH9XSlaVGtfEPC5lA85AYmBw=; b=LJEeM4Xox57nbv7eOIyuxoaMDMAoJKTKG7zm875Ztx7kX/QOYxF8wsr6Z9vs7vBcFY kFhJO3P+GA+BYZmxYqNuZHSyao+MIdEv5lchISFTzXj/+a4OBoRxRzzrBgjqXj9Gs4lg Lr9Mbe0Og3+OZEln75FtnKbmMHzpr9QYr1VcOZT2MQip1K3h7bqnvWfXannjDgjNwtVu xRphdnQ7jAYfCQwDuLSP9HbaweHjPEbNKJujV1Taj0AlTqDc0zTTHPU53yIDYA8nW6Ei 3UIBiQ/Zw+ehGWPAT4AvPrwY762orl4ZFE0KaqkOKYmLrEu6zD/juyM06jRKGUSNcMNp Bk0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=jMSYpk2b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id b3-20020aa78ec3000000b0068fce4338bdsi1149472pfr.62.2023.10.31.08.44.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 08:44:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=jMSYpk2b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 7A530802F56D; Tue, 31 Oct 2023 08:44:49 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231131AbjJaPok (ORCPT <rfc822;chrisjones.unixmen@gmail.com> + 33 others); Tue, 31 Oct 2023 11:44:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229544AbjJaPoj (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 31 Oct 2023 11:44:39 -0400 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E71248F for <linux-kernel@vger.kernel.org>; Tue, 31 Oct 2023 08:44:36 -0700 (PDT) Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39VFErFP011868; Tue, 31 Oct 2023 15:44:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding; s=pp1; bh=hcPfPdzQdn3iAnwDyKZq0p0knBZPODiqUl2zgguD4uU=; b=jMSYpk2bN7uISar83gP/SOJeylP+OPj3Hf2sgSkBM8WA8qDSfdsSpMgp36XYndJy7c8Y k0ZnysmWn9cHjpHKVaqPZ+0DB1iviLU3qjckjtTFQwxAGN3aZesGHQvN3eb4Oeqakt+B r+Gk/DX1mNL0PrYWDrCx5uOLjS5UMkEglkR1uFhA+8Voa7K2HI260kcm0f2AUEvxTnWG +75UA40W2csDkKH2qGQI1FfbtFpZLDH5gmXb+1xmyMcnSPjI2yA/kzVE+9r3aAmkmjMC RaFCCiw3KSx7JIrT07QgiYEQdjOBsX1OYBPsvaLFUnjKhrXnmVRiCrkDIFo3XuzUkbY5 rA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3u33qn1w1s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Oct 2023 15:44:24 +0000 Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 39VFF1Qp012731; Tue, 31 Oct 2023 15:44:23 GMT Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3u33qn1w1a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Oct 2023 15:44:23 +0000 Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 39VEH4It011310; Tue, 31 Oct 2023 15:44:23 GMT Received: from smtprelay04.wdc07v.mail.ibm.com ([172.16.1.71]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 3u1euk16f6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Oct 2023 15:44:22 +0000 Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay04.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 39VFiL4J36831698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 31 Oct 2023 15:44:21 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 841AA58065; Tue, 31 Oct 2023 15:44:21 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D00CD5805D; Tue, 31 Oct 2023 15:44:20 +0000 (GMT) Received: from sbct-3.pok.ibm.com (unknown [9.47.158.153]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP; Tue, 31 Oct 2023 15:44:20 +0000 (GMT) From: Stefan Berger <stefanb@linux.ibm.com> To: linux-kernel@vger.kernel.org Cc: Stefan Berger <stefanb@linux.ibm.com>, "Milton D. Miller II" <mdmii@outlook.com>, Rob Landley <rob@landley.net>, Jeff Layton <jlayton@kernel.org>, Jens Axboe <axboe@kernel.dk>, Jim Cromie <jim.cromie@gmail.com>, Sam Ravnborg <sam@ravnborg.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Eric W. Biederman" <ebiederm@xmission.com>, Alexander Viro <viro@zeniv.linux.org.uk>, "H. Peter Anvin" <hpa@zytor.com>, Mimi Zohar <zohar@linux.ibm.com> Subject: [RFC PATCH] rootfs: Use tmpfs for rootfs even if root= is given Date: Tue, 31 Oct 2023 11:44:17 -0400 Message-ID: <20231031154417.621742-1-stefanb@linux.ibm.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 2LrlqeqYgtB4SLYojPQI_PGG228vNGTn X-Proofpoint-GUID: Xd9rqnfNRXDAGVBAN3DYBn_YOMaZETdg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-31_02,2023-10-31_03,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 mlxlogscore=795 clxscore=1011 malwarescore=0 impostorscore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310240000 definitions=main-2310310125 X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 31 Oct 2023 08:44:49 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781286401703287321 X-GMAIL-MSGID: 1781286401703287321 |
Series |
[RFC] rootfs: Use tmpfs for rootfs even if root= is given
|
|
Commit Message
Stefan Berger
Oct. 31, 2023, 3:44 p.m. UTC
rootfs currently does not use tmpfs if the root= boot option is passed
even though the documentation about rootfs (added in 6e19eded3684) in
Documentation/filesystems/ramfs-rootfs-initramfs.rst states:
If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by
default. To force ramfs, add "rootfstype=ramfs" to the kernel command
line.
However, this currently does not work when root= is passed on the boot
command line since then saved_root_name contains a string and prevents
usage of tmpfs. Therefore, remove the check on saved_root_name to
enable tmpfs for rootfs.
Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= specified")
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Cc: "Milton D. Miller II" <mdmii@outlook.com>
Cc: Rob Landley <rob@landley.net>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Jim Cromie <jim.cromie@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
---
init/do_mounts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, Oct 31, 2023 at 11:44:17AM -0400, Stefan Berger wrote: > rootfs currently does not use tmpfs if the root= boot option is passed > even though the documentation about rootfs (added in 6e19eded3684) in > Documentation/filesystems/ramfs-rootfs-initramfs.rst states: > > If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by > default. To force ramfs, add "rootfstype=ramfs" to the kernel command > line. At this point in time, is there even any difference between ramfs and tmpfs anymore? Why would you want to choose one over the other here? thanks, greg k-h
On October 31, 2023 10:11:01 AM PDT, Stefan Berger <stefanb@linux.ibm.com> wrote: > >On 10/31/23 12:56, Greg Kroah-Hartman wrote: >> On Tue, Oct 31, 2023 at 11:44:17AM -0400, Stefan Berger wrote: >>> rootfs currently does not use tmpfs if the root= boot option is passed >>> even though the documentation about rootfs (added in 6e19eded3684) in >>> Documentation/filesystems/ramfs-rootfs-initramfs.rst states: >>> >>> If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by >>> default. To force ramfs, add "rootfstype=ramfs" to the kernel command >>> line. >> At this point in time, is there even any difference between ramfs and >> tmpfs anymore? Why would you want to choose one over the other here? > >CONFIG_TPMFS_XATTRS allows us to set xattrs, such as security.ima. > > Stefan > >> >> thanks, >> >> greg k-h Why do we even keep ramfs as a standalone file system? To guarantee it cannot be swapped out? Does anyone actually use it?
On 10/31/23 16:33, H. Peter Anvin wrote: > On October 31, 2023 10:11:01 AM PDT, Stefan Berger <stefanb@linux.ibm.com> wrote: >> >> On 10/31/23 12:56, Greg Kroah-Hartman wrote: >>> On Tue, Oct 31, 2023 at 11:44:17AM -0400, Stefan Berger wrote: >>>> rootfs currently does not use tmpfs if the root= boot option is passed >>>> even though the documentation about rootfs (added in 6e19eded3684) in >>>> Documentation/filesystems/ramfs-rootfs-initramfs.rst states: >>>> >>>> If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by >>>> default. To force ramfs, add "rootfstype=ramfs" to the kernel command >>>> line. >>> At this point in time, is there even any difference between ramfs and >>> tmpfs anymore? Why would you want to choose one over the other here? >> >> CONFIG_TPMFS_XATTRS allows us to set xattrs, such as security.ima. >> >> Stefan >> >>> >>> thanks, >>> >>> greg k-h > Why do we even keep ramfs as a standalone file system? To guarantee it cannot be swapped out? Does anyone actually use it? Probably all machines that have root= on the boot command line use it...
On 10/31/23 11:56, Greg Kroah-Hartman wrote: > On Tue, Oct 31, 2023 at 11:44:17AM -0400, Stefan Berger wrote: >> rootfs currently does not use tmpfs if the root= boot option is passed >> even though the documentation about rootfs (added in 6e19eded3684) in >> Documentation/filesystems/ramfs-rootfs-initramfs.rst states: >> >> If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by >> default. To force ramfs, add "rootfstype=ramfs" to the kernel command >> line. > > At this point in time, is there even any difference between ramfs and > tmpfs anymore? Why would you want to choose one over the other here? I submitted a patch to fix this to the list multiple times, which got ignored as always. Most recently here: https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/ Rob
On 11/1/23 07:35, Rob Landley wrote: > On 10/31/23 11:56, Greg Kroah-Hartman wrote: >> On Tue, Oct 31, 2023 at 11:44:17AM -0400, Stefan Berger wrote: >>> rootfs currently does not use tmpfs if the root= boot option is passed >>> even though the documentation about rootfs (added in 6e19eded3684) in >>> Documentation/filesystems/ramfs-rootfs-initramfs.rst states: >>> >>> If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by >>> default. To force ramfs, add "rootfstype=ramfs" to the kernel command >>> line. >> >> At this point in time, is there even any difference between ramfs and >> tmpfs anymore? Why would you want to choose one over the other here? > > I submitted a patch to fix this to the list multiple times, which got ignored as > always. Most recently here: > > https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/ I just tried it with your patch and the machine I am using this with (OpenBMC) uses the boot command line 'console=ttyS4,115200n8 root=/dev/ram rw'. When I append rootfstype=tmpfs to this boot command line then it starts actually using tmpfs. So I think this would work for me. I can add my Tested-by tag to the patch if this helps to get it merged. Ideally it would also propagate back with a Fixes tag... Stefan > > Rob
On 11/1/23 07:35, Rob Landley wrote: > On 10/31/23 11:56, Greg Kroah-Hartman wrote: >> On Tue, Oct 31, 2023 at 11:44:17AM -0400, Stefan Berger wrote: >>> rootfs currently does not use tmpfs if the root= boot option is passed >>> even though the documentation about rootfs (added in 6e19eded3684) in >>> Documentation/filesystems/ramfs-rootfs-initramfs.rst states: >>> >>> If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by >>> default. To force ramfs, add "rootfstype=ramfs" to the kernel command >>> line. >> >> At this point in time, is there even any difference between ramfs and >> tmpfs anymore? Why would you want to choose one over the other here? > > I submitted a patch to fix this to the list multiple times, which got ignored as > always. Most recently here: > > https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/ Everyone, I now responded to Rob's patch over here: https://lkml.org/lkml/2023/11/1/333 > > Rob
On Wed, Nov 01, 2023 at 10:16:37AM -0400, Stefan Berger wrote: > > > On 11/1/23 07:35, Rob Landley wrote: > > On 10/31/23 11:56, Greg Kroah-Hartman wrote: > > > On Tue, Oct 31, 2023 at 11:44:17AM -0400, Stefan Berger wrote: > > > > rootfs currently does not use tmpfs if the root= boot option is passed > > > > even though the documentation about rootfs (added in 6e19eded3684) in > > > > Documentation/filesystems/ramfs-rootfs-initramfs.rst states: > > > > > > > > If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by > > > > default. To force ramfs, add "rootfstype=ramfs" to the kernel command > > > > line. > > > > > > At this point in time, is there even any difference between ramfs and > > > tmpfs anymore? Why would you want to choose one over the other here? > > > > I submitted a patch to fix this to the list multiple times, which got ignored as > > always. Most recently here: > > > > https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/ > > Everyone, > I now responded to Rob's patch over here: > https://lkml.org/lkml/2023/11/1/333 Note, we can't do anything with lkml.org links, they don't even work at times, please always use lore.kernel.org Also, one patch out of a longer series also will not work as we can't pick it up from there either. Can someone resend it, as a stand-alone patch, with the proper people cc:ed and then we can handle that. You all know this... thanks, greg k-h > > > > > > Rob
On Wed, 2023-11-01 at 15:28 +0100, Greg Kroah-Hartman wrote: > On Wed, Nov 01, 2023 at 10:16:37AM -0400, Stefan Berger wrote: > > > > > > On 11/1/23 07:35, Rob Landley wrote: > > > On 10/31/23 11:56, Greg Kroah-Hartman wrote: > > > > On Tue, Oct 31, 2023 at 11:44:17AM -0400, Stefan Berger wrote: > > > > > rootfs currently does not use tmpfs if the root= boot option is passed > > > > > even though the documentation about rootfs (added in 6e19eded3684) in > > > > > Documentation/filesystems/ramfs-rootfs-initramfs.rst states: > > > > > > > > > > If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by > > > > > default. To force ramfs, add "rootfstype=ramfs" to the kernel command > > > > > line. > > > > > > > > At this point in time, is there even any difference between ramfs and > > > > tmpfs anymore? Why would you want to choose one over the other here? > > > > > > I submitted a patch to fix this to the list multiple times, which got ignored as > > > always. Most recently here: > > > > > > https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/ > > > > Everyone, > > I now responded to Rob's patch over here: > > https://lkml.org/lkml/2023/11/1/333 > > Note, we can't do anything with lkml.org links, they don't even work at > times, please always use lore.kernel.org > > Also, one patch out of a longer series also will not work as we can't > pick it up from there either. > > Can someone resend it, as a stand-alone patch, with the proper people > cc:ed and then we can handle that. You all know this... The initramfs@vger.kernel.org mailing list should be Cc'ed as well.
On 11/1/23 07:11, Stefan Berger wrote: > On 11/1/23 07:35, Rob Landley wrote: >> On 10/31/23 11:56, Greg Kroah-Hartman wrote: >>> On Tue, Oct 31, 2023 at 11:44:17AM -0400, Stefan Berger wrote: >>>> rootfs currently does not use tmpfs if the root= boot option is passed >>>> even though the documentation about rootfs (added in 6e19eded3684) in >>>> Documentation/filesystems/ramfs-rootfs-initramfs.rst states: >>>> >>>> If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by >>>> default. To force ramfs, add "rootfstype=ramfs" to the kernel command >>>> line. >>> >>> At this point in time, is there even any difference between ramfs and >>> tmpfs anymore? Why would you want to choose one over the other here? >> >> I submitted a patch to fix this to the list multiple times, which got ignored as >> always. Most recently here: >> >> https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/ > > I just tried it with your patch and the machine I am using this with > (OpenBMC) uses the boot command line 'console=ttyS4,115200n8 > root=/dev/ram rw'. When I append rootfstype=tmpfs to this boot command > line then it starts actually using tmpfs. So I think this would work for me. > I can add my Tested-by tag to the patch if this helps to get it merged. > Ideally it would also propagate back with a Fixes tag... Regarding the "why ramfs" question, one bug report I periodically get is people using initramfs.cpio.gz that works on ramfs but fails to extract when they try tmpfs, and the reason is tmpfs defaults to size=50% of memory and their archive extracts to more than that. Since ramfs hasn't got a limit, it extracted and ran fine (generally a dedicated init app doing its IoT thing) and so far they've always gone back to ramfs as their fix. I vaguely recall I had some todo item to let them supply arguments so they could specify their own size= for initmpfs (ramfs doesn't take any so it hadn't been wired up last time I looked), but somewhere between https://lkml.org/lkml/2016/6/22/686 and https://lkml.iu.edu/hypermail/linux/kernel/2302.2/05597.html still being out of tree 7 years later I kind of lost interest... Rob
On Wed, 2023-11-01 at 06:35 -0500, Rob Landley wrote: > On 10/31/23 11:56, Greg Kroah-Hartman wrote: > > On Tue, Oct 31, 2023 at 11:44:17AM -0400, Stefan Berger wrote: > >> rootfs currently does not use tmpfs if the root= boot option is passed > >> even though the documentation about rootfs (added in 6e19eded3684) in > >> Documentation/filesystems/ramfs-rootfs-initramfs.rst states: > >> > >> If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by > >> default. To force ramfs, add "rootfstype=ramfs" to the kernel command > >> line. > > > > At this point in time, is there even any difference between ramfs and > > tmpfs anymore? Why would you want to choose one over the other here? > > I submitted a patch to fix this to the list multiple times, which got ignored as > always. Most recently here: > > https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/ Rob, the patch set wasn't upstreamed, but it certainly wasn't ignored. There were multiple comments. Can you at least re-post "[PATCH 5/5] fix rootfstype=tmpfs" after addressing the checkpatch.pl complaints?
diff --git a/init/do_mounts.c b/init/do_mounts.c index 5dfd30b13f48..6567cf5807ee 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -510,7 +510,7 @@ struct file_system_type rootfs_fs_type = { void __init init_rootfs(void) { - if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] && + if (IS_ENABLED(CONFIG_TMPFS) && (!root_fs_names || strstr(root_fs_names, "tmpfs"))) is_tmpfs = true; }