From: David Sterba <dsterba@suse.cz>
To: Josef Bacik <josef@toxicpanda.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH] btrfs: add a find_contiguous_extent_bit helper and use it for safe isize
Date: Fri, 14 Feb 2020 22:17:14 +0100 [thread overview]
Message-ID: <20200214211713.GG2902@twin.jikos.cz> (raw)
In-Reply-To: <20200212183831.78293-1-josef@toxicpanda.com>
On Wed, Feb 12, 2020 at 01:38:31PM -0500, Josef Bacik wrote:
> Filipe noticed a race where we would sometimes get the wrong answer for
> the i_disk_size for !NO_HOLES with my patch. That is because I expected
> that find_first_extent_bit() would find the contiguous range, since I'm
> only ever setting EXTENT_DIRTY. However the way set_extent_bit() works
> is it'll temporarily split the range, loop around and set our bits, and
> then merge the state. When it loops it drops the tree->lock, so there
> is a window where we can have two adjacent states instead of one large
> state. Fix this by walking forward until we find a non-contiguous
> state, and set our end_ret to the end of our logically contiguous area.
> This fixes the problem without relying on specific behavior from
> set_extent_bit().
>
> Fixes: 79ceff7f6e5d ("btrfs: introduce per-inode file extent tree")
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
> Dave, I assume you'll want to fold this in to the referenced patch, if not let
> me know and I'll rework the series to include this as a different patch.
Folding looks like a good option, the patch adds other helper for
btrfs_inode_clear_file_extent_range so this patch fits in nicely.
> +/**
> + * find_contiguous_extent_bit: find a contiguous area of bits
> + * @tree - io tree to check
> + * @start - offset to start the search from
> + * @start_ret - the first offset we found with the bits set
> + * @end_ret - the final contiguous range of the bits that were set
> + *
> + * set_extent_bit anc clear_extent_bit can temporarily split contiguous ranges
> + * to set bits appropriately, and then merge them again. During this time it
> + * will drop the tree->lock, so use this helper if you want to find the actual
> + * contiguous area for given bits. We will search to the first bit we find, and
> + * then walk down the tree until we find a non-contiguous area. The area
> + * returned will be the full contiguous area with the bits set.
> + */
This summarizes why it's needed so the changelog does not need to be
updated AFAICS. Patch updated and misc-next pushed. Thanks.
prev parent reply other threads:[~2020-02-14 21:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-12 18:38 [PATCH] btrfs: add a find_contiguous_extent_bit helper and use it for safe isize Josef Bacik
2020-02-12 18:44 ` Filipe Manana
2020-02-12 19:44 ` Josef Bacik
2020-02-13 10:21 ` Filipe Manana
2020-02-13 10:00 ` Johannes Thumshirn
2020-02-13 10:22 ` Filipe Manana
2020-02-14 21:17 ` David Sterba [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=20200214211713.GG2902@twin.jikos.cz \
--to=dsterba@suse.cz \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.