Message ID | 20231120011248.396012-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:9910:0:b0:403:3b70:6f57 with SMTP id i16csp1917646vqn; Sun, 19 Nov 2023 17:13:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IGyy0dI2wbWvJu2xNz+0BUYOEQJPhnKbRORVJjzK8khV1u97B+ZnDwqUH9Ez3kA5cSh5R/0 X-Received: by 2002:a05:6a20:d907:b0:187:703a:8658 with SMTP id jd7-20020a056a20d90700b00187703a8658mr5545042pzb.59.1700442813487; Sun, 19 Nov 2023 17:13:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700442813; cv=none; d=google.com; s=arc-20160816; b=jLffIbwqgNdLqpcZ2ZCkdqXlQsMieb0AOUkJ3t2KdxsmWk0qvnUBJ54RWZC/jIDpk/ 8rCd+iLjc31hfxa/RmUwlw9XvOLVXRESqkrI5BX63pD5+nbY2wKdeF9qQ1KxXGwxWMKo OMz7ExN7vX5lQDlukSVL/N8Tr1RAPiTR2GAv9vByfpFGOMLLloaTSRRUyswFJyq1otno QHAW4wFYBfYtzb8iFLxUdn5Ay5hPA7irSaGlUn2kp4L35PEwTEvmHeVjMTU1lxkry7VG qzIQE6uhTEC6l2y7NaDvWhdDmozlT1qO3ZP5DoQGWGwb7jGpA6DaKlv1N2m3v0RuHaA5 cDJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :message-id:date:subject:cc:to:from:dkim-signature; bh=DT0NjgV5bxTqZenYJx9JCksF59hQvQ1XZaCB+iwtkUA=; fh=BoSMAoIsEK+kuEv1Dr7FyP4Fb69cOvADIn+ejEzByf4=; b=Oafy8Bi4ypUKS2CYuGXYjH9M9KbdERNPFCWQ9oAloc7BmsvebJEsvjBtijJiLoLMhr 64jxbauikbbHwTfciOKUG/rLdtnATFcBf3vF5CIQCWnSvoarL20sBFuGNwRsa8NEiTlD +v//sUrF3CySCfLM3dmdzb1gYsuExX5QYyHD2dGLhfWv5ZL7e95yfHpQLzwkLTnwtABf yUuoICCYRk5v8ZY0pte2dAsSevEHTUkHrF2gVEFkhNGGgM4DDAUPQLj5eRrmZeFOHidN 98s6RWD+r+wUcxMzrnbn3q6x1n+P9yiB24/kvAlfHjDM/AZmIb809Za76fPcGaxiuySs Iz8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=eVyOuf3r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 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. [23.128.96.33]) by mx.google.com with ESMTPS id y20-20020a056a00191400b006c4b01d5f85si7426250pfi.16.2023.11.19.17.13.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Nov 2023 17:13:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=eVyOuf3r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 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 37BCD80615D1; Sun, 19 Nov 2023 17:13:31 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231633AbjKTBNH (ORCPT <rfc822;lhua1029@gmail.com> + 28 others); Sun, 19 Nov 2023 20:13:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229470AbjKTBNG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 19 Nov 2023 20:13:06 -0500 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 473D0115; Sun, 19 Nov 2023 17:13:01 -0800 (PST) Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3AJNINxM025177; Mon, 20 Nov 2023 01:12:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : content-transfer-encoding : mime-version; s=pp1; bh=DT0NjgV5bxTqZenYJx9JCksF59hQvQ1XZaCB+iwtkUA=; b=eVyOuf3rxoTn8YNF+cZzvSmbbgcMosqKP1zoewRN9gprgpOchxUw6BnIqg6j6X9RaFRQ d+x31Jo7WoBxvzIBYG1w0+PDc4AHe5mtYtO1wjXViKhIWp6yVs73B//fwciYRy6gtHXE sW8PYsuZ+zbpOJTa1tewYWxYSVDPaoMKwRSaKb3D41w072AERjgYJxfk8Y1U2eGaT6Pd Ugpsp0Eq8MzXYcg0nL2wQQrg0jChGYtASN2hgBWi31b4OzL6o2vf54r6nS+cEHhUi6qd 69aGI+8iRvtsqy5OLzNX1Fnl34J0uyRZh2EHBIZ0E8FNutCWO1unhJxf28PUnx40dQKS WA== Received: from ppma23.wdc07v.mail.ibm.com (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ufuwrseka-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Nov 2023 01:12:58 +0000 Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1]) by ppma23.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3AJM1s7F026556; Mon, 20 Nov 2023 01:12:58 GMT Received: from smtprelay06.wdc07v.mail.ibm.com ([172.16.1.73]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3uf93kdv9q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Nov 2023 01:12:58 +0000 Received: from smtpav01.dal12v.mail.ibm.com (smtpav01.dal12v.mail.ibm.com [10.241.53.100]) by smtprelay06.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3AK1CvEc26542732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Nov 2023 01:12:57 GMT Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 413FF58057; Mon, 20 Nov 2023 01:12:57 +0000 (GMT) Received: from smtpav01.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C5D7058058; Mon, 20 Nov 2023 01:12:56 +0000 (GMT) Received: from sbct-3.pok.ibm.com (unknown [9.47.158.153]) by smtpav01.dal12v.mail.ibm.com (Postfix) with ESMTP; Mon, 20 Nov 2023 01:12:56 +0000 (GMT) From: Stefan Berger <stefanb@linux.ibm.com> To: linux-kernel@vger.kernel.org Cc: zohar@linux.ibm.com, gregkh@linuxfoundation.org, initramfs@vger.kernel.org, Stefan Berger <stefanb@linux.ibm.com>, stable@vger.kernel.org, Rob Landley <rob@landley.net> Subject: [PATCH v3] rootfs: Fix support for rootfstype= when root= is given Date: Sun, 19 Nov 2023 20:12:48 -0500 Message-ID: <20231120011248.396012-1-stefanb@linux.ibm.com> X-Mailer: git-send-email 2.41.0 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: fLdhSeQwbeQka2ezh3TsY4brwYxLYmKq X-Proofpoint-GUID: fLdhSeQwbeQka2ezh3TsY4brwYxLYmKq Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 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-11-19_21,2023-11-17_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 phishscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 spamscore=0 clxscore=1015 suspectscore=0 mlxscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311200007 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]); Sun, 19 Nov 2023 17:13:31 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783043523847455965 X-GMAIL-MSGID: 1783043523847455965 |
Series |
[v3] rootfs: Fix support for rootfstype= when root= is given
|
|
Commit Message
Stefan Berger
Nov. 20, 2023, 1:12 a.m. UTC
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. This currently does not work when root= is provided since then saved_root_name contains a string and rootfstype= is ignored. Therefore, ramfs is currently always chosen when root= is provided. The current behavior for rootfs's filesystem is: root= | rootfstype= | chosen rootfs filesystem ------------+-------------+-------------------------- unspecified | unspecified | tmpfs unspecified | tmpfs | tmpfs unspecified | ramfs | ramfs provided | ignored | ramfs rootfstype= should be respected regardless whether root= is given, as shown below: root= | rootfstype= | chosen rootfs filesystem ------------+-------------+-------------------------- unspecified | unspecified | tmpfs (as before) unspecified | tmpfs | tmpfs (as before) unspecified | ramfs | ramfs (as before) provided | unspecified | ramfs (compatibility with before) provided | tmpfs | tmpfs (new) provided | ramfs | ramfs (new) This table represents the new behavior. Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= specified") Cc: <stable@vger.kernel.org> Signed-off-by: Rob Landley <rob@landley.net> Link: https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/ Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> --- v3: - Changed initfstype= to rootfstype= - Remove my R-b v2: - Cc'ing stable mailing list now --- init/do_mounts.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
Comments
On Sun, Nov 19, 2023 at 08:12:48PM -0500, Stefan Berger wrote: > 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. > > This currently does not work when root= is provided since then > saved_root_name contains a string and rootfstype= is ignored. Therefore, > ramfs is currently always chosen when root= is provided. > > The current behavior for rootfs's filesystem is: > > root= | rootfstype= | chosen rootfs filesystem > ------------+-------------+-------------------------- > unspecified | unspecified | tmpfs > unspecified | tmpfs | tmpfs > unspecified | ramfs | ramfs > provided | ignored | ramfs > > rootfstype= should be respected regardless whether root= is given, > as shown below: > > root= | rootfstype= | chosen rootfs filesystem > ------------+-------------+-------------------------- > unspecified | unspecified | tmpfs (as before) > unspecified | tmpfs | tmpfs (as before) > unspecified | ramfs | ramfs (as before) > provided | unspecified | ramfs (compatibility with before) > provided | tmpfs | tmpfs (new) > provided | ramfs | ramfs (new) > > This table represents the new behavior. > > Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= specified") > Cc: <stable@vger.kernel.org> > Signed-off-by: Rob Landley <rob@landley.net> > Link: https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/ > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Who should take this patch? Me? Or someone else? thanks, greg k-h
On Tue, 2023-11-28 at 09:54 +0000, Greg KH wrote: > On Sun, Nov 19, 2023 at 08:12:48PM -0500, Stefan Berger wrote: > > 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. > > > > This currently does not work when root= is provided since then > > saved_root_name contains a string and rootfstype= is ignored. Therefore, > > ramfs is currently always chosen when root= is provided. > > > > The current behavior for rootfs's filesystem is: > > > > root= | rootfstype= | chosen rootfs filesystem > > ------------+-------------+-------------------------- > > unspecified | unspecified | tmpfs > > unspecified | tmpfs | tmpfs > > unspecified | ramfs | ramfs > > provided | ignored | ramfs > > > > rootfstype= should be respected regardless whether root= is given, > > as shown below: > > > > root= | rootfstype= | chosen rootfs filesystem > > ------------+-------------+-------------------------- > > unspecified | unspecified | tmpfs (as before) > > unspecified | tmpfs | tmpfs (as before) > > unspecified | ramfs | ramfs (as before) > > provided | unspecified | ramfs (compatibility with before) > > provided | tmpfs | tmpfs (new) > > provided | ramfs | ramfs (new) > > > > This table represents the new behavior. > > > > Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= specified") > > Cc: <stable@vger.kernel.org> > > Signed-off-by: Rob Landley <rob@landley.net> > > Link: https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/ > > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Who should take this patch? Me? Or someone else? Reviewed-and-Tested-by: Mimi Zohar <zohar@linux.ibm.com> Thanks, Greg. As there is no initramfs maintainer, I'd appreciate your picking it up.
diff --git a/init/do_mounts.c b/init/do_mounts.c index 5fdef94f0864..279ad28bf4fb 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -510,7 +510,10 @@ 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"))) - is_tmpfs = true; + if (IS_ENABLED(CONFIG_TMPFS)) { + if (!saved_root_name[0] && !root_fs_names) + is_tmpfs = true; + else if (root_fs_names && !!strstr(root_fs_names, "tmpfs")) + is_tmpfs = true; + } }