On Fri, Feb 22, 2013 at 02:59:29PM +0800, Eryu Guan wrote: > Write to the last block of a sparse file in extent format on ext4 would > hit BUG_ON() on unpatched kernel. > > Regression test for commit: > f17722f ext4: Fix max file size and logical block counting of extent format file > > Signed-off-by: Eryu Guan <eguan@xxxxxxxxxx> > --- > > Note that the second dd could triger a BUG_ON() on ext4/3.8 kernel in > ext4_es_remove_extent(). > > I sent a patch for this issue, please see > http://www.spinics.net/lists/linux-ext4/msg36784.html > > 299 | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 299.out | 1 + > group | 1 + > 3 files changed, 64 insertions(+) > create mode 100644 299 > create mode 100644 299.out > > diff --git a/299 b/299 > new file mode 100644 > index 0000000..9b52243 > --- /dev/null > +++ b/299 > @@ -0,0 +1,62 @@ > +#! /bin/bash > +# FS QA Test No. 299 > +# > +# Write to the last block of a sparse file in extent format on ext4 would > +# hit BUG_ON() on unpatched kernel. > +# > +# Regression test for commit: > +# f17722f ext4: Fix max file size and logical block counting of extent format file > +# > +#----------------------------------------------------------------------- > +# Copyright (c) 2013 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 > +#----------------------------------------------------------------------- > +# > +# creator > +owner=eguan@xxxxxxxxxx > + > +seq=`basename $0` > +echo "QA output created by $seq" > + > +status=1 # failure is the default! > +trap "_cleanup; exit \$status" 0 1 2 3 15 > + > +_cleanup() > +{ > + cd / > + rm -f $testfile > +} > + > +# get standard environment, filters and checks > +. ./common.rc > +. ./common.filter > + > +testfile=$TEST_DIR/testfile.$seq > + > +# real QA test starts here > +_supported_fs generic > +_supported_os Linux > + > +block_size=`stat -f $TEST_DEV | grep "Block size" | cut -d " " -f3` stat -f -c %s > +# Create sparse file > +dd if=/dev/zero of=$testfile bs=$block_size count=1 seek=$((2**32 - 2)) >/dev/null 2>&1 > +sync > +# Write to the last block > +dd if=/dev/zero of=$testfile bs=$block_size count=1 seek=$((2**32 - 1)) >/dev/null 2>&1 That doesn't write to the last block - that writes one block beyond the EOF. And it also truncates the file first, so what is triggering the bug? the truncate of the previous file, or the writing of the file? If it is writing of the file, then what's the point of the first write? Also, I'd prefer that xfs_io is used instead of dd because then the operations being performed are explicit. i.e, the above it this: offset=$(((2**32 - 2) * $block_size)) XFS_IO_PROG -f -c "pwrite $offset $block_size" \ -c fsync $testfile | filter_io XFS_IO_PROG -f -c "truncate 0" \ -c "pwrite $((offset + $block_size)) $block_size" \ -c fsync $testfile | filter_io And it's not clear from either the test of the comments which of the 3 operations is actaully the one that causes the bug to be triggered.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
