On Thu, Feb 17, 2011 at 11:48:19AM +1100, Dave Chinner wrote: > 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?
Looks like I'm confused. I thought they had pulled my proposed backport in, but obviously they didn't since they are missing that first patch. > 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, if you are > So fixing this patch series to compile on the 2.6.32.y tree is all > that needs to be done here, right? Sure and, afaict, it still does. Anyhow, if you're fine with it, I certainly am too. Greg: do you need me to resubmit? _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
