]>
Commit | Line | Data |
---|---|---|
adb53c40 GKH |
1 | From 74177f55b70e2f2be770dd28684dd6d17106a4ba Mon Sep 17 00:00:00 2001 |
2 | From: Jan Kara <jack@suse.cz> | |
3 | Date: Thu, 5 May 2016 11:10:15 -0400 | |
4 | Subject: ext4: fix oops on corrupted filesystem | |
5 | ||
6 | From: Jan Kara <jack@suse.cz> | |
7 | ||
8 | commit 74177f55b70e2f2be770dd28684dd6d17106a4ba upstream. | |
9 | ||
10 | When filesystem is corrupted in the right way, it can happen | |
11 | ext4_mark_iloc_dirty() in ext4_orphan_add() returns error and we | |
12 | subsequently remove inode from the in-memory orphan list. However this | |
13 | deletion is done with list_del(&EXT4_I(inode)->i_orphan) and thus we | |
14 | leave i_orphan list_head with a stale content. Later we can look at this | |
15 | content causing list corruption, oops, or other issues. The reported | |
16 | trace looked like: | |
17 | ||
18 | WARNING: CPU: 0 PID: 46 at lib/list_debug.c:53 __list_del_entry+0x6b/0x100() | |
19 | list_del corruption, 0000000061c1d6e0->next is LIST_POISON1 | |
20 | 0000000000100100) | |
21 | CPU: 0 PID: 46 Comm: ext4.exe Not tainted 4.1.0-rc4+ #250 | |
22 | Stack: | |
23 | 60462947 62219960 602ede24 62219960 | |
24 | 602ede24 603ca293 622198f0 602f02eb | |
25 | 62219950 6002c12c 62219900 601b4d6b | |
26 | Call Trace: | |
27 | [<6005769c>] ? vprintk_emit+0x2dc/0x5c0 | |
28 | [<602ede24>] ? printk+0x0/0x94 | |
29 | [<600190bc>] show_stack+0xdc/0x1a0 | |
30 | [<602ede24>] ? printk+0x0/0x94 | |
31 | [<602ede24>] ? printk+0x0/0x94 | |
32 | [<602f02eb>] dump_stack+0x2a/0x2c | |
33 | [<6002c12c>] warn_slowpath_common+0x9c/0xf0 | |
34 | [<601b4d6b>] ? __list_del_entry+0x6b/0x100 | |
35 | [<6002c254>] warn_slowpath_fmt+0x94/0xa0 | |
36 | [<602f4d09>] ? __mutex_lock_slowpath+0x239/0x3a0 | |
37 | [<6002c1c0>] ? warn_slowpath_fmt+0x0/0xa0 | |
38 | [<60023ebf>] ? set_signals+0x3f/0x50 | |
39 | [<600a205a>] ? kmem_cache_free+0x10a/0x180 | |
40 | [<602f4e88>] ? mutex_lock+0x18/0x30 | |
41 | [<601b4d6b>] __list_del_entry+0x6b/0x100 | |
42 | [<601177ec>] ext4_orphan_del+0x22c/0x2f0 | |
43 | [<6012f27c>] ? __ext4_journal_start_sb+0x2c/0xa0 | |
44 | [<6010b973>] ? ext4_truncate+0x383/0x390 | |
45 | [<6010bc8b>] ext4_write_begin+0x30b/0x4b0 | |
46 | [<6001bb50>] ? copy_from_user+0x0/0xb0 | |
47 | [<601aa840>] ? iov_iter_fault_in_readable+0xa0/0xc0 | |
48 | [<60072c4f>] generic_perform_write+0xaf/0x1e0 | |
49 | [<600c4166>] ? file_update_time+0x46/0x110 | |
50 | [<60072f0f>] __generic_file_write_iter+0x18f/0x1b0 | |
51 | [<6010030f>] ext4_file_write_iter+0x15f/0x470 | |
52 | [<60094e10>] ? unlink_file_vma+0x0/0x70 | |
53 | [<6009b180>] ? unlink_anon_vmas+0x0/0x260 | |
54 | [<6008f169>] ? free_pgtables+0xb9/0x100 | |
55 | [<600a6030>] __vfs_write+0xb0/0x130 | |
56 | [<600a61d5>] vfs_write+0xa5/0x170 | |
57 | [<600a63d6>] SyS_write+0x56/0xe0 | |
58 | [<6029fcb0>] ? __libc_waitpid+0x0/0xa0 | |
59 | [<6001b698>] handle_syscall+0x68/0x90 | |
60 | [<6002633d>] userspace+0x4fd/0x600 | |
61 | [<6002274f>] ? save_registers+0x1f/0x40 | |
62 | [<60028bd7>] ? arch_prctl+0x177/0x1b0 | |
63 | [<60017bd5>] fork_handler+0x85/0x90 | |
64 | ||
65 | Fix the problem by using list_del_init() as we always should with | |
66 | i_orphan list. | |
67 | ||
68 | Reported-by: Vegard Nossum <vegard.nossum@oracle.com> | |
69 | Signed-off-by: Jan Kara <jack@suse.cz> | |
70 | Signed-off-by: Theodore Ts'o <tytso@mit.edu> | |
71 | Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
72 | ||
73 | --- | |
74 | fs/ext4/namei.c | 2 +- | |
75 | 1 file changed, 1 insertion(+), 1 deletion(-) | |
76 | ||
77 | --- a/fs/ext4/namei.c | |
78 | +++ b/fs/ext4/namei.c | |
79 | @@ -2809,7 +2809,7 @@ int ext4_orphan_add(handle_t *handle, st | |
80 | * list entries can cause panics at unmount time. | |
81 | */ | |
82 | mutex_lock(&sbi->s_orphan_lock); | |
83 | - list_del(&EXT4_I(inode)->i_orphan); | |
84 | + list_del_init(&EXT4_I(inode)->i_orphan); | |
85 | mutex_unlock(&sbi->s_orphan_lock); | |
86 | } | |
87 | } |