On Wed, Jun 01, 2016 at 02:35:40PM -0400, Brian Foster wrote:
> XFS had a bug in the multi-block buffer logging code that caused a NULL
> lv panic at log push time due to invalid regions being set in the buffer
> log format bitmap. This was demonstrated by modifying a multi-block
> directory buffer in a manner that only logs regions beyond the first
> FSB-sized mapping of the buffer.
>
> To recreate these conditions, this test fragments free space and
> populates several directories with enough entries to require
> discontiguous multi-block buffers. To recreate the problem, we remove
> entries from the tail end of the directory and fsync to flush the log.
>
> Note that this test causes a panic on kernels affected by the bug. As
> such, it is included in the 'dangerous' group. The bug is resolved by
> kernel commit a3916e528b91 ("xfs: fix broken multi-fsb buffer logging").
>
> Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
Thanks Brian for writing the test! It crashed my 4.7-rc1 test vm as
expected. Looks good to me overall, some minor issues inline.
> ---
> tests/xfs/399 | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> tests/xfs/399.out | 1 +
> tests/xfs/group | 1 +
> 3 files changed, 118 insertions(+)
> create mode 100755 tests/xfs/399
> create mode 100644 tests/xfs/399.out
>
> diff --git a/tests/xfs/399 b/tests/xfs/399
> new file mode 100755
> index 0000000..e652643
> --- /dev/null
> +++ b/tests/xfs/399
> @@ -0,0 +1,116 @@
> +#! /bin/bash
> +# FS QA Test No. 399
> +#
> +# Regression test for an XFS multi-block buffer logging bug.
> +#
> +# The XFS bug results in a panic when a non-contiguous multi-block buffer is
> +# mapped and logged in a particular manner, such that only regions beyond the
> +# first fsb-sized mapping are logged. The crash occurs asynchronous to
> +# transaction submission, when the associated buffer log item is pushed from the
> +# CIL (i.e., when the log is subsequently flushed).
> +#
> +#-----------------------------------------------------------------------
> +# Copyright (c) 2016 Red Hat, Inc. All Rights Reserved.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation.
> +#
> +# This program is distributed in the hope that it would be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write the Free Software Foundation,
> +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> +#-----------------------------------------------------------------------
> +#
> +
> +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.*
Please use tab for indention.
> +}
> +
> +# get standard environment, filters and checks
> +. ./common/rc
> +
> +# Modify as appropriate.
> +_supported_fs xfs
> +_supported_os Linux
> +
> +_require_scratch_nocheck # check complains about single AG fs
> +
> +rm -f $seqres.full
> +_scratch_mkfs_xfs -d size=20m -n size=64k >> $seqres.full 2>&1
Some comments about why 64k dir block size is needed would be better.
> +
> +_scratch_mount
> +
> +# Fill a source directory with many largish-named files. 1k uuid-named entries
> +# sufficiently populates a 64k directory block.
> +mkdir $SCRATCH_MNT/src
> +for i in $(seq 0 1023); do
> + touch $SCRATCH_MNT/src/`uuidgen`
Add an entry in common/config for something like UUIDGEN_PROG, and
'_require_command "$UUIDGEN_PROG" uuidgen' in the beginning of the test?
> +done
> +
> +# precreate target dirs while we still have free space for inodes
> +for i in $(seq 0 3); do
> + mkdir $SCRATCH_MNT/$i
> +done
> +
> +# consume and fragment free space
> +$XFS_IO_PROG -xc "resblks 16" $SCRATCH_MNT >> $seqres.full 2>&1
> +dd if=/dev/zero of=$SCRATCH_MNT/file bs=4k >> $seqres.full 2>&1
> +$XFS_IO_PROG -c "fsync" $SCRATCH_MNT/file >> $seqres.full 2>&1
> +size=`stat -c %s $SCRATCH_MNT/file`
> +for i in $(seq 0 8192 $size); do
> + $XFS_IO_PROG -c "fpunch $i 4k" $SCRATCH_MNT/file >> $seqres.full 2>&1
Good to have a '_require_xfs_io_command "fpunch"'.
> +done
> +
> +# Replicate the src dir several times into fragmented free space. After one or
> +# two dirs, we should have nothing but non-contiguous directory blocks.
> +for d in $(seq 0 3); do
> + for f in `ls -1 $SCRATCH_MNT/src`; do
> + ln $SCRATCH_MNT/src/$f $SCRATCH_MNT/$d/$f
> + done
> +done
> +
> +# Fragment the target dirs a bit. Remove a handful of entries from each to
> +# populate the best free space regions in the directory block headers. We want
> +# to populate these now so the subsequent unlinks have no reason to log the
> +# first block of the directory.
> +for d in $(seq 0 3); do
> + i=0
> + for f in `ls -U $SCRATCH_MNT/$d`; do
> + if [ $i == 0 ]; then
> + unlink $SCRATCH_MNT/$d/$f
> + fi
> + i=$(((i + 1) % 128))
> + done
> +done
> +
> +_scratch_unmount
> +_scratch_mount
We have a new helper to do this now, _scratch_cycle_mount.
And it's good to see some comments about the unmount/mount cycle.
> +
> +# Unlink an entry towards the end of each dir and fsync. The unlink should only
> +# need to log the latter mappings of the 64k directory block. If the logging bug
> +# is present, this will crash!
> +for d in $(seq 0 3); do
> + f=`ls -U $SCRATCH_MNT/$d | tail -10 | head -n 1`
> + unlink $SCRATCH_MNT/$d/$f
> + $XFS_IO_PROG -c fsync $SCRATCH_MNT/$d
> +done
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/xfs/399.out b/tests/xfs/399.out
> new file mode 100644
> index 0000000..955261f
> --- /dev/null
> +++ b/tests/xfs/399.out
> @@ -0,0 +1 @@
> +QA output created by 399
Need "Silence is golden" to indicate no other outputs are expected.
> diff --git a/tests/xfs/group b/tests/xfs/group
> index f4c6816..960cc3b 100644
> --- a/tests/xfs/group
> +++ b/tests/xfs/group
> @@ -285,3 +285,4 @@
> 303 auto quick quota
> 304 auto quick quota
> 305 auto quota
> +399 auto dangerous
It crashed my kernel very quickly, I guess 'quick' group makes sense
here (but I didn't test it). As well as 'rw' group.
Thanks,
Eryu
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
