public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 6/6] XFS: Prevent looping in xfs_sync_inodes_ag
Date: Thu, 9 Oct 2008 11:02:01 +1100	[thread overview]
Message-ID: <20081009000201.GB9597@disturbed> (raw)
In-Reply-To: <20081008182138.GB22941@infradead.org>

On Wed, Oct 08, 2008 at 02:21:38PM -0400, Christoph Hellwig wrote:
> On Wed, Oct 08, 2008 at 08:54:40AM +1100, Dave Chinner wrote:
> > If the last  block of the AG has inodes in it and the AG is an
> > exactly power-of-2 size then the last inode in the AG points
> > to the last block in the AG. If we try to find the next inode
> > in the AG by adding one to the inode number, we increment the
> > inode number past the size of the AG. The result is that the
> > macro XFS_INO_TO_AGINO() will strip the AG portion of the inode
> > number and return an inode number of zero.
> > 
> > That is, instead of terminating the lookup loop because we hit the
> > inode number went outside the valid range for the AG, the search
> > index returns to zero and we start traversing the radix tree from
> > the start again. This results in an endless loop in
> > xfs_sync_inodes_ag().
> > 
> > Fix it be detecting if the new search index decreases as a result of
> > incrementing the current inode number. That indicate an overflow and
> > hence that we have finished processing the AG so we can terminate
> > the loop.
> 
> Shouldn't this get merged into the patch that introduces the radix-tree
> based sync?

It could be, but I didn't want to have to redo that reviewed patch
series. I've only hit this problem once in the past 6 weeks so I
thought adding a new patch rather than modifying patches to add the
fix was a better way to go....

I can integrate it if you want....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2008-10-09  0:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 21:54 [PATCH 0/6] XFS: Track reclaimable inodes in inode cache Dave Chinner
2008-10-07 21:54 ` [PATCH 1/6] XFS: move inode reclaim functions to xfs_sync.c Dave Chinner
2008-10-07 21:54 ` [PATCH 2/6] XFS: rename inode reclaim functions Dave Chinner
2008-10-07 21:54 ` [PATCH 3/6] XFS: mark inodes for reclaim via a tag in the inode radix tree Dave Chinner
2008-10-07 21:54 ` [PATCH 4/6] XFS: use the inode radix tree for reclaiming inodes Dave Chinner
2008-10-07 21:54 ` [PATCH 5/6] XFS: kill deleted inodes list Dave Chinner
2008-10-07 21:54 ` [PATCH 6/6] XFS: Prevent looping in xfs_sync_inodes_ag Dave Chinner
2008-10-08 18:21   ` Christoph Hellwig
2008-10-09  0:02     ` Dave Chinner [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=20081009000201.GB9597@disturbed \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --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