[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200516020253.GG1009@sol.localdomain>
Date: Fri, 15 May 2020 19:02:53 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: ira.weiny@...el.com
Cc: linux-ext4@...r.kernel.org,
Andreas Dilger <adilger.kernel@...ger.ca>,
"Theodore Y. Ts'o" <tytso@....edu>, Jan Kara <jack@...e.cz>,
Al Viro <viro@...iv.linux.org.uk>,
Dan Williams <dan.j.williams@...el.com>,
Dave Chinner <david@...morbit.com>,
Christoph Hellwig <hch@....de>, Jeff Moyer <jmoyer@...hat.com>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/9] fs/ext4: Disallow encryption if inode is DAX
On Tue, May 12, 2020 at 10:43:18PM -0700, ira.weiny@...el.com wrote:
> From: Ira Weiny <ira.weiny@...el.com>
>
> Encryption and DAX are incompatible. Changing the DAX mode due to a
> change in Encryption mode is wrong without a corresponding
> address_space_operations update.
>
> Make the 2 options mutually exclusive by returning an error if DAX was
> set first.
>
> Furthermore, clarify the documentation of the exclusivity and how that
> will work.
>
> Signed-off-by: Ira Weiny <ira.weiny@...el.com>
>
> ---
> Changes:
> remove WARN_ON_ONCE
> Add documentation to the encrypt doc WRT DAX
> ---
> Documentation/filesystems/fscrypt.rst | 4 +++-
> fs/ext4/super.c | 10 +---------
> 2 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst
> index aa072112cfff..1475b8d52fef 100644
> --- a/Documentation/filesystems/fscrypt.rst
> +++ b/Documentation/filesystems/fscrypt.rst
> @@ -1038,7 +1038,9 @@ astute users may notice some differences in behavior:
> - The ext4 filesystem does not support data journaling with encrypted
> regular files. It will fall back to ordered data mode instead.
>
> -- DAX (Direct Access) is not supported on encrypted files.
> +- DAX (Direct Access) is not supported on encrypted files. Attempts to enable
> + DAX on an encrypted file will fail. Mount options will _not_ enable DAX on
> + encrypted files.
>
> - The st_size of an encrypted symlink will not necessarily give the
> length of the symlink target as required by POSIX. It will actually
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index bf5fcb477f66..9873ab27e3fa 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1320,7 +1320,7 @@ static int ext4_set_context(struct inode *inode, const void *ctx, size_t len,
> if (inode->i_ino == EXT4_ROOT_INO)
> return -EPERM;
>
> - if (WARN_ON_ONCE(IS_DAX(inode) && i_size_read(inode)))
> + if (IS_DAX(inode))
> return -EINVAL;
>
> res = ext4_convert_inline_data(inode);
> @@ -1344,10 +1344,6 @@ static int ext4_set_context(struct inode *inode, const void *ctx, size_t len,
> ext4_set_inode_flag(inode, EXT4_INODE_ENCRYPT);
> ext4_clear_inode_state(inode,
> EXT4_STATE_MAY_INLINE_DATA);
> - /*
> - * Update inode->i_flags - S_ENCRYPTED will be enabled,
> - * S_DAX may be disabled
> - */
> ext4_set_inode_flags(inode);
> }
> return res;
> @@ -1371,10 +1367,6 @@ static int ext4_set_context(struct inode *inode, const void *ctx, size_t len,
> ctx, len, 0);
> if (!res) {
> ext4_set_inode_flag(inode, EXT4_INODE_ENCRYPT);
> - /*
> - * Update inode->i_flags - S_ENCRYPTED will be enabled,
> - * S_DAX may be disabled
> - */
> ext4_set_inode_flags(inode);
> res = ext4_mark_inode_dirty(handle, inode);
> if (res)
I'm confused by the ext4_set_context() change.
ext4_set_context() is only called when FS_IOC_SET_ENCRYPTION_POLICY sets an
encryption policy on an empty directory, *or* when a new inode (regular, dir, or
symlink) is created in an encrypted directory (thus inheriting encryption from
its parent).
So when is it reachable when IS_DAX()? Is the issue that the DAX flag can now
be set on directories? The commit message doesn't seem to be talking about
directories. Is the behavior we want is that on an (empty) directory with the
DAX flag set, FS_IOC_SET_ENCRYPTION_POLICY should fail with EINVAL?
I don't see why the i_size_read(inode) check is there though, so I think you're
at least right to remove that.
- Eric
Powered by blists - more mailing lists