From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:60527 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751053AbcFDRGw (ORCPT ); Sat, 4 Jun 2016 13:06:52 -0400 Subject: Patch "f2fs: fix deadlock when flush inline data" has been added to the 4.6-stable tree To: yuchao0@huawei.com, gregkh@linuxfoundation.org, heyunlei@huawei.com, jaegeuk@kernel.org Cc: , From: Date: Sat, 04 Jun 2016 10:06:51 -0700 Message-ID: <1465060011198199@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled f2fs: fix deadlock when flush inline data to the 4.6-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: f2fs-fix-deadlock-when-flush-inline-data.patch and it can be found in the queue-4.6 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From ab47036d8f7227361cad7894adee8e66ab6f95b2 Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Wed, 11 May 2016 19:48:44 +0800 Subject: f2fs: fix deadlock when flush inline data From: Chao Yu commit ab47036d8f7227361cad7894adee8e66ab6f95b2 upstream. Below backtrace info was reported by Yunlei He: Call Trace: [] schedule+0x35/0x80 [] rwsem_down_read_failed+0xed/0x130 [] call_rwsem_down_read_failed+0x18/0x [] down_read+0x20/0x30 [] f2fs_evict_inode+0x242/0x3a0 [f2fs] [] evict+0xc7/0x1a0 [] iput+0x196/0x200 [] __dentry_kill+0x179/0x1e0 [] dput+0x199/0x1f0 [] __fput+0x18b/0x220 [] ____fput+0xe/0x10 [] task_work_run+0x77/0x90 [] exit_to_usermode_loop+0x73/0xa2 [] do_syscall_64+0xfa/0x110 [] entry_SYSCALL64_slow_path+0x25/0x25 Call Trace: [] schedule+0x35/0x80 [] __wait_on_freeing_inode+0xa3/0xd0 [] ? autoremove_wake_function+0x40/0x4 [] find_inode_fast+0x7d/0xb0 [] ilookup+0x6a/0xd0 [] sync_node_pages+0x210/0x650 [f2fs] [] ? do_fsync+0x70/0x70 [] block_operations+0x9e/0xf0 [f2fs] [] ? bio_endio+0x55/0x60 [] write_checkpoint+0x92/0xba0 [f2fs] [] ? mempool_free_slab+0x17/0x20 [] ? mempool_free+0x2b/0x80 [] ? do_fsync+0x70/0x70 [] f2fs_sync_fs+0x63/0xd0 [f2fs] [] ? ext4_sync_fs+0xbf/0x190 [] sync_fs_one_sb+0x20/0x30 [] iterate_supers+0xb9/0x110 [] sys_sync+0x55/0x90 [] do_syscall_64+0x69/0x110 [] entry_SYSCALL64_slow_path+0x25/0x25 With following excuting serials, we will set inline_node in inode page after inode was unlinked, result in a deadloop described as below: 1. open file 2. write file 3. unlink file 4. write file 5. close file Thread A Thread B - dput - iput_final - inode->i_state |= I_FREEING - evict - f2fs_evict_inode - f2fs_sync_fs - write_checkpoint - block_operations - f2fs_lock_all (down_write(cp_rwsem)) - f2fs_lock_op (down_read(cp_rwsem)) - sync_node_pages - ilookup - find_inode_fast - __wait_on_freeing_inode (wait on I_FREEING clear) Here, we change to set inline_node flag only for linked inode for fixing. Reported-by: Yunlei He Signed-off-by: Chao Yu Tested-by: Jaegeuk Kim Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman --- fs/f2fs/data.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -1480,7 +1480,8 @@ restart: if (pos + len <= MAX_INLINE_DATA) { read_inline_data(page, ipage); set_inode_flag(F2FS_I(inode), FI_DATA_EXIST); - set_inline_node(ipage); + if (inode->i_nlink) + set_inline_node(ipage); } else { err = f2fs_convert_inline_page(&dn, page); if (err) Patches currently in stable-queue which might be from yuchao0@huawei.com are queue-4.6/f2fs-fix-deadlock-when-flush-inline-data.patch