Received: by 2002:a05:7412:1703:b0:e2:908c:2ebd with SMTP id dm3csp864518rdb; Fri, 25 Aug 2023 03:41:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGpU4uEzqH3G136m0549A+vwaQeDOlYgFSNPxgA4u/Wqe4PfhLCa1hscbqb9tzn/GmNYAhb X-Received: by 2002:aa7:c508:0:b0:523:1004:1c9a with SMTP id o8-20020aa7c508000000b0052310041c9amr11945700edq.35.1692960071113; Fri, 25 Aug 2023 03:41:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1692960071; cv=none; d=google.com; s=arc-20160816; b=QU6YjXHWOmGv6yvVmDCpyE+m52GcdpsRvCto1bCZigV85KWH0p/4+0MGCW7rsTXXLu aQlIHO8IR7akhvPNiW7VJwOO25J+AU8jkzMIclueD5bSQTAwqOQeiDyxGuIp/f+lQpgb 6r5Fm1SXqey3CBg8gg0PR1SouFkj8RLOQN3zl+WnBEmY50/FtJqK20uRJiSWtyKcS8G4 /QQ0r3JqAWqSpvKtw+yLGKm+yx5K+hFsTb5JI/2l0/ABXJhtd2X9IzBMvTjxhzwmceox Mix3rJLCBnNfYRcdHhzrD5Pq5h0xAiDEO3uXAJoTtVPKxOsL2uQqOjIzl0oPhym5avyo vfSQ== 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=L/XktxmoZ9KjTn58kunW8j6M7rGhlPO31p/N54IrNKQ=; fh=85T0G3+ngVLH/+iXVuwcU00ovCSYsB8f6EurC8socOY=; b=Do3LtZ/G/6GAFF7sCWdeKWFsK5HIDc2RI6UG54Cr/ErK+w8MlqPxChx0SrRx+qtS7y T3oGVoyU5FvTKLnLblhuKONwLH1W020l+8bulE9QKvrBjDB4YVunBjwl4pBgSp5SWXGZ e5u35KlJvk+m37rK+ZvMXfFRGq+6o1lHsJ/i87N9FP66vmrDwI5wr6OwDBqoCakacBO8 h4lMy0W2eoYEkTfj1cAQ/9rUOW+4B3GyTSkk18eByqDMGHKka+e4+g1UNJ5TrzkK40bd qCJOFbWdv15UVn9aoC9yImAppdtorx3DJp9TITuwv5aJpEPx4VtG+vQwH3sMe9aTEHvS C+sA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t22-20020a05640203d600b0052594fef88asi960429edw.619.2023.08.25.03.40.43; Fri, 25 Aug 2023 03:41:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230062AbjHYIdC (ORCPT + 99 others); Fri, 25 Aug 2023 04:33:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241520AbjHYIcw (ORCPT ); Fri, 25 Aug 2023 04:32:52 -0400 Received: from mxct.zte.com.cn (mxct.zte.com.cn [58.251.27.85]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60A9C19AC; Fri, 25 Aug 2023 01:32:48 -0700 (PDT) Received: from mxde.zte.com.cn (unknown [10.35.20.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4RXCrB1xYPz5Sg6; Fri, 25 Aug 2023 16:32:42 +0800 (CST) Received: from mxhk.zte.com.cn (unknown [192.168.250.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mxde.zte.com.cn (FangMail) with ESMTPS id 4RXCqz20NLz7C4m3; Fri, 25 Aug 2023 16:32:31 +0800 (CST) 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 4RXCqr4NNVz8XrRB; Fri, 25 Aug 2023 16:32:24 +0800 (CST) Received: from szxlzmapp06.zte.com.cn ([10.5.230.252]) by mse-fl2.zte.com.cn with SMTP id 37P8WKY6071336; Fri, 25 Aug 2023 16:32:20 +0800 (+08) (envelope-from cheng.lin130@zte.com.cn) Received: from mapi (szxlzmapp03[null]) by mapi (Zmail) with MAPI id mid14; Fri, 25 Aug 2023 16:32:22 +0800 (CST) Date: Fri, 25 Aug 2023 16:32:22 +0800 (CST) X-Zmail-TransId: 2b0564e86716ffffffff803-b2b5c X-Mailer: Zmail v1.0 Message-ID: <202308251632226430480@zte.com.cn> In-Reply-To: <20230824161248.GM11263@frogsfrogsfrogs> References: 202308241543526473806@zte.com.cn,20230824161248.GM11263@frogsfrogsfrogs Mime-Version: 1.0 From: To: Cc: , , , , Subject: =?UTF-8?B?UmU6IFtQQVRDSF0geGZzOiBpbnRyb2R1Y2UgcHJvdGVjdGlvbiBmb3IgZHJvcCBubGluaw==?= Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-fl2.zte.com.cn 37P8WKY6071336 X-Fangmail-Gw-Spam-Type: 0 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 64E86729.000/4RXCrB1xYPz5Sg6 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Thu, Aug 24, 2023 at 03:43:52PM +0800, cheng.lin130@zte.com.cn wrote: >> From: Cheng Lin >> An dir nlinks overflow which down form 0 to 0xffffffff, cause the >> directory to become unusable until the next xfs_repair run. >> >> Introduce protection for drop nlink to reduce the impact of this. >> And produce a warning for directory nlink error during remove. >> >> Signed-off-by: Cheng Lin >> --- >> fs/xfs/xfs_inode.c | 16 +++++++++++++++- >> 1 file changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c >> index 9e62cc5..536dbe4 100644 >> --- a/fs/xfs/xfs_inode.c >> +++ b/fs/xfs/xfs_inode.c >> @@ -919,6 +919,15 @@ STATIC int xfs_iunlink_remove(struct xfs_trans *tp, struct xfs_perag *pag, >> xfs_trans_t *tp, >> xfs_inode_t *ip) >> { >> + xfs_mount_t *mp; >> + >> + if (VFS_I(ip)->i_nlink == 0) { >> + mp = ip->i_mount; >> + xfs_warn(mp, "%s: Deleting inode %llu with no links.", >> + __func__, ip->i_ino); >> + return 0; >> + } >> + >> xfs_trans_ichgtime(tp, ip, XFS_ICHGTIME_CHG); >> >> drop_nlink(VFS_I(ip)); > I'm not sure how nlink would ever get to 0xFFFFFFFF since the VFS won't > let a link count exceed s_max_links, and XFS sets that to 0x7FFFFFFF. > Unless, of course, you did that outside of Linux. In VFS drop_nlink() only produce a warning, when (inode->i_nlink == 0), not prevent its self-reduce(inode->__i_nlink--), cause it underflow from 0 to 0xffffffff. In the old kernel version, this situation was encountered, but I don't know how it happened. It was already a scene with directory errors: "Too many links". kernel: WARNING: CPU: 12 PID: 12928 at fs/inode.c:286 drop_nlink+0x3e/0x50 kernel: CPU: 12 PID: 12928 Comm: gbased Tainted: G W OE ------------ T 3.10.0-693.21.1.el7.x86_64 #1 kernel: Hardware name: HPE ProLiant BL460c Gen10/ProLiant BL460c Gen10, BIOS I41 01/23/2021 kernel: Call Trace:------------------- kernel: [] dump_stack+0x19/0x1b kernel: [] __warn+0xd8/0x100/* kernel: [] warn_slowpath_null+0x1d/0x20 kernel: [] drop_nlink+0x3e/0x50 kernel: [] xfs_droplink+0x28/0x60 [xfs] kernel: [] xfs_remove+0x2aa/0x320 [xfs] kernel: [] xfs_vn_unlink+0x5a/0xa0 [xfs] kernel: [] vfs_rmdir+0xdc/0x150 kernel: [] do_rmdir+0x1f1/0x220 kernel: [] SyS_rmdir+0x16/0x20 kernel: [] system_call_fastpath+0x1c/0x21 > That said, why wouldn't you /pin/ the link count at -1U instead of > allowing it to overflow to zero? > Could you please take a look at this patch that's waiting in my > submission queue? > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?h=inode-repair-improvements&id=05f5a82efa6395c92038e18e008aaf7154238f27 I think the XFS_NLINK_PINNEED(~0U) can be used prevent Overflow in inc_nlink(). Is it better to compare i_nlink with (0U) in drop_nlink() to prevent Underflow? (like this patch does, do not make i_nlink underflow from 0 to 0xffffffff) Thanks. > --D >> @@ -2442,7 +2451,12 @@ STATIC int xfs_iunlink_remove(struct xfs_trans *tp, struct xfs_perag *pag, >> */ >> if (is_dir) { >> ASSERT(VFS_I(ip)->i_nlink >= 2); >> - if (VFS_I(ip)->i_nlink != 2) { >> + if (VFS_I(ip)->i_nlink < 2) { >> + xfs_warn(ip->i_mount, >> + "%s: Remove dir (inode %llu) with invalid links.", >> + __func__, ip->i_ino); >> + } >> + if (VFS_I(ip)->i_nlink > 2) { >> error = -ENOTEMPTY; >> goto out_trans_cancel; >> } >> -- >> 1.8.3.1