|
Bug #337246
http://launchpad.net/bugs/337246 "kernel bug corrupts filesystem on heavy parallel I/O" Upstream has received a patch that fixes this issue via http://bugzilla.kernel.org/show_bug.cgi?id=12821 I've confirmed it applies cleanly to Jaunty. Please cherry-pick commit 395a87bfefbc400011417e9eaae33169f9f036c0 Author: Eric Sandeen <[hidden email]> Date: Tue Mar 10 18:18:47 2009 -0400 ext4: fix header check in ext4_ext_search_right() for deep extent trees. The ext4_ext_search_right() function is confusing; it uses a "depth" variable which is 0 at the root and maximum at the leaves, but the on-disk metadata uses a "depth" (actually eh_depth) which is opposite: maximum at the root, and 0 at the leaves. The ext4_ext_check_header() function is given a depth and checks the header agaisnt that depth; it expects the on-disk semantics, but we are giving it the opposite in the while loop in this function. We should be giving it the on-disk notion of "depth" which we can get from (p_depth - depth) - and if you look, the last (more commonly hit) call to ext4_ext_check_header() does just this. Sending in the wrong depth results in (incorrect) messages about corruption: EXT4-fs error (device sdb1): ext4_ext_search_right: bad header in inode #2621457: unexpected eh_depth - magic f30a, entries 340, max 340(0), depth 1(2) http://bugzilla.kernel.org/show_bug.cgi?id=12821 Reported-by: David Dindorp <[hidden email]> Signed-off-by: Eric Sandeen <[hidden email]> Signed-off-by: "Theodore Ts'o" <[hidden email]> -- kernel-team mailing list [hidden email] https://lists.ubuntu.com/mailman/listinfo/kernel-team |
|
TJ wrote:
> Bug #337246 > http://launchpad.net/bugs/337246 > "kernel bug corrupts filesystem on heavy parallel I/O" > > Upstream has received a patch that fixes this issue via > > http://bugzilla.kernel.org/show_bug.cgi?id=12821 > > I've confirmed it applies cleanly to Jaunty. > > Please cherry-pick commit 395a87bfefbc400011417e9eaae33169f9f036c0 > > Author: Eric Sandeen <[hidden email]> > Date: Tue Mar 10 18:18:47 2009 -0400 > > ext4: fix header check in ext4_ext_search_right() for deep extent trees. > > The ext4_ext_search_right() function is confusing; it uses a > "depth" variable which is 0 at the root and maximum at the leaves, > but the on-disk metadata uses a "depth" (actually eh_depth) which > is opposite: maximum at the root, and 0 at the leaves. > > The ext4_ext_check_header() function is given a depth and checks > the header agaisnt that depth; it expects the on-disk semantics, > but we are giving it the opposite in the while loop in this > function. We should be giving it the on-disk notion of "depth" > which we can get from (p_depth - depth) - and if you look, the last > (more commonly hit) call to ext4_ext_check_header() does just this. > > Sending in the wrong depth results in (incorrect) messages > about corruption: > > EXT4-fs error (device sdb1): ext4_ext_search_right: bad header > in inode #2621457: unexpected eh_depth - magic f30a, entries 340, > max 340(0), depth 1(2) > > http://bugzilla.kernel.org/show_bug.cgi?id=12821 > > Reported-by: David Dindorp <[hidden email]> > Signed-off-by: Eric Sandeen <[hidden email]> > Signed-off-by: "Theodore Ts'o" <[hidden email]> > > > Applied https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/346194/comments/2 On a side note, clean cherry-picks from Linus' tree don't need to be marked as '(drop after 2.6.28)'. rtg -- Tim Gardner [hidden email] -- kernel-team mailing list [hidden email] https://lists.ubuntu.com/mailman/listinfo/kernel-team |
| Powered by Nabble | Edit this page |
