From: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: "Darrick J. Wong" <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>,
Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v3 2/2] ext4: handle layout changes to pinned DAX mappings
Date: Thu, 5 Jul 2018 10:53:10 -0600 [thread overview]
Message-ID: <20180705165310.GB22200@linux.intel.com> (raw)
In-Reply-To: <20180705035952.GB5699@magnolia>
On Wed, Jul 04, 2018 at 08:59:52PM -0700, Darrick J. Wong wrote:
> On Thu, Jul 05, 2018 at 09:54:14AM +1000, Dave Chinner wrote:
> > On Wed, Jul 04, 2018 at 02:27:23PM +0200, Jan Kara wrote:
> > > On Wed 04-07-18 10:49:23, Dave Chinner wrote:
> > > > On Mon, Jul 02, 2018 at 11:29:12AM -0600, Ross Zwisler wrote:
> > > > > Follow the lead of xfs_break_dax_layouts() and add synchronization between
> > > > > operations in ext4 which remove blocks from an inode (hole punch, truncate
> > > > > down, etc.) and pages which are pinned due to DAX DMA operations.
> > > > >
> > > > > Signed-off-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > > > Reviewed-by: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> > > > > Reviewed-by: Lukas Czerner <lczerner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > > > ---
> > > > >
> > > > > Changes since v2:
> > > > > * Added a comment to ext4_insert_range() explaining why we don't call
> > > > > ext4_break_layouts(). (Jan)
> > > >
> > > > Which I think is wrong and will cause data corruption.
> > > >
> > > > > @@ -5651,6 +5663,11 @@ int ext4_insert_range(struct inode *inode, loff_t offset, loff_t len)
> > > > > LLONG_MAX);
> > > > > if (ret)
> > > > > goto out_mmap;
> > > > > + /*
> > > > > + * We don't need to call ext4_break_layouts() because we aren't
> > > > > + * removing any blocks from the inode. We are just changing their
> > > > > + * offset by inserting a hole.
> > > > > + */
>
> Does calling ext4_break_layouts from insert range not work?
>
> It's my understanding that file leases work are a mechanism for the
> filesystem to delegate some of its authority over physical space
> mappings to "client" software. AFAICT it's used for mmap'ing pmem
> directly into userspace and exporting space on shared storage over
> pNFS. Some day we might use the same mechanism for the similar things
> that RDMA does, or the swapfile code since that's essentially how it
> works today.
>
> The other part of these file leases is that the filesystem revokes them
> any time it wants to perform a mapping operation on a file. This breaks
> my mental model of how leases work, and if you commit to this for ext4
> then I'll have to remember that leases are different between xfs and
> ext4. Worse, since the reason for skipping ext4_break_layouts seems to
> be the implementation detail that "DAX won't care", then someone else
> wiring up pNFS/future RDMA/whatever will also have to remember to put it
> back into ext4 or else kaboom.
>
> Granted, Dave said all these things already, but I actually feel
> strongly enough to reiterate.
Jan, would you like me to call ext4_break_layouts() in ext4_insert_range() to
keep the lease mechanism consistent between ext4 and XFS, or would you prefer
the s/ext4_break_layouts()/ext4_dax_unmap_pages()/ rename?
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Jan Kara <jack@suse.cz>,
linux-nvdimm@lists.01.org, Dave Chinner <david@fromorbit.com>,
Christoph Hellwig <hch@lst.de>,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH v3 2/2] ext4: handle layout changes to pinned DAX mappings
Date: Thu, 5 Jul 2018 10:53:10 -0600 [thread overview]
Message-ID: <20180705165310.GB22200@linux.intel.com> (raw)
In-Reply-To: <20180705035952.GB5699@magnolia>
On Wed, Jul 04, 2018 at 08:59:52PM -0700, Darrick J. Wong wrote:
> On Thu, Jul 05, 2018 at 09:54:14AM +1000, Dave Chinner wrote:
> > On Wed, Jul 04, 2018 at 02:27:23PM +0200, Jan Kara wrote:
> > > On Wed 04-07-18 10:49:23, Dave Chinner wrote:
> > > > On Mon, Jul 02, 2018 at 11:29:12AM -0600, Ross Zwisler wrote:
> > > > > Follow the lead of xfs_break_dax_layouts() and add synchronization between
> > > > > operations in ext4 which remove blocks from an inode (hole punch, truncate
> > > > > down, etc.) and pages which are pinned due to DAX DMA operations.
> > > > >
> > > > > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> > > > > Reviewed-by: Jan Kara <jack@suse.cz>
> > > > > Reviewed-by: Lukas Czerner <lczerner@redhat.com>
> > > > > ---
> > > > >
> > > > > Changes since v2:
> > > > > * Added a comment to ext4_insert_range() explaining why we don't call
> > > > > ext4_break_layouts(). (Jan)
> > > >
> > > > Which I think is wrong and will cause data corruption.
> > > >
> > > > > @@ -5651,6 +5663,11 @@ int ext4_insert_range(struct inode *inode, loff_t offset, loff_t len)
> > > > > LLONG_MAX);
> > > > > if (ret)
> > > > > goto out_mmap;
> > > > > + /*
> > > > > + * We don't need to call ext4_break_layouts() because we aren't
> > > > > + * removing any blocks from the inode. We are just changing their
> > > > > + * offset by inserting a hole.
> > > > > + */
>
> Does calling ext4_break_layouts from insert range not work?
>
> It's my understanding that file leases work are a mechanism for the
> filesystem to delegate some of its authority over physical space
> mappings to "client" software. AFAICT it's used for mmap'ing pmem
> directly into userspace and exporting space on shared storage over
> pNFS. Some day we might use the same mechanism for the similar things
> that RDMA does, or the swapfile code since that's essentially how it
> works today.
>
> The other part of these file leases is that the filesystem revokes them
> any time it wants to perform a mapping operation on a file. This breaks
> my mental model of how leases work, and if you commit to this for ext4
> then I'll have to remember that leases are different between xfs and
> ext4. Worse, since the reason for skipping ext4_break_layouts seems to
> be the implementation detail that "DAX won't care", then someone else
> wiring up pNFS/future RDMA/whatever will also have to remember to put it
> back into ext4 or else kaboom.
>
> Granted, Dave said all these things already, but I actually feel
> strongly enough to reiterate.
Jan, would you like me to call ext4_break_layouts() in ext4_insert_range() to
keep the lease mechanism consistent between ext4 and XFS, or would you prefer
the s/ext4_break_layouts()/ext4_dax_unmap_pages()/ rename?
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2018-07-05 16:53 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-27 21:22 [PATCH v2 0/2] ext4: fix DAX dma vs truncate/hole-punch Ross Zwisler
2018-06-27 21:22 ` Ross Zwisler
[not found] ` <20180627212252.31032-1-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-06-27 21:22 ` [PATCH v2 1/2] dax: dax_layout_busy_page() warn on !exceptional Ross Zwisler
2018-06-27 21:22 ` Ross Zwisler
[not found] ` <20180627212252.31032-2-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-02 22:15 ` Theodore Y. Ts'o
2018-07-02 22:15 ` Theodore Y. Ts'o
[not found] ` <20180702221503.GA12830-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2018-07-03 15:41 ` Ross Zwisler
2018-07-03 15:41 ` Ross Zwisler
[not found] ` <20180703154137.GB13019-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-03 17:44 ` Theodore Y. Ts'o
2018-07-03 17:44 ` Theodore Y. Ts'o
2018-06-27 21:22 ` [PATCH v2 2/2] ext4: handle layout changes to pinned DAX mappings Ross Zwisler
2018-06-27 21:22 ` Ross Zwisler
[not found] ` <20180627212252.31032-3-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-06-29 12:02 ` Lukas Czerner
2018-06-29 12:02 ` Lukas Czerner
[not found] ` <20180629120223.oaslngsvspnwf4ae-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2018-06-29 15:13 ` Ross Zwisler
2018-06-29 15:13 ` Ross Zwisler
[not found] ` <20180629151300.GA3006-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-02 7:34 ` Jan Kara
2018-07-02 7:34 ` Jan Kara
2018-07-02 7:59 ` Lukas Czerner
2018-07-02 7:59 ` Lukas Czerner
[not found] ` <20180702075948.i4aqjg5rrorwoxqj-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2018-07-02 16:27 ` Ross Zwisler
2018-07-02 16:27 ` Ross Zwisler
2018-06-30 1:12 ` Dave Chinner
2018-06-30 1:12 ` Dave Chinner
2018-07-02 17:29 ` [PATCH v3 " Ross Zwisler
2018-07-02 17:29 ` Ross Zwisler
[not found] ` <20180702172912.329-1-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-04 0:49 ` Dave Chinner
2018-07-04 0:49 ` Dave Chinner
2018-07-04 12:27 ` Jan Kara
2018-07-04 12:27 ` Jan Kara
[not found] ` <20180704122723.lup2wovzb6u6ta6v-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2018-07-04 23:54 ` Dave Chinner
2018-07-04 23:54 ` Dave Chinner
2018-07-05 3:59 ` Darrick J. Wong
2018-07-05 3:59 ` Darrick J. Wong
2018-07-05 16:53 ` Ross Zwisler [this message]
2018-07-05 16:53 ` Ross Zwisler
[not found] ` <20180705165310.GB22200-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-09 12:33 ` Jan Kara
2018-07-09 12:33 ` Jan Kara
[not found] ` <20180709123347.nw3ixr64prgk7sxz-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2018-07-09 16:23 ` Darrick J. Wong
2018-07-09 16:23 ` Darrick J. Wong
2018-07-09 19:49 ` Jan Kara
2018-07-09 19:49 ` Jan Kara
2018-07-05 20:40 ` Dan Williams
2018-07-05 20:40 ` Dan Williams
[not found] ` <CAPcyv4jSNh95XUPh4ZzguKmcJpgNG7AG5_9=+gbLEjsaZUTq4g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-05 23:29 ` Dave Chinner
2018-07-05 23:29 ` Dave Chinner
2018-07-06 5:08 ` Dan Williams
2018-07-06 5:08 ` Dan Williams
2018-07-09 9:59 ` Lukas Czerner
2018-07-09 9:59 ` Lukas Czerner
[not found] ` <20180709095907.i3mnyodvn6gpcidt-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2018-07-09 16:18 ` Darrick J. Wong
2018-07-09 16:18 ` 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=20180705165310.GB22200@linux.intel.com \
--to=ross.zwisler-vuqaysv1563yd54fqh9/ca@public.gmane.org \
--cc=darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org \
--cc=hch-jcswGhMUV9g@public.gmane.org \
--cc=jack-AlSwsSmVLrQ@public.gmane.org \
--cc=linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.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.