Re: [PATCH 03/25] ext4: remove PAGE_SIZE checks for rec_len conversion

[Jan Kara <jack@suse.cz>]

On Sat 25-10-25 11:21:59, libaokun@huaweicloud.com wrote:
> From: Baokun Li <libaokun1@huawei.com>
> 
> Previously, ext4_rec_len_(to|from)_disk only performed complex rec_len
> conversions when PAGE_SIZE >= 65536 to reduce complexity.
> 
> However, we are soon to support file system block sizes greater than
> page size, which makes these conditional checks unnecessary. Thus, these
> checks are now removed.
> 
> 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/ext4.h | 12 ------------
>  1 file changed, 12 deletions(-)
> 
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 24c414605b08..93c2bf4d125a 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -2464,28 +2464,19 @@ static inline unsigned int ext4_dir_rec_len(__u8 name_len,
>  	return (rec_len & ~EXT4_DIR_ROUND);
>  }
>  
> -/*
> - * If we ever get support for fs block sizes > page_size, we'll need
> - * to remove the #if statements in the next two functions...
> - */
>  static inline unsigned int
>  ext4_rec_len_from_disk(__le16 dlen, unsigned blocksize)
>  {
>  	unsigned len = le16_to_cpu(dlen);
>  
> -#if (PAGE_SIZE >= 65536)
>  	if (len == EXT4_MAX_REC_LEN || len == 0)
>  		return blocksize;
>  	return (len & 65532) | ((len & 3) << 16);
> -#else
> -	return len;
> -#endif
>  }
>  
>  static inline __le16 ext4_rec_len_to_disk(unsigned len, unsigned blocksize)
>  {
>  	BUG_ON((len > blocksize) || (blocksize > (1 << 18)) || (len & 3));
> -#if (PAGE_SIZE >= 65536)
>  	if (len < 65536)
>  		return cpu_to_le16(len);
>  	if (len == blocksize) {
> @@ -2495,9 +2486,6 @@ static inline __le16 ext4_rec_len_to_disk(unsigned len, unsigned blocksize)
>  			return cpu_to_le16(0);
>  	}
>  	return cpu_to_le16((len & 65532) | ((len >> 16) & 3));
> -#else
> -	return cpu_to_le16(len);
> -#endif
>  }
>  
>  /*
> -- 
> 2.46.1
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR