summaryrefslogtreecommitdiff
path: root/fs/ext4
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2020-11-17 06:26:26 +0300
committerEric Biggers <ebiggers@google.com>2020-11-25 02:29:47 +0300
commit4a4b8721f1a5e4b01e45b3153c68d5a1014b25de (patch)
treef9e59b463ec9d631ef1624450405a29e51befa79 /fs/ext4
parent234f1b7f8daf112655c87f75ae8932564f871225 (diff)
downloadlinux-4a4b8721f1a5e4b01e45b3153c68d5a1014b25de.tar.xz
fscrypt: simplify master key locking
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>
Diffstat (limited to 'fs/ext4')
0 files changed, 0 insertions, 0 deletions