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 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.