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 53F82C47DA9 for ; Tue, 30 Jan 2024 04:08:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A63ED6B0095; Mon, 29 Jan 2024 23:08:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EC516B009B; Mon, 29 Jan 2024 23:08:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F0C86B009A; Mon, 29 Jan 2024 23:08:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6185F6B0093 for ; Mon, 29 Jan 2024 23:08:34 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 35210A03A9 for ; Tue, 30 Jan 2024 04:08:34 +0000 (UTC) X-FDA: 81734645748.05.B304ED5 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf26.hostedemail.com (Postfix) with ESMTP id 5E845140004 for ; Tue, 30 Jan 2024 04:08:30 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=iOFxAdQt; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=UhYfymEA; dmarc=pass (policy=none) header.from=oracle.com; spf=pass (imf26.hostedemail.com: domain of liam.howlett@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=liam.howlett@oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706587710; 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=00J7mfGYaedQ73ZsWBbD5f9vU0i4MQOB/BUTQpGuoCQ=; b=l8/exXSbhuDqmHaUTY5cgiUG20limrfnWmmCDosZreTzsy3kFzftAkyqy0zuIz4Wlvolaw VZR1FBvcB1RJT0ApCijZK2fHso/40sXhKyLStEuSfG9EhbeaAksqDDLoz56WYKb/tHYEa1 wUtMPVumUKze70p2cpvIi0W7n8vc2Ak= ARC-Authentication-Results: i=2; imf26.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=iOFxAdQt; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=UhYfymEA; dmarc=pass (policy=none) header.from=oracle.com; spf=pass (imf26.hostedemail.com: domain of liam.howlett@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=liam.howlett@oracle.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1706587711; a=rsa-sha256; cv=pass; b=SE9TcTxE1QqHJUXStbaC812pSqV/aD83aTTHn2RY7emAQJRGYdQvi0lnvZAP1/W5YmYou1 ZVbnP9/BbDZpm4oCiqEM5nWwU6iyXf6ElfEcUbtcl8cAmZSLWgbPmxvh7DYD7ZTo8yI1aa G9QV0JzBbbyjMC2hEvu4wSpiTkdgsT0= Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 40TJiORI022267; Tue, 30 Jan 2024 04:08:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : mime-version; s=corp-2023-11-20; bh=00J7mfGYaedQ73ZsWBbD5f9vU0i4MQOB/BUTQpGuoCQ=; b=iOFxAdQtnuZfJj0xE1amLyHgc+iqX0rDMIrWObk3/Pke3gSDFk1RbpJ31B+61VklyfXT wBjngmIItrk2XcbGGY4zs2whioXSW+5BUNiob9vaJ+ZRIUp5I04zdV6n+TPDnyIOgGNk mhEKfPQ9cdERcasPyprPkHWXg9LH2LMTLNAyVWC9TmaqpZDhJsQ8lQr2Rrpy4k3YgwfX q1dGUUAu5tX4o8OcDzuW9SoDM83F0BH4k7z+sKnRXcpjnQPJI6ise3RAgNgREbP2jUAE 2Osfa/X0ECmj02z9d+/ZcGAnRC2a7Rr1GtFUTQRs/gM/lVHbr57HgExTpTxhxyfDHefp Vg== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3vvre2dpps-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Jan 2024 04:08:19 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 40U40mIH035421; Tue, 30 Jan 2024 04:08:18 GMT Received: from nam02-dm3-obe.outbound.protection.outlook.com (mail-dm3nam02lp2040.outbound.protection.outlook.com [104.47.56.40]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3vvr9ck3kf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Jan 2024 04:08:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jEPiBACJj3c6GEh4NIwFOLOxKVBdc87tOqqS3EETQ6n21HlUZ2J1dMBVd7XXiEIURAE23dGcw5IgL8qEo++tbmRyx0HOHvadYNZ3BkUJQSvxmPeZyfVPEzQgZzO9Ut+CuZZmURUOwr6z+iXaLpygAjNar42uKJ12mElJ/alUtmW7qFepzLtGBZ3xPTVf7LVxxeniQP2+rAanijvZ+a1j/6Hy7o3CFqeU6GoqIXoN9cxcPKNTa/Us3BC0sL6/5auVWXPMpkmpVqlwcjYGfb9sq2Pi6vZBxxlLSPIS2GffNucsc86xrRJHo0vkElzm0H15DlrHOczuRT3D8yT9Hdz5gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=00J7mfGYaedQ73ZsWBbD5f9vU0i4MQOB/BUTQpGuoCQ=; b=bII/15nhUKwqGccCuPzuzMxS6IdxZQvG8SrJthWMTVc9RSCEXFrW2zuZnSGAGmQ621cE1SfTUn4VJ1t5JfSgDFEFFq2zvOgr/QBebLhazAmqAb+JHoNHnKSY1rSEaOjbHZ8r4vX0cUWPydPOp530DOwgj0dUytpa8CAnc4EKYNT2aIhUTFb/pvcmTaCtQrMdH3jeOJBOg2Qi8b+ppSyWlf1j/EvEQ7aOpea9qFkUWqsQvM4X0+LePV+AshddpHCGsFQ3x1uMcuvQLdcT1v5rQzxNzelnjU9fAXBU+zxUKEoXuedmpSc5fkcR6fbi+0UESCa7LgKyWlcMJngXhd/+dg== 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=00J7mfGYaedQ73ZsWBbD5f9vU0i4MQOB/BUTQpGuoCQ=; b=UhYfymEA/BDFlM+OtzVFEw01xGqzDhNKDguHRF7+AkWCyA73dlkE9F2BXBbarxQkzwRnxo3AG5gNKqHP4jJswxBovz4y7EhPmpqWxFT6R5j3hNwkuCSzvBmWZLduDN5N5ving6IW2zyMMjdQLjmf4lWby9kWl6Q2BBrvV+9ckeE= Received: from DS0PR10MB7933.namprd10.prod.outlook.com (2603:10b6:8:1b8::15) by PH7PR10MB6649.namprd10.prod.outlook.com (2603:10b6:510:208::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7228.32; Tue, 30 Jan 2024 04:08:16 +0000 Received: from DS0PR10MB7933.namprd10.prod.outlook.com ([fe80::20c8:7efa:f9a8:7606]) by DS0PR10MB7933.namprd10.prod.outlook.com ([fe80::20c8:7efa:f9a8:7606%4]) with mapi id 15.20.7228.029; Tue, 30 Jan 2024 04:08:15 +0000 Date: Mon, 29 Jan 2024 23:08:14 -0500 From: "Liam R. Howlett" To: Miaohe Lin Cc: Muchun Song , Thorvald Natvig , Linux-MM Subject: Re: hugetlbfs: WARNING: bad unlock balance detected during MADV_REMOVE Message-ID: <20240130040814.hd3edkda5rbsxru7@revolver> Mail-Followup-To: "Liam R. Howlett" , Miaohe Lin , Muchun Song , Thorvald Natvig , Linux-MM References: <42788ABD-99AE-4AEF-B543-C0FABAFA0464@linux.dev> <4780b0e3-42e1-9099-d010-5a1793b6cbd3@huawei.com> <531195fb-b642-2bc1-3a07-4944ee5d8664@huawei.com> <20240129161735.6gmjsswx62o4pbja@revolver> <76f33f3b-f61f-efe7-f63f-1b2e0efaf71d@huawei.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76f33f3b-f61f-efe7-f63f-1b2e0efaf71d@huawei.com> User-Agent: NeoMutt/20220429 X-ClientProxiedBy: YT4P288CA0029.CANP288.PROD.OUTLOOK.COM (2603:10b6:b01:d3::15) To DS0PR10MB7933.namprd10.prod.outlook.com (2603:10b6:8:1b8::15) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR10MB7933:EE_|PH7PR10MB6649:EE_ X-MS-Office365-Filtering-Correlation-Id: 1c61afdb-d975-477f-8706-08dc21491593 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CNLjTC5oB4Y1Sfy/CWLS5zuhBH+Z3qUY4wi7dlUN2XbIQIs2FFV4aXLy03g+gFMUEdAYiuNuvHYH3oU8GfTi6Yvf6Cn1v1A9GA98mZmwLjIEa/juHDMiW7wQ40X37O5axjXcb8+AgMz95UYYv2QKYdcLz6RzYZvUJ07mUKGs5d2ATUMkd8LHMbzrKf2pS1kgpt/BZvs3lL+d77B/hIqASkF+aEeXgXHg1Yt1wBzEnFcyxPVOZFe+lF+khnjAhJhREl5Lt1vND75y9VvXd3Xmq+IcBQUumgV8b/Gj1/rjJrb4K0F6riM4MZGym6d1SNTKqDarZ3hfXuXeAO+EeRKTUuEzBurfb1hv+7gH1dMdKhh3BbBakyvozyCNs3QTqDiNT8Wm/LMAyag/0ZtPoGe326yPpW/rRgVg1U8zq20iJpAQaxea+Y12nRQnvsa2ZmmAPxIJrMwaz8Q/jeMgQiiNUa0BsKFqUjIReIeiiOURdHu0iPImllU5bznukf3/ViYUMEBHCu74B1x1NejkWFmuXbCRwC1IsnE21qSvgDWHFDsnFo457BJVK5ped0jRDXFM2U5rQMYOaP4m0b92YqS/FvKNsYfAy0vAH6MhuB84cUJpwny59n+QmC2TTPnuknpj X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR10MB7933.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(7916004)(396003)(376002)(39860400002)(366004)(346002)(136003)(230273577357003)(230922051799003)(230173577357003)(451199024)(1800799012)(186009)(64100799003)(6506007)(83380400001)(1076003)(53546011)(6512007)(26005)(38100700002)(8936002)(5660300002)(4326008)(8676002)(41300700001)(2906002)(478600001)(966005)(9686003)(6486002)(66946007)(33716001)(6916009)(66556008)(54906003)(316002)(66476007)(86362001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?gJZ3TjzH6HCz/+1TePsUR+eP5dxXt1m2zCSuIJ3NOXrlWXKnUPTD9kRtR9+2?= =?us-ascii?Q?KMQDdXbAfOZEHUN8qJm/SxTuNRJxrOuG9P5nKidb1LeVZ+c4l4d5Jf07TGvo?= =?us-ascii?Q?kgTrkf5ufDi5HksOiVdS2KrHl4n2K4zLpuHuJCyUCLtodmntNCXxesjUSN+b?= =?us-ascii?Q?9AsCsHTe6VmMxFo43xUfssQfsO18whA3YMeB2VQYp+LGBQM+2RDkxbBMclYP?= =?us-ascii?Q?1A/2g6Oy0BGU7T2RimeHS7nz6f1sEjjtt8W6DBDFfb9lE1owiJtE/mgOV+B0?= =?us-ascii?Q?IyJUhev0iMeoE7O6OZ71weMBg05xN0lPzwID2LnCMOEMH9wpRHhrvB3wqJti?= =?us-ascii?Q?jSLq65l5Sg9Ylh0mDPW3IkWUaxucEKt1Ta8k9u2kLtyPCNXNNmr2XZ87a9oN?= =?us-ascii?Q?/RQ2QoL4OCdmvgctEsYanhRvTygqxCImfOsUKMoFzLP1uLl2mk+viy4gANnS?= =?us-ascii?Q?UcY4ILvBCmKfy+BR4/axSzfHkx1LdphMfx1DuZitEOdlhmJhVtugu0f7yEDD?= =?us-ascii?Q?i/RrRgCBEojM9qIX3r3Hru5GHNcE1klCpnX8FLUqUJFkfveRwB7A5yKPLwKa?= =?us-ascii?Q?xkki3QX9zZBorwKsDWG2KuEhuS6CIFcZcEOc4pNUPZJqypjw5N0NsP/aCMqZ?= =?us-ascii?Q?nzMpcyoxXdez8bbsA6eWGverNc8LhsEC1j34Cmd6Oo6Le0nwssCSrBdOUbb2?= =?us-ascii?Q?5N+nA0E1zsDIUqC5psBFoPEKEpVxxjAXQLTyL25g5KyId8a6J/Y5bPVyRsFS?= =?us-ascii?Q?Qo4zIxe8uxYIi4TUdeN+aBMuYrt5e/GZ9NbJo1YPnMP/P7mEgkP7J0nel9v0?= =?us-ascii?Q?k3ZYTNRwmCQJKE+kWMD3cCCw01gyUm684Ii4TtWMneQcbqDTmqkBsmMwYw38?= =?us-ascii?Q?rupRxBd3uR3dccuf8//+NtO93tHR3kya4jq4wcNri+Eias3UsbQaVjLcK5nR?= =?us-ascii?Q?4shDw82kn/tZOxKlbE4nRGsI+5jmjufl6b8w7t2nE+z+QkRYp57BgMYoIBO4?= =?us-ascii?Q?JFKoEOu6Xm54GENzXOCwLpDzJqFaxi9EReb5O8PLa3Kc5eneh+vyCw8ouRSl?= =?us-ascii?Q?h1Cn4NNFLonoUFubQTT9OGmz70FiT7b0Qh6KYPjasvI7UDMESZOn0N2lPwbb?= =?us-ascii?Q?SUoYNl6d9Da7xsA8zAWKdWIaxis1NnWN+5yfmfzw5hV6bLjEmHch1qdouDgD?= =?us-ascii?Q?4kPDsZ2WFCVJp+dbDrAeVFUCWK51VBgvreLtqi1+GxQqdyZ+E+hI+PR9+Xe1?= =?us-ascii?Q?JEZtnm74hj+av1YSxRcNJZpe7xqO6rPql4R6YDjFTwp1g31bYxVKeX03t2D+?= =?us-ascii?Q?sNH+S//b7qO87NUzJDh/WbdtS98oHaQ3e9kiIQYkvUZvAjxSpUQvZozmWGN+?= =?us-ascii?Q?n/PMnAnPiuRDnGYV6jr6ZQoeAg7h/gEYcadrA0ewWHyqcLvDO4L6D62DU0DH?= =?us-ascii?Q?MhNo6DfwucRxrO7Omeulv+CjPB6HjUJNTEemQcaBtgVRRp4ML46SokHZ6TSg?= =?us-ascii?Q?aOAW5iU4oDUDu4xYsV/4/K9V3RYvZThhOSgWk5ZYTd8tsbYPG5tCREicj4Iq?= =?us-ascii?Q?ilA3KR8SLvU5rlzN6wxeFSp+tjxWNQh3eHQEeJiK?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 9EkggKiKyBaQTj85VF6sOETuoXMB7KUQrQW9ItyMYsRsXegAVR7DJw22p14kxHpI3G76SsdyqEMbSMyL3VUjcrdqbI5jQaz5qIQUKM94mHDOB5m1Uviu6wKJ7oAi9QMW0mrEEsCI/Z+Ly3E79HTQBLBp6xzYegq2tqODJ7y/aRHPqZt0pqxE9Kq0fSj9pf8Os1/UlZbTYBYL9+PUQRexYSxwH9ESgyuY2MJlPYU1Mhb5Gl1d44EncCoupLFU/MSJz2E8CfPFqAy/EnM55YEDLsIA0+dTF+Xg6UNrIcOvqKHOcJUoOrDn/CuT/yDcZyS1e7S25FYr69/xuKo/7+d8+AruwRvcU578w0yxeSGu9pmHqFkvMNqr3F9mdeAQCRxW28IxC/YgnD0LVPhFbdAHaph3TO6X0zhtsUuKWOqfrBQtp7SWHkS0GzjRz9pfZhgEmxH8D2MbVl9kWQnzSOcsb4r76H4quRlsCbuZtiL2PzS4EDhYc1m+jTaYK3Mg/gKyMzW3onVEua3yC7zqXgoOemGi4JMqKpjBdWCN1zZlRkgc1Vik15cPdLAbwSuzbngDy7f1Cm5XWZ1w4VLerA9Lm3fmoeFTYQjIhbAcx0IITvk= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c61afdb-d975-477f-8706-08dc21491593 X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7933.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2024 04:08:15.9091 (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: 2CFjgtGxZHpGypABkNOn93QIqeppOUMUNMd4AmwKk9BAudQCn/7JlEJakJ4F/Lrh6jkjObNZn3Iteg+ZWvSkow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB6649 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-29_15,2024-01-29_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 bulkscore=0 spamscore=0 phishscore=0 adultscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401300026 X-Proofpoint-GUID: qc4IOKVEb8t1Cgyf2ZByvOlYDV9QKBRE X-Proofpoint-ORIG-GUID: qc4IOKVEb8t1Cgyf2ZByvOlYDV9QKBRE X-Rspamd-Queue-Id: 5E845140004 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: p89rjnqg1go5hyxjd1ugzki9z1a89raw X-HE-Tag: 1706587710-983245 X-HE-Meta: U2FsdGVkX1815XPY7grLlJSNwm5m4uHwa7IhkTHA3qq1wJoExiNwqQH93XdlRq9Tvc/q6VntfINkZaviKxiTitX6Vhrf1M8KIhaIf+L6Ke/xO560gxKByYuuViKrHI3g+jCuPrLCd98F5HgvLp5ahopALMrgPHFG0b6v4ntN25JSkukfxXJzZbGUUZW9nwejp6Et9gXseU0qYe/pXDCbfkrKbAGtBqvet8kYq+a/KVmTG4Edsb8eLWU28fbyHx4UlaXyLvO30u/TORAdbBGbOYY9DMtEXpkgtqUWK42ZYkPc3+Os4jL2+EW4CuyF7/yYyF76+mtU+OFBEI+yAzlYAI6ckahVSgyOLcSAlayB5OGu/ErZQyz7Kf9gdAgXopixBR3pVVsyLgTeQsFiH2CXrT+FuKf+U7c1pLtL0/CNykGpHf+/d+hfhZJT6QH9WCd6cLGMt/v3mRzpaa/jkFZKTaPRmPB51cqeZZOmpwVrvFhI0fEkC34gzUsibs6my8Hoo7Z5240Zf2yUVJavJxqTPQ9LRUwSabSOqBDb+QEHiiKXJo+LZEKMi4q4KyktBTgi/GuKWymeg/WEWIV7CmKpT6X8RETOA+o56AzIpFrSjeHRE6uM60mA7qnuZ+ghI8vCmpz86jbUIAvHGCjATNVsD2SVbdcbYcG6KpuYrlcXQp1Bp2sai/WFi+JQEijV0+agY4VCJCMOFaZ3p/o7KfAcV5Rx224vfebl+nxx1jH5htmLQyp/pk8yeVtM1HlzO+8kbMxF4Rwn6xCVHgcJWDDCzzlr7m7NM5f4v+1ZiAhZ9o4gtEfV9jkc3ud010Ikq3w1RfcphI7/OmZ2ijOoXa15CCA4X31ZJZiAf7h/jbEmk5B8R/AW6hEBhB6yH01HAHjPgQzJkUvu9/7ld81wBm3rNG27NUTmjMqeUvWbTa9/zwglY92bUJKyFqYu414QkEYq7Uw9IT/4nNpWpEGifKK gKZYqzqu 4G4SAvWDD24m+pl57pr47xRLZslm/7EyiaxTslonHYaeAxHn8lmgI3gbv7nNBa3wsrGb8iA9xzytfOryxzmGdWjt79RGl5FmndUAH85nc3CK0c0La+DaeY/GYewDpqxRxqyr66C4FA5j6bluBBbdUEZ+u/sDD6HiRM1gTaN+gFqbSGbANzpqwbf75UAMJ6aEm4zTO4muD0zmfNVD5w896fBb10rY1urE4WtyL5AGSyixBsVRr0UxIpnc2mwaROUbvvmFAt/LSxioXWUQCMLtVd+7ypNZUgjJlx5FXWVQ2kT20LC5B3w+goKexe63Cbsr5d+QqULkv5JOPZPDyEagFpfx6yrMorO/Ok/tg3GIhG21EAJ74bmurQrS+VGYIpZQthleKNQMuv+rWoPg2EjD4ZPhIgeAHcF0QnB2cGPIQ7f1d3hB26A67AM2KJg9vDKgWWjGoLaVLQVq5iHcudkZcMk7o3k9lrHiY7nDuBUZAbWk7mFwUtAPQO0084Uf1mgsx/biiCUszI06ahDpqMThzBmZKw6hR6/pse1uhD4OztKkdv2dvd1QbgTQ34eTkSEFdChOs 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: * Miaohe Lin [240129 21:14]: > On 2024/1/30 0:17, Liam R. Howlett wrote: > > * Miaohe Lin [240129 07:56]: > >> On 2024/1/27 18:13, Miaohe Lin wrote: > >>> On 2024/1/26 15:50, Muchun Song wrote: > >>>> > >>>> > >>>>> On Jan 26, 2024, at 04:28, Thorvald Natvig wrote: > >>>>> > >>>>> We've found what appears to be a lock issue that results in a blocked > >>>>> process somewhere in hugetlbfs for shared maps; seemingly from an > >>>>> interaction between hugetlb_vm_op_open and hugetlb_vmdelete_list. > >>>>> > >>>>> Based on some added pr_warn, we believe the following is happening: > >>>>> When hugetlb_vmdelete_list is entered from the child process, > >>>>> vma->vm_private_data is NULL, and hence hugetlb_vma_trylock_write does > >>>>> not lock, since neither __vma_shareable_lock nor __vma_private_lock > >>>>> are true. > >>>>> > >>>>> While hugetlb_vmdelete_list is executing, the parent process does > >>>>> fork(), which ends up in hugetlb_vm_op_open, which in turn allocates a > >>>>> lock for the same vma. > >>>>> > >>>>> Thus, when the hugetlb_vmdelete_list in the child reaches the end of > >>>>> the function, vma->vm_private_data is now populated, and hence > >>>>> hugetlb_vma_unlock_write tries to unlock the vma_lock, which it does > >>>>> not hold. > >>>> > >>>> Thanks for your report. ->vm_private_data was introduced since the > >>>> series [1]. So I suspect it was caused by this. But I haven't reviewed > >>>> that at that time (actually, it is a little complex in pmd sharing > >>>> case). I saw Miaohe had reviewed many of those. > >>>> > >>>> CC Miaohe, maybe he has some ideas on this. > >>>> > >>>> [1] https://lore.kernel.org/all/20220914221810.95771-7-mike.kravetz@oracle.com/T/#m2141e4bc30401a8ce490b1965b9bad74e7f791ff > >>>> > >>>> Thanks. > >>>> > >>>>> > >>>>> dmesg: > >>>>> WARNING: bad unlock balance detected! > >>>>> 6.8.0-rc1+ #24 Not tainted > >>>>> ------------------------------------- > >>>>> lock/2613 is trying to release lock (&vma_lock->rw_sema) at: > >>>>> [] hugetlb_vma_unlock_write+0x48/0x60 > >>>>> but there are no more locks to release! > >>> > >>> Thanks for your report. It seems there's a race: > >>> > >>> CPU 1 CPU 2 > >>> fork hugetlbfs_fallocate > >>> dup_mmap hugetlbfs_punch_hole > >>> i_mmap_lock_write(mapping); > >>> vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. > >>> i_mmap_unlock_write(mapping); > >>> hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem! i_mmap_lock_write(mapping); > >>> hugetlb_vmdelete_list > >>> vma_interval_tree_foreach > >>> hugetlb_vma_trylock_write -- Vma_lock is cleared. > >>> tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem! > >>> hugetlb_vma_unlock_write -- Vma_lock is assigned!!! > >>> i_mmap_unlock_write(mapping); > >>> > >>> hugetlb_dup_vma_private and hugetlb_vm_op_open are called outside i_mmap_rwsem lock. So there will be another bugs behind it. > >>> But I'm not really sure. I will take a more closed look at next week. > >> > >> > >> This can be fixed by deferring vma_interval_tree_insert_after() until vma is fully initialized. > >> But I'm not sure whether there're side effects with this patch. > >> > >> linux-UJMmTI:/home/linmiaohe/mm # git diff > >> diff --git a/kernel/fork.c b/kernel/fork.c > >> index 47ff3b35352e..2ef2711452e0 100644 > >> --- a/kernel/fork.c > >> +++ b/kernel/fork.c > >> @@ -712,21 +712,6 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, > >> } else if (anon_vma_fork(tmp, mpnt)) > >> goto fail_nomem_anon_vma_fork; > >> vm_flags_clear(tmp, VM_LOCKED_MASK); > >> - file = tmp->vm_file; > >> - if (file) { > >> - struct address_space *mapping = file->f_mapping; > >> - > >> - get_file(file); > >> - i_mmap_lock_write(mapping); > >> - if (vma_is_shared_maywrite(tmp)) > >> - mapping_allow_writable(mapping); > >> - flush_dcache_mmap_lock(mapping); > >> - /* insert tmp into the share list, just after mpnt */ > >> - vma_interval_tree_insert_after(tmp, mpnt, > >> - &mapping->i_mmap); > >> - flush_dcache_mmap_unlock(mapping); > >> - i_mmap_unlock_write(mapping); > >> - } > >> > >> /* > >> * Copy/update hugetlb private vma information. > >> @@ -747,6 +732,22 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, > >> if (tmp->vm_ops && tmp->vm_ops->open) > >> tmp->vm_ops->open(tmp); > >> > >> + file = tmp->vm_file; > >> + if (file) { > >> + struct address_space *mapping = file->f_mapping; > >> + > >> + get_file(file); > >> + i_mmap_lock_write(mapping); > >> + if (vma_is_shared_maywrite(tmp)) > >> + mapping_allow_writable(mapping); > >> + flush_dcache_mmap_lock(mapping); > >> + /* insert tmp into the share list, just after mpnt. */ > >> + vma_interval_tree_insert_after(tmp, mpnt, > >> + &mapping->i_mmap); > >> + flush_dcache_mmap_unlock(mapping); > >> + i_mmap_unlock_write(mapping); > >> + } > >> + > >> if (retval) { > >> mpnt = vma_next(&vmi); > >> goto loop_out; > >> > >> > > > > How is this possible? I thought, as specified in mm/rmap.c, that the > > hugetlbfs path would be holding the mmap lock (which is also held in the > > fork path)? > > The fork path holds the mmap lock from parent A and other childs(except first child B) while hugetlbfs path > holds the mmap lock from first child B. So the mmap lock won't help here because it comes from different mm. > Or am I miss something? You are correct. It is also in mm/rmap.c: * hugetlbfs PageHuge() take locks in this order: * hugetlb_fault_mutex (hugetlbfs specific page fault mutex) * vma_lock (hugetlb specific lock for pmd_sharing) * mapping->i_mmap_rwsem (also used for hugetlb pmd sharing) * page->flags PG_locked (lock_page) Does it make sense for hugetlb_dup_vma_private() to assert mapping->i_mmap_rwsem is locked? When is that necessary? I also think it might be safer to move the hugetlb_dup_vma_private() call up instead of the insert into the interval tree down? See the following comment from mmap.c: /* * Put into interval tree now, so instantiated pages * are visible to arm/parisc __flush_dcache_page * throughout; but we cannot insert into address * space until vma start or end is updated. */ So there may be arch dependent reasons for this order. Thanks, Liam