Test misc-next (regular, SELF) by kdave · Pull Request #1629 · btrfs/linux

kdave · 2026-04-17T00:37:46Z

No description provided.

The correct path of the "read_policy" module parameter should be /sys/module/btrfs/parameters/read_policy. Fix it. Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

Joining/starting a log transaction tracks if we ever had more than one task concurrently logging by setting the flag BTRFS_ROOT_MULTI_LOG_TASKS in the respective root. Once set, this flag remains for the rest of the lifetime of the transaction, only cleared when we don't have a log root and need to create a new one (transaction commits drop log roots). During log commit, if we are not on a ssd mount (or use the -o nossd mount option) and the BTRFS_ROOT_MULTI_LOG_TASKS flag is set, we sleep for one jiffy with the excuse to allow future log writers to join and log inodes and then commit a larger log transaction to reduce overall IO. However this is extremely inefficient because: 1) If at some point we had multiple tasks logging concurrently but now we have only one task at a time, we force it to wait for 1 jiffy; 2) One jiffy can vary between 1ms to 10ms, depending on the kernel config option CONFIG_HZ, which by default has a value of 250HZ and that corresponds to 4ms - that is a lot. This massively reduces the latency of fsyncs for non-ssd mounts, even on consumer grade spinning disks. Remove this mechanism to track if we have (or ever had) multiple tasks logging and wait for 1 jiffy. The following fio test was used to benchmark: $ cat fio-buffered-fsync.sh DEV=/dev/sdj MNT=/mnt/sdj MOUNT_OPTIONS="" MKFS_OPTIONS="" if [ $# -ne 6 ]; then echo "Use $0 NUM_JOBS FILE_SIZE IO_SIZE FSYNC_FREQ BLOCK_SIZE [write|randwrite]" exit 1 fi NUM_JOBS=$1 FILE_SIZE=$2 IO_SIZE=$3 FSYNC_FREQ=$4 BLOCK_SIZE=$5 WRITE_MODE=$6 if [ "$WRITE_MODE" != "write" ] && [ "$WRITE_MODE" != "randwrite" ]; then echo "Invalid WRITE_MODE, must be 'write' or 'randwrite'" exit 1 fi cat <<EOF > /tmp/fio-job.ini [writers] rw=$WRITE_MODE fsync=$FSYNC_FREQ fallocate=none group_reporting=1 direct=0 bs=$BLOCK_SIZE ioengine=psync filesize=$FILE_SIZE io_size=$IO_SIZE directory=$MNT numjobs=$NUM_JOBS EOF echo echo "Using config:" echo cat /tmp/fio-job.ini echo umount $MNT &> /dev/null mkfs.btrfs -f $MKFS_OPTIONS $DEV mount $MOUNT_OPTIONS $DEV $MNT fio /tmp/fio-job.ini umount $MNT Running the script as: ./fio-buffered-fsync.sh 8 64M 64M 1 4K randwrite Before patch: WRITE: bw=2647KiB/s (2711kB/s), 2647KiB/s-2647KiB/s (2711kB/s-2711kB/s), io=512MiB (537MB), run=198055-198055msec After patch: WRITE: bw=14.9MiB/s (15.6MB/s), 14.9MiB/s-14.9MiB/s (15.6MB/s-15.6MB/s), io=512MiB (537MB), run=34471-34471msec That's about 5.7 times faster. Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

We have the log batch counter defined per root which is now useless after the previous patch (titled: "btrfs: stop sleeping for one jiffy in non-ssd mounts during log commit"). The counter is incremented early in the fsync path, before and after flushing dellaloc and waiting for writeback, and then the counter is read during the log sync path. The goal was to wait for tasks that are about to join a log transaction, so that we could reduce the amount of IO and log syncing (flush all log tree extent buffers and write super blocks), but that mechanism does not work since if there are currently no log writers, btrfs_sync_log() does not unlock the root's log_mutex, so no new log writers can join the log transaction. Having concurrent fsync tasks increasing the log_batch counter only makes us loop unnecessarily in btrfs_sync_log() - that is always true since the previous patch mentioned above and was true before that patch only when not using the "-o ssd" mount option (which is activated by default if the filesystem does not have rotational devices). So remove the log batch counter. No performance changes were observed after removing it. Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

Instead of having every caller check for root->log_commit[] being non-zero and then call wait_log_commit(), move the check into wait_log_commit() and have the callers call it unconditionally. Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

We check for the exit condition after we add ourselves to the wait queue and before we unlock the root's log_mutex, sleep and lock again log_mutex. This is not incorrect, but it's not optimal since in the first iteration this is pointless because we already know that root->log_commit[index] is not zero, so we should check the exit condition only after unlocking log_mutex, sleeping, waking up and locking again the log_mutex. So move the check for the exit condition to bottom of the loop, after we were woken and locked log_mutex again. Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

We are using atomic types for the log_commit array of struct btrfs_root but all we need is simple booleans. The log_commit array elements are always protected by the root's log_mutex, both for writes and reads, so we can use a simple boolean. The use of atomics if from the very early days of the log tree code where the access to the fields was not protected by any lock. So switch to simple booleans, which results in cheaper code and slightly reduces the object size too. Reviewed-by: Boris Burkov <boris@bur.io> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

[BUG] For a crafted btrfs image, the following KASAN can be triggered when reading an inline lzo compressed file extent: BUG: KASAN: slab-out-of-bounds in lzo_decompress+0x57d/0x700 Read of size 4 at addr ffff888006f2e644 by task btrfs_lzo_inlin/77 Call Trace: <TASK> dump_stack_lvl+0x5b/0x70 print_report+0xd1/0x610 kasan_report+0xe0/0x110 __asan_report_load_n_noabort+0x13/0x20 lzo_decompress+0x57d/0x700 btrfs_decompress+0x140/0x1c0 uncompress_inline+0x147/0x1b0 btrfs_get_extent+0xb23/0x10a0 btrfs_do_readpage.constprop.0+0x538/0x1ac0 btrfs_readahead+0x32f/0x5f0 read_pages+0x16f/0x850 page_cache_ra_unbounded+0x296/0x490 do_page_cache_ra+0xd9/0x130 page_cache_sync_ra+0x3ee/0x6f0 filemap_get_pages+0x306/0x15c0 filemap_read+0x329/0xd00 btrfs_file_read_iter+0x1f8/0x2b0 vfs_read+0x4ef/0x720 ksys_read+0xf8/0x1d0 __x64_sys_read+0x71/0xb0 x64_sys_call+0x1ab0/0x1b70 do_syscall_64+0x61/0x470 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> [CAUSE] For an inline lzo compressed file extent, there should always be one lzo header, recording the total length of the compressed data, followed by one segment header, recording the compressed lzo payload. But if a crafted inline lzo compressed file extent contains only an lzo header, without the segment header or payload, lzo_decompress() will still try to read the segment header, causing a read beyond the item boundary. Furthermore if the inline lzo compressed file extent is the first item of the leaf, it will be at the extent buffer boundary. The above out-of-boundary read will go beyond the extent buffer boundary, triggering the above KASAN report. [FIX] Validate the total length of the inlined lzo compressed file extent, to make sure there is at least one LZO header and one segment header, and a non-zero payload. Fixes: a6fa6fa ("btrfs: Add lzo compression support") Assisted-by: Codex:gpt-5.5 Signed-off-by: David Lee <david.lee@trailofbits.com> [ Rework the commit message to remove slop ] Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

Inside reflink.c we still have a lot of functions passing VFS inode pointers, then internally convert them into btrfs_inode pointers. For example, inside btrfs_clone(), we have 12 BTRFS_I() call sites, while only 3 callsites that really require a VFS inode pointer. Do the cleanup to convert the following functions to pass a btrfs_inode pointer instead of a vanilla inode pointer: - btrfs_clone() - btrfs_extent_same_range() - clone_finish_inode_update(). Which covers all ad-hoc BTRFS_I() call sites inside reflink.c. Reviewed-by: Daniel Vacek <neelx@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

… start btree_writepages() writes the btree inode's dirty metadata in ascending logical address order. On a zoned filesystem only one metadata and one system block group is active for writing at a time, and check_bg_is_active() (via btrfs_check_meta_write_pointer()) pivots the active block group as writeback moves from one block group to the next. If the active block group sits at a higher logical address than another block group that also holds dirty metadata, the ascending walk reaches the lower one first and, to write it, has to finish the active block group and activate the lower one. It cannot finish a block group that still has unsent IO, and during WB_SYNC_ALL && !for_sync (commit) writeback it deliberately refuses to wait for that IO under fs_info->zoned_meta_io_lock, as that can deadlock. The pivot thus cannot issue the submission itself either, so it gives up: btrfs_check_meta_write_pointer() returns -EAGAIN, which btrfs_write_and_wait_transaction() treats as fatal and aborts the transaction, forcing the filesystem read-only. This happens intermittently under metadata-heavy relocation (e.g. fstests btrfs/187). Flush the active metadata and system block groups at the start of btree_writepages(), under the fs_info->zoned_meta_io_lock it already holds, so they have no unsent IO left and the later pivot can finish them and make forward progress. Fixes: 13bb483 ("btrfs: zoned: activate metadata block group on write time") Assisted-by: LLM (debugging, commit message) Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>

On a zoned filesystem a freed tree block is not cleared but kept dirty and flagged EXTENT_BUFFER_ZONED_ZEROOUT, so a later writeback zeroes it out and advances the zone write pointer. A transaction abort turns the filesystem read-only before that writeback runs, so these buffers stay dirty and stranded ahead of the write pointer where btree_writepages() can no longer write them. They survive to the final iput() of the btree inode at unmount, which submits the write after the endio workqueues are gone, hanging unmount in folio_wait_writeback(). Clear the dirty state of such buffers when cleaning up the aborted transaction, where the buffer tree still references all of them. Assisted-by: LLM (debugging, commit message) Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>

On a zoned filesystem a freed tree block is kept dirty and flagged EXTENT_BUFFER_ZONED_ZEROOUT so a later writeback zeroes it out and advances the zone write pointer. Unsynced tree-log updates (e.g. from rename or link) leave such buffers behind when the log is freed at commit, and across log generations they can end up ahead of the write pointer behind a hole, so btree_writepages() can never write them. During normal operation the space is later reclaimed by a zone reset; at unmount it is not, and the buffers survive to the final iput() of the btree inode, which hangs in folio_wait_writeback() once the endio workqueues are stopped. They cannot be written back from where they are freed (free_log_tree(), inside the committing transaction) without deadlocking against that commit, and they are stale anyway, not referenced by the committed superblock. Drop their dirty state in close_ctree(), before btrfs_stop_all_workers(). Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>

On a zoned filesystem a freed-but-still-dirty tree block is written out as zeros (EXTENT_BUFFER_ZONED_ZEROOUT) only to keep the zone write pointer advancing. btree_csum_one_bio() implemented this by memzeroing the extent buffer's own folios before submission. That destroys the in-memory buffer while it may still be referenced. In particular btrfs_free_tree_block() can run on it afterwards and reads the header to add a delayed reference; once the header has been zeroed it frees bytenr 0 and corrupts the extent tree (the btrfs_header_bytenr(buf) != 0 ASSERT in btrfs_free_tree_block(), or an "unable to find ref" abort). It is flaky and reproduces under fsstress, e.g. generic/461 and generic/013. Write the zeros to disk from the shared zero page instead and leave the extent buffer content untouched, so any later reference - including the delayed reference from btrfs_free_tree_block() - still sees a valid header. end_bbio_meta_write() now clears writeback on the buffer's own folios, as the bio no longer carries them. Fixes: aa6313e ("btrfs: zoned: don't clear dirty flag of extent buffer") Assisted-by: LLM (debugging, commit message) Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>

Local fuzzing of 6.12.94 has found the following memory leak: Unreferenced object 0xffff888018050a80 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................ backtrace (crc a8a6fc29): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline] qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Unreferenced object 0xffff888018050a00 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................ 90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................ backtrace (crc cb5c9580): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114 extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline] __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086 set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821 qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by freeing an extent changeset before returning from btrfs_do_encoded_write(). Fixes: 7c0c726 ("btrfs: add BTRFS_IOC_ENCODED_WRITE") Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

@EnD

The @EnD parameter for all extent io tree helpers is inclusive, but the call site in extent_fiemap() is passing an exclusive end into btrfs_lock_extent(), which will step into the next block unexpectedly. Pass the inclusive end into btrfs_lock_extent() and btrfs_unlock_extent(). Fixes: ac3c0d3 ("btrfs: make fiemap more efficient and accurate reporting extent sharedness") Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

In btrfs_extent_same_range() and btrfs_clone_files(), the range passed into btrfs_lock_extent() is not aligned at its end, because we can reflink until the EOF, which may not be block aligned. Although this is not a big deal, for the sake of consistency, and to prepare for the upcoming stricter alignment check, pass an aligned range end to btrfs_lock_extent() and btrfs_unlock_extent(). Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

Extent maps have the extra validation since commit 3f255ec ("btrfs: introduce extra sanity checks for extent maps"), but extent states do not have a similar check. Introduce a basic alignment check for the following call sites, so that we can cover all extent states inserted into the tree: - insert_state_fast() - insert_state() - split_state() Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

The problem scenario: If we have a folio mmapped shared and then somebody does a dio read with that folio as the read destination, then it is possible that the dio will see a dirty destination page when it starts (and thus skip dirtying and just GUP pin it) but then while it is doing the read, btrfs finishes writing it back and by the endio, the folio is clean. In that case, the dio read must re-dirty the folio with aops->dirty_folio(): btrfs_check_read_bio() |- __iomap_dio_bio_end_io() from btrfs_bio_end_io() |- bio_check_pages_dirty() |- bio_dirty_fn() |- bio_release_pages(bio, true) |- __bio_release_pages(bio, mark_dirty == true) |- folio_lock() |- folio_mark_dirty() |- aops->dirty_folio() |- folio_unlock() A data block normally moves through writeback as follows: TASK folio_lock write clean -> dirty bit + delalloc folio_unlock WRITEBACK for-each-dirty-folio: folio_lock run_delalloc delalloc consumed -> dirty bit + OE submission dirty bit consumed -> writeback bit + OE folio_unlock ENDIO endio OE bytes accounted OE finish writeback -> clean; destroy OE Three critical invariants that this path maintains are: I1. Any dirty block is covered by delalloc xor an ordered extent I2. Any dirty block covered by an OE will be submitted into that OE I3. Any dirty block already submitted into an OE will not be submitted again into the same OE. These ensure that the block will be written exactly once. It is clear that not reserving delalloc for the re-dirty case violates I1. This situation, even without bs < folio_size, has long required btrfs to fixup such dirty pages during writeback with an asynchronous worker that is allowed to do this expensive work and writeback does not proceed for a folio while it is doing this work. Commit 247e743 ("Btrfs: Use async helpers to deal with pages that have been improperly dirtied") introduced the COW fixup to catch exactly this class at writeback, way back in 2008. Since then, there have been many advances to prevent most of the causes of such re-dirtying and we thought we could get away with removing the annoying cow-fixup in the hope of simplifying writeback for large folio support. Commit b2a9f21 ("btrfs: remove the COW fixup mechanism") Commit 4927b14 ("btrfs: remove folio ordered flag and subpage bitmap") Since it turns out this assumption was incorrect, as evidenced by the report and attendant reproducers, we must reintroduce the fixup concept. This is of course critically further complicated by bs < folio_size. In that case, rather than just a folio dirty bit, we have a bitmap for the dirty blocks in the folio. And the (also broken) invariant is: I4. folio dirty IFF at least one block bitmap dirty. The original report of a stall on a misinterpreted empty bitmap is exactly evidence of a violation of I4. It is exactly because of bs < folio_size we don't want to simply revert the removal patches. The original fixup was not properly bs < folio_size aware, which motivated removal in the first place. So we wish to build a bs < folio_size aware fixup. One other important detail from the old design, any normal write that happens after a re-dirty but before a fixup is racing with the cow fixup to do the delalloc reservation, therefore it must cancel the fixup state. If it arrives after the reservation exists, it will be a normal dirty overwrite. This critically informs the design in a pretty clear way. fixup requiring re-dirty has folio granularity, while cancellation has delalloc (block) granularity so while we only ever produce fixup in chunks of folios, we must be able to clear it in blocks. Therefore we must track the blocks needing fixup at block granularity. The obvious way to do this is with a new bitmap in btrfs_folio_state, but it is desirable to avoid that if possible. Unfortunately, I don't think it is possible and the reason is subtle and leans on a sort of extreme reproducer, but I think can be explained relatively succinctly. Consider a folio whose two halves will land in different ordered extents (can be accomplished with tricks using nodatasum) and a dio read is running with it as the shared mmap destination. 1. The front half: a. folio comes clean on a normal write b. dio read completes into the folio marking it fixup. c. a write comes for the previous folio for a range extending into this folio, this is a cancellation of the fixup which reserves space. d. writeback runs on the range *not* overlapping the folio. This half remains dirty but is now covered by an OE and is awaiting writeback running on its range to be submitted and finish the OE. 2. The back half: a. the folio is part of an OE that gets far enough along to clear writeback. b. dio read completes into the folio marking it fixup. After this, the folio's front half is dirty in the "normal" sense, it needs to be submitted to the OE waiting for it. It's a cancelled fixup. Meanwhile, the second half is a true fresh fixup. So at this point if we run writeback on this folio, we genuinely can't know what to do without block level information. If we submit it, we submit unreserved dirty from the back half. If we don't, we will never finish the OE waiting for it. So it's either a corruption or a deadlock. Thus, the full high level design picture: - btrfs_data_dirty_folio(): For out of band non-reserving dirties, mark still-clean blocks inside EOF dirty and set their fixup bits (the event carries no range, so every clean block is suspect). Already-dirty blocks are covered or pending and are left alone. - Writeback: skip fixup blocks and enqueue work for them - writepage_fixup(): for each fixup block do the fixup reservation in a worker, after which the blocks can be written back normally. - Typical reserving write paths cancel fixup state for the ranges they cover with btrfs_folio_cancel_fixup() Link: https://lore.kernel.org/linux-btrfs/20260721191152.101118-1-borntraeger@linux.ibm.com/ Assisted-by: LLM Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Boris Burkov <boris@bur.io> Signed-off-by: David Sterba <dsterba@suse.com>

@len

…_data() In that function, we round down the start position and round up the ending position. But during the calculation of @len, we use "round_up(start + len, sectorsize)", which is the rounded up end position, not the rounded up length. Which results a much larger length, and later we are still using "start + len", which is completely incorrect. Fix it by declaring a local @aligned_start and @aligned_len and use them instead. Fixes: bc42bda ("btrfs: qgroup: Fix qgroup reserved space underflow by only freeing reserved ranges") Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

In preparation for preallocating extent_buffer data, factor eb initialization away from specifically allocating it. This allows us to allocate the eb, bfs, folios, etc. together in the main search_slot code paths, but still share initialization code with the dummy/test/clone allocation paths. Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

In further preparation for supporting NOFAIL allocations with retries outside the critical section, add a struct to carry the extent_buffer and btrfs_folio_state we need to allocate. Refactor the allocation pathways to use the new struct but with no functional change. Wire empty prealloc structs in from callers. Reviewed-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

Now that we have the btrfs_eb_prealloc struct to carry the allocation and the "needs prealloc" signal, wire that up between the various search_slot style callers down into alloc_extent_buffer. If the prealloc struct indicates that it supports a nowait try, then alloc_extent_buffer tries to allocate NOWAIT. If that succeeds, great. Otherwise, we return EAGAIN and signal via the struct that preallocation is required. The caller then does the allocation and tries again with the eb, bfs, and folios wired through in the prealloc struct. If unlock-and-allocate retries are not supported then we just use the normal gfp flags like before. Note that there are still two GFP_NOFS allocations, as far as I know, that happen under the lock and cannot be preallocated: - the __xa_cmpxchg to insert the eb into the eb xarray - the xarray allocations for filemap_add_folio to add the folios to the btree_inode mapping. The former we could wire up with xa_reserve if we signaled the "prealloc start" back up to the retry point. However, since there is no concept of reservation in the filemap xarray, it seemed relatively unhelpful to bother. These allocations are relatively small cached slab allocations, so hopefully we can move the needle on reclaim stalls without reserving them. Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

extent_buffer readahead should not be able to painfully stall a search_slot and hog tree locks by getting stuck in direct reclaim. If the allocation fails, that is fine, we simply fail to do the readahead in that case. Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Boris Burkov <boris@bur.io> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

Btrfs relies on mapping_set_folio_order_range() to set the minimal folio order for all its data inodes, but that function will be no-op if transparent hugepage is not enabled. Guard the bs > ps support behind CONFIG_TRANSPARENT_HUGEPAGE, just like all other filesystems. Fixes: 98077f7 ("btrfs: enable experimental bs > ps support") Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

[BUG] When running generic/795 with 8K block size, 4K page size, the test always fails, triggering some ASSERT()s related to folio size: 795 (241074): drop_caches: 3 assertion failed: IS_ALIGNED(start, blocksize) && IS_ALIGNED(end + 1, blocksize), in extent_io.c:1404 (blocksize=8192 root=262 ino=258 start=16826368 end=16830463 mapping min order=0) ------------[ cut here ]------------ kernel BUG at extent_io.c:1404! Oops: invalid opcode: 0000 [#1] SMP CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:assert_folio_range.cold+0x3d/0x3f [btrfs] Call Trace: <TASK> btrfs_read_folio+0x9e/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] prepare_one_folio.constprop.0+0x104/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_buffered_write+0x285/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] btrfs_do_write_iter+0x1aa/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3] iter_file_splice_write+0x31a/0x540 direct_splice_actor+0x53/0x170 splice_direct_to_actor+0xe9/0x240 do_splice_direct+0x76/0xb0 vfs_copy_file_range+0x1fd/0x630 __x64_sys_copy_file_range+0xf9/0x220 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- The ASSERT() itself is added by a later patch. The crash is triggered with that new debug patch, and without this fix. [CAUSE] In the above case, the start 16826368 is properly 8K aligned, but the end (16830463 + 1) is not 8K aligned. Furthermore the mapping's minimal folio order is 0, not the expected 1 for 8K block size with 4K page size. So this means some inodes do not have btrfs_set_inode_mapping_order() called on it. The missing btrfs_set_inode_mapping_order() call happens for cached inodes, through the following events: - btrfs_create_new_inode() called for inode X Which properly sets minimal folio order for the VFS inode. - btrfs_update_inode() called for inode X Which calls btrfs_delayed_update_inode() to create a delayed_node into root->delayed_nodes xarray. - Drop cache/memory pressure, evicting in-memory inode X Which evicted the inode X, but delayed_node is still in root->delayed_nodes for future reuse. - btrfs_iget() for inode X called again btrfs_iget() |- btrfs_iget_locked() | |- iget5_locked_rcu() | Which creates a new vfs_inode for btrfs, whose mapping still | has the minimal order as 0. | |- btrfs_read_locked_inode() |- btrfs_fill_inode() | |- btrfs_get_delayed_node() | Which found out the previous node, and use that delayed | node to initialize the new inode. | |- filled = true; |- if (filled) goto cache_index; Which skips the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls. So the inode still has minimal folio order set as 0, not the required 1. Thus later page cache read will get a folio whose size is smaller than block size, as the mapping has its minimal folio order set as 0 not 1, then trigger the ASSERT(). [FIX] Move the btrfs_update_inode_mapping_flags() and btrfs_set_inode_mapping_order() calls under cache_index label, so that the mapping flags and minimal folio order is always set no matter if we have a cached inode. Assisted-by: LLM (analysis) Fixes: ecde48a ("btrfs: expose per-inode stable writes flag") Fixes: cc38d17 ("btrfs: enable large data folio support under CONFIG_BTRFS_EXPERIMENTAL") Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

Inspired by the previous crash exposed by generic/795, we want to make sure every folio from btrfs page cache is properly aligned to block size. This is especially important for bs > ps support, as every btrfs infrastructure, e.g. extent map and extent state, requires strong block alignment checks. Furthermore, also output the minimal folio order from the inode mapping, which is the determining factor during debugging, helping a lot pinning down the final cause. Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Qu Wenruo <wqu@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

If we the no-holes feature is enabled (a default since btrfs-progs 5.15), when doing a full fsync we always iterate of all leaves in the subvolume root that contain file extent items in order to detect holes between them. This can take a lot of time for files with a large number of extents. But if we know there are no prealloc extents and the amount of space (uncompressed space) is greater than or equals to the i_size of the inode, then we cannot have holes and therefore avoid searching for them. So skip the search if those conditions are met. The following test script was used: $ cat test.sh #!/bin/bash MNT=/mnt/nullb0 DEV=/dev/nullb0 umount $MNT &> /dev/null mkfs.btrfs -f $DEV mount $DEV $MNT # 256M gives 64K extents of 4K each. FILE_SIZE=$((256 * 1024 * 1024)) touch $MNT/foobar for ((i = 0; i < $FILE_SIZE; i += 8192)); do xfs_io -c "pwrite -S 0xab $i 4K" $MNT/foobar > /dev/null done xfs_io -c "fsync" $MNT/foobar for ((i = 4096; i < $FILE_SIZE; i += 8192)); do xfs_io -c "pwrite -S 0xab $i 4K" $MNT/foobar > /dev/null done # unmount and mount, clear caches and ensure the next fsync is a # full sync. umount $MNT mount $DEV $MNT # Do some change to the file in order to fsync. xfs_io -c "pwrite -S 0xcd 0 4K" $MNT/foobar > /dev/null T0=$(date +%s%N) xfs_io -c "fsync" $MNT/foobar T1=$(date +%s%N) echo echo "Took $(( (T1 - T0) / 1000 ))us" umount $MNT Before this change: Took 28721us After this change: Took 5453us That's about 5.3x times faster. Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>

Any commits after this one are for testing and evaluation only. Signed-off-by: David Sterba <dsterba@suse.com>

btrfs_record_root_in_trans() has a lockless fast path for shareable roots. It skips reloc_mutex when root->last_trans matches the current transaction and BTRFS_ROOT_IN_TRANS_SETUP is clear. The writer side publishes that state in two phases: it sets IN_TRANS_SETUP before updating root->last_trans, then clears the bit after btrfs_init_reloc_root() finishes. However, the reader-side smp_rmb() is before both loads, so it does not order the last_trans load against the later bit test. A reader can observe the new last_trans value while missing the setup bit and return before the relocation-root setup is complete. Read root->last_trans first, then issue the read barrier before testing IN_TRANS_SETUP. Also use clear_bit_unlock() for the writer's final clear and test_bit_acquire() for the successful fast path, so the lockless return observes the setup done before the bit was cleared. Fixes: 7585717 ("Btrfs: fix relocation races") Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com>

kdave force-pushed the misc-next branch from 10c2443 to ed8b841 Compare April 17, 2026 00:40

kdave force-pushed the ci-kvm branch from 5bdf707 to 479c0f7 Compare April 20, 2026 18:06

kdave force-pushed the misc-next branch 8 times, most recently from a464848 to 8f84140 Compare April 27, 2026 14:35

kdave force-pushed the misc-next branch 2 times, most recently from d93f97d to 7d5a51d Compare April 29, 2026 14:08

kdave force-pushed the misc-next branch 2 times, most recently from 14fb724 to d39211d Compare May 12, 2026 15:26

kdave force-pushed the misc-next branch 2 times, most recently from 8c55fe0 to 2fddc74 Compare May 16, 2026 01:02

kdave force-pushed the misc-next branch 10 times, most recently from 014f22d to 6b43c97 Compare May 29, 2026 00:01

kdave force-pushed the misc-next branch 4 times, most recently from 7263914 to 5342ffb Compare June 8, 2026 13:54

Zenghui Yu and others added 28 commits July 31, 2026 13:30

btrfs: === misc-next on b-for-next ===

6228084

Any commits after this one are for testing and evaluation only. Signed-off-by: David Sterba <dsterba@suse.com>

kdave force-pushed the misc-next branch from 399114b to d0da679 Compare July 31, 2026 11:30

kdave force-pushed the misc-next branch from d0da679 to 5004bcd Compare August 7, 2026 17:18

Navigation Menu

Uh oh!

Test misc-next (regular, SELF) - #1629

Test misc-next (regular, SELF)#1629
kdave wants to merge 10000 commits into
btrfs:ci-kvmfrom
kdave:misc-next

kdave commented Apr 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

20 participants

Uh oh!

Conversation

kdave commented Apr 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

20 participants