Re: [PATCH 10/11] fscrypt: pass a byte length to fscrypt_zeroout_range

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Nov 18, 2025 at 07:21:53AM +0100, Christoph Hellwig wrote:
> Range lengths are usually expressed as bytes in the VFS, switch
> fscrypt_zeroout_range to this convention.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/crypto/bio.c | 6 +++---
>  fs/ext4/inode.c | 3 ++-
>  fs/f2fs/file.c  | 2 +-
>  3 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/crypto/bio.c b/fs/crypto/bio.c
> index 235dd1c3d443..4e9893664c0f 100644
> --- a/fs/crypto/bio.c
> +++ b/fs/crypto/bio.c
> @@ -115,7 +115,7 @@ static int fscrypt_zeroout_range_inline_crypt(const struct inode *inode,
>   * @inode: the file's inode
>   * @pos: the first file logical offset (in bytes) to zero out
>   * @pblk: the first filesystem physical block to zero out
> - * @len: number of blocks to zero out
> + * @len: bytes to zero out
[...]
> int fscrypt_zeroout_range(const struct inode *inode, loff_t pos,                 
>                           sector_t sector, unsigned int len)

The type of 'len' is still unsigned int, so this reduces the maximum
length accepted by fscrypt_zeroout_range() from UINT32_MAX blocks to
UINT32_MAX bytes.  Is that really okay?

Both ext4 and f2fs call this from functions where they have the length
as a u32 number of logical blocks.  And of course both filesystems
support files longer than UINT32_MAX bytes.  So it's not clear to me.
ext4 extents have a smaller size limit, so maybe at least ext4 is okay.
But different extents can be contiguous and operated on together.  So
we'd have to check the callers of the callers, etc.

It would be safer to change the type to u64 and have the callers do
(u64)len_in_blocks << blockbits.

- Eric