This series eliminates the call to fscrypt_destroy_keyring() from __put_super(), which is causing confusion because it looks like (but actually isn't) a sleep-in-atomic bug. See the thread "block: sleeping in atomic warnings", i.e. https://lore.kernel.org/linux-fsdevel/CAHk-=wg6ohuyrmLJYTfEpDbp2Jwnef54gkcpZ3-BYgy4C6UxRQ@xxxxxxxxxxxxxx and its responses. To do this, this series makes it so that the key associated with the "test_dummy_encryption" mount option is added on-demand when files are accessed, instead of immediately when the filesystem is mounted. I was going back and forth between this solution and instead having ext4 and f2fs call fscrypt_destroy_keyring() on ->fill_super failure. (Or using Linus's suggestion of adding the test dummy key as the very last step of ->fill_super.) It does seem ideal to add the key at mount time, but I ended up going with this solution instead because it reduces the number of things the individual filesystems have to handle. Eric Biggers (5): fscrypt: add the test dummy encryption key on-demand ext4: stop calling fscrypt_add_test_dummy_key() f2fs: stop calling fscrypt_add_test_dummy_key() fs/super.c: stop calling fscrypt_destroy_keyring() from __put_super() fscrypt: clean up fscrypt_add_test_dummy_key() fs/crypto/fscrypt_private.h | 4 ++++ fs/crypto/keyring.c | 26 +++++++------------------- fs/crypto/keysetup.c | 23 +++++++++++++++++++++-- fs/crypto/policy.c | 3 +-- fs/ext4/super.c | 13 +------------ fs/f2fs/super.c | 6 ------ fs/super.c | 1 - include/linux/fscrypt.h | 9 --------- 8 files changed, 34 insertions(+), 51 deletions(-) base-commit: 6d796c50f84ca79f1722bb131799e5a5710c4700 -- 2.39.1
