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.
Ok, how about I just drop this whole series from my "to-apply" stable queue and you resend what is needed, when it is tested. This way I will not forget why it's in my queue but not applied. thansk, greg k-h _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
