linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Nikolay Borisov <nborisov@suse.com>, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH v2] fstests: btrfs/244: add test case to verify the behavior of deleting non-existing device
Date: Fri, 6 Aug 2021 20:15:21 +0800	[thread overview]
Message-ID: <2760b7ed-d216-1d5c-e73d-1569ac4c702d@gmx.com> (raw)
In-Reply-To: <5547039c-2989-e9d7-6126-15877758b3f0@suse.com>



On 2021/8/6 下午7:42, Nikolay Borisov wrote:
>
>
> On 6.08.21 г. 14:33, Qu Wenruo wrote:
>> There is a kernel regression for btrfs, that when passing non-existing
>> devid to "btrfs device remove" command, kernel will crash due to NULL
>> pointer dereference.
>>
>> The test case is for such regression, it will:
>>
>> - Create and mount an empty single-device btrfs
>> - Try to remove devid 3, which doesn't exist for above fs
>> - Make sure the command exits properly with expected error message
>>
>> The kernel fix is titled "btrfs: fix NULL pointer dereference when
>> deleting device by invalid id".
>>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>> Changelog:
>> v2:
>> - Change the subject to also verify the error behavior
>> - Include the error message into golden output
>> - Also verify the return value of btrfs command
>> ---
>>   tests/btrfs/244     | 47 +++++++++++++++++++++++++++++++++++++++++++++
>>   tests/btrfs/244.out |  2 ++
>>   2 files changed, 49 insertions(+)
>>   create mode 100755 tests/btrfs/244
>>   create mode 100644 tests/btrfs/244.out
>>
>> diff --git a/tests/btrfs/244 b/tests/btrfs/244
>> new file mode 100755
>> index 00000000..fbefeedf
>> --- /dev/null
>> +++ b/tests/btrfs/244
>> @@ -0,0 +1,47 @@
>> +#! /bin/bash
>> +# SPDX-License-Identifier: GPL-2.0
>> +# Copyright (c) 2021 SUSE Linux Products GmbH.  All Rights Reserved.
>> +#
>> +# FS QA Test 244
>> +#
>> +# Make sure "btrfs device remove" won't crash when non-existing devid
>> +# is provided
>> +#
>> +. ./common/preamble
>> +_begin_fstest auto quick volume dangerous
>> +
>> +# Override the default cleanup function.
>> +# _cleanup()
>> +# {
>> +# 	cd /
>> +# 	rm -r -f $tmp.*
>> +# }
>> +
>> +# Import common functions.
>> +# . ./common/filter
>> +
>> +# real QA test starts here
>> +
>> +# Modify as appropriate.
>> +_supported_fs btrfs
>> +_require_scratch
>> +
>> +_scratch_mkfs >> $seqres.full 2>&1
>> +_scratch_mount
>> +
>> +# Above created fs only contains one device with devid 1, device remove 3
>> +# should just fail with proper error message showing devid 3 can't be found.
>> +# Although on unpatched kernel, this will trigger a NULL pointer dereference.
>> +$BTRFS_UTIL_PROG device remove 3 $SCRATCH_MNT
>> +ret=$?
>> +
>> +if [ $ret -ne 1 ]; then
>> +	echo "Unexpected return value from btrfs command, has $ret expected 1"
>> +fi
>
> <rant>
> This just shows how broken progs are w.r.t return values. The generally
> accepted return value is 0 on success, yet it returns 1 on success since
> the functions implementing this functionality in progs treat the return
> value as a boolean.
> </rant>


Nope, we're testing a failure case, thus returning 1 is what we expect.

Thanks,
Qu
>
>
>
>> +
>> +# Fstests will automatically check the filesystem to make sure metadata is not
>> +# corrupted.
>> +
>> +# success, all done
>> +status=0
>> +exit
>> diff --git a/tests/btrfs/244.out b/tests/btrfs/244.out
>> new file mode 100644
>> index 00000000..629adf2a
>> --- /dev/null
>> +++ b/tests/btrfs/244.out
>> @@ -0,0 +1,2 @@
>> +QA output created by 244
>> +ERROR: error removing devid 3: No such file or directory
>>

  reply	other threads:[~2021-08-06 12:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06 11:33 [PATCH v2] fstests: btrfs/244: add test case to verify the behavior of deleting non-existing device Qu Wenruo
2021-08-06 11:42 ` Nikolay Borisov
2021-08-06 12:15   ` Qu Wenruo [this message]
2021-08-10 14:04   ` David Sterba
2021-08-06 15:48 ` Filipe Manana

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=2760b7ed-d216-1d5c-e73d-1569ac4c702d@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=wqu@suse.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;
as well as URLs for NNTP newsgroup(s).