generic/251: use sentinel files to kill the fstrim loop

Apparently the subshell kill doesn't always take, and then the test runs
for hours and hours because nothing stops it.  Instead, use a sentinel
file to detect when fstrim_loop should stop execing background fstrims.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/009: allow logically contiguous preallocations

The new rtgroups feature implements a simplistic rotor to pick the
rtgroup for an initial allocation to a file.  This causes test failures
if the preallocations are spread across two rtgroups, which happens if
there are more subtests than rtgroups.

One way to fix this would be to reset the rotor then each subtest starts
allocating from rtgroup 0, but the only way to do that is to cycle the
scratch mount, which is a bit gross.

Instead, report logically contiguous mappings as a single mapping even
if the physical space is not contiguous.  Unfortunately, there's not
enough context in the comments to know if the test actually was checking
for physical contiguity?  Or if this is just an exerciser of the old
preallocation calls, and it's fine as long as the file ranges are mapped
(or unmapped) as desired.

Messing with some awk is a lot cheaper than umount/mount cycling.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/163: skip test if we can't shrink due to enospc issues

If this test fails due to insufficient space, skip this test.  This can
happen if a realtime volume is enabled on the filesystem and we cannot
shrink due to the rtbitmap.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/562: handle ENOSPC while cloning gracefully

This test creates a couple of patterned files on a tiny filesystem,
fragments the free space, clones one patterned file to the other, and
checks that the entire file was cloned.

However, this test doesn't work on a 64k fsblock filesystem because
we've used up all the free space reservation for the rmapbt, and that
causes the FICLONE to error out with ENOSPC partway through.  Hence we
need to detect the ENOSPC and _notrun the test.

That said, it turns out that XFS has been silently dropping error codes
if we managed to make some progress cloning extents.  That's ok if the
operation has REMAP_FILE_CAN_SHORTEN like copy_file_range does, but
FICLONE/FICLONERANGE do not permit partial results, so the dropped error
codes is actually an error.

Therefore, this testcase now becomes a regression test for the patch to
fix that.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common/rc: capture dmesg when oom kills happen

Capture the dmesg output if the OOM killer is invoked during fstests.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/508: fix test for 64k blocksize

It turns out that icreate transactions will try to reserve quite a bit
of space on a 64k fsblock filesystem -- enough to handle the worst case
parent directory expansion, a new inode chunk, and these days a parent
pointer as well.  This can work out to quite a bit of space:

fsblock reservation
1k 172K
4k 368K
16k 1136K
64k 3650K

Unfortunately, this test sets its block quota limits at 1-2MB, so we
can't even create a child file.  Bump the limits up by 10x so that this
test will pass even if there's more metadata size creep in the future.

Fixes: f769a923f576df ("xfs: project quota ineritance flag test")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/113: fix failure to corrupt the entire directory

This test tries to corrupt the data blocks of a directory, but it
doesn't take into account the fact that __populate_check_xfs_dir can
remove enough entries to cause sparse holes in the directory.  If that
happens, this "file data block is unmapped" logic will cause the
corruption loop to exit early.  Then we can add to the directory, which
causes the test to fail.

Instead, create a list of mappable dir block offsets, and run 100
corruptions at a time to reduce the amount of time we spend initializing
xfs_db.  This fixes the regressions that I see with 32k/64k block sizes.

Cc: fstests@vger.kernel.org # v2022.05.01
Fixes: c8e6dbc8812653 ("xfs: test directory metadata corruption checking and repair")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/757: convert to thinp

Convert this test to use dm-thinp so that discards always zero the data.
This prevents weird replay problems if the scratch device doesn't
guarantee that read after discard returns zeroes.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/757: fix various bugs in this test

Fix this test so the check doesn't fail on XFS, and restrict runtime to
100 loops because otherwise this test takes many hours.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/028: kill lingering processes when test is interrupted

If we interrupt the test after it spawned the fsstress and balance
processes (while it's sleeping for 30 seconds * $TIME_FACTOR), we don't
kill them and they stay around for a long time, making it impossible to
unmount the scratch filesystem (failing with -EBUSY).

Fix this by adding a _cleanup function that kills the processes and
waits for them to exit.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic: Addition of new tests for extsize hints

This commit adds new tests that checks the behaviour of xfs/ext4
filesystems when extsize hint is set on file with inode size as 0,
non-empty files with allocated and delalloc extents and so on.
Although currently this test is placed under tests/generic, it
only runs on xfs and there is an ongoing patch series[1] to
enable extsize hints for ext4 as well.

[1] https://lore.kernel.org/linux-ext4/cover.1726034272.git.ojaswin@linux.ibm.com/

Reviewed-by Ritesh Harjani (IBM) <ritesh.list@gmail.com>

Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Suggested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Signed-off-by: Nirjhar Roy <nirjhar@linux.ibm.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common/rc: Add a new _require_scratch_extsize helper function

_require_scratch_extsize helper function will be used in the
the next patch to make the test run only on filesystems with
extsize support.

Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Signed-off-by: Nirjhar Roy <nirjhar@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common/rc,xfs/207: Add a common helper function to check xflag bits

This patch defines a common helper function to test whether any of
fsxattr xflags field is set or not. We will use this helper in
an upcoming patch for checking extsize (e) flag.

Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Signed-off-by: Nirjhar Roy <nirjhar@linux.ibm.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/229: call on the test directory

xfs/229 operates on a directory that is forced to the data volume, but
it calls _require_fs_space on $TEST_DIR which might point to the RT
device when -d rtinherit is set.

Call _require_fs_space on $TDIR after it is created to check for the
space actually used by the test.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: "Hans Holmberg" <hans.holmberg@wdc.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/185: don't fail when rtfile is larger than rblocks

This test creates a 200MB rt volume on a file-backed loopdev.  However,
if the size of the loop file is not congruent with the rt extent size
(e.g.  28k) then the rt volume will not use all 200MB because we cannot
have partial rt extents.  Because of this rounding, we can end up with
an fsmap listing that covers fewer sectors than the bmap of the loop
file.

Fix the test to allow this case.

Cc: fstests@vger.kernel.org # v2022.05.01
Fixes: 410a2e3186a1e8 ("xfs: regresion test for fsmap problems with realtime")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/273: check thoroughness of the mappings

Enhance this test to make sure that there are no gaps in the fsmap
records, and (especially) that they we report all the way to the end of
the device.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/136: check for ext3 support

Test-case btrfs/136 requires ext3 support, so check for ext3 using
_require_extra_fs.

Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common/casefold: Support for tmpfs casefold test

Test casefold support for tmpfs.

Signed-off-by: André Almeida <andrealmeid@igalia.com>
Reviewed-by: Gabriel Krisman Bertazi <gabriel@krisman.be>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/321: make the filter to handle older btrfs-progs

[FALSE ALERT]
With much older distros like SLE12SP5, which is using btrfs-progs 4.5.3,
test case btrfs/321 fails like this:

 btrfs/321       QA output created by 321
 unable to locate the last csum tree leaf
 (see /opt/xfstests/results//btrfs/321.full for details)
 [failed, exit status 1]- output mismatch (see /opt/xfstests/results//btrfs/321.out.bad)
     --- tests/btrfs/321.out 2024-10-28 07:03:54.000000000 -0400
     +++ /opt/xfstests/results//btrfs/321.out.bad 2024-11-07 09:33:58.238442033 -0500
     @@ -1,2 +1,3 @@
      QA output created by 321
     -Silence is golden
     +unable to locate the last csum tree leaf
     +(see /opt/xfstests/results//btrfs/321.full for details)
     ...
     (Run diff -u /opt/xfstests/tests/btrfs/321.out /opt/xfstests/results//btrfs/321.out.bad  to see the entire diff)

[CAUSE]
The full output shows the regular csum tree as usual:

 btrfs-progs v4.5.3+20160729
 checksum tree key (CSUM_TREE ROOT_ITEM 0)
 node 4247552 level 1 items 9 free 112 generation 7 owner 7
 fs uuid 5623d533-ff79-4ddf-b9a1-7d359fa97c48
 chunk uuid 0af5a7bd-d2d8-4146-ada8-444f2a2f5351
  key (EXTENT_CSUM EXTENT_CSUM 20971520) block 4243456 (1036) gen 7
  key (EXTENT_CSUM EXTENT_CSUM 25006080) block 4251648 (1038) gen 7
  key (EXTENT_CSUM EXTENT_CSUM 29040640) block 4255744 (1039) gen 7
  key (EXTENT_CSUM EXTENT_CSUM 33075200) block 4259840 (1040) gen 7
  key (EXTENT_CSUM EXTENT_CSUM 37109760) block 4263936 (1041) gen 7
  key (EXTENT_CSUM EXTENT_CSUM 41144320) block 4268032 (1042) gen 7
  key (EXTENT_CSUM EXTENT_CSUM 45178880) block 4272128 (1043) gen 7
  key (EXTENT_CSUM EXTENT_CSUM 49213440) block 4276224 (1044) gen 7
  key (EXTENT_CSUM EXTENT_CSUM 53248000) block 4280320 (1045) gen 7
 leaf 4243456 items 1 free space 30 generation 7 owner 7
 fs uuid 5623d533-ff79-4ddf-b9a1-7d359fa97c48
 chunk uuid 0af5a7bd-d2d8-4146-ada8-444f2a2f5351
  item 0 key (EXTENT_CSUM EXTENT_CSUM 20971520) itemoff 55 itemsize 3940
  extent csum item
 [...]
 leaf 4280320 items 1 free space 2722 generation 7 owner 7
 fs uuid 5623d533-ff79-4ddf-b9a1-7d359fa97c48
 chunk uuid 0af5a7bd-d2d8-4146-ada8-444f2a2f5351
  item 0 key (EXTENT_CSUM EXTENT_CSUM 53248000) itemoff 2747 itemsize 1248
  extent csum item
 total bytes 25768755200
 bytes used 34213888
 uuid 5623d533-ff79-4ddf-b9a1-7d359fa97c48

But notice the header for each leaf, there is no flags for the leaf.
On newer btrfs-progs, the leaf header lines looks like this:

 leaf 5423104 items 1 free space 2918 generation 7 owner CSUM_TREE
 leaf 5423104 flags 0x1(WRITTEN) backref revision 1

It's two lines, not the old one line output.
The new behavior is introduced in btrfs-progs commit 9cc9c9ab3220
("btrfs-progs: print the eb flags for nodes as well"), included by v5.10
release.

So the test case doesn't handle older output format and failed to locate
the target leaf.

[FIX]
Instead of relying on the leaf flags line, use the much older
"leaf <bytenr> items" line as the filter target, so we can support much
older distros.

Reported-by: Long An <lan@suse.com>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1233303
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

ext4/032: add a new testcase in online resize tests

Add a new testcase for [1] commit in ext4 online resize testsuite.

Link: https://lore.kernel.org/linux-ext4/20240927133329.1015041-1-libaokun@huaweicloud.com
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Baokun Li <libaokun1@huawei.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs: a new test case to verify mount behavior with background remounting

[BUG]
When there is a process in the background remounting a btrfs, switching
between RO/RW, then another process try to mount another subvolume of
the same btrfs read-only, we can hit a race causing the RW mount to fail
with -EBUSY:

[CAUSE]
During the btrfs mount, to support mounting different subvolumes with
different RO/RW flags, we have a small hack during the mount:

  Retry with matching RO flags if the initial mount fail with -EBUSY.

The problem is, during that retry we do not hold any super block lock
(s_umount), this meanings there can be a remount process changing the RO
flags of the original fs super block.

If so, we can have an EBUSY error during retry.
And this time we treat any failure as an error, without any retry and
cause the above EBUSY mount failure.

[FIX]
The fix is already sent to the mailing list.
The fix is to allow btrfs to have different RO flag between super block
and mount point during mount, and if the RO flag mismatch, reconfigure
the fs to RW with s_umount hold, so that there will be no race.

[TEST CASE]
The test case will create two processes:

- Remounting an existing subvolume mount point
  Switching between RO and RW

- Mounting another subvolume RW
  After a successful mount, unmount and retry.

This is enough to trigger the -EBUSY error in less than 5 seconds.
To be extra safe, the test case will run for 10 seconds at least, and
follow TIME_FACTOR for extra loads.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs: add a test for defrag of contiguous file extents

Test that defrag merges adjacent extents that are contiguous.
This exercises a regression fixed by a patchset for the kernel that is
comprissed of the following patches:

  btrfs: fix extent map merging not happening for adjacent extents
  btrfs: fix defrag not merging contiguous extents due to merged extent maps

Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs: online grow vs. log recovery stress test (realtime version)

This is fundamentally the same as the previous growfs vs. log
recovery test, with tweaks to support growing the XFS realtime
volume on such configurations. Changes include using the appropriate
mkfs params, growfs params, and enabling realtime inheritance on the
scratch fs.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redaht.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs: online grow vs. log recovery stress test

fstests includes decent functional tests for online growfs and
shrink, and decent stress tests for crash and log recovery, but no
combination of the two. This test combines bits from a typical
growfs stress test like xfs/104 with crash recovery cycles from a
test like generic/388. As a result, this reproduces at least a
couple recently fixed issues related to log recovery of online
growfs operations.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/287: make the test work when compression is enabled

When running btrfs/287 with compression enabled (mount options), the test
fails because it expects to find 4M extents, however compression limits
the maximum size of extents to 128K, breaking the tests' expectations.

Example:

  $ MOUNT_OPTIONS="-o compress" ./check btrfs/287
  FSTYP         -- btrfs
  PLATFORM      -- Linux/x86_64 debian0 6.12.0-rc4-btrfs-next-177+ #1 SMP PREEMPT_DYNAMIC Thu Oct 24 17:14:37 WEST 2024
  MKFS_OPTIONS  -- /dev/sdc
  MOUNT_OPTIONS -- -o compress /dev/sdc /home/fdmanana/btrfs-tests/scratch_1

  btrfs/287 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/287.out.bad)
      --- tests/btrfs/287.out 2024-10-19 18:21:30.451644840 +0100
      +++ /home/fdmanana/git/hub/xfstests/results//btrfs/287.out.bad 2024-10-29 16:31:20.926612583 +0000
      @@ -25,22 +25,14 @@
       resolve first extent with ignore offset option:
       inode 257 offset 16777216 root 5
       inode 257 offset 8388608 root 5
      -inode 257 offset 2097152 root 5
       resolve first extent +1M offset:
      -inode 257 offset 17825792 root 5
      -inode 257 offset 9437184 root 5
      ...
      (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/287.out /home/fdmanana/git/hub/xfstests/results//btrfs/287.out.bad'  to see the entire diff)

  HINT: You _MAY_ be missing kernel fix:
        0cad8f14d70c btrfs: fix backref walking not returning all inode refs

  Ran: btrfs/287
  Failures: btrfs/287
  Failed 1 of 1 tests

Fix this by creating the two 4M extents with fallocate, so that the test
works regardless of compression being enabled or not.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

f2fs/007: add testcase to check consistency of compressed inode metadata

metadata of compressed inode should always be consistent after file
compression, reservation, releasement and decompression, let's add
a testcase to check it.

Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Qi Han <hanqi@vivo.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

f2fs/006: add testcase to check out-of-space case

This is a regression test to check whether f2fs handles dirty
data correctly when checkpoint is disabled, if lfs mode is on,
it will trigger OPU for all overwritten data, this will cost
free segments, so f2fs must account overwritten data as OPU
data when calculating free space, otherwise, it may run out
of free segments in f2fs' allocation function. If kernel config
CONFIG_F2FS_CHECK_FS is on, it will cause system panic, otherwise,
dd may encounter I/O error.

Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Chao Yu <chao@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

f2fs/005: add testcase to check checkpoint disabling functionality

This patch introduce a regression test to check whether f2fs handles
dirty inode correctly when checkpoint is disabled in a corner case,
it may hang umount before the bug is fixed.

Cc: Qi Han <hanqi@vivo.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic: new test case to verify if certain fio load will hang the filesystem

[BUG]
During the development to make btrfs pass generic/563 (which needs to
make btrfs to support partial folios), generic/095 causes hangs
during tests.

The call trace for the hanging process looks like this:

  __switch_to+0xf8/0x168
  __schedule+0x328/0x8a8
  schedule+0x54/0x140
  io_schedule+0x44/0x68
  folio_wait_bit_common+0x198/0x3f8
  __folio_lock+0x24/0x40
  extent_write_cache_pages+0x2e0/0x4c0 [btrfs]
  btrfs_writepages+0x94/0x158 [btrfs]
  do_writepages+0x74/0x190
  filemap_fdatawrite_wbc+0x88/0xc8
  __filemap_fdatawrite_range+0x6c/0xa8
  filemap_fdatawrite_range+0x1c/0x30
  btrfs_start_ordered_extent+0x264/0x2e0 [btrfs]
  btrfs_lock_and_flush_ordered_range+0x8c/0x160 [btrfs]
  __get_extent_map+0xa0/0x220 [btrfs]
  btrfs_do_readpage+0x1bc/0x5d8 [btrfs]
  btrfs_read_folio+0x50/0xa0 [btrfs]
  filemap_read_folio+0x54/0x110
  filemap_update_page+0x2e0/0x3b8
  filemap_get_pages+0x228/0x4d8
  filemap_read+0x11c/0x3b8
  btrfs_file_read_iter+0x74/0x90 [btrfs]
  new_sync_read+0xd0/0x1d0
  vfs_read+0x1a0/0x1f0

[CAUSE]
The root cause is a btrfs specific behavior that during a folio read, we
can trigger writeback of the same folio, which will try to lock the same
folio already locked by the read process.

The fix is already sent to the mailing list:
https://lore.kernel.org/linux-btrfs/62bf73ada7be2888d45a787c2b6fd252103a5d25.1729725088.git.wqu@suse.com/

This problem can only happen if all the following conditions are met:

- The sector size of btrfs is smaller than page size
  To have partial uptodate folios.

- Btrfs won't read the full folio if buffered write is block aligned
  This is done by the not yet merged patch:
  https://lore.kernel.org/linux-btrfs/ac2639ec4e9ac176d33e95ef7ecf008fa6be5461.1727833878.git.wqu@suse.com/

[TEST CASE]
During the debugging of that generic/095 hang, I extracted a minimal
reproducer which is much smaller and faster, although it still requires
several runs to trigger a hang.

The test case will run the fio workload 32 times by default, which is
more than enough to trigger the hang.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs: notrun if kernel xfs not supports ascii-ci feature

As the ascii-ci feature is deprecated, if linux build without the
CONFIG_XFS_SUPPORT_ASCII_CI, mount xfs with "-n version=ci" will
get EINVAL. So let's notrun if it's not supported by kernel.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs: test remount with "compress" clears "compress-force"

Test that remounting with the "compress" mount option clears the
"compress-force" mount option previously specified.

This tests a regression introduced with kernel 6.8 and recently fixed by
the following kernel commit:

  3510e684b8f6 ("btrfs: clear force-compress on remount when compress mount option is given")

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic: increase file size to match CoW delayed allocation for XFS 64k bs

generic/305,326,328 have been failing for 32k and 64k blocksizes.

We do the following in the test 305 and 326 (highlighting only the part
that is related to failure):

- create a 1M test-1/file1
- reflink test-1/file2 and test-1/file3 based on test-1/file1
- Overwrite first half of test-1/file2 to do a CoW operation
- Expect the size of the test-1 dir to be 3M

The test is failing for 32k and 64k blocksizes as the number of blocks
(direct + delayed) is higher than number of blocks allocated for
blocksizes < 32k in XFS, resulting in size of test-1 to be more than 3M.
Though generic/328 has a different IO pattern, the reason for failure is
the same.

This is the failure output :
    --- tests/generic/305.out   2024-06-05 11:52:27.430262812 +0000
    +++ /root/results//64k_4ks/generic/305.out.bad      2024-10-23 10:56:57.643986870 +0000
    @@ -11,7 +11,7 @@
     CoW one of the files
     root 0 0 0
     nobody 0 0 0
    -fsgqa 3072 0 0
    +fsgqa 4608 0 0
     Remount the FS to see if accounting changes
     root 0 0 0

In these tests, XFS is doing a delayed allocation of
XFS_DEFAULT_COWEXTSIZE_HINT(32). Increase the size of the file so that
the CoW write(sz/2) matches the maximum size of the delayed allocation
for the max blocksize of 64k. This will ensure that all parts of the
delayed extents are converted to real extents for all blocksizes.

Even though this is not the most complete solution to fix these tests,
the objective of these tests are to test quota and not the effect of delayed
allocations.

Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/219: use filesystem blocksize while calculating the file size

generic/219 was failing for XFS with 32k and 64k blocksize. Even though
we do only 48k IO, XFS will allocate blocks rounded to the nearest
blocksize.

Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

f2fs/004: add missing _fixed_by_kernel_commit line

The bug related to this regression testcase has been fixed by commit
b2c160f4f3cf ("f2fs: atomic: fix to forbid dio in atomic_file"), let's
add missing _fixed_by_kernel_commit line for this testcase.

Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fstests: btrfs/002: fix the OOM caused by too large block size

[BUG]
When running the test case btrfs/002, with 64K page size and 64K sector
size, and the VM doesn't have much memory (in my case 4G Vram), the test
case will trigger OOM and fail:

btrfs/002 4s ... [failed, exit status 1]- output mismatch (see /home/adam/xfstests-dev/results//btrfs/002.out.bad)
    --- tests/btrfs/002.out 2024-04-25 18:13:45.035555469 +0930
    +++ /home/adam/xfstests-dev/results//btrfs/002.out.bad 2024-10-12 17:19:48.785156223 +1030
    @@ -1,2 +1 @@
     QA output created by 002
    -Silence is golden
    ...

The OOM is triggered by the dd process, and a lot of dd processes are
using too much memory:

 dd invoked oom-killer: gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, oom_score_adj=250
 CPU: 0 UID: 0 PID: 185764 Comm: dd Not tainted 6.12.0-rc2-custom+ #76
 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022
 Tasks state (memory values in pages):
 [  pid  ]   uid  tgid total_vm      rss rss_anon rss_file rss_shmem pgtables_bytes swapents oom_score_adj name
 [ 185665]     0 185665     8688     3840     3840        0         0   458752     4832           250 dd
 [ 185672]     0 185672     8688     2432     2432        0         0   393216     5312           250 dd
 [ 185680]     0 185680     8688     2016     2016        0         0   458752     4960           250 dd
 [ 185686]     0 185686     8688     2080     2080        0         0   458752     3584           250 dd
 [ 185693]     0 185693     8688     2144     2144        0         0   458752     4384           250 dd
 [ 185700]     0 185700     8688     2176     2176        0         0   458752     3584           250 dd
 [ 185707]     0 185707     8688     1792     1792        0         0   524288     3616           250 dd
 [ 185714]     0 185714     8688     2304     2304        0         0   458752     3488           250 dd
 [ 185721]     0 185721     8688     1920     1920        0         0   458752     2624           250 dd
 [ 185728]     0 185728     8688     2272     2272        0         0   393216     2528           250 dd
 [ 185735]     0 185735     8688     2048     2048        0         0   393216     3552           250 dd
 [ 185742]     0 185742     8688     1984     1984        0         0   458752     2816           250 dd
 [ 185751]     0 185751     8688     1600     1600        0         0   458752     2784           250 dd
 [ 185756]     0 185756     8688     1120     1120        0         0   458752     2400           250 dd
 [ 185764]     0 185764     8688     1504     1504        0         0   393216     2240           250 dd
 [ 185772]     0 185772     8688     1504     1504        0         0   458752     1984           250 dd
 [ 185777]     0 185777     8688     1280     1280        0         0   393216     2336           250 dd
 [ 185784]     0 185784     8688     2144     2144        0         0   393216     2272           250 dd
 [ 185791]     0 185791     8688     2176     2176        0         0   458752      576           250 dd
 [ 185798]     0 185798     8688     1696     1696        0         0   458752     1536           250 dd
 [ 185806]     0 185806     8688     1728     1728        0         0   393216      544           250 dd
 [ 185815]     0 185815     8688     2240     2240        0         0   458752        0           250 dd
 [ 185819]     0 185819     8688     1504     1504        0         0   458752      384           250 dd
 [ 185826]     0 185826     8688     1536     1536        0         0   458752      160           250 dd
 [ 185833]     0 185833     8688     2944     2944        0         0   458752       64           250 dd
 [ 185838]     0 185838     8688     2400     2400        0         0   458752        0           250 dd
 [ 185847]     0 185847     8688      864      864        0         0   458752        0           250 dd
 [ 185853]     0 185853     8688     1088     1088        0         0   393216        0           250 dd
 [ 185860]     0 185860     8688      416      416        0         0   393216        0           250 dd
 [ 185867]     0 185867     8688      352      352        0         0   458752        0           250 dd

[CAUSE]
The test case workload _fill_blk() is going to fill the file to its block
boundary.

But the implementation is not taking larger blocks into consideration.

FSIZE=`stat -t $i | cut -d" " -f2`
BLKS=`stat -c "%B" $i`
NBLK=`stat -c "%b" $i`
FALLOC=$(($BLKS * $NBLK))
WS=$(($FALLOC - $FSIZE))

$FSIZE is the file size, $BLKS is the size of each reported block,
$NBLK is the number of blocks the file takes, thus $FALLOC is the
rounded up block size.

For 64K sector size, the BLKS is 512, and NBLKS is 128 (one 64K sector).
$FALLOC is the correct value of 64K (10K rounded up to 64K).

Then the problem comes to how the write is done:

_ddt of=$i oseek=$FSIZE obs=$WS count=1 status=noxfer 2>/dev/null &

Unfrotunately the above command is using output block size of 54K, and
need to skip 10K * 54K bytes, resulting a file size of 540M.

So far although it's not the correct intention, it's not yet causing
problem.

But during _append_file(), we further enlarge the file by:

FSIZE=`stat -t $i | cut -d" " -f2`
dd if=$X of=$i seek=1 bs=$FSIZE obs=$FSIZE count=1 status=noxfer 2>/dev/null &

In above case, since the previous file is 540M size, the output block
size will also be 540M, taking a lot of memory.

Furthermore since the workload is run in background, we can have many dd
processes taking up at least 540M, causing huge memory usage and trigger
OOM.

[FIX]
The original code is already not doing what it should do, just get rid of
the cursed dd command usage inside _fill_blk(), and use pwrite from
xfs_io instead.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

misc: amend unicode confusing name tests to check for hidden tag characters

The Unicode consortium has twice defined (and later deprecated) special
"tag" codepoints.  These tag codepoints are not supposed to be rendered
(i.e. they're invisible) but you can certainly encode them in
directories and labels to try to confuse users.

xfs_scrub already knows how complain about these tag characters because
libicu can detect both their presence and their use in confusing name
attacks, so add this as an explicit regression test.

Link: https://embracethered.com/blog/posts/2024/hiding-and-finding-text-with-unicode-tags/
Link: https://arstechnica.com/security/2024/10/ai-chatbots-can-read-and-write-invisible-text-creating-an-ideal-covert-channel/
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fstests: btrfs/330: enable the test case for both new and old APIs

[BUG]
If the mount tool is utilizing the new fs-based API
(e.g. util-linux 2.40.2 from Archlinux), btrfs' per-subvolume RO/RW mount
is broken again:

  # mount -o subvol=subv1,ro /dev/test/scratch1 /mnt/test
  # mount -o rw,subvol=subv2 /dev/test/scratch1  /mnt/scratch
  # mount | grep mnt
  /dev/mapper/test-scratch1 on /mnt/test type btrfs (ro,relatime,discard=async,space_cache=v2,subvolid=256,subvol=/subv1)
  /dev/mapper/test-scratch1 on /mnt/scratch type btrfs (ro,relatime,discard=async,space_cache=v2,subvolid=257,subvol=/subv2)
  # touch /mnt/scratch/foobar
  touch: cannot touch '/mnt/scratch/foobar': Read-only file system

[CAUSE]
Btrfs has an extra remount hack to handle above case, which will
re-configure the super block to be RW on the first RW mount.

The initial promise is, the new fd-based API will not set ro FLAG, but
only MOUNT_ATTR_RDONLY, so that btrfs will skip the remount hack for new
API based mount request.

However it's not the case, the first RO subvolume mount will set ro flag
at fsconfig(), and also set MOUNT_ATTR_RDONLY attribute for the mount
point:

  # strace  mount -o subvol=subv1,ro /dev/test/scratch1 /mnt/test/
  ...
  fsconfig(3, FSCONFIG_SET_STRING, "source", "/dev/mapper/test-scratch1", 0) = 0
  fsconfig(3, FSCONFIG_SET_STRING, "subvol", "subv1", 0) = 0
  fsconfig(3, FSCONFIG_SET_FLAG, "ro", NULL, 0) = 0
  fsconfig(3, FSCONFIG_CMD_CREATE, NULL, NULL, 0) = 0
  fsmount(3, FSMOUNT_CLOEXEC, 0)          = 4
  mount_setattr(4, "", AT_EMPTY_PATH, {attr_set=MOUNT_ATTR_RDONLY, attr_clr=0, propagation=0 /* MS_??? */, userns_fd=0}, 32) = 0
  move_mount(4, "", AT_FDCWD, "/mnt/test", MOVE_MOUNT_F_EMPTY_PATH) = 0

This will result exactly the same behavior,  no matter if it's the new
API or not.

Furthermore we can even have corner cases like mounting the initial RO
subvolume using the old API, then mount the RW subvolume using the new
API.

So even using the new API, there is no guarantee to keep the
per-subvolume RO/RW mount feature.
We have to do the reconfigure anyway.

[FIX]
The kernel fix is already submitted, but for the test case part, we
should enable btrfs/330 for all mount tools, no matter the API it
utilizes.

The only difference for the new API based mount is the new
_fixed_by_kernel_commit call, to show the proper fix.

Now it can properly detects the broken feature.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/012: fix false alerts when SELinux is enabled

[FALSE FAILURE]
If SELinux is enabled, the test btrfs/012 will fail due to metadata
mismatch:

FSTYP         -- btrfs
PLATFORM      -- Linux/x86_64 localhost 6.4.0-150600.23.25-default #1 SMP PREEMPT_DYNAMIC Tue Oct  1 10:54:01 UTC 2024 (ea7c56d)
MKFS_OPTIONS  -- /dev/loop1
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/loop1 /mnt/scratch

btrfs/012       - output mismatch (see /home/adam/xfstests-dev/results//btrfs/012.out.bad)
    --- tests/btrfs/012.out 2024-10-18 10:15:29.132894338 +1030
    +++ /home/adam/xfstests-dev/results//btrfs/012.out.bad 2024-10-18 10:25:51.834819708 +1030
    @@ -1,6 +1,1390 @@
     QA output created by 012
     Checking converted btrfs against the original one:
    -OK
    +metadata mismatch in /p0/d2/f4
    +metadata mismatch in /p0/d2/f5
    +metadata and data mismatch in /p0/d2/
    +metadata and data mismatch in /p0/
    ...

[CAUSE]
All the mismatch happens in the metadata, to be more especific, it's the
security xattrs.

Although btrfs-convert properly convert all xattrs including the
security ones, at mount time we will get new SELinux labels, causing the
mismatch between the converted and original fs.

[FIX]
Override SELINUX_MOUNT_OPTIONS so that we will not touch the security
xattrs, and that should fix the false alert.

Reported-by: Long An <lan@suse.com>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1231524
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/161: adapt the test case for LBS filesystem

This test fails for >= 64k filesystem block size on a 4k PAGE_SIZE
system(see LBS efforts[1]). Adapt the blksz so that we create more than
one block for the testcase.

Cap the blksz to be at least 64k to retain the same behaviour as before
for smaller filesystem blocksizes.

[1] LBS effort: https://lore.kernel.org/lkml/20230915183848.1018717-1-kernel@pankajraghav.com/

Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common/xfs: _notrun tests that fail due to block size < sector size

It makes no sense to fail a test that failed to format a filesystem with
a block size smaller than the sector size since the test preconditions
are not valid.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic: add test for missing btrfs csums in log when doing async on subpage vol

Adds a test for a bug we encountered on Linux 6.4 on aarch64, where a
race could mean that csums weren't getting written to the log tree,
leading to corruption when it was replayed.

The patches to detect log this tree corruption are in btrfs-progs 6.11.

Signed-off-by: Mark Harmstone <maharmstone@fb.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs: add test for cleaner thread under seed-sprout

We have a longstanding bug that creating a seed sprout fs with the
ro->rw transition done with

mount -o remount,rw $mnt

instead of

umount $mnt
mount $sprout_dev $mnt

results in an fs without BTRFS_FS_OPEN set, which fails to ever run the
critical btrfs cleaner thread.

This test reproduces that bug and detects it by creating and deleting a
subvolume, then triggering the cleaner thread. The expected behavior is
for the cleaner thread to delete the stale subvolume and for the list to
show no entries. Without the fix, we see a DELETED entry for the subvol.

Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: Zorro Lang <zlang@kernel.org>

src/fiexchange.h: add the start-commit/commit-range ioctls

Add these two ioctls as well, since they're a part of the file content
exchange functionality.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fsstress: add support for FALLOC_FL_UNSHARE_RANGE

Teach fsstress to try to unshare file blocks on filesystems, seeing how
the recent addition to fsx has uncovered a lot of bugs.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common/config: fix RECREATE_TEST_DEV initialization

Do not allow the overwriting of the RECREATE_TEST_DEV variable. When
this variable is enabled, common/rc -> common/config will reset it
to false after the test device recreation process. This allows for
differentiation in mount options for SCRATCH and TEST.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common/populate: fix bash syntax error in _fill_fs

In bash, one does not set a variable by prepending the dollar sign to
the variable name.  Amazingly, this was copied verbatim from generic/256
in 2016 and hasn't been caught since its introduction in 2011. :(

Cc: allison.henderson@oracle.com
Fixes: 815015e9ee ("generic: make 17[1-4] work well when btrfs compression is enabled")
Fixes: b55fb0807c ("xfstests: Add ENOSPC Hole Punch Test")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/315: update filter to match mount cmd

Mount error info changed since util-linux v2.40
(91ea38e libmount: report failed syscall name).
So update _filter_mount_error() to match it.

Signed-off-by: An Long <lan@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/322: add git commit ID

The corresponding btrfs kernel patch was merged into Linus' tree and
included in kernel 6.12-rc2, so update the test with the commit ID.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs: update some tests to be able to run with btrfs-progs v6.11

In btrfs-progs v6.11 the output of the "filesystem show" command changed
so that it no longers prints blank lines. This happened with commit
4331bfb011bd ("btrfs-progs: fi show: remove stray newline in filesystem
show").

We have some tests that expect the blank lines in their golden output,
and therefore they fail with btrfs-progs v6.11.

So update the filter _filter_btrfs_filesystem_show to remove blank lines
and change the golden output of the tests to not expect the blank lines,
making the tests work with btrfs-progs v6.11 and older versions.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Boris Burkov <boris@bur.io>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/318: add _require_loop

btrfs/318 uses loopback devices, but was missing a call to _require_loop
to print the correct message if CONFIG_LOOP is not set.

Signed-off-by: Mark Harmstone <maharmstone@fb.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common/fail_make_request: fix error message

fail_make_request depends on the kernel option CONFIG_FAIL_MAKE_REQUEST
to function, not CONFIG_FAULT_INJECTION_DEBUG_FS.

Signed-off-by: Mark Harmstone <maharmstone@fb.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/694: sync before sampling i_blocks

Without a sync there might still be temporary blocks in i_blocks like
indirect block reservations or additional blocks reserved for out of
place writes.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/157,xfs/547,xfs/548: switch to using _scratch_mkfs_sized

These test cases specify small -d sizes which combined with a rt dev of
unrestricted size and the rtrmap feature can cause mkfs to fail with
error:

mkfs.xfs: cannot handle expansion of realtime rmap btree; need <x> free
blocks, have <y>

This is due to that the -d size is not big enough to support the
metadata space allocation required for the rt groups.

Switch to use _scratch_mkfs_sized that sets up the -r size parameter
to avoid this. If -r size=x and -d size=x we will not risk running
out of space on the ddev as the metadata size is just a fraction of
the rt data size.

Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common: make rt_ops local in _try_scratch_mkfs_sized

If we call _try_scratch_mkfs_size with $SCRATCH_RTDEV set followed by
a call with $SCRATCH_RTDEV cleared, rt_ops will have stale size
parameters that will cause mkfs.xfs to fail with:
"size specified for non-existent rt subvolume"

Make rt_ops local to fix this.

Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fstests: generic/563: use fs blocksize to do the writes

[FALSE ALERTS]
If the system has a page size larger than 4K, and the fs block size
matches the page size, test case generic/563 will fail:

    --- tests/generic/563.out 2024-04-25 18:13:45.178550333 +0930
    +++ /home/adam/xfstests-dev/results//generic/563.out.bad 2024-09-30 09:09:16.155312379 +0930
    @@ -3,7 +3,8 @@
     read is in range
     write is in range
     write -> read/write
    -read is in range
    +read has value of 8388608
    +read is NOT in range -33792 .. 33792
     write is in range
    ...

Both Ext4 and btrfs fail with 64K block size and 64K page size

[CAUSE]
The test case writes the 8MiB file using the default block size xfs_io
pwrite, which is 4KiB.

Since the fs block size is 64K, such 4KiB write is unaligned inside a
block, causing the fs to read out the full page.

Thus the pwrite will cause the fs to read out every page, resulting the
above 8MiB+ read value.

[FIX]
Fix the test case by using the fs block size to avoid such unaligned
buffered write.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Boris Burkov <boris@bur.io>
Reviewed-by: Mark Harmstone <maharmstone@fb.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

src/Makefile: install two necessary files

parse-dev-tree.awk and parse-extent-tree.awk are used by generic/746.
We need to make sure them are installed, otherwise generic/746 will
have problems if fstests is installed via "make install".

Signed-off-by: An Long <lan@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

src/min_dio_alignment: don't return invalid dio_offset_align

If returned parameters of statx() are: a)STATX_DIOALIGN is set in
stx_mask, b)stx.stx_dio_offset_align is zero, it indicates filesystem
supports DIO, but the file doesn't.

It needs to avoid returning zeroed stx.stx_dio_offset_align value,
instead, we can fallthrough to get alignment size of block device or
page size, otherwise, it may cause potential deadloop, e.g.
generic/465:

align=stx_dio_offset_align(it equals to zero)
page_size=4096
while [ $align -le $page_size ]; do
    echo "$AIO_TEST -a $align -d $testfile.$align" >> $seqres.full
    $AIO_TEST -a $align -d $testfile.$align 2>&1 | tee -a $seqres.full
    align=$((align * 2))
done

Cc: Christoph Hellwig <hch@lst.de>
Cc: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Chao Yu <chao@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs: new EOF fragmentation tests

These tests create substantial file fragmentation as a result of
application actions that defeat post-EOF preallocation
optimisations. They are intended to replicate known vectors for
these problems, and provide a check that the fragmentation levels
have been controlled. The mitigations we make may not completely
remove fragmentation (e.g. they may demonstrate speculative delalloc
related extent size growth) so the checks don't assume we'll end up
with perfect layouts and hence check for an exceptable level of
fragmentation rather than none.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
[move to different test number, update to current xfstest APIs]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs: test an incremental send scenario with cloning of unaligned extent

Test that doing an incremental send with a file that had its size
decreased and became the destination for a clone operation of an extent
with an unaligned end offset that matches the new file size, works
correctly.

This tests a bug fixed by the following kernel patch:

  "btrfs: send: fix invalid clone operation for file that got its size decreased"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fsx: support unshare range fallocate mode

The fallocate unshare mode flag modifies traditional preallocate
mode to unshare any shared extents backing the target range. Without
the unshare flag, preallocate mode simply assures that blocks are
physically allocated, regardless of whether they might be shared.
Unshare mode behaves the same as preallocate mode outside of the
shared extent case.

Since unshare is fundamentally a modifier to preallocate mode,
enable it via an operation flag. Similar to keep size mode, select
it randomly for fallocate operations and track it via a flag and
string combination for operation logging and replay.

Unshare is mainly used for filesystems that support reflink, but the
operation is equivalent to preallocate mode for non-shared ranges,
so enable it by default. Filesystems that do not support the
fallocate flag (such as those that might not support reflink) will
fail the test operation and disable unshare calls at runtime. Also
provide a new command line option to explicitly disable unshare
calls.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/321: make the test work when compression is enabled

When running btrfs/321 with compression enabled it fails like this:

  $ MOUNT_OPTIONS="-o compress" ./check btrfs/321
  FSTYP         -- btrfs
  PLATFORM      -- Linux/x86_64 debian0 6.11.0-rc7-btrfs-next-174+ #1 SMP PREEMPT_DYNAMIC Tue Sep 10 17:11:38 WEST 2024
  MKFS_OPTIONS  -- /dev/sdc
  MOUNT_OPTIONS -- -o compress /dev/sdc /home/fdmanana/btrfs-tests/scratch_1

  btrfs/321 2s ... [failed, exit status 1]- output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/321.out.bad)
      --- tests/btrfs/321.out 2024-09-12 12:12:11.259272125 +0100
      +++ /home/fdmanana/git/hub/xfstests/results//btrfs/321.out.bad 2024-09-12 13:18:40.231120012 +0100
      @@ -1,2 +1,5 @@
       QA output created by 321
      -Silence is golden
      +mount: /home/fdmanana/btrfs-tests/scratch_1: can't read superblock on /dev/sdc.
      +       dmesg(1) may have more information after failed mount system call.
      +mount -o compress -o ro /dev/sdc /home/fdmanana/btrfs-tests/scratch_1 failed
      +(see /home/fdmanana/git/hub/xfstests/results//btrfs/321.full for details)
      ...
      (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/321.out /home/fdmanana/git/hub/xfstests/results//btrfs/321.out.bad'  to see the entire diff)

  HINT: You _MAY_ be missing kernel fix:
        10d9d8c3512f btrfs: fix a use-after-free bug when hitting errors inside btrfs_submit_chunk()

  Ran: btrfs/321
  Failures: btrfs/321
  Failed 1 of 1 tests

This is because with compression enabled we get a csum tree that has only
one leaf, and that leaf is the root of the csum tree. That means that
after the test corrupts the leaf, the next mount will fail since an error
loading the root is critical and makes the mount operation fail.

Fix this by creating a file with 128M of data instead of 32M, as this
guarantees that even if compression is enabled, and even with the maximum
allowed leaf size (64K), we still get a csum tree with multiple leaves,
making the test work.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic: add a regression test for sub-block fsmap queries

Zizhi Wo found some bugs in the GETFSMAP implementation if it is fed
sub-fsblock ranges.  Add a regression test for this.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fstests: fix min_dio_alignment logic for getting device block size

If we failed to get the dio alignment from statx we try to get the
device's block size using the BLKSSZGET ioctl, however we failed to
return it because we don't check if the ioctl succeeded (returned 0).
Furthermore in case the ioctl returned an error, we end up returning an
undefined value since the 'logical_block_size' variable ends up not
being initialized.

This was causing some tests to be skipped on btrfs after commit
ee799a0cf1d4 ("replace _min_dio_alignment with calls to
src/min_dio_alignment"), like generic/240 for example:

  $ ./check generic/240
  FSTYP         -- btrfs
  PLATFORM      -- Linux/x86_64 debian0 6.11.0-rc7-btrfs-next-174+ #1 SMP PREEMPT_DYNAMIC Tue Sep 10 17:11:38 WEST 2024
  MKFS_OPTIONS  -- /dev/sdc
  MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1

  generic/240 1s ... [not run] fs block size must be larger than the device block size.  fs block size: 4096, device block size: 4096
  Ran: generic/240
  Not run: generic/240
  Passed all 1 tests

Where before that commit the test ran.

Fix this by checking that the ioctl succeeded.

Fixes: 0e5f196d0a6a ("add a new min_dio_alignment helper")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fstests: add missing kernel git commit IDs to some tests

Three tests (btrfs/321, generic/364 and xfs/608) refer to kernel patches
that are now in Linus' git kernel tree, so update the tests to include
the commit IDs.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

overlay: create a variant to syncfs error test xfs/546

Test overlayfs over xfs with and without "volatile" mount option.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

ext4: Regression test for corruption during on-line resize

Regression test for:
a6b3bfe176e8 ext4: fix corruption during on-line resize

Signed-off-by: Srivathsa Dara <srivathsa.d.dara@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/319: make the test work when compression is used

Currently btrfs/319 assumes there is no compression and that the files
get a single extent (1 fiemap line) with a size of 1048581 bytes. However
when testing with compression, for example by passing "-o compress" to
MOUNT_OPTIONS environment variable, we get several extents and two lines
of fiemap output, which makes the test fail since it hardcodes the fiemap
output:

  $ MOUNT_OPTIONS="-o compress" ./check btrfs/319
  FSTYP         -- btrfs
  PLATFORM      -- Linux/x86_64 debian0 6.11.0-rc6-btrfs-next-173+ #1 SMP PREEMPT_DYNAMIC Tue Sep  3 17:40:24 WEST 2024
  MKFS_OPTIONS  -- /dev/sdc
  MOUNT_OPTIONS -- -o compress /dev/sdc /home/fdmanana/btrfs-tests/scratch_1

  btrfs/319 1s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/319.out.bad)
      --- tests/btrfs/319.out 2024-08-12 14:16:55.653383284 +0100
      +++ /home/fdmanana/git/hub/xfstests/results//btrfs/319.out.bad 2024-09-05 15:24:53.323076548 +0100
      @@ -6,11 +6,13 @@
       e61178ee0288ebe3fa36a3c975b02c94  SCRATCH_MNT/snap/foo
       e61178ee0288ebe3fa36a3c975b02c94  SCRATCH_MNT/snap/bar
       File bar fiemap in the original filesystem:
      -0: [0..2055]: shared|last
      +0: [0..2047]: shared
      +1: [2048..2055]: shared|last
       Creating a new filesystem to receive the send stream...
      ...
      (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/319.out /home/fdmanana/git/hub/xfstests/results//btrfs/319.out.bad'  to see the entire diff)

  HINT: You _MAY_ be missing kernel fix:
        46a6e10a1ab1 btrfs: send: allow cloning non-aligned extent if it ends at i_size

  Ran: btrfs/319
  Failures: btrfs/319
  Failed 1 of 1 tests

So change the test to not rely on the fiemap output in its golden output
and instead just check if all the extents reported by fiemap have the
shared flag set (failing if there are any without the shared flag).

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/756: test name_to_handle_at(AT_HANDLE_MNT_ID_UNIQUE) explicitly

In order to make sure we are actually testing AT_HANDLE_MNT_ID_UNIQUE,
add a test (based on generic/426) which runs the open_by_handle in a
mode where it will error out if there is a problem with getting mount
IDs. The test is skipped if the kernel doesn't support the necessary
features.

Suggested-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

open_by_handle: verify u32 and u64 mount IDs

Now that open_by_handle_at(2) can return u64 mount IDs, do some tests to
make sure they match properly as part of the regular open_by_handle
tests. Also, add automatic tests for the old u32 mount IDs as well.

By default, we do mount ID checks but silently skip the tests if the
syscalls are not supported by the running kernel (to ensure the tests
continue to work for old kernels). We will add some tests explicitly
checking the new features (with no silent skipping) in a future patch.

The u32 mount ID tests require STATX_MNT_ID (Linux 5.8), while the u64
mount ID tests require STATX_MNT_ID_UNIQUE (Linux 6.9) and
AT_HANDLE_MNT_ID_UNIQUE (linux-next).

Link: https://lore.kernel.org/all/20240828-exportfs-u64-mount-id-v3-0-10c2c4c16708@cyphar.com/
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/362: skip test on NFS mount

xfstests complains:

FSTYP         -- nfs
PLATFORM      -- Linux/x86_64 r95b-1 5.14.0-496.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Aug 12 18:50:44 EDT 2024
MKFS_OPTIONS  -- 192.168.122.42:/nfsscratch
MOUNT_OPTIONS -- -o vers=4.2 192.168.122.42:/nfsscratch /mnt/scratch

generic/362       QA output created by 362
Failed to open/create file: Invalid argument
Silence is golden
- output mismatch (see /var/lib/xfstests/results//generic/362.out.bad)
    --- tests/generic/362.out   2024-09-02 14:27:09.162636093 -0400
    +++ /var/lib/xfstests/results//generic/362.out.bad  2024-09-02 14:33:36.167636093 -0400
    @@ -1,2 +1,3 @@
     QA output created by 362
    +Failed to open/create file: Invalid argument
     Silence is golden
    ...
    (Run 'diff -u /var/lib/xfstests/tests/generic/362.out /var/lib/xfstests/results//generic/362.out.bad'  to see the entire diff)
Ran: generic/362
Failures: generic/362
Failed 1 of 1 tests

NFS commit 9597c13b forbade open with O_APPEND|O_DIRECT

strace show that dio-append-buf-fault use (O_APPEND|O_DIRECT):

 mount -o vers=4.2 192.168.122.42:/nfstest /mnt/scratch/
 strace ./src/dio-append-buf-fault /mnt/scratch/111
..
  openat(AT_FDCWD, "/mnt/scratch/111", O_WRONLY|O_CREAT|O_TRUNC|O_APPEND|O_DIRECT, 0666) = 3

So skip generic/362 on NFS

Signed-off-by: Chen Hanxiao <chenhx.fnst@fujitsu.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic: test concurrent direct IO writes and fsync using same fd

Test that a program that has 2 threads using the same file descriptor and
concurrently doing direct IO writes and fsync doesn't trigger any crash
or deadlock.

This is motivated by a bug found in btrfs fixed by the following patch:

  "btrfs: fix race between direct IO write and fsync when using same fd"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs: functional testing for filesystem properties

Make sure that fs property storage and retrieval actually work.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common/xfs: FITRIM now supports realtime volumes

XFS now supports FITRIM to the realtime volume.  Detect this support and
enable it.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs: refactor statfs field extraction

Prepare for the next patch by refactoring the open-coded bits that call
statfs on a mounted xfs filesystem to extract a status field.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/004: fix column extraction code

Now that the xfs_db freesp command prints a CDF of the free space
histograms, fix the pct column extraction code to handle the two
new columns by <cough> using awk.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs: test xfs_scrub services

Create a pair of new tests that check that xfs_scrub and xfs_scrub_all
will find and test mounted filesystems.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/453: check xfs_scrub detection of confusing job offers

Earlier this year, ESET revealed that Linux users had been tricked into
opening executables containing malware payloads.  The trickery came in
the form of a malicious zip file containing a filename with the string
"job offer․pdf".  Note that the filename does *not* denote a real pdf
file, since the last four codepoints in the file name are "ONE DOT
LEADER", p, d, and f.  Not period (ok, FULL STOP), p, d, f like you'd
normally expect.

Now that xfs_scrub can look for codepoints that could be confused with a
period followed by alphanumerics, let's make sure it actually works.

Link: https://www.welivesecurity.com/2023/04/20/linux-malware-strengthens-links-lazarus-3cx-supply-chain-attack/
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/453: test confusable name detection with 32-bit unicode codepoints

Test the confusable name detection when there are 32-bit unicode
sequences in use.  In other words, emoji.  Change the xfs_scrub test to
dump the output to a file instead of passing huge echo commands around.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs/319: add git commit ID

The kernel patch was merged into Linus' tree, so update the 'xxxxxxxxxxxx'
stub with the respective git commit ID.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fstests: btrfs: test reading data with a corrupted checksum tree leaf

[BUG]
There is a bug report that, KASAN get triggered when:

- A read bio needs to be split
  This can happen for profiles with stripes, including
  RAID0/RAID10/RAID5/RAID6.

- An error happens before submitting the new split bio
  This includes:
  * chunk map lookup failure
  * data csum lookup failure

Then during the error path of btrfs_submit_chunk(), the original bio is
fully freed before submitted range has a chance to call its endio
function, resulting a use-after-free bug.

[NEW TEST CASE]
Introduce a new test case to verify the specific behavior by:

- Create a btrfs with enough csum leaves with data RAID0 profile
  To bump the csum tree level, use the minimal nodesize possible (4K).
  Writing 32M data which needs at least 8 leaves for data checksum

  RAID0 profile ensures the data read bios will get split.

- Find the last csum tree leave and corrupt it

- Read the data many times until we trigger the bug or exit gracefully
  With an x86_64 VM with KASAN enabled, it can trigger the KASAN report in
  just 4 iterations (the default iteration number is 32).

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fstests: btrfs/125: do not use raid5 for metadata

[BUG]
There are several bug reports of btrfs/125 failure recently, either
causing balance failure (-EIO), or even kernel crash.

The balance failure looks like this:

     Mount normal and balance
    +ERROR: error during balancing '/mnt/scratch': Input/output error
    +There may be more info in syslog - try dmesg | tail
    +md5sum: /mnt/scratch/tf2: Input/output error

The test case btrfs/125 is not reliable in the past, and has been
discussed several times:

https://lore.kernel.org/linux-btrfs/CAL3q7H4oa70DUhOFE7kot62KjxcbvvZKxu62VfLpAcmgsinBFw@mail.gmail.com/
https://lore.kernel.org/linux-btrfs/53f7bace2ac75d88ace42dd811d48b7912647301.1654672140.git.wqu@suse.com/#t

[CAUSE]
There are several different factors involved.

1. RMW mix the old and new metadata, causing unrepairable corruption
   E.g. with the following layout:

   data 1   |<- Stale metadata ->| (from the out-of-date device)
   data 2   |     Unused         |
   parity   |PPPPPPPPPPPPPPPPPPPP|

   In above case, although metadata on data 1 is out-of-date, we can
   still rebuild the correct data from parity and data 2.

   But if we have new metadata writes into the data 2 stripe, an RMW
   will screw up the whole situation:

   data 1   |<- Stale metadata ->| (from the out-of-date device)
   data 2   |<-  New metadata  ->|
   parity   |XXXXXXXXXXXXXXXXXXXX|

   The RMW will use the stale metadata and new metadata to calculate new
   parity.
   The resulted new parity will no longer be able to recover the old
   data 1.

   This is a known bug, thus our documentation is already recommending
   to avoid RAID56 for metadata usage.

   > Metadata
   >    Do not use raid5 nor raid6 for metadata. Use raid1 or raid1c3
   >    respectively.

   And this is very hard to fix, unlike data we can fetch the
   data csum and verify during RMW, we can not do that during RMW.

   At the timing of RMW, we're holding the rbio lock for the full
   stripe.
   If the extent tree search requires a read-recover, it will generate
   another rbio, which may cover the same full stripe we're working on,
   leading to a deadlock.

   Furthermore the current RAID56 repair code is all based on veritical
   sectors, but metadata can cross several horizontal sectors.
   This will require multiple combinations to repair a metadata.

2. Crash caused by double freeing a bio
   By chance if the above RMW corrupted csum tree, then during
   btrfs_submit_chunk() we will hit an error path that leads to double
   freeing of a bio, resulting crash or a KASAN report.

   Thankfully the patch fixing the use-after-free is already sent to the
   mailing list:
   https://lore.kernel.org/linux-btrfs/f4f916352ddf3f80048567ec7d8cc64cb388dc09.1724493430.git.wqu@suse.com/

[WORKAROUND]
Since it's very hard to fix the RAID56 metadata problem without a
deadlock or a huge code rework, for now just use RAID1 for the metadata
of this particular test case.

There may be a chance to fix the situation by properly marking the
missing-then-reappear device as out-of-date, so no direct read from that
device.

But that will also be a huge new feature, not something can be done
immediately.

Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic: test to run fsx eof pollution

Filesystem regressions related to partial page zeroing can go
unnoticed for a decent amount of time. A recent example is the issue
of iomap zero range not handling dirty pagecache over unwritten
extents, which leads to wrong behavior on certain file extending
operations (i.e. truncate, write extension, etc.).

fsx does occasionally uncover these sorts of problems, but failures
can be rare and/or require longer running tests outside what is
typically run via full fstests regression runs. fsx now supports a
mode that injects post-eof data in order to explicitly test partial
eof zeroing behavior. This uncovers certain problems more quickly
and applies coverage more broadly across size changing operations.

Add a new test that runs an fsx instance (modeled after generic/127)
with eof pollution mode enabled. While the test is generic, it is
currently limited to XFS as that is currently the only known major
fs that does enough zeroing to satisfy the strict semantics expected
by fsx. The long term goal is to uncover and fix issues so more
filesystems can enable this test.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fsx: support eof page pollution for eof zeroing test coverage

File ranges that are newly exposed via size changing operations are
expected to return zeroes until written to. This behavior tends to
be difficult to regression test as failures can be racy and
transient. fsx is probably the best tool for this type of test
coverage, but uncovering issues can require running for a
significantly longer period of time than is typically invoked
through fstests tests. As a result, these types of regressions tend
to go unnoticed for an unfortunate amount of time.

To facilitate uncovering these problems more quickly, implement an
eof pollution mode in fsx that opportunistically injects post-eof
data prior to operations that change file size. Since data injection
occurs immediately before the size changing operation, it can be
used to detect problems in partial eof page/block zeroing associated
with each relevant operation.

The implementation takes advantage of the fact that mapped writes
can place data beyond eof so long as the page starts within eof. The
main reason for the isolated per-operation approach (vs. something
like allowing mapped writes to write beyond eof, for example) is to
accommodate the fact that writeback zeroes post-eof data on the eof
page. The current approach is therefore not necessarily guaranteed
to detect all problems, but provides more generic and broad test
coverage than the alternative of testing explicit command sequences
and doesn't require significant changes to how fsx works. If this
proves useful long term, further enhancements can be considered that
might facilitate the presence of post-eof data across operations.

Enable the feature with the -e command line option. It is disabled
by default because zeroing behavior is inconsistent across
filesystems. This can also be revisited in the future if zeroing
behavior is refined for the major filesystems that rely on fstests
for regression testing.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fsx: factor out a file size update helper

In preparation for support for eof page pollution, factor out a file
size update helper. This updates the internally tracked file size
based on the upcoming operation and zeroes the appropriate range in
the good buffer for extending operations.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

fsx: don't skip file size and buf updates on simulated ops

fsx supports the ability to skip through a certain number of
operations of a given command sequence before beginning full
operation. The way this works is by tracking the operation count,
simulating minimal side effects of skipped operations in-memory, and
then finally writing out the in-memory state to the target file when
full operation begins.

Several fallocate() related operations don't correctly track
in-memory state when simulated, however. For example, consider an
ops file with the following two operations:

  zero_range 0x0 0x1000 0x0
  read 0x0 0x1000 0x0

... and an fsx run like so:

  fsx -d -b 2 --replay-ops=<opsfile> <file>

This simulates the zero_range operation, but fails to track the file
extension that occurs as a side effect such that the subsequent read
doesn't occur as expected:

  Will begin at operation 2
  skipping zero size read

The read is skipped in this case because the file size is zero.  The
proper behavior, and what is consistent with other size changing
operations, is to make the appropriate in-core changes before
checking whether an operation is simulated so the end result of
those changes can be reflected on-disk for eventual non-simulated
operations. This results in expected behavior with the same ops file
and test command:

  Will begin at operation 2
  2 read  0x0 thru        0xfff   (0x1000 bytes)

Update zero, copy and clone range to do the file size and EOF change
related zeroing before checking against the simulated ops count.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

f2fs/003: add missing _fixed_by_kernel_commit line

The bug related to this regression testcase has been fixed by commit
b40a2b003709 ("f2fs: use meta inode for GC of atomic file"), let's
add missing _fixed_by_kernel_commit line for this testcase.

Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

overlay: deprecate test t_truncate_self

Since kernel commit 2a010c412853 ("fs: don't block i_writecount during
exec"), truncating an executable file while it is being executed is
allowed. Therefore, the test t_truncate_self now fails, so remove it.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/615: add to the quick group

This is a simple and very quick test, add it to the quick group.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs: add a test for v1 inodes with nonzero nlink and onlink fields

Add a regression test for XFS V1 inodes that have both nlink and onlink
fields set to 1.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Zorro Lang <zlang@kernel.org>

common/config: Correctly ignore {TEST|SCRATCH}_DEV for tmpfs

As per commit 264e5358e2c2 ("tmpfs: don't require {TEST|SCRATCH}_DEV"),
tmpfs doesn't need TEST or SCRATCH devices due to being a RAM-based
filesystem.

Fix the check by comparing the content of the variable TEST_DEV, instead
of comparing with the string TEST_DEV. Same for SCRATCH_DEV.

Fixes: 264e5358e2c2 ("tmpfs: don't require {TEST|SCRATCH}_DEV")
Signed-off-by: André Almeida <andrealmeid@igalia.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic/755: test that inode's ctime is updated on unlink

I recently found and fixed a bug in btrfs where it wasn't updating the
citme on the target inode when unlinking [1]. Add a fstest for this.

[1]: https://lore.kernel.org/linux-btrfs/20240812-btrfs-unlink-v1-1-ee5c2ef538eb@kernel.org/

Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

replace _min_dio_alignment with calls to src/min_dio_alignment

Use the min_dio_alignment C tool to check the minimum alignment.
This allows using the values obtained from statx instead of just guessing
based on the sector size and page size.

For tests using the scratch device this sometimes required moving code
around a bit to ensure the scratch device is actually mounted before
querying the alignment.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

generic: don't use _min_dio_alignment without a device argument

Replace calls to _min_dio_alignment that do not provide a device to
check with calls to the feature utility to query the page size, as that
is what these calls actually do.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/424: don't use _min_dio_alignment

xfs/424 tests xfs_db and not the kernel xfs code, and really wants
the device sector size and not the minimum direct I/O alignment.

Switch to a direct call of the blockdev utility.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

add a new min_dio_alignment helper

Add a new C program to find the minimum direct I/O alignment.  This
uses the statx stx_dio_offset_align field if provided, then falls
back to the BLKSSZGET ioctl for block backed file systems and finally
the page size.  It is intended as a more capable replacement for the
_min_dio_alignment bash helper.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

statx.h: update to latest kernel UAPI

Update the localy provided statx definition to the latest kernel UAPI,
and use it unconditionally instead only if no kernel version is provided.

This allows using more recent additions than provided in the system
headers.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

btrfs: test send clones extents with unaligned end offset ending at i_size

Test that a send operation will issue a clone operation for a shared
extent of a file if the extent ends at the i_size of the file and the
i_size is not sector size aligned.

This verifies an improvement to the btrfs send feature implemented by
the following kernel patch:

  "btrfs: send: allow cloning non-aligned extent if it ends at i_size"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/348: add helper tags

This test requires a kernel patch since 3bf963a6c6 ("xfs/348: partially revert
dbcc549317"), so note that in the test.

Signed-off-by: Ma Xinjian <maxj.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/516: use _scratch_mkfs_xfs

Use _scratch_mkfs_xfs instead of _scratch_mkfs to get _notrun handling
for unsupported option combinations.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>

xfs/432: use _scratch_mkfs_xfs

Use _scratch_mkfs_xfs instead of _scratch_mkfs to get _notrun handling
for unsupported option combinations.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>