@@ -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
@@ -23,6 +23,10 @@ _require_scratch_encryption -v 2
_scratch_mkfs_encrypted &>> $seqres.full
_scratch_mount
+if [ $FSTYP = "btrfs" ]; then
+ _notrun "extent encryption locks open files immediately on key removal"
+fi
+
test_with_policy_version()
{
local vers=$1
@@ -35,6 +35,10 @@ _require_command "$KEYCTL_PROG" keyctl
_scratch_mkfs_encrypted &>> $seqres.full
_scratch_mount
+if [ $FSTYP = "btrfs" ]; then
+ _notrun "extent encryption locks open files immediately on key removal"
+fi
+
dir=$SCRATCH_MNT/dir
runtime=$((4 * TIME_FACTOR))
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 key is removed, even if there's an open file using it, that file immediately becomes unreadable and unwritable. This contradicts the assumptions in three tests. In generic/429, we can issue a sync to push the dirty data to the filesystem before dropping the key. However, generic/580 explicitly wants to write data after dropping the key, and generic/595 wants to intermingle key removals and data writes, which is unpredictable in effect. So just disable those two. Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me> --- tests/generic/429 | 6 ++++++ tests/generic/580 | 4 ++++ tests/generic/595 | 4 ++++ 3 files changed, 14 insertions(+)