linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Chandan Babu R <chandanrlinux@gmail.com>
Cc: guaneryu@gmail.com, linux-xfs@vger.kernel.org,
	fstests@vger.kernel.org, guan@eryu.me
Subject: Re: [PATCH 03/10] xfs: test rtalloc alignment and math errors
Date: Mon, 22 Mar 2021 21:15:32 -0700	[thread overview]
Message-ID: <20210323041532.GI1670408@magnolia> (raw)
In-Reply-To: <87mtvaceaf.fsf@garuda>

On Thu, Mar 11, 2021 at 01:28:32PM +0530, Chandan Babu R wrote:
> On 09 Mar 2021 at 10:10, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> >
> > Add a couple of regression tests for "xfs: make sure the rt allocator
> > doesn't run off the end" and "xfs: ensure that fpunch, fcollapse, and
> > finsert operations are aligned to rt extent size".
> >
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> >  tests/xfs/759     |  100 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  tests/xfs/759.out |    2 +
> >  tests/xfs/760     |   68 ++++++++++++++++++++++++++++++++++++
> >  tests/xfs/760.out |    9 +++++
> >  tests/xfs/group   |    2 +
> >  5 files changed, 181 insertions(+)
> >  create mode 100755 tests/xfs/759
> >  create mode 100644 tests/xfs/759.out
> >  create mode 100755 tests/xfs/760
> >  create mode 100644 tests/xfs/760.out
> >
> >
> > diff --git a/tests/xfs/759 b/tests/xfs/759
> > new file mode 100755
> > index 00000000..8558fe30
> > --- /dev/null
> > +++ b/tests/xfs/759
> > @@ -0,0 +1,100 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0-or-later
> > +# Copyright (c) 2021 Oracle.  All Rights Reserved.
> > +#
> > +# FS QA Test No. 759
> > +#
> > +# This is a regression test for commit 2a6ca4baed62 ("xfs: make sure the rt
> > +# allocator doesn't run off the end") which fixes an overflow error in the
> > +# _near realtime allocator.  If the rt bitmap ends exactly at the end of a
> > +# block and the number of rt extents is large enough to allow an allocation
> > +# request larger than the maximum extent size, it's possible that during a
> > +# large allocation request, the allocator will fail to constrain maxlen on the
> > +# second run through the loop, and the rt bitmap range check will run right off
> > +# the end of the rtbitmap file.  When this happens, xfs triggers a verifier
> > +# error and returns EFSCORRUPTED.
> > +
> > +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
> > +
> > +# real QA test starts here
> > +_supported_fs xfs
> > +_require_scratch
> > +_require_realtime
> > +_require_test_program "punch-alternating"
> > +
> > +rm -f $seqres.full
> > +
> > +# Format filesystem to get the block size
> > +_scratch_mkfs > $seqres.full
> > +_scratch_mount >> $seqres.full
> > +
> > +blksz=$(_get_block_size $SCRATCH_MNT)
> > +rextsize=$($XFS_INFO_PROG $SCRATCH_MNT | grep realtime.*extsz | sed -e 's/^.*extsz=\([0-9]*\).*$/\1/g')
> > +rextblks=$((rextsize / blksz))
> > +
> > +echo "blksz $blksz rextsize $rextsize rextblks $rextblks" >> $seqres.full
> > +
> > +_scratch_unmount
> > +
> > +# Format filesystem with a realtime volume whose size fits the following:
> > +# 1. Longer than (XFS MAXEXTLEN * blocksize) bytes.
> 
> Shouldn't the multiplier be RT extent size rather than FS block size?

No, because reproducing the bug requires a large enough allocation
request that we can't fit it all in a single data fork extent mapping
and have to call back into the allocator to get more space.  bmbt
mappings are always in units of fsblocks, not rt extents.

> > +# 2. Exactly a multiple of (NBBY * blksz * rextsize) bytes.
> 
> i.e The bits in one rt bitmap block map (NBBY * blksz * rextsize) bytes of an
> rt device. Hence to have the bitmap end at a fs block boundary the
> corresponding rt device size should be a multiple of this product. Is my
> understanding correct?

Right.

(I swear I responded to this but who knows these days...)

--D

> 
> > +
> > +rtsize1=$((2097151 * blksz))
> > +rtsize2=$((8 * blksz * rextsize))
> > +rtsize=$(( $(blockdev --getsz $SCRATCH_RTDEV) * 512 ))
> > +
> > +echo "rtsize1 $rtsize1 rtsize2 $rtsize2 rtsize $rtsize" >> $seqres.full
> > +
> > +test $rtsize -gt $rtsize1 || \
> > +	_notrun "scratch rt device too small, need $rtsize1 bytes"
> > +test $rtsize -gt $rtsize2 || \
> > +	_notrun "scratch rt device too small, need $rtsize2 bytes"
> > +
> > +rtsize=$((rtsize - (rtsize % rtsize2)))
> > +
> 
> --
> chandan

  reply	other threads:[~2021-03-23  4:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-09  4:40 [PATCHSET 00/10] fstests: test kernel regressions fixed in 5.12 Darrick J. Wong
2021-03-09  4:40 ` [PATCH 01/10] xfs: test regression in xfs_bmap_validate_extent Darrick J. Wong
2021-03-09  4:40 ` [PATCH 02/10] generic: test reflink and copy_file_range behavior with O_SYNC and FS_XFLAG_SYNC files Darrick J. Wong
2021-03-09  4:40 ` [PATCH 03/10] xfs: test rtalloc alignment and math errors Darrick J. Wong
2021-03-11  7:58   ` Chandan Babu R
2021-03-23  4:15     ` Darrick J. Wong [this message]
2021-03-25  7:52       ` Chandan Babu R
2021-03-09  4:40 ` [PATCH 04/10] xfs: test mkfs min log size calculation w/ rt volumes Darrick J. Wong
2021-03-11  9:32   ` Chandan Babu R
2021-03-14 14:51   ` Eryu Guan
2021-03-14 16:39     ` Eryu Guan
2021-03-09  4:40 ` [PATCH 05/10] common/filter: refactor quota report filtering Darrick J. Wong
2021-03-11  9:42   ` Chandan Babu R
2021-03-09  4:40 ` [PATCH 06/10] xfs: test quota softlimit warning functionality Darrick J. Wong
2021-03-11 11:10   ` Chandan Babu R
2021-03-12  4:25     ` Chandan Babu R
2021-03-09  4:40 ` [PATCH 07/10] xfs/122: fix test for xfs_attr_shortform_t conversion Darrick J. Wong
2021-03-11 12:58   ` Christoph Hellwig
2021-03-09  4:40 ` [PATCH 08/10] generic: test file writers racing with FIDEDUPERANGE Darrick J. Wong
2021-03-12  7:13   ` Chandan Babu R
2021-03-09  4:40 ` [PATCH 09/10] generic: test a deadlock in xfs_rename when whiteing out files Darrick J. Wong
2021-03-14 18:06   ` Eryu Guan
2021-03-15 16:54     ` Darrick J. Wong
2021-03-09  4:40 ` [PATCH 10/10] xfs: test delalloc quota leak when chprojid fails Darrick J. Wong
2021-03-12  8:49   ` Chandan Babu R
2021-03-14 18:07 ` [PATCHSET 00/10] fstests: test kernel regressions fixed in 5.12 Eryu Guan
2021-03-14 21:36   ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210323041532.GI1670408@magnolia \
    --to=djwong@kernel.org \
    --cc=chandanrlinux@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=guaneryu@gmail.com \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).