From: "xuyang2018.jy@fujitsu.com" <xuyang2018.jy@fujitsu.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: "fstests@vger.kernel.org" <fstests@vger.kernel.org>
Subject: Re: [PATCH v2] xfs/126: Add a getxattr opeartion after corrupted xattr
Date: Thu, 6 Jan 2022 01:41:17 +0000 [thread overview]
Message-ID: <61D648E5.3010209@fujitsu.com> (raw)
In-Reply-To: <20211126232817.GA266000@magnolia>
on 2021/11/27 7:28, Darrick J. Wong wrote:
> On Thu, Nov 25, 2021 at 01:13:27PM +0800, Yang Xu wrote:
>> It is design to reproduce a deadlock on upstream kernel. It is introduced by kernel
>> commit 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") and fixed by kernel
>> commit a1de97fe296c ("xfs: Fix the free logic of state in xfs_attr_node_hasname")[1].
>>
>> [1]https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/commit/?h=for-next&id=a1de97fe296c
>
> NAK, this is a general fuzz test. Please create a separate targeted
> regression test for the kernel bugfix so that you can control exactly
> which part of the attr leaf block gets corrupted so that the verifier
> will signal error.
Sorry for the late reply.
IMO, getattr or setattr should all report metadata corrupt in
dmesg(command fail)after the attr leaf block gets corrupted.
I think it should be a common part, not only for this case also for
other attr corrupt case ie xfs/125. We should add getattr for them after
attr corrupt to avoid similar problem occurs other places.
what do you think about this?
ps: I should update my commit message for this.
Best Regards
Yang Xu
>
> --D
>
>>
>> Signed-off-by: Yang Xu<xuyang2018.jy@fujitsu.com>
>> ---
>> tests/xfs/126 | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/tests/xfs/126 b/tests/xfs/126
>> index c3a74b1c..5496f3d7 100755
>> --- a/tests/xfs/126
>> +++ b/tests/xfs/126
>> @@ -7,6 +7,10 @@
>> # Create and populate an XFS filesystem, corrupt a leaf xattr's data extent,
>> # then see how the kernel and xfs_repair deal with it.
>> #
>> +# It is also a regression test for kernel commit:
>> +# a1de97fe296c ("xfs: Fix the free logic of state in xfs_attr_node_hasname")
>> +#
>> +
>> . ./common/preamble
>> _begin_fstest fuzzers
>>
>> @@ -69,7 +73,7 @@ done
>>
>> echo "+ mount image&& modify xattr"
>> if _try_scratch_mount>> $seqres.full 2>&1; then
>> -
>> + getfattr "${SCRATCH_MNT}/attrfile" -n "user.x00000000" 2> /dev/null&& _fail "got corrupt xattr"
>> setfattr -x "user.x00000000" "${SCRATCH_MNT}/attrfile" 2> /dev/null&& _fail "modified corrupt xattr"
>> umount "${SCRATCH_MNT}"
>> fi
>> --
>> 2.23.0
>>
next prev parent reply other threads:[~2022-01-06 1:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-25 5:13 [PATCH v2] xfs/126: Add a getxattr opeartion after corrupted xattr Yang Xu
2021-11-26 23:28 ` Darrick J. Wong
2022-01-06 1:41 ` xuyang2018.jy [this message]
2022-01-17 8:22 ` [PATCH v3] xfs/12[4-6]: Add getfattr operation after xattr corrupted Yang Xu
2022-01-23 13:09 ` Eryu Guan
2022-01-27 3:02 ` xuyang2018.jy
2022-01-27 4:59 ` Zorro Lang
2022-01-30 2:44 ` 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=61D648E5.3010209@fujitsu.com \
--to=xuyang2018.jy@fujitsu.com \
--cc=djwong@kernel.org \
--cc=fstests@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 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.