From patchwork Thu Jan 5 07:24:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhang Yi X-Patchwork-Id: 9498533 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id ED8F5606B5 for ; Thu, 5 Jan 2017 07:29:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DCCE128112 for ; Thu, 5 Jan 2017 07:29:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D16362815E; Thu, 5 Jan 2017 07:29:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 86A8528112 for ; Thu, 5 Jan 2017 07:29:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967975AbdAEH2u (ORCPT ); Thu, 5 Jan 2017 02:28:50 -0500 Received: from szxga01-in.huawei.com ([58.251.152.64]:40122 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966976AbdAEH1t (ORCPT ); Thu, 5 Jan 2017 02:27:49 -0500 Received: from 172.24.1.47 (EHLO SZXEML424-HUB.china.huawei.com) ([172.24.1.47]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DXM08081; Thu, 05 Jan 2017 15:24:16 +0800 (CST) Received: from [127.0.0.1] (10.177.244.145) by SZXEML424-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP Server id 14.3.235.1; Thu, 5 Jan 2017 15:24:15 +0800 Subject: Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy To: "Theodore Ts'o" , "Darrick J. Wong" , , , , , References: <1482755657-28791-1-git-send-email-yi.zhang@huawei.com> <141922.1483225153@turing-police.cc.vt.edu> <10c6fa5d-a7bb-a87c-11ad-8d30230a6075@huawei.com> <20170104215424.GB14021@birch.djwong.org> <20170104233550.oy7nzc3rxppmejbk@thunk.org> From: "zhangyi (F)" Message-ID: <5505c121-8038-1b72-423a-42f36257e959@huawei.com> Date: Thu, 5 Jan 2017 15:24:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170104233550.oy7nzc3rxppmejbk@thunk.org> X-Originating-IP: [10.177.244.145] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.586DF4A2.0393, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a7049b29909c18362f0ee5c22844f0b9 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 On 2017/1/5 7:35, Theodore Ts'o wrote: > > So how exactly how did we get into this state? When we read the inode > into memory, if i_nlink is zero, we declare the file system as > corrupted immediately. > > So I assume this is happening the on-disk i_links_count (which is read > into inode->i_nlink) was too low. So I think the way we should be > handling this is in unlink and rename, before we let i_nlink drop to > zero, we need to check to see if there are other dcache entries > pointing at the inode. If so, we need to call ext4_error(), and in > the errors=continue case, return EFSCORRUPTED (aka EUCLEAN). > Because the filesystem have many errors, and the reason of i_nlink becomes zero is unknown, the on-disk i_links_count was too low may be one reason. I think we can add i_nlink check in ext4_rename just like ext4_unlink did, it can avoid inversion under any case. --- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -3662,6 +3662,11 @@ static int ext4_rename(struct inode *old_dir, struct dentry *old_dentry, } if (new.inode) { + if (new.inode->i_nlink == 0) { + ext4_warning_inode(new.inode, "Removing file '%.*s' with no links", + new.dentry->d_name.len, new.dentry->d_name.name); + set_nlink(new.inode, 1); + } ext4_dec_count(handle, new.inode); new.inode->i_ctime = ext4_current_time(new.inode); }