[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220523094023.e3rnile4wh7uiich@quack3.lan>
Date: Mon, 23 May 2022 11:40:23 +0200
From: Jan Kara <jack@...e.cz>
To: Baokun Li <libaokun1@...wei.com>
Cc: linux-ext4@...r.kernel.org, tytso@....edu,
adilger.kernel@...ger.ca, jack@...e.cz, ritesh.list@...il.com,
linux-kernel@...r.kernel.org, yi.zhang@...wei.com,
yebin10@...wei.com, yukuai3@...wei.com
Subject: Re: [PATCH 2/2] ext4: correct the judgment of BUG in
ext4_mb_normalize_request
On Sat 21-05-22 21:42:17, Baokun Li wrote:
> When either of the "start + size <= ac->ac_o_ex.fe_logical" or
> "start > ac->ac_o_ex.fe_logical" conditions is met, it indicates
> that the fe_logical is not in the allocated range.
> In this case, it should be bug_ON.
>
> Fixes: dfe076c106f6 ("ext4: get rid of code duplication")
> Signed-off-by: Baokun Li <libaokun1@...wei.com>
I think this is actually wrong. The original condition checks whether
start + size does not overflow the used integer type. Your condition is
much stronger and I don't think it always has to be true. E.g. allocation
goal block (start variable) can be pushed to larger values by existing
preallocation or so.
Honza
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 32410b79b664..d0fb57970648 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -4190,7 +4190,7 @@ ext4_mb_normalize_request(struct ext4_allocation_context *ac,
> }
> rcu_read_unlock();
>
> - if (start + size <= ac->ac_o_ex.fe_logical &&
> + if (start + size <= ac->ac_o_ex.fe_logical ||
> start > ac->ac_o_ex.fe_logical) {
> ext4_msg(ac->ac_sb, KERN_ERR,
> "start %lu, size %lu, fe_logical %lu",
> --
> 2.31.1
>
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists