public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 07/11] xfs: mark reclaimed inodes invalid earlier
Date: Fri, 15 Apr 2016 09:31:01 +1000	[thread overview]
Message-ID: <20160414233101.GY567@dastard> (raw)
In-Reply-To: <20160414121048.GB20696@bfoster.bfoster>

On Thu, Apr 14, 2016 at 08:10:49AM -0400, Brian Foster wrote:
> On Wed, Apr 13, 2016 at 04:49:00PM +1000, Dave Chinner wrote:
> > On Wed, Apr 13, 2016 at 03:31:28PM +1000, Dave Chinner wrote:
> > > From: Dave Chinner <dchinner@redhat.com>
> > > 
> > > The last thing we do before using call_rcu() on an xfs_inode to be
> > > freed is mark it as invalid. This means there is a window between
> > > when we know for certain that the inode is going to be freed and
> > > when we do actually mark it as "freed".
> > > 
> > > This is important in the context of RCU lookups - we can look up the
> > > inode, find that it is valid, and then use it as such not realising
> > > that it is in the final stages of being freed.
> > > 
> > > As such, mark the inode as being invalid the moment we know it is
> > > going to be reclaimed. This can be done while we still hold the
> > > XFS_ILOCK_EXCL and the flush lock in xfs_inode_reclaim, meaning that
> > > it occurs well before we remove it from the radix tree, and that
> > > the i_flags_lock, the XFS_ILOCK and the inode flush lock all act as
> > > synchronisation points for detecting that an inode is about to go
> > > away.
> > > 
> > > For defensive purposes, this allows us to add a further check to
> > > xfs_iflush_cluster to ensure we skip inodes that are being freed
> > > after we grab the XFS_ILOCK_SHARED and the flush lock - we know that
> > > if the inode number if valid while we have these locks held we know
> > > that it has not progressed through reclaim to the point where it is
> > > clean and is about to be freed.
> > > 
> > > [bfoster: fixed __xfs_inode_clear_reclaim() using ip->i_ino after it
> > > 	  had already been zeroed.]
> > 
> > And, of course, in reordering this I dropped this fix because it was
> > handled by the reworking of tagging code to use pag->pag_agno.
> > 
> > So I've brought that small change forward to this patch (using
> > pag->pag_agno instead of deriving it from the ip->i_ino in
> > __xfs_inode_clear_reclaim()).
> > 
> 
> I don't see any such change in this patch..?
> __xfs_inode_clear_reclaim() still uses ip->i_ino.

I meant that I realised that I'd screwed it up and so I'd changed my
local copy after I sent this.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-04-14 23:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13  5:31 [PATCH 00/11 v3] xfs: inode reclaim vs the world Dave Chinner
2016-04-13  5:31 ` [PATCH 01/11] xfs: we don't need no steekin ->evict_inode Dave Chinner
2016-04-13 16:41   ` Christoph Hellwig
2016-04-13 21:20     ` Dave Chinner
2016-04-14 12:10   ` Brian Foster
2016-04-13  5:31 ` [PATCH 02/11] xfs: xfs_iflush_cluster fails to abort on error Dave Chinner
2016-04-13 16:41   ` Christoph Hellwig
2016-04-13  5:31 ` [PATCH 03/11] xfs: fix inode validity check in xfs_iflush_cluster Dave Chinner
2016-04-13  5:31 ` [PATCH 04/11] xfs: skip stale inodes " Dave Chinner
2016-04-13  5:31 ` [PATCH 05/11] xfs: optimise xfs_iext_destroy Dave Chinner
2016-04-13 16:45   ` Christoph Hellwig
2016-04-13  5:31 ` [PATCH 06/11] xfs: xfs_inode_free() isn't RCU safe Dave Chinner
2016-04-13  5:31 ` [PATCH 07/11] xfs: mark reclaimed inodes invalid earlier Dave Chinner
2016-04-13  6:49   ` Dave Chinner
2016-04-14 12:10     ` Brian Foster
2016-04-14 23:31       ` Dave Chinner [this message]
2016-04-15 12:46         ` Brian Foster
2016-04-13  5:31 ` [PATCH 08/11] xfs: xfs_iflush_cluster has range issues Dave Chinner
2016-04-13  5:31 ` [PATCH 09/11] xfs: rename variables in xfs_iflush_cluster for clarity Dave Chinner
2016-04-13  5:31 ` [PATCH 10/11] xfs: simplify inode reclaim tagging interfaces Dave Chinner
2016-04-14 12:10   ` Brian Foster
2016-06-29  4:21   ` Darrick J. Wong
2016-04-13  5:31 ` [PATCH 11/11] xfs: move reclaim tagging functions Dave Chinner
2016-04-14 12:11   ` Brian Foster
2016-04-13 15:38 ` [PATCH 00/11 v3] xfs: inode reclaim vs the world Darrick J. Wong

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=20160414233101.GY567@dastard \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=xfs@oss.sgi.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