From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: 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 09:58:36 +0200 [thread overview]
Message-ID: <20200814075836.GS2026@twin.jikos.cz> (raw)
In-Reply-To: <455de733-ce1a-0c4f-19c9-6503d8bf9bca@gmx.com>
On Fri, Aug 14, 2020 at 08:54:27AM +0800, Qu Wenruo wrote:
> 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().
That sounds perfect.
next prev parent reply other threads:[~2020-08-14 7:59 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
2020-08-14 7:58 ` David Sterba [this message]
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=20200814075836.GS2026@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.com \
--cc=quwenruo.btrfs@gmx.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