On Wed, Feb 16, 2011 at 02:24:17PM -0700, dann frazier wrote: > On Wed, Feb 16, 2011 at 12:56:55PM -0800, Greg KH wrote: > > On Wed, Feb 16, 2011 at 12:56:22PM -0800, Greg KH wrote: > > > On Mon, Jan 10, 2011 at 01:10:16PM -0700, [email protected] wrote: > > > > From: Dave Chinner <[email protected]> > > > > > > > > Upstream commit: 4536f2ad8b330453d7ebec0746c4374eadd649b1 > > > > > > > > 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. > > > > > > > > Cc: <[email protected]> > > > > Signed-off-by: Dave Chinner <[email protected]> > > > > Reviewed-by: Christoph Hellwig <[email protected]> > > > > [dannf: Backported to 2.6.32.y] > > > > > > This still doesn't apply to the .32-longterm tree, care to try again? > > > patching file fs/xfs/xfs_ialloc.c > > > Hunk #1 FAILED at 1220. > > > Hunk #2 FAILED at 1236. > > > Hunk #3 FAILED at 1255. > > > 3 out of 3 hunks FAILED -- saving rejects to file > > > fs/xfs/xfs_ialloc.c.rej > > > > Oh wait, you want the first 5 patches applied first, doh, sorry for the > > noise, I'll work on that after lunch... > > > > Right - though, you might hold off until this is resolved: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/692848 > > Dave has been working with the user to help diagnose the problem; last > I saw he was waiting for some feedback from the user to rule out a > pre-existing fs corruption issue. I just noticed that the user > provided that info a few days ago, which I believe tells us that there > is likely an alignment issue with the backport.
Hold on, I'm confused. How did ubuntu get these patches into their kernel if none of them have been applied to the 2.6.32.y stable tree yet? As it is, I think the ubuntu problem has been diagnosed down to the fact their kernel doesn't have the first patch in this series in their kernel. See: http://oss.sgi.com/archives/xfs/2011-02/msg00085.html So fixing this patch series to compile on the 2.6.32.y tree is all that needs to be done here, right? Cheers, Dave. -- Dave Chinner [email protected] _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
