linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hanna Czenczek <hreitz@redhat.com>
To: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-doc@vger.kernel.org, virtualization@lists.linux.dev
Cc: "Hanna Czenczek" <hreitz@redhat.com>,
	"Miklos Szeredi" <mszeredi@redhat.com>,
	"German Maglione" <gmaglione@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Vivek Goyal" <vgoyal@redhat.com>
Subject: [PATCH 1/2] virtio-fs: Add 'file' mount option
Date: Tue,  9 Jul 2024 13:19:17 +0200	[thread overview]
Message-ID: <20240709111918.31233-2-hreitz@redhat.com> (raw)
In-Reply-To: <20240709111918.31233-1-hreitz@redhat.com>

This new option allows mounting filesystems whose root node is a regular
file instead of a directory.

FUSE itself has the more generic 'rootmode' option, which theoretically
allows mounting filesystems with an even greater variety of root node
modes.  There are two reasons why we do not let virtio-fs provide that
same option:

First, with FUSE, this option is supposed to be set automatically by
e.g. the fusermount helper program to match the root node's mode, no
user involvement necessary.  It is easy for fusermount to stat() the
mount point (whose mode must match the filesystem's root node mode) and
fill the 'rootmode' option appropriately.  In the case of virtio-fs,
however, mounting is often done manually by the user, there is no helper
program; and I as a user find the simple '-o file' preferable over the
more cryptic '-o rootmode=0100000'.

Second, inode modes other than S_IFDIR and S_IFREG have limited use with
virtio-fs anyway:
- Device files are host-specific, so passing them via virtio-fs from
  host to guest (or between different guests) seems rarely useful,
- FIFOs and Unix domain sockets currently do not allow communication
  between guest and host (or between different guests), which is really
  the only reason why they would be used as virtio-fs filesystem root
  nodes,
- and symlinks in general do not make much sense as filesystem root
  nodes.

The more generic 'rootmode' option is therefore not very useful for
virtio-fs, while being harder to use.

Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
---
 fs/fuse/virtio_fs.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index 1a52a51b6b07..ba1a6ac31000 100644
--- a/fs/fuse/virtio_fs.c
+++ b/fs/fuse/virtio_fs.c
@@ -107,11 +107,13 @@ static const struct constant_table dax_param_enums[] = {
 enum {
 	OPT_DAX,
 	OPT_DAX_ENUM,
+	OPT_FILE,
 };
 
 static const struct fs_parameter_spec virtio_fs_parameters[] = {
 	fsparam_flag("dax", OPT_DAX),
 	fsparam_enum("dax", OPT_DAX_ENUM, dax_param_enums),
+	fsparam_flag("file", OPT_FILE),
 	{}
 };
 
@@ -133,6 +135,10 @@ static int virtio_fs_parse_param(struct fs_context *fsc,
 	case OPT_DAX_ENUM:
 		ctx->dax_mode = result.uint_32;
 		break;
+	case OPT_FILE:
+		ctx->rootmode = S_IFREG;
+		ctx->rootmode_present = true;
+		break;
 	default:
 		return -EINVAL;
 	}
@@ -1401,7 +1407,8 @@ static const struct fuse_iqueue_ops virtio_fs_fiq_ops = {
 
 static inline void virtio_fs_ctx_set_defaults(struct fuse_fs_context *ctx)
 {
-	ctx->rootmode = S_IFDIR;
+	if (!ctx->rootmode_present)
+		ctx->rootmode = S_IFDIR;
 	ctx->default_permissions = 1;
 	ctx->allow_other = 1;
 	ctx->max_read = UINT_MAX;
-- 
2.45.1


  reply	other threads:[~2024-07-09 11:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-09 11:19 [PATCH 0/2] virtio-fs: Add 'file' mount option Hanna Czenczek
2024-07-09 11:19 ` Hanna Czenczek [this message]
2024-07-09 11:19 ` [PATCH 2/2] virtio-fs: Document " Hanna Czenczek
2024-07-09 17:56 ` [PATCH 0/2] virtio-fs: Add " Josef Bacik
2024-07-10  7:28   ` Hanna Czenczek
2024-07-10 18:42     ` Josef Bacik
2024-07-11  8:21       ` Hanna Czenczek
2024-07-11 14:27         ` Hanna Czenczek
2024-07-11 14:34         ` Josef Bacik
2024-07-11 15:04           ` Hanna Czenczek
2024-07-10 17:28 ` Stefan Hajnoczi
2024-07-11  8:31   ` Hanna Czenczek
2024-08-29  8:07 ` Miklos Szeredi
2024-08-29 12:37   ` Hanna Czenczek
2024-08-29 13:07     ` Miklos Szeredi
     [not found]       ` <b82dd5f9-a214-4a13-b500-38b07f1e9761@redhat.com>
2024-08-29 13:21         ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240709111918.31233-2-hreitz@redhat.com \
    --to=hreitz@redhat.com \
    --cc=corbet@lwn.net \
    --cc=eperezma@redhat.com \
    --cc=gmaglione@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=virtualization@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).