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,
        openglfreak@googlemail.com, jack@suse.cz, yukuai3@huawei.com
Subject: Re: [PATCH] ext4: ext4_read_bh_lock() should submit IO if the buffer isn't uptodate
Date:   Thu, 29 Sep 2022 23:19:46 -0400
Message-Id: <166450797715.256913.16436347919601739345.b4-ty@mit.edu>
In-Reply-To: <20220831074629.3755110-1-yi.zhang@huawei.com>
References: <20220831074629.3755110-1-yi.zhang@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Wed, 31 Aug 2022 15:46:29 +0800, Zhang Yi wrote:
> Recently we notice that ext4 filesystem occasionally fail to read
> metadata from disk and report error message, but the disk and block
> layer looks fine. After analyse, we lockon commit 88dbcbb3a484
> ("blkdev: avoid migration stalls for blkdev pages"). It provide a
> migration method for the bdev, we could move page that has buffers
> without extra users now, but it lock the buffers on the page, which
> breaks the fragile metadata read operation on ext4 filesystem,
> ext4_read_bh_lock() was copied from ll_rw_block(), it depends on the
> assumption of that locked buffer means it is under IO. So it just
> trylock the buffer and skip submit IO if it lock failed, after
> wait_on_buffer() we conclude IO error because the buffer is not
> uptodate.
> 
> [...]

Applied, thanks!

[1/1] ext4: ext4_read_bh_lock() should submit IO if the buffer isn't uptodate
      commit: 07e3f4273ff54a4c891f05e9f0f0c842b46578a7

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