Re: [PATCH v2 20/20] btrfs: implement fscrypt ioctls

David Sterba
2022-09-07T21:38:58Z

On Mon, Sep 05, 2022 at 08:35:35PM -0400, Sweet Tea Dorminy wrote:
> From: Omar Sandoval <osandov@osandov.com>
>
> These ioctls allow encryption to be set up.
>
> Signed-off-by: Omar Sandoval <osandov@osandov.com>
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> ---
> fs/btrfs/ioctl.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 708e514aca25..ea1c14b26206 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -5457,6 +5457,34 @@ long btrfs_ioctl(struct file *file, unsigned int
> return btrfs_ioctl_get_fslabel(fs_info, argp);
> case FS_IOC_SETFSLABEL:
> return btrfs_ioctl_set_fslabel(file, argp);
> + case FS_IOC_SET_ENCRYPTION_POLICY: {
> + if (!IS_ENABLED(CONFIG_FS_ENCRYPTION))
> + return -EOPNOTSUPP;
> + if (sb_rdonly(fs_info->sb))
> + return -EROFS;
> + /*
> + * If we crash before we commit, nothing encrypted could have
> + * been written so it doesn't matter whether the encrypted
> + * state persists.
> + */
> + btrfs_set_fs_incompat(fs_info, FSCRYPT);
> + return fscrypt_ioctl_set_policy(file, (const void __user *)arg);
> + }
> + case FS_IOC_GET_ENCRYPTION_POLICY:
> + return fscrypt_ioctl_get_policy(file, (void __user *)arg);
> + case FS_IOC_GET_ENCRYPTION_POLICY_EX:
> + return fscrypt_ioctl_get_policy_ex(file, (void __user *)arg);
> + case FS_IOC_ADD_ENCRYPTION_KEY:
> + return fscrypt_ioctl_add_key(file, (void __user *)arg);
> + case FS_IOC_REMOVE_ENCRYPTION_KEY:
> + return fscrypt_ioctl_remove_key(file, (void __user *)arg);
> + case FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS:
> + return fscrypt_ioctl_remove_key_all_users(file,
> + (void __user *)arg);
> + case FS_IOC_GET_ENCRYPTION_KEY_STATUS:
> + return fscrypt_ioctl_get_key_status(file, (void __user *)arg);
> + case FS_IOC_GET_ENCRYPTION_NONCE:
> + return fscrypt_ioctl_get_nonce(file, (void __user *)arg);

I've looked what ext4 does for the ioctls and there's a check before
each case if the feature is supported, do we need something like that as
well?

> case FITRIM:
> return btrfs_ioctl_fitrim(fs_info, argp);
> case BTRFS_IOC_SNAP_CREATE:
> --
> 2.35.1