[ANCK 6.6] [Fix] ext4: fix largest free orders lists corruption on mb_optimize_scan switch · Pull Request !5875 · anolis/cloud-kernel

bugzilla:https://bugzilla.openanolis.cn/show_bug.cgi?id=26388

1. ext4: fix largest free orders lists corruption on mb_optimize_scan switch
The grp->bb_largest_free_order is updated regardless of whether
    mb_optimize_scan is enabled. This can lead to inconsistencies between
    grp->bb_largest_free_order and the actual s_mb_largest_free_orders list
    index when mb_optimize_scan is repeatedly enabled and disabled via remount.
    
    For example, if mb_optimize_scan is initially enabled, largest free
    order is 3, and the group is in s_mb_largest_free_orders[3]. Then,
    mb_optimize_scan is disabled via remount, block allocations occur,
    updating largest free order to 2. Finally, mb_optimize_scan is re-enabled
    via remount, more block allocations update largest free order to 1.
    
    At this point, the group would be removed from s_mb_largest_free_orders[3]
    under the protection of s_mb_largest_free_orders_locks[2]. This lock
    mismatch can lead to list corruption.
    
    To fix this, whenever grp->bb_largest_free_order changes, we now always
    attempt to remove the group from its old order list. However, we only
    insert the group into the new order list if `mb_optimize_scan` is enabled.
    This approach helps prevent lock inconsistencies and ensures the data in
    the order lists remains reliable.
    
    Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning")

类型	指派人员	状态
审查	hsiangkao josephhz JeffleXu	已完成 (0/0人)
测试	小龙已测试通过	已完成 (1/1人)

GVPanolis/cloud-kernel

搜索帮助

GVP anolis/cloud-kernel