lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu,  5 Mar 2009 22:11:43 -0800 (PST)
From:	bugme-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 12821] filesystem corrupts on heavy I/O

http://bugzilla.kernel.org/show_bug.cgi?id=12821





------- Comment #8 from sandeen@...hat.com  2009-03-05 22:11 -------
Created an attachment (id=20443)
 --> (http://bugzilla.kernel.org/attachment.cgi?id=20443&action=view)
potential fix

I have not yet tested this patch, but it may fix your problem.

you can wait 'til I've had a chance to test it, or give it a go; if I'm wrong,
the worst you should get is more corrupt header messages and EIO errors.  :)

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 expects the on-disk semantics, but we are
feeding it the opposite in the while loop in this function.  We should be
feeding it the on-disk notion of "depth" which we can get with (p_depth -
depth) - and if you look, the last (more commonly hit) call to
ext4_ext_check_header() does just this.

For a depth 4 tree (p_depth 3) (which would be an incredible amount of extents,
so perhaps not your problem, but perhaps....), then, you'd have:

"depth" in function  eh_depth                      p_depth - depth
0                    3                             3
1                    2                             2
2                    1 <---- I think you are here  1
3                    0                             0

Your error messages:
[1099257.456522] 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)

indicate that it was asked to check that the header was depth (2) but it
actually found depth 1 in the disk metadata.

I've not yet crafted a test to hit this codepath at all, so have not tested
this yet, but by inspection I *think* it is correct.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ