linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@gmail.com>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>,
	Jiachen YANG <farseerfc@gmail.com>
Subject: Re: [PATCH 1/2] btrfs-progs: convert: Ensure the data chunks size never exceed device size
Date: Tue, 16 Feb 2021 14:45:52 +0000	[thread overview]
Message-ID: <CAL3q7H5sgq_vXpP5rB+bBOBNqaq1+AszGLZvfdgdMLDruQZ4_w@mail.gmail.com> (raw)
In-Reply-To: <20200624115527.855816-1-wqu@suse.com>

On Wed, Jun 24, 2020 at 10:00 PM Qu Wenruo <wqu@suse.com> wrote:
>
> [BUG]
> The following script could lead to corrupted btrfs fs after
> btrfs-convert:
>
>   fallocate -l 1G test.img
>   mkfs.ext4 test.img
>   mount test.img $mnt
>   fallocate -l 200m $mnt/file1
>   fallocate -l 200m $mnt/file2
>   fallocate -l 200m $mnt/file3
>   fallocate -l 200m $mnt/file4
>   fallocate -l 205m $mnt/file1
>   fallocate -l 205m $mnt/file2
>   fallocate -l 205m $mnt/file3
>   fallocate -l 205m $mnt/file4
>   umount $mnt
>   btrfs-convert test.img
>
> The result btrfs will have a device extent beyond its boundary:
>   pening filesystem to check...
>   Checking filesystem on test.img
>   UUID: bbcd7399-fd5b-41a7-81ae-d48bc6935e43
>   [1/7] checking root items
>   [2/7] checking extents
>   ERROR: dev extent devid 1 physical offset 993198080 len 85786624 is beyond device boundary 1073741824
>   ERROR: errors found in extent allocation tree or chunk allocation
>   [3/7] checking free space cache
>   [4/7] checking fs roots
>   [5/7] checking only csums items (without verifying data)
>   [6/7] checking root refs
>   [7/7] checking quota groups skipped (not enabled on this FS)
>   found 913960960 bytes used, error(s) found
>   total csum bytes: 891500
>   total tree bytes: 1064960
>   total fs tree bytes: 49152
>   total extent tree bytes: 16384
>   btree space waste bytes: 144885
>   file data blocks allocated: 2129063936
>    referenced 1772728320
>
> [CAUSE]
> Btrfs-convert first collect all used blocks in the original fs, then
> slightly enlarge the used blocks range as new btrfs data chunks.
>
> However the enlarge part has a problem, that it doesn't take the device
> boundary into consideration.
>
> Thus it caused device extents and data chunks to go beyond device
> boundary.
>
> [FIX]
> Just to extra check before inserting data chunks into
> btrfs_convert_context::data_chunk.
>
> Reported-by: Jiachen YANG <farseerfc@gmail.com>
> Signed-off-by: Qu Wenruo <wqu@suse.com>

So, having upgraded a test box from btrfs-progs v5.6.1 to v5.10.1, I
now have btrfs/136 (fstests) failing:

$ ./check btrfs/136
FSTYP         -- btrfs
PLATFORM      -- Linux/x86_64 debian8 5.11.0-rc7-btrfs-next-81 #1 SMP
PREEMPT Tue Feb 16 12:29:07 WET 2021
MKFS_OPTIONS  -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1

btrfs/136 7s ... [failed, exit status 1]- output mismatch (see
/home/fdmanana/git/hub/xfstests/results//btrfs/136.out.bad)
    --- tests/btrfs/136.out 2020-06-10 19:29:03.818519162 +0100
    +++ /home/fdmanana/git/hub/xfstests/results//btrfs/136.out.bad
2021-02-16 14:31:30.669559188 +0000
    @@ -1,2 +1,3 @@
     QA output created by 136
    -Silence is golden
    +btrfs-convert failed
    +(see /home/fdmanana/git/hub/xfstests/results//btrfs/136.full for details)
    ...
    (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/136.out
/home/fdmanana/git/hub/xfstests/results//btrfs/136.out.bad'  to see
the entire diff)
Ran: btrfs/136
Failures: btrfs/136
Failed 1 of 1 tests

A bisect pointed to this patch.
Did you get this failure on your test box as well?

Thanks.

> ---
>  convert/main.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/convert/main.c b/convert/main.c
> index c86ddd988c63..7709e9a6c085 100644
> --- a/convert/main.c
> +++ b/convert/main.c
> @@ -669,6 +669,8 @@ static int calculate_available_space(struct btrfs_convert_context *cctx)
>                         cur_off = cache->start;
>                 cur_len = max(cache->start + cache->size - cur_off,
>                               min_stripe_size);
> +               /* data chunks should never exceed device boundary */
> +               cur_len = min(cctx->total_bytes - cur_off, cur_len);
>                 ret = add_merge_cache_extent(data_chunks, cur_off, cur_len);
>                 if (ret < 0)
>                         goto out;
> --
> 2.27.0
>


-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

  parent reply	other threads:[~2021-02-16 14:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 11:55 [PATCH 1/2] btrfs-progs: convert: Ensure the data chunks size never exceed device size Qu Wenruo
2020-06-24 11:55 ` [PATCH 2/2] btrfs-progs: tests/convert: Add test case to make sure we won't allocate dev extents beyond device boundary Qu Wenruo
2020-06-24 15:49   ` David Sterba
2020-06-24 15:51   ` David Sterba
2020-06-24 15:58 ` [PATCH 1/2] btrfs-progs: convert: Ensure the data chunks size never exceed device size David Sterba
2020-08-15 13:38 ` Anand Jain
2020-08-15 23:40   ` Qu Wenruo
2021-02-16 14:45 ` Filipe Manana [this message]
2021-02-16 23:42   ` Qu Wenruo
2021-02-17 10:59     ` Filipe Manana
2021-02-17 11:28       ` Qu Wenruo
2021-02-17 12:12         ` Filipe Manana
2021-02-17 12:29           ` Qu Wenruo
2021-02-17 12:47             ` Filipe Manana

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=CAL3q7H5sgq_vXpP5rB+bBOBNqaq1+AszGLZvfdgdMLDruQZ4_w@mail.gmail.com \
    --to=fdmanana@gmail.com \
    --cc=farseerfc@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@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;
as well as URLs for NNTP newsgroup(s).