From: Filipe Manana <fdmanana@kernel.org>
To: Nikolay Borisov <nborisov@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v4] btrfs: improve error reporting in lookup_inline_extent_backref
Date: Thu, 28 Apr 2022 16:16:14 +0100 [thread overview]
Message-ID: <YmqvviNRmr+N8NFJ@debian9.Home> (raw)
In-Reply-To: <20220428131449.792353-1-nborisov@suse.com>
On Thu, Apr 28, 2022 at 04:14:49PM +0300, Nikolay Borisov wrote:
> When iterating the backrefs in an extent item if the ptr to the
> 'current' backref record goes beyond the extent item a warning is
> generated and -ENOENT is returned. However what's more appropriate to
> debug such cases would be to return EUCLEAN and also print identifying
> information about the performed search as well as the current content of
> the leaf containing the possibly corrupted extent item.
>
> Signed-off-by: Nikolay Borisov <nborisov@suse.com>
> ---
>
> V4:
> * Also print the value of 'parent' as it's pertinent when metadata inline backrefs
> are being searched (Filipe)
> * Print the leaf before printing the error message so that the latter is
> not lost (Filipe)
>
> V3:
> * Fixed format for the btree slot
> * Removed redundant argument passed to format string
>
> fs/btrfs/extent-tree.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 963160a0c393..cae2ef560f3f 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -895,7 +895,14 @@ int lookup_inline_extent_backref(struct btrfs_trans_handle *trans,
> err = -ENOENT;
> while (1) {
> if (ptr >= end) {
> - WARN_ON(ptr > end);
> + if (ptr > end) {
> + err = -EUCLEAN;
> + btrfs_print_leaf(path->nodes[0]);
> + btrfs_crit(fs_info,
> +"overrun extent record at slot %d [%llu BTRFS_EXTENT_ITEM_KEY %llu] while looking for inline extent for root %llu owner %llu offset %llu parent %llu",
> + path->slots[0], bytenr, num_bytes,
The key being printed is misleading, as it will often be incorrect.
First the type is not always BTRFS_EXTENT_ITEM_KEY, it can also be
BTRFS_METADATA_ITEM_KEY.
Secondly, the offset's value is not always 'num_bytes', it can also be 'owner'.
So it's better to just print the key as "%llu %u %llu" and using key.objectid,
key.type and key.offset. Or just leave the key from the message since we have
printed the slot, and therefore it's redundant. Either option is fine for me.
Sorry, I missed this before and I hate to have to make you send another version.
With that fixed,
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Thanks.
> + root_objectid, owner, offset, parent);
> + }
> break;
> }
> iref = (struct btrfs_extent_inline_ref *)ptr;
> --
> 2.25.1
>
next prev parent reply other threads:[~2022-04-28 15:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-28 13:14 [PATCH v4] btrfs: improve error reporting in lookup_inline_extent_backref Nikolay Borisov
2022-04-28 15:16 ` Filipe Manana [this message]
2022-04-28 16:39 ` Nikolay Borisov
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=YmqvviNRmr+N8NFJ@debian9.Home \
--to=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@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