public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz, Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org, Nikolay Borisov <nborisov@suse.com>,
	Josef Bacik <josef@toxicpanda.com>
Subject: Re: [PATCH v4 4/4] btrfs: ctree: Checking key orders before merged tree blocks
Date: Fri, 14 Aug 2020 08:54:27 +0800	[thread overview]
Message-ID: <455de733-ce1a-0c4f-19c9-6503d8bf9bca@gmx.com> (raw)
In-Reply-To: <20200813142121.GJ2026@twin.jikos.cz>



On 2020/8/13 下午10:21, David Sterba wrote:
> On Wed, Aug 12, 2020 at 02:05:09PM +0800, Qu Wenruo wrote:
[...]
>> ---
>>  fs/btrfs/ctree.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 68 insertions(+)
>>
>> diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
>> index 70e49d8d4f6c..497abb397ea1 100644
>> --- a/fs/btrfs/ctree.c
>> +++ b/fs/btrfs/ctree.c
>> @@ -3159,6 +3159,52 @@ void btrfs_set_item_key_safe(struct btrfs_fs_info *fs_info,
>>  		fixup_low_keys(path, &disk_key, 1);
>>  }
>>
>> +/*
>> + * Check the cross tree block key ordering.
>> + *
>> + * Tree-checker only works inside one tree block, thus the following
>> + * corruption can not be rejected by tree-checker:
>> + * Leaf @left			| Leaf @right
>> + * --------------------------------------------------------------
>> + * | 1 | 2 | 3 | 4 | 5 | f6 |   | 7 | 8 |
>> + *
>> + * Key f6 in leaf @left itself is valid, but not valid when the next
>> + * key in leaf @right is 7.
>> + * This can only be checked at tree block merge time.
>> + * And since tree checker has ensured all key order in each tree block
>> + * is correct, we only need to bother the last key of @left and the first
>> + * key of @right.
>> + */
>> +static bool valid_cross_tree_key_order(struct extent_buffer *left,
>> +				       struct extent_buffer *right)
>
> I think this naming is confusing, my first thought was that keys from
> two trees were being checked, but this is for two leaves in the same
> tree.
>
> The arguments should be constified.
>
> Elsewhere we use a check_<something> naming scheme with return value
> true - problem, and 0/false - all ok. The 'valid' is the reverse and
> also not following the scheme.

Any good candidate?

My current top list candidate is, check_sibling_keys().

Thanks,
Qu

>
>> +{
>> +	struct btrfs_key left_last;
>> +	struct btrfs_key right_first;
>> +	int level = btrfs_header_level(left);
>> +	int nr_left = btrfs_header_nritems(left);
>> +	int nr_right = btrfs_header_nritems(right);
>> +
>> +	/* No key to check in one of the tree blocks */
>> +	if (!nr_left || !nr_right)
>> +		return true;
>> +	if (level) {
>
> You don't need a temporary variable for one-time use, btrfs_header_level
> is understandable here.
>

  reply	other threads:[~2020-08-14  0:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-12  6:05 [PATCH v4 0/4] btrfs: Enhanced runtime defence against fuzzed images Qu Wenruo
2020-08-12  6:05 ` [PATCH v4 1/4] btrfs: extent_io: Do extra check for extent buffer read write functions Qu Wenruo
2020-08-13 14:05   ` David Sterba
2020-08-14  0:47     ` Qu Wenruo
2020-08-14 10:29       ` David Sterba
2020-08-12  6:05 ` [PATCH v4 2/4] btrfs: extent-tree: Kill BUG_ON() in __btrfs_free_extent() and do better comment Qu Wenruo
2020-08-13 14:10   ` David Sterba
2020-08-14  0:52     ` Qu Wenruo
2020-08-14  8:01       ` David Sterba
2020-08-14  8:07         ` Qu Wenruo
2020-08-12  6:05 ` [PATCH v4 3/4] btrfs: extent-tree: Kill the BUG_ON() in insert_inline_extent_backref() Qu Wenruo
2020-08-12  6:05 ` [PATCH v4 4/4] btrfs: ctree: Checking key orders before merged tree blocks Qu Wenruo
2020-08-13 14:21   ` David Sterba
2020-08-14  0:54     ` Qu Wenruo [this message]
2020-08-14  7:58       ` David Sterba
2020-08-12  6:52 ` [PATCH v4 0/4] btrfs: Enhanced runtime defence against fuzzed images David Sterba

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=455de733-ce1a-0c4f-19c9-6503d8bf9bca@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=dsterba@suse.cz \
    --cc=josef@toxicpanda.com \
    --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