All of lore.kernel.org
 help / color / mirror / Atom feed
From: "xuyang2018.jy@fujitsu.com" <xuyang2018.jy@fujitsu.com>
To: Zorro Lang <zlang@redhat.com>
Cc: "fstests@vger.kernel.org" <fstests@vger.kernel.org>
Subject: Re: [PATCH 2/2] xfs/082: Add xfs_db get value regression test
Date: Tue, 5 Jul 2022 07:23:36 +0000	[thread overview]
Message-ID: <62C3F53E.2050302@fujitsu.com> (raw)
In-Reply-To: <20220704175706.lzquvtzgzv3zv7q4@zlang-mailbox>

on 2022/07/05 1:57, Zorro Lang wrote:
> On Mon, Jun 27, 2022 at 10:30:03PM +0800, Yang Xu wrote:
>> This case is a regression test for xfsprogs commit
>> f4afdcb0a ("xfs_db: clean up the salvage read callsites in set_cur()").
>>
>> I found this because xfs/270 on older xfsprogs can hit this bug.
>> The code is pasted from xfs/270 but remove mount rw/ro test.
>>
>> Signed-off-by: Yang Xu<xuyang2018.jy@fujitsu.com>
>> ---
>>   tests/xfs/082     | 67 +++++++++++++++++++++++++++++++++++++++++++++++
>>   tests/xfs/082.out |  2 ++
>>   2 files changed, 69 insertions(+)
>>   create mode 100755 tests/xfs/082
>>   create mode 100644 tests/xfs/082.out
>>
>> diff --git a/tests/xfs/082 b/tests/xfs/082
>> new file mode 100755
>> index 00000000..7a5ece8f
>> --- /dev/null
>> +++ b/tests/xfs/082
>> @@ -0,0 +1,67 @@
>> +#! /bin/bash
>> +# SPDX-License-Identifier: GPL-2.0
>> +# Copyright (c) 2022 FUJITSU LIMITED. All rights reserved.
>> +#
>> +# FS QA Test 082
>> +#
>> +# Today xfs_db set_cur whether clean up the LIBXFS_READBUF_SALVAGE
>> +# call sites so that we use the return value directly instead of
>> +# scraping it out later.
>> +#
>> +# It is a regression test for xfsprogs
>> +# f4afdcb0a ("xfs_db: clean up the salvage read callsites in set_cur()").
>> +#
>> +
>> +. ./common/preamble
>> +_begin_fstest auto quick mount
>> +
>> +# Import common functions.
>> +. ./common/filter
>> +
>> +# real QA test starts here
>> +_supported_fs xfs
>> +# skip fs check because superblock contains unknown ro-compat features
>> +_require_scratch_nocheck
>> +# Only V5 XFS disallow rw mount/remount with unknown ro-compat features
>> +_require_scratch_xfs_crc
>> +
>> +_scratch_mkfs_xfs>>$seqres.full 2>&1
>> +
>> +# set the highest bit of features_ro_compat, use it as an unknown
>> +# feature bit. If one day this bit become known feature, please
>> +# change this case.
>> +
>> +ro_compat=$(_scratch_xfs_get_metadata_field "features_ro_compat" "sb 0")
>> +echo $ro_compat | grep -q -E '^0x[[:xdigit:]]$'
>> +if [[ $? != 0  ]]; then
>> +	echo "features_ro_compat has an invalid value."
>> +fi
>> +
>> +ro_compat=$(echo $ro_compat | \
>> +		    awk '/^0x[[:xdigit:]]+/ {
>> +				printf("0x%x\n", or(strtonum($1), 0x80000000))
>> +			}')
>> +
>> +# write the new ro compat field to the superblock
>> +_scratch_xfs_set_metadata_field "features_ro_compat" "$ro_compat" "sb 0" \
>> +				>  $seqres.full 2>&1
>> +
>> +# read the newly set ro compat filed for verification
>> +new_ro_compat=$(_scratch_xfs_get_metadata_field "features_ro_compat" "sb 0" \
>> +					>$seqres.full 2>&1)
>
> Hi,
>
> Although you hit this issue by xfs/270, but that doesn't mean you need to do the
> same complicated calculation.
>
> You nearly can corrupt many fields to trigger that xfs_db bug, due to
> you don't need to test xfs mount. For example corrupt the features_ro_compat
> simply:
>
>    # xfs_db -x -c "sb 0" -c "write -d features_ro_compat 0x80000000" /dev/sda3
>    Allowing write of corrupted data with good CRC
>    features_ro_compat = 0x80000000
>    # xfs_db -c "sb 0" -c "print features_ro_compat" /dev/sda3
>    Superblock has unknown read-only compatible features (0x80000000) enabled.
>    Attempted to mount read-only compatible filesystem read-write.
>    Filesystem can only be safely mounted read only.
>    no current type
>    cache_purge: shake on cache 0x562ed6463a70 left 1 nodes!?
>    cache_purge: shake on cache 0x562ed6463a70 left 1 nodes!?
>    cache_zero_check: refcount is 1, not zero (node=0x562ed6478110)
>
> Or even corrupt the sb magicnum (sb 0 need -F) directly:
>
>    # xfs_db -x -c "sb 1" -c "write -d magicnum 0" /dev/sda3
>    Allowing write of corrupted data and bad CRC
>    magicnum = 0
>    # xfs_db -c "sb 1" -c "print magicnum" /dev/sda3
>    bad magic number
>    no current type
>    cache_purge: shake on cache 0x5589a86a9a70 left 1 nodes!?
>    cache_purge: shake on cache 0x5589a86a9a70 left 1 nodes!?
>    cache_zero_check: refcount is 1, not zero (node=0x5589a86be110)

I think corrputing sb 1 magic number is ok. Will use it on v2. Thanks.

>
> Or choose other fields you feel good.


>
>> +
>> +# verify the new ro_compat field is empty
>> +# Without xfsprog patch, xfs_db set_cur function doesn't return directly when
>> +# meeting error by using LIBXFS_READBUF_SALVAGE flag. So cache_purge will complain
>> +# about this.
>> +if [ -z $new_ro_compat ]; then
>> +	grep -q "cache_purge: shake on cache" $seqres.full&&  \
>> +		echo "Hit xfsprogs set_cur bug"
>> +	echo "Unable to get new ro compat filed"
>
> Let those "cache_purge ..." things break golden image (.out2 file) directly.

Yes.

Best Regard
Yang Xu
>
>> +fi
>> +
>> +echo "Silence is golden."
>> +
>> +# success, all done
>> +status=0
>> +exit
>> diff --git a/tests/xfs/082.out b/tests/xfs/082.out
>> new file mode 100644
>> index 00000000..6ed56cb1
>> --- /dev/null
>> +++ b/tests/xfs/082.out
>> @@ -0,0 +1,2 @@
>> +QA output created by 082
>> +Silence is golden.
>> --
>> 2.27.0
>>
>

  reply	other threads:[~2022-07-05  7:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 14:30 [PATCH 1/2] xfs/270: only check new_ro_compat value when mkfs.xfs supports nrext64 feature Yang Xu
2022-06-27 14:30 ` [PATCH 2/2] xfs/082: Add xfs_db get value regression test Yang Xu
2022-07-04 17:57   ` Zorro Lang
2022-07-05  7:23     ` xuyang2018.jy [this message]
2022-07-04  9:43 ` [PATCH 1/2] xfs/270: only check new_ro_compat value when mkfs.xfs supports nrext64 feature xuyang2018.jy
2022-07-04 15:42 ` Zorro Lang
2022-07-05  5:46   ` xuyang2018.jy

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=62C3F53E.2050302@fujitsu.com \
    --to=xuyang2018.jy@fujitsu.com \
    --cc=fstests@vger.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 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.