9pfs: make multidevs=remap default

1a6ed33cc5 introduced option multidevs=remap|forbid|warn and made
"warn" the default option.

As it turned out though, e.g. by several reports in conjunction with
following 9p client issue:

850925a813

Many people are just ignoring this warning, or even do not notice the
warning at all. Therefore make multidevs=remap the new default option to
prevent people to run into such kind of severe misbehaviours in the first
place.

From performance PoV the runtime overhead of multidevs=remap is
neglectable with few or even just only one device being shared with the
same 9p export, expected to be constant Theta(1). The inode numbers
emitted to guest also just loose one bit (since 6b6aa8285d) for the 1st
device being shared.

Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <09cc84e5561f66b6a8cf49b3532c6c78a6acc806.1734876877.git.qemu_oss@crudebyte.com>
This commit is contained in:
Christian Schoenebeck 2024-12-22 15:10:44 +01:00
parent 0ad7cb925e
commit a2f17bd40b
2 changed files with 30 additions and 22 deletions

View file

@ -1538,6 +1538,9 @@ static int local_parse_opts(QemuOpts *opts, FsDriverEntry *fse, Error **errp)
"[remap|forbid|warn]\n");
return -1;
}
} else {
fse->export_flags &= ~V9FS_FORBID_MULTIDEVS;
fse->export_flags |= V9FS_REMAP_INODES;
}
if (!path) {

View file

@ -1951,32 +1951,37 @@ SRST
Specifies the tag name to be used by the guest to mount this
export point.
``multidevs=multidevs``
Specifies how to deal with multiple devices being shared with a
9p export. Supported behaviours are either "remap", "forbid" or
"warn". The latter is the default behaviour on which virtfs 9p
expects only one device to be shared with the same export, and
if more than one device is shared and accessed via the same 9p
export then only a warning message is logged (once) by qemu on
host side. In order to avoid file ID collisions on guest you
should either create a separate virtfs export for each device to
be shared with guests (recommended way) or you might use "remap"
instead which allows you to share multiple devices with only one
export instead, which is achieved by remapping the original
inode numbers from host to guest in a way that would prevent
such collisions. Remapping inodes in such use cases is required
``multidevs=remap|forbid|warn``
Specifies how to deal with multiple devices being shared with
the same 9p export in order to avoid file ID collisions on guest.
Supported behaviours are either "remap" (default), "forbid" or
"warn".
``remap`` : assumes the possibility that more than one device is
shared with the same 9p export. Therefore inode numbers from host
are remapped for guest in a way that would prevent file ID
collisions on guest. Remapping inodes in such cases is required
because the original device IDs from host are never passed and
exposed on guest. Instead all files of an export shared with
virtfs always share the same device id on guest. So two files
virtfs always share the same device ID on guest. So two files
with identical inode numbers but from actually different devices
on host would otherwise cause a file ID collision and hence
potential misbehaviours on guest. "forbid" on the other hand
assumes like "warn" that only one device is shared by the same
export, however it will not only log a warning message but also
deny access to additional devices on guest. Note though that
"forbid" does currently not block all possible file access
operations (e.g. readdir() would still return entries from other
devices).
potential severe misbehaviours on guest.
``warn`` : virtfs 9p expects only one device to be shared with
the same export. If however more than one device is shared and
accessed via the same 9p export then only a warning message is
logged (once) by qemu on host side. No further action is performed
in this case that would prevent file ID collisions on guest. This
could thus lead to severe misbehaviours in this case like wrong
files being accessed and data corruption on the exported tree.
``forbid`` : assumes like "warn" that only one device is shared
by the same 9p export, however it will not only log a warning
message but also deny access to additional devices on guest. Note
though that "forbid" does currently not block all possible file
access operations (e.g. readdir() would still return entries from
other devices).
ERST
DEF("iscsi", HAS_ARG, QEMU_OPTION_iscsi,