From: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> To: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org> Cc: linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org Subject: Re: [PATCH 10/12] xfs: use iomap to implement DAX Date: Wed, 14 Sep 2016 11:32:47 -0600 [thread overview] Message-ID: <20160914173247.GC30852@linux.intel.com> (raw) In-Reply-To: <1473847291-18913-11-git-send-email-hch-jcswGhMUV9g@public.gmane.org> On Wed, Sep 14, 2016 at 12:01:29PM +0200, Christoph Hellwig wrote: > Another users of buffer_heads bytes the dust. > > Signed-off-by: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org> > --- > fs/xfs/xfs_file.c | 61 +++++++++++++++--------------------------------------- > fs/xfs/xfs_iomap.c | 11 ++++++---- > 2 files changed, 24 insertions(+), 48 deletions(-) > > diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c > index 62649cc..663634f 100644 > --- a/fs/xfs/xfs_file.c > +++ b/fs/xfs/xfs_file.c <> > @@ -711,52 +704,32 @@ xfs_file_dax_write( > struct kiocb *iocb, > struct iov_iter *from) > { > - struct address_space *mapping = iocb->ki_filp->f_mapping; > - struct inode *inode = mapping->host; > + struct inode *inode = iocb->ki_filp->f_mapping->host; > struct xfs_inode *ip = XFS_I(inode); > - ssize_t ret = 0; > int iolock = XFS_IOLOCK_EXCL; > - struct iov_iter data; > + ssize_t ret, error = 0; > + size_t count; > + loff_t pos; > > xfs_rw_ilock(ip, iolock); > ret = xfs_file_aio_write_checks(iocb, from, &iolock); > if (ret) > goto out; > > - /* > - * Yes, even DAX files can have page cache attached to them: A zeroed > - * page is inserted into the pagecache when we have to serve a write > - * fault on a hole. It should never be dirtied and can simply be > - * dropped from the pagecache once we get real data for the page. > - * > - * XXX: This is racy against mmap, and there's nothing we can do about > - * it. dax_do_io() should really do this invalidation internally as > - * it will know if we've allocated over a holei for this specific IO and > - * if so it needs to update the mapping tree and invalidate existing > - * PTEs over the newly allocated range. Remove this invalidation when > - * dax_do_io() is fixed up. > - */ > - if (mapping->nrpages) { > - loff_t end = iocb->ki_pos + iov_iter_count(from) - 1; > - > - ret = invalidate_inode_pages2_range(mapping, > - iocb->ki_pos >> PAGE_SHIFT, > - end >> PAGE_SHIFT); > - WARN_ON_ONCE(ret); > - } > + pos = iocb->ki_pos; > + count = iov_iter_count(from); > > - trace_xfs_file_dax_write(ip, iov_iter_count(from), iocb->ki_pos); > + trace_xfs_file_dax_write(ip, count, pos); > > - data = *from; > - ret = dax_do_io(iocb, inode, &data, xfs_get_blocks_direct, > - xfs_end_io_direct_write, 0); > - if (ret > 0) { > - iocb->ki_pos += ret; > - iov_iter_advance(from, ret); > + ret = iomap_dax_rw(iocb, from, &xfs_iomap_ops); > + if (ret > 0 && iocb->ki_pos > i_size_read(inode)) { > + i_size_write(inode, iocb->ki_pos); > + error = xfs_setfilesize(ip, pos, count); I think this should be xfs_setfilesize(ip, pos, ret)? 'count' and 'ret' are the same in non-error cases, but in error cases where iomap_dax_rw() does some work and then encounters an error, 'ret' could be smaller. In error cases like this using 'ret' instead of 'count' will also keep the value we use in i_size_write() equal to what we write via xfs_setfilesize() because iocb->ki_pos == pos+ret, not pos+count. Aside from that, even though I'm sure you'll want a review from an XFS developer: Reviewed-by: Ross Zwisler <ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com> To: Christoph Hellwig <hch@lst.de> Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org, ross.zwisler@linux.intel.com Subject: Re: [PATCH 10/12] xfs: use iomap to implement DAX Date: Wed, 14 Sep 2016 11:32:47 -0600 [thread overview] Message-ID: <20160914173247.GC30852@linux.intel.com> (raw) In-Reply-To: <1473847291-18913-11-git-send-email-hch@lst.de> On Wed, Sep 14, 2016 at 12:01:29PM +0200, Christoph Hellwig wrote: > Another users of buffer_heads bytes the dust. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > fs/xfs/xfs_file.c | 61 +++++++++++++++--------------------------------------- > fs/xfs/xfs_iomap.c | 11 ++++++---- > 2 files changed, 24 insertions(+), 48 deletions(-) > > diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c > index 62649cc..663634f 100644 > --- a/fs/xfs/xfs_file.c > +++ b/fs/xfs/xfs_file.c <> > @@ -711,52 +704,32 @@ xfs_file_dax_write( > struct kiocb *iocb, > struct iov_iter *from) > { > - struct address_space *mapping = iocb->ki_filp->f_mapping; > - struct inode *inode = mapping->host; > + struct inode *inode = iocb->ki_filp->f_mapping->host; > struct xfs_inode *ip = XFS_I(inode); > - ssize_t ret = 0; > int iolock = XFS_IOLOCK_EXCL; > - struct iov_iter data; > + ssize_t ret, error = 0; > + size_t count; > + loff_t pos; > > xfs_rw_ilock(ip, iolock); > ret = xfs_file_aio_write_checks(iocb, from, &iolock); > if (ret) > goto out; > > - /* > - * Yes, even DAX files can have page cache attached to them: A zeroed > - * page is inserted into the pagecache when we have to serve a write > - * fault on a hole. It should never be dirtied and can simply be > - * dropped from the pagecache once we get real data for the page. > - * > - * XXX: This is racy against mmap, and there's nothing we can do about > - * it. dax_do_io() should really do this invalidation internally as > - * it will know if we've allocated over a holei for this specific IO and > - * if so it needs to update the mapping tree and invalidate existing > - * PTEs over the newly allocated range. Remove this invalidation when > - * dax_do_io() is fixed up. > - */ > - if (mapping->nrpages) { > - loff_t end = iocb->ki_pos + iov_iter_count(from) - 1; > - > - ret = invalidate_inode_pages2_range(mapping, > - iocb->ki_pos >> PAGE_SHIFT, > - end >> PAGE_SHIFT); > - WARN_ON_ONCE(ret); > - } > + pos = iocb->ki_pos; > + count = iov_iter_count(from); > > - trace_xfs_file_dax_write(ip, iov_iter_count(from), iocb->ki_pos); > + trace_xfs_file_dax_write(ip, count, pos); > > - data = *from; > - ret = dax_do_io(iocb, inode, &data, xfs_get_blocks_direct, > - xfs_end_io_direct_write, 0); > - if (ret > 0) { > - iocb->ki_pos += ret; > - iov_iter_advance(from, ret); > + ret = iomap_dax_rw(iocb, from, &xfs_iomap_ops); > + if (ret > 0 && iocb->ki_pos > i_size_read(inode)) { > + i_size_write(inode, iocb->ki_pos); > + error = xfs_setfilesize(ip, pos, count); I think this should be xfs_setfilesize(ip, pos, ret)? 'count' and 'ret' are the same in non-error cases, but in error cases where iomap_dax_rw() does some work and then encounters an error, 'ret' could be smaller. In error cases like this using 'ret' instead of 'count' will also keep the value we use in i_size_write() equal to what we write via xfs_setfilesize() because iocb->ki_pos == pos+ret, not pos+count. Aside from that, even though I'm sure you'll want a review from an XFS developer: Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
next prev parent reply other threads:[~2016-09-14 17:32 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-09-14 10:01 iomap based DAX path V2 Christoph Hellwig 2016-09-14 10:01 ` Christoph Hellwig [not found] ` <1473847291-18913-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org> 2016-09-14 10:01 ` [PATCH 01/12] iomap: add IOMAP_F_NEW flag Christoph Hellwig 2016-09-14 10:01 ` Christoph Hellwig 2016-09-14 10:01 ` [PATCH 02/12] iomap: expose iomap_apply outside iomap.c Christoph Hellwig 2016-09-14 10:01 ` Christoph Hellwig 2016-09-14 10:01 ` [PATCH 12/12] ext2: use iomap to implement DAX Christoph Hellwig 2016-09-14 10:01 ` Christoph Hellwig [not found] ` <1473847291-18913-13-git-send-email-hch-jcswGhMUV9g@public.gmane.org> 2016-09-14 22:51 ` Ross Zwisler 2016-09-14 22:51 ` Ross Zwisler 2016-09-15 5:14 ` Christoph Hellwig 2016-09-14 10:01 ` [PATCH 03/12] dax: don't pass buffer_head to dax_insert_mapping Christoph Hellwig 2016-09-14 10:01 ` [PATCH 04/12] dax: don't pass buffer_head to copy_user_dax Christoph Hellwig 2016-09-14 10:01 ` [PATCH 05/12] dax: provide an iomap based dax read/write path Christoph Hellwig [not found] ` <1473847291-18913-6-git-send-email-hch-jcswGhMUV9g@public.gmane.org> 2016-09-14 17:26 ` Ross Zwisler 2016-09-14 17:26 ` Ross Zwisler 2016-09-14 10:01 ` [PATCH 06/12] dax: provide an iomap based fault handler Christoph Hellwig 2016-09-14 17:27 ` Ross Zwisler [not found] ` <20160914172717.GB30852-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> 2016-09-15 5:13 ` Christoph Hellwig 2016-09-15 5:13 ` Christoph Hellwig 2016-09-14 10:01 ` [PATCH 07/12] xfs: fix locking for DAX writes Christoph Hellwig 2016-09-14 10:01 ` [PATCH 08/12] xfs: take the ilock shared if possible in xfs_file_iomap_begin Christoph Hellwig 2016-09-14 10:01 ` [PATCH 09/12] xfs: refactor xfs_setfilesize Christoph Hellwig 2016-09-14 10:01 ` [PATCH 10/12] xfs: use iomap to implement DAX Christoph Hellwig [not found] ` <1473847291-18913-11-git-send-email-hch-jcswGhMUV9g@public.gmane.org> 2016-09-14 17:32 ` Ross Zwisler [this message] 2016-09-14 17:32 ` Ross Zwisler [not found] ` <20160914173247.GC30852-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> 2016-09-15 5:14 ` Christoph Hellwig 2016-09-15 5:14 ` Christoph Hellwig 2016-09-15 5:29 ` Darrick J. Wong [not found] ` <20160915052933.GH9314-PTl6brltDGh4DFYR7WNSRA@public.gmane.org> 2016-09-15 6:43 ` Christoph Hellwig 2016-09-15 6:43 ` Christoph Hellwig 2016-09-14 10:01 ` [PATCH 11/12] ext2: stop passing buffer_head to ext2_get_blocks Christoph Hellwig [not found] ` <1473847291-18913-12-git-send-email-hch-jcswGhMUV9g@public.gmane.org> 2016-09-14 22:42 ` Ross Zwisler 2016-09-14 22:42 ` Ross Zwisler 2016-09-16 11:27 iomap based DAX path V3 Christoph Hellwig [not found] ` <1474025234-13804-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org> 2016-09-16 11:27 ` [PATCH 10/12] xfs: use iomap to implement DAX Christoph Hellwig 2016-09-16 11:27 ` Christoph Hellwig
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=20160914173247.GC30852@linux.intel.com \ --to=ross.zwisler-vuqaysv1563yd54fqh9/ca@public.gmane.org \ --cc=hch-jcswGhMUV9g@public.gmane.org \ --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org \ --cc=linux-xfs-u79uwXL29TY76Z2rM5mHXA@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: linkBe 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.