Files
apfstests/tests/btrfs/230
T
Qu Wenruo 0e195a4ca9 btrfs: check qgroup doesn't crash when beyond limit
There is a bug that, when btrfs is beyond qgroup limit, touching a file
could crash btrfs.

Such beyond limit situation needs to be intentionally created, e.g.
writing 1GiB file, then limit the subvolume to 512 MiB.
As current qgroup works pretty well at preventing us from reaching the
limit.

This makes existing qgroup test cases unable to detect it.

The regression is introduced by commit c53e9653605d ("btrfs: qgroup:
try to flush qgroup space when we get -EDQUOT"), and the fix is
commit 6f23277a49e6 ("btrfs: qgroup: don't commit transaction when
we already hold the handle")

Link: https://bugzilla.suse.com/show_bug.cgi?id=1178634
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2021-01-17 23:11:16 +08:00

60 lines
1.3 KiB
Bash
Executable File

#! /bin/bash
# SPDX-License-Identifier: GPL-2.0
# Copyright (c) 2020 SUSE Linux Products GmbH. All Rights Reserved.
#
# FS QA Test 230
#
# Test if btrfs qgroup would crash if we're modifying the fs
# after exceeding the limit
#
seq=`basename $0`
seqres=$RESULT_DIR/$seq
echo "QA output created by $seq"
here=`pwd`
tmp=/tmp/$$
status=1 # failure is the default!
trap "_cleanup; exit \$status" 0 1 2 3 15
_cleanup()
{
cd /
rm -f $tmp.*
}
# get standard environment, filters and checks
. ./common/rc
. ./common/filter
# remove previous $seqres.full before test
rm -f $seqres.full
# real QA test starts here
_supported_fs btrfs
# Need at least 2GiB
_require_scratch_size $((2 * 1024 * 1024))
_scratch_mkfs > /dev/null 2>&1
_scratch_mount
_pwrite_byte 0xcd 0 1G $SCRATCH_MNT/file >> $seqres.full
# Make sure the data reach disk so later qgroup scan can see it
sync
$BTRFS_UTIL_PROG quota enable $SCRATCH_MNT
$BTRFS_UTIL_PROG quota rescan -w $SCRATCH_MNT >> $seqres.full
# Set the limit to just 512MiB, which is way below the existing usage
$BTRFS_UTIL_PROG qgroup limit 512M 0/5 $SCRATCH_MNT
# Touch above file, if kernel not patched, it will trigger an ASSERT()
#
# Even for patched kernel, we will still get EDQUOT error, but that
# is expected behavior.
touch $SCRATCH_MNT/file 2>&1 | _filter_scratch
# success, all done
status=0
exit