[RFC PATCH v3 6/9] tests: adjust generic/429 for extent encryption

[Sweet Tea Dorminy <sweettea-kernel@dorminy.me>]

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(+)

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
-- 
2.41.0