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

[Anand Jain <anand.jain@oracle.com>]

On 09/08/2023 01:21, Sweet Tea Dorminy wrote:
> 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.	


  A whitespace error in this line.



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