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 27FFEE77199 for ; Wed, 8 Jan 2025 18:31:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 773DC6B007B; Wed, 8 Jan 2025 13:31:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 723FC6B0083; Wed, 8 Jan 2025 13:31:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54F136B0085; Wed, 8 Jan 2025 13:31:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 31DF16B007B for ; Wed, 8 Jan 2025 13:31:38 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C384E1409C8 for ; Wed, 8 Jan 2025 18:31:37 +0000 (UTC) X-FDA: 82985127834.26.73F6236 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf01.hostedemail.com (Postfix) with ESMTP id 369994001B for ; Wed, 8 Jan 2025 18:31:04 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=orD99013; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=aGFma3Wp; spf=pass (imf01.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736361065; 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=Tp19HEALnQwglbDPCKnrhTLCaNws0VRCK8n8wG0vnlo=; b=tgoBUWH+8KdzZyyr6iKoMxPp/+i1apc10Iz9/xGnYSulBDTtkCKdH4cHWgIOL7iFaPM6Hx 7+G/Ma/giBW3ubf+U8/cVrXj1p0MY+2yM+pVAQm0SE5jgXo9Vu4/hWJpeT+EYyG0sEkEGU 4VK4r6C6naFk5mCylihzzALu9o91T88= ARC-Authentication-Results: i=2; imf01.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=orD99013; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=aGFma3Wp; spf=pass (imf01.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1736361065; a=rsa-sha256; cv=pass; b=lihwVRURYc3Z/L7M8tzmCmpxZcAW5VtKH5gMSElAU8EkxyEtDIUu7nnuxKGMbiOLodQSGW iAr324rSBIm/Qwe5Ps8gMzhLPQAdOSn+wN0olJio90FUKcNjt/LeKDEIyBCNVUfZq21RxB JdK66I8vfAJhX9yXzjUovFVBUMwRndI= Received: from pps.filterd (m0246630.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 508IMsYm005814; Wed, 8 Jan 2025 18:31:02 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=Tp19HEALnQwglbDPCK nrhTLCaNws0VRCK8n8wG0vnlo=; b=orD99013rNkDR2f10QIDVs9rIv7EACYM+A DE7c5MFTdOKwEre+O43JzR+uqf+r54cV/rlLKWlhkr9ZuxKvK5LXbxwNej/jBzze Atb7u6igp55UL5/Ce/fnMmP+pa/iYb65veDXncpig1HoEV96MpDWifqcfiColfr1 2P9Fmk/gnp9lOzKyR6W1z2r8IzxOm39JLUK3H9bOv6XmpZvT+RrmqogCll4WLpT5 hoqcOVtk9ckcGPHS3Q3AmhOIZpcYT+SndrZ1k2PQpggEOINAqIt6pOIciqEIDhMP FH+5qVvD8GU7VFFrMbMgL7xEYovwrVQc3BU2in2b/5tcmkyHfrlg== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43xudc7n63-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 08 Jan 2025 18:31:01 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 508HtM92019879; Wed, 8 Jan 2025 18:31:01 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2046.outbound.protection.outlook.com [104.47.55.46]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43xuegeh1u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 08 Jan 2025 18:31:01 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WdVq1PK3Kf0MRNjNAnQjSjD0zBucfKcv92m7QsvBlOk/YyX1NzqsYsQdKOrkVPWUBq/Ogm/iKrZQ9ObBoRIsODnwMZIJJGsHEy8O3Ir7pZMcuzlv0gnKzza6Zk5GNg4L2R35o/8OQGiB2Z1RGLsK1XO5hdRnKDSblqXL2aAtOFaJceogeHwzGwzJ3216YMlgwYjizbb1+tRo52noCTOin8gpsjSTztsdaWhT8OURwX1AquaJGr70cZoZCllZHzQajj9DL4VR9hUuKCPsyiLqT9U3OXAvjHbPack6AhOMhfrO5DKqedUzqu0Vzc9B7OkCqZTBpcPa/qjzz8ciAoq5Jg== 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=Tp19HEALnQwglbDPCKnrhTLCaNws0VRCK8n8wG0vnlo=; b=iGovqRbyhgBRRdX2fViXptaT2tqryeSKecOKiZDvLBwLqwSHAxraXIYlN4T9mErK+6dTrk9mNzVJbiUcjYX6LGJzoG6DKON8Q1q5Dwhx6H4hSEvyJ4mgSfSJKTycV8Dcn8UTWzwf298bA7mkJ/O1dpZfLoyZlj5YsN92dXgEDnqhFWaRaIL4eO579IbXvBKNovwi8/U82wKcYyO1xInvkseFoVqkSumgL7h5TYk7YB/LYt5U4GIhcp9MC549EI4I/negvgRnnAztmUkSM5QxWg4t1WYiZJ3v3h6DZP6TGIn1nxF5tgueF38rRtjE0P4DZPRR8Aer0nFtvnNxEKkXhA== 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=Tp19HEALnQwglbDPCKnrhTLCaNws0VRCK8n8wG0vnlo=; b=aGFma3WpiG+wegIJrHZv7DTIU32vVI3qsYmuersFWCg8r1/vQsR+2kSx2Iuphw0C1uoZBLnKdZ4GxSqMHnvdqSllWNJxKsYOSJNkwwqts3ikculmu7I9wYfybv1y0/DOSN0ujH1a24YaYjtQ09OPFkWFfVBAnTMjx5B9Yfd7LLY= Received: from BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) by CY8PR10MB7242.namprd10.prod.outlook.com (2603:10b6:930:79::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8335.10; Wed, 8 Jan 2025 18:30:59 +0000 Received: from BYAPR10MB3366.namprd10.prod.outlook.com ([fe80::baf2:dff1:d471:1c9]) by BYAPR10MB3366.namprd10.prod.outlook.com ([fe80::baf2:dff1:d471:1c9%4]) with mapi id 15.20.8335.010; Wed, 8 Jan 2025 18:30:59 +0000 Date: Wed, 8 Jan 2025 18:30:54 +0000 From: Lorenzo Stoakes To: "Isaac J. Manjarres" Cc: Andrew Morton , kaleshsingh@google.com, jstultz@google.com, aliceryhl@google.com, surenb@google.com, kernel-team@android.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] mm/memfd: Refactor and cleanup the logic in memfd_create() Message-ID: <8bcbd7af-1cd2-4043-ab10-978d568a9b89@lucifer.local> References: <20250107184804.4074147-1-isaacmanjarres@google.com> <20250107184804.4074147-2-isaacmanjarres@google.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250107184804.4074147-2-isaacmanjarres@google.com> X-ClientProxiedBy: LO4P123CA0027.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::14) To BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR10MB3366:EE_|CY8PR10MB7242:EE_ X-MS-Office365-Filtering-Correlation-Id: 69f91bcf-878a-471c-fb74-08dd301298bf X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?1B7asi51zpI7PsyqHruSVjsRroVqn3fFLNybq+dt5T5+t7i6yIiwZMuJue58?= =?us-ascii?Q?41LEebJO4KQD3Nftb3DynGvLH1vIfKu2uPHK6jXSX9fmYNWwi7EsqbuSt7ax?= =?us-ascii?Q?Lx6TRm0lgstYIb3dlbIzQe1IkPRE69bIvlIXzft7yFFi/+7z0eoTe65p10FL?= =?us-ascii?Q?WeqkZ89cXg7mASJ3BUm3RhJ8N5z9SUHGceFbuxCaLgj3h6LjmvPsybLnMGo+?= =?us-ascii?Q?8wdnexiv8OUuN7eQbHQ5zG4KL5f2z8InoLiwaYjzbat3kxfttdsVTxtP3s0C?= =?us-ascii?Q?qYjuorOYcUFix2TYpzIJWlslH5sYA0gwbIK6BptyApOWTRlbVE583hKPJ9vK?= =?us-ascii?Q?jkjEcnZuleIB3RtxR+hpm/oEOZOLGfpIec4WyvhT1zNFkQBPK5Zizd4VvATw?= =?us-ascii?Q?QMcmbeK2HCPKlwaVwqqBx/d3YLv3yxzPoVHccD+cPC3CxsRluu7fVnLXFb9S?= =?us-ascii?Q?/yYe1uDpuTmZS2EZeSBai/sx5PJ2ismbIbaf7P8PrrYE5HkzrFWqkF7Up2q/?= =?us-ascii?Q?dAx+uxh9ARwxTebb54pGmGpmjtXIQMFj+7w+7NgztsCIixJP+z5czCcGfn6c?= =?us-ascii?Q?4pF6KPZkIR8HKBSYoT3782RH5NnyTREJwCAFCuxzQIENG/QKzA9CyoP29QRM?= =?us-ascii?Q?Qsw5C6i0BBPaM+gzy4EDCxMxw1IDL1ssMX7p3fUzuf1sjUoXF8RPlTRUw+at?= =?us-ascii?Q?vIQT4rjJNuVZLyQvqUNUZCpYpw7RI1JSPpc027QHNsv5MVbQYxAHBTulPJgZ?= =?us-ascii?Q?8GndEIfxAxmHuS2BV+PR55csMetxBMZOc0IM5azpn3Ie/hROl53PpR1LYJ95?= =?us-ascii?Q?sqCHfqDvvNqwpFTkk3+vkoX+luwKxza9T2tncbZJ/gHymkXtLRCfIYXgJ0Uf?= =?us-ascii?Q?A4RIRM9nWddkG+bnLFKjozQ8mcrBWLxpmdd00rTZnkgrQQ6e0vQb4bNq/cNB?= =?us-ascii?Q?uvR0Zlt/YvM8Qq2/dLZMjQ+xL+SoqyQPzEARknO5DyfjMMwpAlc6y8ChGMYd?= =?us-ascii?Q?HO6+l6LSX8sVk8bib1eVMrLhqjXyVQSzBwemN4qvYPOAvxnm9QWZuGFOzN6D?= =?us-ascii?Q?vP9ygH3MYvElMpk6qyWuGQHHhkK7M5kr8AkZK/HWR8aOIaLtIyWJjDydOsq0?= =?us-ascii?Q?CV7NUjJ5jdEPjA998ZRG0sBu5pV52/7v0E0/BIyi89DLRamCpxIIcbcoDgCj?= =?us-ascii?Q?UQJAGH03axcKv+Hez1u6XMGCDqxGl6p4p5xkAn7RvF4IJDpH6TILGgKf7Fxd?= =?us-ascii?Q?Xi9kyI3drjjWdFHnlMO24tS1eDujOSou3tiuhBWXIF8D5FtokKxDSfUoYFHm?= =?us-ascii?Q?6ZOUEGIshYYU6zd+vJdnrsXx6Be2hgVR7xpw9QPT1Cz5Pz92pOKuyMJtrxib?= =?us-ascii?Q?wcjRV3YrH4MN0GLPRG+i+VnbGcx6?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR10MB3366.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?mx++AAFnyY6XtBP0oPAp6QO1Ap2Ukh3k78982POriukrmsdJ9GRhy6rnKQau?= =?us-ascii?Q?r9T+rFeNeVrXZMlfNOTNQ99VCMMXsxCDgInEHHz+KISBi9oSexnwP9iMEhlx?= =?us-ascii?Q?qF3cjPOhZ9mlGrNT1Yh5zHvQ0L+7nGHQX//BZNKqB1UwmhJdfhFQcbEDgdy5?= =?us-ascii?Q?gX6Ek8/ZV/OOgaQ5/AGjt+HEDMj4G7sA7qfrEycXZcvkP3z11Bzb0qLmovEd?= =?us-ascii?Q?8syl3RA2guBqYrRrSyyBO1lV0u6SNEOq+F4m2iCu2wPCi/cDzDbFSy+Fm8bg?= =?us-ascii?Q?9WmtxjqYyxmnPLs6rxpqHnL99lIPhus0V+Ru+RWxEoJT1cyqFqb+ETcwVmLO?= =?us-ascii?Q?bROVs+ybnxaEEwqrW4xOg9f3ANYdnKbgrIdIctLo0Uisgf0pUMqcTqBNY1Dp?= =?us-ascii?Q?qbimrkZfDwoBGwwb3+mZznoazAXR9GSYHvfDeJOldoIQKqqePxBmGIw+JoOz?= =?us-ascii?Q?mFn/ayvFuFdPEZKt3K+GuQYsGymuiXYxs/PCsUvXc+xCRWR7eCh1cafuWfy8?= =?us-ascii?Q?58IowEusJcyQOE3szsd5AL0syR2Hn5k6gvgebg9u+am+PfC1zxJcL0NzPjQs?= =?us-ascii?Q?Ao+FKfNOJNS/n5TU5mDmOoVA4EAvoVmbyLknhA5Rw1gJLunKcd/qq7cmiZ8T?= =?us-ascii?Q?r+q/9n7XkF/qe+i35aXCQGWoXXdDwzDJK4VIYg9kjKHVAj+ufIPe93Yq+2+c?= =?us-ascii?Q?TSjECHwWZWxGH8EvokIC78F/Z382oHoQ1uFJ7BF59mV4FnhctumdbHpi8w93?= =?us-ascii?Q?b27fidjtxXm2Bf1ucILdwvxDDt+b8pysKSA5rjv30ah+eLTXRBU/5gEAocEJ?= =?us-ascii?Q?EOgwNBl0yVcvYzrBHBtDoy7H/S5Mu2skgCS5L1+WCo7vim3dUmaRo38vhNEq?= =?us-ascii?Q?Td4c1lXZkkEmgm2TJDQ9hHTqlvVXZ+v3iHCWqabWQNbeDwaC6CJ4aDIGwoyM?= =?us-ascii?Q?gY4gwLNUemJX2ESuXTlr0yEImJLxSf02vZshpG2ZPAgdE+l4WQuXw79bbgEO?= =?us-ascii?Q?8O4Sk7KuYz5jij7wxWI4o60HhXLLX9GnhVgjhaMotVlL8ahdK1xdnJdiLxbO?= =?us-ascii?Q?nBKhUUaUhzgxnTMt6ZQZxx2JTX89e7KB9gV/1+Xyi1T9HXTKAodFs6hKpC+i?= =?us-ascii?Q?08J8ubTS65m0nJrOh05MeIWlyw95T4BRoQz6ifpyks8stdg03sALLceRQch+?= =?us-ascii?Q?TZVHd8/HPrhh1+dyk7TN8MQ+W1A5drCvj6fq+vJTTx2mh9DIPC3xN9gQFu9F?= =?us-ascii?Q?8Ntj2OYPqPzol4RtFvw1riYmUbBpL8OGUUZbclSWKfmnyHNlnmT8kfODM86m?= =?us-ascii?Q?6QZkbWFH/gGFGWFmLO88CI7HF/V5m0nX+0vl/VzIkYMqiXly82+qZjhS/DYQ?= =?us-ascii?Q?DCCAMmD9795juvICfsRCPJyxWp/A0zJFJaF//vufP4USANsXmYNGEvvMJurm?= =?us-ascii?Q?Wn3vZGyd5JlKnN7aInJZ3qpexj9XSsQXE/OPcXQZvPt82AkNCgvK4OtNWQBK?= =?us-ascii?Q?acPrfMqB6L1TlmWjPc6mpkIZTjI0L5ggdyUP9f5y2w2Freb2M4laQhiJJEnT?= =?us-ascii?Q?W34s16ByMxMAgI26uJ+dmXdDYBm8Fqz7R+7lW10hCiejF/DDJShJHHZwFFtw?= =?us-ascii?Q?NQ=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: UrVqQoCY6No5ucPdufXgsq9w9xr1/uY72qHlWSoQzpbz4xH7H6j+mqg16W3U+CWRFXZ5ngKOBZ3cfWo75+VtG4rbLn9M4vymHJ/tADJQdmkwyU/cSVPsMjROnQ6fzd8XO9bLupXkv5ZosqR5otNy4bRGfECbM7mkRQwQ4PvkhGcZlSveczyH/iifOiXnzqJqOdhFc0yVfrr2Sg38wnuHTV+XHHT+XN81gp6c8fs1pOvJtXcL5yOXujTtdFt5D7dEdyCwAVFSQMS9NZ991XnvBTKezJdbD0A/XCXv6L79f2vb2zqt6ENvqNTzUNpWk1mRLGbUHAjML3mDBJe2epH8Pe7YcL3DNcmTu9VfPkrO2tiC/AOkQtgKxhkBIknlOSryv2C5f8RXRvfn19dVYwwCqDom0FZDDkIDGMoI19YJja8+LrC3rPabbt03yQgjxM5P0tX9dV4LtdvNIAGNpk43m0MY9Ra3kIhp3RfQn0xpLu9fehp5tWNHARa6xEYaoiYxrvknMeQ8wDWc+Cf5wmUnQaVuMSZiuV8poh7t24UUtePEDmrad5EY29DEsngKE6LCgwEPMg0l5h/UdRPnAsTUcg+z1jjPOwXWZbBoVCLoP94= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69f91bcf-878a-471c-fb74-08dd301298bf X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3366.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2025 18:30:58.9617 (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: 2NdCFYr/gUf3hLl6sYVj6I6dLKgdm6OfmjEK1KzUPTesWYRJ5aQheVOdodYXoQ6HkEeyIzB9Yscf3P2826ZYHV+sBxldSBRDDxLLyltjObM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR10MB7242 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-08_05,2025-01-08_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2501080151 X-Proofpoint-ORIG-GUID: IvwJHf6bIddBETzNBeSJJvajivVHmsEJ X-Proofpoint-GUID: IvwJHf6bIddBETzNBeSJJvajivVHmsEJ X-Rspamd-Queue-Id: 369994001B X-Rspamd-Server: rspam12 X-Stat-Signature: rwahi715hioep13ejsy6yocmwfkf8c9h X-Rspam-User: X-HE-Tag: 1736361064-208382 X-HE-Meta: U2FsdGVkX18TRnd4a0MmufySWW9uFrIPHiJTgyulbKz/aWHHFj+e1GtyA4Rmzy6cpHHxHfWp6yfakAzQwB7KnKwxQJ7JgkME/AvbKVJQ8oMtR17RR+N3032UCl250I75v/VouU7MvjB1KLblVauJiQieGB871kZLKzYBW4GTe+/6SD/pfC4c5OUbMSY5M/FDJ5GqodLCiV9D9+cwxBaNfp9+zNAw5p7xoUMlgMstDVWenbQ+5NNYf+AN7Wk50spcIm/z5O3DPK1h8cFlnS5VJxiQUtQkN7h3N0KJ6DNeGnA07JQo7cRESZzxQCjpHmqWW1kPxSH8Jfzo1X8XxU37mvYEaHNWzl7P1L41bsSbYXlz/7UpwbraiwTS/nzFjAaScUG9IKHQctQjemE2nJ24Anl8H7Mu3hQ5Tx6g5BjKHkm9MJ14ejAfhIHlwkpomxDOUw8L3jQkAS+GsFNkU/sg3rShGWVLST8q7nl/FwH6CuGOrGFIwt86UTVki4DMfHOpdJM2e73aKflH6e8/QyJ7HBX7qx/YB/F44M50cdr1mCg8VZaLiPMhGJWmr5rd60OwmCmFygtJpj/EdI4dVU+PO7ZUJvLJeiJsTo7DhQCRh7f5uUItksO0ITPLn/AsAfWv2j+1P2sMSnEl30VPqFUKqW+m5XrE9p8gL6xxny97U4sKYMq9ltBKwcfJQr6o9iyxXrsupgwL4dWZkJ34Q2B0U4zWq1n5tYpIEIRiDywNpwG/wxBBDAfo2ppbpdBxFe74jqypnZmHzVhSGWM9zG2q/dAy7RJQcIzxSkh+hR/GW5GDCL4kb0HfO/SK62oHPX8i7v2HikkoCZBhAz5Th3EWpdrhFQ+Am3WlWgPe/NPx3XKPDs0glF+y4cmwP5nHcY2hKMEczsqgb9LLbLA/0MyXk2Z5a+NOlhjwxASwcuYYz6BvWjobcbBUqOEDJqW2I9GG9q/2sn4/cY0OqR7N04c /SFMu7+q Uj76SFyTnrpDXAzHmORCgeslOjYLL/Hj4dCWay/4b3l8Lmfs0o6CEEtr98cTwOs2v0KcZdW0onheMKDIIkYPgUCxc8HqR6xF3Kgh6hB8ZLNYe7ONQ55pYTfOfOmXA1PiURKOIqt3yM6JCTp/l+Zb3v9+eV+mwC/QPbLibDfHtFmN4n5Qkx0gd4CHf0xkcr/6MpCfHXx5HeEL7yMct3NVLQH45DXy/woOPSL517jW752WfA5JbJMv32ku6donGnfbVB9G6V8hf4yn33oGa0JwY1MuWCcv49eEdGHykh5HQYNSKJ/cF1BNKBtfGNpsqhhaQay1JpIAest6OQKzfbaD14Mr6Zm7YEiIKNsl9CPKheiMvJ5X+4jxJV5heh82idMULV+F80SoCbSLmKwRFaJDhRa08LbSXORKYhVtkqYx44ggzAcSeQuOB6fJt/Bp5bCkt1c6XSio71cz+UEcp9cyC9IjCCoqGSsu6lNUWBUnTJBpBqzZon0cml4+MaP+ygXdtbTCt0iBKUQZPPtgFdiP5ML1it/J9+/ilmAeqytt9hnUsoY3UukhjpJktB2X/g4BccCr7twxLIyoqjHP/Prso2DgIxDMtbi8GK6US/gRZmI/C6+EZZ0YBSHGv1Q== 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 Tue, Jan 07, 2025 at 10:48:01AM -0800, Isaac J. Manjarres wrote: > memfd_create() is a pretty busy function that could be easier to read > if some of the logic was split out into helper functions. > > Therefore, split the flags check, name creation, and file creation into > their own helper functions, and create the file structure before > creating the memfd. This allows for simplifying the error handling path > in memfd_create(). I do like the intent of this change, but I think this needs some tweaking. I wish the diff algorithm would do a little better here, because it's quite hard to follow. In no way your fault that :) difftastic hopefully can help me here... > > No functional change. > > Signed-off-by: Isaac J. Manjarres > --- > mm/memfd.c | 87 +++++++++++++++++++++++++++++++++++------------------- > 1 file changed, 56 insertions(+), 31 deletions(-) > > diff --git a/mm/memfd.c b/mm/memfd.c > index 5f5a23c9051d..a9430090bb20 100644 > --- a/mm/memfd.c > +++ b/mm/memfd.c > @@ -369,16 +369,8 @@ int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags_ptr) > return err; > } > > -SYSCALL_DEFINE2(memfd_create, > - const char __user *, uname, > - unsigned int, flags) > +static int memfd_validate_flags(unsigned int flags) For static functions the memfd_ prefix is redundant, please strip them. We know we're in mm/memfd.c which is context enough for these internal helpers! > { > - unsigned int *file_seals; > - struct file *file; > - int fd, error; > - char *name; > - long len; > - > if (!(flags & MFD_HUGETLB)) { > if (flags & ~(unsigned int)MFD_ALL_FLAGS) > return -EINVAL; > @@ -393,20 +385,25 @@ SYSCALL_DEFINE2(memfd_create, > if ((flags & MFD_EXEC) && (flags & MFD_NOEXEC_SEAL)) > return -EINVAL; > > - error = check_sysctl_memfd_noexec(&flags); > - if (error < 0) > - return error; > + return check_sysctl_memfd_noexec(&flags); More importantly - this is broken... The check_sysctl_memfd_noexec() function is _changing_ flags, which you now discard. This also renders 'validate' in the name a little inaccurate (hey naming is hard :), perhaps 'sanitise_flags()'? Anyway you should pass flags as a pointer (even if that's yuck) and rename. > +} > + > +static char *memfd_create_name(const char __user *uname) Again, strip memfd_ prefix please. Also I don't know what 'create' means here. Given the function you're interacting with is memfd_create() it's rendered a little vague. I'd say 'alloc_name()' would be better. > +{ > + int error; > + char *name; > + long len; > > /* length includes terminating zero */ > len = strnlen_user(uname, MFD_NAME_MAX_LEN + 1); > if (len <= 0) > - return -EFAULT; > + return ERR_PTR(-EFAULT); Not sure if this is necessary, I mean I guess technically... but feels like it's adding a bunch of noise. I know you refactor this whole thing in the next commit so maybe to reduce the size of this commit you could drop these changes here and keep the bare minimum before you change the function again? > if (len > MFD_NAME_MAX_LEN + 1) > - return -EINVAL; > + return ERR_PTR(-EINVAL); > > name = kmalloc(len + MFD_NAME_PREFIX_LEN, GFP_KERNEL); > if (!name) > - return -ENOMEM; > + return ERR_PTR(-ENOMEM); > > strcpy(name, MFD_NAME_PREFIX); > if (copy_from_user(&name[MFD_NAME_PREFIX_LEN], uname, len)) { > @@ -420,11 +417,22 @@ SYSCALL_DEFINE2(memfd_create, > goto err_name; > } > > - fd = get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); > - if (fd < 0) { > - error = fd; > - goto err_name; > - } > + return name; > + > +err_name: > + kfree(name); > + return ERR_PTR(error); > +} > + > +static struct file *memfd_file_create(const char *name, unsigned int flags) I really am not a great fan of this name, memfd_ prefix obviously has to go, but 'file_create' when the actual system call is 'memfd_create". Again, naming eh? It is hard :) alloc_file() probably works best as you are in fact allocating memory for this. Then, as mentioned below, restore the original ordering of fd assignment in the syscall, do so before file allocation, and install the file into the fd afterwards. > +{ > + unsigned int *file_seals; > + struct file *file; > + int error; > + > + error = memfd_validate_flags(flags); > + if (error < 0) > + return ERR_PTR(error); I'm not actually sure why you put this here, it seems quite arbitrary. Let's invoke this from the syscall so we neatly divide the logic into each part rather than dividing into different parts one of which is invoked by another. And obviously make sure the original ordering is restored. > > if (flags & MFD_HUGETLB) { > file = hugetlb_file_setup(name, 0, VM_NORESERVE, > @@ -433,10 +441,8 @@ SYSCALL_DEFINE2(memfd_create, > MFD_HUGE_MASK); > } else > file = shmem_file_setup(name, 0, VM_NORESERVE); I know not to do with you, and strictly this is probably in line with kernel code style, but this dangling else _kills_ me. Could we put { } around it? Risking invoking the ire of the strict adherents of the coding style perhaps here :P > - if (IS_ERR(file)) { > - error = PTR_ERR(file); > - goto err_fd; > - } > + if (IS_ERR(file)) > + return file; > file->f_mode |= FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE; > file->f_flags |= O_LARGEFILE; > > @@ -456,13 +462,32 @@ SYSCALL_DEFINE2(memfd_create, > *file_seals &= ~F_SEAL_SEAL; > } > > - fd_install(fd, file); > - kfree(name); > - return fd; > + return file; > +} > > -err_fd: > - put_unused_fd(fd); > -err_name: > +SYSCALL_DEFINE2(memfd_create, > + const char __user *, uname, > + unsigned int, flags) > +{ > + struct file *file; > + int fd; > + char *name; > + > + name = memfd_create_name(uname); > + if (IS_ERR(name)) > + return PTR_ERR(name); You're changing the ordering of checks which is user-visible. Previously the flags would be validated first, now you're 'creating' the name (not sure this is a great name - naming is hard obviously but this doesn't really tell me what you intend here, I'll highlight in that bit of code I guess). Please try to keep the order of checks the same and validate the flags first. > + > + file = memfd_file_create(name, flags); > + /* name is not needed beyond this point. */ This is nice to highlight! Though it absolutely SUCKS to kmalloc() some memory then instantly discard it like this. But I suppose we have no choice here. > kfree(name); > - return error; > + if (IS_ERR(file)) > + return PTR_ERR(file); > + > + fd = get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); > + if (fd >= 0) > + fd_install(fd, file); > + else > + fput(file); You've changed the ordering of this again, and you're not doing anything to free file if something goes wrong with fd allocation? That's a leak no? Please reinstate the original ordering. It's strange to open code this when we don't open code other things... but perhaps for a few lines it's ok. > + > + return fd; > } > -- > 2.47.1.613.gc27f4b7a9f-goog >