kernel/git/next/linux-next.git/fs/fuse, branch master

Merge branch 'vfs.all' of https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git

2026-09-10T11:38:10+00:00

# Conflicts: # tools/testing/selftests/Makefile

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git

2026-09-10T11:37:55+00:00

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

fuse: fall back to copy_splice_read() on FOPEN_DIRECT_IO

2026-09-02T07:36:08+00:00

Yafang Shao reports: "After upgrading the kernel from 6.1.y to 6.18.y on production servers, some containers failed to read lxcfs data. The root cause is that our lxcfs is still at the old v3.0.4, which does not include commit 25982f5 ("Set the file size to 4k") [0]. Between 6.1.y and 6.18.y, the FUSE splice_read path was converted from generic_file_splice_read() to filemap_splice_read() by commit 2cb1e08985e3 ("splice: Use filemap_splice_read() instead of generic_file_splice_read()"). Unlike generic_file_splice_read(), filemap_splice_read() strictly checks i_size and refuses to read from zero-size files, which breaks virtual FUSE filesystems like the old lxcfs." Fix by using copy_splice_read() for the FOPEN_DIRECT_IO case, just like the VFS does for DAX and O_DIRECT files. Reported-by: Yafang Shao Closes: https://lore.kernel.org/all/20260706025705.58301-1-laoar.shao@gmail.com/ Reported-by: Changyuan Lyu Closes: https://lore.kernel.org/all/20260901213412.1763253-1-changyuanl@google.com/ Fixes: 2cb1e08985e3 ("splice: Use filemap_splice_read() instead of generic_file_splice_read()") Tested-and-acked-by: Yafang Shao Signed-off-by: Miklos Szeredi

fuse: don't bump attr_version for async direct read completion

2026-09-02T07:36:08+00:00

The attr_version counter should only be incremented when cached attributes are actually modified (as documented in commit 1fb69e781729 ("fuse: fix race between getattr and write")). Async direct reads do not modify any cached inode attributes (size, mtime, ctime), so bumping attr_version in fuse_aio_complete() for reads is incorrect. This unconditional bump causes a livelock when auto_inval_data is enabled together with writeback_cache: fuse_cache_read_iter() issues a FUSE_GETATTR before every read, but by the time the response arrives, an async DIO read completion has already incremented fi->attr_version past the snapshot taken before the request. The GETATTR result is then discarded (attr_version race), fi->i_time is never refreshed, and every subsequent read triggers yet another GETATTR -- creating an infinite loop of useless round-trips. Fix this by only bumping attr_version for write completions, consistent with the synchronous DIO write path (fuse_write_update_attr) and the cached write path. Fixes: 01e9d11a3e79 ("fuse: add support of async IO") Reviewed-by: Horst Birthelmer Signed-off-by: Jingbo Xu Signed-off-by: Miklos Szeredi

fuse: mark DAX VMA page protections as decrypted

2026-09-02T07:36:08+00:00

In confidential computing guest environments (such as AMD SEV-SNP or Intel TDX), direct memory access (DAX) mappings between the guest kernel and host-backed FUSE/virtiofs shared memory regions must be accessed using shared (decrypted) page protections. Modify fuse_dax_mmap() to apply pgprot_decrypted() to vma->vm_page_prot when establishing FUSE DAX memory mappings. This ensures guest page table entries for shared DAX buffers are explicitly marked as decrypted, preventing memory encryption faults when accessing host-shared DAX memory. Signed-off-by: Punit Salian Acked-by: Pankaj Gupta Signed-off-by: Miklos Szeredi

fuse: don't fill in.h.pid in case args->nocreds is set

2026-09-02T07:36:08+00:00

Commit 794e811d1443 ("fuse: split out filesystem part of request sending") alters the pid sent on force && nocreds requests. Previously these allocated a zeroed request and skipped fuse_force_creds(), so they went out with in.h.pid == 0. In fuse_fill_creds(), args->pid is now set before the nocreds early return, and fuse_args_to_req() copies it unconditionally - so writeback, release, and DESTROY requests now report the triggering (often kernel-worker) pid instead of 0. Move the nocreds check above setting args->pid. Also remove the WARN_ON(!args->nocreds) from the !args->force branch, since it's obviously not going to be triggered. Reported-by: David CARLIER Closes: https://lore.kernel.org/all/CA+XhMqye_NBihcadRTU=w4xAfrdY9rsMB3oHF5+bwHukkjHMoQ@mail.gmail.com/ Fixes: 794e811d1443 ("fuse: split out filesystem part of request sending") Signed-off-by: Miklos Szeredi

fuse: allow FUSE_SYNCFS for privileged userspace servers

2026-09-02T07:36:07+00:00

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 trust property that virtiofs and fuseblk satisfy is that neither can be mounted without CAP_SYS_ADMIN in the initial user namespace (neither sets FS_USERNS_MOUNT). A plain fuse mount does set FS_USERNS_MOUNT, so its existence guarantees no such privilege; the privilege has to be checked rather than assumed. Add an opt-in INIT flag, FUSE_HAS_SYNCFS, and honor it only when the server opened /dev/fuse with CAP_SYS_ADMIN in the initial user namespace, recorded at mount time via file_ns_capable(). This is the same privilege that mounting virtiofs or fuseblk requires, applied to the process that actually services (and could stall) the connection. Checking the device opener's capability -- rather than the mount's user namespace -- avoids treating an unprivileged server that merely happens to run in the initial user namespace (e.g. a normal sshfs mount) as trusted. The flag is only advertised to servers that pass this check, 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 Assisted-by: Claude:claude-opus-4-8 [Claude-Code] Signed-off-by: Miklos Szeredi

fuse: ioctl: remove unnecessary comparison in fuse_setup_measure_verity()

2026-09-02T07:36:07+00:00

Clang reports a warning in fuse_setup_measure_verity() when comparing the __u16 digest_size with SIZE_MAX minus the size of struct fsverity_digest: warning: result of comparison of constant 18446744073709551611 with expression of type '__u16' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare] This was first observed while building an x86_64 kernel with Clang and W=1. Since -Werror was enabled in my build, the warning caused the build to fail. The same warning can also be reproduced with the same build options using tinyconfig with FUSE enabled, so this is not specific to the kernel configuration used in the original build. The comparison is between the 16-bit digest_size and a size_t-sized constant. Since this comparison cannot be true, remove it. Signed-off-by: Ali Nasrollahi Signed-off-by: Miklos Szeredi

vfs: move O_IS_MKDIR check from lookup_open() into individual filesystems

2026-08-31T08:32:26+00:00

Individual filesystems that implement ->atomic_open() need to get the chance to implement O_CREAT|O_DIRECTORY or not, rather than decide this at the VFS level in lookup_open(). Signed-off-by: Jori Koolstra Link: https://patch.msgid.link/20260823160706.358293-8-jkoolstra@xs4all.nl Signed-off-by: Christian Brauner (Amutable)