On Mon, Apr 27, 2020 at 07:57:08PM -0700, Eric Biggers wrote: > Or maybe 'struct blk_ksm_keyslot' should contain a pointer to the > 'struct blk_crypto_key' rather than a copy of it? If we did that, then: > > - Each duplicate blk_crypto_key would use its own keyslot and not interfere > with > any others. > > - blk_crypto_evict_key() would be *required* to be called. > > - It would be a kernel bug if blk_crypto_evict_key() were called with any > pending I/O, so WARN_ON_ONCE() would be the right thing to do. > > - The hash function used to find a key's keyslot would be > hash_ptr(blk_crypto_key, ksm->log_slot_hashtable_size) instead of > SipHash(key=perboot_key, data=raw_key). > > I might be forgetting something; was there a reason we didn't do that? > It wouldn't be as robust against users forgetting to call > blk_crypto_evict_key(), but that would be a bug anyway.
The above sounds pretty sensible to me (but I'm everything but an expert in the area). _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
