From patchwork Wed May 13 17:46:04 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jaegeuk Kim X-Patchwork-Id: 6399301 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 346E99F32E for ; Wed, 13 May 2015 17:46:26 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5DB8D20411 for ; Wed, 13 May 2015 17:46:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8B0C620439 for ; Wed, 13 May 2015 17:46:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753531AbbEMRqS (ORCPT ); Wed, 13 May 2015 13:46:18 -0400 Received: from mail.kernel.org ([198.145.29.136]:56062 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751921AbbEMRqS (ORCPT ); Wed, 13 May 2015 13:46:18 -0400 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0263320430; Wed, 13 May 2015 17:46:17 +0000 (UTC) Received: from localhost (unknown [166.170.43.41]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3101220411; Wed, 13 May 2015 17:46:14 +0000 (UTC) Date: Wed, 13 May 2015 10:46:04 -0700 From: Jaegeuk Kim To: hujianyang Cc: "linux-fsdevel@vger.kernel.org" , linux-f2fs-devel@lists.sourceforge.net Subject: Re: [f2fs-dev] Space leak in f2fs Message-ID: <20150513174417.GA56247@jaegeuk-mac02.mot.com> References: <5552FA7D.7000704@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5552FA7D.7000704@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Hu, Thank you for the report. When I tried to reproduce this, it seems that this can occur under somewhat stressful condition. I could't reach out to this problem. Nevertheless, I think this is a possible scenario, so I wrote a patch for this. Could you test this patch? Thanks, --- fs/f2fs/super.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index 19438f2..4593cd1 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -431,8 +431,26 @@ static int f2fs_drop_inode(struct inode *inode) * - f2fs_gc -> iput -> evict * - inode_wait_for_writeback(inode) */ - if (!inode_unhashed(inode) && inode->i_state & I_SYNC) + if (!inode_unhashed(inode) && inode->i_state & I_SYNC) { + if (!inode->i_nlink && !is_bad_inode(inode)) { + spin_unlock(&inode->i_lock); + + i_size_write(inode, 0); + + if (F2FS_HAS_BLOCKS(inode)) + f2fs_truncate(inode); + + f2fs_lock_op(F2FS_I_SB(inode)); + remove_inode_page(inode); + f2fs_unlock_op(F2FS_I_SB(inode)); + + /* avoid any write_inode call */ + clear_inode_flag(F2FS_I(inode), FI_DIRTY_INODE); + + spin_lock(&inode->i_lock); + } return 0; + } return generic_drop_inode(inode); }