From fcc5c22218a18509a7412bf074fc9a7a5d874a8a Mon Sep 17 00:00:00 2001 From: Wu Fengguang Date: Mon, 11 Jul 2011 23:08:50 -0700 Subject: writeback: don't busy retry writeback on new/freeing inodes Fix a system hang bug introduced by commit b7a2441f9966 ("writeback: remove writeback_control.more_io") and e8dfc3058 ("writeback: elevate queue_io() into wb_writeback()") easily reproducible with high memory pressure and lots of file creation/deletions, for example, a kernel build in limited memory. It hangs when some inode is in the I_NEW, I_FREEING or I_WILL_FREE state, the flusher will get stuck busy retrying that inode, never releasing wb->list_lock. The lock in turn blocks all kinds of other tasks when they are trying to grab it. As put by Jan, it's a safe change regarding data integrity. I_FREEING or I_WILL_FREE inodes are written back by iput_final() and it is reclaim code that is responsible for eventually removing them. So writeback code can safely ignore them. I_NEW inodes should move out of this state when they are fully set up and in the writeback round following that, we will consider them for writeback. So the change makes sense. CC: Jan Kara Reported-by: Hugh Dickins Tested-by: Hugh Dickins Signed-off-by: Wu Fengguang --- fs/fs-writeback.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'fs/fs-writeback.c') diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 50445cf0b83a..6d49439ca31d 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -593,7 +593,7 @@ static long writeback_sb_inodes(struct super_block *sb, spin_lock(&inode->i_lock); if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) { spin_unlock(&inode->i_lock); - requeue_io(inode, wb); + redirty_tail(inode, wb); continue; } __iget(inode); -- cgit v1.2.2