Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp5935810rdb; Sun, 17 Sep 2023 20:46:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEOqB8m+HRtVb/35vt4DtQuoYskHfEs9gpHUnLwau1DK4oU3k4v3cPkn9kngH/mwFfLSTD6 X-Received: by 2002:a05:6a00:158b:b0:68f:f741:57a1 with SMTP id u11-20020a056a00158b00b0068ff74157a1mr11482574pfk.7.1695008775871; Sun, 17 Sep 2023 20:46:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695008775; cv=none; d=google.com; s=arc-20160816; b=YtF4zlsLDBCbQJbphQDL500c787Lcj3631DtyAcx3tzka8jfByO/+tp1PjPik4/gut m+tcqijqx+RQGhxG31vM3ik4zc2mRx3qNCPiTg0Yph5Pt8lZYCW5JX8PVgMCAbsajJrH qN74zPWN8XIs3AgdEyfxPotM0LwuGTlqjO5blog3eMYBKx28VTJBoPrbncJKDbTB4kNl mxiF7q0b5sljgQHmBSS+bGeHjoAU3l3SpRdwAJiQ+QbyESIlkK7UPQ9WJo6sEkIqKkmY fVGPCY4bP3VA7KU0J86+1cYaMz8foqhgHOSN9Oiwzsejazn5BBoesCq3QVUc11c9LrX2 fEMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:cc:to:from:mime-version:references :in-reply-to:message-id:date; bh=8fFat3B2yBbEPEvYuzXGmvwDn7tpp8LoaG5P8w+qkUk=; fh=okqyKAMnJqCBhDF0MfAL9zudqu7K5dnQ+gQFwCw4tj0=; b=BcMkeO6yW7Rjmdmq+Ek5NF6h77dzUgxeEaTLFQeXiQTVJDwxvqa1NKvitja9yy9C03 8NdfawoO3TaL0uMezeRpFrSjooEegMlQKHMxxWnI28X2UQJSmuNvl3WfIxRXDJqVtcax nwqSSV4Spx44DPGka1mV99Eo7O9Sh3yzWGkGihsmQ61tzFJyahG2ljNE98H9fsUMMCY8 s7oIStkU/guFsQhY8KSM7CHWDuR/hP41YRLOKYnInR6TPqxtjXrL3q1BxKHdo/HbvXpE Jc2uxPGh98Soo8MABQoOlg8GLzpD6wtOnyEWl5fyc2dcpyuDxgpZ+6/2GhK4z0W0OuG9 w3gw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zte.com.cn Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id cn15-20020a056a00340f00b0069015b1491bsi7366024pfb.120.2023.09.17.20.46.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Sep 2023 20:46:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=zte.com.cn Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 97D1E80F7295; Sun, 17 Sep 2023 20:46:13 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230360AbjIRDph (ORCPT + 99 others); Sun, 17 Sep 2023 23:45:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236717AbjIRDpG (ORCPT ); Sun, 17 Sep 2023 23:45:06 -0400 Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 388BE10A; Sun, 17 Sep 2023 20:44:59 -0700 (PDT) Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4RprK34GWKz8XrRF; Mon, 18 Sep 2023 11:44:55 +0800 (CST) Received: from szxlzmapp01.zte.com.cn ([10.5.231.85]) by mse-fl2.zte.com.cn with SMTP id 38I3iqSr028467; Mon, 18 Sep 2023 11:44:52 +0800 (+08) (envelope-from cheng.lin130@zte.com.cn) Received: from mapi (szxlzmapp06[null]) by mapi (Zmail) with MAPI id mid14; Mon, 18 Sep 2023 11:44:53 +0800 (CST) Date: Mon, 18 Sep 2023 11:44:53 +0800 (CST) X-Zmail-TransId: 2b086507c7b56cf-2fc22 X-Mailer: Zmail v1.0 Message-ID: <202309181144537682244@zte.com.cn> In-Reply-To: References: ZQJIyx419cw24ppF@dread.disaster.area,202309151750563356840@zte.com.cn,ZQeBY3kmww8qAjfP@dread.disaster.area Mime-Version: 1.0 From: To: Cc: , , , , , Subject: =?UTF-8?B?UmU6IFtQQVRDSCB2M10geGZzOiBpbnRyb2R1Y2UgcHJvdGVjdGlvbiBmb3IgZHJvcCBubGluaw==?= Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-fl2.zte.com.cn 38I3iqSr028467 X-Fangmail-Gw-Spam-Type: 0 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 6507C7B7.001/4RprK34GWKz8XrRF X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Sun, 17 Sep 2023 20:46:13 -0700 (PDT) > On Fri, Sep 15, 2023 at 05:50:56PM +0800, cheng.lin130@zte.com.cn wrote: > > > On Wed, Sep 13, 2023 at 05:44:45PM +0800, cheng.lin130@zte.com.cn wrote: > > > > From: Cheng Lin > > > > > > > > When abnormal drop_nlink are detected on the inode, > > > > shutdown filesystem, to avoid corruption propagation. > > > > > > > > Signed-off-by: Cheng Lin > > > > --- > > > > fs/xfs/xfs_inode.c | 9 +++++++++ > > > > 1 file changed, 9 insertions(+) > > > > > > > > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c > > > > index 9e62cc500..40cc106ae 100644 > > > > --- a/fs/xfs/xfs_inode.c > > > > +++ b/fs/xfs/xfs_inode.c > > > > @@ -919,6 +919,15 @@ xfs_droplink( > > > > xfs_trans_t *tp, > > > > xfs_inode_t *ip) > > > > { > > > > + > > > > + if (VFS_I(ip)->i_nlink == 0) { > > > > + xfs_alert(ip->i_mount, > > > > + "%s: Deleting inode %llu with no links.", > > > > + __func__, ip->i_ino); > > > > + tp->t_flags |= XFS_TRANS_DIRTY; > > > Marking the transaction dirty is not necessary. > > > Otherwise this seems fine. > > Another strategy: > > Set nlink to an invalid value(like XFS_NLINK_PINNED), and > > Complete this transaction before shutdown fs. To make sure > > nlink not be zero. If the nlink of a directory are zero, it may > > be cleaned up. > > Is that appropriate? > No, all I'm asking you to do is drop dirtying of the transaction > from this patch because it is a) unnecessary and b) a layering > violation. > It is unnecessary because the transaction will almost always be > dirty before we get to xfs_droplink(). In the cases where it isn't > dirty (e.g. xfs_remove() on a directory) we explicitly check that > nlink == 2 before proceeding to call xfs_droplink(). Hence we can't > actually get to xfs_droplink() with a clean transaction, and so If the corrupted inode is a parent directory, when remove its subdirectory, the parent's nlink will be decreased to 0. But the transaction of subdirectory removing is not dirty (There are not check about the parent directory). In this situation, the transaction will be failed and the filesystem will be alive. > marking it dirty here on underrun is unnecessary as returning an > error from xfs_droplink() will result in shutting down the > filesystem when the transaction is cancelled. > -Dave. > -- > Dave Chinner > david@fromorbit.com