On 6/10/25 9:21 PM, Eric Biggers wrote:
blk-crypto-fallback runs at the top layer, so yes it's different from native inline encryption support where the encryption is done at the bottom. (But the results are the same from the filesystem's perspective, since native support only gets passed through and used when it would give the expected result.)
Although I'm not sure Keith realizes this, his patch may move encryption from the top of the block driver stack (a device mapper driver) to the
bottom (something else than a device mapper driver). This may happen because device mapper drivers do not split bios unless this is essential, e.g. because the LBA range of a bio spans more than one entry in the mapping table. Is my understanding correct that this is acceptable because the encryption IV is based on the file offset provided by the filesystem and not on the LBA where the data is written?
Just keep in mind that blk-crypto-fallback is meant to work on any block device (even ones that don't have a crypto profile, as the profile is just for the native support). So we do need to make sure it always gets invoked when needed.
I propose that we require that bio-based drivers must call bio_split_to_limits() to support inline encryption. Otherwise the approach of Keith's patch can't work. Does this seem reasonable to you? As far as I can tell upstream bio-based drivers already call bio_split_to_limits(). Thanks, Bart.
