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 4/4] btrfs: test invalid splitting when skipping pinned drop extent_map
Date: Fri, 18 Aug 2023 11:49:15 +0100 [thread overview]
Message-ID: <ZN9Mq5VDREK0rO1C@debian0.Home> (raw)
In-Reply-To: <cb4e2f77d7ab9670223ca0d76594abb93bb1c32d.1692305624.git.josef@toxicpanda.com>
On Thu, Aug 17, 2023 at 04:57:33PM -0400, Josef Bacik wrote:
> This reproduces the bug fixed by "btrfs: fix incorrect splitting in
> btrfs_drop_extent_map_range", we were improperly calculating the range
> for the split extent. Add a test that exercises this scenario and
> validates that we get the correct resulting extent_maps in our tree.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Looks good, just a minor comment below.
> ---
> fs/btrfs/tests/extent-map-tests.c | 138 ++++++++++++++++++++++++++++++
> 1 file changed, 138 insertions(+)
>
> diff --git a/fs/btrfs/tests/extent-map-tests.c b/fs/btrfs/tests/extent-map-tests.c
> index 18ab03f0d029..06820a8b4d1f 100644
> --- a/fs/btrfs/tests/extent-map-tests.c
> +++ b/fs/btrfs/tests/extent-map-tests.c
> @@ -710,6 +710,141 @@ static int test_case_6(struct btrfs_fs_info *fs_info,
> return ret;
> }
>
> +/*
> + * Regression test for btrfs_drop_extent_map_range. Calling with skip_pinned ==
> + * true would mess up the start/end calculations and subsequent splits would be
> + * incorrect.
> + */
> +static int test_case_7(void)
> +{
> + struct extent_map_tree *em_tree;
> + struct extent_map *em = NULL;
> + struct inode *inode = NULL;
These two initializations to NULL are not needed.
> + int ret;
> +
> + test_msg("Running btrfs_drop_extent_cache with pinned");
> +
> + inode = btrfs_new_test_inode();
> + if (!inode) {
> + test_std_err(TEST_ALLOC_INODE);
> + return -ENOMEM;
> + }
> +
> + em_tree = &BTRFS_I(inode)->extent_tree;
> +
> + em = alloc_extent_map();
> + if (!em) {
> + test_std_err(TEST_ALLOC_EXTENT_MAP);
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + /* [0, 16K), pinned */
> + em->start = 0;
> + em->len = SZ_16K;
> + em->block_start = 0;
> + em->block_len = SZ_4K;
> + set_bit(EXTENT_FLAG_PINNED, &em->flags);
> + write_lock(&em_tree->lock);
> + ret = add_extent_mapping(em_tree, em, 0);
> + write_unlock(&em_tree->lock);
> + if (ret < 0) {
> + test_err("couldn't add extent map");
> + goto out;
> + }
> + free_extent_map(em);
> +
> + em = alloc_extent_map();
> + if (!em) {
> + test_std_err(TEST_ALLOC_EXTENT_MAP);
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + /* [32K, 48K), not pinned */
> + em->start = SZ_32K;
> + em->len = SZ_16K;
> + em->block_start = SZ_32K;
> + em->block_len = SZ_16K;
> + write_lock(&em_tree->lock);
> + ret = add_extent_mapping(em_tree, em, 0);
> + write_unlock(&em_tree->lock);
> + if (ret < 0) {
> + test_err("couldn't add extent map");
> + goto out;
> + }
> + free_extent_map(em);
> +
> + /*
> + * Drop [0, 36K) This should skip the [0, 4K) extent and then split the
> + * [32K, 48K) extent.
> + */
> + btrfs_drop_extent_map_range(BTRFS_I(inode), 0, (36 * SZ_1K) - 1, true);
> +
> + /* Make sure our extent maps look sane. */
> + ret = -EINVAL;
> +
> + em = lookup_extent_mapping(em_tree, 0, SZ_16K);
> + if (!em) {
> + test_err("didn't find an em at 0 as expected");
> + goto out;
> + }
> +
> + if (em->start != 0) {
> + test_err("em->start is %llu, expected 0", em->start);
> + goto out;
> + }
> +
> + if (em->len != SZ_16K) {
> + test_err("em->len is %llu, expected 16K", em->len);
> + goto out;
> + }
> +
> + free_extent_map(em);
> +
> + read_lock(&em_tree->lock);
> + em = lookup_extent_mapping(em_tree, SZ_16K, SZ_16K);
> + read_unlock(&em_tree->lock);
> + if (em) {
> + test_err("found an em when we weren't expecting one");
> + goto out;
> + }
> +
> + read_lock(&em_tree->lock);
> + em = lookup_extent_mapping(em_tree, SZ_32K, SZ_16K);
> + read_unlock(&em_tree->lock);
> + if (!em) {
> + test_err("didn't find an em at 32K as expected");
> + goto out;
> + }
> +
> + if (em->start != (36 * SZ_1K)) {
> + test_err("em->start is %llu, expected 36K", em->start);
> + goto out;
> + }
> +
> + if (em->len != (12 * SZ_1K)) {
> + test_err("em->len is %llu, expected 12K", em->len);
> + goto out;
> + }
> +
> + free_extent_map(em);
> +
> + read_lock(&em_tree->lock);
> + em = lookup_extent_mapping(em_tree, 48 * SZ_1K, (u64)-1);
> + read_unlock(&em_tree->lock);
> + if (em) {
> + test_err("found an unexpected em above 48K");
> + goto out;
> + }
> +
> + ret = 0;
> +out:
> + free_extent_map(em);
> + iput(inode);
> + return ret;
> +}
> +
> struct rmap_test_vector {
> u64 raid_type;
> u64 physical_start;
> @@ -893,6 +1028,9 @@ int btrfs_test_extent_map(void)
> if (ret)
> goto out;
> ret = test_case_6(fs_info, em_tree);
> + if (ret)
> + goto out;
> + ret = test_case_7();
> if (ret)
> goto out;
>
> --
> 2.26.3
>
next prev parent reply other threads:[~2023-08-18 10:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 20:57 [PATCH 0/4] Fix incorrect splitting logic in btrfs_drop_extent_map_range Josef Bacik
2023-08-17 20:57 ` [PATCH 1/4] btrfs: fix incorrect splitting " Josef Bacik
2023-08-18 10:46 ` Filipe Manana
2023-08-17 20:57 ` [PATCH 2/4] btrfs: add extent_map tests for dropping with odd layouts Josef Bacik
2023-08-18 10:47 ` Filipe Manana
2023-08-17 20:57 ` [PATCH 3/4] btrfs: add a self test for btrfs_add_extent_mapping Josef Bacik
2023-08-18 10:48 ` Filipe Manana
2023-08-17 20:57 ` [PATCH 4/4] btrfs: test invalid splitting when skipping pinned drop extent_map Josef Bacik
2023-08-18 10:49 ` Filipe Manana [this message]
2023-08-17 23:52 ` [PATCH 0/4] Fix incorrect splitting logic in btrfs_drop_extent_map_range 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=ZN9Mq5VDREK0rO1C@debian0.Home \
--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 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.