All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-nvdimm@lists.01.org, linux-xfs@vger.kernel.org,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH v6 3/3] xfs: reject removal of realtime flag when datadev doesn't support DAX
Date: Wed, 21 Feb 2018 10:15:24 +1100	[thread overview]
Message-ID: <20180220231524.GD7000@dastard> (raw)
In-Reply-To: <20180220230109.GG27629@magnolia>

On Tue, Feb 20, 2018 at 03:01:09PM -0800, Darrick J. Wong wrote:
> On Sun, Feb 18, 2018 at 11:23:17AM +1100, Dave Chinner wrote:
> > On Fri, Feb 16, 2018 at 09:22:47AM -0800, Darrick J. Wong wrote:
> > > On Fri, Feb 16, 2018 at 10:04:26AM -0700, Dave Jiang wrote:
> > > > In a situation where the rt_dev is DAX and data_dev is not DAX, if the user
> > > > requests to remove the realtime flag via ioctl we can no longer support DAX
> > > > for that file. Dynamic changing of S_DAX on the inode is not supported due
> > > > to various complications in the existing implementation. Therefore until we
> > > > address the dynamic S_DAX change issues, we must disallow realtime flag
> > > > being removed.
> > > > 
> > > > Signed-off-by: Dave Jiang <dave.jiang@intel.com>
> > > > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > > > ---
> > > >  fs/xfs/xfs_ioctl.c |   14 ++++++++++++++
> > > >  1 file changed, 14 insertions(+)
> > > > 
> > > > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> > > > index 2c70a0a4f59f..edd97d527fe8 100644
> > > > --- a/fs/xfs/xfs_ioctl.c
> > > > +++ b/fs/xfs/xfs_ioctl.c
> > > > @@ -1030,6 +1030,20 @@ xfs_ioctl_setattr_xflags(
> > > >  {
> > > >  	struct xfs_mount	*mp = ip->i_mount;
> > > >  	uint64_t		di_flags2;
> > > > +	struct inode		*inode = VFS_I(ip);
> > > > +	struct super_block	*sb = inode->i_sb;
> > > > +
> > > > +	/*
> > > > +	 * In the case that the inode is realtime, and we are trying to remove
> > > > +	 * the realtime flag, and the rtdev supports DAX but the datadev does
> > > > +	 * not support DAX, we can't allow the realtime flag to be removed
> > > > +	 * since we do not support dynamic S_DAX flag removal yet.
> > > > +	 */
> > > > +	if (XFS_IS_REALTIME_INODE(ip) &&
> > > > +	    !(fa->fsx_xflags & FS_XFLAG_REALTIME) &&
> > > > +	    bdev_dax_supported(mp->m_rtdev_targp->bt_bdev, sb->s_blocksize) &&
> > > > +	    !bdev_dax_supported(mp->m_ddev_targp->bt_bdev, sb->s_blocksize))
> > > 
> > > What happens here if we have a non-rt file that we're trying to turn
> > > into an rt file and the data dev supports dax but not the rt dev?
> > > 
> > > Changing the rt flag is only supported on files with no data blocks (no
> > > extents, no delalloc blocks), so why can't we remove S_DAX from an empty
> > > file?  There aren't any memory mappings or page cache to get in the way,
> > > correct?
> > 
> > File size can be non-zero, so you can have DAX read-over-hole
> > mappings present. I simply don't think it's safe to remove/add S_DAX
> > flags via ioctls right now. If we have a DAX capable rtdev, then the
> > only way we should allow rtdev+dax to be used right now is via the
> > RT inherit bit on the dir that creates files in the rtdev right from
> > the start. i.e. we can't set/remove the RT inode flag on an inode
> > via ioctl if rtdev+dax is enabled until the whole dynamic S_DAX
> > inode flag thing is resolved.
> 
> Could we deal with the restriction that the DAX flag can't change
> (whether by user ioctl or by toggling the rt flag) unless the file size
> is zero?  That adds another way setting/clearing the realtime flag can
> fail, but at least it'd be the same EINVAL.

I thought we still mmap a zero length file and get a page fault that
returns a zeroed page? Or does that segv?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>
To: "Darrick J. Wong" <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
	linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v6 3/3] xfs: reject removal of realtime flag when datadev doesn't support DAX
Date: Wed, 21 Feb 2018 10:15:24 +1100	[thread overview]
Message-ID: <20180220231524.GD7000@dastard> (raw)
In-Reply-To: <20180220230109.GG27629@magnolia>

On Tue, Feb 20, 2018 at 03:01:09PM -0800, Darrick J. Wong wrote:
> On Sun, Feb 18, 2018 at 11:23:17AM +1100, Dave Chinner wrote:
> > On Fri, Feb 16, 2018 at 09:22:47AM -0800, Darrick J. Wong wrote:
> > > On Fri, Feb 16, 2018 at 10:04:26AM -0700, Dave Jiang wrote:
> > > > In a situation where the rt_dev is DAX and data_dev is not DAX, if the user
> > > > requests to remove the realtime flag via ioctl we can no longer support DAX
> > > > for that file. Dynamic changing of S_DAX on the inode is not supported due
> > > > to various complications in the existing implementation. Therefore until we
> > > > address the dynamic S_DAX change issues, we must disallow realtime flag
> > > > being removed.
> > > > 
> > > > Signed-off-by: Dave Jiang <dave.jiang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > > > Reviewed-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
> > > > ---
> > > >  fs/xfs/xfs_ioctl.c |   14 ++++++++++++++
> > > >  1 file changed, 14 insertions(+)
> > > > 
> > > > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> > > > index 2c70a0a4f59f..edd97d527fe8 100644
> > > > --- a/fs/xfs/xfs_ioctl.c
> > > > +++ b/fs/xfs/xfs_ioctl.c
> > > > @@ -1030,6 +1030,20 @@ xfs_ioctl_setattr_xflags(
> > > >  {
> > > >  	struct xfs_mount	*mp = ip->i_mount;
> > > >  	uint64_t		di_flags2;
> > > > +	struct inode		*inode = VFS_I(ip);
> > > > +	struct super_block	*sb = inode->i_sb;
> > > > +
> > > > +	/*
> > > > +	 * In the case that the inode is realtime, and we are trying to remove
> > > > +	 * the realtime flag, and the rtdev supports DAX but the datadev does
> > > > +	 * not support DAX, we can't allow the realtime flag to be removed
> > > > +	 * since we do not support dynamic S_DAX flag removal yet.
> > > > +	 */
> > > > +	if (XFS_IS_REALTIME_INODE(ip) &&
> > > > +	    !(fa->fsx_xflags & FS_XFLAG_REALTIME) &&
> > > > +	    bdev_dax_supported(mp->m_rtdev_targp->bt_bdev, sb->s_blocksize) &&
> > > > +	    !bdev_dax_supported(mp->m_ddev_targp->bt_bdev, sb->s_blocksize))
> > > 
> > > What happens here if we have a non-rt file that we're trying to turn
> > > into an rt file and the data dev supports dax but not the rt dev?
> > > 
> > > Changing the rt flag is only supported on files with no data blocks (no
> > > extents, no delalloc blocks), so why can't we remove S_DAX from an empty
> > > file?  There aren't any memory mappings or page cache to get in the way,
> > > correct?
> > 
> > File size can be non-zero, so you can have DAX read-over-hole
> > mappings present. I simply don't think it's safe to remove/add S_DAX
> > flags via ioctls right now. If we have a DAX capable rtdev, then the
> > only way we should allow rtdev+dax to be used right now is via the
> > RT inherit bit on the dir that creates files in the rtdev right from
> > the start. i.e. we can't set/remove the RT inode flag on an inode
> > via ioctl if rtdev+dax is enabled until the whole dynamic S_DAX
> > inode flag thing is resolved.
> 
> Could we deal with the restriction that the DAX flag can't change
> (whether by user ioctl or by toggling the rt flag) unless the file size
> is zero?  That adds another way setting/clearing the realtime flag can
> fail, but at least it'd be the same EINVAL.

I thought we still mmap a zero length file and get a page fault that
returns a zeroed page? Or does that segv?

Cheers,

Dave.
-- 
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Dave Jiang <dave.jiang@intel.com>,
	linux-nvdimm@lists.01.org, linux-xfs@vger.kernel.org,
	ross.zwisler@linux.intel.com, linux-ext4@vger.kernel.org,
	dan.j.williams@intel.com
Subject: Re: [PATCH v6 3/3] xfs: reject removal of realtime flag when datadev doesn't support DAX
Date: Wed, 21 Feb 2018 10:15:24 +1100	[thread overview]
Message-ID: <20180220231524.GD7000@dastard> (raw)
In-Reply-To: <20180220230109.GG27629@magnolia>

On Tue, Feb 20, 2018 at 03:01:09PM -0800, Darrick J. Wong wrote:
> On Sun, Feb 18, 2018 at 11:23:17AM +1100, Dave Chinner wrote:
> > On Fri, Feb 16, 2018 at 09:22:47AM -0800, Darrick J. Wong wrote:
> > > On Fri, Feb 16, 2018 at 10:04:26AM -0700, Dave Jiang wrote:
> > > > In a situation where the rt_dev is DAX and data_dev is not DAX, if the user
> > > > requests to remove the realtime flag via ioctl we can no longer support DAX
> > > > for that file. Dynamic changing of S_DAX on the inode is not supported due
> > > > to various complications in the existing implementation. Therefore until we
> > > > address the dynamic S_DAX change issues, we must disallow realtime flag
> > > > being removed.
> > > > 
> > > > Signed-off-by: Dave Jiang <dave.jiang@intel.com>
> > > > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > > > ---
> > > >  fs/xfs/xfs_ioctl.c |   14 ++++++++++++++
> > > >  1 file changed, 14 insertions(+)
> > > > 
> > > > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> > > > index 2c70a0a4f59f..edd97d527fe8 100644
> > > > --- a/fs/xfs/xfs_ioctl.c
> > > > +++ b/fs/xfs/xfs_ioctl.c
> > > > @@ -1030,6 +1030,20 @@ xfs_ioctl_setattr_xflags(
> > > >  {
> > > >  	struct xfs_mount	*mp = ip->i_mount;
> > > >  	uint64_t		di_flags2;
> > > > +	struct inode		*inode = VFS_I(ip);
> > > > +	struct super_block	*sb = inode->i_sb;
> > > > +
> > > > +	/*
> > > > +	 * In the case that the inode is realtime, and we are trying to remove
> > > > +	 * the realtime flag, and the rtdev supports DAX but the datadev does
> > > > +	 * not support DAX, we can't allow the realtime flag to be removed
> > > > +	 * since we do not support dynamic S_DAX flag removal yet.
> > > > +	 */
> > > > +	if (XFS_IS_REALTIME_INODE(ip) &&
> > > > +	    !(fa->fsx_xflags & FS_XFLAG_REALTIME) &&
> > > > +	    bdev_dax_supported(mp->m_rtdev_targp->bt_bdev, sb->s_blocksize) &&
> > > > +	    !bdev_dax_supported(mp->m_ddev_targp->bt_bdev, sb->s_blocksize))
> > > 
> > > What happens here if we have a non-rt file that we're trying to turn
> > > into an rt file and the data dev supports dax but not the rt dev?
> > > 
> > > Changing the rt flag is only supported on files with no data blocks (no
> > > extents, no delalloc blocks), so why can't we remove S_DAX from an empty
> > > file?  There aren't any memory mappings or page cache to get in the way,
> > > correct?
> > 
> > File size can be non-zero, so you can have DAX read-over-hole
> > mappings present. I simply don't think it's safe to remove/add S_DAX
> > flags via ioctls right now. If we have a DAX capable rtdev, then the
> > only way we should allow rtdev+dax to be used right now is via the
> > RT inherit bit on the dir that creates files in the rtdev right from
> > the start. i.e. we can't set/remove the RT inode flag on an inode
> > via ioctl if rtdev+dax is enabled until the whole dynamic S_DAX
> > inode flag thing is resolved.
> 
> Could we deal with the restriction that the DAX flag can't change
> (whether by user ioctl or by toggling the rt flag) unless the file size
> is zero?  That adds another way setting/clearing the realtime flag can
> fail, but at least it'd be the same EINVAL.

I thought we still mmap a zero length file and get a page fault that
returns a zeroed page? Or does that segv?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-02-20 23:09 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-16 17:04 [PATCH v6 0/3] minimal DAX support for XFS realtime device Dave Jiang
2018-02-16 17:04 ` Dave Jiang
2018-02-16 17:04 ` [PATCH v6 1/3] fs: allow per-device dax status checking for filesystems Dave Jiang
2018-02-16 17:04   ` Dave Jiang
2018-02-16 17:04   ` Dave Jiang
2018-02-20  0:24   ` kbuild test robot
2018-02-20  0:24     ` kbuild test robot
2018-02-20  0:24     ` kbuild test robot
2018-02-16 17:04 ` [PATCH v6 2/3] dax: change bdev_dax_supported() to support boolean returns Dave Jiang
2018-02-16 17:04   ` Dave Jiang
2018-02-16 17:04   ` Dave Jiang
2018-02-16 17:26   ` Darrick J. Wong
2018-02-16 17:26     ` Darrick J. Wong
2018-02-16 17:26     ` Darrick J. Wong
2018-02-16 17:04 ` [PATCH v6 3/3] xfs: reject removal of realtime flag when datadev doesn't support DAX Dave Jiang
2018-02-16 17:04   ` Dave Jiang
2018-02-16 17:22   ` Darrick J. Wong
2018-02-16 17:22     ` Darrick J. Wong
2018-02-18  0:23     ` Dave Chinner
2018-02-18  0:23       ` Dave Chinner
2018-02-20 23:01       ` Darrick J. Wong
2018-02-20 23:01         ` Darrick J. Wong
2018-02-20 23:01         ` Darrick J. Wong
2018-02-20 23:15         ` Dave Chinner [this message]
2018-02-20 23:15           ` Dave Chinner
2018-02-20 23:15           ` Dave Chinner
2018-02-20 23:23           ` Darrick J. Wong
2018-02-20 23:23             ` Darrick J. Wong
2018-02-20 23:23             ` Darrick J. Wong
2018-02-27 16:46             ` Dave Jiang
2018-02-27 16:46               ` Dave Jiang
2018-02-27 16:46               ` Dave Jiang
2018-02-27 17:14               ` Darrick J. Wong
2018-02-27 17:14                 ` Darrick J. Wong
2018-02-27 17:14                 ` Darrick J. Wong

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=20180220231524.GD7000@dastard \
    --to=david@fromorbit.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.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.