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
next prev parent 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
[not found] ` <150181368442.32119.13336247800141074356.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
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
[not found] ` <CAPcyv4ii41F-Rj9pPGc0FHwrQ=hkSF_f0niQDn5_NjU-wcL+gg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-05 9:50 ` Christoph Hellwig
2017-08-05 9:50 ` Christoph Hellwig
2017-08-05 9:50 ` Christoph Hellwig
[not found] ` <20170805095013.GC14930-jcswGhMUV9g@public.gmane.org>
2017-08-06 18:51 ` Dan Williams
2017-08-06 18:51 ` Dan Williams
2017-08-06 18:51 ` Dan Williams
[not found] ` <CAPcyv4jgKmakB0WRUjx=2eD3YJ1x+C8cgnR6tA+g4+m+0etawQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-11 10:44 ` Christoph Hellwig
2017-08-11 10:44 ` Christoph Hellwig
2017-08-11 10:44 ` Christoph Hellwig
[not found] ` <20170811104429.GA13736-jcswGhMUV9g@public.gmane.org>
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
[not found] ` <CALCETrVvMbaxobdydtsdQWHyP1VhL1fpq1qS4M3=SmR1y4x5kw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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
[not found] ` <CAPcyv4jrZ5a+zmAehZDxfP=+6BNCFAXOFWro2L7ruLkk+cY7OQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-12 7:33 ` Christoph Hellwig
2017-08-12 7:33 ` Christoph Hellwig
2017-08-12 7:33 ` Christoph Hellwig
[not found] ` <20170812073349.GA12679-jcswGhMUV9g@public.gmane.org>
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
[not found] ` <20170813092436.GB32112-jcswGhMUV9g@public.gmane.org>
2017-08-13 20:31 ` Dan Williams
2017-08-13 20:31 ` Dan Williams
2017-08-13 20:31 ` Dan Williams
[not found] ` <CAPcyv4ixTgSWG9K2Eg3XJmOvqJht81qL+Z3njoOjcXCD7XMpZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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
[not found] ` <CAPcyv4hi_Y5Qj=h_Qf4Bcyv+EWBosa2gQT+-8ro3hPY9VMshSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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
[not found] ` <CAPcyv4hFTn4Fz5o+Gm857mS-RA6WAVsf4CmwiLiK2O8w2_SamQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-16 13:57 ` Jan Kara
2017-08-16 13:57 ` Jan Kara
2017-08-16 13:57 ` Jan Kara
[not found] ` <20170814124059.GC17820-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
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.