[Top] [All Lists]

Re: [PATCH] xfs_repair: Check if agno is inside the filesystem

To: Lukas Czerner <lczerner@xxxxxxxxxx>
Subject: Re: [PATCH] xfs_repair: Check if agno is inside the filesystem
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 28 Jun 2011 21:37:02 +1000
Cc: xfs@xxxxxxxxxxx, aelder@xxxxxxx
In-reply-to: <alpine.LFD.2.00.1106281120250.3864@xxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <1309193610-17078-1-git-send-email-lczerner@xxxxxxxxxx> <20110628012838.GI32466@dastard> <alpine.LFD.2.00.1106281120250.3864@xxxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Tue, Jun 28, 2011 at 11:24:46AM +0200, Lukas Czerner wrote:
> On Tue, 28 Jun 2011, Dave Chinner wrote:
> > On Mon, Jun 27, 2011 at 06:53:30PM +0200, Lukas Czerner wrote:
> > > When getting an inode tree pointer from an array inode_tree_ptrs, we
> > > should check if agno, which is used as a pointer to the array, lives
> > > within the file system, because if it is not, we can end up touching
> > > uninitialized memory.
> > 
> > How do you get an agno outside the bounds of the filesystem?
> Hi Dave,
> in my particular case the problem was in
> longform_dir2_entry_check_data(). xfs_dir2_data_entry_t was read and we
> used inode numbed (xfs_dir2_data_entry_t)->inumber to compute AG number.
> However it contained garbage so the resulting agno was too high. In
> modify mode it was not a problem, because the inode was cleared in the
> earlies phase, but in no_modify mode, the was still there.

Ok, a corrupted directory entry is the cause. Might be worthwhile
mentioning that in the commit log.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>