From: Filipe Manana <fdmanana@kernel.org>
To: Josef Bacik <josef@toxicpanda.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v2] btrfs: set start on clone before calling copy_extent_buffer_full
Date: Mon, 15 Apr 2024 12:33:45 +0100 [thread overview]
Message-ID: <CAL3q7H7XjBHGkz68PW9oqXKMaU5EN+jshBAZ5ndgqk5RgEDhdw@mail.gmail.com> (raw)
In-Reply-To: <cbf5bf79edc537544f383ee3d6c79a1bec45a964.1713100883.git.josef@toxicpanda.com>
On Sun, Apr 14, 2024 at 2:22 PM Josef Bacik <josef@toxicpanda.com> wrote:
>
> Our subpage testing started hanging on generic/560 and I bisected it
> down to 1cab1375ba6d ("btrfs: reuse cloned extent buffer during
> fiemap to avoid re-allocations"). This is subtle because we use
> eb->start to figure out where in the folio we're copying to when we're
> subpage, as our ->start may refer to an area inside of the folio.
>
> For example, assume a 16k page size machine with a 4k node size, and
> assume that we already have a cloned extent buffer when we cloned the
> previous search.
>
> copy_extent_buffer_full() will do the following when copying the extent
> buffer path->nodes[0] (src) into cloned (dest):
>
> src->start = 8k; // this is the new leaf we're cloning
> cloned->start = 4k; // this is left over from the previous clone
>
> src_addr = folio_address(src->folios[0]);
> dest_addr = folio_address(dest->folios[0]);
>
> memcpy(dest_addr + get_eb_offset_in_folio(dst, 0),
> src_addr + get_eb_offset_in_folio(src, 0), src->len);
>
> Now get_eb_offset_in_folio() is where the problems occur, because for
> sub-pagesize blocksize we can have multiple eb's per folio, the code for
> this is as follows
>
> size_t get_eb_offset_in_folio(eb, offset) {
> return (eb->start + offset & (folio_size(eb->folio[0]) - 1));
> }
>
> So in the above example we are copying into offset 4k inside the folio.
> However once we update cloned->start to 8k to match the src the math for
> get_eb_offset_in_folio() changes, and any subsequent reads (ie
> btrfs_item_key_to_cpu()) will start reading from the offset 8k instead
> of 4k where we copied to, giving us garbage.
>
> Fix this by setting start before we co copy_extent_buffer_full() to make
> sure that we're copying into the same offset inside of the folio that we
> will read from later.
>
> All other sites of copy_extent_buffer_full() are correct because we
> either set ->start beforehand or we simply don't change it in the case
> of the tree-log usage.
>
> With this fix we now pass generic/560 on our subpage tests.
>
> Fixes: 1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations")
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Now this change log is informative and helpful. Thanks for the update.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
> ---
> fs/btrfs/extent_io.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index 49f7161a6578..a59cd88cf318 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -2809,13 +2809,19 @@ static int fiemap_next_leaf_item(struct btrfs_inode *inode, struct btrfs_path *p
> goto out;
> }
>
> - /* See the comment at fiemap_search_slot() about why we clone. */
> - copy_extent_buffer_full(clone, path->nodes[0]);
> /*
> * Important to preserve the start field, for the optimizations when
> * checking if extents are shared (see extent_fiemap()).
> + *
> + * We must set ->start before calling copy_extent_buffer_full(). If we
> + * are on sub-pagesize blocksize, we use ->start to determine the offset
> + * into the folio where our eb exists, and if we update ->start after
> + * the fact then any subsequent reads of the eb may read from a
> + * different offset in the folio than where we originally copied into.
> */
> clone->start = path->nodes[0]->start;
> + /* See the comment at fiemap_search_slot() about why we clone. */
> + copy_extent_buffer_full(clone, path->nodes[0]);
>
> slot = path->slots[0];
> btrfs_release_path(path);
> --
> 2.43.0
>
>
prev parent reply other threads:[~2024-04-15 11:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-14 13:22 [PATCH v2] btrfs: set start on clone before calling copy_extent_buffer_full Josef Bacik
2024-04-15 0:04 ` Qu Wenruo
2024-04-15 11:33 ` Filipe Manana [this message]
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=CAL3q7H7XjBHGkz68PW9oqXKMaU5EN+jshBAZ5ndgqk5RgEDhdw@mail.gmail.com \
--to=fdmanana@kernel.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).