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 72D6FC4828F for ; Fri, 2 Feb 2024 21:02:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0903E6B0072; Fri, 2 Feb 2024 16:02:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 03FD16B0074; Fri, 2 Feb 2024 16:02:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAE0A6B0075; Fri, 2 Feb 2024 16:02:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C43406B0072 for ; Fri, 2 Feb 2024 16:02:17 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 992BB160591 for ; Fri, 2 Feb 2024 21:02:17 +0000 (UTC) X-FDA: 81748086714.13.0E7A882 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf30.hostedemail.com (Postfix) with ESMTP id 7403E80023 for ; Fri, 2 Feb 2024 21:02:13 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b="PGHW/Fjv"; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b="yA/U58Hl"; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf30.hostedemail.com: domain of jane.chu@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=jane.chu@oracle.com; dmarc=pass (policy=none) header.from=oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706907733; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=axIadLzH8kJShb8wZj39ktZ/E0Oladn7PfxI+zbJSe0=; b=Wh0TzTjPJHheVrfRG/KkKnuasg2NMC8UkOmgZDH5awkUTZ1dF0h348cyOKplztnYub2B+k thNHR1XPCegr6jL4jKaMnYExkPJfK5rglAGEZ5Nnwx6yaix5BymTS2SHbSSHxCaIpj4Li6 gImYXI0dd8FDNzoJeAeaYf9IiDGstY0= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1706907733; a=rsa-sha256; cv=pass; b=A16aC/MHeyW+GwyHZf2dKB7cbzjq5eEiZqxOCosHkQlWwju5WMKn7jWaZz7qVVuvoKGd3M 7O6zSMmtRICu9e63DMBgiFSrY+fa6a1IKGbdy1x1FthOxeX3JOs3ZtmvrawVFGdDEIY5mG wGhSpLiUUH3YcGxYmaanNhhnEpP2UiA= ARC-Authentication-Results: i=2; imf30.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b="PGHW/Fjv"; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b="yA/U58Hl"; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (imf30.hostedemail.com: domain of jane.chu@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=jane.chu@oracle.com; dmarc=pass (policy=none) header.from=oracle.com Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 412Jx3mI029135; Fri, 2 Feb 2024 21:02:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : message-id : date : subject : to : references : from : in-reply-to : mime-version; s=corp-2023-11-20; bh=axIadLzH8kJShb8wZj39ktZ/E0Oladn7PfxI+zbJSe0=; b=PGHW/FjvIjhxol5SlhkibS4pt6FVEnL+evswJA6qkxW9T8dd6vl4WZR+UNhUH1DV3g8P TjsvSXYw2BIkR1yZZTGkj0C3GOV/dVJqUetvIosIiZwjdT/yZJJYtJP/niioY3cOQ/DL zkOHX3tz1kVtcUYlANv2vlRUf9VQf7GRDR6mECNamQ+j5cWGXPU0J4UNxWdN0hVNDU24 wRcT4l2uFgmhSZkkGEk2AIQgzlTfWcorGfoggVBMjkqAEAFxyxkkoBloETymyq6bJw74 idltN2MzjYgEgRzCMtFxn17ZgTktOgbGhuPGDRh9vNSqkbRPzHXjhBPw4zdwIJq+KkNO 8g== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3vvseurj9x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Feb 2024 21:02:06 +0000 Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 412JKmMJ012086; Fri, 2 Feb 2024 21:02:05 GMT Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2168.outbound.protection.outlook.com [104.47.55.168]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3vvr9cxj9c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Feb 2024 21:02:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fYJmHVyX7sHIUVuQsCBp6rV/Ia9YiETJrmFKu2eH7zO1DdtTWlBtqGdVmFLC6TGze3Cc8VC1CepjIbfR0y0kWgeYEBW2JSp/Zi2EgV7h/ie+RMd1eeh2VBO/ooMl5FHnX8eUfoaEZHAIfZZwhz366YPfTJwiv0703punnZhURhqnBDduB882OU7UC8PqDpmOR4/80e5bmxmnmEkbg1nrOY8f888G1Yx7dW/hPlJHPb6IDL4eP8iLX/ciEtY6XkU16igbQHm7OMNr0RI0LA+SVN+qRRzJDM1d5ZyTjZx7M9rTvwK64TiTuOz3m2Uc0o8Izxq5/z3/LJ6UEw4Fy2Iv+g== 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=axIadLzH8kJShb8wZj39ktZ/E0Oladn7PfxI+zbJSe0=; b=h5dfJlJviNnlhOrUtHTCwRGG0iWK7Qc5sb2DJMavEGBNbqxR/Bg02cH1gHfbUKupzFoM30FPpeObgGmACC9m50+aW6p50Ix36mSpieI4OTCkzAottXKcNthC9cjlnhEX0aj9JKRz4RS5QNyBFnXFBszO90u6DmR+kr7bbpd8o9I/75DifwZA0TndGnCVCFTtV5hi1Y1GjmS50NqVhMCwtRykTxssddSNBto4W2eAK9OpS1uJLPTOfW6fWz5VAg/28MS2Tg5wIj9fPczu6U4rYhhsB2XgSA/HckL6MmuCudqprGf/lGerSBoj/IJd8HMcssAtYmgblhU3ctjEq2TqMg== 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=axIadLzH8kJShb8wZj39ktZ/E0Oladn7PfxI+zbJSe0=; b=yA/U58HlMPAbBqcsLt7/eA1n1E+PUvRyjN7VdKUHldEgFNAT4G4EsFeaNmu8shmi9RAp0oGUFHt1KTpv8+WpMRkClAJXCyCqQllIWydWVkPK/RYGooU2koGjhyPY+vodzQYjWro3//231Yo+n7T+pxa3cZGGocLQjCXCwkp+0k0= Received: from SJ0PR10MB4429.namprd10.prod.outlook.com (2603:10b6:a03:2d1::14) by CY8PR10MB7243.namprd10.prod.outlook.com (2603:10b6:930:7c::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.30; Fri, 2 Feb 2024 21:02:02 +0000 Received: from SJ0PR10MB4429.namprd10.prod.outlook.com ([fe80::210e:eea7:3142:6088]) by SJ0PR10MB4429.namprd10.prod.outlook.com ([fe80::210e:eea7:3142:6088%5]) with mapi id 15.20.7249.025; Fri, 2 Feb 2024 21:02:02 +0000 Content-Type: multipart/alternative; boundary="------------G4Wun7KSPOIyNZkDKemOaKXU" Message-ID: <70f13c9f-4364-4154-9b5c-69d6c5e9d65a@oracle.com> Date: Fri, 2 Feb 2024 13:02:00 -0800 User-Agent: Mozilla Thunderbird Subject: Re: hugetlbfs: WARNING: bad unlock balance detected during MADV_REMOVE Content-Language: en-US To: Miaohe Lin , "Liam R. Howlett" , 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> <20240130040814.hd3edkda5rbsxru7@revolver> From: Jane Chu In-Reply-To: X-ClientProxiedBy: SJ0PR03CA0252.namprd03.prod.outlook.com (2603:10b6:a03:3a0::17) To SJ0PR10MB4429.namprd10.prod.outlook.com (2603:10b6:a03:2d1::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ0PR10MB4429:EE_|CY8PR10MB7243:EE_ X-MS-Office365-Filtering-Correlation-Id: 028dd684-a92e-4712-1f0b-08dc24323435 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rREWi/l1OFDAeswGpJcTN3ZqeSVXmEv4J+25g6G1o/FCVRx1pGGR44UVni/KK/oa/oP22z/X8r9MQh4uizomAUcWNjvak4vkkTmDdYLymVCedKjzaSM+5imVCmzh8CYcFwRL31gfWTwHPsk6HVjaEl35LbmoZ7IyPzNRxBkbHW9iLPe/chDQTI6InUJ+x8hYeVDb6KbOrgRQ1SxUCxgwRSwGR2+GXhaB8GMXw/A7OhpMY7tE9nUyCOZSFQuhQs1jBiLMYJRUJwv8I7/qLFclujqV4K+NI4Z55e2fRJPnmGeNmC0OR+E7AOqU943o95HNRzlDkfKs9N/z+IaYSvwItjs84jxrrV7hKMVktHfDf4ImfOrgP7n9NUVUKRYh6CRP8OGlzhy8n6LqCKJwvuHYuo64CUsmoowS0st2Vky13+ftcSKY8ty0BCjRAzy4w6O79WRvf0XqXt47JxZgJ5AubfzMe5dP2CWyVD7mPFvwru9ymcRkG1+dBJWtAUwH5FZ5kOb0dne9RuchtPIpwyers3GGEKGjaOUnpDnLOFcgjllUBOqXrqL7IVWoeP8Z4f2+gP3QZSl0CP/fGZsgXCQugZ11PCr4cFeYisX8Uu1GJHMKJESgEysHPqkS9alZuIzMC1mEojwG5ssGotfRNLkEGA== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ0PR10MB4429.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(39860400002)(346002)(376002)(396003)(366004)(136003)(230273577357003)(230922051799003)(451199024)(1800799012)(186009)(64100799003)(38100700002)(31686004)(33964004)(6506007)(53546011)(166002)(83380400001)(2616005)(8676002)(6512007)(30864003)(44832011)(86362001)(31696002)(36756003)(316002)(8936002)(2906002)(66556008)(66476007)(66946007)(110136005)(966005)(6486002)(26005)(478600001)(41300700001)(5660300002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UGpLaU9lczZXR2Z3ZSt2SFNHSytHRkNpUDA1Skdtazl2QzdTOVdwYzVLeGpl?= =?utf-8?B?Vkk5Q2RkaGY5cXl3TFdlRS9ocWJSM3FseW9Ra040R1NSdEpSdGllOHA3YmtC?= =?utf-8?B?eEI5Sm4vZzNnR24zR1dEYXVyZzNabGFWOXJtWlUwYmViVlZSOTZoS1pQMzcz?= =?utf-8?B?dGt2eGhiZDY5STdYY2JkdTEyQi8rZy9JRUVPOXBSaXA0OVplS2htdjFBak5K?= =?utf-8?B?T1lsblBIMWdrV3Z3YXdxcWFzZ0tPSWdLb0RycWozeVM4NHMvdyttWmpNVXVh?= =?utf-8?B?K09HM1BhaGZmR0dsaVdkNFR0aElJaUpJQWpKYnVSR3ZRWXFOMktlRkpZbmRi?= =?utf-8?B?U01uUE5xaDhOcmtxU1hSbHMxK1NKaXJ4ajZMMytxbnlHSTQzV0p0TE5Vb0lv?= =?utf-8?B?NCtKME1pVkx0czdMcXcwVDdFRnRjMlU5em9TRTh5di8rVm00MUNaUWZQSml4?= =?utf-8?B?cDFJNm5DUnkrNGIrU0l5VVFMNkQrdWJXZ2d1YVd4K0ZvMDJWTkp5LzZzTDBG?= =?utf-8?B?NCtQWTlpaXdNem9nWWRDUWtzZ0lsVDhWY1MxTlV2VzQ4NDVjZnZtOXhIZkZo?= =?utf-8?B?akxiaTZuYktmMUhPSlVVc1hqMENiQVVENG91eVh6T2c5QXdpblNZMFptNmhN?= =?utf-8?B?TmkzcE53cWJFY0pSMkozZUN3MUJpU3NOckZmVVlqOFRwbmFFcno5L3QxRzNl?= =?utf-8?B?b29LYmcvUkhMeUNiYUhSY2d0ZHV0RU8vRzZhTDJnTWN6VkpYM2xQMnRGT2ZY?= =?utf-8?B?UTg3MFJyanRGQXNOdHc4VExwYjRFZXVZQStCeUxtc2VCbGJzWDZNbHorY1Qx?= =?utf-8?B?WnpHQzVUNWk4VTZKT1lWcEhBSkx4ekIzKy8vZkI2SlZRdlhmbW1kaWFZMjhG?= =?utf-8?B?eGc5ano0aGtTbFp2MGZWRnR4K3JseDZKRXY1VzhDZ2tyY2UrVklUY04xSUU0?= =?utf-8?B?bDlLUWU1K0RQYytyRENjaUloMUxKZ3dka290MzVZYlpLMG1BQm5iY0tWOTVr?= =?utf-8?B?Vkl4VjJpWEljdFlsUS9GNzNpNHpaQlJnZCthZWtUbXk1VGVxTkhKT1VZWHpu?= =?utf-8?B?a0FRYXlOcHVSeTd3dW4zbU9WeEpIR2FRS0EvL1NrQkZIYndmeDcyN2QvU0Zw?= =?utf-8?B?eEQxTFhzL2wrVUt3MUJLbzFiU0V6Zk1oSFpHeGp4NklwZnBFMHhqMkQ1Z1BN?= =?utf-8?B?dGk4VnZVYmpVNnkzNFMvdlNQWG1kQ2pISU9Jd3FGMmpsZlZQUzhYZmdKVitG?= =?utf-8?B?MEFEWFlzdUpsVTdvNkdybldHL3A0NytYK29PNEVhc2NGaE04eVR1dWR3Q3FM?= =?utf-8?B?eUNCSEJZaUYzWHhla1Y4YkJXQzJzNk9JeDhuRTVOQ1E1TGQxZVFHYmRwc2VL?= =?utf-8?B?ek5nOFVDdklNMFZTMFgwRzQyTy85YmpSNE11UUh3UmE4TlVTbG1kQ2hzZjJy?= =?utf-8?B?RkJ3ZjNjdm1sdU1wL0FLbDZZa3YxNzlGRUVGVVcxbUpTK1V0Q1V4REZoN1lR?= =?utf-8?B?TnVqb0RQeHJPblRnQ0Z2TzhHR2V2aXVIdXVCQ0dpUUlIZEdGQTZ1REJOWVVn?= =?utf-8?B?QnRtYnhLbms5VTdOK0pHZEVFWWdhQi8rdkI2QzJja0NiOGtKcGdjK0xyTVls?= =?utf-8?B?VTZkanBzTk9Vemt5Z0NRYkRja05oWUt0YXk5bjlsZFF0NURYTXh4NFBYU0RJ?= =?utf-8?B?Mm93bVZNZm1nZ25ZVzc0YWxFV1c0ZXR4K3VvQldyZk9DUVpEMzJ6WFZQWkR6?= =?utf-8?B?dnp2Q3d1RllsY1dDZ1VzR1VHZXowNlFkNll4N0lvMFFiT3lWSjNucjhLSGNX?= =?utf-8?B?QXdidXRuVmtTcytndXFuTitXdTllazRMR2hZajNjRlVPbUQ5Vjg4dW1YQXYv?= =?utf-8?B?MG1HTnpPSTNnS3pOMFhiS3c2VUtpNytSeUNuVWVPS2dBNHFrSWVWRVJVZWpn?= =?utf-8?B?YklXb3pIUGZhNEFvaVhmMW4xT1lXMi80Y0NoRHFZdzBTNVRRS3ZINnppRFhO?= =?utf-8?B?WjZxdy82cXQ1NDRYQWZXMk9RTWdoODVFaDFDclJWVG82dklpUXdBZmRKRkkx?= =?utf-8?B?QkVIdHU3S01XL2ZmMFhUQXYweC9sRmVOdlZtdUQ5SWJtWVlvVjhNcCtCa1JZ?= =?utf-8?Q?9owwuwn/mw4XzTQ3M6t+n+QiH?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: NTuLsfQuXw9dQK34+8CGVVKZKr3fsFQqqoeMKO4lJXAWjE4+NHhsg5veeMZU7YASA7MB60A6O4DRTo1I7eRaP4ISJKlGLnqCP4Wtjcw1JgO/dpTw1TYANwrQvQXG5MgGITIL1V+g8ELJFuS3yRxqZXLBWYI0JjDn3WR4/pNIA8XM7IkwU9FDvzE2qoB497DM608JUKZxN3yVPeyk82/RsD5U6xeCZNQtrxaTeI9xIZZMBGfYcYpsZ+zw00hkvnPOPOoMQoWZcc8yQwiDT1otZoGhm4GnnWZqRifMa4GFJa1I63ZrZYGZ5fH1aS1v6vRN7ZKjpBoZMKwyzlg+4kV5U/Lvo/c+PAPlPjLCEUcdWId9pz9xl3TH7UItMubmXNaXO41cuFAN9K+D3F4S1bK/EXuR/R9nqG1G8C0StPgM4d5iyNTX4of8R5miw/bXuRWoq0rnKu/IISWAI32PiByIbsJ2hzPwxn/DyRRjRfPLK8s95OTvz7VvqfclstMKRijbvLNHSUB5q3Fnjwy+Qlt2B41i2++ITmTqpkd65rDHsniowoUal58hSTdp3bNTWrkqew4PiQpK+OoaxVSYEiOml9KqDngrN8CvYShH05d4Q9I= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 028dd684-a92e-4712-1f0b-08dc24323435 X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB4429.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2024 21:02:02.4520 (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: 9B3ieIRXT4iVV6DEArTKf51Sm+U8fINxVTTTa7rGE1QH8sPU3XBDwinA40kOJxNL9li2xlJuzeVfq4yWOOQcsA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB7243 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-02-02_14,2024-01-31_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 mlxscore=0 spamscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2402020154 X-Proofpoint-ORIG-GUID: sz-DEJDKduTF04vAtTWv4sknDPVPuC4m X-Proofpoint-GUID: sz-DEJDKduTF04vAtTWv4sknDPVPuC4m X-Stat-Signature: bujw1yxuj8rs37mcjkqp6fhsir73onj1 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 7403E80023 X-Rspam-User: X-HE-Tag: 1706907733-872293 X-HE-Meta: U2FsdGVkX1/ou9wn2hLu+blV+FEmZPEejylK/mBUApN3IRNOKgh8MfHWXrcF/wj8T/VbHeyEsYqVPBJ/FfLPzgzsQ4Gx3XjaoCdTogTcnW/tC3RN4lQmakpO7pmRm1E4HjP76NZP0tuR52yN+KECUKGh4JIDjUQ8vgzd9VmPzvpSj1YYYdZci/DEWXMsIpd68h/bKjhnjj+ax/HXv5e3g0UcTecaDWIhnm7dWkuFOKn2XLI9EExBwGDTOAtgcWXahSI60ZwWRnHs5O5GLxwUJe9IYHz31AutCil0I41Foqv8/SeX8jI/eIMfxV3C4KEnviU0QSO+794mLuSTixtZ3sSHrGZb/f7t4URwbBN/61Qu6MwfoefIVnZZjtIzUR1Phb78yGfk1ywxeGGPaaLJm7GMVKRhX0MLK9wOMs0bQNn/Ygro30as/bNVWqGPAu0H/w87IWbofpfO70ZyklFPkzJPkhUi4hdr6jbYvimxqrXOQUXC2WXtZn5dwlGLr90sdfhuur1ohxCNi8ZWIEHqmUtzlfVBybk0+ZYEi/yr36dqLWlHMbCSCRymzWzAdESkgVLOm7f9K7z+13w55/sxfRSoMEq/4UH6dlXIb9CdEnMFcqSUz3ICkocfVz4qwPTpfgpuXera8ET07k7gY/lmnncGF+4W0CsRreVp6SLucHvQ8ad6mB/sUe1EqDLXspV98RIsvvS7HgPyosNTWBRGyU7C5knZfk0JGvPRp34RA8EfogZoHuCVZiv+Wsyb4qv+kLZsV2/Q+qonfd9prhjhinYTUJW+JYtS5M/FR3K/ZeaphZzgra4bsom6VH7GzYWOs3kJy6ty+NoVNHTJbE+tqalhQRiXE5lkcH3nTkuV1xtbuP0upAfzvfv82xHwdY/9qPFVLeBtyY2gd22FP4HNEW0QQVtzh1wnMHjwlpMx0Skx1DKpf+jegtBdkivi718iPoKo/NG0InLKyOuFirk 4sEQExIR dBBKayukrDZOL1g7CsRcUoOr/XblgQasD8QggkAp5cVvEmBxrvrLhfA/aoA9paZQJikcQKLojMwNbFJtDzqIA8P4hne+8anDGQ47se7CwxHX1zpd/ljyJIIFQUT25kWkN7+IKpnMBYNNPsFignqpcPiGHoAHBep+CqdPSzK0lrSoXYbsYKqh2Babp6UqTyWJQXSrvH39u7ksTLrOZnS1HjitVeFDoIEAl/NLF8rYL0sck0tx0+BDcA2exIIfxgfq/e46VTZJ12qMgkgFvq+iuKHm3CN9VZRU1zM1IApyMzZCLMuTRjJGbU1jkU69U5Lw4fqQTXbJ4MX3aTteOjT0d8kI7OPDytYI5vfqxuBbW+cn4CnJdSyllOEFrL4nXdWUBZdBba0iUSrzUakdigrpDG6sPDTSF9Kb54WchcadY5pHbhMfr1E5Gw8SWFrqCkdsLcLQ7goh/4+g17cd89SWSyrDJsLy0x7/zTT1E8ZHX3xW4zkuqAcTGnJjMNE4CCKX68qZ0UbLVlcc201pP2ZHb7xLXZOiM4zL6GRqQkiy6VIDTrXHPa1ZGSLnUTO53AZqCI6puDHqVdBHzUkp3s+pZAkvdm6WmaOxgT7MaZ5N1Tp/bl1SVT2T47N7xQTT9BZvR5INuQD6P++bjbgYPtNLd4+Qh46/v7pwFdO+XwqqIWT/1shBe/sXJDxhzcT7EVLCvyR9XlxRbyr3VK3RqOHU1gJC5fKn+ufR2bE/dq/l45r0+qV4jAQJysjUO+Ad8RCCISZ36XaumcYU9LDk= 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: --------------G4Wun7KSPOIyNZkDKemOaKXU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/30/2024 10:51 PM, Miaohe Lin wrote: > On 2024/1/30 12:08, Liam R. Howlett wrote: >> * 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'm afraid not. AFAICS, vma_lock(vma->vm_private_data) is only modified at the time of > vma creating or destroy. Vma_lock is not supposed to be used at that time. > >> 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. > Yes, it should be safer to move hugetlb_dup_vma_private() call up. But we also need to move tmp->vm_ops->open(tmp) call up. > Or the race still exists: > > CPU 1 CPU 2 > fork hugetlbfs_fallocate > dup_mmap hugetlbfs_punch_hole > hugetlb_dup_vma_private -- Clear vma_lock. <-- it is moved up. > i_mmap_lock_write(mapping); > vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. > i_mmap_unlock_write(mapping); > i_mmap_lock_write(mapping); > hugetlb_vmdelete_list > vma_interval_tree_foreach > hugetlb_vma_trylock_write -- Vma_lock is already 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); > > > My patch should not be a complete solution. It's used to prove and fix the race quickly. It's very great if you or > someone else can provide a better and safer solution. But,  your patch has already moved the vma_interval_tree_insert_after() block after the tmp->vm_ops->open(tmp) call, right? Hence, there should be no more race with truncation? thanks, -jane > > Thanks. > >> Thanks, >> Liam >> >> . >> > --------------G4Wun7KSPOIyNZkDKemOaKXU Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 1/30/2024 10:51 PM, Miaohe Lin wrote:

On 2024/1/30 12:08, Liam R. Howlett wrote:

* Miaohe Lin <linmiaohe@huawei.com> [240129 21:14]:

On 2024/1/30 0:17, Liam R. Howlett wrote:

* Miaohe Lin <linmiaohe@huawei.com> [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 <thorvald@google.com> 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:
[<ffffffffa94c6128>] 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'm afraid not. AFAICS, vma_lock(vma->vm_private_data) is only modified at the time of
vma creating or destroy. Vma_lock is not supposed to be used at that time.


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.

Yes, it should be safer to move hugetlb_dup_vma_private() call up. But we also need to move tmp->vm_ops->open(tmp) call up.
Or the race still exists:

 CPU 1											CPU 2
 fork											hugetlbfs_fallocate
  dup_mmap										 hugetlbfs_punch_hole
   hugetlb_dup_vma_private -- Clear vma_lock.	<-- it is moved up.
   i_mmap_lock_write(mapping);								
   vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree.
   i_mmap_unlock_write(mapping);
   		 									 i_mmap_lock_write(mapping);
   											 hugetlb_vmdelete_list
											  vma_interval_tree_foreach
											   hugetlb_vma_trylock_write -- Vma_lock is already 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);


My patch should not be a complete solution. It's used to prove and fix the race quickly. It's very great if you or
someone else can provide a better and safer solution.

But,  your patch has already moved the  vma_interval_tree_insert_after() block after the

tmp->vm_ops->open(tmp) call, right?  Hence, there should be no more race with truncation?

thanks,
-jane




Thanks.


Thanks,
Liam

.
--------------G4Wun7KSPOIyNZkDKemOaKXU--