fix-oops-on-corrupted-filesystem

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