summaryrefslogtreecommitdiff
path: root/fs/crypto/fscrypt_private.h
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2020-09-17 07:11:32 +0300
committerEric Biggers <ebiggers@google.com>2020-09-22 16:48:42 +0300
commit9dad5feb49a5c3b99838b102555cdbedf244320a (patch)
treeef8b842a656937687c80f5104a924a6a11bf9997 /fs/crypto/fscrypt_private.h
parent4cc1a3e7e8520226c62019553b18f1c12388a99d (diff)
downloadlinux-9dad5feb49a5c3b99838b102555cdbedf244320a.tar.xz
fscrypt: stop pretending that key setup is nofs-safe
fscrypt_get_encryption_info() has never actually been safe to call in a context that needs GFP_NOFS, since it calls crypto_alloc_skcipher(). crypto_alloc_skcipher() isn't GFP_NOFS-safe, even if called under memalloc_nofs_save(). This is because it may load kernel modules, and also because it internally takes crypto_alg_sem. Other tasks can do GFP_KERNEL allocations while holding crypto_alg_sem for write. The use of fscrypt_init_mutex isn't GFP_NOFS-safe either. So, stop pretending that fscrypt_get_encryption_info() is nofs-safe. I.e., when it allocates memory, just use GFP_KERNEL instead of GFP_NOFS. Note, another reason to do this is that GFP_NOFS is deprecated in favor of using memalloc_nofs_save() in the proper places. Acked-by: Jeff Layton <jlayton@kernel.org> Link: https://lore.kernel.org/r/20200917041136.178600-10-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
Diffstat (limited to 'fs/crypto/fscrypt_private.h')
0 files changed, 0 insertions, 0 deletions