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 02D01E7719D for ; Fri, 10 Jan 2025 15:23:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A1668D0003; Fri, 10 Jan 2025 10:23:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0520C8D0001; Fri, 10 Jan 2025 10:23:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D97B48D0003; Fri, 10 Jan 2025 10:23:24 -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 ACB988D0001 for ; Fri, 10 Jan 2025 10:23:24 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 43F33C0BB9 for ; Fri, 10 Jan 2025 15:23:24 +0000 (UTC) X-FDA: 82991911128.25.21D5173 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf11.hostedemail.com (Postfix) with ESMTP id A726040003 for ; Fri, 10 Jan 2025 15:23:20 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=GIkfbvlH; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=NI3DueOR; spf=pass (imf11.hostedemail.com: domain of steven.sistare@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=steven.sistare@oracle.com; dmarc=pass (policy=reject) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736522600; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nPrgAGHi7dLjHgXB66jWm2Fgr5rOXem/X1ayHaXexok=; b=j+CQMKIr/A1Uz9HG1+vjUj+VHwEtsVTbaU/wdPUEY7XD4SW7Fhs4QkcZKgWQFAYqTwVAW+ C1yzXdTornQULUTMs1/UWCQhHswmSx6jQyFye4VtD7+t29gzslgTNtdmOWPGKuolxXOf8i dKfDWfP17R4cl4XfzQrCH4Q63TWh7bE= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1736522600; a=rsa-sha256; cv=pass; b=dZG4AXXKw6YY2O01bKWSIxruWK8p63l95WuXtFCagN9114KG+429/r+ctQLwaX+0R/Edp8 Xm/DkF7NvrQ6TOF+b9MAFX+4SYQ8Y/l2DAIiUK8V9I9AJAnjFNqttWBqLt+Sp5t9MwvcqL WfK1WIGdn4r+SCoI1nxOe+uWXtGne1k= ARC-Authentication-Results: i=2; imf11.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=GIkfbvlH; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=NI3DueOR; spf=pass (imf11.hostedemail.com: domain of steven.sistare@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=steven.sistare@oracle.com; dmarc=pass (policy=reject) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 50AENWxK029359; Fri, 10 Jan 2025 15:23:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s= corp-2023-11-20; bh=nPrgAGHi7dLjHgXB66jWm2Fgr5rOXem/X1ayHaXexok=; b= GIkfbvlHA4lfDPqfalNJeh2GGZa4troBqQgoC6epLfFrfL9Tmpu/okdvK/bgf2cl pu6m3FCW38kBJiJhqCSoyJeFNOgtVmOgnfoM8IniE0W+VsnaqlTraHG3YL3VYTz5 FjW1pv8anJLaK/SUU2H52JGtlVUqwYEAyphQplvuGB23z84Jrwtdt4kwaMO6VDLb rrfdvYgIU4apNl6T0cWqcFcUo/pTGKnC7egz0mxTeKktHDfn5rDFL9kkZT9asbiI otwsB/UuNzpXQrlciF6w57ZSff7bZKvydE6yaeUCW+i6obFVacHy8AaH0na7V1mt lhLqpqZS0HYclGSW/lf2aQ== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43xuk0bfrr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Jan 2025 15:23:17 +0000 (GMT) Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 50ADRjoX010893; Fri, 10 Jan 2025 15:23:16 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2047.outbound.protection.outlook.com [104.47.66.47]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43xuecdux3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Jan 2025 15:23:16 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YK6xwKVdak9j2Jc7Z4L991JBkGqvf+liYOq6971TkMvWf1EpTVQ9AKJMHC930+4N/lvgwZonrSZshFvgnBmiifKBPQXD6JtJ7GBrVy/87RrGhZqrb8/uqndCobbsa2xlHdy0Hmh1TMTXUCC1gs6TVW64tHh15Jp1eZQ7x3hwoqLq7q0vwnwOWkqzQ54rtS0Ozs4tLkCwPxg5Ej9VgSINHJZshDGAVaOb/QnVKRrR8jh0xBnGxNGjN96KLTd/yDSg8SXk9ZF0m9AL0gu9nDJRjgpOxZkh69REItXqxO9vsAouZNI1IC7GojiMxQh7JVXA1anICrXKxGKhe18SIZB4IA== 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=nPrgAGHi7dLjHgXB66jWm2Fgr5rOXem/X1ayHaXexok=; b=seXXlnmAVYb1RAYDy80Fg4j8ZPZb4mBNtz+OPVs1U8by67yCjOg1izbubocwyaUZU/JykJjSaBMLup2a4Jyvku4icxcgqcJaokmTi7Q5BlrbBrtHYyxBBv2+j94e/cHSaGuLPoe1NCWqIF6ijTsWiN8HtxHTZpR6oOw2UMe58sPkoHA3kJ26bZ5SFW083srLHbYndZU4GfgRWJ3v97n0sPMogSIgctD4bcMxSy4xszFzGvvagdLh7bth/dNLVHdQxJGjQsKxvwKU1orkllPESjD+tqPwMWLeWAd5BwWASgUJy5ubkwLFkE9Chd53wyYcjQJqyT3G1aOhb8TAlUYElA== 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=nPrgAGHi7dLjHgXB66jWm2Fgr5rOXem/X1ayHaXexok=; b=NI3DueORhaQrGJQIF9RCA+GTqGETc9HWDp7HHKt9/WkZK+LTcSo1JwzrCVAIdKT3+2zVPVSIrb7PbdLUfYOWdvUNoY+g7gTdG2Kx3ryVfwMFksOlBmIx71FfFvTR71U2kcGO+DdWZ00SOK3g3fq2f1WKDMgzMCbDtQ6apCFmBic= Received: from IA1PR10MB7447.namprd10.prod.outlook.com (2603:10b6:208:44c::10) by CY8PR10MB6826.namprd10.prod.outlook.com (2603:10b6:930:9d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.12; Fri, 10 Jan 2025 15:22:49 +0000 Received: from IA1PR10MB7447.namprd10.prod.outlook.com ([fe80::f2fe:d6c6:70c4:4572]) by IA1PR10MB7447.namprd10.prod.outlook.com ([fe80::f2fe:d6c6:70c4:4572%3]) with mapi id 15.20.8335.012; Fri, 10 Jan 2025 15:22:49 +0000 Message-ID: <2b428c92-8953-45cf-be48-b73f8efc9261@oracle.com> Date: Fri, 10 Jan 2025 10:22:47 -0500 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/memfd: reserve hugetlb folios before allocation To: "Kasireddy, Vivek" , "linux-mm@kvack.org" Cc: "syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com" , Muchun Song , David Hildenbrand , Andrew Morton References: <20250107072517.2089633-1-vivek.kasireddy@intel.com> <12795c8f-11b6-4e31-aa1e-b3b4d3108c53@oracle.com> <7631067f-0a5f-4ba5-b630-d434a3ed2f72@oracle.com> Content-Language: en-US From: Steven Sistare In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: BN9PR03CA0483.namprd03.prod.outlook.com (2603:10b6:408:130::8) To IA1PR10MB7447.namprd10.prod.outlook.com (2603:10b6:208:44c::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA1PR10MB7447:EE_|CY8PR10MB6826:EE_ X-MS-Office365-Filtering-Correlation-Id: 19e39b46-33b6-4a97-a659-08dd318aa4b5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?UGJvVUphcFRtT3lSOUN1eklXUTdKait2S3BUVys3eTlCUjJsQk9iRlk0ZlRR?= =?utf-8?B?MFMyamxmVHp0WTRaTHZzRG9iTTZ0VWdRQmZGYytvejZQb0YxNVE0N0x4dytB?= =?utf-8?B?QlZjUkdmL3NpUElsNTdoNUNqT05BVHRkeEhhM3hhMDd5M2ltZjNZQ3ZVV1RJ?= =?utf-8?B?RVVWcC9TQ2N3aEFsYWs2K2xrbWNpSnhYTHpOMUVUYk1BNHZKTkJFa1p2TUc1?= =?utf-8?B?eXA2clp6L3pUZXY2ZEl4OFFQZWZqUkJZQm9qc1VnOWNxckdTVkgxSjQ3U0tr?= =?utf-8?B?MytUUm05cWFOdlZ1bGZNSTBOVzF0ZDUzOFRvd05Qb3NEU1BmN3laVEUzYlJy?= =?utf-8?B?Q2NoUnJxaWNsUmk1NHl2eEZNd1ZqZmt4VVlsY1JHQmRyOHJLLzQvVjE1enpI?= =?utf-8?B?N3BwaXlvdmhyZTV4TGcyT0VOSFVEb2ZEdHpGOEpHdTlMWWJyTUxyUkljSnN3?= =?utf-8?B?OXlrTHRQRXNkSGJJTmhINkF1OUtGOVN2QmVqTDVnOGJSd2lDOTFJeWR6Q0c2?= =?utf-8?B?TXZ4aGI3aDE0a1cxQjJMS0VpZ1dOejRBNC9tWDgyZzNVSGNOdVFkdmdPY2FO?= =?utf-8?B?REhYZE1CSS90QTA1SVpydVF4VnZPL0srLzZ5SFdRWDZ3T1BmK05QT29OcHk2?= =?utf-8?B?MGdZSC9CZ0llZHlCWVF2UUoxS0RMQXBCRkdYSDdISHViQ0d5OHVWK2w0NjJI?= =?utf-8?B?MDJ0TVlxaldWWUhhUk9XeFFvZjM5LzVNdDlSaFJiQS9YTlVVS1NoS29uR0s1?= =?utf-8?B?VHVGaUREK0dBdWV6V3pEYm5RK0xLN0MvQmVxMWJQUXZDSktDOUZqMVVvWWpE?= =?utf-8?B?N2FMTFZmcm50ZGFxNG5MUWpleE1qTnlCdlRDbFVPakJjTGprWVk5SWp6STJE?= =?utf-8?B?bjJSNmVySldzWFFVM0xhVGFON1k4eTc4NThVc2VRek03bVZ1V1lzQ0o4MitJ?= =?utf-8?B?Y2IzUDdzV0k1U1N5UGU3SHRMZTJTeEN1aHhZSlptM2hmOEVDR3dSUlJCWEN3?= =?utf-8?B?NDMrL1p5dEZvU0huK2RjZHdiTEhRUk9IMlFkTmQ0a2t0ZmNrdjdZb0hoR1VE?= =?utf-8?B?L3ozWFJ3WG0rak9MV1c5aEU2T1R4K05FckhwMWNrNU9TbnBmV0dKZmpjTVVv?= =?utf-8?B?VHpUSERJZ2tmU2RRS3JKZzZUREMvaThZeE9UbzdwMHlSK0pGR2VnbFNtblY0?= =?utf-8?B?SmpNT2tJODNVTnVOT2ZzTDBxU0Q2MkRFYXJ5c2xNT0NKcjRDaU0rdWEwbDVU?= =?utf-8?B?WUtTMytUenFPblp5V2ZmRW0xaVVtN3BTZzFYRGlMZ2RmU2toeXIvaE9pOEFq?= =?utf-8?B?TEtJMDlwN0NGUXd0WW05aWtRSldYaFZyVHJURnVxaFNhN2VIelUrSGR4aDZZ?= =?utf-8?B?ZUV6NDlWaFJ3MHlmZG9pYTVZS0gyaXR6aGdCeU9XWjVaNDJ3Zm1BNG8waERD?= =?utf-8?B?bEpmQ3k0d0p2L1B6VmhPNEdrb1RiZkNxbDdvdHc4MXhwM0lFU0ZOZFQ5bUJU?= =?utf-8?B?L2ZmbTFkZjkvNDZKQ1NzZEVVRlRVV21qMTBQV0JTYkxFT0cvMlJrWGs2RlBo?= =?utf-8?B?YjMxd0Z0dnArdkhUYWlwMzZVbnNjTXdUMCtVWHBpVW9pa0RMaFEwZkQxenJJ?= =?utf-8?B?U1ZRYXd0bUxqMDBOYTlVd1JhQk1lS0JOM3lEN0tMTjBic0JmVnQ1dTNMd3N6?= =?utf-8?B?Ums1K0p3dS9waDAxS0lFTm1BZkhLKzN3SXREKzgvMjgrSzZEMGV3WVhqdnd6?= =?utf-8?B?cE9XWnQrdzk4cHFiYW9RMHM3a25YbGk3aTVoOTI5WmdNVUNqYThMRTR6UTl4?= =?utf-8?B?Rzd3WjJkbDFyNEVsU1dnUEE0czlkNGVTVEUxNHBiZ3RkWlVBOFhRdkNqYkJr?= =?utf-8?Q?89nVwhtJTN40m?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA1PR10MB7447.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TDY0VlA5d3kwTUlLeUE3SGNBUlpDU3AydEtGYW1tRFpaa0k2dmtqT1JiVzF5?= =?utf-8?B?b0YyTjkyREllN0RyQ0tsWlhZN1V2S0o4UzhUSlBWUmRuaFNyMXBkcW1KYjgz?= =?utf-8?B?NTBIMDJkalFreHJET2IyaEYzQ25DVDhVL2RyTkFUZGxxbVMybUhtcnBFLzcz?= =?utf-8?B?bVA3YXR3V216a2VtL3BTaEhYL1JCNGFYYWtqS0FCK0V6TmYxMGhPNkJPQmpS?= =?utf-8?B?emJhV0czN1pWR3VOM2hKSXc5dzFOVnN1M0J4OU5uK3FSN3FTbDhhL3NIUEho?= =?utf-8?B?VkFuQWUxN1B5Nmx0Vk51eVV2QlpheCtONFVlZW1qTTVmTitLUXB2RzZUcUlr?= =?utf-8?B?dUhEeG1xN3J4aXZaT0x4SGRMakRrQURQR0JSSjQ0UkJNU25Jck41L01nMUFT?= =?utf-8?B?Nm92dFpKRUtoZDRDQXhBZ29QMzIwOE83QW9TNzNlNitKTWlWWVpzT3RlZnBS?= =?utf-8?B?bU5uN1VVY1lORE54VjlVbjhEb0lRa0NKbGkzQzZjKzI2aHU0QU5HL0VSbksz?= =?utf-8?B?dDdpYm10WjJKT1VwdERNVW5yU0R0a1pKUitSaGp4dTV3RnhrOG1BR0hJVzZo?= =?utf-8?B?NlhkcW95TFoxK0h5UUROZ0c3a1lGWDBaUlY3VEl4V1NROUxpTXlqa1NRNmRX?= =?utf-8?B?V3IvZUR1YnZKM0Npd21KSHRUVlhWakN1L0dhbmg3d25JdUR5bVRMRlhCN3N2?= =?utf-8?B?WHU4bklaWFdnaXQ1c3VKMkp0VjB5R2hqYUl0WDVlVm5aVURlZXlEYjJSWXNw?= =?utf-8?B?Q1RoLzE4NDByTEV5aTRzMUVJcUs0cHhJNEZ2eGJrTEIxRGJpZlVYODhPREQv?= =?utf-8?B?ZDd2akV5R2JiNkIvK24vamZpYzhlb0pnanRMd2xCNjgxL2VvOS9oMXJjSnlJ?= =?utf-8?B?alpxM0FjRTM3dXhEdm9xK2xVbURJNVpsclUrUFEwSG5ldlhnTUIrMUNiTFVk?= =?utf-8?B?UXZ2MWVQNi9KVkFVdlpISlVEM2ZRdENabEEvYThQQ1I2UDUzRzFISFNFZjlr?= =?utf-8?B?UjloeFRVcm56QTZMYUtwMzM2azYzYnpxODREZk1waHJBZWpCUzc5NXBHalBy?= =?utf-8?B?ZCtEZFJlQ3l0eVVxa0JLWkNGNzNmcVpmdnUycFVDcUk4Y2JTa2dtQWlVQWJB?= =?utf-8?B?MTNud1UzalMvenQxZTBxazNxU0JIWFhJNTNZY01CUEZkQmQ5VzZ1RDdtRFVo?= =?utf-8?B?TEIyQzdpSk80YmQrUm9TbVE3WGduTDA3UFVYSzBUU0xvS29rU2E0WEdBY09S?= =?utf-8?B?NU90YVpEZzF5MmVkUkh0V0pyRm1DK1hZYkIyQ2ozNUk5MUlzc2FBS3RISmNy?= =?utf-8?B?bE5DZnoySmdpOEJ0Yy9HYk5vM1JsblBlUGh5QlpCbUFZVXBqZTJSR2J5cGtG?= =?utf-8?B?b29hcU9kcWpMNWwxZGJWRUtNMTdWTC8zL3FZbDl5NUpCaUIwdXRMVU9QU25H?= =?utf-8?B?M3YrTjN6V2IvenlmbzBQbStNUTRhTFZTWkhTWFJUakdwdUNtSThpcngybUUz?= =?utf-8?B?SjgyU3Z6MUFoenM2WEhiYm83R0Zkb1hzOTRpRkRrZ3U2U0RCRVJYdklkR1hE?= =?utf-8?B?K2RUek5CNVE4TEh5azlVM0pNZHR5S3BRR08vV0JkcWp5azl0RVZYRUFUVWJq?= =?utf-8?B?cEIwL21VczZnWks4RllZcHlVUlh6allaYklqVjJZVWNRL1lKYUQ2ak54SUFl?= =?utf-8?B?bkpwbG5NbHFseTlKQnArN2JNdDhSbU1JVlEzRk9LZk02Q3B0dmQ3Ym9CU1k2?= =?utf-8?B?OUJCM3I4TVcwR0ZwT003MVpTT2kyVTEvZG8rcTJ2SzdEWHVjZ3F0QmJWS1A0?= =?utf-8?B?VTNQTldwRFU3bzN0aktSZ3hHL0ZLbHFsanJRd0pzK2duUGIwVVJ6cEpRWm1E?= =?utf-8?B?T0tqQmZackY1VEd4QjZURDllbGtYM2ZOUHZuQmZxaC91VVRqd1NvRm1FUk1L?= =?utf-8?B?VExMV1lsUG9WWkNmRlBqZk9xQUpTT2JWanFvOHhpRzlqY1RtdGNHTXBTeUxR?= =?utf-8?B?c0ZTMlBpVFkweGJOajhuRlBmNmVkNXprNEc5N21FdmFHUGkzcFJSNk02eWpn?= =?utf-8?B?NllnVndSNDY0WVBiTWZ1Q0lSbU55bXg5UVM5MHNwRVYwNTl4anc3WkdTVk92?= =?utf-8?B?OGF0TTd4ck5rNmo4RGo2eE1CSHRNT2RNZWpEWTFQZ0J0SEtGTHVjRWI4VTVr?= =?utf-8?B?VUE9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: +8eqNNo+MnMWPLpacsU7wsoVSTNV/OrWy1UtGpRk28tuYcrrR9n2oTCvLuAT7nvuhVupTBt/ojJPW9feBff7dQPcjrLFEIABrVUA6HKKGHNt0omcO5+cx2LxJs/VndBSiFgtjSw5mWa9C0nPgFvYieo2Q6vQra+dQR5PII5SauFlZvkhCSsjy8KVNByv7lW0YCebI4ix8MsG+EILmjL8XYrjEdOesi9a+4UvUliqIdHkQUMMGzJPz+rnLZ5cm5HLXxVKq0wxKY67z/wYnf1hq++9t03c2TaoQ6/azbuC8SVGP09Q2oVoPPvfl39yjlnzkn31VVyW2aaS3YBggrkkHtPP8RsscxmGNI0qzps5pWd0smNpvv6JmNz4IpmIROLWkp2VLjg8fUL47aB95y5x11eH7U+Ih+zIosqPWtmmbM2K1KbVi4YKIYzPle2WSk/q13AK/QljvKqsZdhZ0dn3fMFUMn4/ROG3a1MnfS7RYmBLbJdgRNpKXSvLarIjQzwuX9oeNfL+LoA/BzwfsFffdVGCb4PQzI9+XU/pJKdYjuW48wKcDUTg3hrRS2eee0aF96oV6MtPhaqOEjSgmobO+9ggNUtIFAe5R6TlTbdqQqQ= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19e39b46-33b6-4a97-a659-08dd318aa4b5 X-MS-Exchange-CrossTenant-AuthSource: IA1PR10MB7447.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2025 15:22:49.6701 (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: EmyQVd+gCbasvK038UimThd+z0lUgz6xpy1w+iOQwa1/Vozr2t5408cPd9qLl5Ba68IAlU8vUN8aM+lLIvFXFRvJefmbi/FdsXaUf8FayJc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB6826 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-01-10_07,2025-01-10_02,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2501100121 X-Proofpoint-ORIG-GUID: 5SY8HJB59FrBbZnmWIEKzu5wR7yvIyuk X-Proofpoint-GUID: 5SY8HJB59FrBbZnmWIEKzu5wR7yvIyuk X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A726040003 X-Stat-Signature: 9ore1dbzrzppyuonym5qxu76zccn5suz X-Rspam-User: X-HE-Tag: 1736522600-663227 X-HE-Meta: U2FsdGVkX18FlsvInzgeo/mkgZFnn4l3VJoE1tcsngA9Q0Tt1s1Ax323afB+1tr65V8U/CG3pAVm2yBatvzD0/fRdgGYgP6zVSoPNB8TTe9BlIBsrJ+5NUL2XnDZyjCbYvqOS5iEW0cqH80tZxjM69N70jSnOwtYw5/BSijGPBf0D8t4i8eBh2PfIvWmbgotPlSEYPQtFZjuHpdzcQSzeq0gCWRalYLvqYin/VeYONPL36dr7qk4O1oR3J8TXd9m0rp378I66RfCoqq5cep888d4+lu+uTLEa4ARrT8TSwZEOXMXFwA3s5s7A2wRpupEX9eHm/bJZAmZ/LmP5SmQwUAHs9UD4i4wbDDKOq7IPrCb6XKj0FoRjSkur+OHIRhsIr2SnwgdMJ3Rvo3oyB9nXG46jiZmKjrt2Y3JTz7OiiZe/N2ISYBJ10m6QDGt8D0NnZvK/KvceFnSTJbj685Cm+bA3kPpR+KbYYLLbBMRQ+a2aIMxSFpFxmueI2s5lipo1bpSm8M4P24AHWfh4/yZynvVCnPf8sp6i4S8KJ34QFHHPg3VTgrGbJuBWRLC+WT9+D3hokkNrLGYcTP3B+2LWdAU1jqFQU3RjDdJH5p2+u+GrBZPZucZ0XQU8nyFurEwn/Dvwwoyq8fEH50PhJSkRpmcl9gmVrHBgH3RHLFFo327/OotoU5iHbpxV2lYzg7tEbOuONFxZukxTlN8SMiTs2ai/iDzSsjhKNpZfpcFU8VkyQTOBVEEQESk3oK2KBmaDYkFwSOiFaS47tlI20vtKxU6NF05wvka/kYcBNrCZ776Rp9mw94kP9w4p+iDgk9MrUPesSJLdma4xYrjccHrXnXDSaDaOjo42Cwtl9Fy/nE3TUoJGZUWyYfKYh9l7ifzicIGksbWkJm8qNwxqnGhwg2LzC+TbT6rWheqaHn/Yot/l5UxQfPmxyabwZ6L9bzL+GBl2mZyy7BXRBUVJLG QBgR+9Ic 2dEpJU7/pP6Urgp1V0nrzSNqIvfAlpzbF4RGez0HeIK/z2AC+jF3RuGaYxAGcL8b6QuOpB2kVDHA2ZJJYtZVmANgMfp9Dp7ur6+MViuXuS1u/9ZgrPulfV5ZMOhRwT4RAkHV+FFWAzLAUuuD0sFvFSMTW8W+ZGay8lVIH4ZGwoC/2djnufNoOvBBds1WusjRi+WbqEK0J6ChVfLk9D1E5zUvR92PwG1yqFq3D4mvPhFSkjzgQ9L8ihz1UX8po86aOr65HcB9B9aawyrEpiS2/H770AHIdf0at1jz3xyRrjV41j+TCSB5pBBSWlv9I6HdmqtBkdFbyMoYpwTNFbJRNuolnYhqbBWxFxkJRiwbXpDhFhSWel+hjIrx7CgsBMb4cPbw6XszbwVIvLC8H4Qz5EoYU3gEeoAyee7KuW+x2I9+fYgaI304QZS5C5EwrWF+1J6X4/UXPG4yzVQI29y1a+S+8dhOa4z8e9VuXcan6lQF5VrZJJvUFZZaPFGQKIKxm1/zmDGkxYS8E/XLdAhBh6/R+gvCQCol81fu/btexCxTNpBQhSWbY7K6YMiYwsunrqysFgdae/ec53TVM9GMQRt1bB5XTRVuJh6Mw5M6Wlz8+VoNfGVfsSwf/XluvXxie6DFb8FZ/RZtJ1/RXzc2i/KHr1Ljb9hmAP9l5U/1AUKYfJvLTh/g0qFKmph+PPXW+ti4uXbBnnxW3I80TcZzCtK5pExDyI3ReqgF+/V1jjNlaHCXOC0YF8QsoLGpEd+yi6um6N0se0swaSbdSpPDtx/DXYYpmgu3Ied0RkvB7F5K6bDlOEbo92VSDTlFdQdiF8A0o63/wHOj9zObElY+3l5JF3+5VNRi3lzEya0NO1m2hcBrp7skw1yG65J20cN3TqbGVW/uBDshmBUlz1Dl0Yr7NAAIGwxF76x0j 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 1/10/2025 1:17 AM, Kasireddy, Vivek wrote: > Hi Steve, > >> Subject: Re: [PATCH] mm/memfd: reserve hugetlb folios before allocation >> >>>>> There are cases when we try to pin a folio but discover that it has >>>>> not been faulted-in. So, we try to allocate it in memfd_alloc_folio() >>>>> but there is a chance that we might encounter a crash/failure >>>>> (VM_BUG_ON(!h->resv_huge_pages)) if there are no active reservations >>>>> at that instant. This issue was reported by syzbot: >>>>> >>>>> kernel BUG at mm/hugetlb.c:2403! >>>>> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI >>>>> CPU: 0 UID: 0 PID: 5315 Comm: syz.0.0 Not tainted >>>>> 6.13.0-rc5-syzkaller-00161-g63676eefb7a0 #0 >>>>> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS >>>>> 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 >>>>> RIP: 0010:alloc_hugetlb_folio_reserve+0xbc/0xc0 mm/hugetlb.c:2403 >>>>> Code: 1f eb 05 e8 56 18 a0 ff 48 c7 c7 40 56 61 8e e8 ba 21 cc 09 4c 89 >>>>> f0 5b 41 5c 41 5e 41 5f 5d c3 cc cc cc cc e8 35 18 a0 ff 90 <0f> 0b 66 >>>>> 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f >>>>> RSP: 0018:ffffc9000d3d77f8 EFLAGS: 00010087 >>>>> RAX: ffffffff81ff6beb RBX: 0000000000000000 RCX: 0000000000100000 >>>>> RDX: ffffc9000e51a000 RSI: 00000000000003ec RDI: 00000000000003ed >>>>> RBP: 1ffffffff34810d9 R08: ffffffff81ff6ba3 R09: 1ffffd4000093005 >>>>> R10: dffffc0000000000 R11: fffff94000093006 R12: dffffc0000000000 >>>>> R13: dffffc0000000000 R14: ffffea0000498000 R15: ffffffff9a4086c8 >>>>> FS: 00007f77ac12e6c0(0000) GS:ffff88801fc00000(0000) >>>>> knlGS:0000000000000000 >>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>> CR2: 00007f77ab54b170 CR3: 0000000040b70000 CR4: >> 0000000000352ef0 >>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: >> 0000000000000000 >>>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 >>>>> Call Trace: >>>>> >>>>> memfd_alloc_folio+0x1bd/0x370 mm/memfd.c:88 >>>>> memfd_pin_folios+0xf10/0x1570 mm/gup.c:3750 >>>>> udmabuf_pin_folios drivers/dma-buf/udmabuf.c:346 [inline] >>>>> udmabuf_create+0x70e/0x10c0 drivers/dma-buf/udmabuf.c:443 >>>>> udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:495 [inline] >>>>> udmabuf_ioctl+0x301/0x4e0 drivers/dma-buf/udmabuf.c:526 >>>>> vfs_ioctl fs/ioctl.c:51 [inline] >>>>> __do_sys_ioctl fs/ioctl.c:906 [inline] >>>>> __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 >>>>> do_syscall_x64 arch/x86/entry/common.c:52 [inline] >>>>> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 >>>>> entry_SYSCALL_64_after_hwframe+0x77/0x7f >>>>> >>>>> Therefore, to avoid this situation and fix this issue, we just need >>>>> to make a reservation before we try to allocate the folio. While at >>>>> it, also remove the VM_BUG_ON() as there is no need to crash the >>>>> system in this scenario and instead we could just fail the allocation. >>>>> >>>>> Fixes: 26a8ea80929c ("mm/hugetlb: fix memfd_pin_folios >> resv_huge_pages >>>> leak") >>>>> Reported-by: >> syzbot+a504cb5bae4fe117ba94@syzkaller.appspotmail.com >>>>> Signed-off-by: Vivek Kasireddy >>>>> Cc: Steve Sistare >>>>> Cc: Muchun Song >>>>> Cc: David Hildenbrand >>>>> Cc: Andrew Morton >>>>> --- >>>>> mm/hugetlb.c | 9 ++++++--- >>>>> mm/memfd.c | 5 +++++ >>>>> 2 files changed, 11 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >>>>> index c498874a7170..e46c461210a4 100644 >>>>> --- a/mm/hugetlb.c >>>>> +++ b/mm/hugetlb.c >>>>> @@ -2397,12 +2397,15 @@ struct folio >> *alloc_hugetlb_folio_reserve(struct >>>> hstate *h, int preferred_nid, >>>>> struct folio *folio; >>>>> >>>>> spin_lock_irq(&hugetlb_lock); >>>>> + if (!h->resv_huge_pages) { >>>>> + spin_unlock_irq(&hugetlb_lock); >>>>> + return NULL; >>>>> + } >>>> >>>> This should be the entire fix, plus deleting the VM_BUG_ON. See below. >>>> >>>>> + >>>>> folio = dequeue_hugetlb_folio_nodemask(h, gfp_mask, >>>> preferred_nid, >>>>> nmask); >>>>> - if (folio) { >>>>> - VM_BUG_ON(!h->resv_huge_pages); >>>>> + if (folio) >>>>> h->resv_huge_pages--; >>>>> - } >>>>> >>>>> spin_unlock_irq(&hugetlb_lock); >>>>> return folio; >>>>> diff --git a/mm/memfd.c b/mm/memfd.c >>>>> index 35a370d75c9a..a3012c444285 100644 >>>>> --- a/mm/memfd.c >>>>> +++ b/mm/memfd.c >>>>> @@ -85,6 +85,10 @@ struct folio *memfd_alloc_folio(struct file >> *memfd, >>>> pgoff_t idx) >>>>> gfp_mask &= ~(__GFP_HIGHMEM | __GFP_MOVABLE); >>>>> idx >>= huge_page_order(h); >>>>> >>>>> + if (!hugetlb_reserve_pages(file_inode(memfd), >>>>> + idx, idx + 1, NULL, 0)) >>>>> + return ERR_PTR(-ENOMEM); >>>> >>>> I believe it is wrong to force a reservation here. >>> Is there any particular reason why you believe a reservation here would be >> wrong? >>> AFAICS, at the moment, we are not doing any region/subpool accounting >> before >>> our folio allocation and this gets flagged in the form of elevated >> resv_huge_pages >>> value (hugetlb_acct_memory() elevates it based on the return value of >> region_del()) >>> when hugetlb_unreserve_pages() eventually gets called. >>> >>>> Pages should have already been >>>> reserved at this point, eg by calls from hugetlbfs_file_mmap or >> hugetlb_file_setup. >>> hugetlb_file_setup() does not reserve any pages as it passes in >> VM_NORESERVE. >>> And, the case we are trying to address is exactly when >> hugetlbfs_file_mmap() does >>> not get called before pinning. >> >> But you must not break the case where hugetlbfs_file_mmap was called first, which > AFAICS, this patch does not break the primary use-case where hugetlbfs_file_mmap() > gets called first. > >> reserves, then memfd_alloc_folio is called, which reserves again with your fix. Does >> that work correctly, or do the counts go bad? > Yes it works correctly and ` cat /proc/meminfo|grep Huge` does not show any > unexpected counts. > >> >>> So, when hugetlbfs_file_mmap() does eventually >>> get called, I don't see any problem if it calls hugetlb_reserve_pages() again >> for the >>> same range or overlapping ranges. >> >> Does that work correctly, or do the counts go bad? > It works correctly as expected. And, as mentioned to David in another email, > if a range is already reserved, and when hugetlb_reserve_pages() gets called > again for the same range (in this use-case), it would mostly become a no-op > as region_chg() and region_add() return 0 (based on my light testing). Great, thanks. >> Please try those scenarios with your test program: mmap + >> memfd_alloc_folio, and >> memfd_alloc_folio + mmap. > Here are the scenarios I tried (with the calls in the exact order as below): > 1) hugetlbfs_file_mmap() > memfd_alloc_folio() > hugetlb_fault() > > 2) memfd_alloc_folio() > hugetlbfs_file_mmap() > hugetlb_fault() > > 3) hugetlbfs_file_mmap() > hugetlb_fault() > alloc_hugetlb_folio() > > memfd_alloc_folio() does not get called in the last case as the folio is already > allocated (and is present in the page cache). While testing all these cases, I > did not notice any splats or messed-up counts. > > If it is not too much trouble, could you please try this patch with your test-cases? Done, and all tests pass. I will review your V2 patch. Thanks for working on this bug. - Steve >>>> syzcaller has forced its way down this path without calling those pre- >> requisites, >>>> doing weird stuff as it should. >>> This issue is not very hard to reproduce. If we have free_huge_pages > 0 >> and >>> resv_huge_pages = 0, and then we call memfd_pin_folios() before mmap()/ >>> hugetlbfs_file_mmap() we can easily encounter this issue. Furthermore, we >>> should be able to allocate a folio in this scenario (as available_huge_pages >>> 0), >>> which we would not be able to do if we don't call hugetlb_reserve_pages(). >>> Note that hugetlb_reserve_pages() actually elevates resv_huge_pages in >>> this case and kind of gives a go-ahead for the allocation. >>> >>> I have used a slightly modified udmabuf selftest to reproduce this issue >> which >>> I'll send out as part of v2. >>> >>> Thanks, >>> Vivek >>> >>>> >>>> To fix, I suggest you simply fix alloc_hugetlb_folio_reserve as above. >>>> >>>> - Steve >>>> >>>>> + >>>>> folio = alloc_hugetlb_folio_reserve(h, >>>>> numa_node_id(), >>>>> NULL, >>>>> @@ -100,6 +104,7 @@ struct folio *memfd_alloc_folio(struct file >> *memfd, >>>> pgoff_t idx) >>>>> folio_unlock(folio); >>>>> return folio; >>>>> } >>>>> + hugetlb_unreserve_pages(file_inode(memfd), idx, idx + 1, 1); >>>>> return ERR_PTR(-ENOMEM); >>>>> } >>>>> #endif >>> >