On Sat 25-10-25 11:22:10, libaokun@huaweicloud.com wrote:
> From: Baokun Li <libaokun1@huawei.com>
>
> We use EXT4_BAD_INO for the buddy cache inode number. This inode is not
> accessed via __ext4_new_inode() or __ext4_iget(), meaning
> ext4_set_inode_mapping_order() is not called to set its folio order range.
>
> However, future block size greater than page size support requires this
> inode to support large folios, and the buddy cache code already handles
> BS > PS. Therefore, ext4_set_inode_mapping_order() is now explicitly
> called for this specific inode to set its folio order range.
>
> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
Looks good. Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/ext4/mballoc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 31f4c7d65eb4..155c43ff2bc2 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -3493,6 +3493,8 @@ static int ext4_mb_init_backend(struct super_block *sb)
> * this will avoid confusion if it ever shows up during debugging. */
> sbi->s_buddy_cache->i_ino = EXT4_BAD_INO;
> EXT4_I(sbi->s_buddy_cache)->i_disksize = 0;
> + ext4_set_inode_mapping_order(sbi->s_buddy_cache);
> +
> for (i = 0; i < ngroups; i++) {
> cond_resched();
> desc = ext4_get_group_desc(sb, i, NULL);
> --
> 2.46.1
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR