* Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: Askar Safin @ 2026-06-16 1:15 UTC (permalink / raw)
To: joannelkoong
Cc: akpm, axboe, bernd, brauner, david, dhowells, fuse-devel, hch,
jack, linux-api, linux-fsdevel, linux-kernel, linux-mm, miklos,
netdev, patches, pfalcato, rostedt, safinaskar, torvalds, val,
viro, willy
In-Reply-To: <CAJnrk1Y9egYizkx1H9K0cqxSYuB+7vLvQbV7Tf4C5eHFqnnC-A@mail.gmail.com>
Joanne Koong <joannelkoong@gmail.com>:
> > speaking of fuse_dev_splice……_write actually, this series has broken
> > xdg-document-portal!
> >
> > https://github.com/flatpak/xdg-desktop-portal/issues/2026
> >
> > Specifically what happens is that the EINVAL is returned due to oh.len
> > != nbytes:
> >
> > fuse_dev_do_write: oh.len 16400 != nbytes 15526
> >
> > (where 16400 == 16384 (read len) + 16, 15526 == 15510 (file len) + 16)
> >
> > After reverting the series, there is no error because oh.len
> > becomes 15526 too.
>
> I think this is because of how libfuse handles eof / short reads. When
> it detects a short read, it fixes up the header length after the
> header was already vmspliced to the pipe because it assumes vmsplice
> mapped the header's page into the pipe by reference. It assumes that
> modifying the header length in place gets then reflected in what the
> pipe later splices out.
>
> The logic for this happens in fuse_send_data_iov() [1]:
> a) sets out->len = headerlen (16) + len (16384) = 16400 in the
> stack-allocated fuse_out_header
> b) vmsplices the header to the pipe
> c) splices the backing file to the pipe. if this hits EOF, it'll get
> back 15510 instead of 16384
> d) detects the short read [2], fixes up the stack out->len = 16 + 15510 = 15526
> e) splices the pipe to /dev/fuse
>
> After this patch, step b) is a straight copy which means step d)'s
> fixup doesn't modify what's in the pipe. This could be fixed up in
> libfuse to not depend on modify-after-vmsplice, but I don't think this
> helps for applications using already-released libfuse versions. I
> think this patch needs to be reverted.
>
> Thanks,
> Joanne
>
> [1] https://github.com/libfuse/libfuse/blob/master/lib/fuse_lowlevel.c#L846
> [2] https://github.com/libfuse/libfuse/blob/master/lib/fuse_lowlevel.c#L956
Uh, this is very unfortunate. But I still want to remove vmsplice.
Maybe we can somehow save my patchsets? For example, let's return EINVAL
for this particular combination (writable pipe + SPLICE_F_NONBLOCK).
--
Askar Safin
^ permalink raw reply
* Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: Joanne Koong @ 2026-06-16 6:38 UTC (permalink / raw)
To: Askar Safin
Cc: akpm, axboe, bernd, brauner, david, dhowells, fuse-devel, hch,
jack, linux-api, linux-fsdevel, linux-kernel, linux-mm, miklos,
netdev, patches, pfalcato, rostedt, torvalds, val, viro, willy
In-Reply-To: <20260616011516.4039110-1-safinaskar@gmail.com>
On Mon, Jun 15, 2026 at 9:15 PM Askar Safin <safinaskar@gmail.com> wrote:
>
> Joanne Koong <joannelkoong@gmail.com>:
> > > speaking of fuse_dev_splice……_write actually, this series has broken
> > > xdg-document-portal!
> > >
> > > https://github.com/flatpak/xdg-desktop-portal/issues/2026
> > >
> > > Specifically what happens is that the EINVAL is returned due to oh.len
> > > != nbytes:
> > >
> > > fuse_dev_do_write: oh.len 16400 != nbytes 15526
> > >
> > > (where 16400 == 16384 (read len) + 16, 15526 == 15510 (file len) + 16)
> > >
> > > After reverting the series, there is no error because oh.len
> > > becomes 15526 too.
> >
> > I think this is because of how libfuse handles eof / short reads. When
> > it detects a short read, it fixes up the header length after the
> > header was already vmspliced to the pipe because it assumes vmsplice
> > mapped the header's page into the pipe by reference. It assumes that
> > modifying the header length in place gets then reflected in what the
> > pipe later splices out.
> >
> > The logic for this happens in fuse_send_data_iov() [1]:
> > a) sets out->len = headerlen (16) + len (16384) = 16400 in the
> > stack-allocated fuse_out_header
> > b) vmsplices the header to the pipe
> > c) splices the backing file to the pipe. if this hits EOF, it'll get
> > back 15510 instead of 16384
> > d) detects the short read [2], fixes up the stack out->len = 16 + 15510 = 15526
> > e) splices the pipe to /dev/fuse
> >
> > After this patch, step b) is a straight copy which means step d)'s
> > fixup doesn't modify what's in the pipe. This could be fixed up in
> > libfuse to not depend on modify-after-vmsplice, but I don't think this
> > helps for applications using already-released libfuse versions. I
> > think this patch needs to be reverted.
> >
> > Thanks,
> > Joanne
> >
> > [1] https://github.com/libfuse/libfuse/blob/master/lib/fuse_lowlevel.c#L846
> > [2] https://github.com/libfuse/libfuse/blob/master/lib/fuse_lowlevel.c#L956
>
> Uh, this is very unfortunate. But I still want to remove vmsplice.
> Maybe we can somehow save my patchsets? For example, let's return EINVAL
> for this particular combination (writable pipe + SPLICE_F_NONBLOCK).
writable pipe + SPLICE_F_NONBLOCK is a valid vmsplice call today, so I
think returning -EINVAL would still cause regressions. It happens to
be a workaround for libfuse only because libfuse falls back to
writev() when vmsplice fails, but I don't think we can assume other
callers have the same fallback.
Thanks,
Joanne
>
> --
> Askar Safin
^ permalink raw reply
* Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: David Hildenbrand (Arm) @ 2026-06-16 7:38 UTC (permalink / raw)
To: Joanne Koong, Askar Safin
Cc: akpm, axboe, bernd, brauner, dhowells, fuse-devel, hch, jack,
linux-api, linux-fsdevel, linux-kernel, linux-mm, miklos, netdev,
patches, pfalcato, rostedt, torvalds, val, viro, willy
In-Reply-To: <CAJnrk1Z_V8TShvWV6zwTMQqXra3J4J5CL5ofFMm9DGoLj9whEw@mail.gmail.com>
On 6/16/26 08:38, Joanne Koong wrote:
> On Mon, Jun 15, 2026 at 9:15 PM Askar Safin <safinaskar@gmail.com> wrote:
>>
>> Joanne Koong <joannelkoong@gmail.com>:
>>>
>>> I think this is because of how libfuse handles eof / short reads. When
>>> it detects a short read, it fixes up the header length after the
>>> header was already vmspliced to the pipe because it assumes vmsplice
>>> mapped the header's page into the pipe by reference. It assumes that
>>> modifying the header length in place gets then reflected in what the
>>> pipe later splices out.
>>>
>>> The logic for this happens in fuse_send_data_iov() [1]:
>>> a) sets out->len = headerlen (16) + len (16384) = 16400 in the
>>> stack-allocated fuse_out_header
>>> b) vmsplices the header to the pipe
>>> c) splices the backing file to the pipe. if this hits EOF, it'll get
>>> back 15510 instead of 16384
>>> d) detects the short read [2], fixes up the stack out->len = 16 + 15510 = 15526
>>> e) splices the pipe to /dev/fuse
>>>
>>> After this patch, step b) is a straight copy which means step d)'s
>>> fixup doesn't modify what's in the pipe. This could be fixed up in
>>> libfuse to not depend on modify-after-vmsplice, but I don't think this
>>> helps for applications using already-released libfuse versions. I
>>> think this patch needs to be reverted.
>>>
>>> Thanks,
>>> Joanne
>>>
>>> [1] https://github.com/libfuse/libfuse/blob/master/lib/fuse_lowlevel.c#L846
>>> [2] https://github.com/libfuse/libfuse/blob/master/lib/fuse_lowlevel.c#L956
>>
>> Uh, this is very unfortunate. But I still want to remove vmsplice.
>> Maybe we can somehow save my patchsets? For example, let's return EINVAL
>> for this particular combination (writable pipe + SPLICE_F_NONBLOCK).
>
> writable pipe + SPLICE_F_NONBLOCK is a valid vmsplice call today, so I
> think returning -EINVAL would still cause regressions.
I recall that, after the vmsplice vs. fork security issue happened, vmsplice was
blocked in some container runtimes. e.g., [1] still seems to disable it, added
in 2021 [2].
So maybe one could at least assume that many containerized workloads should be
able to deal with vmsplice not being available nowadays. But in the general case
I'm afraid Joanne is right.
[1] https://github.com/containers/common/blob/main/pkg/seccomp/seccomp.json
[2]
https://github.com/containers/common/commit/7ced5daafa0e36102eb931050ba3ff99f42bdfac
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Christoph Hellwig @ 2026-06-16 13:31 UTC (permalink / raw)
To: Pankaj Raghav
Cc: linux-xfs, bfoster, lukas, Darrick J . Wong, dgc, gost.dev,
pankaj.raghav, andres, kundan.kumar, cem, Zhang Yi, linux-fsdevel,
linux-api
In-Reply-To: <20260611114029.176200-4-p.raghav@samsung.com>
[API questions for Zhang and -fsdevel/ -api below)
> + unsigned int blksize = i_blocksize(inode);
> + loff_t offset_aligned = round_down(offset, blksize);
I think this actually needs to found up instead of rounding down.
> + /*
> + * Zero the tail of the old EOF block and any space up to the new
> + * offset.
> + * In the usual truncate path, xfs_falloc_setsize takes care of
> + * zeroing those blocks.
> + */
> + if (offset_aligned > old_size) {
> + trace_xfs_zero_eof(ip, old_size, offset_aligned - old_size);
> + error = xfs_zero_range(ip, old_size, offset_aligned - old_size,
> + NULL, &did_zero);
> + if (error)
> + return error;
> + }
... then this will properly zero from the old i_size to the first block
boundary after the old size.
> + error = xfs_alloc_file_space(ip, offset, len,
> + XFS_ALLOC_FILE_SPACE_WRITE_ZEROES);
... and here we need to pass offset_aligned instead of offset and
a new calculated len based on the last block boundary, and then
zero again after that. That is assuming FALLOC_FL_WRITE_ZEROES
allows unaligned ranges for file systems. The block code doesn't,
but I can't quite follow the ext4 code if it does or not, and there
is no mention of FALLOC_FL_WRITE_ZEROES even in the latest man-pages
tree.
Maybe we also want xfstests that try unaligned FALLOC_FL_WRITE_ZEROES
and make sure no existing data before the range is lost and the
entire range is zeroed?
> + if (error)
> + return error;
> +
> + /*
> + * xfs_falloc_setsize() would re-zero the written extents via
> + * iomap_zero_range(). Use xfs_setfilesize() instead.
> + * Update in-core i_size first as xfs_setfilesize() clamps the on-disk
> + * size to it.
> + */
> + if (new_size > i_size_read(inode))
> + i_size_write(inode, new_size);
I think Sashiko is right that we need a pagecache_isize_extended and
filemap_write_and_wait_range calls here.
^ permalink raw reply
* [PATCH 0/2] fuse: allow FUSE_SYNCFS for privileged userspace servers
From: Jimmy Zuber @ 2026-06-16 15:19 UTC (permalink / raw)
To: Miklos Szeredi
Cc: fuse-devel, linux-fsdevel, linux-api, linux-kernel, Shuah Khan,
linux-kselftest
FUSE_SYNCFS (propagating syncfs()/sync() to the server) is currently
enabled only for virtiofs and fuseblk, since an untrusted server can stall
sync(). But any FUSE filesystem may buffer data in the server that should
reach storage on sync(); the only thing that should gate it is whether the
mount was set up with host privilege. This series lets a plain /dev/fuse
server opt in via a new FUSE_HAS_SYNCFS INIT flag, honored only for mounts
owned by the initial user namespace. Patch 1 has the full rationale and
the security argument.
Patch 1: the kernel change (UAPI flag + gating in process_init_reply()).
Patch 2: a selftest that speaks the raw FUSE protocol over /dev/fuse, so
it can withhold the flag and directly observe whether the
FUSE_SYNCFS opcode is forwarded -- covering the privileged,
opt-out, and unprivileged-userns cases.
A matching libfuse change (FUSE_CAP_SYNCFS negotiation) will be sent to the
libfuse project once the UAPI flag here is settled.
Testing: built and booted under QEMU (x86_64). The selftest passes all
three cases. A separate end-to-end check on a FUSE_WRITEBACK_CACHE mount
confirmed the point of the change: after write() the server had received 0
bytes (data dirty in the page cache), and after syncfs() it received the
full buffered payload followed by FUSE_SYNCFS -- i.e. syncfs() flushes
cached data to the server on a privileged mount.
Jimmy Zuber (2):
fuse: allow FUSE_SYNCFS for privileged userspace servers
selftests/fuse: add test for FUSE_HAS_SYNCFS privilege gating
fs/fuse/inode.c | 16 +
include/uapi/linux/fuse.h | 11 +-
.../selftests/filesystems/fuse/.gitignore | 1 +
.../selftests/filesystems/fuse/Makefile | 2 +-
.../selftests/filesystems/fuse/test_syncfs.c | 318 ++++++++++++++++++
5 files changed, 346 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/filesystems/fuse/test_syncfs.c
base-commit: 7d87a5a284bb34edb3f4e7e312ef403b3385a7b7
--
2.50.1
^ permalink raw reply
* [PATCH 1/2] fuse: allow FUSE_SYNCFS for privileged userspace servers
From: Jimmy Zuber @ 2026-06-16 15:19 UTC (permalink / raw)
To: Miklos Szeredi
Cc: fuse-devel, linux-fsdevel, linux-api, linux-kernel, Shuah Khan,
linux-kselftest
In-Reply-To: <20260616151909.916667-1-jamz@amazon.com>
Propagating syncfs()/sync() to a FUSE server via FUSE_SYNCFS lets the
server flush its own cached or intermediate state when userspace asks the
filesystem to sync. This is currently enabled only for virtiofs and
fuseblk, because an untrusted server can use it to stall sync()
indefinitely (see commit 2d82ab251ef0 ("virtiofs: propagate sync() to file
server"), and commit d3906d8f3cee ("fuse: enable FUSE_SYNCFS for all
fuseblk servers")). Both of those mount types require host privilege to
set up, so the server is trusted not to abuse it.
There is nothing virtiofs- or block-specific about wanting to handle
syncfs(), though. A plain /dev/fuse server is just as entitled to
participate in the sync() path -- so that data it has buffered reaches
stable storage when the user asks for it -- provided it is equally
trusted. The relevant trust boundary is whether the mount was set up with
host privilege.
Add an opt-in INIT flag, FUSE_HAS_SYNCFS, and enable propagation only when
both:
- the server sets FUSE_HAS_SYNCFS in its INIT reply, and
- the mount is owned by the initial user namespace
(fc->user_ns == &init_user_ns).
The user namespace check is the key restriction. A regular fuse mount is
mountable from a non-initial user namespace (FS_USERNS_MOUNT), where the
server is untrusted; the VFS already marks such mounts with
SB_I_UNTRUSTED_MOUNTER. Restricting FUSE_SYNCFS to init_user_ns mounts
preserves the original DoS protection for unprivileged servers in full,
while mirroring how virtiofs and fuseblk earn syncfs by construction
(neither is mountable from a non-initial user namespace).
The flag is only advertised to servers whose mount is owned by the initial
user namespace, so an unprivileged server is never invited to opt in (and
is ignored by fuse_syncfs_enable() if it sets the flag anyway).
Signed-off-by: Jimmy Zuber <jamz@amazon.com>
Assisted-by: Claude:claude-opus-4-8 [Claude-Code]
---
fs/fuse/inode.c | 16 ++++++++++++++++
include/uapi/linux/fuse.h | 11 ++++++++++-
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index d975073c6029..d0005a373729 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -1266,6 +1266,16 @@ struct fuse_init_args {
struct fuse_mount *fm;
};
+/*
+ * A server can stall syncfs()/sync(), so only honor FUSE_HAS_SYNCFS for
+ * mounts owned by the initial user namespace, i.e. set up with host
+ * privilege (like virtiofs and fuseblk).
+ */
+static bool fuse_syncfs_enable(struct fuse_conn *fc, u64 flags)
+{
+ return (flags & FUSE_HAS_SYNCFS) && fc->user_ns == &init_user_ns;
+}
+
static void process_init_reply(struct fuse_args *args, int error)
{
struct fuse_init_args *ia = container_of(args, typeof(*ia), args);
@@ -1406,6 +1416,9 @@ static void process_init_reply(struct fuse_args *args, int error)
if (flags & FUSE_REQUEST_TIMEOUT)
timeout = arg->request_timeout;
+
+ if (fuse_syncfs_enable(fc, flags))
+ fc->sync_fs = 1;
} else {
ra_pages = fc->max_read / PAGE_SIZE;
fc->no_lock = 1;
@@ -1473,6 +1486,9 @@ static struct fuse_init_args *fuse_new_init(struct fuse_mount *fm)
flags |= FUSE_SUBMOUNTS;
if (IS_ENABLED(CONFIG_FUSE_PASSTHROUGH))
flags |= FUSE_PASSTHROUGH;
+ /* Only offered to host-privileged mounts; see fuse_syncfs_enable(). */
+ if (fm->fc->user_ns == &init_user_ns)
+ flags |= FUSE_HAS_SYNCFS;
/*
* This is just an information flag for fuse server. No need to check
diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
index c13e1f9a2f12..de1002063ca2 100644
--- a/include/uapi/linux/fuse.h
+++ b/include/uapi/linux/fuse.h
@@ -240,6 +240,9 @@
* - add FUSE_COPY_FILE_RANGE_64
* - add struct fuse_copy_file_range_out
* - add FUSE_NOTIFY_PRUNE
+ *
+ * 7.46
+ * - add FUSE_HAS_SYNCFS opt-in flag for privileged userspace servers
*/
#ifndef _LINUX_FUSE_H
@@ -275,7 +278,7 @@
#define FUSE_KERNEL_VERSION 7
/** Minor version number of this interface */
-#define FUSE_KERNEL_MINOR_VERSION 45
+#define FUSE_KERNEL_MINOR_VERSION 46
/** The node ID of the root inode */
#define FUSE_ROOT_ID 1
@@ -448,6 +451,11 @@ struct fuse_file_lock {
* FUSE_OVER_IO_URING: Indicate that client supports io-uring
* FUSE_REQUEST_TIMEOUT: kernel supports timing out requests.
* init_out.request_timeout contains the timeout (in secs)
+ * FUSE_HAS_SYNCFS: server requests that syncfs()/sync() be propagated as
+ * FUSE_SYNCFS requests. Only honored by the kernel for mounts
+ * owned by the initial user namespace (i.e. set up with real
+ * host privilege), since an untrusted server can use this to
+ * stall sync(). Unprivileged (user namespace) mounts ignore it.
*/
#define FUSE_ASYNC_READ (1 << 0)
#define FUSE_POSIX_LOCKS (1 << 1)
@@ -495,6 +503,7 @@ struct fuse_file_lock {
#define FUSE_ALLOW_IDMAP (1ULL << 40)
#define FUSE_OVER_IO_URING (1ULL << 41)
#define FUSE_REQUEST_TIMEOUT (1ULL << 42)
+#define FUSE_HAS_SYNCFS (1ULL << 43)
/**
* CUSE INIT request/reply flags
--
2.50.1
^ permalink raw reply related
* [PATCH 2/2] selftests/fuse: add test for FUSE_HAS_SYNCFS privilege gating
From: Jimmy Zuber @ 2026-06-16 15:19 UTC (permalink / raw)
To: Miklos Szeredi
Cc: fuse-devel, linux-fsdevel, linux-api, linux-kernel, Shuah Khan,
linux-kselftest
In-Reply-To: <20260616151909.916667-1-jamz@amazon.com>
Add a selftest that talks the raw FUSE protocol over /dev/fuse (rather
than via libfuse, which negotiates INIT internally) so it can both choose
whether to advertise FUSE_HAS_SYNCFS and directly observe whether a
FUSE_SYNCFS opcode is forwarded by the kernel.
Three cases are covered:
T1: host-root mount, server sets FUSE_HAS_SYNCFS
-> FUSE_SYNCFS must reach the server.
T2: host-root mount, server does not opt in
-> FUSE_SYNCFS must not be sent (back-compat).
T3: unprivileged user-namespace mount, server sets FUSE_HAS_SYNCFS
-> kernel must still withhold FUSE_SYNCFS.
T3 requires CONFIG_USER_NS and the ability to create an unprivileged
user-namespace mount; it is skipped otherwise.
Signed-off-by: Jimmy Zuber <jamz@amazon.com>
Assisted-by: Claude:claude-opus-4-8 [Claude-Code]
---
.../selftests/filesystems/fuse/.gitignore | 1 +
.../selftests/filesystems/fuse/Makefile | 2 +-
.../selftests/filesystems/fuse/test_syncfs.c | 318 ++++++++++++++++++
3 files changed, 320 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/filesystems/fuse/test_syncfs.c
diff --git a/tools/testing/selftests/filesystems/fuse/.gitignore b/tools/testing/selftests/filesystems/fuse/.gitignore
index 3e72e742d08e..4e92f363c74a 100644
--- a/tools/testing/selftests/filesystems/fuse/.gitignore
+++ b/tools/testing/selftests/filesystems/fuse/.gitignore
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
fuse_mnt
fusectl_test
+test_syncfs
diff --git a/tools/testing/selftests/filesystems/fuse/Makefile b/tools/testing/selftests/filesystems/fuse/Makefile
index 612aad69a93a..cbba01635226 100644
--- a/tools/testing/selftests/filesystems/fuse/Makefile
+++ b/tools/testing/selftests/filesystems/fuse/Makefile
@@ -2,7 +2,7 @@
CFLAGS += -Wall -O2 -g $(KHDR_INCLUDES)
-TEST_GEN_PROGS := fusectl_test
+TEST_GEN_PROGS := fusectl_test test_syncfs
TEST_GEN_FILES := fuse_mnt
include ../../lib.mk
diff --git a/tools/testing/selftests/filesystems/fuse/test_syncfs.c b/tools/testing/selftests/filesystems/fuse/test_syncfs.c
new file mode 100644
index 000000000000..c00375ffeaea
--- /dev/null
+++ b/tools/testing/selftests/filesystems/fuse/test_syncfs.c
@@ -0,0 +1,318 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test that FUSE_SYNCFS is propagated to a userspace server only when the
+ * server opts in with FUSE_HAS_SYNCFS *and* the mount is owned by the initial
+ * user namespace (i.e. set up with real host privilege).
+ *
+ * Unlike the libfuse-based selftests, this talks the raw FUSE wire protocol
+ * over /dev/fuse so it can (a) choose whether to advertise FUSE_HAS_SYNCFS in
+ * the INIT reply and (b) observe directly whether a FUSE_SYNCFS opcode arrives.
+ */
+#define _GNU_SOURCE
+#include <errno.h>
+#include <fcntl.h>
+#include <poll.h>
+#include <sched.h>
+#include <signal.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <sys/eventfd.h>
+#include <sys/mount.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <sys/uio.h>
+#include <sys/wait.h>
+#include <linux/fuse.h>
+
+#include "../../kselftest.h"
+
+#define FUSE_ROOT_ID 1
+
+/*
+ * eventfd the server child writes once when it receives FUSE_SYNCFS; the
+ * parent poll()s it to observe (or rule out) propagation.
+ */
+static int syncfs_evfd;
+
+static void reply(int fd, uint64_t unique, int error, void *data, size_t len)
+{
+ struct fuse_out_header oh = {
+ .len = sizeof(oh) + len,
+ .error = error,
+ .unique = unique,
+ };
+ struct iovec iov[2] = {
+ { &oh, sizeof(oh) },
+ { data, len },
+ };
+
+ if (writev(fd, iov, data ? 2 : 1) < 0)
+ ksft_print_msg("server writev failed: %s\n", strerror(errno));
+}
+
+static void fill_attr(struct fuse_attr *a, uint64_t ino, uint32_t mode,
+ uint32_t nlink)
+{
+ memset(a, 0, sizeof(*a));
+ a->ino = ino;
+ a->mode = mode;
+ a->nlink = nlink;
+ a->blksize = 4096;
+}
+
+/*
+ * Minimal FUSE server. Advertises FUSE_HAS_SYNCFS in its INIT reply iff
+ * @advertise is set. Signals syncfs_evfd when a FUSE_SYNCFS opcode arrives.
+ */
+#define SERVER_MAX_WRITE 65536
+static void run_server(int fd, int advertise)
+{
+ /*
+ * The kernel rejects reads (EINVAL) whose buffer is smaller than
+ * max_write + header, so size generously for the max_write we
+ * advertise in the INIT reply below.
+ */
+ static char buf[SERVER_MAX_WRITE + 4096];
+
+ for (;;) {
+ ssize_t n = read(fd, buf, sizeof(buf));
+ struct fuse_in_header *ih = (void *)buf;
+
+ if (n < 0) {
+ if (errno == EINTR || errno == EAGAIN)
+ continue;
+ return; /* device closed on unmount/abort */
+ }
+ if (n < (ssize_t)sizeof(*ih))
+ continue;
+
+ switch (ih->opcode) {
+ case FUSE_INIT: {
+ struct fuse_init_in *in = (void *)(ih + 1);
+ struct fuse_init_out out = {0};
+ uint64_t flags = FUSE_INIT_EXT;
+
+ out.major = FUSE_KERNEL_VERSION;
+ out.minor = FUSE_KERNEL_MINOR_VERSION;
+ out.max_readahead = in->max_readahead;
+ out.max_write = SERVER_MAX_WRITE;
+ out.max_background = 16;
+ out.congestion_threshold = 12;
+ if (advertise)
+ flags |= FUSE_HAS_SYNCFS;
+ out.flags = flags;
+ out.flags2 = flags >> 32;
+ reply(fd, ih->unique, 0, &out, sizeof(out));
+ break;
+ }
+ case FUSE_GETATTR: {
+ struct fuse_attr_out out = {0};
+
+ fill_attr(&out.attr, FUSE_ROOT_ID, S_IFDIR | 0755, 2);
+ reply(fd, ih->unique, 0, &out, sizeof(out));
+ break;
+ }
+ case FUSE_SYNCFS: {
+ uint64_t one = 1;
+
+ if (write(syncfs_evfd, &one, sizeof(one)) < 0)
+ ksft_print_msg("server eventfd write failed: %s\n",
+ strerror(errno));
+ reply(fd, ih->unique, 0, NULL, 0);
+ break;
+ }
+ default:
+ /*
+ * Anything else (e.g. OPENDIR from opening the mount
+ * root) is not needed to drive this test; -ENOSYS lets
+ * the kernel proceed.
+ */
+ reply(fd, ih->unique, -ENOSYS, NULL, 0);
+ break;
+ }
+ }
+}
+
+/*
+ * Mount a fuse fs backed by a forked server, issue syncfs(), and report
+ * whether the server observed FUSE_SYNCFS. Returns 0 on success, -1 if the
+ * environment could not support the test (caller should skip).
+ */
+static int do_mount_and_syncfs(const char *mnt, int advertise, int *seen)
+{
+ struct pollfd pfd = { .events = POLLIN };
+ char opts[256];
+ int fd, mfd = -1, i;
+ pid_t pid;
+
+ syncfs_evfd = eventfd(0, EFD_CLOEXEC);
+ if (syncfs_evfd < 0)
+ return -1;
+
+ fd = open("/dev/fuse", O_RDWR);
+ if (fd < 0)
+ goto out_evfd;
+
+ mkdir(mnt, 0755);
+ snprintf(opts, sizeof(opts),
+ "fd=%d,rootmode=40000,user_id=%d,group_id=%d",
+ fd, getuid(), getgid());
+
+ if (mount("fuse", mnt, "fuse", 0, opts) < 0)
+ goto out_fd;
+
+ pid = fork();
+ if (pid < 0)
+ goto out_umount;
+ if (pid == 0) {
+ run_server(fd, advertise);
+ _exit(0);
+ }
+
+ /*
+ * The parent does not service the fuse fd; the child does. Close our
+ * copy so the kernel sees a single server, and so that if the child
+ * dies the connection aborts instead of hanging us forever.
+ */
+ close(fd);
+
+ /*
+ * mount() returns before the server has answered FUSE_INIT, so the
+ * first open() can race and fail with ENOTCONN; retry until the
+ * handshake settles.
+ */
+ for (i = 0; i < 1000; i++) {
+ mfd = open(mnt, O_RDONLY | O_DIRECTORY);
+ if (mfd >= 0)
+ break;
+ usleep(1000);
+ }
+ if (mfd >= 0) {
+ syncfs(mfd);
+ close(mfd);
+ }
+
+ /*
+ * No waiting is needed: the server writes syncfs_evfd before it replies
+ * to FUSE_SYNCFS, and that reply is what unblocks the synchronous
+ * syncfs() above. So once syncfs() has returned, the eventfd is already
+ * signalled if the opcode was propagated, and will never be otherwise.
+ * poll() with a zero timeout therefore decides both cases immediately.
+ */
+ pfd.fd = syncfs_evfd;
+ *seen = poll(&pfd, 1, 0) > 0 && (pfd.revents & POLLIN);
+
+ kill(pid, SIGKILL);
+ waitpid(pid, NULL, 0);
+ umount2(mnt, MNT_DETACH);
+ close(syncfs_evfd);
+ return 0;
+
+out_umount:
+ umount2(mnt, MNT_DETACH);
+out_fd:
+ close(fd);
+out_evfd:
+ close(syncfs_evfd);
+ return -1;
+}
+
+/* T3: same as above but the mount is created inside a new user namespace. */
+static int run_in_userns(const char *mnt, int advertise, int *seen)
+{
+ uid_t uid = getuid();
+ gid_t gid = getgid();
+ char map[64];
+ int f;
+
+ if (unshare(CLONE_NEWUSER | CLONE_NEWNS) < 0)
+ return -1; /* unprivileged userns mounts unavailable */
+
+ f = open("/proc/self/setgroups", O_WRONLY);
+ if (f >= 0) {
+ dprintf(f, "deny");
+ close(f);
+ }
+ snprintf(map, sizeof(map), "0 %d 1", uid);
+ f = open("/proc/self/uid_map", O_WRONLY);
+ if (f < 0 || dprintf(f, "%s", map) < 0)
+ return -1;
+ close(f);
+ snprintf(map, sizeof(map), "0 %d 1", gid);
+ f = open("/proc/self/gid_map", O_WRONLY);
+ if (f < 0 || dprintf(f, "%s", map) < 0)
+ return -1;
+ close(f);
+
+ /* Need a mount namespace where we can mount fuse unprivileged. */
+ if (mount(NULL, "/", NULL, MS_REC | MS_PRIVATE, NULL) < 0)
+ return -1;
+
+ return do_mount_and_syncfs(mnt, advertise, seen);
+}
+
+int main(void)
+{
+ char mnt[] = "/tmp/fuse_syncfs_XXXXXX";
+ int seen, ret;
+
+ ksft_print_header();
+ ksft_set_plan(3);
+
+ /* Hard watchdog: never let a stuck syncfs hang the test runner. */
+ signal(SIGALRM, SIG_DFL);
+ alarm(60);
+
+ if (geteuid() != 0)
+ ksft_exit_skip("test requires root to mount fuse\n");
+
+ if (!mkdtemp(mnt))
+ ksft_exit_fail_msg("mkdtemp failed\n");
+
+ /* T1: host-root mount, server opts in -> syncfs must reach server. */
+ ret = do_mount_and_syncfs(mnt, 1, &seen);
+ if (ret < 0)
+ ksft_test_result_skip("T1: could not mount fuse\n");
+ else
+ ksft_test_result(seen,
+ "T1 host-root + FUSE_HAS_SYNCFS: server receives FUSE_SYNCFS\n");
+
+ /* T2: host-root mount, server does NOT opt in -> no FUSE_SYNCFS. */
+ ret = do_mount_and_syncfs(mnt, 0, &seen);
+ if (ret < 0)
+ ksft_test_result_skip("T2: could not mount fuse\n");
+ else
+ ksft_test_result(!seen,
+ "T2 host-root, no opt-in: server does NOT receive FUSE_SYNCFS\n");
+
+ /*
+ * T3: unprivileged userns mount, server opts in -> kernel must still
+ * withhold FUSE_SYNCFS. Run in a child since it unshares namespaces.
+ */
+ {
+ pid_t p = fork();
+
+ if (p == 0) {
+ int s = 0;
+ int r = run_in_userns(mnt, 1, &s);
+
+ _exit(r < 0 ? 2 : (s ? 1 : 0));
+ } else {
+ int status;
+
+ waitpid(p, &status, 0);
+ if (!WIFEXITED(status))
+ ksft_test_result_error("T3: child crashed\n");
+ else if (WEXITSTATUS(status) == 2)
+ ksft_test_result_skip("T3: userns fuse mount unavailable\n");
+ else
+ ksft_test_result(WEXITSTATUS(status) == 0,
+ "T3 unpriv userns + opt-in: FUSE_SYNCFS withheld\n");
+ }
+ }
+
+ rmdir(mnt);
+ ksft_finished();
+}
--
2.50.1
^ permalink raw reply related
* Re: [PATCH 1/2] fuse: allow FUSE_SYNCFS for privileged userspace servers
From: Miklos Szeredi @ 2026-06-17 8:22 UTC (permalink / raw)
To: Jimmy Zuber
Cc: fuse-devel, linux-fsdevel, linux-api, linux-kernel, Shuah Khan,
linux-kselftest
In-Reply-To: <20260616151909.916667-2-jamz@amazon.com>
On Tue, 16 Jun 2026 at 17:20, Jimmy Zuber <jamz@amazon.com> wrote:
> +/*
> + * A server can stall syncfs()/sync(), so only honor FUSE_HAS_SYNCFS for
> + * mounts owned by the initial user namespace, i.e. set up with host
> + * privilege (like virtiofs and fuseblk).
> + */
> +static bool fuse_syncfs_enable(struct fuse_conn *fc, u64 flags)
> +{
> + return (flags & FUSE_HAS_SYNCFS) && fc->user_ns == &init_user_ns;
> +}
Sounds really easy to trick: start the server in the initial user ns,
then clone the mounter with a new user/mount namespace. The
init_user_ns test will pass happily, since the server is running in
the initial namespace.
Thanks,
Miklos
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Pankaj Raghav (Samsung) @ 2026-06-17 9:44 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Pankaj Raghav, linux-xfs, bfoster, lukas, Darrick J . Wong, dgc,
gost.dev, andres, kundan.kumar, cem, Zhang Yi, linux-fsdevel,
linux-api
In-Reply-To: <ajFQPANpajmFuKpi@infradead.org>
On Tue, Jun 16, 2026 at 06:31:40AM -0700, Christoph Hellwig wrote:
> [API questions for Zhang and -fsdevel/ -api below)
>
> > + unsigned int blksize = i_blocksize(inode);
> > + loff_t offset_aligned = round_down(offset, blksize);
>
> I think this actually needs to found up instead of rounding down.
>
> > + /*
> > + * Zero the tail of the old EOF block and any space up to the new
> > + * offset.
> > + * In the usual truncate path, xfs_falloc_setsize takes care of
> > + * zeroing those blocks.
> > + */
> > + if (offset_aligned > old_size) {
> > + trace_xfs_zero_eof(ip, old_size, offset_aligned - old_size);
> > + error = xfs_zero_range(ip, old_size, offset_aligned - old_size,
> > + NULL, &did_zero);
> > + if (error)
> > + return error;
> > + }
>
> ... then this will properly zero from the old i_size to the first block
> boundary after the old size.
Hmm, right now we do this:
|----------|----------|----------|
^ ^ ^ ^
| | | |
old_size | offset |
| |
off_rd off_ru
At the moment, we zero out old_size to off_rd and pass offset to
xfs_alloc_file_space. xfs_alloc_file_space rounds down the offset to off_rd.
What you are proposing is to zero out old_size to off_ru, and pass
off_ru to xfs_alloc_file_space. I don't exactly understand the
difference.
>
> > + error = xfs_alloc_file_space(ip, offset, len,
> > + XFS_ALLOC_FILE_SPACE_WRITE_ZEROES);
>
> ... and here we need to pass offset_aligned instead of offset and
> a new calculated len based on the last block boundary, and then
> zero again after that. That is assuming FALLOC_FL_WRITE_ZEROES
> allows unaligned ranges for file systems. The block code doesn't,
> but I can't quite follow the ext4 code if it does or not, and there
> is no mention of FALLOC_FL_WRITE_ZEROES even in the latest man-pages
> tree.
I can't find any references to FALLOC_FL_WRITE_ZEROES in the man pages
master branch. Maybe we missed it. I can send a separate patch for that
once we have some clarity on the API.
>
> Maybe we also want xfstests that try unaligned FALLOC_FL_WRITE_ZEROES
> and make sure no existing data before the range is lost and the
> entire range is zeroed?
>
I added FALLOC_FL_WRITE_ZEROES support to ltp (both fsx and fsstress).
For example, generic/363 tests for unaligned writes and checks for any
stale data. By default, I think we do unaligned reads, writes and
truncate in fsx.
>
> > + if (error)
> > + return error;
> > +
> > + /*
> > + * xfs_falloc_setsize() would re-zero the written extents via
> > + * iomap_zero_range(). Use xfs_setfilesize() instead.
> > + * Update in-core i_size first as xfs_setfilesize() clamps the on-disk
> > + * size to it.
> > + */
> > + if (new_size > i_size_read(inode))
> > + i_size_write(inode, new_size);
>
> I think Sashiko is right that we need a pagecache_isize_extended and
> filemap_write_and_wait_range calls here.
>
Ok. Current fsx or fsstress did not expose this
problem. I will look into this. Thanks Christoph.
--
Pankaj
^ permalink raw reply
* Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: Christian Brauner @ 2026-06-17 11:07 UTC (permalink / raw)
To: Joanne Koong
Cc: Val Packett, Al Viro, Linus Torvalds, Askar Safin, linux-kernel,
linux-mm, linux-api, netdev, Matthew Wilcox, Jens Axboe,
Christoph Hellwig, David Howells, Andrew Morton,
David Hildenbrand, Pedro Falcato, Miklos Szeredi, patches,
linux-fsdevel, Jan Kara, Steven Rostedt, fuse-devel,
Bernd Schubert
In-Reply-To: <CAJnrk1Y9egYizkx1H9K0cqxSYuB+7vLvQbV7Tf4C5eHFqnnC-A@mail.gmail.com>
> After this patch, step b) is a straight copy which means step d)'s
> fixup doesn't modify what's in the pipe. This could be fixed up in
> libfuse to not depend on modify-after-vmsplice, but I don't think this
> helps for applications using already-released libfuse versions. I
> think this patch needs to be reverted.
Note, nothing was merged. I deliberately kept in -next though for a long
time to see how quickly we'd see regressions.
^ permalink raw reply
* Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: Andrei Vagin @ 2026-06-17 19:57 UTC (permalink / raw)
To: Christian Brauner
Cc: Joanne Koong, Val Packett, Al Viro, Linus Torvalds, Askar Safin,
linux-kernel, linux-mm, linux-api, netdev, Matthew Wilcox,
Jens Axboe, Christoph Hellwig, David Howells, Andrew Morton,
David Hildenbrand, Pedro Falcato, Miklos Szeredi, patches,
linux-fsdevel, Jan Kara, Steven Rostedt, fuse-devel,
Bernd Schubert, Aleksandr Mikhalitsyn, criu@lists.linux.dev
In-Reply-To: <20260617-attest-gewechselt-tragik-7ed473860051@brauner>
On Wed, Jun 17, 2026 at 4:08 AM Christian Brauner <brauner@kernel.org> wrote:
>
> > After this patch, step b) is a straight copy which means step d)'s
> > fixup doesn't modify what's in the pipe. This could be fixed up in
> > libfuse to not depend on modify-after-vmsplice, but I don't think this
> > helps for applications using already-released libfuse versions. I
> > think this patch needs to be reverted.
>
> Note, nothing was merged. I deliberately kept in -next though for a long
> time to see how quickly we'd see regressions.
The bait worked. CRIU wins a prize in this lottery.
The CRIU fifo test fails with this change. The problem is that vmsplice
with SPLICE_F_NONBLOCK to a fifo file descriptor fails with -EOPNOTSUPP.
It seems we need a fix like this one:
diff --git a/fs/pipe.c b/fs/pipe.c
index 429b0714ec57..6fc49e933727 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -1253,6 +1253,7 @@ static int fifo_open(struct inode *inode, struct
file *filp)
/* We can only do regular read/write on fifos */
stream_open(inode, filp);
+ filp->f_mode |= FMODE_NOWAIT;
switch (filp->f_mode & (FMODE_READ | FMODE_WRITE)) {
case FMODE_READ:
^ permalink raw reply related
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Zhang Yi @ 2026-06-18 3:22 UTC (permalink / raw)
To: Pankaj Raghav (Samsung), Christoph Hellwig
Cc: Pankaj Raghav, linux-xfs, bfoster, lukas, Darrick J . Wong, dgc,
gost.dev, andres, kundan.kumar, cem, linux-fsdevel, linux-api
In-Reply-To: <kn5dyqdxmsydibpfcurgpom5vwqtwinrz27oenh4pekks6ybdj@wyi4zkh7mogy>
On 6/17/2026 5:44 PM, Pankaj Raghav (Samsung) wrote:
> On Tue, Jun 16, 2026 at 06:31:40AM -0700, Christoph Hellwig wrote:
>> [API questions for Zhang and -fsdevel/ -api below)
>>
>>> + unsigned int blksize = i_blocksize(inode);
>>> + loff_t offset_aligned = round_down(offset, blksize);
>>
>> I think this actually needs to found up instead of rounding down.
>>
>>> + /*
>>> + * Zero the tail of the old EOF block and any space up to the new
>>> + * offset.
>>> + * In the usual truncate path, xfs_falloc_setsize takes care of
>>> + * zeroing those blocks.
>>> + */
>>> + if (offset_aligned > old_size) {
>>> + trace_xfs_zero_eof(ip, old_size, offset_aligned - old_size);
>>> + error = xfs_zero_range(ip, old_size, offset_aligned - old_size,
>>> + NULL, &did_zero);
>>> + if (error)
>>> + return error;
>>> + }
>>
>> ... then this will properly zero from the old i_size to the first block
>> boundary after the old size.
>
> Hmm, right now we do this:
>
> |----------|----------|----------|
> ^ ^ ^ ^
> | | | |
> old_size | offset |
> | |
> off_rd off_ru
>
> At the moment, we zero out old_size to off_rd and pass offset to
> xfs_alloc_file_space. xfs_alloc_file_space rounds down the offset to off_rd.
>
> What you are proposing is to zero out old_size to off_ru, and pass
> off_ru to xfs_alloc_file_space. I don't exactly understand the
> difference.
IMO, FALLOC_FL_WRITE_ZEROES should handle the unaligned cases, if the
'offset' and 'end' are not block-size aligned, then:
1) if the two blocks straddling the boundaries have not yet been allocated,
or allocated as unwritten, we should round outward the allocation range
and zero out all allocated blocks, including those two boundary blocks.
2) if the blocks at the boundaries are already in the written state — which
can occur when we call FALLOC_FL_WRITE_ZEROES within the file size. We
should be careful here: we should only zero the ranges [offset, offset_ru)
and [end_rd, end) for the boundary blocks, leaving the already-written
portions of the boundary blocks intact.
Thoughs?
Regarding the second point, the current ext4 implementation has an issue —
it zeroes out the entire boundary blocks. I overlooked this previously, and
I appreciate you pointing it out.
>
>>
>>> + error = xfs_alloc_file_space(ip, offset, len,
>>> + XFS_ALLOC_FILE_SPACE_WRITE_ZEROES);
>>
>> ... and here we need to pass offset_aligned instead of offset and
>> a new calculated len based on the last block boundary, and then
>> zero again after that. That is assuming FALLOC_FL_WRITE_ZEROES
>> allows unaligned ranges for file systems. The block code doesn't,
>> but I can't quite follow the ext4 code if it does or not, and there
>> is no mention of FALLOC_FL_WRITE_ZEROES even in the latest man-pages
>> tree.
>
>
> I can't find any references to FALLOC_FL_WRITE_ZEROES in the man pages
> master branch. Maybe we missed it. I can send a separate patch for that
> once we have some clarity on the API.
Yeah, I missed to update the man pages last year. Thanks.
Best Regards,
Yi.
>>
>> Maybe we also want xfstests that try unaligned FALLOC_FL_WRITE_ZEROES
>> and make sure no existing data before the range is lost and the
>> entire range is zeroed?
>>
>
> I added FALLOC_FL_WRITE_ZEROES support to ltp (both fsx and fsstress).
> For example, generic/363 tests for unaligned writes and checks for any
> stale data. By default, I think we do unaligned reads, writes and
> truncate in fsx.
>
>>
>>> + if (error)
>>> + return error;
>>> +
>>> + /*
>>> + * xfs_falloc_setsize() would re-zero the written extents via
>>> + * iomap_zero_range(). Use xfs_setfilesize() instead.
>>> + * Update in-core i_size first as xfs_setfilesize() clamps the on-disk
>>> + * size to it.
>>> + */
>>> + if (new_size > i_size_read(inode))
>>> + i_size_write(inode, new_size);
>>
>> I think Sashiko is right that we need a pagecache_isize_extended and
>> filemap_write_and_wait_range calls here.
>>
>
> Ok. Current fsx or fsstress did not expose this
> problem. I will look into this. Thanks Christoph.
>
> --
> Pankaj
>
^ permalink raw reply
* Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
From: Andrei Vagin @ 2026-06-18 6:34 UTC (permalink / raw)
To: Christian Brauner
Cc: Joanne Koong, Val Packett, Al Viro, Linus Torvalds, Askar Safin,
linux-kernel, linux-mm, linux-api, netdev, Matthew Wilcox,
Jens Axboe, Christoph Hellwig, David Howells, Andrew Morton,
David Hildenbrand, Pedro Falcato, Miklos Szeredi, patches,
linux-fsdevel, Jan Kara, Steven Rostedt, fuse-devel,
Bernd Schubert, Aleksandr Mikhalitsyn, criu@lists.linux.dev
In-Reply-To: <CANaxB-zK5q=Xw6UZTmeFtXsDZjUsPkFk=p485m-wtNTBnf4hgg@mail.gmail.com>
On Wed, Jun 17, 2026 at 12:57 PM Andrei Vagin <avagin@gmail.com> wrote:
>
> On Wed, Jun 17, 2026 at 4:08 AM Christian Brauner <brauner@kernel.org> wrote:
> >
> > > After this patch, step b) is a straight copy which means step d)'s
> > > fixup doesn't modify what's in the pipe. This could be fixed up in
> > > libfuse to not depend on modify-after-vmsplice, but I don't think this
> > > helps for applications using already-released libfuse versions. I
> > > think this patch needs to be reverted.
> >
> > Note, nothing was merged. I deliberately kept in -next though for a long
> > time to see how quickly we'd see regressions.
>
> The bait worked. CRIU wins a prize in this lottery.
>
> The CRIU fifo test fails with this change. The problem is that vmsplice
> with SPLICE_F_NONBLOCK to a fifo file descriptor fails with -EOPNOTSUPP.
Actually, this change introduces a performance and functional
regression for CRIU.
Here is a brief overview of how CRIU currently dumps memory pages:
CRIU injects a parasite code blob into the target process's address
space. The parasite invokes vmsplice() with the SPLICE_F_GIFT flag to
pin physical pages directly inside a pipe without copying them. The main
CRIU process then takes over from outside the target context, calling
splice() on the other end of the pipe to stream the data directly into
checkpoint image files or a remote network socket.
I ran a simple test that creates an anonymous mapping and touches every
page within it:
Without this patch, CRIU takes 9 seconds to dump the test process.
With this patch, It takes 18 seconds...
Plus, it obviously introduces some memory overhead.
If these changes are merged, we will need to completely rework the
memory dumping mechanism in CRIU. Using vmsplice() in this proposed form
no longer makes any sense for our architecture...
Thanks,
Andrei
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Pankaj Raghav (Samsung) @ 2026-06-18 8:18 UTC (permalink / raw)
To: Zhang Yi, hch
Cc: Christoph Hellwig, Pankaj Raghav, linux-xfs, bfoster, lukas,
Darrick J . Wong, dgc, gost.dev, andres, kundan.kumar, cem,
linux-fsdevel, linux-api
In-Reply-To: <557b2e5c-7c65-48de-87a9-6fba21eca99f@huaweicloud.com>
On Thu, Jun 18, 2026 at 11:22:45AM +0800, Zhang Yi wrote:
> On 6/17/2026 5:44 PM, Pankaj Raghav (Samsung) wrote:
> > On Tue, Jun 16, 2026 at 06:31:40AM -0700, Christoph Hellwig wrote:
> >> [API questions for Zhang and -fsdevel/ -api below)
> >>
> >>> + unsigned int blksize = i_blocksize(inode);
> >>> + loff_t offset_aligned = round_down(offset, blksize);
> >>
> >> I think this actually needs to found up instead of rounding down.
> >>
> >>> + /*
> >>> + * Zero the tail of the old EOF block and any space up to the new
> >>> + * offset.
> >>> + * In the usual truncate path, xfs_falloc_setsize takes care of
> >>> + * zeroing those blocks.
> >>> + */
> >>> + if (offset_aligned > old_size) {
> >>> + trace_xfs_zero_eof(ip, old_size, offset_aligned - old_size);
> >>> + error = xfs_zero_range(ip, old_size, offset_aligned - old_size,
> >>> + NULL, &did_zero);
> >>> + if (error)
> >>> + return error;
> >>> + }
> >>
> >> ... then this will properly zero from the old i_size to the first block
> >> boundary after the old size.
> >
> > Hmm, right now we do this:
> >
> > |----------|----------|----------|
> > ^ ^ ^ ^
> > | | | |
> > old_size | offset |
> > | |
> > off_rd off_ru
> >
> > At the moment, we zero out old_size to off_rd and pass offset to
> > xfs_alloc_file_space. xfs_alloc_file_space rounds down the offset to off_rd.
> >
> > What you are proposing is to zero out old_size to off_ru, and pass
> > off_ru to xfs_alloc_file_space. I don't exactly understand the
> > difference.
>
> IMO, FALLOC_FL_WRITE_ZEROES should handle the unaligned cases, if the
> 'offset' and 'end' are not block-size aligned, then:
>
> 1) if the two blocks straddling the boundaries have not yet been allocated,
> or allocated as unwritten, we should round outward the allocation range
> and zero out all allocated blocks, including those two boundary blocks.
> 2) if the blocks at the boundaries are already in the written state — which
> can occur when we call FALLOC_FL_WRITE_ZEROES within the file size. We
> should be careful here: we should only zero the ranges [offset, offset_ru)
> and [end_rd, end) for the boundary blocks, leaving the already-written
> portions of the boundary blocks intact.
>
> Thoughs?
Ok, this makes sense to me.
@Christoph, now I understood your reply about rounding up and rounding
down.
So, I could do xfs_zero_range(offset, offset_ru)[1] and xfs_zero_range(end_rd, end).
(offset_ru, end_rd) will be using the accelerated XFS_BMAPI_ZERO to
zero out the extents.
I also need to add pagecache_isize_extended and filemap_write_and_wait_range
to persist the xfs_zero_range calls before we call setfilesize.
xfs_zero_range should take care of the boundary blocks so that we don't
overwrite any data or zeroing out the unallocated or unwritten blocks as
pointed out in 1 and 2.
Let me know what you think. I am also wondering how fsx did not trigger
the boundary block edge case where the current impl might zero out user
data in the boundary blocks.
[1] if old_size < offset, then xfs_zero_range(old_size, offset_ru))
--
Pankaj
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Christoph Hellwig @ 2026-06-18 8:57 UTC (permalink / raw)
To: Pankaj Raghav (Samsung)
Cc: Zhang Yi, Pankaj Raghav, linux-xfs, bfoster, lukas,
Darrick J . Wong, dgc, gost.dev, andres, kundan.kumar, cem,
linux-fsdevel, linux-api
In-Reply-To: <6l3n2w2b7qoz2g3kfu3xsdjhlzq6m4ocs6ptq2esq27wxrb5ve@5gqv4ei4gi4b>
On Thu, Jun 18, 2026 at 10:18:49AM +0200, Pankaj Raghav (Samsung) wrote:
> So, I could do xfs_zero_range(offset, offset_ru)[1] and xfs_zero_range(end_rd, end).
> (offset_ru, end_rd) will be using the accelerated XFS_BMAPI_ZERO to
> zero out the extents.
Yeah.
> I also need to add pagecache_isize_extended and filemap_write_and_wait_range
> to persist the xfs_zero_range calls before we call setfilesize.
Yeah, Or we need to find a way to use xfs_falloc_setsize after all
which would share all that code, although I'm not really sure how
that would work best.
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Christoph Hellwig @ 2026-06-18 8:59 UTC (permalink / raw)
To: Zhang Yi
Cc: Pankaj Raghav (Samsung), Pankaj Raghav, linux-xfs, bfoster, lukas,
Darrick J . Wong, dgc, gost.dev, andres, kundan.kumar, cem,
linux-fsdevel, linux-api
In-Reply-To: <557b2e5c-7c65-48de-87a9-6fba21eca99f@huaweicloud.com>
On Thu, Jun 18, 2026 at 11:22:45AM +0800, Zhang Yi wrote:
> 1) if the two blocks straddling the boundaries have not yet been allocated,
> or allocated as unwritten, we should round outward the allocation range
> and zero out all allocated blocks, including those two boundary blocks.
> 2) if the blocks at the boundaries are already in the written state — which
> can occur when we call FALLOC_FL_WRITE_ZEROES within the file size. We
> should be careful here: we should only zero the ranges [offset, offset_ru)
> and [end_rd, end) for the boundary blocks, leaving the already-written
> portions of the boundary blocks intact.
>
> Thoughs?
Yes.
> Regarding the second point, the current ext4 implementation has an issue —
> it zeroes out the entire boundary blocks. I overlooked this previously, and
> I appreciate you pointing it out.
Which means we're missing test coverage for this as well..
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Christoph Hellwig @ 2026-06-18 9:00 UTC (permalink / raw)
To: Pankaj Raghav (Samsung)
Cc: Pankaj Raghav, linux-xfs, bfoster, lukas, Darrick J . Wong, dgc,
gost.dev, andres, kundan.kumar, cem, Zhang Yi, linux-fsdevel,
linux-api
In-Reply-To: <kn5dyqdxmsydibpfcurgpom5vwqtwinrz27oenh4pekks6ybdj@wyi4zkh7mogy>
On Wed, Jun 17, 2026 at 11:44:47AM +0200, Pankaj Raghav (Samsung) wrote:
> > Maybe we also want xfstests that try unaligned FALLOC_FL_WRITE_ZEROES
> > and make sure no existing data before the range is lost and the
> > entire range is zeroed?
> >
>
> I added FALLOC_FL_WRITE_ZEROES support to ltp (both fsx and fsstress).
> For example, generic/363 tests for unaligned writes and checks for any
> stale data. By default, I think we do unaligned reads, writes and
> truncate in fsx.
But I guess not unaligned FALLOC_FL_WRITE_ZEROES?
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Pankaj Raghav (Samsung) @ 2026-06-18 9:28 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Pankaj Raghav, linux-xfs, bfoster, lukas, Darrick J . Wong, dgc,
gost.dev, andres, kundan.kumar, cem, Zhang Yi, linux-fsdevel,
linux-api
In-Reply-To: <ajOzoBt_peOCtNUm@infradead.org>
On Thu, Jun 18, 2026 at 02:00:16AM -0700, Christoph Hellwig wrote:
> On Wed, Jun 17, 2026 at 11:44:47AM +0200, Pankaj Raghav (Samsung) wrote:
> > > Maybe we also want xfstests that try unaligned FALLOC_FL_WRITE_ZEROES
> > > and make sure no existing data before the range is lost and the
> > > entire range is zeroed?
> > >
> >
> > I added FALLOC_FL_WRITE_ZEROES support to ltp (both fsx and fsstress).
> > For example, generic/363 tests for unaligned writes and checks for any
> > stale data. By default, I think we do unaligned reads, writes and
> > truncate in fsx.
>
> But I guess not unaligned FALLOC_FL_WRITE_ZEROES?
-r readbdy: 4096 would make reads page aligned (default 1)
-t truncbdy: 4096 would make truncates page aligned (default 1)
-w writebdy: 4096 would make writes page aligned (default 1)
FALLOC_FL_WRITE_ZEROES comes under truncate. So I would assume we also
do that. That is how I also found the issue with offset > EOF. I will
take a look or else, I will add a test case to test this condition!
Thanks.
--
Pankaj
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Christoph Hellwig @ 2026-06-18 9:36 UTC (permalink / raw)
To: Pankaj Raghav (Samsung)
Cc: Christoph Hellwig, Pankaj Raghav, linux-xfs, bfoster, lukas,
Darrick J . Wong, dgc, gost.dev, andres, kundan.kumar, cem,
Zhang Yi, linux-fsdevel, linux-api
In-Reply-To: <au3yznolpebvd5vphmzv73fzosdy7bxrb45kv56n734jnwwj3l@43d7sqlef27k>
On Thu, Jun 18, 2026 at 11:28:15AM +0200, Pankaj Raghav (Samsung) wrote:
> > But I guess not unaligned FALLOC_FL_WRITE_ZEROES?
>
> -r readbdy: 4096 would make reads page aligned (default 1)
> -t truncbdy: 4096 would make truncates page aligned (default 1)
> -w writebdy: 4096 would make writes page aligned (default 1)
>
> FALLOC_FL_WRITE_ZEROES comes under truncate. So I would assume we also
> do that. That is how I also found the issue with offset > EOF. I will
> take a look or else, I will add a test case to test this condition!
A targeted test using xfs_io that does FALLOC_FL_WRITE_ZEROES on an
unaligned range and then checks that the data around it is preserved
while the unaligned data in the range is zeroed would also be useful.
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Zhang Yi @ 2026-06-18 10:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Pankaj Raghav (Samsung), Pankaj Raghav, linux-xfs, bfoster, lukas,
Darrick J . Wong, dgc, gost.dev, andres, kundan.kumar, cem,
linux-fsdevel, linux-api
In-Reply-To: <ajOzZv7407w_hodk@infradead.org>
On 6/18/2026 4:59 PM, Christoph Hellwig wrote:
> On Thu, Jun 18, 2026 at 11:22:45AM +0800, Zhang Yi wrote:
>> 1) if the two blocks straddling the boundaries have not yet been allocated,
>> or allocated as unwritten, we should round outward the allocation range
>> and zero out all allocated blocks, including those two boundary blocks.
>> 2) if the blocks at the boundaries are already in the written state — which
>> can occur when we call FALLOC_FL_WRITE_ZEROES within the file size. We
>> should be careful here: we should only zero the ranges [offset, offset_ru)
>> and [end_rd, end) for the boundary blocks, leaving the already-written
>> portions of the boundary blocks intact.
>>
>> Thoughs?
>
> Yes.
>
>> Regarding the second point, the current ext4 implementation has an issue —
>> it zeroes out the entire boundary blocks. I overlooked this previously, and
>> I appreciate you pointing it out.
>
> Which means we're missing test coverage for this as well..
>
Ha, I just re-checked the ext4 implementation and found that scenario 2 is
actually fine, Sorry I misread the code earlier. Fortunately, no data
corruption occurred. :-)
The real issue is in scenario 1, where the boundary blocks are not correctly
converted to written-type extents.
As for testing the unaligned case, I also agree that we should explicitly add
a dedicated test for it. Relying on existing fsstress and fsx is not reliable
enough in this regard.
Thanks,
Yi.
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Pankaj Raghav (Samsung) @ 2026-06-18 13:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Pankaj Raghav, linux-xfs, bfoster, lukas, Darrick J . Wong, dgc,
gost.dev, andres, kundan.kumar, cem, Zhang Yi, linux-fsdevel,
linux-api
In-Reply-To: <ajO8AHsMFolUQLra@infradead.org>
On Thu, Jun 18, 2026 at 02:36:00AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 18, 2026 at 11:28:15AM +0200, Pankaj Raghav (Samsung) wrote:
> > > But I guess not unaligned FALLOC_FL_WRITE_ZEROES?
> >
> > -r readbdy: 4096 would make reads page aligned (default 1)
> > -t truncbdy: 4096 would make truncates page aligned (default 1)
> > -w writebdy: 4096 would make writes page aligned (default 1)
> >
> > FALLOC_FL_WRITE_ZEROES comes under truncate. So I would assume we also
> > do that. That is how I also found the issue with offset > EOF. I will
> > take a look or else, I will add a test case to test this condition!
>
> A targeted test using xfs_io that does FALLOC_FL_WRITE_ZEROES on an
> unaligned range and then checks that the data around it is preserved
> while the unaligned data in the range is zeroed would also be useful.
>
|----------|----------|----------|----------|----------|
^ ^ ^ ^ ^ ^
| | | | | |
| offset | | end |
| | | |
off_rd off_ru end_rd end_ru
I wrote a simple test case for unaligned FALLOC_FL_WRITE_ZEROES. The
existing code **does not** overwrite any user data. Here is why:
- xfs_free_file_space (punch hole) punches inward (offset_ru -> end_rd)
and zeroes out from (offset -> offset_ru) and (end_rd -> end) with
xfs_zero_range
- Luckily, even though we consider offset_rd to end_ru in
alloc_file_space, XFS_BMAPI_ZERO will skip zeroing already written
edge blocks and only offset_ru -> end_rd are zeroed using unmap zero range.
( (offset -> offset_ru) -> EXT_NORM, (offset_ru -> end_rd) -> HOLE,
(end_rd -> end) -> EXT_NORM)
I didn't think it through but the code still holds for these cases. This
might be the reason why fsx did not complain? I will also document this
in the patch.
But as you said, we need a xfstest for this boundary block checks in case
some behaviour changes in the future.
I guess apart from this, the only change is to address persisting data
when offset > old_size as sashiko reported.
Let me know what you think.
--
Pankaj
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Christoph Hellwig @ 2026-06-18 13:37 UTC (permalink / raw)
To: Pankaj Raghav (Samsung)
Cc: Christoph Hellwig, Pankaj Raghav, linux-xfs, bfoster, lukas,
Darrick J . Wong, dgc, gost.dev, andres, kundan.kumar, cem,
Zhang Yi, linux-fsdevel, linux-api
In-Reply-To: <xklmkbxoh7yfm5mkxxpp72wfifngzr2v4nfrn3lgzc57ep7nkj@louxc6z3gfmk>
On Thu, Jun 18, 2026 at 03:26:14PM +0200, Pankaj Raghav (Samsung) wrote:
> existing code **does not** overwrite any user data. Here is why:
>
> - xfs_free_file_space (punch hole) punches inward (offset_ru -> end_rd)
> and zeroes out from (offset -> offset_ru) and (end_rd -> end) with
> xfs_zero_range
Ah, right.
> - Luckily, even though we consider offset_rd to end_ru in
> alloc_file_space, XFS_BMAPI_ZERO will skip zeroing already written
> edge blocks and only offset_ru -> end_rd are zeroed using unmap zero range.
> ( (offset -> offset_ru) -> EXT_NORM, (offset_ru -> end_rd) -> HOLE,
> (end_rd -> end) -> EXT_NORM)
Oh. So this was lucky because of the corner cases. I still think doing
the proper alignment in the higher level code and only calling down for
the area that we really want to zero would be benefitial here, if only
to make the code easier to follow.
^ permalink raw reply
* Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES
From: Pankaj Raghav (Samsung) @ 2026-06-18 13:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Pankaj Raghav, linux-xfs, bfoster, lukas, Darrick J . Wong, dgc,
gost.dev, andres, kundan.kumar, cem, Zhang Yi, linux-fsdevel,
linux-api
In-Reply-To: <ajP0sno47hihsCCo@infradead.org>
On Thu, Jun 18, 2026 at 06:37:54AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 18, 2026 at 03:26:14PM +0200, Pankaj Raghav (Samsung) wrote:
> > existing code **does not** overwrite any user data. Here is why:
> >
> > - xfs_free_file_space (punch hole) punches inward (offset_ru -> end_rd)
> > and zeroes out from (offset -> offset_ru) and (end_rd -> end) with
> > xfs_zero_range
>
> Ah, right.
>
> > - Luckily, even though we consider offset_rd to end_ru in
> > alloc_file_space, XFS_BMAPI_ZERO will skip zeroing already written
> > edge blocks and only offset_ru -> end_rd are zeroed using unmap zero range.
> > ( (offset -> offset_ru) -> EXT_NORM, (offset_ru -> end_rd) -> HOLE,
> > (end_rd -> end) -> EXT_NORM)
>
> Oh. So this was lucky because of the corner cases. I still think doing
> the proper alignment in the higher level code and only calling down for
> the area that we really want to zero would be benefitial here, if only
> to make the code easier to follow.
I agree. I will do the changes and document some of the nuances in the
code.
Thanks!
--
Pankaj
^ permalink raw reply
* Re: [PATCH 1/2] fuse: allow FUSE_SYNCFS for privileged userspace servers
From: Jimmy Zuber @ 2026-06-19 16:33 UTC (permalink / raw)
To: miklos
Cc: fuse-devel, jamz, linux-api, linux-fsdevel, linux-kernel,
linux-kselftest, shuah
In-Reply-To: <CAJfpeguaa4U6Tsxh5opeaLeYQQxP6MQsRMu_JATJwwgj=OBt3Q@mail.gmail.com>
On Mon, 16 Jun 2026, Miklos Szeredi <miklos@szeredi.hu> wrote:
> Sounds really easy to trick: start the server in the initial user ns,
> then clone the mounter with a new user/mount namespace. The
> init_user_ns test will pass happily, since the server is running in
> the initial namespace.
Ah, the intention was to limit sync to sufficiently privileged FUSE
setups. I missed that the initial user namespace is not equivalent to
elevated permissions. I am thinking instead it would make sense to
assert that the opener of /dev/fuse has CAP_SYS_ADMIN in the initial
user namespace. They could then hand off the fd to a less privileged
server, but that is the prerogative of that privileged user, so I think
it satisfies the spirit of the DoS prevention requirement.
I will follow up shortly with a new version.
Thank you!
Jimmy
^ permalink raw reply
* [PATCH v2 0/2] fuse: allow FUSE_SYNCFS for privileged userspace servers
From: Jimmy Zuber @ 2026-06-19 17:02 UTC (permalink / raw)
To: Miklos Szeredi
Cc: fuse-devel, linux-fsdevel, linux-api, linux-kernel, Shuah Khan,
linux-kselftest
In-Reply-To: <20260616151909.916667-1-jamz@amazon.com>
FUSE_SYNCFS (propagating syncfs()/sync() to the server) is currently
enabled only for virtiofs and fuseblk, since an untrusted server can stall
sync(). Any FUSE filesystem may buffer data in the server that ought to
reach storage on sync(); the only thing that should gate it is whether the
/dev/fuse opener is sufficiently privileged to be trusted to block sync.
This series lets a plain /dev/fuse server opt in via a new FUSE_HAS_SYNCFS
INIT flag, honored only when the server opened /dev/fuse with CAP_SYS_ADMIN
privilege in the initial user namespace -- checked with file_ns_capable() at
mount time.
Patch 1: the kernel change (UAPI flag + privilege gating).
Patch 2: a selftest that speaks the raw FUSE protocol over /dev/fuse, so
it can withhold the flag and directly observe whether the
FUSE_SYNCFS opcode is forwarded.
A matching libfuse change (FUSE_CAP_SYNCFS negotiation) will be sent to the
libfuse project once the UAPI flag here is settled.
Changes since v1 [1]:
- Gate on the privilege of the opener (CAP_SYS_ADMIN in init_user_ns at
/dev/fuse open time, via file_ns_capable()) rather than on the mount's
user namespace. Miklos pointed out that the v1 check
(fc->user_ns == &init_user_ns) tested a property of the mount, not of
the server that actually services -- and can stall -- the connection.
Being in the initial user namespace is not itself a privilege
(e.g. an ordinary sshfs mount qualifies). Checking the device opener's
capability closes that gap.
- Selftest: add a case covering exactly that distinction -- a server
in the initial user namespace that opened /dev/fuse without
CAP_SYS_ADMIN -- which v1 would have wrongly allowed.
Testing: built and booted under QEMU. The selftest passes all
four cases, including the new case above (verified that the kernel withholds
FUSE_SYNCFS while it would have been granted under the v1 check).
[1] https://lore.kernel.org/20260616151909.916667-1-jamz@amazon.com
Jimmy Zuber (2):
fuse: allow FUSE_SYNCFS for privileged userspace servers
selftests/fuse: add test for FUSE_HAS_SYNCFS privilege gating
fs/fuse/fuse_i.h | 9 +
fs/fuse/inode.c | 28 ++
include/uapi/linux/fuse.h | 12 +-
.../selftests/filesystems/fuse/.gitignore | 1 +
.../selftests/filesystems/fuse/Makefile | 2 +-
.../selftests/filesystems/fuse/test_syncfs.c | 370 ++++++++++++++++++
6 files changed, 420 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/filesystems/fuse/test_syncfs.c
base-commit: 7d87a5a284bb34edb3f4e7e312ef403b3385a7b7
--
2.50.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox