kernel/linux.git/fs/libfs.c, branch v7.1-rc5

Merge tag 'vfs-7.1-rc1.bh.metadata' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

2026-04-13T19:46:42+00:00

Pull vfs buffer_head updates from Christian Brauner: "This cleans up the mess that has accumulated over the years in metadata buffer_head tracking for inodes. It moves the tracking into dedicated structure in filesystem-private part of the inode (so that we don't use private_list, private_data, and private_lock in struct address_space), and also moves couple other users of private_data and private_list so these are removed from struct address_space saving 3 longs in struct inode for 99% of inodes" * tag 'vfs-7.1-rc1.bh.metadata' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (42 commits) fs: Drop i_private_list from address_space fs: Drop mapping_metadata_bhs from address space ext4: Track metadata bhs in fs-private inode part minix: Track metadata bhs in fs-private inode part udf: Track metadata bhs in fs-private inode part fat: Track metadata bhs in fs-private inode part bfs: Track metadata bhs in fs-private inode part affs: Track metadata bhs in fs-private inode part ext2: Track metadata bhs in fs-private inode part fs: Provide functions for handling mapping_metadata_bhs directly fs: Switch inode_has_buffers() to take mapping_metadata_bhs fs: Make bhs point to mapping_metadata_bhs fs: Move metadata bhs tracking to a separate struct fs: Fold fsync_buffers_list() into sync_mapping_buffers() fs: Drop osync_buffers_list() kvm: Use private inode list instead of i_private_list fs: Remove i_private_data aio: Stop using i_private_data and i_private_lock hugetlbfs: Stop using i_private_data fs: Stop using i_private_data for metadata bh tracking ...

fs: Rename generic_file_fsync() to simple_fsync()

2026-03-26T14:03:28+00:00

The implementation is now really basic so rename generic_file_fsync() simple_fsync() and __generic_file_fsync() to simple_fsync_noflush(). Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260326095354.16340-56-jack@suse.cz Signed-off-by: Christian Brauner

fs: Drop sync_mapping_buffers() from __generic_file_fsync()

2026-03-26T14:03:28+00:00

No filesystem calling __generic_file_fsync() uses metadata bh tracking. Drop sync_mapping_buffers() call from __generic_file_fsync() as it's pointless now which untangles buffer head handling from fs/libfs.c. Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260326095354.16340-55-jack@suse.cz Signed-off-by: Christian Brauner

fs: Remove inode lock from __generic_file_fsync()

2026-03-26T14:03:27+00:00

Inode lock in __generic_file_fsync() protects sync_mapping_buffers() and sync_inode_metadata() calls. Neither sync_mapping_buffers() nor sync_inode_metadata() themselves need the protection by inode_lock and both metadata buffer head writeback and inode writeback can happen without inode lock (either in case of background writeback or sync(2) calls). The only protection inode_lock can possibly provide is that write(2) or other inode modifying calls cannot happen in the middle of bh+inode writeout and thus result in writeout of inconsistent metadata. However if writes and fsyncs race, background writeback can submit inconsistent metadata just after fsync completed even with inode_lock protecting fsync so this seems moot as well. So let's remove the apparently pointless inode_lock protection. Signed-off-by: Jan Kara Link: https://patch.msgid.link/20260326095354.16340-50-jack@suse.cz Signed-off-by: Christian Brauner

libfs: change simple_done_creating() to use end_creating()

2026-03-06T09:24:11+00:00

simple_done_creating() and end_creating() are identical. So change the former to use the latter. This further centralises unlocking of directories. Signed-off-by: NeilBrown Link: https://patch.msgid.link/20260224222542.3458677-5-neilb@ownmail.net Reviewed-by: Jeff Layton Signed-off-by: Christian Brauner

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

fs: remove simple_nosetlease()

2026-01-12T09:55:48+00:00

Setting ->setlease() to a NULL pointer now has the same effect as setting it to simple_nosetlease(). Remove all of the setlease file_operations that are set to simple_nosetlease, and the function itself. Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260108-setlease-6-20-v1-24-ea4dec9b67fa@kernel.org Acked-by: Al Viro Acked-by: Christoph Hellwig Reviewed-by: Jan Kara Signed-off-by: Christian Brauner

tmpfs: add setlease file operation

2026-01-12T09:55:47+00:00

Add the setlease file_operation pointing to generic_setlease to the tmpfs file_operations structures. A future patch will change the default behavior to reject lease attempts with -EINVAL when there is no setlease file operation defined. Add generic_setlease to retain the ability to set leases on this filesystem. Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260108-setlease-6-20-v1-19-ea4dec9b67fa@kernel.org Acked-by: Al Viro Acked-by: Christoph Hellwig Reviewed-by: Jan Kara Signed-off-by: Christian Brauner

shmem: fix recovery on rename failures

2025-12-16T05:57:29+00:00

maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange(). Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won't fail past the successful call of shmem_whiteout(). Not hard to fix, fortunately - mtree_store() can't fail if the index we are trying to store into is already present in the tree as a singleton. For simple_offset_rename_exchange() that's enough - we just need to be careful about the order of operations. For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations. That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we'd need to deal with the possibility of failure after successful shmem_whiteout(). Fixes: a2e459555c5f ("shmem: stable directory offsets") Reviewed-by: Christian Brauner Reviewed-by: Chuck Lever Signed-off-by: Al Viro