]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
ext4: correct the hole length returned by ext4_map_blocks()
authorZhang Yi <yi.zhang@huawei.com>
Sat, 27 Jan 2024 01:58:02 +0000 (09:58 +0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 1 Mar 2024 12:34:52 +0000 (13:34 +0100)
commitf5411b7666275d67bf91beb2f84bbf12ccb3dead
tree1162b72fc8d4692eda52a6e573bbaed2b02d57c4
parent2fdb5551e35b0dcb61d85f70d0963813f53d377f
ext4: correct the hole length returned by ext4_map_blocks()

[ Upstream commit 6430dea07e85958fa87d0276c0c4388dd51e630b ]

In ext4_map_blocks(), if we can't find a range of mapping in the
extents cache, we are calling ext4_ext_map_blocks() to search the real
path and ext4_ext_determine_hole() to determine the hole range. But if
the querying range was partially or completely overlaped by a delalloc
extent, we can't find it in the real extent path, so the returned hole
length could be incorrect.

Fortunately, ext4_ext_put_gap_in_cache() have already handle delalloc
extent, but it searches start from the expanded hole_start, doesn't
start from the querying range, so the delalloc extent found could not be
the one that overlaped the querying range, plus, it also didn't adjust
the hole length. Let's just remove ext4_ext_put_gap_in_cache(), handle
delalloc and insert adjusted hole extent in ext4_ext_determine_hole().

Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Suggested-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240127015825.1608160-4-yi.zhang@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fs/ext4/extents.c