Re: [PATCH v3 6/7] btrfs-progs: check: update inline extent length checking
Qu Wenruo <[email protected]>
| Newsgroups | org.kernel.vger.linux-btrfs,org.kernel.vger.linux-fscrypt,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
在 2026/7/8 14:30, Daniel Vacek 写道: > On Wed, 8 Jul 2026 at 00:43, Qu Wenruo <[email protected]> wrote: >> 在 2026/7/7 23:57, Daniel Vacek 写道: >>> 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 = 0; >>> u64 extent_offset = 0; >>> u64 mask = gfs_info->sectorsize - 1; >>> - u32 max_inline_size = 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_root *root, >>> fi = btrfs_item_ptr(eb, slot, struct btrfs_file_extent_item); >>> extent_type = btrfs_file_extent_type(eb, fi); >>> compression = btrfs_file_extent_compression(eb, fi); >>> + encryption = btrfs_file_extent_encryption(eb, fi); >>> >>> if (extent_type == BTRFS_FILE_EXTENT_INLINE) { >>> - num_bytes = btrfs_file_extent_ram_bytes(eb, fi); >>> - if (num_bytes == 0) >>> + u32 max_inline_size = min_t(u32, mask, >>> + BTRFS_MAX_INLINE_DATA_SIZE(gfs_info)); >>> + u64 num_disk_bytes = btrfs_file_extent_inline_item_len(eb, slot); >>> + u64 num_decoded_bytes = btrfs_file_extent_ram_bytes(eb, fi); >>> + if (num_decoded_bytes == 0) >>> rec->errors |= 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 = min_t(u32, gfs_info->sectorsize, >>> + BTRFS_MAX_INLINE_DATA_SIZE(gfs_info)); >> >> 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... Thanks a lot, that explains the reason why we can not follow the old sectorsize - 1 limit. Thanks, Qu > > --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 |= I_ERR_FILE_EXTENT_TOO_LARGE; >>> } else { >>> - if (num_bytes > max_inline_size) >>> + if (num_decoded_bytes > max_inline_size) >>> rec->errors |= I_ERR_FILE_EXTENT_TOO_LARGE; >>> - if (btrfs_file_extent_inline_item_len(eb, slot) != >>> - num_bytes) >>> + if (num_disk_bytes != num_decoded_bytes) >>> rec->errors |= I_ERR_INLINE_RAM_BYTES_WRONG; >>> } >>> - rec->found_size += num_bytes; >>> - num_bytes = (num_bytes + mask) & ~mask; >>> + rec->found_size += num_decoded_bytes; >>> + num_bytes = (num_decoded_bytes + mask) & ~mask; >>> } else if (extent_type == BTRFS_FILE_EXTENT_REG || >>> extent_type == BTRFS_FILE_EXTENT_PREALLOC) { >>> num_bytes = btrfs_file_extent_num_bytes(eb, fi); >> >