From: David Sterba <dsterba@suse.cz>
To: Nikolay Borisov <nborisov@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2] btrfs: Add self-tests for btrfs_rmap_block
Date: Thu, 2 Jan 2020 16:40:32 +0100 [thread overview]
Message-ID: <20200102154032.GJ3929@twin.jikos.cz> (raw)
In-Reply-To: <20191210180045.2047-1-nborisov@suse.com>
On Tue, Dec 10, 2019 at 08:00:45PM +0200, Nikolay Borisov wrote:
> This is enough to exercise out of boundary address exclusion as well as
> address matching.
>
> Signed-off-by: Nikolay Borisov <nborisov@suse.com>
> ---
> V2:
> * Adjusted comments about some members of struct rmap_test_vector
> * Fixed inline comments
> * Correctly handle error when initialising dummy device
> * Other minor cosmetic changes around comments/braces for single statement 'if'
> and structure initialization
I still found issues unfixed from v1 and some that I did not notice
before
> fs/btrfs/tests/extent-map-tests.c | 146 +++++++++++++++++++++++++++++-
> 1 file changed, 145 insertions(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/tests/extent-map-tests.c b/fs/btrfs/tests/extent-map-tests.c
> index 4a7f796c9900..4878904434af 100644
> --- a/fs/btrfs/tests/extent-map-tests.c
> +++ b/fs/btrfs/tests/extent-map-tests.c
> @@ -6,6 +6,10 @@
> #include <linux/types.h>
> #include "btrfs-tests.h"
> #include "../ctree.h"
> +#include "../volumes.h"
> +#include "../disk-io.h"
> +#include "../block-group.h"
> +
Extra newline
>
> static void free_extent_map_tree(struct extent_map_tree *em_tree)
> {
> @@ -437,11 +441,144 @@ static int test_case_4(struct btrfs_fs_info *fs_info,
> return ret;
> }
>
> +struct rmap_test_vector {
> + u64 raid_type;
> + u64 physical_start;
> + u64 data_stripe_size;
> + u64 num_data_stripes;
> + u64 num_stripes;
> + /* Assume we won't have more than 5 physical stripes */
> + u64 data_stripe_phys_start[5];
> + int expected_mapped_addr;
This should be bool
> + /* Physical to logical addresses */
> + u64 mapped_logical[5];
> +};
> +
> +static int test_rmap_block(struct btrfs_fs_info *fs_info,
> + struct rmap_test_vector *test)
> +{
> + struct extent_map *em;
> + struct map_lookup *map = NULL;
> + u64 *logical;
> + int i, out_ndaddrs, out_stripe_len;
> + int ret = -EINVAL;
> +
> + em = alloc_extent_map();
> + if (!em) {
> + test_std_err(TEST_ALLOC_EXTENT_MAP);
> + return -ENOMEM;
> + }
> +
> + map = kmalloc(map_lookup_size(test->num_stripes), GFP_KERNEL);
> + if (!map) {
> + kfree(em);
> + test_std_err(TEST_ALLOC_EXTENT_MAP);
> + return -ENOMEM;
> + }
> +
> + set_bit(EXTENT_FLAG_FS_MAPPING, &em->flags);
> + /* Start at 4gb logical address */
> + em->start = SZ_4G;
> + em->len = test->data_stripe_size * test->num_data_stripes;
> + em->block_len = em->len;
> + em->orig_block_len = test->data_stripe_size;
> + em->map_lookup = map;
> +
> + map->num_stripes = test->num_stripes;
> + map->stripe_len = BTRFS_STRIPE_LEN;
> + map->type = test->raid_type;
> +
> + for (i = 0; i < map->num_stripes; i++)
> + {
> + struct btrfs_device *dev = btrfs_alloc_dummy_device(fs_info);
> + if (!dev) {
> + test_err("ENOMEM while allocating dummy device");
ret = -ENOMEM;
And the error message should follow the scheme of the other standard
error messages (defined in test_error)
> + goto out;
> + }
> + map->stripes[i].dev = dev;
> + map->stripes[i].physical = test->data_stripe_phys_start[i];
> + }
> +
> + write_lock(&fs_info->mapping_tree.lock);
> + ret = add_extent_mapping(&fs_info->mapping_tree, em, 0);
> + write_unlock(&fs_info->mapping_tree.lock);
> + if (ret)
> + test_err("Error adding block group mapping to mapping tree");
Error found but no exit, other selftests do that. And no capital letter
at the beginning of the string. I've added a label before the 2nd
free_extent_map.
> +
> + ret = btrfs_rmap_block(fs_info, em->start, btrfs_sb_offset(1),
> + &logical, &out_ndaddrs, &out_stripe_len);
> + if (ret || (out_ndaddrs == 0 && test->expected_mapped_addr)) {
> + test_err("Didn't rmap anything but expected %d",
... in all strings passed to test_err
> + test->expected_mapped_addr);
> + goto out;
> + }
> +
> + if (out_stripe_len != BTRFS_STRIPE_LEN) {
> + test_err("Calculated stripe len doesn't match");
Here
> + goto out;
> + }
> +
> + if (out_ndaddrs != test->expected_mapped_addr) {
> + for (i = 0; i < out_ndaddrs; i++)
> + test_msg("Mapped %llu", logical[i]);
Here
> + test_err("Unexpected number of mapped addresses: %d", out_ndaddrs);
Here
> + goto out;
> + }
> +
> + for (i = 0; i < out_ndaddrs; i++) {
> + if (logical[i] != test->mapped_logical[i]) {
> + test_err("Unexpected logical address mapped");
Here
> + goto out;
> + }
> + }
> +
> + ret = 0;
> +out:
> + write_lock(&fs_info->mapping_tree.lock);
> + remove_extent_mapping(&fs_info->mapping_tree, em);
> + write_unlock(&fs_info->mapping_tree.lock);
> + /* For us */
> + free_extent_map(em);
> + /* For the tree */
> + free_extent_map(em);
> + return ret;
> +}
> +
> int btrfs_test_extent_map(void)
> {
> struct btrfs_fs_info *fs_info = NULL;
> struct extent_map_tree *em_tree;
> - int ret = 0;
> + int ret = 0, i;
> + struct rmap_test_vector rmap_tests[] = {
> + {
> + /*
> + * Tests a chunk with 2 data stripes one of which
> + * interesects the physical address of the super block
> + * is correctly recognised.
> + */
> + .raid_type = BTRFS_BLOCK_GROUP_RAID1,
> + .physical_start = SZ_64M - SZ_4M,
> + .data_stripe_size = SZ_256M,
> + .num_data_stripes = 2,
> + .num_stripes = 2,
> + .data_stripe_phys_start = {SZ_64M - SZ_4M, SZ_64M - SZ_4M + SZ_256M},
Formatting
> + .expected_mapped_addr = 1,
> + .mapped_logical= {SZ_4G + SZ_4M}
> + },
> + {
> + /* test that out of range physical addresses are ignored */
> +
> + /* SINGLE chunk type */
> + .raid_type = 0,
> + .physical_start = SZ_4G,
> + .data_stripe_size = SZ_256M,
> + .num_data_stripes = 1,
> + .num_stripes = 1,
> + .data_stripe_phys_start = {SZ_256M},
> + .expected_mapped_addr = 0,
> + .mapped_logical = {0}
> + }
> + };
>
> test_msg("running extent_map tests");
>
> @@ -474,6 +611,13 @@ int btrfs_test_extent_map(void)
> goto out;
> ret = test_case_4(fs_info, em_tree);
>
> + test_msg("Running rmap tests.");
test_msg("running rmap tests");
> + for (i = 0; i < ARRAY_SIZE(rmap_tests); i++) {
> + ret = test_rmap_block(fs_info, &rmap_tests[i]);
> + if (ret)
> + goto out;
> + }
> +
> out:
> kfree(em_tree);
> btrfs_free_dummy_fs_info(fs_info);
> --
> 2.17.1
next prev parent reply other threads:[~2020-01-02 15:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-19 12:05 [PATCH 0/6] Cleanup super block stripe exclusion code Nikolay Borisov
2019-11-19 12:05 ` [PATCH 1/6] btrfs: Move and unexport btrfs_rmap_block Nikolay Borisov
2019-11-26 15:53 ` David Sterba
2019-12-10 17:57 ` [PATCH v2] " Nikolay Borisov
2020-01-02 15:21 ` David Sterba
2019-11-19 12:05 ` [PATCH 2/6] btrfs: selftests: Add support for dummy devices Nikolay Borisov
2019-11-19 12:05 ` [PATCH 3/6] btrfs: Add self-tests for btrfs_rmap_block Nikolay Borisov
2019-11-26 16:04 ` David Sterba
2019-12-10 18:00 ` [PATCH v2] " Nikolay Borisov
2020-01-02 15:40 ` David Sterba [this message]
2020-01-10 14:46 ` Nikolay Borisov
2020-01-14 16:51 ` David Sterba
2019-11-19 12:05 ` [PATCH 4/6] btrfs: Refactor btrfs_rmap_block to improve readability Nikolay Borisov
2019-11-19 12:05 ` [PATCH 5/6] btrfs: Read stripe len directly in btrfs_rmap_block Nikolay Borisov
2020-01-14 16:54 ` David Sterba
2020-01-15 10:52 ` Nikolay Borisov
2019-11-19 12:05 ` [PATCH 6/6] btrfs: Remove dead code exclude_super_stripes 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=20200102154032.GJ3929@twin.jikos.cz \
--to=dsterba@suse.cz \
--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