linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Baokun Li <libaokun1@huawei.com>
To: <linux-ext4@vger.kernel.org>
Cc: <tytso@mit.edu>, <adilger.kernel@dilger.ca>, <jack@suse.cz>,
	<ritesh.list@gmail.com>, <lczerner@redhat.com>,
	<linux-kernel@vger.kernel.org>, <yi.zhang@huawei.com>,
	<yebin10@huawei.com>, <yukuai3@huawei.com>,
	<libaokun1@huawei.com>
Subject: [PATCH v3 0/3] ext4: fix two bugs in ext4_mb_normalize_request
Date: Sat, 28 May 2022 19:00:14 +0800	[thread overview]
Message-ID: <20220528110017.354175-1-libaokun1@huawei.com> (raw)

The logical block map reached before the problem stack was 1011.
The estimated location of the size logical block of the inde plus
the required allocation length 7, the size is 1018.

But the i_size of inode is 1299, so the size is 1299,
the aligned size is 2048, and the end is 2048.
Because of the restriction of ar -> pleft, start==648.

EXT4_BLOCKS_PER_GROUP (ac- > ac_sb) is 256,
so the size is 256 and the end is 904.

It is not normal to truncate here, the end is less than 1299 of the
target logical block, that is, the allocated range does not contain
the target logical block.

Then this new scope conflicts with the previous PA, as follows:

        pa_start-506        pa_end-759
 |____________P________V_________P__________V_____________l________|
 0                 start-648             end-904    logical-1299   2048

In this case, start is changed to pa_end, that is, 759.
In this case, a bug_ON is reported in ext4_mb_mark_diskspace_used.

The problem is caused by the truncation introduced in the
cd648b8a8fd5 ("ext4: trim allocation requests to group size").
The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP.
However, the truncation method is incorrect. The group where the
logical is located should be used for allocation. If the value of
EXT4_BLOCKS_PER_GROUP is 256, size 2048 can be divided into eight
groups. If the value of logical is 1299, the value of logical must be
in the sixth group, that is,
	start=1299/256*256=5*256=1280,
	end=size+1280=1536.

Then, the value range can be further narrowed down based on
other restrictions.
                              1024    1280     1536
|_______|_______|_______|_______|_______|__l_____|_______|_______|
0 group1  group2  group3  group4  group5  group6  group7  group8 2048 

At the same time, we fixed earlier assertions that we could find out when
the target logical block was not in the allocated range.

Ritesh Harjani found that flex_bg groups was not considered in
ext4_mb_normalize_request. So we add support for flex_bg to make
the physical blocks of large files contiguous.

I ran xfstests on ext3 and ext4 and found no problems in ext3/4.

V1: https://patchwork.ozlabs.org/project/linux-ext4/cover/20220521134217.312071-1-libaokun1@huawei.com/
V2: https://patchwork.ozlabs.org/project/linux-ext4/cover/20220523141658.2919003-1-libaokun1@huawei.com/

Baokun Li (3):
  ext4: fix bug_on ext4_mb_use_inode_pa
  ext4: correct the judgment of BUG in ext4_mb_normalize_request
  ext4: support flex_bg in ext4_mb_normalize_request

 fs/ext4/mballoc.c | 37 +++++++++++++++++++++++++++++++++----
 1 file changed, 33 insertions(+), 4 deletions(-)

-- 
2.31.1


             reply	other threads:[~2022-05-28 10:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-28 11:00 Baokun Li [this message]
2022-05-28 11:00 ` [PATCH v3 1/3] ext4: fix bug_on ext4_mb_use_inode_pa Baokun Li
2022-05-28 15:10   ` Ritesh Harjani
2022-05-30  2:12     ` Baokun Li
2022-05-28 11:00 ` [PATCH v3 2/3] ext4: correct the judgment of BUG in ext4_mb_normalize_request Baokun Li
2022-05-28 15:12   ` Ritesh Harjani
2022-05-30  2:13     ` Baokun Li
2022-05-28 11:00 ` [PATCH v3 3/3] ext4: support flex_bg " Baokun Li
2022-05-28 15:09   ` Ritesh Harjani
2022-05-30  2:35     ` Baokun Li
2022-06-18  2:12 ` [PATCH v3 0/3] ext4: fix two bugs " Theodore Ts'o

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=20220528110017.354175-1-libaokun1@huawei.com \
    --to=libaokun1@huawei.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ritesh.list@gmail.com \
    --cc=tytso@mit.edu \
    --cc=yebin10@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai3@huawei.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).