diff options
author | Eric Biggers <ebiggers@google.com> | 2020-09-16 21:11:32 -0700 |
---|---|---|
committer | Eric Biggers <ebiggers@google.com> | 2020-09-22 06:48:42 -0700 |
commit | 9dad5feb49a5c3b99838b102555cdbedf244320a (patch) | |
tree | ef8b842a656937687c80f5104a924a6a11bf9997 /samples | |
parent | 4cc1a3e7e8520226c62019553b18f1c12388a99d (diff) | |
download | linux-9dad5feb49a5c3b99838b102555cdbedf244320a.tar.bz2 |
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 'samples')
0 files changed, 0 insertions, 0 deletions