2 # SPDX-License-Identifier: GPL-2.0
3 # Copyright (c) 2018 Google, Inc. All Rights Reserved.
8 # 349fa7d6e193 ("ext4: prevent right-shifting extents beyond EXT_MAX_BLOCKS")
9 # 7d83fb14258b ("xfs: prevent creating negative-sized file via INSERT_RANGE")
12 seqres=$RESULT_DIR/$seq
13 echo "QA output created by $seq"
15 status=1 # failure is the default!
16 trap "_cleanup; exit \$status" 0 1 2 3 15
24 # get standard environment, filters and checks
28 # remove previous $seqres.full before test
31 # real QA test starts here
36 _require_xfs_io_command "falloc" "-k"
37 _require_xfs_io_command "finsert"
38 _require_xfs_io_command "truncate"
40 block_size=$(_get_file_block_size $TEST_DIR)
41 max_file_size=$(_get_max_file_size)
42 max_blocks=$((max_file_size / block_size))
43 testfile=$TEST_DIR/testfile.$seq
45 echo "# With KEEP_SIZE"
48 # Add an extent at the beginning of the file. With ext4, this is needed to
49 # reproduce the bug where the extents appear out of order later.
50 $XFS_IO_PROG -f -c "falloc 0 $((2 * block_size))" "$testfile"
52 # Add an extent just below s_maxbytes, without changing i_size (i.e. with -k).
53 # The out-of-order extents bug can't be reproduced if i_size is changed, because
54 # then the range insertion fails due to the new i_size being > s_maxbytes.
55 $XFS_IO_PROG -c "falloc -k $(( (max_blocks - 1) * $block_size )) $block_size" \
58 # Insert an extent at the beginning of the file. With the ext4 bug, this caused
59 # the logical block number of the extent just below s_maxbytes to wrap around,
60 # causing the extents to get out of order, causing corruption detected by
61 # e2fsck. With the fix, the range insertion fails with EINVAL. Though, with
62 # xfs and f2fs the insertion succeeds, resulting in extents beyond s_maxbytes,
63 # but there is no wraparound -- which is arguably okay. So we allow either
64 # behavior and just rely on fsck detecting if something went wrong.
65 $XFS_IO_PROG -c "finsert 0 $((2 * block_size))" "$testfile" &>>$seqres.full
67 # Also do the same test, but with changing i_size (i.e. without -k). The
68 # insertion should fail with EFBIG. This exposed an XFS bug where i_size + len
69 # underwent signed overflow, resulting in a negative-sized file.
70 echo "# Without KEEP_SIZE"
72 $XFS_IO_PROG -f -c "falloc 0 $((2 * block_size))" "$testfile"
73 $XFS_IO_PROG -c "falloc $(( (max_blocks - 1) * $block_size )) $block_size" \
75 $XFS_IO_PROG -c "finsert 0 $((2 * block_size))" "$testfile"