On Thu, Jul 31, 2025 at 06:04:52PM +0200, Mikulas Patocka wrote: > > > 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.
This seems to be a question about fscrypt, not about inline encryption per se. FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_INSERT_RANGE fail with EOPNOTSUPP on encrypted files, as is documented in Documentation/filesystems/fscrypt.rst. For ext4, the check happens at the beginning of ext4_fallocate(). - Eric
