Kemeng Shi <shikemeng@xxxxxxxxxxxxxxx> writes: > This patch separates block bitmap and buddy bitmap freeing in order to > udpate block bitmap with ext4_mb_mark_context in following patch. > The reason why this can be sperated is explained in previous submit. > Put the explanation here to simplify the code archeology to > ext4_group_add_blocks(): > > Separated freeing is safe with concurrent allocation as long as: > 1. Firstly allocate block in buddy bitmap, and then in block bitmap. > 2. Firstly free block in block bitmap, and then buddy bitmap. > Then freed block will only be available to allocation when both buddy > bitmap and block bitmap are updated by freeing. > Allocation obeys rule 1 already, just do sperated freeing with rule 2. > > Separated freeing has no race with generate_buddy as: > Once ext4_mb_load_buddy_gfp is executed successfully, the update-to-date > buddy page can be found in sbi->s_buddy_cache and no more buddy > initialization of the buddy page will be executed concurrently until > buddy page is unloaded. As we always do free in "load buddy, free, > unload buddy" sequence, separated freeing has no race with generate_buddy. > > Signed-off-by: Kemeng Shi <shikemeng@xxxxxxxxxxxxxxx> > --- > fs/ext4/mballoc.c | 54 +++++++++++++++++++++++------------------------ > 1 file changed, 26 insertions(+), 28 deletions(-) > Looks good to me. Please feel free to add - Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@xxxxxxxxx>
