On Tue, Feb 07, 2023 at 10:57:08AM -0800, Linus Torvalds wrote:

On Tue, Feb 7, 2023 at 10:36 AM Eric Biggers [off-list ref] wrote:

quoted

Also note that keys are normally added using an ioctl, which can only be
executed after the filesystem was mounted.  The only exception is the key
associated with the "test_dummy_encryption" mount option.

Could we perhaps then replace the

                fscrypt_destroy_keyring(s);

with a more specific

                fscrypt_destroy_dummy_keyring(s);

thing, that would only handle the dummy encryption case?

Sure, they would still need to do most of the same things though.

Or could we just *fix* the dummy encryption test to actually work like
real encryption cases, so that it doesn't have this bogus case?

We've wanted to do that for a very long time, but there never has been a way to
actually do it.  Especially with the filesystem-level keyring now, if the kernel
doesn't automatically add the key for test_dummy_encryption, then userspace
would have to do it *every time it mounts the filesystem*.

The point of the "test_dummy_encryption" mount option is that you can just add
it to the mount options and run existing tests, such as a full run of xfstests,
and test all the encrypted I/O paths that way.  Which is extremely useful; it
wouldn't really be possible to properly test the encryption feature without it.

So that's why we've gone through some pain to keep "test_dummy_encryption"
working over time.

Now, it's possible that "the kernel automatically adds the key for
test_dummy_encryption" could be implemented a bit differently.  It maybe could
be done at the last minute, when the key is being looked for due to a user
filesystem operation, instead of during the mount itself.  That would eliminate
the need to call fscrypt_destroy_keyring() from __put_super(), which would avoid
the issue being discussed here.  I'll see if there's a good way to do that.

- Eric