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?
next prev parent reply other threads:[~2018-07-05 16:53 UTC|newest]
Thread overview: 26+ 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
[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
[not found] ` <20180627212252.31032-2-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-02 22:15 ` Theodore Y. Ts'o
[not found] ` <20180702221503.GA12830-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
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-06-27 21:22 ` [PATCH v2 2/2] ext4: handle layout changes to pinned DAX mappings Ross Zwisler
[not found] ` <20180627212252.31032-3-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-06-29 12:02 ` Lukas Czerner
[not found] ` <20180629120223.oaslngsvspnwf4ae-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
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:59 ` Lukas Czerner
[not found] ` <20180702075948.i4aqjg5rrorwoxqj-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2018-07-02 16:27 ` Ross Zwisler
2018-06-30 1:12 ` Dave Chinner
2018-07-02 17:29 ` [PATCH v3 " Ross Zwisler
[not found] ` <20180702172912.329-1-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-07-04 0:49 ` Dave Chinner
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-05 3:59 ` Darrick J. Wong
2018-07-05 16:53 ` Ross Zwisler [this message]
[not found] ` <20180705165310.GB22200-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
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 19:49 ` Jan Kara
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-06 5:08 ` Dan Williams
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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).