From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F02711187 for ; Fri, 13 Oct 2023 09:41:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=none X-Greylist: delayed 8011 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Fri, 13 Oct 2023 02:41:13 PDT Received: from mxct.zte.com.cn (mxct.zte.com.cn [183.62.165.209]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47D48121; Fri, 13 Oct 2023 02:41:12 -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 mxct.zte.com.cn (FangMail) with ESMTPS id 4S6M2Q36gSz4xVbr; Fri, 13 Oct 2023 17:41:02 +0800 (CST) Received: from szxlzmapp04.zte.com.cn ([10.5.231.166]) by mse-fl2.zte.com.cn with SMTP id 39D9esWV078823; Fri, 13 Oct 2023 17:40:54 +0800 (+08) (envelope-from cheng.lin130@zte.com.cn) Received: from mapi (szxlzmapp07[null]) by mapi (Zmail) with MAPI id mid14; Fri, 13 Oct 2023 17:40:57 +0800 (CST) Date: Fri, 13 Oct 2023 17:40:57 +0800 (CST) X-Zmail-TransId: 2b09652910a934b-6def0 X-Mailer: Zmail v1.0 Message-ID: <202310131740571821517@zte.com.cn> In-Reply-To: <20231013-tyrannisieren-umfassen-0047ab6279aa@brauner> References: 202310131527303451636@zte.com.cn,20231013-tyrannisieren-umfassen-0047ab6279aa@brauner Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 From: To: Cc: , , , , , , , , Subject: =?UTF-8?B?UmU6IFtSRkMgUEFUQ0hdIGZzOiBpbnRyb2R1Y2UgY2hlY2sgZm9yIGRyb3AvaW5jX25saW5r?= Content-Type: text/plain; charset="UTF-8" X-MAIL:mse-fl2.zte.com.cn 39D9esWV078823 X-Fangmail-Gw-Spam-Type: 0 X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 652910AE.000/4S6M2Q36gSz4xVbr X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,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 > On Fri, Oct 13, 2023 at 03:27:30PM +0800, cheng.lin130@zte.com.cn wrote: > > From: Cheng Lin > > > > Avoid inode nlink overflow or underflow. > > > > Signed-off-by: Cheng Lin > > --- > I'm very confused. There's no explanation why that's needed. As it > stands it's not possible to provide a useful review. > I'm not saying it's wrong. I just don't understand why and even if this > should please show up in the commit message. In an xfs issue, there was an nlink underflow of a directory inode. There is a key information in the kernel messages, that is the WARN_ON from drop_nlink(). However, VFS did not prevent the underflow. I'm not sure if this behavior is inadvertent or specifically designed. As an abnormal situation, perhaps prohibiting nlink overflow or underflow is a better way to handle it. Request for your comment.