linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs: move the check for post-EOF mappings into xfs_can_free_eofblocks
Date: Thu, 18 Mar 2021 23:05:34 -0700	[thread overview]
Message-ID: <20210319060534.GF1670408@magnolia> (raw)
In-Reply-To: <20210319055907.GB955126@infradead.org>

On Fri, Mar 19, 2021 at 05:59:07AM +0000, Christoph Hellwig wrote:
> On Thu, Mar 18, 2021 at 03:33:37PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Fix the weird split of responsibilities between xfs_can_free_eofblocks
> > and xfs_free_eofblocks by moving the chunk of code that looks for any
> > actual post-EOF space mappings from the second function into the first.
> > 
> > This clears the way for deferred inode inactivation to be able to decide
> > if an inode needs inactivation work before committing the released inode
> > to the inactivation code paths (vs. marking it for reclaim).
> > 
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> >  fs/xfs/xfs_bmap_util.c |  148 +++++++++++++++++++++++++-----------------------
> >  1 file changed, 78 insertions(+), 70 deletions(-)
> > 
> > 
> > diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
> > index e7d68318e6a5..d4ceba5370c7 100644
> > --- a/fs/xfs/xfs_bmap_util.c
> > +++ b/fs/xfs/xfs_bmap_util.c
> > @@ -597,8 +597,17 @@ xfs_bmap_punch_delalloc_range(
> >   * regular files that are marked preallocated or append-only.
> >   */
> >  bool
> > -xfs_can_free_eofblocks(struct xfs_inode *ip, bool force)
> > +xfs_can_free_eofblocks(
> > +	struct xfs_inode	*ip,
> > +	bool			force)
> >  {
> > +	struct xfs_bmbt_irec	imap;
> > +	struct xfs_mount	*mp = ip->i_mount;
> > +	xfs_fileoff_t		end_fsb;
> > +	xfs_fileoff_t		last_fsb;
> > +	int			nimaps = 1;
> > +	int			error;
> 
> Should we have an assert here that this is called under the iolock?
> Or can't the reclaim be expressed nicely?

xfs_inactive doesn't take the iolock because (evidently) at some point
there were lockdep complaints about taking it in reclaim context.  By
the time the inode reaches inactivation context, there can't be any
other users of it anyway -- the last caller dropped its reference, we
tore down the VFS inode, and anyone who wants to resuscitate the inode
will wait in xfs_iget for us to finish.

--D

> > +/*
> > + * This is called to free any blocks beyond eof. The caller must hold
> > + * IOLOCK_EXCL unless we are in the inode reclaim path and have the only
> > + * reference to the inode.
> > + */
> 
> Same thing here, usually asserts are better than comments..  That being
> said can_free_eofblocks would benefit from at least a comment if the
> assert doesn't work.
> 
> Otherwise this looks good.

  reply	other threads:[~2021-03-19  6:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 22:33 [PATCHSET 0/2] xfs: make xfs_can_free_eofblocks a predicate Darrick J. Wong
2021-03-18 22:33 ` [PATCH 1/2] xfs: move the xfs_can_free_eofblocks call under the IOLOCK Darrick J. Wong
2021-03-19  5:53   ` Christoph Hellwig
2021-03-19  6:01     ` Darrick J. Wong
2021-03-19  6:31       ` Christoph Hellwig
2021-03-18 22:33 ` [PATCH 2/2] xfs: move the check for post-EOF mappings into xfs_can_free_eofblocks Darrick J. Wong
2021-03-19  5:59   ` Christoph Hellwig
2021-03-19  6:05     ` Darrick J. Wong [this message]
2021-03-19  6:35       ` Christoph Hellwig
2021-03-19 16:59         ` Darrick J. Wong
2021-03-23 18:32           ` Christoph Hellwig
2021-03-26  0:20 [PATCHSET v2 0/2] xfs: make xfs_can_free_eofblocks a predicate Darrick J. Wong
2021-03-26  0:21 ` [PATCH 2/2] xfs: move the check for post-EOF mappings into xfs_can_free_eofblocks Darrick J. Wong
2021-03-26  6:00   ` 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=20210319060534.GF1670408@magnolia \
    --to=djwong@kernel.org \
    --cc=hch@infradead.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).