On Wed, 30 Jul 2025, LongPing Wei wrote:
> Hi, Mikulas
>
> For example:
>
> F2FS/EXT4
> ----
> dm-thin
> ----
> dm-thin-pool
> ----
> pool data
>
> 1. There is a block of testfile in F2FS/EXT4.
> 2. The offset of this block is n.
> 3. The position in the dm-thin device is m.
> 4. The position in the pool data is x.
>
> The IV is only be affectted by offset in file and the ino of this file.
>
> Even if we change m by defrag or change x by COW, IV won't changed.
>
> The upper layer will only read the decrypted blocks with the same key and
> continous IV in one bio.
>
> If the upper layer read the full chunk with mixed blocks for GC purpose, key
> and IV won't be passed in. Then the upper layer just get the encrypted blocks.
>
> LongPing Wei
Yes - so if the IV is calculated from inode and offset, it seems safe to
support it on dm-thin. So, I accepted the patch (and increased the target
version).
BTW. what happens if someone uses FALLOC_FL_COLLAPSE_RANGE or
FALLOC_FL_INSERT_RANGE on a file with inline encryption? That changes file
offsets of existing data, so it should be disallowed when using inline
encryption - but I don't see a test for this in the functions
ext4_collapse_range and ext4_insert_range.
Mikulas
