All of lore.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 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.