linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Waiman Long <longman@redhat.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	Qian Cai <cai@lca.pw>, Eric Sandeen <sandeen@redhat.com>
Subject: Re: [PATCH v4] xfs: Fix false positive lockdep warning with sb_internal & fs_reclaim
Date: Fri, 19 Jun 2020 08:58:10 +1000	[thread overview]
Message-ID: <20200618225810.GJ2005@dread.disaster.area> (raw)
In-Reply-To: <20200618171941.9475-1-longman@redhat.com>

On Thu, Jun 18, 2020 at 01:19:41PM -0400, Waiman Long wrote:
> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
> index 379cbff438bc..1b94b9bfa4d7 100644
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@ -913,11 +913,33 @@ xfs_fs_freeze(
>  	struct super_block	*sb)
>  {
>  	struct xfs_mount	*mp = XFS_M(sb);
> +	unsigned long		pflags;
> +	int			ret;
>  
> +	/*
> +	 * A fs_reclaim pseudo lock is added to check for potential deadlock
> +	 * condition with fs reclaim. The following lockdep splat was hit
> +	 * occasionally. This is actually a false positive as the allocation
> +	 * is being done only after the frozen filesystem is no longer dirty.
> +	 * One way to avoid this splat is to add GFP_NOFS to the affected
> +	 * allocation calls. This is what PF_MEMALLOC_NOFS is for.
> +	 *
> +	 *       CPU0                    CPU1
> +	 *       ----                    ----
> +	 *  lock(sb_internal);
> +	 *                               lock(fs_reclaim);
> +	 *                               lock(sb_internal);
> +	 *  lock(fs_reclaim);
> +	 *
> +	 *  *** DEADLOCK ***
> +	 */

The lockdep splat is detailed in the commit message - it most
definitely does not need to be repeated in full here because:

	a) it doesn't explain why the splat occurring is, and
	b) we most definitely don't care about how the lockdep check
	   that triggered it is implemented.

IOWs, the comment here needs to explain how the freeze state held at
this point requires that we avoid reclaim recursion back into the
filesystem, regardless of how lockdep detects it or whether the
lockdep splats are a false positive or not...

e.g.

/*
 * The superblock is now in the frozen state, which means we cannot
 * allow memory allocation to recurse into reclaim on this
 * filesystem as this may require running operations that the
 * current freeze state prevents. This should not occur if
 * everything is working correctly and sometimes lockdep may report
 * false positives in this path. However, to be safe and to avoid
 * unnecessary false positives in test/CI environments, put the
 * entire final freeze processing path under GFP_NOFS allocation
 * contexts to prevent reclaim recursion from occurring anywhere in
 * the path.
 */

Cheers,

Dave.

> +	current_set_flags_nested(&pflags, PF_MEMALLOC_NOFS);
>  	xfs_stop_block_reaping(mp);
>  	xfs_save_resvblks(mp);
>  	xfs_quiesce_attr(mp);
> -	return xfs_sync_sb(mp, true);
> +	ret = xfs_sync_sb(mp, true);
> +	current_restore_flags_nested(&pflags, PF_MEMALLOC_NOFS);
> +	return ret;
>  }
>  
>  STATIC int
> -- 
> 2.18.1
> 
> 

-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2020-06-18 22:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-18 17:19 [PATCH v4] xfs: Fix false positive lockdep warning with sb_internal & fs_reclaim Waiman Long
2020-06-18 22:58 ` Dave Chinner [this message]
2020-06-18 23:04   ` Dave Chinner
2020-06-22 17:56     ` Waiman Long

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=20200618225810.GJ2005@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=cai@lca.pw \
    --cc=darrick.wong@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=sandeen@redhat.com \
    /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).