fscrypt: simplify master key locking
authorEric Biggers <ebiggers@google.com>
Fri, 4 Nov 2022 23:37:58 +0000 (16:37 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 10 Nov 2022 17:14:24 +0000 (18:14 +0100)
commit092401142b959de39ba3db8425cffd9b30f7dea9
tree1336bfae8fe3cf8be27f7051c4b04a7a9eef5f76
parent54c13d3520ef5b57f5a11cac883fce05d9ce6b52
fscrypt: simplify master key locking

commit 4a4b8721f1a5e4b01e45b3153c68d5a1014b25de upstream.

The stated reasons for separating fscrypt_master_key::mk_secret_sem from
the standard semaphore contained in every 'struct key' no longer apply.

First, due to commit a992b20cd4ee ("fscrypt: add
fscrypt_prepare_new_inode() and fscrypt_set_context()"),
fscrypt_get_encryption_info() is no longer called from within a
filesystem transaction.

Second, due to commit d3ec10aa9581 ("KEYS: Don't write out to userspace
while holding key semaphore"), the semaphore for the "keyring" key type
no longer ranks above page faults.

That leaves performance as the only possible reason to keep the separate
mk_secret_sem.  Specifically, having mk_secret_sem reduces the
contention between setup_file_encryption_key() and
FS_IOC_{ADD,REMOVE}_ENCRYPTION_KEY.  However, these ioctls aren't
executed often, so this doesn't seem to be worth the extra complexity.

Therefore, simplify the locking design by just using key->sem instead of
mk_secret_sem.

Link: https://lore.kernel.org/r/20201117032626.320275-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/crypto/fscrypt_private.h
fs/crypto/hooks.c
fs/crypto/keyring.c
fs/crypto/keysetup.c