From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Chandan Babu R <chandan.babu@oracle.com>,
Christian Brauner <brauner@kernel.org>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 07/12] xfs: take XFS_MMAPLOCK_EXCL xfs_file_write_zero_eof
Date: Tue, 17 Sep 2024 14:24:27 -0700 [thread overview]
Message-ID: <20240917212427.GD182177@frogsfrogsfrogs> (raw)
In-Reply-To: <20240910043949.3481298-8-hch@lst.de>
On Tue, Sep 10, 2024 at 07:39:09AM +0300, Christoph Hellwig wrote:
> xfs_file_write_zero_eof is the only caller of xfs_zero_range that does
> not take XFS_MMAPLOCK_EXCL (aka the invalidate lock). Currently that
> is acrually the right thing, as an error in the iomap zeroing code will
actually
> also take the invalidate_lock to clean up, but to fix that deadlock we
> need a consistent locking pattern first.
>
> The only extra thing that XFS_MMAPLOCK_EXCL will lock out are read
> pagefaults, which isn't really needed here, but also not actively
> harmful.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> fs/xfs/xfs_file.c | 8 +++++++-
> fs/xfs/xfs_iomap.c | 2 ++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index a30fda1985e6af..37dc26f51ace65 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -357,6 +357,7 @@ xfs_file_write_zero_eof(
> {
> struct xfs_inode *ip = XFS_I(iocb->ki_filp->f_mapping->host);
> loff_t isize;
> + int error;
>
> /*
> * We need to serialise against EOF updates that occur in IO completions
> @@ -404,7 +405,12 @@ xfs_file_write_zero_eof(
> }
>
> trace_xfs_zero_eof(ip, isize, iocb->ki_pos - isize);
> - return xfs_zero_range(ip, isize, iocb->ki_pos - isize, NULL);
> +
> + xfs_ilock(ip, XFS_MMAPLOCK_EXCL);
> + error = xfs_zero_range(ip, isize, iocb->ki_pos - isize, NULL);
> + xfs_iunlock(ip, XFS_MMAPLOCK_EXCL);
Ah, ok, so we're taking the invalidate_lock so that we can't have page
faults that might add folios (or dirty existing ones) in the mapping.
We're the only ones who can access the page cache, and we're doing that
so that we can zero the folios between the old EOF and the start of the
write region.
Is that right? Then
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> +
> + return error;
> }
>
> /*
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 1e11f48814c0d0..3c98d82c0ad0dc 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1435,6 +1435,8 @@ xfs_zero_range(
> {
> struct inode *inode = VFS_I(ip);
>
> + xfs_assert_ilocked(ip, XFS_IOLOCK_EXCL | XFS_MMAPLOCK_EXCL);
> +
> if (IS_DAX(inode))
> return dax_zero_range(inode, pos, len, did_zero,
> &xfs_dax_write_iomap_ops);
> --
> 2.45.2
>
>
next prev parent reply other threads:[~2024-09-17 21:24 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 4:39 fix stale delalloc punching for COW I/O v2 Christoph Hellwig
2024-09-10 4:39 ` [PATCH 01/12] iomap: handle a post-direct I/O invalidate race in iomap_write_delalloc_release Christoph Hellwig
2024-09-10 4:39 ` [PATCH 02/12] iomap: improve shared block detection in iomap_unshare_iter Christoph Hellwig
2024-09-10 4:39 ` [PATCH 03/12] iomap: pass flags to iomap_file_buffered_write_punch_delalloc Christoph Hellwig
2024-09-10 4:39 ` [PATCH 04/12] iomap: pass the iomap to the punch callback Christoph Hellwig
2024-09-10 4:39 ` [PATCH 05/12] iomap: remove the iomap_file_buffered_write_punch_delalloc return value Christoph Hellwig
2024-09-10 4:39 ` [PATCH 06/12] xfs: factor out a xfs_file_write_zero_eof helper Christoph Hellwig
2024-09-17 21:14 ` Darrick J. Wong
2024-09-18 5:09 ` Christoph Hellwig
2024-09-18 15:30 ` Darrick J. Wong
2024-09-20 0:25 ` Dave Chinner
2024-09-20 11:31 ` Christoph Hellwig
2024-09-10 4:39 ` [PATCH 07/12] xfs: take XFS_MMAPLOCK_EXCL xfs_file_write_zero_eof Christoph Hellwig
2024-09-17 21:24 ` Darrick J. Wong [this message]
2024-09-18 5:10 ` Christoph Hellwig
2024-09-10 4:39 ` [PATCH 08/12] iomap: zeroing already holds invalidate_lock Christoph Hellwig
2024-09-17 21:29 ` Darrick J. Wong
2024-09-18 5:15 ` Christoph Hellwig
2024-09-18 15:32 ` Darrick J. Wong
2024-09-20 0:42 ` Dave Chinner
2024-09-10 4:39 ` [PATCH 09/12] xfs: support the COW fork in xfs_bmap_punch_delalloc_range Christoph Hellwig
2024-09-10 4:39 ` [PATCH 10/12] xfs: share more code in xfs_buffered_write_iomap_begin Christoph Hellwig
2024-09-10 4:39 ` [PATCH 11/12] xfs: set IOMAP_F_SHARED for all COW fork allocations Christoph Hellwig
2024-09-10 4:39 ` [PATCH 12/12] xfs: punch delalloc extents from the COW fork for COW writes Christoph Hellwig
2024-09-10 9:21 ` fix stale delalloc punching for COW I/O v2 Christian Brauner
2024-09-10 15:17 ` Christoph Hellwig
2024-09-10 9:22 ` (subset) " Christian Brauner
2024-09-10 15:17 ` 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=20240917212427.GD182177@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=brauner@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=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).