On 7/7/23 19:36, Boris Burkov wrote:
Clear solution: enable direct encrypted IO :). I've removed this check altogether, thanks for the note.On Wed, Jun 28, 2023 at 08:35:24PM -0400, Sweet Tea Dorminy wrote:From: Omar Sandoval <osandov@xxxxxxxxxxx> Initially, only normal data extents, using the normal (non-direct) IO path, will be encrypted. This change forbids various other bits: - allows reflinking only if both inodes have the same encryption status - disables direct IO on encrypted inodes - disable inline data on encrypted inodes Signed-off-by: Omar Sandoval <osandov@xxxxxxxxxxx> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@xxxxxxxxxx> --- fs/btrfs/file.c | 4 ++-- fs/btrfs/inode.c | 3 ++- fs/btrfs/reflink.c | 7 +++++++ 3 files changed, 11 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 392bc7d512a0..354962a7dd72 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1502,7 +1502,7 @@ static ssize_t btrfs_direct_write(struct kiocb *iocb, struct iov_iter *from) goto relock; }- if (check_direct_IO(fs_info, from, pos)) {+ if (IS_ENCRYPTED(inode) || check_direct_IO(fs_info, from, pos)) { btrfs_inode_unlock(BTRFS_I(inode), ilock_flags); goto buffered; } @@ -3741,7 +3741,7 @@ static ssize_t btrfs_direct_read(struct kiocb *iocb, struct iov_iter *to) ssize_t read = 0; ssize_t ret;- if (fsverity_active(inode))+ if (IS_ENCRYPTED(inode) || fsverity_active(inode))What's different about fscrypt vs fsverity that makes the inode flag a good check for encryption while verity relies on the presence of the extra context metadata? Is the enable model not subject to the same race where S_VERITY gets set ahead of actually storing the verity info/item? I think it's fine for these "skip" cases, but I imagine if we have cases of "I want a fully ready encrypted file" the verity-style check could be better?
|