From: "Darrick J. Wong" <djwong@kernel.org>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: don't call into blockgc scan with freeze protection
Date: Thu, 18 Feb 2021 19:23:09 -0800 [thread overview]
Message-ID: <20210219032309.GX7193@magnolia> (raw)
In-Reply-To: <20210218201458.718889-1-bfoster@redhat.com>
On Thu, Feb 18, 2021 at 03:14:58PM -0500, Brian Foster wrote:
> fstest xfs/167 produced a lockdep splat that complained about a
> nested transaction acquiring freeze protection during an eofblocks
> scan. Drop freeze protection around the block reclaim scan in the
> transaction allocation code to avoid this problem.
>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
I think it seems reasonable, though I really wish that other patchset to
clean up all the "modify thread state when we start/end transactions"
had landed.
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> ---
> fs/xfs/xfs_trans.c | 19 ++++++++++++++-----
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c
> index 44f72c09c203..c32c62d3b77a 100644
> --- a/fs/xfs/xfs_trans.c
> +++ b/fs/xfs/xfs_trans.c
> @@ -261,6 +261,7 @@ xfs_trans_alloc(
> {
> struct xfs_trans *tp;
> int error;
> + bool retried = false;
>
> /*
> * Allocate the handle before we do our freeze accounting and setting up
> @@ -288,19 +289,27 @@ xfs_trans_alloc(
> INIT_LIST_HEAD(&tp->t_dfops);
> tp->t_firstblock = NULLFSBLOCK;
>
> +retry:
> error = xfs_trans_reserve(tp, resp, blocks, rtextents);
> - if (error == -ENOSPC) {
> + if (error == -ENOSPC && !retried) {
> /*
> * We weren't able to reserve enough space for the transaction.
> * Flush the other speculative space allocations to free space.
> * Do not perform a synchronous scan because callers can hold
> * other locks.
> */
> + retried = true;
> + if (!(flags & XFS_TRANS_NO_WRITECOUNT))
> + sb_end_intwrite(mp->m_super);
> error = xfs_blockgc_free_space(mp, NULL);
> - if (!error)
> - error = xfs_trans_reserve(tp, resp, blocks, rtextents);
> - }
> - if (error) {
> + if (error) {
> + kmem_cache_free(xfs_trans_zone, tp);
> + return error;
> + }
> + if (!(flags & XFS_TRANS_NO_WRITECOUNT))
> + sb_start_intwrite(mp->m_super);
> + goto retry;
> + } else if (error) {
> xfs_trans_cancel(tp);
> return error;
> }
> --
> 2.26.2
>
next prev parent reply other threads:[~2021-02-19 3:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 20:14 [PATCH] xfs: don't call into blockgc scan with freeze protection Brian Foster
2021-02-19 3:23 ` Darrick J. Wong [this message]
2021-02-19 4:56 ` Dave Chinner
2021-02-19 13:09 ` Brian Foster
2021-02-19 20:42 ` Dave Chinner
2021-02-22 12:05 ` Brian Foster
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=20210219032309.GX7193@magnolia \
--to=djwong@kernel.org \
--cc=bfoster@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.