From: "Nirjhar Roy (IBM)" <nirjhar.roy.lists@gmail.com>
To: Zorro Lang <zlang@redhat.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
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, 21 Feb 2025 11:19:41 +0530 [thread overview]
Message-ID: <b8dcd75a-ba05-40c7-adb4-862e594f9b70@gmail.com> (raw)
In-Reply-To: <20250221054737.owarnxetb34gdicf@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>
On 2/21/25 11:17, Zorro Lang wrote:
> On Fri, Feb 21, 2025 at 09:44:19AM +0530, Nirjhar Roy (IBM) wrote:
>> On 2/10/25 19:53, Zorro Lang wrote:
>>> On Thu, Feb 06, 2025 at 11:32:43PM +0530, Nirjhar Roy (IBM) wrote:
>>>> On 2/1/25 12:05, Zorro Lang wrote:
>>>>> On Fri, Jan 31, 2025 at 08:24:57AM -0800, Darrick J. Wong wrote:
>>>>>> 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...?)
>>>>> I think people just hope to import the helpers in common/rc mostly, don't
>>>>> want to run init_rc again. Maybe we can make sure the init_rc is only run
>>>>> once each time?
>>>>>
>>>>> E.g.
>>>>>
>>>>> if [ _INIT_RC != "done" ];then
>>>>> init_rc
>>>>> _INIT_RC="done"
>>>>> fi
>>>>>
>>>>> Or any better idea.
>>>> Yes, this idea looks good too. However, after thinking a bit more, I like
>>>> Darrick's idea to remove the call to init_rc from common/rc and explicitly
>>>> calling them explicitly whenever necessary makes more sense. This also makes
>>>> the interface/reason to source common/rc more meaningful, and also not
>>>> making common/rc do something via init_rc silently. What do you think?
>>> Sorry I'm on a travel, reply you late. I don't like to run codes in include
>>> files either :) If we remove the init_rc calling from common/rc we might
>>> need to do 2 things:
>>> 1) xfstests/check needs to run init_rc, calls it in check properly.
>>> 2) Now each sub-cases run init_rc when they import common/rc, I think
>>> we can call init_rc in common/preamble:_begin_fstest().
>> Sorry for my delayed reply, I got caught up with some other work items.
>> Thank you for your above suggestions. Let me go through them, look for some
>> edge cases and I can come up with a patch after some proper testing.
> No problem :) I just suggested, but the thing is we must figure out which
> ". common/rc" hopes to run init_rc, and which not :) Thanks for looking
> into it and test it.
Yes, I will look into this. Thank you.
--NR
>
>> Regards,
>>
>> --NR
>>
>>> If I miss other things, please feel free to remind me:)
>>>
>>> Thanks,
>>> Zorro
>>>
>>>> --NR
>>>>
>>>>> Thanks,
>>>>> Zorro
>>>>>
>>>>>> --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
>>>>>>>
>>>>>>>
>>>> --
>>>> Nirjhar Roy
>>>> Linux Kernel Developer
>>>> IBM, Bangalore
>>>>
>> --
>> Nirjhar Roy
>> Linux Kernel Developer
>> IBM, Bangalore
>>
--
Nirjhar Roy
Linux Kernel Developer
IBM, Bangalore
next prev parent reply other threads:[~2025-02-21 5:49 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
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) [this message]
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=b8dcd75a-ba05-40c7-adb4-862e594f9b70@gmail.com \
--to=nirjhar.roy.lists@gmail.com \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=zlang@kernel.org \
--cc=zlang@redhat.com \
/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