All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ira Weiny <ira.weiny@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Eric Biggers <ebiggers@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@lst.de>, Jeff Moyer <jmoyer@redhat.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 7/8] fs/ext4: Introduce DAX inode flag
Date: Wed, 20 May 2020 11:34:04 -0700	[thread overview]
Message-ID: <20200520183404.GE3660833@iweiny-DESK2.sc.intel.com> (raw)
In-Reply-To: <20200520141138.GE30597@quack2.suse.cz>

On Wed, May 20, 2020 at 04:11:38PM +0200, Jan Kara wrote:
> On Tue 19-05-20 22:57:52, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> > 
> > Add a flag to preserve FS_XFLAG_DAX in the ext4 inode.
> > 
> > Set the flag to be user visible and changeable.  Set the flag to be
> > inherited.  Allow applications to change the flag at any time with the
> > exception of if VERITY or ENCRYPT is set.
> > 
> > Disallow setting VERITY or ENCRYPT if DAX is set.
> > 
> > Finally, on regular files, flag the inode to not be cached to facilitate
> > changing S_DAX on the next creation of the inode.
> > 
> > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> 
> The patch looks good to me. You can add:
> 
> Reviewed-by: Jan Kara <jack@suse.cz>
> 
> One comment below:
> 
> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> > index 5ba65eb0e2ef..be9713e898eb 100644
> > --- a/fs/ext4/super.c
> > +++ b/fs/ext4/super.c
> > @@ -1323,6 +1323,9 @@ static int ext4_set_context(struct inode *inode, const void *ctx, size_t len,
> >  	if (WARN_ON_ONCE(IS_DAX(inode) && i_size_read(inode)))
> >  		return -EINVAL;
> 
> AFAIU this check is here so that fscrypt_inherit_context() is able call us
> and we can clear S_DAX flag.

Basically yes that is true.  It is IMO somewhat convoluted because I think ext4
probably could have prevented S_DAX from being set in __ext4_new_inode() in the
first place.  But that is a clean up I was not prepared to make last night.

> So can't we rather move this below the
> EXT4_INODE_DAX check and change this to
> 
> 	IS_DAX(inode) && !(inode->i_flags & I_NEW)
> 
> ? Because as I'm reading the code now, this should never trigger?

I agree this should never trigger.  But I don't see how the order of the checks
maters much.  But changing this to !new is probably worth doing to make it
clear what we really mean here.

I think that is a follow on patch.  In addition, if we don't set S_DAX at all
in __ext4_new_inode() this check could then be what I had originally with the warn on.

	if (WARN_ON_ONCE(IS_DAX(inode)))
		...

... because it would be considered a bug to be setting DAX on inodes which are
going to be encrypted..

Ira

Something like this:  (compiled only)

commit 6cd5aed3cd9e2c10e3fb7c6dd23918580532f256 (HEAD -> lck-4071-b13-v4)
Author: Ira Weiny <ira.weiny@intel.com>
Date:   Wed May 20 11:32:50 2020 -0700

    RFC: do not set S_DAX on an inode which is going to be encrypted

diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 7941c140723f..be80cb639d74 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -844,6 +844,9 @@ struct inode *__ext4_new_inode(handle_t *handle, struct inode *dir,
                return ERR_PTR(-ENOMEM);
        ei = EXT4_I(inode);
 
+       if (encrypt)
+               ext4_set_inode_flag(inode, EXT4_INODE_ENCRYPT);
+
        /*
         * Initialize owners and quota early so that we don't have to account
         * for quota initialization worst case in standard inode creating
@@ -1165,6 +1168,7 @@ struct inode *__ext4_new_inode(handle_t *handle, struct inode *dir,
                err = fscrypt_inherit_context(dir, inode, handle, true);
                if (err)
                        goto fail_free_drop;
+               ext4_clear_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA);
        }
 
        if (!(ei->i_flags & EXT4_EA_INODE_FL)) {
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index be9713e898eb..099b87864f55 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1320,7 +1320,10 @@ 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)))
+       /* S_DAX should never be set here because encryption is not compatible
+        * with DAX
+        */
+       if (WARN_ON_ONCE(IS_DAX(inode)))
                return -EINVAL;
 
        if (ext4_test_inode_flag(inode, EXT4_INODE_DAX))
@@ -1337,22 +1340,11 @@ static int ext4_set_context(struct inode *inode, const void *ctx, size_t len,
         * being set on an existing inode in its own transaction.  Only in the
         * latter case should the "retry on ENOSPC" logic be used.
         */
-
        if (handle) {
                res = ext4_xattr_set_handle(handle, inode,
                                            EXT4_XATTR_INDEX_ENCRYPTION,
                                            EXT4_XATTR_NAME_ENCRYPTION_CONTEXT,
                                            ctx, len, 0);
-               if (!res) {
-                       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, false);
-               }
                return res;
        }


  reply	other threads:[~2020-05-20 18:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20  5:57 [PATCH V3 0/8] Enable ext4 support for per-file/directory DAX operations ira.weiny
2020-05-20  5:57 ` [PATCH V3 1/8] fs/ext4: Narrow scope of DAX check in setflags ira.weiny
2020-05-20  5:57 ` [PATCH V3 2/8] fs/ext4: Disallow verity if inode is DAX ira.weiny
2020-05-20  5:57 ` [PATCH V3 3/8] fs/ext4: Change EXT4_MOUNT_DAX to EXT4_MOUNT_DAX_ALWAYS ira.weiny
2020-05-20  5:57 ` [PATCH V3 4/8] fs/ext4: Update ext4_should_use_dax() ira.weiny
2020-05-20 13:37   ` Jan Kara
2020-05-20 19:40     ` Ira Weiny
2020-05-21 10:24       ` Jan Kara
2020-05-20  5:57 ` [PATCH V3 5/8] fs/ext4: Only change S_DAX on inode load ira.weiny
2020-05-20  5:57 ` [PATCH V3 6/8] fs/ext4: Make DAX mount option a tri-state ira.weiny
2020-05-20  5:57 ` [PATCH V3 7/8] fs/ext4: Introduce DAX inode flag ira.weiny
2020-05-20 14:11   ` Jan Kara
2020-05-20 18:34     ` Ira Weiny [this message]
2020-05-20 19:26   ` Andreas Dilger
2020-05-20 20:02     ` Ira Weiny
2020-05-20 20:55       ` Darrick J. Wong
2020-05-21  0:57         ` Andreas Dilger
2020-05-20  5:57 ` [PATCH V3 8/8] Documentation/dax: Update DAX enablement for ext4 ira.weiny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200520183404.GE3660833@iweiny-DESK2.sc.intel.com \
    --to=ira.weiny@intel.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=dan.j.williams@intel.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=ebiggers@kernel.org \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=jmoyer@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.