While beating on ecryptfs with fsfuzzer (which I've set up to overlay ecryptfs atop ext3), I hit the following panic, which appears to be in the ext3 code: crash> bt PID: 9184 TASK: ffff810020b11820 CPU: 1 COMMAND: "fstest" #0 [ffff81002008f9d0] crash_kexec at ffffffff800aaaa2 #1 [ffff81002008fa90] __die at ffffffff800650af #2 [ffff81002008fad0] die at ffffffff8006b7d1 #3 [ffff81002008fb00] do_invalid_op at ffffffff8006bd91 #4 [ffff81002008fbc0] error_exit at ffffffff8005dde9 [exception RIP: dx_probe+331] RIP: ffffffff880531d9 RSP: ffff81002008fc78 RFLAGS: 00010282 RAX: 0000000000000081 RBX: ffff8100219b0418 RCX: ffffffff80450560 RDX: 00000000ffffffff RSI: 0000000000000000 RDI: ffffffff802ed9dc RBP: 0000000000000000 R8: 00000000000000a0 R9: 0000000000000020 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000000000 R13: ffff81001f9deb50 R14: ffff810020610110 R15: ffff81002008fd24 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffff81002008fc70] dx_probe at ffffffff880531d9 #6 [ffff81002008fcc0] ext3_htree_fill_tree at ffffffff880545da #7 [ffff81002008fd60] ext3_readdir at ffffffff8804ce35 #8 [ffff81002008fe40] vfs_readdir at ffffffff80034df6 #9 [ffff81002008fe80] ecryptfs_readdir at ffffffff8855e3fb #10 [ffff81002008fef0] vfs_readdir at ffffffff80034df6 #11 [ffff81002008ff30] sys_getdents at ffffffff8003869f #12 [ffff81002008ff80] tracesys at ffffffff8005d28d (via system_call) RIP: 000000354e49499b RSP: 00007fffd0f6d5e0 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: ffffffff8005d28d RCX: ffffffffffffffff RDX: 0000000000001000 RSI: 0000000012653f38 RDI: 0000000000000005 RBP: 0000000000000000 R8: 0000000012653f38 R9: 0000000000000004 R10: 0000000000000003 R11: 0000000000000202 R12: 0000000000000005 R13: ffffffffffffffb0 R14: 0000000012653f00 R15: 00007fffd0f6e6b0 ORIG_RAX: 000000000000004e CS: 0033 SS: 002b vmcore available upon request, attaching the image file that produced the panic when fsfuzzer's fstest was examining it.
Created attachment 311520 [details] 4M ext3 fs image that triggered panic
Oops, that wasn't supposed to be private...
And neither was the dependency. Ugh. That's what I get for being lazy and cloning instead of just starting a new bug...
Josef, any desire to look into this one to put another notch in your fsfuzzer belt? ;)
can I get the core, my box isn't cooperating with me.
Created attachment 313698 [details] patch to fix the problem. Here's a patch thats fixes the assert that happens due to the corrupt dirents. Tested and verified the problem is fixed.
Updating PM score.
posted 4/20.
in kernel-2.6.18-141.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5 Please do NOT transition this bugzilla state to VERIFIED until our QE team has sent specific instructions indicating when to do so. However feel free to provide a comment indicating that this fix has been verified.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1243.html