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 <[email protected]> > --- > 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
