From: Dave Chinner <david@fromorbit.com>
To: fdmanana@kernel.org
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org,
brauner@kernel.org, Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH] common/rc: fix _try_scratch_mount() and _test_mount() when mount fails
Date: Tue, 12 Apr 2022 08:46:59 +1000 [thread overview]
Message-ID: <20220411224659.GK1609613@dread.disaster.area> (raw)
In-Reply-To: <0ab59504aef01776ab58f9f92c55e86bf1c75424.1649685964.git.fdmanana@suse.com>
On Mon, Apr 11, 2022 at 03:08:38PM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> After the recent commit 4a7b35d7a76cd9 ("common: allow to run all tests
> on idmapped mounts"), some test that use _try_scratch_mount started to
> fail. For example:
>
> $ ./check btrfs/131 btrfs/220
> FSTYP -- btrfs
> PLATFORM -- Linux/x86_64 debian9 5.17.0-rc8-btrfs-next-114 (...)
> MKFS_OPTIONS -- /dev/sdc
> MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
>
> btrfs/131 2s ... - output mismatch (see .../results//btrfs/131.out.bad)
> --- tests/btrfs/131.out 2020-06-10 19:29:03.818519162 +0100
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/131.out.bad (...)
> @@ -6,8 +6,6 @@
> Disabling free space cache and enabling free space tree
> free space tree is enabled
> Trying to mount without free space tree
> -mount failed
> -mount failed
> Mounting existing free space tree
> free space tree is enabled
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/131.out ...
> btrfs/220 7s ... - output mismatch (see .../results//btrfs/220.out.bad)
> --- tests/btrfs/220.out 2020-10-16 23:13:46.802162554 +0100
> +++ /home/fdmanana/git/hub/xfstests/results//btrfs/220.out.bad (...)
> @@ -1,2 +1,32 @@
> QA output created by 220
> +Option fragment=invalid should fail to mount
> +umount: /home/fdmanana/btrfs-tests/scratch_1: not mounted.
> +Option nologreplay should fail to mount
> +umount: /home/fdmanana/btrfs-tests/scratch_1: not mounted.
> +Option norecovery should fail to mount
> +umount: /home/fdmanana/btrfs-tests/scratch_1: not mounted.
> ...
> (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/220.out ...
> Ran: btrfs/131 btrfs/220
> Failures: btrfs/131 btrfs/220
> Failed 2 of 2 tests
>
> The reason is that if _try_scratch_mount() fails to mount the filesystem,
> we don't return the failure, instead we call _idmapped_mount(), which
> can succeed and make _try_scratch_mount() return 0 (success). The same
> happens for _test_mount(), however a quick search revealed no tests
> currently relying on the return value of _test_mount().
>
> So fix that by making _try_scratch_mount() return immediately if it gets
> a mount failure. Also do the same for _test_mount().
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
> ---
> common/rc | 8 ++++++++
> 1 file changed, 8 insertions(+)
Yup, that fixes the generic/607 failure that I just hit.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2022-04-11 22:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-11 14:08 [PATCH] common/rc: fix _try_scratch_mount() and _test_mount() when mount fails fdmanana
2022-04-11 22:37 ` Darrick J. Wong
2022-04-11 22:46 ` Dave Chinner [this message]
2022-04-13 7:01 ` Christian Brauner
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=20220411224659.GK1609613@dread.disaster.area \
--to=david@fromorbit.com \
--cc=brauner@kernel.org \
--cc=fdmanana@kernel.org \
--cc=fdmanana@suse.com \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@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