| Message ID | e891b87b67add59ed8816575de8c6c7aeb3bf0ac.1688929294.git.sweettea-kernel@dorminy.me (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fstests: add btrfs encryption testing | expand |
diff --git a/tests/generic/429 b/tests/generic/429 index 2cf12316..1d26deda 100755 --- a/tests/generic/429 +++ b/tests/generic/429 @@ -68,6 +68,12 @@ show_directory_with_key() show_file_contents } +# btrfs needs to have dirty data pushed into it before session keyring +# is unlinked, as it doesn't set up the data encryption key until then. +if [ "$FSTYP" = "btrfs" ]; then + sync +fi + # View the directory without the encryption key. The plaintext names shouldn't # exist, but 'cat' each to verify this, which also should create negative # dentries. The no-key names are unpredictable by design, but verify that the
Extent encryption is different from the existing inode-based encryption insofar as it only generates encryption keys for data encryption at the moment at which the data is written. This means that when a session key is removed, even if there's an open file using it, that file immediately becomes unreadable and unwritable. This isn't an issue for non-session keys, which are soft deleted by fscrypt and stick around until there are no more open files with extent encryption using them. But for session keys, which are managed by the kernel keyring directly instead of through fscrypt, when they're removed they're removed. generic/429 uses session keys and expects to use the written data after key removal; while it's not quite what the test means for other filesystems, most of the test is still meaningful if we push the dirty data into the filesystem with a sync before dropping the key. Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> --- tests/generic/429 | 6 ++++++ 1 file changed, 6 insertions(+)