Skip to content
  • Eric Biggers's avatar
    4a4b8721
    fscrypt: simplify master key locking · 4a4b8721
    Eric Biggers authored
    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 a992b20c ("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 d3ec10aa ("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: default avatarEric Biggers <ebiggers@google.com>
    4a4b8721
    fscrypt: simplify master key locking
    Eric Biggers authored
    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 a992b20c ("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 d3ec10aa ("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: default avatarEric Biggers <ebiggers@google.com>
Loading