On Tue, Aug 08, 2023 at 01:08:29PM -0400, Sweet Tea Dorminy wrote: > For v1 encryption policies using per-session keys, the thread which > opens the inode and therefore initializes the encryption info is part of > the session, so it can get the key from the session keyring. However, > for extent encryption, the extent infos are likely loaded from a > different thread, which does not have access to the session keyring. > This change saves the credentials of the inode opening thread and reuses > those credentials temporarily when dealing with extent infos, allowing > finding the encryption key correctly. > > v1 encryption policies using per-session keys should probably not exist > for new usages such as extent encryption, but this makes more tests > work without change; maybe the right answer is to disallow v1 session > keys plus extent encryption and deal with editing tests to not use v1 > session encryption so much. > > Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@xxxxxxxxxx> I don't understand why you would need to look up the master key for each extent. The master key should just come from the inode, which the master key was already looked up for when the file was opened. - Eric
|