From: Christoph Hellwig <hch@lst.de>
To: linux-xfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Subject: [PATCH 16/21] xfs: remove the imap_valid flag
Date: Thu, 31 May 2018 20:07:54 +0200 [thread overview]
Message-ID: <20180531180759.21631-17-hch@lst.de> (raw)
In-Reply-To: <20180531180759.21631-1-hch@lst.de>
Simplify the way we check for a valid imap - we know we have a valid
mapping after xfs_map_blocks returned successfully, and we know we can
call xfs_imap_valid on any imap, as it will always fail on a
zero-initialized map.
We can also remove the xfs_imap_valid function and fold it into
xfs_map_blocks now.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
---
fs/xfs/xfs_aops.c | 78 +++++++++++++++++++----------------------------
1 file changed, 31 insertions(+), 47 deletions(-)
diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index 5c4cc713edba..5f8e40a032b1 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -42,7 +42,6 @@
*/
struct xfs_writepage_ctx {
struct xfs_bmbt_irec imap;
- bool imap_valid;
unsigned int io_type;
struct xfs_ioend *ioend;
sector_t last_block;
@@ -382,15 +381,40 @@ xfs_map_blocks(
struct xfs_inode *ip = XFS_I(inode);
struct xfs_mount *mp = ip->i_mount;
ssize_t count = i_blocksize(inode);
- xfs_fileoff_t offset_fsb, end_fsb;
+ xfs_fileoff_t offset_fsb = XFS_B_TO_FSBT(mp, offset), end_fsb;
struct xfs_bmbt_irec imap;
int whichfork = XFS_DATA_FORK;
struct xfs_iext_cursor icur;
+ bool imap_valid;
int error = 0;
+ /*
+ * We have to make sure the cached mapping is within EOF to protect
+ * against eofblocks trimming on file release leaving us with a stale
+ * mapping. Otherwise, a page for a subsequent file extending buffered
+ * write could get picked up by this writeback cycle and written to the
+ * wrong blocks.
+ *
+ * Note that what we really want here is a generic mapping invalidation
+ * mechanism to protect us from arbitrary extent modifying contexts, not
+ * just eofblocks.
+ */
+ xfs_trim_extent_eof(&wpc->imap, ip);
+
+ imap_valid = offset_fsb >= wpc->imap.br_startoff &&
+ offset_fsb < wpc->imap.br_startoff + wpc->imap.br_blockcount;
+ if (imap_valid && !xfs_is_reflink_inode(ip))
+ return 0;
+
if (XFS_FORCED_SHUTDOWN(mp))
return -EIO;
+ /*
+ * If we don't have a valid map, now it's time to get a new one for this
+ * offset. This will convert delayed allocations (including COW ones)
+ * into real extents. If we return without a valid map, it means we
+ * landed in a hole and we skip the block.
+ */
xfs_ilock(ip, XFS_ILOCK_SHARED);
ASSERT(ip->i_d.di_format != XFS_DINODE_FMT_BTREE ||
(ip->i_df.if_flags & XFS_IFEXTENTS));
@@ -399,7 +423,6 @@ xfs_map_blocks(
if (offset > mp->m_super->s_maxbytes - count)
count = mp->m_super->s_maxbytes - offset;
end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count);
- offset_fsb = XFS_B_TO_FSBT(mp, offset);
/*
* Check if this is offset is covered by a COW extents, and if yes use
@@ -432,7 +455,7 @@ xfs_map_blocks(
/*
* Map valid and no COW extent in the way? We're done.
*/
- if (wpc->imap_valid) {
+ if (imap_valid) {
xfs_iunlock(ip, XFS_ILOCK_SHARED);
return 0;
}
@@ -477,31 +500,6 @@ xfs_map_blocks(
return 0;
}
-STATIC bool
-xfs_imap_valid(
- struct inode *inode,
- struct xfs_bmbt_irec *imap,
- xfs_off_t offset)
-{
- offset >>= inode->i_blkbits;
-
- /*
- * We have to make sure the cached mapping is within EOF to protect
- * against eofblocks trimming on file release leaving us with a stale
- * mapping. Otherwise, a page for a subsequent file extending buffered
- * write could get picked up by this writeback cycle and written to the
- * wrong blocks.
- *
- * Note that what we really want here is a generic mapping invalidation
- * mechanism to protect us from arbitrary extent modifying contexts, not
- * just eofblocks.
- */
- xfs_trim_extent_eof(imap, XFS_I(inode));
-
- return offset >= imap->br_startoff &&
- offset < imap->br_startoff + imap->br_blockcount;
-}
-
STATIC void
xfs_start_buffer_writeback(
struct buffer_head *bh)
@@ -858,25 +856,11 @@ xfs_writepage_map(
continue;
}
- if (wpc->imap_valid)
- wpc->imap_valid = xfs_imap_valid(inode, &wpc->imap,
- file_offset);
- /*
- * If we don't have a valid map, now it's time to get a new one
- * for this offset. This will convert delayed allocations
- * (including COW ones) into real extents. If we return without
- * a valid map, it means we landed in a hole and we skip the
- * block.
- */
- if (!wpc->imap_valid || xfs_is_reflink_inode(XFS_I(inode))) {
- error = xfs_map_blocks(wpc, inode, file_offset);
- if (error)
- goto out;
- wpc->imap_valid = xfs_imap_valid(inode, &wpc->imap,
- file_offset);
- }
+ error = xfs_map_blocks(wpc, inode, file_offset);
+ if (error)
+ goto out;
- if (!wpc->imap_valid || wpc->io_type == XFS_IO_HOLE)
+ if (wpc->io_type == XFS_IO_HOLE)
continue;
lock_buffer(bh);
--
2.17.0
next prev parent reply other threads:[~2018-05-31 18:08 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-31 18:07 buffered writes without buffer heads in xfs and iomap v5 Christoph Hellwig
2018-05-31 18:07 ` [PATCH 01/21] fs: factor out a __generic_write_end helper Christoph Hellwig
2018-05-31 18:07 ` [PATCH 02/21] iomap: add initial support for writes without buffer heads Christoph Hellwig
2018-05-31 18:07 ` [PATCH 03/21] xfs: simplify xfs_bmap_punch_delalloc_range Christoph Hellwig
2018-05-31 18:07 ` [PATCH 04/21] xfs: simplify xfs_aops_discard_page Christoph Hellwig
2018-05-31 18:07 ` [PATCH 05/21] xfs: move locking into xfs_bmap_punch_delalloc_range Christoph Hellwig
2018-05-31 18:07 ` [PATCH 06/21] xfs: do not set the page uptodate in xfs_writepage_map Christoph Hellwig
2018-05-31 18:07 ` [PATCH 07/21] xfs: don't clear imap_valid for a non-uptodate buffers Christoph Hellwig
2018-05-31 18:07 ` [PATCH 08/21] xfs: don't use XFS_BMAPI_IGSTATE in xfs_map_blocks Christoph Hellwig
2018-06-04 12:25 ` Brian Foster
2018-05-31 18:07 ` [PATCH 09/21] xfs: remove xfs_reflink_trim_irec_to_next_cow Christoph Hellwig
2018-06-04 12:25 ` Brian Foster
2018-05-31 18:07 ` [PATCH 10/21] xfs: remove xfs_map_cow Christoph Hellwig
2018-06-04 12:25 ` Brian Foster
2018-06-13 15:30 ` Christoph Hellwig
2018-05-31 18:07 ` [PATCH 11/21] xfs: rename the offset variable in xfs_writepage_map Christoph Hellwig
2018-06-04 12:25 ` Brian Foster
2018-05-31 18:07 ` [PATCH 12/21] xfs: make xfs_writepage_map extent map centric Christoph Hellwig
2018-06-04 12:26 ` Brian Foster
2018-05-31 18:07 ` [PATCH 13/21] xfs: remove the now unused XFS_BMAPI_IGSTATE flag Christoph Hellwig
2018-06-04 12:27 ` Brian Foster
2018-05-31 18:07 ` [PATCH 14/21] xfs: remove xfs_reflink_find_cow_mapping Christoph Hellwig
2018-05-31 18:07 ` [PATCH 15/21] xfs: simplify xfs_map_blocks by using xfs_iext_lookup_extent directly Christoph Hellwig
2018-05-31 18:07 ` Christoph Hellwig [this message]
2018-05-31 18:07 ` [PATCH 17/21] xfs: don't look at buffer heads in xfs_add_to_ioend Christoph Hellwig
2018-05-31 18:07 ` [PATCH 18/21] xfs: move all writeback buffer_head manipulation into xfs_map_at_offset Christoph Hellwig
2018-05-31 18:07 ` [PATCH 19/21] xfs: remove xfs_start_page_writeback Christoph Hellwig
2018-05-31 18:07 ` [PATCH 20/21] xfs: refactor the tail of xfs_writepage_map Christoph Hellwig
2018-05-31 18:07 ` [PATCH 21/21] xfs: allow writeback on pages without buffer heads 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=20180531180759.21631-17-hch@lst.de \
--to=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.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).