From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFF71D591B7 for ; Mon, 18 Nov 2024 20:58:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5663E6B008A; Mon, 18 Nov 2024 15:58:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 515A46B0092; Mon, 18 Nov 2024 15:58:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 368BD6B0093; Mon, 18 Nov 2024 15:58:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 139A96B008A for ; Mon, 18 Nov 2024 15:58:38 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B60D540468 for ; Mon, 18 Nov 2024 20:58:37 +0000 (UTC) X-FDA: 82800426030.17.604CA58 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf09.hostedemail.com (Postfix) with ESMTP id 258F8140017 for ; Mon, 18 Nov 2024 20:57:59 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=kSkBLy9A; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=R+g2sTu8; dmarc=pass (policy=reject) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf09.hostedemail.com: domain of chuck.lever@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=chuck.lever@oracle.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1731963448; a=rsa-sha256; cv=pass; b=eqylgJVspdxD2F9JqTUgQyH6lLYbTnejnY08wVoNQtk1RSHzxd/JlHL/gsR51IqfIWihrI IV8Mz1MA+wnCTGQtbZs1V04dRTAZb83uS/73W7TfEGsXIPbpVMvAiss08+dMMtKGlO37sF /teibizmIpLv/U7wSbME+Q7kgU7Lei0= ARC-Authentication-Results: i=2; imf09.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=kSkBLy9A; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=R+g2sTu8; dmarc=pass (policy=reject) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf09.hostedemail.com: domain of chuck.lever@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=chuck.lever@oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731963448; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pnZ3AP2MW9azKgBYDo+aZ7wT9DO82x58622qZkb45Tk=; b=bbQXMIkBOHnTGQCad7lZujgKlrgu6Gxf71teZR/zuGs8Go/tj/P3z/yoC8AiqM5pHbUa8P 6em1Z6bOzhqdwtQGfOPbDdh80YkTi7m5H0veeExIk9tcRrlpJmv5TZVHKC9/ClPacGOzlS scC/4/U+DQ9VbXyNd0+U4l4fL8oPhbY= Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4AIKtfAQ009774; Mon, 18 Nov 2024 20:58:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=corp-2023-11-20; bh=pnZ3AP2MW9azKgBYDo +aZ7wT9DO82x58622qZkb45Tk=; b=kSkBLy9AFbeJG9VicYB35dfz5SvhuyDaW7 0VbtHx/LejgCN8b2IW1IdRg8WBwDUzl6Rx04tavCoDooG2xhbptxwkPnXkJWVdqz R44S9jtHIaZu/RpcUBu4e72IFpZ+PIfc0mnDFlNqL6AHlZvASX1+fb5rmb6KmNI0 m+s5oEy/NedQo11HtAHKH23+l7fBo64UQLhsi+idz1kVumkRJnZlw4zskoSYCYmU B4Ii0o/QCWceXpprtUvczMBsOIffn9PV5CVUJBegI2sAN+DXYiUjQSsPcB5zA/ml 4uQ8ktqKE+254Mrks418qG+6nV2CsptFtiQVP2f0m/Ua9JxlSJ9w== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 42xk98kjhe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Nov 2024 20:58:16 +0000 (GMT) Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4AIJpgUH023653; Mon, 18 Nov 2024 20:58:15 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2047.outbound.protection.outlook.com [104.47.58.47]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 42xhu80hvx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 18 Nov 2024 20:58:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ArOagQHKKulL6vySBsKecL3Dd9XJ+nqNEhsfVei5ChvierBNLGbIr4US/4cTjseEf3AB5mBlBFbM/RaljDvD0CQC987sbjFPn8sStsInoz7zAbHPN9+XOxQg77X4PuRshMf1Qs+JULqppsJA0UJUcRQSjJqrNTZ8EW+StXuiWo4Lr03DFC08nQbKyFxvhVp8i/6YpgzTYtdtQsb8gjO+iJyHzKACeWRdZCBipr0wFmiwGIEu6V4dwlT9xkxvhFgHZ3HUalIVbRridnbvK4Y+/4oUqZsjACFrWd553xt3+tha0ynBkaZ7whjPq8bsjS+vlROYILlu7OdfjB8QxebU4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pnZ3AP2MW9azKgBYDo+aZ7wT9DO82x58622qZkb45Tk=; b=Jl4tE3n9mbLyvv5qMC31RG+VPgpQcBwvG7vGJ6nJ/HyoEVHgpjiWKxuDnmNMlI2yppM5lrUwT1V6pIN3HPA1Np46lmEFXc7c5b6N4hSOdiq93+0SxZyUXwKfifOs5PWUo4zMtoL+Gh0sNyuuq+NSJ4VjLBgYtWQkqd9zbTRBR+YYieCqhuKswgxriDEWJJYUJGvU4tjjA7A79IT4R9SaxOOwNxg1lyEcBODcugshK8f/pWEOpagZfGXT7+GylpTCUWzY8aGzCLwTGCaP3L1cbIS/OWD6XQeG7zlOFbqH56+C+WI3Ik+9TTPgpkXJFO133aE8WbNAoINO3iA8yZtRNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pnZ3AP2MW9azKgBYDo+aZ7wT9DO82x58622qZkb45Tk=; b=R+g2sTu8zatWNPH6jnMQMhgJ/jEAds9xgUuh26BtlPxyFvqpCX2grHHL4z3McS2+QKUj1PNhXf17MrJsFAlY8Qpc+5K53OJlNCYMPTcaW7y7lVuNC1UcPSbkVXon/fCI3L9Vceu245hPOZqwb4Kg6ZeYHXY14zjqS4kHSvUIT3M= Received: from BN0PR10MB5128.namprd10.prod.outlook.com (2603:10b6:408:117::24) by BN0PR10MB5127.namprd10.prod.outlook.com (2603:10b6:408:124::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8158.21; Mon, 18 Nov 2024 20:58:12 +0000 Received: from BN0PR10MB5128.namprd10.prod.outlook.com ([fe80::743a:3154:40da:cf90]) by BN0PR10MB5128.namprd10.prod.outlook.com ([fe80::743a:3154:40da:cf90%4]) with mapi id 15.20.8158.023; Mon, 18 Nov 2024 20:58:12 +0000 Date: Mon, 18 Nov 2024 15:58:09 -0500 From: Chuck Lever To: Jeff Layton Cc: cel@kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Hugh Dickens , yukuai3@huawei.com, yangerkun@huaweicloud.com Subject: Re: [RFC PATCH 2/2] libfs: Improve behavior when directory offset values wrap Message-ID: References: <20241117213206.1636438-1-cel@kernel.org> <20241117213206.1636438-3-cel@kernel.org> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: CH0PR04CA0058.namprd04.prod.outlook.com (2603:10b6:610:77::33) To BN0PR10MB5128.namprd10.prod.outlook.com (2603:10b6:408:117::24) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN0PR10MB5128:EE_|BN0PR10MB5127:EE_ X-MS-Office365-Filtering-Correlation-Id: 0e1bfd78-1948-4bc1-50bf-08dd0813b6fb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?GGoMbc6Ntdg2CKYb9OeCe8CkVP4yea/naRFmDHBiUUT15uAnEDVWgKwA+ifY?= =?us-ascii?Q?B/wk1cmE6RPXZGKqrQkSjPnFD7iEgObdsYKlONqZWMSQNBNsRValhVhBaM+w?= =?us-ascii?Q?gF5gqwotv3sWv6R9xgDZ0cxgOXiehUQ61fYZpSlbjJUQHPQgX9ZX9gLQ6eXv?= =?us-ascii?Q?nxfwQHGE0TKMHlqwaPQWFDSyaBFIJ/xJIENN66F2b1NYNklCFtagHMPq7EGl?= =?us-ascii?Q?PNJpoorbxoo+r0wqkoKFxggvmapOADodJimNKzBA9ncjC2oqySRmhj7Z4P+G?= =?us-ascii?Q?R5E3mn7HZybJR8pNgMJ2TSQ24XVMdJVVomvFJhPbL5IXLiRm66CjPexT1Ozb?= =?us-ascii?Q?pZWJ+YNz/RLz3scV0ri4Uc1+Mpb8QXVYaHxcxs7VZGSfq1zKG08ZsGKvRdma?= =?us-ascii?Q?SYW60ryRhCtb9kPYGkK9LsXn/Ck0VM1chuYD9pUchQkraiPigtgWuISGvBlc?= =?us-ascii?Q?EQ7qYgOkIm7xPSDVGIBJfoGbcTNBeyvCPTAN+0idB9PLHNoAWNYG+QwVVZod?= =?us-ascii?Q?CTAS5VqFTR3FkamqB28xHDhboEkp2UdkX8aLyEfZMRQaYehYzq9Ug58KGrv1?= =?us-ascii?Q?7GI3uUvhq9n1HKpOI6Cmk68mIR0wTp1BWT8nwpu+UyGdmfdWq1bzLJ2Y/NsU?= =?us-ascii?Q?hHy8top2b6fpNFpxZRQBAvk9GZWrKyH0GIMOGVRzwr/NsIykr26iiDKkPOMB?= =?us-ascii?Q?2hCC4XRCPtgzuInSFdWTDRUEGc/wwEnN45Dlm86cCupHOdvuhOYnVrWnPbwd?= =?us-ascii?Q?GtbkpiyqV84RWQngbEeuK5/h9sdbRZBZkBPM/WNh3J3T7c+DO8DWap6vekZn?= =?us-ascii?Q?xRT+4j8LFZ6SDDIGamnEuShOhMFAoys//d+R62LO878EwOOOCdFOvdtFHCEb?= =?us-ascii?Q?fN1nwMrJF/4Zk6xEDD3Ywvjf5TWuIKZdukMhlSNN3yoirAaAynuCSLXqMyNG?= =?us-ascii?Q?5APHilOs7Zo5aKN4OrJ8+EhEFcPxzc+8+YJkTRGjtHSQYm6mQ8LcNIp+CbT9?= =?us-ascii?Q?CxK03P/qSUCDalgTmhX0XZSzTVW/UfTA1aT1uIwz0DRMFAMKhkU+9oh8v086?= =?us-ascii?Q?Dpv/fVAuo4rL2QfZ9I/16kJhTsZtjF4EnP7jrUHdbNJf06p2p6SdxGhnxutm?= =?us-ascii?Q?IRBfIEqktnr7uEtVXc7NFMp+rsXBbJ/bn81pLYgyPQxNofnUYmYhKXd7Sqd1?= =?us-ascii?Q?fnOS2mZODW/INB1OymXmfiFSA8Ln+2sTXPal1FUmv0HGQdIXwXLTtAhnkpgt?= =?us-ascii?Q?s61IPIFbsYvRJn2Vum7YeoJ5GhPTDrGTwYDPEnwglVboF0BSmyZ2IzVX3He5?= =?us-ascii?Q?pcm3k01KSX661IcmgMhdWRJC?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN0PR10MB5128.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?VTWMMXQTc74Er2DjB+6iuk8lNfwHvomVad720Drb6vaGLCjdKzKPMXjPNw23?= =?us-ascii?Q?CKbRbOv4Hje8wpBAFqgMxjgRgffP7Zezu4FCpZZpxTx5AWouJwn8wGpjliOm?= =?us-ascii?Q?h2hXhqnMP0JLST5b3djm5NadPZGQ4kp5J2aWamAqxQqxNACHCg/+LqBcHa7F?= =?us-ascii?Q?a+JZ/quKSlk7IJdckkmh9HRPEj6N1DtV8AAWqXlOOhcTgfI7zNptQgwgDjIh?= =?us-ascii?Q?E1xxJIeIsYYH86lmPrX32scHoJusdxw4dji63vNNLHzMCTRP5KTqsNehFDsd?= =?us-ascii?Q?msqyRQ2tQZMAezGZzb6VOFMQuJ1DNq81KZtW5XAmNUSFSunYPdyjloy0GHj5?= =?us-ascii?Q?8Iy4pQ11PMgSXBbwZuX8dwQyUykzyKfWQsud1jw1mXaJ4wQb9aM3KS4fTr2R?= =?us-ascii?Q?yisrqwuaieDXJexbW4pw8dp6h77hDwRFaTKovVFfRJtfpFqMnZ7QG2qxBe8x?= =?us-ascii?Q?/5C/oJbqSWFLND3fY6Ka4vWQRJAfslVAldJU1MwG5rH/QPnmhpjcgJ/nK9ec?= =?us-ascii?Q?S0qzJBgk8ZvPteRkMd4sQR6qUY96qT1vg8i+v1ETVWF93Yz7RsN0Cy4mOXN9?= =?us-ascii?Q?Y6b/ZgAt3h8SJPlSuYwl8bL5BU2ScS1BfHfEUSPX/aA3P3i73DtpAQQmBvSf?= =?us-ascii?Q?os4pi7u3B3Vt275kJxSZ6R4EpTZVWl5JzDO+UYP9wFsZDSEdNS+oyoHqCUpZ?= =?us-ascii?Q?uke/qxeji/IcY1E+RvSz6UZSIo6I8abyxQU10FOyYu9c8rEK1rCvyiLDmCio?= =?us-ascii?Q?9VND+tJrG7auKtow/SJdRXYuIA+HK8L+qk7iLnrf/hUn/ZrM8zf/9BUO+m2t?= =?us-ascii?Q?Uo/wq82zG1Re9/bNdBMvFLNRm4aQ2KcDPUPFva4kGohm6KUfqEvlLZNPvd8d?= =?us-ascii?Q?wQacQ8KjbUZc5iQXk/P+XtScX94y+GixvOKZT+Y9CqGkjW1hK1xHAAbSiWiV?= =?us-ascii?Q?Q041D2u1ent61zA1+1SZfIXG//j53UjdEBwGCGi4EkVW8a/6vbi3vlSBZhvQ?= =?us-ascii?Q?6X//N00cpjyF5E7lqZgcjLQcN7214yw/4xupT6mPDThBnJYaTFkoYNZnXzJ6?= =?us-ascii?Q?di32AtinqlCiS9Y+/uQ+wGrC39cW+QrpmQFUyJh3rqx4DVNodhiCu9M8klk+?= =?us-ascii?Q?McmWB7xTaww+STs6i5E0UhHo4SbwfBoQ0klwBdw0dcilxxO8fVXEEd4ZAVZa?= =?us-ascii?Q?LxtGin1IYU1U2hRNiTtvDIW4ETswHL7UOiSdL1TLaEMp+fSkFx7H82vwUUhh?= =?us-ascii?Q?p0iaQ5bJdjXwoRTxw2oYLqHr6+6usY6KJpXhFcZEQHuTRLDH9hLIwGu7KSbx?= =?us-ascii?Q?1P41MVD4Al4FupVvhYPHkzK2r9iu6I0rB81dxSFtRhPgq/5jfgICRIVL8bQg?= =?us-ascii?Q?ermUBkANy+ycf2ikJEm61gBTRuRyUR81PeXRCP3hW+qKq3lZlSL7xP+fsLMH?= =?us-ascii?Q?zr5oJkF4oekTweoxE98NWVaSAF5oOfTDn7DC1rgW9Kq8ADphZPVsB6GbsAPs?= =?us-ascii?Q?nCU0AtGlHEwD3Ky2KFQwTytujUfJXuRknw7XPETVj9k4n9jGy/tM1MxN5gRf?= =?us-ascii?Q?oTAtIB+hEZMavO+K5tBDT4MD1HGFdhxI/Uk3ArDT?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: TG0muPz34FM6oH0hgOB2klEjzHoDUnnoF4fUN0NC+1KCAe27l0MY7E0FcpTh/UdGTNVRHonveZI0hXBhpuW/tucZoaW6PqMEMAprMIsU6Xs53IRjO+tvm4bAdufU3UAPVtsEcuosw9OkA3IBu/phH0ZPD2z7r90BOkwQBgdDIgtiLTBRLER0DqMDJt0X+cnKKJAjX5z0gY+R7vRbrQUfsReVjrqROOnY0QBBHVrNim2uZTifdWYaaySaRP9KQt2NsCFb4xKHpU1trB0fNCujRjGSvpV1q0CJHgm/gGhsaIJ3tAKgqD9s8ID+ntE7c28i1+4FliYdCBFWIPP+9oyFiddfnR5BLsXV9gqY4/+TN3wLHyJvYhRIfiX89NBApQCl9L9FL/KhwbCThrFVuUoIOz6stSkzZYzsnMlKtT/yR6KgBf8ovo8eHs0p7W0nijuarAm4vGdTNXdGYFKlEHL+WjjHvyExPoADVVc1iGZ3gRrPs4vZWaLxY21P0mHyppMwbA0TfD2our4M6DqT0/wl5bLphOqHohhhUSYKXTqNtZE7GfEOteMcgHUY4iRX0XhjUySqCO2UdxxobdMUUn9+7Sj+OjhNlNR7Z75M2auNtVo= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e1bfd78-1948-4bc1-50bf-08dd0813b6fb X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2024 20:58:12.5421 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HdPV2J/swFyjDOGDT3z6Q57jAC40jASD2QiyerFg8Foub240pf1c0rkr8eR+f9RyGE0ZVEkCCsEy78th39y0pg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB5127 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-11-18_17,2024-11-18_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 suspectscore=0 phishscore=0 spamscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2409260000 definitions=main-2411180171 X-Proofpoint-ORIG-GUID: uh2UBnHxIjOnDkdKy9Aru_BGa-tA5f-C X-Proofpoint-GUID: uh2UBnHxIjOnDkdKy9Aru_BGa-tA5f-C X-Rspam-User: X-Rspamd-Queue-Id: 258F8140017 X-Rspamd-Server: rspam01 X-Stat-Signature: 1xiafr7ip6q6c66ux1833u9mp7p6odb7 X-HE-Tag: 1731963479-262841 X-HE-Meta: U2FsdGVkX1/XKY1N/ZXpspFC7+zXtdwvXqxGoWsA7P4POnZgQbtpc+drOuCZFCZP+GqwmRM/Hsks3CiSm9XrOmD1CSFB/U9saJWDusmYaMOfQGp1i7rjUsgIMDr0hQQw1cryyavAv5of0g7vZ8jOHK3X70XgOTt9eW8Q2nibBKWjBLPr1odCwL1QMpFDJghuhIY9Kg3PGyV3A6cykYRniJReIvOewCTc8gvQP4WyGDnx0bARSUukdf9OpPioXdD7bGD61/oYElVHloZKTiLDMua9ytFBBA+OwMTJE26GsXJDM1Q4JPj9tm8mOuhnVqp8sJyrUGlBFWp8cBqvRM/+gB9+VC5boQWJP3Zk6RHoobPtZHvTOL91hKK21xyVveoZAkZeRyr7OV3wegpkm7Mk4hATZKK89fHyaRyyhNerD4eqzvbd359tEP/KKiGdMIh2E8JuZq+h1YKJ7nLDEH+SpDFi98ZXa2l6oIS5boZYM9gK8y51jO1s+9+dWRPd5qlmJxudJ9lJswHoCSiCHgTAr7exyXw49FsQsMuOAfCe5S0yd0J8LrIWAl4U2q8+u23Gi5ueQVoQ59gQd//2TjL95RKSdQjYyAZyf+VSWOOpIxe1HmGFsOuDOYqBolkCsRaxW9wATArdnBwyi5Mh8Yx46+OZpGsWuROTavg75p8JjdnyTK9YXUDM7A5cslX93PX/0N3ts49De+bmtj8ITNJ1LUB79u6pCjf9/XSWBFo2RgyBeu6ocFz19gCL8ywaaz4LpUqvbYcdasGYipItRxrfDoNBNGq79d6HldjSC2TMLCiLyTNinWzvVJ107CZlwSSxKDsz2FHTKgWytjDaSkqrNLq/GYNGmLakpqs7p4E4ZxxxIl2+dJmgzhmNu/8N2VpqjO6dD8luf4eOEJjMT379+5uDQwtrcvVNtYLZvcSODafPgQuXz1SAyUUCvQRdQ2USVedpu7KPlBYoDBCd83e QicjgPuQ U54TJ1F8CUIrIlQzQGHXmT3y1MP5Xoi5tPAnFyLLz4JMbPbsXnr63Nsa+NSakwqsNWvWTeRDdLwX+gg+6cMyh0V7xpwAkwsi8dGJLGa4qOMV34jKvK2Gdi/ueHmfja1I7HKpdKUI79zZtECAQ2MGk8+1qnUp1Xd0g1feOBASdR8B0nRgF9NtlkOMuV8GYTzcjilPTxxbO4xu57Pn9sbLROshaOPv8uC7dICzkdsiBvbDZ+WNEIvoGRfDcwytbeQ3887CiV0ifTqz0jCf/1H0YFJwgaf22xhxQJYmj91FlKBl7QhhqXC4/nIYjPNKZ8vVaAla3UXCndZirRQa135yjz8YKsQXy1QGe3VNVH3G/wZDL1CfR6MKwbwW49VvgLc/MK6tNY4TimtznHz968f0aurgujmYo+kqKAbNxW2fn7Geg5EJCqKMvv+mQHfFA3SCHa38WF06MTtqFk3HeAggl8aFzF19ggpifdfB4CoTNHiEjUwGYdW4ClnPkluUA09FiGsqK8iQUXvZEbabK2RbTziePS2t6sP6qPUyXy6/x3oWYCpijKBkUhtORf5ZthPt6teCfAMoZjZwWa2zIPVRf4cY5vCBNDFfmNIHvrtZ64JnJC+xGHROzh4PPwQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Nov 18, 2024 at 03:00:56PM -0500, Jeff Layton wrote: > On Sun, 2024-11-17 at 16:32 -0500, cel@kernel.org wrote: > > From: Chuck Lever > > > > The fix in commit 64a7ce76fb90 ("libfs: fix infinite directory reads > > for offset dir") introduced a fence in offset_iterate_dir() to stop > > the loop from returning child entries created after the directory > > was opened. This comparison relies on the strong ordering of > > DIR_OFFSET_MIN <= largest child offset <= next_offset to terminate > > the directory iteration. > > > > However, because simple_offset_add() uses mtree_alloc_cyclic() to > > select each next new directory offset, ctx->next_offset is not > > always the highest unused offset. Once mtree_alloc_cyclic() allows > > a new offset value to wrap, ctx->next_offset will be set to a value > > less than the actual largest child offset. > > > > The result is that readdir(3) no longer shows any entries in the > > directory because their offsets are above ctx->next_offset, which is > > now a small value. This situation is persistent, and the directory > > cannot be removed unless all current children are already known and > > can be explicitly removed by name first. > > > > In the current Maple tree implementation, there is no practical way > > that 63-bit offset values can ever wrap, so this issue is cleverly > > avoided. But the ordering dependency is not documented via comments > > or code, making the mechanism somewhat brittle. And it makes the > > continued use of mtree_alloc_cyclic() somewhat confusing. > > > > Further, if commit 64a7ce76fb90 ("libfs: fix infinite directory > > reads for offset dir") were to be backported to a kernel that still > > uses xarray to manage simple directory offsets, the directory offset > > value range is limited to 32-bits, which is small enough to allow a > > wrap after a few weeks of constant creation of entries in one > > directory. > > > > Therefore, replace the use of ctx->next_offset for fencing new > > children from appearing in readdir results. > > > > A jiffies timestamp marks the end of each opendir epoch. Entries > > created after this timestamp will not be visible to the file > > descriptor. I chose jiffies so that the dentry->d_time field can be > > re-used for storing the entry creation time. > > > > The new mechanism has its own corner cases. For instance, I think > > if jiffies wraps twice while a directory is open, some children > > might become invisible. On 32-bit systems, the jiffies value wraps > > every 49 days. Double-wrapping is not a risk on systems with 64-bit > > jiffies. Unlike with the next_offset-based mechanism, re-opening the > > directory will make invisible children re-appear. > > > > Reported-by: Yu Kuai > > Closes: https://lore.kernel.org/stable/20241111005242.34654-1-cel@kernel.org/T/#m1c448e5bd4aae3632a09468affcfe1d1594c6a59 > > Fixes: 64a7ce76fb90 ("libfs: fix infinite directory reads for offset dir") > > Signed-off-by: Chuck Lever > > --- > > fs/libfs.c | 36 +++++++++++++++++------------------- > > 1 file changed, 17 insertions(+), 19 deletions(-) > > > > diff --git a/fs/libfs.c b/fs/libfs.c > > index bf67954b525b..862a603fd454 100644 > > --- a/fs/libfs.c > > +++ b/fs/libfs.c > > @@ -294,6 +294,7 @@ int simple_offset_add(struct offset_ctx *octx, struct dentry *dentry) > > return ret; > > > > offset_set(dentry, offset); > > + WRITE_ONCE(dentry->d_time, jiffies); > > return 0; > > } > > > > @@ -454,9 +455,7 @@ void simple_offset_destroy(struct offset_ctx *octx) > > > > static int offset_dir_open(struct inode *inode, struct file *file) > > { > > - struct offset_ctx *ctx = inode->i_op->get_offset_ctx(inode); > > - > > - file->private_data = (void *)ctx->next_offset; > > + file->private_data = (void *)jiffies; > > return 0; > > } > > > > @@ -473,9 +472,6 @@ static int offset_dir_open(struct inode *inode, struct file *file) > > */ > > static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence) > > { > > - struct inode *inode = file->f_inode; > > - struct offset_ctx *ctx = inode->i_op->get_offset_ctx(inode); > > - > > switch (whence) { > > case SEEK_CUR: > > offset += file->f_pos; > > @@ -490,7 +486,8 @@ static loff_t offset_dir_llseek(struct file *file, loff_t offset, int whence) > > > > /* In this case, ->private_data is protected by f_pos_lock */ > > if (!offset) > > - file->private_data = (void *)ctx->next_offset; > > + /* Make newer child entries visible */ > > + file->private_data = (void *)jiffies; > > return vfs_setpos(file, offset, LONG_MAX); > > } > > > > @@ -521,7 +518,8 @@ static bool offset_dir_emit(struct dir_context *ctx, struct dentry *dentry) > > inode->i_ino, fs_umode_to_dtype(inode->i_mode)); > > } > > > > -static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx, long last_index) > > +static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx, > > + unsigned long fence) > > { > > struct offset_ctx *octx = inode->i_op->get_offset_ctx(inode); > > struct dentry *dentry; > > @@ -531,14 +529,15 @@ static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx, lon > > if (!dentry) > > return; > > > > - if (dentry2offset(dentry) >= last_index) { > > - dput(dentry); > > - return; > > - } > > - > > - if (!offset_dir_emit(ctx, dentry)) { > > - dput(dentry); > > - return; > > + /* > > + * Output only child entries created during or before > > + * the current opendir epoch. > > + */ > > + if (time_before_eq(dentry->d_time, fence)) { > > + if (!offset_dir_emit(ctx, dentry)) { > > + dput(dentry); > > + return; > > + } > > } > > > > ctx->pos = dentry2offset(dentry) + 1; > > @@ -569,15 +568,14 @@ static void offset_iterate_dir(struct inode *inode, struct dir_context *ctx, lon > > */ > > static int offset_readdir(struct file *file, struct dir_context *ctx) > > { > > + unsigned long fence = (unsigned long)file->private_data; > > struct dentry *dir = file->f_path.dentry; > > - long last_index = (long)file->private_data; > > > > lockdep_assert_held(&d_inode(dir)->i_rwsem); > > > > if (!dir_emit_dots(file, ctx)) > > return 0; > > - > > - offset_iterate_dir(d_inode(dir), ctx, last_index); > > + offset_iterate_dir(d_inode(dir), ctx, fence); > > return 0; > > } > > > > Using timestamps instead of directory ordering does seem less brittle, > and the choice to use jiffies makes sense given that d_time is also an > unsigned long. > > Reviewed-by: Jeff Layton Precisely. The goal was to re-use as much code as possible to avoid perturbing the current size of "struct dentry". That said, I'm not overjoyed with using jiffies, given it has similar wrapping issues as ctx->next_offset on 32-bit systems. The consequences of an offset value wrap are less severe, though, since that can no longer make children entries disappear permanently. I've been trying to imagine a solution that does not depend on the range of an integer value and has solidly deterministic behavior in the face of multiple child entry creations during one timer tick. We could partially re-use the legacy cursor/list mechanism. * When a child entry is created, it is added at the end of the parent's d_children list. * When a child entry is unlinked, it is removed from the parent's d_children list. This includes creation and removal of entries due to a rename. * When a directory is opened, mark the current end of the d_children list with a cursor dentry. New entries would then be added to this directory following this cursor dentry in the directory's d_children list. * When a directory is closed, its cursor dentry is removed from the d_children list and freed. Each cursor dentry would need to refer to an opendir instance (using, say, a pointer to the "struct file" for that open) so that multiple cursors in the same directory can reside in its d_chilren list and won't interfere with each other. Re-use the cursor dentry's d_fsdata field for that. * offset_readdir gets its starting entry using the mtree/xarray to map ctx->pos to a dentry. * offset_readdir continues iterating by following the .next pointer in the current dentry's d_child field. * offset_readdir returns EOD when it hits the cursor dentry matching this opendir instance. I think all of these operations could be O(1), but it might require some additional locking. -- Chuck Lever