xfs
[Top] [All Lists]

Re: [PATCH] Re: xfsdump-3.0.4 problems

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] Re: xfsdump-3.0.4 problems
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed, 18 Aug 2010 06:10:36 -0400
Cc: Mario Bachmann <mbachman@xxxxxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20100817114550.GQ10429@dastard>
References: <20100816182236.249a2a0f@xxxxxxxxxxx> <20100816223021.GL10429@dastard> <20100817083227.06e23889@xxxxxxxxxxx> <20100817071337.GN10429@dastard> <20100817095340.6b9ab8e2@xxxxxxxxxxx> <20100817090534.GP10429@dastard> <20100817114550.GQ10429@dastard>
User-agent: Mutt/1.5.20 (2009-08-17)
> xfs: fix untrusted inode number lookup
> 
> From: Dave Chinner <dchinner@xxxxxxxxxx>
> 
> Commit 7124fe0a5b619d65b739477b3b55a20bf805b06d ("xfs: validate untrusted 
> inode
> numbers during lookup") changes the inode lookup code to do btree lookups for
> untrusted inode numbers. This change made an invalid assumption about the
> alignment of inodes and hence incorrectly calculated the first inode in the
> cluster. As a result, some inode numbers were being incorrectly considered
> invalid when they were actually valid.
> 
> The issue was not picked up by the xfstests suite because it always runs fsr
> and dump (the two utilities that utilise the bulkstat interface) on cache hot
> inodes and hence the lookup code in the cold cache path was not sufficiently
> exercised to uncover this intermittent problem.
> 
> Fix the issue by relaxing the btree lookup criteria and then checking if the
> record returned contains the inode number we are lookup for. If it we get an
> incorrect record, then the inode number is invalid.

Looks good and fixes the dump issues I've seen in xfstests.


Reviewed-by: Christoph Hellwig <hch@xxxxxx>

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