On Fri, Jul 22, 2022 at 06:03:49PM +0200, Christoph Hellwig wrote: > > To avoid that, I think we could go through and evict all the > > blk_crypto_keys (i.e. call fscrypt_destroy_prepared_key() on the > > fscrypt_prepared_keys embedded in each fscrypt_master_key) during the > > unmount itself, separating it from the destruction of the key objects > > from the keyring subsystem's perspective. That could happen in the > > moved call to fscrypt_sb_free(). Note: for iterating through the keys in ->s_master_keys, I'd try something like assoc_array_iterate(&sb->s_master_keys->keys, fscrypt_teardown_key, sb) > > I'll give this a try. > > What would be a good test suite or set of tests to make sure I don't > break fscrypt operation? You can run xfstests on ext4 and f2fs with "-g encrypt", both with and without the inlinecrypt mount option. https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#tests shows the commands to do this with kvm-xfstests, but it can also be done with regular xfstests. Note that for the inlinecrypt mount option to work you'll need a kernel with CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y and CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y. There are relevant things that aren't tested by this, such as f2fs's multi-device support and whether the blk-crypto keys really get evicted, but that's the best we have. - Eric
