lkml.org 
[lkml]   [2016]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 4.2.y-ckt 063/206] ext4: fix oops on corrupted filesystem
    Date
    4.2.8-ckt12 -stable review patch.  If anyone has any objections, please let me know.

    ---8<------------------------------------------------------------

    From: Jan Kara <jack@suse.cz>

    commit 74177f55b70e2f2be770dd28684dd6d17106a4ba upstream.

    When filesystem is corrupted in the right way, it can happen
    ext4_mark_iloc_dirty() in ext4_orphan_add() returns error and we
    subsequently remove inode from the in-memory orphan list. However this
    deletion is done with list_del(&EXT4_I(inode)->i_orphan) and thus we
    leave i_orphan list_head with a stale content. Later we can look at this
    content causing list corruption, oops, or other issues. The reported
    trace looked like:

    WARNING: CPU: 0 PID: 46 at lib/list_debug.c:53 __list_del_entry+0x6b/0x100()
    list_del corruption, 0000000061c1d6e0->next is LIST_POISON1
    0000000000100100)
    CPU: 0 PID: 46 Comm: ext4.exe Not tainted 4.1.0-rc4+ #250
    Stack:
    60462947 62219960 602ede24 62219960
    602ede24 603ca293 622198f0 602f02eb
    62219950 6002c12c 62219900 601b4d6b
    Call Trace:
    [<6005769c>] ? vprintk_emit+0x2dc/0x5c0
    [<602ede24>] ? printk+0x0/0x94
    [<600190bc>] show_stack+0xdc/0x1a0
    [<602ede24>] ? printk+0x0/0x94
    [<602ede24>] ? printk+0x0/0x94
    [<602f02eb>] dump_stack+0x2a/0x2c
    [<6002c12c>] warn_slowpath_common+0x9c/0xf0
    [<601b4d6b>] ? __list_del_entry+0x6b/0x100
    [<6002c254>] warn_slowpath_fmt+0x94/0xa0
    [<602f4d09>] ? __mutex_lock_slowpath+0x239/0x3a0
    [<6002c1c0>] ? warn_slowpath_fmt+0x0/0xa0
    [<60023ebf>] ? set_signals+0x3f/0x50
    [<600a205a>] ? kmem_cache_free+0x10a/0x180
    [<602f4e88>] ? mutex_lock+0x18/0x30
    [<601b4d6b>] __list_del_entry+0x6b/0x100
    [<601177ec>] ext4_orphan_del+0x22c/0x2f0
    [<6012f27c>] ? __ext4_journal_start_sb+0x2c/0xa0
    [<6010b973>] ? ext4_truncate+0x383/0x390
    [<6010bc8b>] ext4_write_begin+0x30b/0x4b0
    [<6001bb50>] ? copy_from_user+0x0/0xb0
    [<601aa840>] ? iov_iter_fault_in_readable+0xa0/0xc0
    [<60072c4f>] generic_perform_write+0xaf/0x1e0
    [<600c4166>] ? file_update_time+0x46/0x110
    [<60072f0f>] __generic_file_write_iter+0x18f/0x1b0
    [<6010030f>] ext4_file_write_iter+0x15f/0x470
    [<60094e10>] ? unlink_file_vma+0x0/0x70
    [<6009b180>] ? unlink_anon_vmas+0x0/0x260
    [<6008f169>] ? free_pgtables+0xb9/0x100
    [<600a6030>] __vfs_write+0xb0/0x130
    [<600a61d5>] vfs_write+0xa5/0x170
    [<600a63d6>] SyS_write+0x56/0xe0
    [<6029fcb0>] ? __libc_waitpid+0x0/0xa0
    [<6001b698>] handle_syscall+0x68/0x90
    [<6002633d>] userspace+0x4fd/0x600
    [<6002274f>] ? save_registers+0x1f/0x40
    [<60028bd7>] ? arch_prctl+0x177/0x1b0
    [<60017bd5>] fork_handler+0x85/0x90

    Fix the problem by using list_del_init() as we always should with
    i_orphan list.

    Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Kamal Mostafa <kamal@canonical.com>
    ---
    fs/ext4/namei.c | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
    index 011dcfb..81fc2c6 100644
    --- a/fs/ext4/namei.c
    +++ b/fs/ext4/namei.c
    @@ -2805,7 +2805,7 @@ int ext4_orphan_add(handle_t *handle, struct inode *inode)
    * list entries can cause panics at unmount time.
    */
    mutex_lock(&sbi->s_orphan_lock);
    - list_del(&EXT4_I(inode)->i_orphan);
    + list_del_init(&EXT4_I(inode)->i_orphan);
    mutex_unlock(&sbi->s_orphan_lock);
    }
    }
    --
    2.7.4
    \
     
     \ /
      Last update: 2016-06-10 00:41    [W:4.033 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site