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.
next prev parent 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).