From: "Darrick J. Wong" <djwong@kernel.org>
To: "Nirjhar Roy (IBM)" <nirjhar.roy.lists@gmail.com>
Cc: fstests@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-xfs@vger.kernel.org, ritesh.list@gmail.com,
ojaswin@linux.ibm.com, zlang@kernel.org
Subject: Re: [PATCH v2] check: Fix fs specfic imports when $FSTYPE!=$OLD_FSTYPE
Date: Fri, 31 Jan 2025 08:24:57 -0800 [thread overview]
Message-ID: <20250131162457.GV1611770@frogsfrogsfrogs> (raw)
In-Reply-To: <dfbd2895-e29a-4e25-bbc6-a83826d14878@gmail.com>
On Fri, Jan 31, 2025 at 06:49:50PM +0530, Nirjhar Roy (IBM) wrote:
>
> On 1/29/25 21:32, Darrick J. Wong wrote:
> > On Wed, Jan 29, 2025 at 04:48:10PM +0530, Nirjhar Roy (IBM) wrote:
> > > On 1/28/25 23:39, Darrick J. Wong wrote:
> > > > On Tue, Jan 28, 2025 at 05:00:22AM +0000, Nirjhar Roy (IBM) wrote:
> > > > > Bug Description:
> > > > >
> > > > > _test_mount function is failing with the following error:
> > > > > ./common/rc: line 4716: _xfs_prepare_for_eio_shutdown: command not found
> > > > > check: failed to mount /dev/loop0 on /mnt1/test
> > > > >
> > > > > when the second section in local.config file is xfs and the first section
> > > > > is non-xfs.
> > > > >
> > > > > It can be easily reproduced with the following local.config file
> > > > >
> > > > > [s2]
> > > > > export FSTYP=ext4
> > > > > export TEST_DEV=/dev/loop0
> > > > > export TEST_DIR=/mnt1/test
> > > > > export SCRATCH_DEV=/dev/loop1
> > > > > export SCRATCH_MNT=/mnt1/scratch
> > > > >
> > > > > [s1]
> > > > > export FSTYP=xfs
> > > > > export TEST_DEV=/dev/loop0
> > > > > export TEST_DIR=/mnt1/test
> > > > > export SCRATCH_DEV=/dev/loop1
> > > > > export SCRATCH_MNT=/mnt1/scratch
> > > > >
> > > > > ./check selftest/001
> > > > >
> > > > > Root cause:
> > > > > When _test_mount() is executed for the second section, the FSTYPE has
> > > > > already changed but the new fs specific common/$FSTYP has not yet
> > > > > been done. Hence _xfs_prepare_for_eio_shutdown() is not found and
> > > > > the test run fails.
> > > > >
> > > > > Fix:
> > > > > Remove the additional _test_mount in check file just before ". commom/rc"
> > > > > since ". commom/rc" is already sourcing fs specific imports and doing a
> > > > > _test_mount.
> > > > >
> > > > > Fixes: 1a49022fab9b4 ("fstests: always use fail-at-unmount semantics for XFS")
> > > > > Signed-off-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
> > > > > ---
> > > > > check | 12 +++---------
> > > > > 1 file changed, 3 insertions(+), 9 deletions(-)
> > > > >
> > > > > diff --git a/check b/check
> > > > > index 607d2456..5cb4e7eb 100755
> > > > > --- a/check
> > > > > +++ b/check
> > > > > @@ -784,15 +784,9 @@ function run_section()
> > > > > status=1
> > > > > exit
> > > > > fi
> > > > > - if ! _test_mount
> > > > Don't we want to _test_mount the newly created filesystem still? But
> > > > perhaps after sourcing common/rc ?
> > > >
> > > > --D
> > > common/rc calls init_rc() in the end and init_rc() already does a
> > > _test_mount. _test_mount after sourcing common/rc will fail, won't it? Does
> > > that make sense?
> > >
> > > init_rc()
> > > {
> > > # make some further configuration checks here
> > > if [ "$TEST_DEV" = "" ]
> > > then
> > > echo "common/rc: Error: \$TEST_DEV is not set"
> > > exit 1
> > > fi
> > >
> > > # if $TEST_DEV is not mounted, mount it now as XFS
> > > if [ -z "`_fs_type $TEST_DEV`" ]
> > > then
> > > # $TEST_DEV is not mounted
> > > if ! _test_mount
> > > then
> > > echo "common/rc: retrying test device mount with external set"
> > > [ "$USE_EXTERNAL" != "yes" ] && export USE_EXTERNAL=yes
> > > if ! _test_mount
> > > then
> > > echo "common/rc: could not mount $TEST_DEV on $TEST_DIR"
> > > exit 1
> > > fi
> > > fi
> > > fi
> > > ...
> > ahahahaha yes it does.
> >
> > /commit message reading comprehension fail, sorry about that.
> >
> > Though now that you point it out, should check elide the init_rc call
> > about 12 lines down if it re-sourced common/rc ?
>
> Yes, it should. init_rc() is getting called twice when common/rc is getting
> re-sourced. Maybe I can do like
>
>
> if $RECREATE_TEST_DEV || [ "$OLD_FSTYP" != "$FSTYP" ]; then
>
> <...>
>
> . common/rc # changes in this patch
>
> <...>
>
> elif [ "$OLD_TEST_FS_MOUNT_OPTS" != "$TEST_FS_MOUNT_OPTS" ]; then
>
> ...
>
> init_rc() # explicitly adding an init_rc() for this condition
>
> else
>
> init_rc() # # explicitly adding an init_rc() for all other conditions.
> This will prevent init_rc() from getting called twice during re-sourcing
> common/rc
>
> fi
>
> What do you think?
Sounds fine as a mechanical change, but I wonder, should calling init_rc
be explicit? There are not so many places that source common/rc:
$ git grep 'common/rc'
check:362:if ! . ./common/rc; then
check:836: . common/rc
common/preamble:52: . ./common/rc
soak:7:. ./common/rc
tests/generic/749:18:. ./common/rc
(I filtered out the non-executable matches)
I think the call in generic/749 is unnecessary and I don't know what
soak does. But that means that one could insert an explicit call to
init_rc at line 366 and 837 in check and at line 53 in common/preamble,
and we can clean up one more of those places where sourcing a common/
file actually /does/ something quietly under the covers.
(Unless the maintainer is ok with the status quo...?)
--D
>
> >
> > Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
> >
> > --D
> >
> > > ...
> > >
> > > --NR
> > >
> > >
> > >
> > > > > - then
> > > > > - echo "check: failed to mount $TEST_DEV on $TEST_DIR"
> > > > > - status=1
> > > > > - exit
> > > > > - fi
> > > > > - # TEST_DEV has been recreated, previous FSTYP derived from
> > > > > - # TEST_DEV could be changed, source common/rc again with
> > > > > - # correct FSTYP to get FSTYP specific configs, e.g. common/xfs
> > > > > + # Previous FSTYP derived from TEST_DEV could be changed, source
> > > > > + # common/rc again with correct FSTYP to get FSTYP specific configs,
> > > > > + # e.g. common/xfs
> > > > > . common/rc
> > > > > _prepare_test_list
> > > > > elif [ "$OLD_TEST_FS_MOUNT_OPTS" != "$TEST_FS_MOUNT_OPTS" ]; then
> > > > > --
> > > > > 2.34.1
> > > > >
> > > > >
> > > --
> > > Nirjhar Roy
> > > Linux Kernel Developer
> > > IBM, Bangalore
> > >
> --
> Nirjhar Roy
> Linux Kernel Developer
> IBM, Bangalore
>
>
next prev parent reply other threads:[~2025-01-31 16:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 5:00 [PATCH v2] check: Fix fs specfic imports when $FSTYPE!=$OLD_FSTYPE Nirjhar Roy (IBM)
2025-01-28 18:09 ` Darrick J. Wong
2025-01-29 11:18 ` Nirjhar Roy (IBM)
2025-01-29 16:02 ` Darrick J. Wong
2025-01-31 13:19 ` Nirjhar Roy (IBM)
2025-01-31 16:24 ` Darrick J. Wong [this message]
2025-02-01 6:35 ` Zorro Lang
2025-02-06 18:02 ` Nirjhar Roy (IBM)
2025-02-10 14:23 ` Zorro Lang
2025-02-21 4:14 ` Nirjhar Roy (IBM)
2025-02-21 5:47 ` Zorro Lang
2025-02-21 5:49 ` Nirjhar Roy (IBM)
2025-02-06 5:35 ` Nirjhar Roy (IBM)
2025-02-06 15:52 ` Darrick J. Wong
2025-02-06 17:58 ` Nirjhar Roy (IBM)
2025-02-01 7:05 ` Zorro Lang
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=20250131162457.GV1611770@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=nirjhar.roy.lists@gmail.com \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=zlang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.