Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp955610ybk; Fri, 15 May 2020 19:04:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhUdxNrkP08iZQWb6rkBoN5vWs5Epnjcmoyk8NBd6WyCpttR9biHm82UUwF1l949udREOu X-Received: by 2002:a17:907:1199:: with SMTP id uz25mr5967496ejb.24.1589594645396; Fri, 15 May 2020 19:04:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589594645; cv=none; d=google.com; s=arc-20160816; b=FLXxTMhnjsEx1V7FTXxrZLo3XMiMByQPwxEMTOHAFvkplNSVcaJ1xguuXOCAr7hIGs KPSjFDVvXGPxWU2pX5Cp1OA/2Ojmo+/dJw+CbPpH9pa5vG0JEQxQ7CuTSPR1HWDq+v65 S7d8pbgDBWtP9mrBy+RWTk3wEKyESHN3qaV+j3fjw6YTHzuSanbtxbjo7Q6xIKyRrzy7 W1z0lJ8biroF+ReDfw/Bb1hGAnJj2JZExda8/rvzUfwr7fPbdfpD0Eli2TY4KxsECDxx Igyu7AUtAy5Plx0MzyWeYH4lTBHsBsXpcrX62TuEWxLfnpeYIb/9+YHlVDyJYhdAq+gh pMsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=rzRtsUY9ZFEqN3Hh1XJTV7R1hQ++rCnFiR9WSPiFeQ0=; b=GX/ZIY0ksE97jhi9aqId8QLffBRYKjG0L4CjiZWQVCiTW4B6uq2ScUtUlOVPtbpjmI bjimEm0gugY6qoUpbT/hMJLm1FphYk/7eM4rkLvISY9hRLzzl2PdqR3oDdY4khwDFIEa uJmWtIwkCWWEM4YrmGtHYuq9WTCJWVuSM0vyJbhLJE3K5Cq4InD6O2MDujV89zU5ct4U x8Ha/xkMjiegF5tU82yVNYl+DOmrE6sxO4AoXI9P7TQLdpqaBO8Wiyp6/QHjtD0UVyZ1 cqgLhbrb8DKyS5r0M/K0f0LTaFZ9QqiTGbEWIDHDHV7lJhy/5pqL3XC2FMoL4wMJEReE mnCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=opoNd5ub; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p20si2398906ejf.49.2020.05.15.19.03.32; Fri, 15 May 2020 19:04:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=opoNd5ub; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726553AbgEPCC4 (ORCPT + 99 others); Fri, 15 May 2020 22:02:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:49430 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726541AbgEPCC4 (ORCPT ); Fri, 15 May 2020 22:02:56 -0400 Received: from sol.localdomain (c-107-3-166-239.hsd1.ca.comcast.net [107.3.166.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 047B120671; Sat, 16 May 2020 02:02:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589594575; bh=udGZ/mluE2geb6BB8HoGVq2HXLCwXdDkVOVFXYUtwhw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=opoNd5ub3tJqB7aomfT3jNItncU2GVNtSneh6kO9sM8U/OsKCHyX7JqIq+jJpqax/ btQ+J2EQ7PGpxh1xYxSlW0mk6vCLoyVaq0JcjUGxjb5dUcLDW3n3chvxw55ZDoxAGo 3N4Lkt0uGqa3OgAYoiVezqJold1tfxIkFNtpOYf4= Date: Fri, 15 May 2020 19:02:53 -0700 From: Eric Biggers To: ira.weiny@intel.com Cc: linux-ext4@vger.kernel.org, Andreas Dilger , "Theodore Y. Ts'o" , Jan Kara , Al Viro , Dan Williams , Dave Chinner , Christoph Hellwig , Jeff Moyer , "Darrick J. Wong" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/9] fs/ext4: Disallow encryption if inode is DAX Message-ID: <20200516020253.GG1009@sol.localdomain> References: <20200513054324.2138483-1-ira.weiny@intel.com> <20200513054324.2138483-4-ira.weiny@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200513054324.2138483-4-ira.weiny@intel.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, May 12, 2020 at 10:43:18PM -0700, ira.weiny@intel.com wrote: > From: Ira Weiny > > 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 > > --- > 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