From: "Darrick J. Wong" <djwong@kernel.org>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: linux-xfs@vger.kernel.org, linux-afs@lists.infradead.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/3] xfs: Remove xfs_filemap_map_pages() wrapper
Date: Wed, 8 Feb 2023 08:39:19 -0800 [thread overview]
Message-ID: <Y+PQN8cLdOXST20D@magnolia> (raw)
In-Reply-To: <20230208145335.307287-2-willy@infradead.org>
On Wed, Feb 08, 2023 at 02:53:33PM +0000, Matthew Wilcox (Oracle) wrote:
> XFS doesn't actually need to be holding the XFS_MMAPLOCK_SHARED
> to do this, any more than it needs the XFS_MMAPLOCK_SHARED for a
> read() that hits in the page cache.
Hmm. From commit cd647d5651c0 ("xfs: use MMAPLOCK around
filemap_map_pages()"):
The page faultround path ->map_pages is implemented in XFS via
filemap_map_pages(). This function checks that pages found in page
cache lookups have not raced with truncate based invalidation by
checking page->mapping is correct and page->index is within EOF.
However, we've known for a long time that this is not sufficient to
protect against races with invalidations done by operations that do
not change EOF. e.g. hole punching and other fallocate() based
direct extent manipulations. The way we protect against these
races is we wrap the page fault operations in a XFS_MMAPLOCK_SHARED
lock so they serialise against fallocate and truncate before calling
into the filemap function that processes the fault.
Do the same for XFS's ->map_pages implementation to close this
potential data corruption issue.
How do we prevent faultaround from racing with fallocate and reflink
calls that operate below EOF?
--D
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> fs/xfs/xfs_file.c | 17 +----------------
> 1 file changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index 705250f9f90a..528fc538b6b9 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -1388,25 +1388,10 @@ xfs_filemap_pfn_mkwrite(
> return __xfs_filemap_fault(vmf, PE_SIZE_PTE, true);
> }
>
> -static vm_fault_t
> -xfs_filemap_map_pages(
> - struct vm_fault *vmf,
> - pgoff_t start_pgoff,
> - pgoff_t end_pgoff)
> -{
> - struct inode *inode = file_inode(vmf->vma->vm_file);
> - vm_fault_t ret;
> -
> - xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
> - ret = filemap_map_pages(vmf, start_pgoff, end_pgoff);
> - xfs_iunlock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
> - return ret;
> -}
> -
> static const struct vm_operations_struct xfs_file_vm_ops = {
> .fault = xfs_filemap_fault,
> .huge_fault = xfs_filemap_huge_fault,
> - .map_pages = xfs_filemap_map_pages,
> + .map_pages = filemap_map_pages,
> .page_mkwrite = xfs_filemap_page_mkwrite,
> .pfn_mkwrite = xfs_filemap_pfn_mkwrite,
> };
> --
> 2.35.1
>
next prev parent reply other threads:[~2023-02-08 16:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 14:53 [PATCH 0/3] Prevent ->map_pages from sleeping Matthew Wilcox (Oracle)
2023-02-08 14:53 ` [PATCH 1/3] xfs: Remove xfs_filemap_map_pages() wrapper Matthew Wilcox (Oracle)
2023-02-08 16:39 ` Darrick J. Wong [this message]
2023-02-08 17:12 ` Matthew Wilcox
2023-02-08 21:53 ` Dave Chinner
2023-02-09 2:44 ` Matthew Wilcox
2023-02-09 21:53 ` Dave Chinner
2023-02-09 22:34 ` Matthew Wilcox
2023-02-09 23:59 ` Dave Chinner
2023-02-08 14:53 ` [PATCH 2/3] afs: Split afs_pagecache_valid() out of afs_validate() Matthew Wilcox (Oracle)
2023-02-08 14:53 ` [PATCH 3/3] mm: Hold the RCU read lock over calls to ->map_pages Matthew Wilcox (Oracle)
2023-02-09 14:28 ` [PATCH 2/3] afs: Split afs_pagecache_valid() out of afs_validate() David Howells
2023-02-09 14:56 ` Matthew Wilcox
2023-02-09 14:49 ` David Howells
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=Y+PQN8cLdOXST20D@magnolia \
--to=djwong@kernel.org \
--cc=linux-afs@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.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).