Re: [PATCH v3 6/7] btrfs-progs: check: update inline extent length checking
Daniel Vacek <[email protected]> Wed, 8 Jul 2026 07:00:51 +0200
| Newsgroups | org.kernel.vger.linux-fscrypt,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAPjX3FfsH7tG3jy3nezrr0371EWsYx1hJEkT+b8CQF2iaMrMoQ@mail.gmail.com> |
On Wed, 8 Jul 2026 at 00:43, Qu Wenruo <[email protected]> wrote: > =E5=9C=A8 2026/7/7 23:57, Daniel Vacek =E5=86=99=E9=81=93: > > From: Sweet Tea Dorminy <[email protected]> > > > > As part of the encryption changes, encrypted inline file extents record > > their actual data length in ram_bytes, like compressed inline file > > extents, while the item's length records the actual size. As such, > > encrypted inline extents must be treated like compressed ones for > > inode length consistency checking. > > > > Signed-off-by: Sweet Tea Dorminy <[email protected]> > > Signed-off-by: Daniel Vacek <[email protected]> > > --- > > check/main.c | 31 +++++++++++++++++-------------- > > 1 file changed, 17 insertions(+), 14 deletions(-) > > > > diff --git a/check/main.c b/check/main.c > > index 9447b01e..cadcfef0 100644 > > --- a/check/main.c > > +++ b/check/main.c > > @@ -1720,9 +1720,7 @@ static int process_file_extent(struct btrfs_root = *root, > > u64 disk_bytenr =3D 0; > > u64 extent_offset =3D 0; > > u64 mask =3D gfs_info->sectorsize - 1; > > - u32 max_inline_size =3D min_t(u32, mask, > > - BTRFS_MAX_INLINE_DATA_SIZE(gfs_info)); > > - u8 compression; > > + u8 compression, encryption; > > int extent_type; > > int ret; > > > > @@ -1747,25 +1745,30 @@ static int process_file_extent(struct btrfs_roo= t *root, > > fi =3D btrfs_item_ptr(eb, slot, struct btrfs_file_extent_item); > > extent_type =3D btrfs_file_extent_type(eb, fi); > > compression =3D btrfs_file_extent_compression(eb, fi); > > + encryption =3D btrfs_file_extent_encryption(eb, fi); > > > > if (extent_type =3D=3D BTRFS_FILE_EXTENT_INLINE) { > > - num_bytes =3D btrfs_file_extent_ram_bytes(eb, fi); > > - if (num_bytes =3D=3D 0) > > + u32 max_inline_size =3D min_t(u32, mask, > > + BTRFS_MAX_INLINE_DATA_SIZE(gfs_in= fo)); > > + u64 num_disk_bytes =3D btrfs_file_extent_inline_item_len(= eb, slot); > > + u64 num_decoded_bytes =3D btrfs_file_extent_ram_bytes(eb,= fi); > > + if (num_decoded_bytes =3D=3D 0) > > rec->errors |=3D I_ERR_BAD_FILE_EXTENT; > > - if (compression) { > > - if (btrfs_file_extent_inline_item_len(eb, slot) > > > - max_inline_size || > > - num_bytes > gfs_info->sectorsize) > > + if (compression || encryption) { > > + if (encryption) > > + max_inline_size =3D min_t(u32, gfs_info->= sectorsize, > > + BTRFS_MAX_INLINE_DATA_SIZE(gfs_in= fo)); > > The change looks good to me now. > > However I'm just curious, is it possible to limit the encrypted data > size to sectorsize-1? > > Or it is some fscrypt limit internal requiring a power-of-2 size or just > lack of interface? The encrypted data has the granularity of the cipher block size. With AES, it's 16 bytes. Hence why. Eventually the best we could do would be sectorsize-16. But then, if the cipher changed in the future... --nX > Anyway I won't object this new change. > > Thanks, > Qu > > > + if (num_disk_bytes > max_inline_size || > > + num_decoded_bytes > gfs_info->sectorsize) > > rec->errors |=3D I_ERR_FILE_EXTENT_TOO_LA= RGE; > > } else { > > - if (num_bytes > max_inline_size) > > + if (num_decoded_bytes > max_inline_size) > > rec->errors |=3D I_ERR_FILE_EXTENT_TOO_LA= RGE; > > - if (btrfs_file_extent_inline_item_len(eb, slot) != =3D > > - num_bytes) > > + if (num_disk_bytes !=3D num_decoded_bytes) > > rec->errors |=3D I_ERR_INLINE_RAM_BYTES_W= RONG; > > } > > - rec->found_size +=3D num_bytes; > > - num_bytes =3D (num_bytes + mask) & ~mask; > > + rec->found_size +=3D num_decoded_bytes; > > + num_bytes =3D (num_decoded_bytes + mask) & ~mask; > > } else if (extent_type =3D=3D BTRFS_FILE_EXTENT_REG || > > extent_type =3D=3D BTRFS_FILE_EXTENT_PREALLOC) { > > num_bytes =3D btrfs_file_extent_num_bytes(eb, fi); >