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
prev parent 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