linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 08/12] iomap: zeroing already holds invalidate_lock
Date: Wed, 18 Sep 2024 08:32:58 -0700	[thread overview]
Message-ID: <20240918153258.GG182177@frogsfrogsfrogs> (raw)
In-Reply-To: <20240918051523.GC31238@lst.de>

On Wed, Sep 18, 2024 at 07:15:23AM +0200, Christoph Hellwig wrote:
> On Tue, Sep 17, 2024 at 02:29:35PM -0700, Darrick J. Wong wrote:
> > On Tue, Sep 10, 2024 at 07:39:10AM +0300, Christoph Hellwig wrote:
> > > All callers of iomap_zero_range already hold invalidate_lock, so we can't
> > > take it again in iomap_file_buffered_write_punch_delalloc.
> > > 
> > > Use the passed in flags argument to detect if we're called from a zeroing
> > > operation and don't take the lock again in this case.
> > > 
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > ---
> > >  fs/iomap/buffered-io.c | 10 ++++++++--
> > >  1 file changed, 8 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> > > index 52f285ae4bddcb..3d7e69a542518a 100644
> > > --- a/fs/iomap/buffered-io.c
> > > +++ b/fs/iomap/buffered-io.c
> > > @@ -1188,8 +1188,13 @@ static void iomap_write_delalloc_release(struct inode *inode, loff_t start_byte,
> > >  	 * folios and dirtying them via ->page_mkwrite whilst we walk the
> > >  	 * cache and perform delalloc extent removal. Failing to do this can
> > >  	 * leave dirty pages with no space reservation in the cache.
> > > +	 *
> > > +	 * For zeroing operations the callers already hold invalidate_lock.
> > >  	 */
> > > -	filemap_invalidate_lock(inode->i_mapping);
> > > +	if (flags & IOMAP_ZERO)
> > > +		rwsem_assert_held_write(&inode->i_mapping->invalidate_lock);
> > 
> > Does the other iomap_zero_range user (gfs2) take the invalidate lock?
> > AFAICT it doesn't.  Shouldn't we annotate iomap_zero_range to say that
> > callers have to hold i_rwsem and the invalidate_lock?
> 
> gfs2 does not hold invalidate_lock over iomap_zero_range.  But
> it also does not use iomap_file_buffered_write_punch_delalloc at
> all, which is what requires the lock (and asserts that it is held).

Aha, that's why it works.  Silly me, forgetting that gfs2 doesn't do
delalloc.  It was quite relaxing to let everything page out of my brain
these past two weeks... :)

--D

  reply	other threads:[~2024-09-18 15:32 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
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 [this message]
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=20240918153258.GG182177@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).