All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-nvdimm@lists.01.org, Dave Chinner <david@fromorbit.com>,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	luto@kernel.org, linux-fsdevel@vger.kernel.org,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v2 3/5] fs, xfs: introduce FALLOC_FL_UNSEAL_BLOCK_MAP
Date: Fri, 4 Aug 2017 13:04:46 -0700	[thread overview]
Message-ID: <20170804200446.GD24087@magnolia> (raw)
In-Reply-To: <150181370272.32119.9941879917087053701.stgit@dwillia2-desk3.amr.corp.intel.com>

On Thu, Aug 03, 2017 at 07:28:23PM -0700, Dan Williams wrote:
> Provide an explicit fallocate operation type for clearing the
> S_IOMAP_IMMUTABLE flag. Like the enable case it requires CAP_IMMUTABLE
> and it can only be performed while no process has the file mapped.
> 
> Cc: Jan Kara <jack@suse.cz>
> Cc: Jeff Moyer <jmoyer@redhat.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
> Suggested-by: Dave Chinner <david@fromorbit.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  fs/open.c                   |   17 +++++++++++------
>  fs/xfs/xfs_bmap_util.c      |   42 ++++++++++++++++++++++++++++++++++++++++++
>  fs/xfs/xfs_bmap_util.h      |    3 +++
>  fs/xfs/xfs_file.c           |    4 +++-
>  include/linux/falloc.h      |    3 ++-
>  include/uapi/linux/falloc.h |    1 +
>  6 files changed, 62 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/open.c b/fs/open.c
> index e3aae59785ae..ccfd8d3becc8 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -274,13 +274,17 @@ int vfs_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
>  		return -EINVAL;
>  
>  	/*
> -	 * Seal block map operation should only be used exclusively, and
> -	 * with the IMMUTABLE capability.
> +	 * Seal/unseal block map operations should only be used
> +	 * exclusively, and with the IMMUTABLE capability.
>  	 */
> -	if (mode & FALLOC_FL_SEAL_BLOCK_MAP) {
> +	if (mode & (FALLOC_FL_SEAL_BLOCK_MAP | FALLOC_FL_UNSEAL_BLOCK_MAP)) {
>  		if (!capable(CAP_LINUX_IMMUTABLE))
>  			return -EPERM;
> -		if (mode & ~FALLOC_FL_SEAL_BLOCK_MAP)
> +		if (mode == (FALLOC_FL_SEAL_BLOCK_MAP
> +					| FALLOC_FL_UNSEAL_BLOCK_MAP))
> +			return -EINVAL;
> +		if (mode & ~(FALLOC_FL_SEAL_BLOCK_MAP
> +					| FALLOC_FL_UNSEAL_BLOCK_MAP))
>  			return -EINVAL;
>  	}
>  
> @@ -303,9 +307,10 @@ int vfs_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
>  		return -ETXTBSY;
>  
>  	/*
> -	 * We cannot allow any allocation changes on an iomap immutable file
> +	 * We cannot allow any allocation changes on an iomap immutable
> +	 * file, but we can allow clearing the immutable state.
>  	 */
> -	if (IS_IOMAP_IMMUTABLE(inode))
> +	if (IS_IOMAP_IMMUTABLE(inode) && !(mode & FALLOC_FL_UNSEAL_BLOCK_MAP))
>  		return -ETXTBSY;
>  
>  	/*
> diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
> index 46d8eb9e19fc..70ac2d33ab27 100644
> --- a/fs/xfs/xfs_bmap_util.c
> +++ b/fs/xfs/xfs_bmap_util.c
> @@ -1494,6 +1494,48 @@ xfs_seal_file_space(
>  	return error;
>  }
>  
> +int
> +xfs_unseal_file_space(
> +	struct xfs_inode	*ip,
> +	xfs_off_t		offset,
> +	xfs_off_t		len)
> +{
> +	struct inode		*inode = VFS_I(ip);
> +	struct address_space	*mapping = inode->i_mapping;
> +	int			error;
> +
> +	ASSERT(xfs_isilocked(ip, XFS_MMAPLOCK_EXCL));

Same assert-on-the-iolock comment as the previous patch.

> +
> +	if (offset)
> +		return -EINVAL;
> +
> +	xfs_ilock(ip, XFS_ILOCK_EXCL);
> +	/*
> +	 * It does not make sense to unseal less than the full range of
> +	 * the file.
> +	 */
> +	error = -EINVAL;
> +	if (len < i_size_read(inode))
> +		goto out_unlock;

Hmm, should we be picky and require len == i_size_read() here?

> +	/*
> +	 * Provide safety against one thread changing the policy of not
> +	 * requiring fsync/msync (for block allocations) behind another
> +	 * thread's back.
> +	 */
> +	error = -EBUSY;
> +	if (mapping_mapped(mapping))
> +		goto out_unlock;
> +
> +	inode->i_flags &= ~S_IOMAP_IMMUTABLE;

It occurred to me, should we jump out early from the seal/unseal
operations if the flag state matches whatever the user is asking for?
This is perhaps not necessary for unseal since we don't do a lot of
work.

--D

> +	error = 0;
> +
> +out_unlock:
> +	xfs_iunlock(ip, XFS_ILOCK_EXCL);
> +
> +	return error;
> +}
> +
>  /*
>   * @next_fsb will keep track of the extent currently undergoing shift.
>   * @stop_fsb will keep track of the extent at which we have to stop.
> diff --git a/fs/xfs/xfs_bmap_util.h b/fs/xfs/xfs_bmap_util.h
> index 5115a32a2483..b64653a75942 100644
> --- a/fs/xfs/xfs_bmap_util.h
> +++ b/fs/xfs/xfs_bmap_util.h
> @@ -62,6 +62,9 @@ int	xfs_insert_file_space(struct xfs_inode *, xfs_off_t offset,
>  				xfs_off_t len);
>  int	xfs_seal_file_space(struct xfs_inode *, xfs_off_t offset,
>  				xfs_off_t len);
> +int	xfs_unseal_file_space(struct xfs_inode *, xfs_off_t offset,
> +				xfs_off_t len);
> +
>  
>  /* EOF block manipulation functions */
>  bool	xfs_can_free_eofblocks(struct xfs_inode *ip, bool force);
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index e21121530a90..833f77700be2 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -740,7 +740,7 @@ xfs_file_write_iter(
>  		(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |		\
>  		 FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE |	\
>  		 FALLOC_FL_INSERT_RANGE | FALLOC_FL_UNSHARE_RANGE |	\
> -		 FALLOC_FL_SEAL_BLOCK_MAP)
> +		 FALLOC_FL_SEAL_BLOCK_MAP | FALLOC_FL_UNSEAL_BLOCK_MAP)
>  
>  STATIC long
>  xfs_file_fallocate(
> @@ -840,6 +840,8 @@ xfs_file_fallocate(
>  						XFS_BMAPI_PREALLOC);
>  			} else if (mode & FALLOC_FL_SEAL_BLOCK_MAP) {
>  				error = xfs_seal_file_space(ip, offset, len);
> +			} else if (mode & FALLOC_FL_UNSEAL_BLOCK_MAP) {
> +				error = xfs_unseal_file_space(ip, offset, len);
>  			} else
>  				error = xfs_alloc_file_space(ip, offset, len,
>  						XFS_BMAPI_PREALLOC);
> diff --git a/include/linux/falloc.h b/include/linux/falloc.h
> index 48546c6fbec7..b22c1368ed1e 100644
> --- a/include/linux/falloc.h
> +++ b/include/linux/falloc.h
> @@ -27,6 +27,7 @@ struct space_resv {
>  					 FALLOC_FL_ZERO_RANGE |		\
>  					 FALLOC_FL_INSERT_RANGE |	\
>  					 FALLOC_FL_UNSHARE_RANGE |	\
> -					 FALLOC_FL_SEAL_BLOCK_MAP)
> +					 FALLOC_FL_SEAL_BLOCK_MAP |	\
> +					 FALLOC_FL_UNSEAL_BLOCK_MAP)
>  
>  #endif /* _FALLOC_H_ */
> diff --git a/include/uapi/linux/falloc.h b/include/uapi/linux/falloc.h
> index 39076975bf6f..a4949e1a2dae 100644
> --- a/include/uapi/linux/falloc.h
> +++ b/include/uapi/linux/falloc.h
> @@ -95,4 +95,5 @@
>   * with the punch, zero, collapse, or insert range modes.
>   */
>  #define FALLOC_FL_SEAL_BLOCK_MAP	0x080
> +#define FALLOC_FL_UNSEAL_BLOCK_MAP	0x100
>  #endif /* _UAPI_FALLOC_H_ */
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
_______________________________________________
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: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-nvdimm@lists.01.org, Dave Chinner <david@fromorbit.com>,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	Jeff Moyer <jmoyer@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	luto@kernel.org, linux-fsdevel@vger.kernel.org,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v2 3/5] fs, xfs: introduce FALLOC_FL_UNSEAL_BLOCK_MAP
Date: Fri, 4 Aug 2017 13:04:46 -0700	[thread overview]
Message-ID: <20170804200446.GD24087@magnolia> (raw)
In-Reply-To: <150181370272.32119.9941879917087053701.stgit@dwillia2-desk3.amr.corp.intel.com>

On Thu, Aug 03, 2017 at 07:28:23PM -0700, Dan Williams wrote:
> Provide an explicit fallocate operation type for clearing the
> S_IOMAP_IMMUTABLE flag. Like the enable case it requires CAP_IMMUTABLE
> and it can only be performed while no process has the file mapped.
> 
> Cc: Jan Kara <jack@suse.cz>
> Cc: Jeff Moyer <jmoyer@redhat.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
> Cc: Alexander Viro <viro@zeniv.linux.org.uk>
> Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
> Suggested-by: Dave Chinner <david@fromorbit.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  fs/open.c                   |   17 +++++++++++------
>  fs/xfs/xfs_bmap_util.c      |   42 ++++++++++++++++++++++++++++++++++++++++++
>  fs/xfs/xfs_bmap_util.h      |    3 +++
>  fs/xfs/xfs_file.c           |    4 +++-
>  include/linux/falloc.h      |    3 ++-
>  include/uapi/linux/falloc.h |    1 +
>  6 files changed, 62 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/open.c b/fs/open.c
> index e3aae59785ae..ccfd8d3becc8 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -274,13 +274,17 @@ int vfs_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
>  		return -EINVAL;
>  
>  	/*
> -	 * Seal block map operation should only be used exclusively, and
> -	 * with the IMMUTABLE capability.
> +	 * Seal/unseal block map operations should only be used
> +	 * exclusively, and with the IMMUTABLE capability.
>  	 */
> -	if (mode & FALLOC_FL_SEAL_BLOCK_MAP) {
> +	if (mode & (FALLOC_FL_SEAL_BLOCK_MAP | FALLOC_FL_UNSEAL_BLOCK_MAP)) {
>  		if (!capable(CAP_LINUX_IMMUTABLE))
>  			return -EPERM;
> -		if (mode & ~FALLOC_FL_SEAL_BLOCK_MAP)
> +		if (mode == (FALLOC_FL_SEAL_BLOCK_MAP
> +					| FALLOC_FL_UNSEAL_BLOCK_MAP))
> +			return -EINVAL;
> +		if (mode & ~(FALLOC_FL_SEAL_BLOCK_MAP
> +					| FALLOC_FL_UNSEAL_BLOCK_MAP))
>  			return -EINVAL;
>  	}
>  
> @@ -303,9 +307,10 @@ int vfs_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
>  		return -ETXTBSY;
>  
>  	/*
> -	 * We cannot allow any allocation changes on an iomap immutable file
> +	 * We cannot allow any allocation changes on an iomap immutable
> +	 * file, but we can allow clearing the immutable state.
>  	 */
> -	if (IS_IOMAP_IMMUTABLE(inode))
> +	if (IS_IOMAP_IMMUTABLE(inode) && !(mode & FALLOC_FL_UNSEAL_BLOCK_MAP))
>  		return -ETXTBSY;
>  
>  	/*
> diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
> index 46d8eb9e19fc..70ac2d33ab27 100644
> --- a/fs/xfs/xfs_bmap_util.c
> +++ b/fs/xfs/xfs_bmap_util.c
> @@ -1494,6 +1494,48 @@ xfs_seal_file_space(
>  	return error;
>  }
>  
> +int
> +xfs_unseal_file_space(
> +	struct xfs_inode	*ip,
> +	xfs_off_t		offset,
> +	xfs_off_t		len)
> +{
> +	struct inode		*inode = VFS_I(ip);
> +	struct address_space	*mapping = inode->i_mapping;
> +	int			error;
> +
> +	ASSERT(xfs_isilocked(ip, XFS_MMAPLOCK_EXCL));

Same assert-on-the-iolock comment as the previous patch.

> +
> +	if (offset)
> +		return -EINVAL;
> +
> +	xfs_ilock(ip, XFS_ILOCK_EXCL);
> +	/*
> +	 * It does not make sense to unseal less than the full range of
> +	 * the file.
> +	 */
> +	error = -EINVAL;
> +	if (len < i_size_read(inode))
> +		goto out_unlock;

Hmm, should we be picky and require len == i_size_read() here?

> +	/*
> +	 * Provide safety against one thread changing the policy of not
> +	 * requiring fsync/msync (for block allocations) behind another
> +	 * thread's back.
> +	 */
> +	error = -EBUSY;
> +	if (mapping_mapped(mapping))
> +		goto out_unlock;
> +
> +	inode->i_flags &= ~S_IOMAP_IMMUTABLE;

It occurred to me, should we jump out early from the seal/unseal
operations if the flag state matches whatever the user is asking for?
This is perhaps not necessary for unseal since we don't do a lot of
work.

--D

> +	error = 0;
> +
> +out_unlock:
> +	xfs_iunlock(ip, XFS_ILOCK_EXCL);
> +
> +	return error;
> +}
> +
>  /*
>   * @next_fsb will keep track of the extent currently undergoing shift.
>   * @stop_fsb will keep track of the extent at which we have to stop.
> diff --git a/fs/xfs/xfs_bmap_util.h b/fs/xfs/xfs_bmap_util.h
> index 5115a32a2483..b64653a75942 100644
> --- a/fs/xfs/xfs_bmap_util.h
> +++ b/fs/xfs/xfs_bmap_util.h
> @@ -62,6 +62,9 @@ int	xfs_insert_file_space(struct xfs_inode *, xfs_off_t offset,
>  				xfs_off_t len);
>  int	xfs_seal_file_space(struct xfs_inode *, xfs_off_t offset,
>  				xfs_off_t len);
> +int	xfs_unseal_file_space(struct xfs_inode *, xfs_off_t offset,
> +				xfs_off_t len);
> +
>  
>  /* EOF block manipulation functions */
>  bool	xfs_can_free_eofblocks(struct xfs_inode *ip, bool force);
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index e21121530a90..833f77700be2 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -740,7 +740,7 @@ xfs_file_write_iter(
>  		(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |		\
>  		 FALLOC_FL_COLLAPSE_RANGE | FALLOC_FL_ZERO_RANGE |	\
>  		 FALLOC_FL_INSERT_RANGE | FALLOC_FL_UNSHARE_RANGE |	\
> -		 FALLOC_FL_SEAL_BLOCK_MAP)
> +		 FALLOC_FL_SEAL_BLOCK_MAP | FALLOC_FL_UNSEAL_BLOCK_MAP)
>  
>  STATIC long
>  xfs_file_fallocate(
> @@ -840,6 +840,8 @@ xfs_file_fallocate(
>  						XFS_BMAPI_PREALLOC);
>  			} else if (mode & FALLOC_FL_SEAL_BLOCK_MAP) {
>  				error = xfs_seal_file_space(ip, offset, len);
> +			} else if (mode & FALLOC_FL_UNSEAL_BLOCK_MAP) {
> +				error = xfs_unseal_file_space(ip, offset, len);
>  			} else
>  				error = xfs_alloc_file_space(ip, offset, len,
>  						XFS_BMAPI_PREALLOC);
> diff --git a/include/linux/falloc.h b/include/linux/falloc.h
> index 48546c6fbec7..b22c1368ed1e 100644
> --- a/include/linux/falloc.h
> +++ b/include/linux/falloc.h
> @@ -27,6 +27,7 @@ struct space_resv {
>  					 FALLOC_FL_ZERO_RANGE |		\
>  					 FALLOC_FL_INSERT_RANGE |	\
>  					 FALLOC_FL_UNSHARE_RANGE |	\
> -					 FALLOC_FL_SEAL_BLOCK_MAP)
> +					 FALLOC_FL_SEAL_BLOCK_MAP |	\
> +					 FALLOC_FL_UNSEAL_BLOCK_MAP)
>  
>  #endif /* _FALLOC_H_ */
> diff --git a/include/uapi/linux/falloc.h b/include/uapi/linux/falloc.h
> index 39076975bf6f..a4949e1a2dae 100644
> --- a/include/uapi/linux/falloc.h
> +++ b/include/uapi/linux/falloc.h
> @@ -95,4 +95,5 @@
>   * with the punch, zero, collapse, or insert range modes.
>   */
>  #define FALLOC_FL_SEAL_BLOCK_MAP	0x080
> +#define FALLOC_FL_UNSEAL_BLOCK_MAP	0x100
>  #endif /* _UAPI_FALLOC_H_ */
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-08-04 20:03 UTC|newest]

Thread overview: 108+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-04  2:28 [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap Dan Williams
2017-08-04  2:28 ` Dan Williams
2017-08-04  2:28 ` [PATCH v2 1/5] fs, xfs: introduce S_IOMAP_IMMUTABLE Dan Williams
2017-08-04  2:28   ` Dan Williams
2017-08-04 20:00   ` Darrick J. Wong
2017-08-04 20:00     ` Darrick J. Wong
2017-08-04 20:31     ` Dan Williams
2017-08-04 20:31       ` Dan Williams
2017-08-05  9:47   ` Christoph Hellwig
2017-08-05  9:47     ` Christoph Hellwig
2017-08-07  0:25     ` Dave Chinner
2017-08-07  0:25       ` Dave Chinner
2017-08-11 10:34       ` Christoph Hellwig
2017-08-11 10:34         ` Christoph Hellwig
2017-08-04  2:28 ` [PATCH v2 2/5] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP Dan Williams
2017-08-04  2:28   ` Dan Williams
2017-08-04  2:28   ` Dan Williams
2017-08-04 19:46   ` Darrick J. Wong
2017-08-04 19:46     ` Darrick J. Wong
2017-08-04 19:52     ` Dan Williams
2017-08-04 19:52       ` Dan Williams
2017-08-04 23:31   ` Dave Chinner
2017-08-04 23:31     ` Dave Chinner
2017-08-04 23:43     ` Dan Williams
2017-08-04 23:43       ` Dan Williams
2017-08-05  0:04       ` Dave Chinner
2017-08-05  0:04         ` Dave Chinner
2017-08-04  2:28 ` [PATCH v2 3/5] fs, xfs: introduce FALLOC_FL_UNSEAL_BLOCK_MAP Dan Williams
2017-08-04  2:28   ` Dan Williams
2017-08-04 20:04   ` Darrick J. Wong [this message]
2017-08-04 20:04     ` Darrick J. Wong
2017-08-04 20:36     ` Dan Williams
2017-08-04 20:36       ` Dan Williams
2017-08-04  2:28 ` [PATCH v2 4/5] xfs: introduce XFS_DIFLAG2_IOMAP_IMMUTABLE Dan Williams
2017-08-04  2:28   ` Dan Williams
2017-08-04 20:33   ` Darrick J. Wong
2017-08-04 20:33     ` Darrick J. Wong
2017-08-04 20:45     ` Dan Williams
2017-08-04 20:45       ` Dan Williams
2017-08-04 23:46     ` Dave Chinner
2017-08-04 23:46       ` Dave Chinner
2017-08-04 23:57       ` Darrick J. Wong
2017-08-04 23:57         ` Darrick J. Wong
2017-08-04  2:28 ` [PATCH v2 5/5] xfs: toggle XFS_DIFLAG2_IOMAP_IMMUTABLE in response to fallocate Dan Williams
2017-08-04  2:28   ` Dan Williams
2017-08-04 20:14   ` Darrick J. Wong
2017-08-04 20:14     ` Darrick J. Wong
2017-08-04 20:47     ` Dan Williams
2017-08-04 20:47       ` Dan Williams
2017-08-04 20:53       ` Darrick J. Wong
2017-08-04 20:53         ` Darrick J. Wong
2017-08-04 20:55         ` Dan Williams
2017-08-04 20:55           ` Dan Williams
2017-08-04  2:38 ` [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap Dan Williams
2017-08-04  2:38   ` Dan Williams
2017-08-04  2:38   ` Dan Williams
2017-08-05  9:50   ` Christoph Hellwig
2017-08-05  9:50     ` Christoph Hellwig
2017-08-05  9:50     ` Christoph Hellwig
2017-08-06 18:51     ` Dan Williams
2017-08-06 18:51       ` Dan Williams
2017-08-06 18:51       ` Dan Williams
2017-08-11 10:44       ` Christoph Hellwig
2017-08-11 10:44         ` Christoph Hellwig
2017-08-11 10:44         ` Christoph Hellwig
2017-08-11 22:26         ` Dan Williams
2017-08-11 22:26           ` Dan Williams
2017-08-11 22:26           ` Dan Williams
2017-08-12  3:57           ` Andy Lutomirski
2017-08-12  3:57             ` Andy Lutomirski
2017-08-12  4:44             ` Dan Williams
2017-08-12  4:44               ` Dan Williams
2017-08-12  4:44               ` Dan Williams
2017-08-12  7:34             ` Christoph Hellwig
2017-08-12  7:34               ` Christoph Hellwig
2017-08-12  7:34               ` Christoph Hellwig
2017-08-12  7:33           ` Christoph Hellwig
2017-08-12  7:33             ` Christoph Hellwig
2017-08-12  7:33             ` Christoph Hellwig
2017-08-12 19:19             ` Dan Williams
2017-08-12 19:19               ` Dan Williams
2017-08-12 19:19               ` Dan Williams
2017-08-13  9:24               ` Christoph Hellwig
2017-08-13  9:24                 ` Christoph Hellwig
2017-08-13 20:31                 ` Dan Williams
2017-08-13 20:31                   ` Dan Williams
2017-08-13 20:31                   ` Dan Williams
2017-08-14 12:40                   ` Jan Kara
2017-08-14 12:40                     ` Jan Kara
2017-08-14 12:40                     ` Jan Kara
2017-08-14 16:14                     ` Dan Williams
2017-08-14 16:14                       ` Dan Williams
2017-08-15  8:37                       ` Jan Kara
2017-08-15  8:37                         ` Jan Kara
2017-08-15  8:37                         ` Jan Kara
2017-08-15 23:50                         ` Dan Williams
2017-08-15 23:50                           ` Dan Williams
2017-08-16 13:57                           ` Jan Kara
2017-08-16 13:57                             ` Jan Kara
2017-08-16 13:57                             ` Jan Kara
2017-08-21  9:16                     ` Peter Zijlstra
2017-08-21  9:16                       ` Peter Zijlstra
2017-08-21  9:16                       ` Peter Zijlstra
2017-08-14 21:46                   ` Darrick J. Wong
2017-08-14 21:46                     ` Darrick J. Wong
2017-08-14 21:46                     ` Darrick J. Wong
2017-08-13 23:46                 ` Dave Chinner
2017-08-13 23:46                   ` Dave Chinner

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=20170804200446.GD24087@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=dan.j.williams@intel.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=luto@kernel.org \
    --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.