linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: linux-xfs@vger.kernel.org, zlang@redhat.com
Subject: Re: [PATCH] xfs: fix unbalanced inode reclaim flush locking
Date: Mon, 17 Oct 2016 12:17:52 -0400	[thread overview]
Message-ID: <20161017161752.GF12736@bfoster.bfoster> (raw)
In-Reply-To: <5b9824d0-2cce-93a9-09ce-aa3c5825e4df@sandeen.net>

On Mon, Oct 17, 2016 at 10:54:18AM -0500, Eric Sandeen wrote:
> On 10/17/16 10:02 AM, Brian Foster wrote:
> > Filesystem shutdown testing on an older distro kernel has uncovered an
> > imbalanced locking pattern for the inode flush lock in
> > xfs_reclaim_inode(). Specifically, there is a double unlock sequence
> > between the call to xfs_iflush_abort() and xfs_reclaim_inode() at the
> > "reclaim:" label.
> > 
> > This actually does not cause obvious problems on current kernels due to
> > the current flush lock implementation. Older kernels use a counting
> > based flush lock mechanism, however, which effectively breaks the lock
> > indefinitely when an already unlocked flush lock is repeatedly unlocked.
> > Though this only currently occurs on filesystem shutdown, it has
> > reproduced the effect of elevating an fs shutdown to a system-wide crash
> > or hang.
> > 
> > Because this problem exists on filesystem shutdown and thus only after
> > unrelated catastrophic failure, issue the simple fix to reacquire the
> > flush lock in xfs_reclaim_inode() before jumping to the reclaim code.
> > Add an assert to xfs_ifunlock() to help prevent future occurrences of
> > the same problem. Finally, update xfs_reclaim_inode() to bitwise-OR the
> > reclaim flag to avoid smashing the flush lock in the process (which is
> > based on an inode flag in current kernels). This avoids a (spurious)
> > failure of the newly introduced xfs_ifunlock() assertion.
> > 
> > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > Reported-by: Zorro Lang <zlang@redhat.com>
> > ---
> >  fs/xfs/xfs_icache.c |  3 ++-
> >  fs/xfs/xfs_inode.h  | 11 ++++++-----
> >  2 files changed, 8 insertions(+), 6 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c
> > index 14796b7..7375313 100644
> > --- a/fs/xfs/xfs_icache.c
> > +++ b/fs/xfs/xfs_icache.c
> > @@ -982,6 +982,7 @@ restart:
> >  	if (XFS_FORCED_SHUTDOWN(ip->i_mount)) {
> >  		xfs_iunpin_wait(ip);
> 
> I suppose comments here might help...
> 
> Other callers of xfs_iflush_abort include:
> 
>         /*
>          * Unlocks the flush lock
>          */
> 
> and immediately re-locking it here might be worth explaining as well.
> 

Indeed, I'll add something.

> >  		xfs_iflush_abort(ip, false);
> > +		xfs_iflock(ip);
> >  		goto reclaim;
> >  	}
> >  	if (xfs_ipincount(ip)) {
> 
> > @@ -1044,7 +1045,7 @@ reclaim:
> >  	 * skip.
> >  	 */
> >  	spin_lock(&ip->i_flags_lock);
> > -	ip->i_flags = XFS_IRECLAIM;
> > +	ip->i_flags |= XFS_IRECLAIM;
> >  	ip->i_ino = 0;
> >  	spin_unlock(&ip->i_flags_lock);
> >  
> 
> I think xfs_inode_free() should get the same |= treatment?
> 

Yeah, I think that makes sense. That would allow the
ASSERT(!xfs_isiflocked(ip)) check in __xfs_inode_free() to actually
work. Thanks!

Brian

> -Eric
> 
> 
> > diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h
> > index f14c1de..71e8a81 100644
> > --- a/fs/xfs/xfs_inode.h
> > +++ b/fs/xfs/xfs_inode.h
> > @@ -246,6 +246,11 @@ static inline bool xfs_is_reflink_inode(struct xfs_inode *ip)
> >   * Synchronize processes attempting to flush the in-core inode back to disk.
> >   */
> >  
> > +static inline int xfs_isiflocked(struct xfs_inode *ip)
> > +{
> > +	return xfs_iflags_test(ip, XFS_IFLOCK);
> > +}
> > +
> >  extern void __xfs_iflock(struct xfs_inode *ip);
> >  
> >  static inline int xfs_iflock_nowait(struct xfs_inode *ip)
> > @@ -261,16 +266,12 @@ static inline void xfs_iflock(struct xfs_inode *ip)
> >  
> >  static inline void xfs_ifunlock(struct xfs_inode *ip)
> >  {
> > +	ASSERT(xfs_isiflocked(ip));
> >  	xfs_iflags_clear(ip, XFS_IFLOCK);
> >  	smp_mb();
> >  	wake_up_bit(&ip->i_flags, __XFS_IFLOCK_BIT);
> >  }
> >  
> > -static inline int xfs_isiflocked(struct xfs_inode *ip)
> > -{
> > -	return xfs_iflags_test(ip, XFS_IFLOCK);
> > -}
> > -
> >  /*
> >   * Flags for inode locking.
> >   * Bit ranges:	1<<1  - 1<<16-1 -- iolock/ilock modes (bitfield)
> > 

      reply	other threads:[~2016-10-17 16:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 15:02 [PATCH] xfs: fix unbalanced inode reclaim flush locking Brian Foster
2016-10-17 15:54 ` Eric Sandeen
2016-10-17 16:17   ` Brian Foster [this message]

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=20161017161752.GF12736@bfoster.bfoster \
    --to=bfoster@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --cc=zlang@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).