kernel/git/next/linux-next.git/include/uapi, branch fs-next

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

2026-09-11T11:34:33+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-11T11:34:18+00:00

btrfs: fix typos and repeated words in comments

2026-09-07T12:36:34+00:00

Fix misspellings and repeated words in comments, found with scripts/checkpatch.pl and codespell. Only touches comments, no code changes. Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: qgroup: use atomic operations for btrfs_fs_info::qgroup_flags

2026-09-07T09:25:16+00:00

Currently we define btrfs_fs_info::qgroup_flags as u64, to match the on-disk qgroup status item's flag. But for now we have only 4 bits utilized for that flag, and since it's u64 we have no way to properly use the existing atomic bit operations (requires an unsigned long pointer). This results in a lot of non-atomic operations inside qgroup code. Some maybe fine as other locks are involved, but still it's not a good practice. Remove those non-atomic operations by: - Re-define btrfs_fs_info::qgroup_flags as unsigned long - Define BTRFS_QGROUP_STATUS_BIT_* and BTRFS_QGROUP_RUNTIME_BIT_* Instead of the old value define the bit number. - Use set_bit()/clear_bit()/test_bit() to replace open-coded bit operations - Add one extra check at qgroup status item read time To make sure the on-disk flag is still inside ULONG_MAX. Otherwise reject the status item and disable qgroup. - Get rid of unnecessary spinlock when checking a single bit Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba

Merge tag 'integrity-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity

2026-09-05T02:36:11+00:00

Pull IMA fixes from Mimi Zohar: - Instantiating the ima_file_truncate and ima_path_truncate LSM hooks resulted in configfs locking issues. configfs files should not be measured, appraised, or audited in the first place, so the builtin policies are updated to exclude them. - IMA audit messages include the filename, which could result in a page fault when the filename doesn't exist - Un-hide the IMA_MEASURE_PCR_IDX Kconfig prompt * tag 'integrity-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity: ima: allow users to specify the pcr index with IMA_MEASURE_PCR_IDX ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() ima: don't measure/appraise files on configfs configfs: move CONFIGFS_MAGIC definition to magic.h

drm/amdgpu/userq: fix struct drm_amdgpu_info_device padding for 32bit compile

2026-09-02T21:02:23+00:00

need to pad before __u64 tcc_disabled_mask variable. This patch fixes 64bit Kernel + 32 bit mesa combination. But at the same time it will break 32bit Kernel(using this patch) + older 32bit mesa(not using this patch). This issue was discussd with alexander.deucher@amd.com, christian.koenig@amd.com and pierre-eric.pelloux-prayer@amd.com. Currently today 32 bit kernel + 32 bit userspace and 64 bit kernel and 64 bit userspace work. Mixed 64 bit kernel and 32 bit userspace is currently broken. Since 32 bit kernel and userspace is probably pretty rare these days and the data affected by this is not critical, Hence we can go ahead with this patch. Fixes: cf21e76a6005 ("drm/amdgpu: return tcc_disabled_mask to userspace") Signed-off-by: Yogesh Mohan Marimuthu Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 497b5090f2857ef8ad9a162aa31ada0de5814663)

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

configfs: move CONFIGFS_MAGIC definition to magic.h

2026-09-02T02:28:55+00:00

IMA shouldn't measure or appraise configfs, but currently does because it's missing from the default exclusion policies. Move CONFIGFS_MAGIC to magic.h to expose the file system's magic to IMA, as well as other userland applications. Suggested-by: Mimi Zohar Signed-off-by: Frederick Lawler Acked-by: Breno Leitao Signed-off-by: Mimi Zohar

coredump: select memory types to include

2026-08-31T10:07:30+00:00

Currently /proc//coredump_filter determines what types of memory are included in a coredump produced by . This is fairly static. The coredump server has no easy way to configure what memory to dump even though it can figure out all the necessary details to make an informed decision. Add a new COREDUMP_MEMORY_TYPES feature bit. If the coredump server raises it the kernel will dump memory types raised in the coredump_ack->memory_types member. Zero is valid and causes the creation of a coredump that just includes the program headers and notes but no memory apart from the mappings that are always dumped. struct coredump_req gains @memory_types which is set to the default memory types that are included in the coredump. This can be overridden by raising bits in coredump_ack->memory_types. It also gains @memory_types_mask which contains a bitmask of all memory types the kernel knows about. A coredump server may only raise bits in coredump_ack->memory_types that are raised in coredump_req->memory_types_mask. struct coredump_ack grows too. If COREDUMP_MEMORY_TYPES is raised in @mask the kernel dumps the memory types set in the @memory_types mask. Zero is valid and dumps no memory apart from the mappings that are always dumped. A coredump server wanting to add or drop memory types instead of outright replacing it should simply copy coredump_req->memory_types and then mask off or raise types as needed. @memory_types must be zero if COREDUMP_MEMORY_TYPES isn't raised. COREDUMP_MEMORY_TYPES requires COREDUMP_KERNEL and an ack of at least COREDUMP_ACK_SIZE_VER1 bytes. Link: https://patch.msgid.link/20260821-work-coredump-filter-v1-1-91f9a73ef03e@kernel.org Signed-off-by: Christian Brauner (Amutable)

coredump: add COREDUMP_SPARSE to the coredump socket protocol

2026-08-31T09:06:10+00:00

A coredump with a lot of unpopulated mappings sends useless amounts of zero data to userspace. This is nonsensical. While __dump_skip() can seek over them when the target is a regular file a socket cannot do this. COREDUMP_RECORDS put the zeroes in records but it didn't get rid of them. Add a COREDUMP_SPARSE feature bit and a COREDUMP_RECORD_ZERO record type. A zero record is a bare header that tells userspace how many zero bytes were skipped. So a hole crosses the socket as one header no matter how long it is. The coredump server can recreate this sparsely. Zero records only exist inside a record stream. COREDUMP_SPARSE requires COREDUMP_RECORDS. Link: https://patch.msgid.link/20260820-work-coredump-sparse-v2-14-ba32dd718c51@kernel.org Signed-off-by: Christian Brauner (Amutable)