All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: ira.weiny@intel.com, linux-kernel@vger.kernel.org,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@lst.de>, Jeff Moyer <jmoyer@redhat.com>,
	linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH RFC 2/8] fs/ext4: Disallow verity if inode is DAX
Date: Wed, 15 Apr 2020 11:55:25 -0400	[thread overview]
Message-ID: <20200415155525.GI90651@mit.edu> (raw)
In-Reply-To: <20200415120002.GE6126@quack2.suse.cz>

On Wed, Apr 15, 2020 at 02:00:02PM +0200, Jan Kara wrote:
> On Mon 13-04-20 21:00:24, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> > 
> > Verity and DAX are incompatible.  Changing the DAX mode due to a verity
> > flag change is wrong without a corresponding address_space_operations
> > update.
> > 
> > Make the 2 options mutually exclusive by returning an error if DAX was
> > set first.
> > 
> > (Setting DAX is already disabled if Verity is set first.)
> > 
> > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> > ---
> >  fs/ext4/verity.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/fs/ext4/verity.c b/fs/ext4/verity.c
> > index dc5ec724d889..ce3f9a198d3b 100644
> > --- a/fs/ext4/verity.c
> > +++ b/fs/ext4/verity.c
> > @@ -113,6 +113,9 @@ static int ext4_begin_enable_verity(struct file *filp)
> >  	handle_t *handle;
> >  	int err;
> >  
> > +	if (WARN_ON_ONCE(IS_DAX(inode)))
> > +		return -EINVAL;
> > +
> 
> Hum, one question, is there a reason for WARN_ON_ONCE()? If I understand
> correctly, user could normally trigger this, couldn't he?

Tes, the WARN_ON_ONCE isn't appropriate here.  We should also disallow
setting the DAX flag if the inode has the verity flag set already.

And if we need to decide what to if the file system is mounted with
"-o dax=always" and the verity file system feature is enabled.  We
could either (a) reject the mount with if the mount option is given
and the file system can have verity files, or (b) make "-o dax=always"
mean "-o dax=mostly_always" and treat verity files as not using dax
even when dax=always is selected.

Also, in theory, we *could* support dax and verity files, but
verifying the crypto checksums of all of the pages when the file is
first accessed, and then marking that in a flag in the in-inode flag.
Or we could have a per-page flag stored somewhere that indicates that
the page has been verified, so that we can on-demand verify the
integrity of the page.  Given that verity files are read-only, the
main reason why someone might want to use dax && verity would be to
reduce page cache overhead of system files; if executing out of dax
pages doesn't have significant performance impacts, this might be
something which might be a nice-to-have.  I don't think we need to
worry about this for now; if there are use cases where mobile devices
want to use dax && verity, we can let them figure out how to make it
work.  I'm just pointing out that it's not really a completely insane
combination.

Cheers,

						- Ted

  reply	other threads:[~2020-04-15 15:55 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14  4:00 [PATCH RFC 0/8] Enable ext4 support for per-file/directory DAX operations ira.weiny
2020-04-14  4:00 ` [PATCH RFC 1/8] fs/ext4: Narrow scope of DAX check in setflags ira.weiny
2020-04-15 11:45   ` Jan Kara
2020-04-14  4:00 ` [PATCH RFC 2/8] fs/ext4: Disallow verity if inode is DAX ira.weiny
2020-04-15 11:58   ` Jan Kara
2020-04-15 12:00   ` Jan Kara
2020-04-15 15:55     ` Theodore Y. Ts'o [this message]
2020-04-15 19:21       ` Ira Weiny
2020-04-15 19:14     ` Ira Weiny
2020-04-16  1:29       ` Eric Biggers
2020-04-16  3:48         ` Ira Weiny
2020-04-15 20:34     ` Ira Weiny
2020-04-14  4:00 ` [PATCH RFC 3/8] fs/ext4: Disallow encryption " ira.weiny
2020-04-15 12:02   ` Jan Kara
2020-04-15 20:35     ` Ira Weiny
2020-04-15 16:03   ` Theodore Y. Ts'o
2020-04-15 17:27     ` Dan Williams
2020-04-15 19:54     ` Ira Weiny
2020-04-21 18:41       ` Ira Weiny
2020-04-21 18:56         ` Darrick J. Wong
2020-04-14  4:00 ` [PATCH RFC 4/8] fs/ext4: Introduce DAX inode flag ira.weiny
2020-04-15 12:08   ` Jan Kara
2020-04-15 20:39     ` Ira Weiny
2020-04-16 10:32       ` Jan Kara
2020-04-16 18:01       ` Theodore Y. Ts'o
2020-04-16 16:25   ` Darrick J. Wong
2020-04-16 22:33     ` Ira Weiny
2020-04-16 22:49       ` Darrick J. Wong
2020-04-17  0:37         ` Ira Weiny
2020-04-17  1:57           ` Darrick J. Wong
2020-04-17  2:20             ` Ira Weiny
2020-04-17  6:43               ` Andreas Dilger
2020-04-17 17:19                 ` Ira Weiny
2020-04-14  4:00 ` [PATCH RFC 5/8] fs/ext4: Make DAX mount option a tri-state ira.weiny
2020-04-15 12:51   ` Jan Kara
2020-04-14  4:00 ` [PATCH RFC 6/8] fs/ext4: Update ext4_should_use_dax() ira.weiny
2020-04-15 13:58   ` Jan Kara
2020-04-17 17:16     ` Ira Weiny
2020-04-14  4:00 ` [PATCH RFC 7/8] fs/ext4: Only change S_DAX on inode load ira.weiny
2020-04-15 14:03   ` Jan Kara
2020-04-17 17:18     ` Ira Weiny
2020-04-14  4:00 ` [PATCH RFC 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=20200415155525.GI90651@mit.edu \
    --to=tytso@mit.edu \
    --cc=dan.j.williams@intel.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=ira.weiny@intel.com \
    --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=linux-xfs@vger.kernel.org \
    /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.