All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: "Nirjhar Roy (IBM)" <nirjhar.roy.lists@gmail.com>,
	fstests@vger.kernel.org
Cc: linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org,
	ojaswin@linux.ibm.com, djwong@kernel.org, zlang@kernel.org
Subject: Re: [PATCH] check: Fix fs specfic imports when $FSTYPE!=$OLD_FSTYPE
Date: Mon, 13 Jan 2025 21:09:37 +0530	[thread overview]
Message-ID: <87frlmvi2u.fsf@gmail.com> (raw)
In-Reply-To: <1efecce4-f051-40fc-8851-e9f9c057e844@gmail.com>

"Nirjhar Roy (IBM)" <nirjhar.roy.lists@gmail.com> writes:

> On 1/13/25 01:11, Ritesh Harjani (IBM) wrote:
>> "Nirjhar Roy (IBM)" <nirjhar.roy.lists@gmail.com> writes:
>>
>>> Bug Description:
>>>
>>> _test_mount function is failing with the following error:
>>> ./common/rc: line 4716: _xfs_prepare_for_eio_shutdown: command not found

Please notice the error that you are seeing here ^^^ 

>>> 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:
>>> call _source_specific_fs $FSTYP at the correct call site of  _test_mount()
>> You should add the Fixes: tag too. Based on your description I guess
>> this should be the tag?
>>
>> Fixes: 1a49022fab9b4 ("fstests: always use fail-at-unmount semantics for XFS")

Please look into the above commit. The above patch introduced function
"_prepare_for_eio_shutdown()" in _test_mount(), which is what we are
getting the error for (for XFS i.e. _xfs_prepare_for_eio_shutdown()
command not found). Right? 

Ok, why don't revert the above commit and see if the revert fixes the
issue for you. 

https://www.kernel.org/doc/html/v4.10/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes

-ritesh

>
> Shouldn't this be the following?
>
> commit f8e4f532f18d7517430d9849bfc042305d7f7f4d (HEAD)
> Author: Lukas Czerner <lczerner@redhat.com>
> Date:   Fri Apr 4 17:18:15 2014 +1100
>
>      check: Allow to recreate TEST_DEV
>
>      Add config option RECREATE_TEST_DEV to allow to recreate file system on
>      the TEST_DEV device. Permitted values are true and false.
>
>      If RECREATE_TEST_DEV is set to true the TEST_DEV device will be
>      unmounted and FSTYP file system will be created on it. Afterwards it
>      will be mounted to TEST_DIR again with the default, or specified mount
>      options.
>
>      Also recreate the file system if FSTYP differs from the previous
>      section.
>
>>
>> I agree with today the problem was in _test_mount(), tomorrow it could
>> be _test_mkfs, hence we could source the new FSTYP config file before
>> calling _test_mkfs().
>>
>> With the fixes tag added, please feel free to add:
>>
>> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>>
>>> Signed-off-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
>>> ---
>>>   check | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/check b/check
>>> index 607d2456..8cdbb68f 100755
>>> --- a/check
>>> +++ b/check
>>> @@ -776,6 +776,7 @@ function run_section()
>>>   	if $RECREATE_TEST_DEV || [ "$OLD_FSTYP" != "$FSTYP" ]; then
>>>   		echo "RECREATING    -- $FSTYP on $TEST_DEV"
>>>   		_test_unmount 2> /dev/null
>>> +		[[ "$OLD_FSTYP" != "$FSTYP" ]] && _source_specific_fs $FSTYP
>>>   		if ! _test_mkfs >$tmp.err 2>&1
>>>   		then
>>>   			echo "our local _test_mkfs routine ..."
>>> -- 
>>> 2.34.1
>
> -- 
> Nirjhar Roy
> Linux Kernel Developer
> IBM, Bangalore

  reply	other threads:[~2025-01-13 15:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-12 15:21 [PATCH] check: Fix fs specfic imports when $FSTYPE!=$OLD_FSTYPE Nirjhar Roy (IBM)
2025-01-12 19:41 ` Ritesh Harjani
2025-01-13  5:59   ` Nirjhar Roy (IBM)
2025-01-13 15:39     ` Ritesh Harjani [this message]
2025-01-15  5:06       ` Nirjhar Roy (IBM)
2025-01-13  5:59 ` Zorro Lang
2025-01-13  8:52   ` Nirjhar Roy (IBM)
2025-01-13 13:11     ` Zorro Lang
2025-01-13 15:33       ` Ritesh Harjani
2025-01-15  5:10         ` Nirjhar Roy (IBM)
2025-01-15  5:07       ` Nirjhar Roy (IBM)

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=87frlmvi2u.fsf@gmail.com \
    --to=ritesh.list@gmail.com \
    --cc=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=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.