fscrypt: stop pretending that key setup is nofs-safe
authorEric Biggers <ebiggers@google.com>
Thu, 17 Sep 2020 04:11:32 +0000 (21:11 -0700)
committerEric Biggers <ebiggers@google.com>
Tue, 22 Sep 2020 13:48:42 +0000 (06:48 -0700)
commit9dad5feb49a5c3b99838b102555cdbedf244320a
treeef8b842a656937687c80f5104a924a6a11bf9997
parent4cc1a3e7e8520226c62019553b18f1c12388a99d
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>
fs/crypto/inline_crypt.c
fs/crypto/keysetup.c
fs/crypto/keysetup_v1.c