Bug 32082

Summary: ext4: oops when mounting intentionally corrupted filesystem
Product: File System Reporter: Sami Liedes (sami.liedes)
Component: ext4Assignee: fs_ext4 (fs_ext4)
Status: CLOSED CODE_FIX    
Severity: normal CC: florian, tm
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.38.2 Subsystem:
Regression: No Bisected commit-id:
Attachments: Test ext4 file system (intentionally corrupted)

Description Sami Liedes 2011-03-28 23:11:58 UTC
Created attachment 52392 [details]
Test ext4 file system (intentionally corrupted)

Mounting the attached (intentionally corrupted) ext4 filesystem image causes a kernel OOPS (under KVM, vanilla 2.6.38.2, x86-64)

Steps to reproduce:

1. bunzip2 hdb.41.bz2
2. mount hdb.41 /mnt -t ext4 -o errors=continue
[oops]

Here's the dmesg output after issuing the mount command:

------------------------------------------------------------
------------[ cut here ]------------
kernel BUG at kernel/timer.c:659!
invalid opcode: 0000 [#1] 
last sysfs file: 
CPU 0 
Pid: 2639, comm: mount Not tainted 2.6.38.2 #3 Bochs Bochs
RIP: 0010:[<ffffffff81054983>]  [<ffffffff81054983>] mod_timer+0x1d3/0x250
RSP: 0000:ffff880003757ac8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880003d83500 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000000010148cdae RDI: ffff880003d83500
RBP: ffff880003757b08 R08: 0000000000000000 R09: 0000000004000000
R10: 0000000000000000 R11: 0000000000000000 R12: 000000010148cdae
R13: 000000010148cdae R14: ffffffff81c23b05 R15: ffffffff81efa148
FS:  0000000000000000(0000) GS:ffffffff8221e000(0063) knlGS:00000000f7587960
CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 000000000856d000 CR3: 000000000376e000 CR4: 00000000000006b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mount (pid: 2639, threadinfo ffff880003756000, task ffff88000556ef90)
Stack:
 0000000000000002 0000000000000002 ffff880004490208 0000000000000000
 ffff8800076e7400 ffff880003d81000 0000000000001385 ffffffff81c23b05
 ffff880003757b38 ffffffff811e9b5a ffff880003d81000 0000000000000000
Call Trace:
 [<ffffffff811e9b5a>] __save_error_info+0x9a/0x110
 [<ffffffff811ee7f1>] save_error_info+0x11/0x30
 [<ffffffff811efc31>] ext4_error_inode+0x61/0x110
 [<ffffffff8111d5b6>] ? __wait_on_buffer+0x26/0x30
 [<ffffffff811d4710>] ? __ext4_get_inode_loc+0x1e0/0x400
 [<ffffffff811d69f4>] ext4_iget+0x714/0x830
 [<ffffffff81074188>] ? debug_mutex_init+0x38/0x50
 [<ffffffff811f28d4>] ext4_fill_super+0x1664/0x2890
 [<ffffffff81078d0d>] ? trace_hardirqs_on_caller+0x13d/0x180
 [<ffffffff810f4f37>] mount_bdev+0x1a7/0x1f0
 [<ffffffff811f1270>] ? ext4_fill_super+0x0/0x2890
 [<ffffffff811e82f0>] ext4_mount+0x10/0x20
 [<ffffffff810f52d8>] vfs_kern_mount+0x88/0x280
 [<ffffffff810f56df>] do_kern_mount+0x4f/0x100
 [<ffffffff811102fb>] do_mount+0x3db/0x810
 [<ffffffff8110fe40>] ? copy_mount_options+0xf0/0x190
 [<ffffffff8113729f>] compat_sys_mount+0x12f/0x280
 [<ffffffff81033642>] ia32_sysret+0x0/0x5
Code: 50 48 e9 04 ff ff ff 90 4d 89 e5 49 29 c5 49 c1 ed 08 4d 01 e5 e9 80 fe ff ff 66 0f 1f 44 00 00 41 bd 01 00 00 00 e9 48 ff ff ff <0f> 0b 49 89 c6 e9 1d ff ff ff 4c 8b 35 0c 8e 2c 01 4d 85 f6 0f 
RIP  [<ffffffff81054983>] mod_timer+0x1d3/0x250
 RSP <ffff880003757ac8>
---[ end trace 1b18f0361c17f387 ]---
./runtest: line 35:  2639 Segmentation fault      mount $HDB /mnt -t ext4 -o errors=continue
------------------------------------------------------------
Comment 1 Tao Ma 2011-03-29 04:15:40 UTC
Hi Sami, please check this patch. It should resolve your problem. It works here now.
http://marc.info/?l=linux-ext4&m=130137187707414&w=2
Comment 2 Sami Liedes 2011-03-29 09:05:17 UTC
Yes, seems to fix the panic. Thank you.
Comment 3 Florian Mickler 2011-04-12 09:19:42 UTC
A patch referencing this bug report has been merged in v2.6.39-rc3:

commit 0449641130f5652b344ef6fa39fa019d7e94660a
Author: Tao Ma <boyu.mt@taobao.com>
Date:   Tue Apr 5 19:55:28 2011 -0400

    ext4: init timer earlier to avoid a kernel panic in __save_error_info