[PATCH v3 0/3] 9p: add support for root file systems

[PATCH v3 0/3] 9p: add support for root file systems

[Changbin Du]

Just like cifs and nfs, this short series enables rootfs support for 9p.
Bellow is an example which mounts v9fs with tag 'r' as rootfs in qemu
guest via virtio transport.

  $ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \
        -virtfs local,path=$rootfs_dir,mount_tag=r,security_model=passthrough,id=r \
        -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \
        -append "root=/dev/v9fs v9fsroot=r,trans=virtio rw console=ttyS0 3"

v3:
 o rebase.

v2:
  o use pr_err instead of printk.
  o ROOT_DEV is only set after checking.
  o cleanup DEFAULT_MNT_OPTS.
  o do not retry mount for fd and virtio transport.

Changbin Du (3):
  9p: add support for root file systems
  9p: doc: move to a new dedicated folder
  9p: doc: add v9fsroot description

Changbin Du (3):
  9p: add support for root file systems
  9p: doc: move to a new dedicated folder
  9p: doc: add v9fsroot description

 Documentation/filesystems/index.rst         |  2 +-
 Documentation/filesystems/{ => v9fs}/9p.rst |  0
 Documentation/filesystems/v9fs/index.rst    | 12 ++++
 Documentation/filesystems/v9fs/v9fsroot.rst | 52 +++++++++++++++++
 MAINTAINERS                                 |  8 ++-
 fs/9p/Kconfig                               |  6 ++
 fs/9p/Makefile                              |  1 +
 fs/9p/v9fsroot.c                            | 64 +++++++++++++++++++++
 include/linux/root_dev.h                    |  1 +
 init/do_mounts.c                            | 55 ++++++++++++++++++
 10 files changed, 199 insertions(+), 2 deletions(-)
 rename Documentation/filesystems/{ => v9fs}/9p.rst (100%)
 create mode 100644 Documentation/filesystems/v9fs/index.rst
 create mode 100644 Documentation/filesystems/v9fs/v9fsroot.rst
 create mode 100644 fs/9p/v9fsroot.c

-- 
2.30.2

[PATCH v3 1/3] 9p: add support for root file systems

[Changbin Du]

This introduces a new kernel command-line option called 'v9fsroot='
which will tell the kernel to mount the root file system by
utilizing the 9p protocol.

This allows us to mount host folder as rootfs for guest linux in qemu.
Bellow is an example which mounts v9fs with tag 'r' as rootfs in qemu
guest via virtio transport.

  $ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \
      -virtfs local,path=$rootfs_dir,mount_tag=r,security_model=passthrough,id=r \
      -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \
      -append "root=/dev/v9fs v9fsroot=r,trans=virtio rw console=ttyS0 3"

Signed-off-by: Changbin Du <changbin.du@gmail.com>

---
v2:
  o use pr_err instead of printk.
  o ROOT_DEV is only set after checking.
  o cleanup DEFAULT_MNT_OPTS.
  o do not retry mount for fd and virtio transport.
---
 MAINTAINERS              |  5 ++++
 fs/9p/Kconfig            |  6 ++++
 fs/9p/Makefile           |  1 +
 fs/9p/v9fsroot.c         | 64 ++++++++++++++++++++++++++++++++++++++++
 include/linux/root_dev.h |  1 +
 init/do_mounts.c         | 55 ++++++++++++++++++++++++++++++++++
 6 files changed, 132 insertions(+)
 create mode 100644 fs/9p/v9fsroot.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b706dd20ff2b..35b2c8f614d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -239,6 +239,11 @@ F:	include/trace/events/9p.h
 F:	include/uapi/linux/virtio_9p.h
 F:	net/9p/
 
+9P FILE SYSTEM ROOTFS SUPPORT
+R:	Changbin Du <changbin.du@gmail.com>
+S:	Supported
+F:	fs/9p/v9fsroot.c
+
 A8293 MEDIA DRIVER
 M:	Antti Palosaari <crope@iki.fi>
 L:	linux-media@vger.kernel.org
diff --git a/fs/9p/Kconfig b/fs/9p/Kconfig
index 09fd4a185fd2..71c5a49f9a27 100644
--- a/fs/9p/Kconfig
+++ b/fs/9p/Kconfig
@@ -42,3 +42,9 @@ config 9P_FS_SECURITY
 
 	  If you are not using a security module that requires using
 	  extended attributes for file security labels, say N.
+
+config 9P_FS_ROOT
+	bool "9p root file system"
+	depends on 9P_FS=y
+	help
+	  Enables root file system support over 9p protocol.
diff --git a/fs/9p/Makefile b/fs/9p/Makefile
index e7800a5c7395..bc2a4ef10049 100644
--- a/fs/9p/Makefile
+++ b/fs/9p/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_9P_FS) := 9p.o
 
 9p-$(CONFIG_9P_FSCACHE) += cache.o
 9p-$(CONFIG_9P_FS_POSIX_ACL) += acl.o
+9p-$(CONFIG_9P_FS_ROOT) += v9fsroot.o
diff --git a/fs/9p/v9fsroot.c b/fs/9p/v9fsroot.c
new file mode 100644
index 000000000000..6c9f7e335c1a
--- /dev/null
+++ b/fs/9p/v9fsroot.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * 9p root file system support
+ *
+ * Copyright (c) 2021 Changbin Du <changbin.du@gmail.com>
+ */
+#include <linux/init.h>
+#include <linux/fs.h>
+#include <linux/types.h>
+#include <linux/ctype.h>
+#include <linux/string.h>
+#include <linux/root_dev.h>
+#include <linux/kernel.h>
+
+static char root_dev[2048] __initdata = "";
+static char root_opts[1024] __initdata = "";
+
+/* v9fsroot=<path>[,options] */
+static int __init v9fs_root_setup(char *line)
+{
+	char *s;
+	int len;
+
+	if (strlen(line) >= 1) {
+		/* make s point to ',' or '\0' at end of line */
+		s = strchrnul(line, ',');
+		/* len is strlen(unc) + '\0' */
+		len = s - line + 1;
+		if (len > sizeof(root_dev)) {
+			pr_err("Root-V9FS: path too long\n");
+			return 1;
+		}
+		strscpy(root_dev, line, len);
+
+		if (*s) {
+			int n = snprintf(root_opts,
+					 sizeof(root_opts), "%s",
+					 s + 1);
+			if (n >= sizeof(root_opts)) {
+				pr_err("Root-V9FS: mount options string too long\n");
+				root_opts[sizeof(root_opts)-1] = '\0';
+				return 1;
+			}
+		}
+	}
+
+	ROOT_DEV = Root_V9FS;
+	return 1;
+}
+
+__setup("v9fsroot=", v9fs_root_setup);
+
+int __init v9fs_root_data(char **dev, char **opts)
+{
+	if (!root_dev[0]) {
+		pr_err("Root-V9FS: no rootdev specified\n");
+		return -1;
+	}
+
+	*dev = root_dev;
+	*opts = root_opts;
+
+	return 0;
+}
diff --git a/include/linux/root_dev.h b/include/linux/root_dev.h
index 4e78651371ba..becd0ee2ff87 100644
--- a/include/linux/root_dev.h
+++ b/include/linux/root_dev.h
@@ -9,6 +9,7 @@
 enum {
 	Root_NFS = MKDEV(UNNAMED_MAJOR, 255),
 	Root_CIFS = MKDEV(UNNAMED_MAJOR, 254),
+	Root_V9FS = MKDEV(UNNAMED_MAJOR, 253),
 	Root_RAM0 = MKDEV(RAMDISK_MAJOR, 0),
 	Root_RAM1 = MKDEV(RAMDISK_MAJOR, 1),
 	Root_FD0 = MKDEV(FLOPPY_MAJOR, 0),
diff --git a/init/do_mounts.c b/init/do_mounts.c
index a78e44ee6adb..952e91f6efcb 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -287,6 +287,8 @@ dev_t name_to_dev_t(const char *name)
 		return Root_NFS;
 	if (strcmp(name, "/dev/cifs") == 0)
 		return Root_CIFS;
+	if (strcmp(name, "/dev/v9fs") == 0)
+		return Root_V9FS;
 	if (strcmp(name, "/dev/ram") == 0)
 		return Root_RAM0;
 #ifdef CONFIG_BLOCK
@@ -536,6 +538,52 @@ static int __init mount_cifs_root(void)
 }
 #endif
 
+#ifdef CONFIG_9P_FS_ROOT
+
+extern int v9fs_root_data(char **dev, char **opts);
+
+#define V9FSROOT_TIMEOUT_MIN	5
+#define V9FSROOT_TIMEOUT_MAX	30
+#define V9FSROOT_RETRY_MAX	5
+
+static bool v9fs_should_retry(char *mount_opts)
+{
+	if (strstr(mount_opts, "trans=virtio") || strstr(mount_opts, "trans=fd"))
+		return false;
+	return true;
+}
+
+static int __init mount_v9fs_root(void)
+{
+	char *root_dev, *root_data;
+	unsigned int timeout = V9FSROOT_TIMEOUT_MIN;
+	bool should_retry;
+	int try, err;
+
+	err = v9fs_root_data(&root_dev, &root_data);
+	if (err != 0)
+		return 0;
+
+	should_retry = v9fs_should_retry(root_data);
+	for (try = 1; ; try++) {
+		err = do_mount_root(root_dev, "9p",
+				    root_mountflags, root_data);
+		if (err == 0)
+			return 1;
+
+		if (!should_retry || try > V9FSROOT_RETRY_MAX)
+			break;
+
+		/* Wait, in case the server refused us immediately */
+		ssleep(timeout);
+		timeout <<= 1;
+		if (timeout > V9FSROOT_TIMEOUT_MAX)
+			timeout = V9FSROOT_TIMEOUT_MAX;
+	}
+	return 0;
+}
+#endif
+
 void __init mount_root(void)
 {
 #ifdef CONFIG_ROOT_NFS
@@ -552,6 +600,13 @@ void __init mount_root(void)
 		return;
 	}
 #endif
+#ifdef CONFIG_9P_FS_ROOT
+	if (ROOT_DEV == Root_V9FS) {
+		if (!mount_v9fs_root())
+			pr_err("VFS: Unable to mount root fs via 9p.\n");
+		return;
+	}
+#endif
 #ifdef CONFIG_BLOCK
 	{
 		int err = create_dev("/dev/root", ROOT_DEV);
-- 
2.30.2

[PATCH v3 2/3] 9p: doc: move to a new dedicated folder

[Changbin Du]

Later we will add another documentation for v9fs.

Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 Documentation/filesystems/index.rst         |  2 +-
 Documentation/filesystems/{ => v9fs}/9p.rst |  0
 Documentation/filesystems/v9fs/index.rst    | 11 +++++++++++
 MAINTAINERS                                 |  2 +-
 4 files changed, 13 insertions(+), 2 deletions(-)
 rename Documentation/filesystems/{ => v9fs}/9p.rst (100%)
 create mode 100644 Documentation/filesystems/v9fs/index.rst

diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst
index d4853cb919d2..e53992636a49 100644
--- a/Documentation/filesystems/index.rst
+++ b/Documentation/filesystems/index.rst
@@ -63,7 +63,7 @@ Documentation for filesystem implementations.
 .. toctree::
    :maxdepth: 2
 
-   9p
+   v9fs/index
    adfs
    affs
    afs
diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/v9fs/9p.rst
similarity index 100%
rename from Documentation/filesystems/9p.rst
rename to Documentation/filesystems/v9fs/9p.rst
diff --git a/Documentation/filesystems/v9fs/index.rst b/Documentation/filesystems/v9fs/index.rst
new file mode 100644
index 000000000000..a1e45b89e2a2
--- /dev/null
+++ b/Documentation/filesystems/v9fs/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====
+v9fs
+====
+
+.. toctree::
+   :maxdepth: 6
+   :numbered:
+
+   9p
diff --git a/MAINTAINERS b/MAINTAINERS
index 35b2c8f614d0..3da44eef1471 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -232,7 +232,7 @@ W:	http://swik.net/v9fs
 Q:	http://patchwork.kernel.org/project/v9fs-devel/list/
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git
 T:	git git://github.com/martinetd/linux.git
-F:	Documentation/filesystems/9p.rst
+F:	Documentation/filesystems/v9fs/
 F:	fs/9p/
 F:	include/net/9p/
 F:	include/trace/events/9p.h
-- 
2.30.2

[PATCH v3 3/3] 9p: doc: add v9fsroot description

[Changbin Du]

This documentation is modified from cifs/cifsroot.rst.

Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
 Documentation/filesystems/v9fs/index.rst    |  1 +
 Documentation/filesystems/v9fs/v9fsroot.rst | 52 +++++++++++++++++++++
 MAINTAINERS                                 |  1 +
 3 files changed, 54 insertions(+)
 create mode 100644 Documentation/filesystems/v9fs/v9fsroot.rst

diff --git a/Documentation/filesystems/v9fs/index.rst b/Documentation/filesystems/v9fs/index.rst
index a1e45b89e2a2..65e1ceb04c9c 100644
--- a/Documentation/filesystems/v9fs/index.rst
+++ b/Documentation/filesystems/v9fs/index.rst
@@ -9,3 +9,4 @@ v9fs
    :numbered:
 
    9p
+   v9fsroot
diff --git a/Documentation/filesystems/v9fs/v9fsroot.rst b/Documentation/filesystems/v9fs/v9fsroot.rst
new file mode 100644
index 000000000000..ce6b3c85e301
--- /dev/null
+++ b/Documentation/filesystems/v9fs/v9fsroot.rst
@@ -0,0 +1,52 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================================
+Mounting root file system via v9fs (9p.ko)
+==========================================
+
+:Author: Changbin Du <changbin.du@gmail.com>
+
+The CONFIG_9P_FS_ROOT option enables experimental root file system
+support for v9fs.
+
+It introduces a new kernel command-line option called 'v9fsroot='
+which will tell the kernel to mount the root file system by
+utilizing the 9p protocol.
+
+
+Kernel command line
+===================
+
+::
+
+    root=/dev/v9fs
+
+This is just a virtual device that basically tells the kernel to mount
+the root file system via 9p protocol.
+
+::
+
+    v9fsroot=<path>[,options]
+
+Enables the kernel to mount the root file system via 9p specified in this
+option.
+
+path
+	Could be a remote file server, Plan 9 From User Space applications
+	or mount tag of virtio transport.
+
+options
+	Optional mount options.
+
+Examples
+========
+Test it under QEMU on a kernel built with CONFIG_9P_FS_ROOT and
+CONFIG_IP_PNP options enabled::
+
+    # qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \
+    -virtfs local,path=$rootfs_dir,mount_tag=r,security_model=passthrough,id=r \
+    -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \
+    -append "root=/dev/v9fs v9fsroot=r,trans=virtio rw console=ttyS0 3"
+
+The above example mounts v9fs with tag 'r' as rootfs in qemu guest via
+virtio transport.
diff --git a/MAINTAINERS b/MAINTAINERS
index 3da44eef1471..dfcee6dfe182 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -243,6 +243,7 @@ F:	net/9p/
 R:	Changbin Du <changbin.du@gmail.com>
 S:	Supported
 F:	fs/9p/v9fsroot.c
+F:	Documentation/filesystems/v9fs/v9fsroot.rst
 
 A8293 MEDIA DRIVER
 M:	Antti Palosaari <crope@iki.fi>
-- 
2.30.2

Re: [PATCH v3 0/3] 9p: add support for root file systems

[Dominique Martinet]

Changbin Du wrote on Mon, Jun 07, 2021 at 07:09:19AM +0800:
> Just like cifs and nfs, this short series enables rootfs support for 9p.
> Bellow is an example which mounts v9fs with tag 'r' as rootfs in qemu
> guest via virtio transport.
> 
>   $ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \
>         -virtfs local,path=$rootfs_dir,mount_tag=r,security_model=passthrough,id=r \
>         -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \
>         -append "root=/dev/v9fs v9fsroot=r,trans=virtio rw console=ttyS0 3"

Thanks for rebasing -- I haven't forgotten, just been otherwise busy.

Will make time for this and the netfs rework over the next couple of
weeks.


Just a couple of notes:

linux-fsdevel@vger is still not in Cc of the patches, and they weren't
for any other version except for one of my replies, so it might be worth
resending just for them as it touches do_mounts.c / root_dev.h


>  MAINTAINERS                                 |  8 ++-

I don't think it's worth adding yourself as MAINTAINERS for this, will
likely strip it out (I know I'm the one who asked for your help if
people have problems with this, but we should keep contacts simple)
I'll forward you requests when they come if it's not trivial and you're
not subscribed to the v9fs-developer@sf list

-- 
Dominique

Re: [PATCH v3 1/3] 9p: add support for root file systems

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]

Hi Changbin,

I love your patch! Perhaps something to improve:

[auto build test WARNING on lwn/docs-next]
[also build test WARNING on linus/master v5.13-rc5 next-20210604]
[cannot apply to v9fs/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Changbin-Du/9p-add-support-for-root-file-systems/20210607-071229
base:   git://git.lwn.net/linux-2.6 docs-next
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/96098f751038703cc0fda4f018236d240a86930d
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Changbin-Du/9p-add-support-for-root-file-systems/20210607-071229
        git checkout 96098f751038703cc0fda4f018236d240a86930d
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> fs/9p/v9fsroot.c:53:12: warning: no previous prototype for 'v9fs_root_data' [-Wmissing-prototypes]
      53 | int __init v9fs_root_data(char **dev, char **opts)
         |            ^~~~~~~~~~~~~~


vim +/v9fs_root_data +53 fs/9p/v9fsroot.c

    52	
  > 53	int __init v9fs_root_data(char **dev, char **opts)

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 78542 bytes --]

Re: [PATCH v3 1/3] 9p: add support for root file systems

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

Hi Changbin,

I love your patch! Perhaps something to improve:

[auto build test WARNING on lwn/docs-next]
[also build test WARNING on linus/master v5.13-rc5 next-20210604]
[cannot apply to v9fs/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Changbin-Du/9p-add-support-for-root-file-systems/20210607-071229
base:   git://git.lwn.net/linux-2.6 docs-next
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/96098f751038703cc0fda4f018236d240a86930d
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Changbin-Du/9p-add-support-for-root-file-systems/20210607-071229
        git checkout 96098f751038703cc0fda4f018236d240a86930d
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> fs/9p/v9fsroot.c:53:12: warning: no previous prototype for 'v9fs_root_data' [-Wmissing-prototypes]
      53 | int __init v9fs_root_data(char **dev, char **opts)
         |            ^~~~~~~~~~~~~~


vim +/v9fs_root_data +53 fs/9p/v9fsroot.c

    52	
  > 53	int __init v9fs_root_data(char **dev, char **opts)

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 78542 bytes --]

Re: [PATCH v3 1/3] 9p: add support for root file systems

[Changbin Du]

On Mon, Jun 07, 2021 at 09:06:54AM +0800, kernel test robot wrote:
> Hi Changbin,
> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on lwn/docs-next]
> [also build test WARNING on linus/master v5.13-rc5 next-20210604]
> [cannot apply to v9fs/for-next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:    https://github.com/0day-ci/linux/commits/Changbin-Du/9p-add-support-for-root-file-systems/20210607-071229
> base:   git://git.lwn.net/linux-2.6 docs-next
> config: arm-allyesconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # https://github.com/0day-ci/linux/commit/96098f751038703cc0fda4f018236d240a86930d
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review Changbin-Du/9p-add-support-for-root-file-systems/20210607-071229
>         git checkout 96098f751038703cc0fda4f018236d240a86930d
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> 
> All warnings (new ones prefixed by >>):
> 
> >> fs/9p/v9fsroot.c:53:12: warning: no previous prototype for 'v9fs_root_data' [-Wmissing-prototypes]
>       53 | int __init v9fs_root_data(char **dev, char **opts)
>          |            ^~~~~~~~~~~~~~
>
This just follows the existing rootfs support manner. This function doesn't have
a dedicated header file to place. So I think we can ignore this warning.

> 
> vim +/v9fs_root_data +53 fs/9p/v9fsroot.c
> 
>     52	
>   > 53	int __init v9fs_root_data(char **dev, char **opts)
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org



-- 
Cheers,
Changbin Du

Re: [PATCH v3 1/3] 9p: add support for root file systems

[Changbin Du]

[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]

On Mon, Jun 07, 2021 at 09:06:54AM +0800, kernel test robot wrote:
> Hi Changbin,
> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on lwn/docs-next]
> [also build test WARNING on linus/master v5.13-rc5 next-20210604]
> [cannot apply to v9fs/for-next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:    https://github.com/0day-ci/linux/commits/Changbin-Du/9p-add-support-for-root-file-systems/20210607-071229
> base:   git://git.lwn.net/linux-2.6 docs-next
> config: arm-allyesconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # https://github.com/0day-ci/linux/commit/96098f751038703cc0fda4f018236d240a86930d
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review Changbin-Du/9p-add-support-for-root-file-systems/20210607-071229
>         git checkout 96098f751038703cc0fda4f018236d240a86930d
>         # save the attached .config to linux build tree
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> 
> All warnings (new ones prefixed by >>):
> 
> >> fs/9p/v9fsroot.c:53:12: warning: no previous prototype for 'v9fs_root_data' [-Wmissing-prototypes]
>       53 | int __init v9fs_root_data(char **dev, char **opts)
>          |            ^~~~~~~~~~~~~~
>
This just follows the existing rootfs support manner. This function doesn't have
a dedicated header file to place. So I think we can ignore this warning.

> 
> vim +/v9fs_root_data +53 fs/9p/v9fsroot.c
> 
>     52	
>   > 53	int __init v9fs_root_data(char **dev, char **opts)
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org



-- 
Cheers,
Changbin Du

Re: [PATCH v3 0/3] 9p: add support for root file systems

[Josh Triplett]

On Mon, Jun 07, 2021 at 07:09:19AM +0800, Changbin Du wrote:
> Just like cifs and nfs, this short series enables rootfs support for 9p.
> Bellow is an example which mounts v9fs with tag 'r' as rootfs in qemu
> guest via virtio transport.
> 
>   $ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \
>         -virtfs local,path=$rootfs_dir,mount_tag=r,security_model=passthrough,id=r \
>         -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \
>         -append "root=/dev/v9fs v9fsroot=r,trans=virtio rw console=ttyS0 3"

Rather than inventing a pseudo-device /dev/v9fs for this, would it
potentially work to use the existing rootfstype and rootflags options
for this? rootfstype already determines what filesystem should be used
to mount the root, and rootflags already provides options for that
filesystem.

For instance, for the above example:
rootfstype=9p root=r rootflags=trans=virtio

That would require a bit of fiddling to make rootfstype=9p allow a root
that's just the mount_tag. If that isn't an option, then even with
root=/dev/v9fs I think it still makes sense to use the existing
rootflags for "trans=virtio" rather than creating a new "v9fsroot"
option for that.

- Josh Triplett

Re: [PATCH v3 0/3] 9p: add support for root file systems

[Dominique Martinet]

Josh Triplett wrote on Mon, Jun 14, 2021 at 01:57:54AM -0700:
> On Mon, Jun 07, 2021 at 07:09:19AM +0800, Changbin Du wrote:
> > Just like cifs and nfs, this short series enables rootfs support for 9p.
> > Bellow is an example which mounts v9fs with tag 'r' as rootfs in qemu
> > guest via virtio transport.
> > 
> >   $ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \
> >         -virtfs local,path=$rootfs_dir,mount_tag=r,security_model=passthrough,id=r \
> >         -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \
> >         -append "root=/dev/v9fs v9fsroot=r,trans=virtio rw console=ttyS0 3"
> 
> Rather than inventing a pseudo-device /dev/v9fs for this, would it
> potentially work to use the existing rootfstype and rootflags options
> for this? rootfstype already determines what filesystem should be used
> to mount the root, and rootflags already provides options for that
> filesystem.
> 
> For instance, for the above example:
> rootfstype=9p root=r rootflags=trans=virtio
> 
> That would require a bit of fiddling to make rootfstype=9p allow a root
> that's just the mount_tag. If that isn't an option, then even with
> root=/dev/v9fs I think it still makes sense to use the existing
> rootflags for "trans=virtio" rather than creating a new "v9fsroot"
> option for that.

This doesn't work as is because of the way the code is written, if
there's no block device associated with a root=x option right now it
will lead to kernel panic.

I replied with folks in Cc but there's another thread on linux-fsdevel@
with a more generic approach that will build a list of filesystems which
don't require such a block device (either hardcoded with virtiofs and 9p
or based on FS_REQUIRES_DEV), thread started there but there's a second
patch hidden an more discussion below:
https://lore.kernel.org/linux-fsdevel/20210608153524.GB504497@redhat.com/


My preferred approach right now would be to go with their approach, and
adjust the documentation Changbin Du wrote here, to have the best of
both worlds.

-- 
Dominique

Re: [PATCH v3 0/3] 9p: add support for root file systems

[Josh Triplett]

On Mon, Jun 14, 2021 at 06:01:44PM +0900, Dominique Martinet wrote:
> Josh Triplett wrote on Mon, Jun 14, 2021 at 01:57:54AM -0700:
> > On Mon, Jun 07, 2021 at 07:09:19AM +0800, Changbin Du wrote:
> > > Just like cifs and nfs, this short series enables rootfs support for 9p.
> > > Bellow is an example which mounts v9fs with tag 'r' as rootfs in qemu
> > > guest via virtio transport.
> > > 
> > >   $ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \
> > >         -virtfs local,path=$rootfs_dir,mount_tag=r,security_model=passthrough,id=r \
> > >         -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \
> > >         -append "root=/dev/v9fs v9fsroot=r,trans=virtio rw console=ttyS0 3"
> > 
> > Rather than inventing a pseudo-device /dev/v9fs for this, would it
> > potentially work to use the existing rootfstype and rootflags options
> > for this? rootfstype already determines what filesystem should be used
> > to mount the root, and rootflags already provides options for that
> > filesystem.
> > 
> > For instance, for the above example:
> > rootfstype=9p root=r rootflags=trans=virtio
> > 
> > That would require a bit of fiddling to make rootfstype=9p allow a root
> > that's just the mount_tag. If that isn't an option, then even with
> > root=/dev/v9fs I think it still makes sense to use the existing
> > rootflags for "trans=virtio" rather than creating a new "v9fsroot"
> > option for that.
> 
> This doesn't work as is because of the way the code is written, if
> there's no block device associated with a root=x option right now it
> will lead to kernel panic.
> 
> I replied with folks in Cc but there's another thread on linux-fsdevel@
> with a more generic approach that will build a list of filesystems which
> don't require such a block device (either hardcoded with virtiofs and 9p
> or based on FS_REQUIRES_DEV), thread started there but there's a second
> patch hidden an more discussion below:
> https://lore.kernel.org/linux-fsdevel/20210608153524.GB504497@redhat.com/

The patch later on in that thread (either using a list of
non-block-device filesystems or the version referenced elsewhere that
uses a flag in the filesystem definition) looks really appealing! That's
exactly what I was hoping for. That gets us closer to directly
translating `mount -t type -o options rootdesc` into `rootfstype=type
rootflags=options root=rootdesc` in the general case, rather than having
special cases for different filesystems.

Re: [PATCH v3 0/3] 9p: add support for root file systems

[Changbin Du]

On Mon, Jun 14, 2021 at 02:19:38AM -0700, Josh Triplett wrote:
> On Mon, Jun 14, 2021 at 06:01:44PM +0900, Dominique Martinet wrote:
> > Josh Triplett wrote on Mon, Jun 14, 2021 at 01:57:54AM -0700:
> > > On Mon, Jun 07, 2021 at 07:09:19AM +0800, Changbin Du wrote:
> > > > Just like cifs and nfs, this short series enables rootfs support for 9p.
> > > > Bellow is an example which mounts v9fs with tag 'r' as rootfs in qemu
> > > > guest via virtio transport.
> > > > 
> > > >   $ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \
> > > >         -virtfs local,path=$rootfs_dir,mount_tag=r,security_model=passthrough,id=r \
> > > >         -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \
> > > >         -append "root=/dev/v9fs v9fsroot=r,trans=virtio rw console=ttyS0 3"
> > > 
> > > Rather than inventing a pseudo-device /dev/v9fs for this, would it
> > > potentially work to use the existing rootfstype and rootflags options
> > > for this? rootfstype already determines what filesystem should be used
> > > to mount the root, and rootflags already provides options for that
> > > filesystem.
> > > 
> > > For instance, for the above example:
> > > rootfstype=9p root=r rootflags=trans=virtio
> > > 
> > > That would require a bit of fiddling to make rootfstype=9p allow a root
> > > that's just the mount_tag. If that isn't an option, then even with
> > > root=/dev/v9fs I think it still makes sense to use the existing
> > > rootflags for "trans=virtio" rather than creating a new "v9fsroot"
> > > option for that.
> > 
> > This doesn't work as is because of the way the code is written, if
> > there's no block device associated with a root=x option right now it
> > will lead to kernel panic.
> > 
> > I replied with folks in Cc but there's another thread on linux-fsdevel@
> > with a more generic approach that will build a list of filesystems which
> > don't require such a block device (either hardcoded with virtiofs and 9p
> > or based on FS_REQUIRES_DEV), thread started there but there's a second
> > patch hidden an more discussion below:
> > https://lore.kernel.org/linux-fsdevel/20210608153524.GB504497@redhat.com/
> 
> The patch later on in that thread (either using a list of
> non-block-device filesystems or the version referenced elsewhere that
> uses a flag in the filesystem definition) looks really appealing! That's
> exactly what I was hoping for. That gets us closer to directly
> translating `mount -t type -o options rootdesc` into `rootfstype=type
> rootflags=options root=rootdesc` in the general case, rather than having
> special cases for different filesystems.
Bellow is all the parameters of non-block rootfs support.
 nfs:    nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
 cifs:   cifsroot=//<server-ip>/<share>[,options]
 v9fs:   v9fsroot=<tag/ip>[,options]
 mtd:    root=mtd:<identifier> or root=ubi:<identifier>
 virtiofs: root=fstag:<tag>

The main problem is we lack a generic handing for non-block rootdev. I think
maybe we can unify all of above.
 non-block:  root=<type>:<identifier>
 blockdev:   root=<bock-dev-path> or root=<blockdev major/minor>

Then:
 nfs:    root=nfs:[<server-ip>:]<root-dir>  rootflags=[nfs-options]
 cifs:   root=cifs://<server-ip>/<share>    rootflags=[options]
 v9fs:   root=9p:<tag/ip>                   rootflags=[options]
 mtd:    root=mtd:<identifier>              rootflags=[options]
 ubi:    root=ubi:<identifier>              rootflags=[options]
 virtiofs: root=virtiofs:<tag>              rootflags=[options]

And maybe we can also remove all the special fs code out of init/do_mounts.c.

-- 
Cheers,
Changbin Du

Re: [PATCH v3 0/3] 9p: add support for root file systems

[Dominique Martinet]

Changbin Du wrote on Sun, Jun 20, 2021 at 11:36:59AM +0800:
> The main problem is we lack a generic handing for non-block rootdev. I think
> maybe we can unify all of above.

We're already going in that direction, please have a look at the threads
on fsdevel:
(new patch by Christoph)
https://lore.kernel.org/linux-fsdevel/20210617153649.1886693-1-hch@lst.de/

(older threads I linked earlier)
https://lore.kernel.org/linux-fsdevel/20210608153524.GB504497@redhat.com/


I think it's getting there, Christoph should send a v2 addressing Vivek
remarks that will likely get picked up.
-- 
Dominique