Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     linux-ext4@vger.kernel.org, Zhang Yi <yi.zhang@huawei.com>
Cc:     "Theodore Ts'o" <tytso@mit.edu>, adilger.kernel@dilger.ca,
        jack@suse.cz, yukuai3@huawei.com
Subject: Re: [PATCH v3] ext4: fix underflow in ext4_max_bitmap_size()
Date:   Thu,  3 Mar 2022 10:14:14 -0500
Message-Id: <164632037182.689479.17594587165510308394.b4-ty@mit.edu>
In-Reply-To: <20220301111704.2153829-1-yi.zhang@huawei.com>
References: <20220301111704.2153829-1-yi.zhang@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Tue, 1 Mar 2022 19:17:04 +0800, Zhang Yi wrote:
> when ext4 filesystem is created with 64k block size, ^extent and
> ^huge_file features. the upper_limit would underflow during the
> computations in ext4_max_bitmap_size(). The problem is the size of block
> index tree for such large block size is more than i_blocks can carry.
> So fix the computation to count with this possibility. After this fix,
> the 'res' cannot overflow loff_t on the extreme case of filesystem with
> huge_files and 64K block size, so this patch also revert commit
> 75ca6ad408f4 ("ext4: fix loff_t overflow in ext4_max_bitmap_size()").
> 
> [...]

Applied, thanks!

[1/1] ext4: fix underflow in ext4_max_bitmap_size()
      commit: 5c93e8ecd5bd3bfdee013b6da0850357eb6ca4d8

Best regards,
-- 
Theodore Ts'o <tytso@mit.edu>