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.
>
next prev parent 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