public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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


  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