summaryrefslogtreecommitdiff
path: root/fs/ext4/fsmap.c
diff options
context:
space:
mode:
authorChunguang Xu <brookxu@tencent.com>2020-12-04 06:05:43 +0300
committerTheodore Ts'o <tytso@mit.edu>2020-12-22 21:08:45 +0300
commit82ef1370b0c1757ab4ce29f34c52b4e93839b0aa (patch)
tree825a0e93809324de1600cb9d0f12225c30f6992d /fs/ext4/fsmap.c
parentc92dc856848f32781e37b88c1b7f875e274f5efb (diff)
downloadlinux-82ef1370b0c1757ab4ce29f34c52b4e93839b0aa.tar.xz
ext4: avoid s_mb_prefetch to be zero in individual scenarios
Commit cfd732377221 ("ext4: add prefetching for block allocation bitmaps") introduced block bitmap prefetch, and expects to read block bitmaps of flex_bg through an IO. However, it seems to ignore the value range of s_log_groups_per_flex. In the scenario where the value of s_log_groups_per_flex is greater than 27, s_mb_prefetch or s_mb_prefetch_limit will overflow, cause a divide zero exception. In addition, the logic of calculating nr is also flawed, because the size of flexbg is fixed during a single mount, but s_mb_prefetch can be modified, which causes nr to fail to meet the value condition of [1, flexbg_size]. To solve this problem, we need to set the upper limit of s_mb_prefetch. Since we expect to load block bitmaps of a flex_bg through an IO, we can consider determining a reasonable upper limit among the IO limit parameters. After consideration, we chose BLK_MAX_SEGMENT_SIZE. This is a good choice to solve divide zero problem and avoiding performance degradation. [ Some minor code simplifications to make the changes easy to follow -- TYT ] Reported-by: Tosk Robot <tencent_os_robot@tencent.com> Signed-off-by: Chunguang Xu <brookxu@tencent.com> Reviewed-by: Samuel Liao <samuelliao@tencent.com> Reviewed-by: Andreas Dilger <adilger@dilger.ca> Link: https://lore.kernel.org/r/1607051143-24508-1-git-send-email-brookxu@tencent.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'fs/ext4/fsmap.c')
0 files changed, 0 insertions, 0 deletions