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 C8707E77188 for ; Wed, 8 Jan 2025 20:24:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4378A6B0085; Wed, 8 Jan 2025 15:24:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E7456B0088; Wed, 8 Jan 2025 15:24:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 212E16B0089; Wed, 8 Jan 2025 15:24:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id EEA196B0085 for ; Wed, 8 Jan 2025 15:24:07 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7C5D61C6B98 for ; Wed, 8 Jan 2025 20:24:07 +0000 (UTC) X-FDA: 82985411334.21.3F8997B Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf27.hostedemail.com (Postfix) with ESMTP id 2EA6D40013 for ; Wed, 8 Jan 2025 20:24:03 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=kdNgWiJN; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=ZGxpelQb; spf=pass (imf27.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@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=1736367844; 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=ydWhXlZMORnCLU0sn1i8n2iMHAycv+gSlFsBeuhicKs=; b=PKOuv2mtwG6jnlYdVMWFxOxICWefUfKnvQ/s/mAf8+Q/0EfM+3Sf/9n3eH1R181SBivwVP jmr3aKEL27L/hbcTIOJ5CobJsiYVH5WVSXtrb9t+gqloUFrhFZeerKpxEvNsT4tXE+ZVqe Y18reRehNDYLZxn0DI+z2U9DWso4pC4= ARC-Authentication-Results: i=2; imf27.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=kdNgWiJN; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=ZGxpelQb; spf=pass (imf27.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com; dmarc=pass (policy=reject) header.from=oracle.com; arc=pass ("microsoft.com:s=arcselector10001:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1736367844; a=rsa-sha256; cv=pass; b=bB9a++ry9tZa8vrPnYpJ5nh5DXa3L8Claw8RA1tBk0RJux3a9IAgIToroy0fTZeC2DTqs6 ed1ZfjUhkdu149fSH3zkG3hmNdFr46xVGkkc8kckiYIJ4EvJecZ74Ek9F4d2oDgsvq1Xjn MEpvts5evNG5UEJFkSzK+uurLFT7iFw= Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 508IMsbM013206; Wed, 8 Jan 2025 20:24:01 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=ydWhXlZMORnCLU0sn1 i8n2iMHAycv+gSlFsBeuhicKs=; b=kdNgWiJNXXQnADG7EzH+nnzB4deaQXSWYt tm/z2fX7gjEf0HfK4lx5lN6XRiXuIjQNp7KYDHWpUwH0CBUEXkJ+ELh59IwWS4sA iKW80uwYXxIKuNakeq3gnq1S8FLAiWN28MxyUh+mrnNeOE0xs2qiqDgFXgkfWJo2 njAaaEUxapOHfutq9sI6qe/kgUi89jbLGGAciNk4/uHveKF6QarVsiY+yCM7kEiC 59KZBgK0bU2akE5Y2H9a3IUWz7L24/ABdLVE0GFBlkUI6lWSu84ASbtZm/cKgA3+ OhPoXGcwZSfUwX7U1bYyLdstEYRtcipH4jj0LZ87PvdZu1zaBFiQ== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 43xwhsqfpq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 08 Jan 2025 20:24:00 +0000 (GMT) Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 508KMKlE011032; Wed, 8 Jan 2025 20:23:59 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2042.outbound.protection.outlook.com [104.47.55.42]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 43xuea20mn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 08 Jan 2025 20:23:59 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VZKOr10ZrMu3pw/GbgC1aXXZ4/07ceoMcobvqa/Ty2Vafx/Rnx7FYM/QYb5T/rJfYWwsGRtkTVeCmKUHpuVzJ+7tl4vcAMQQleXj2CC9aC7sgPBE+Qh5UvB5B01M6tkPKDCV9PL+yL2hWnaMVJBhFZQ2TADF75R186CTh+STe83REQ9GqYYkl6S4AaIYSuamYow2eA2XOeoONO2IY2rpfLbtsSmhfr8LP0FjfgcE8kHQvHZlB7grO13jpgql9RjtYFKBTdsXALiz3oXCyI6umYn43+7m+q3EaWnpG16cNeIo0Bn7u54EaWe9ht3q4Ot1WBRb4+MBHbnxuN02tbGB8A== 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=ydWhXlZMORnCLU0sn1i8n2iMHAycv+gSlFsBeuhicKs=; b=zC6P2MxiYB8s1YftI3+Xp5dcH+sYbLbwNIPh+TPNGlNjo4J6s0vbFrADN/N+Ak9Nsl4Yn/yThhxc0k+7Ailbn9UXYR2/wE9GNcIhbuBMoPKYjP2i+vU7HwuCO6fRlHvGLRlH6s+vMciYR1BrjHP1cAozLdplM22furDHPgJzKLxdv60zbPM8Uxr/NNWwGcnHgqtR/lFmMYp7Kll9oNp+0tSTp/16cPWDkvgMpGpG4WYmaWBxwRIqqMjLasE833o/SFRqQNAdEO+ht4Ew3ZH3w5saS133zcXP1zfRQ2Ml8TJmOqUs/2aoYDTDscV39cObd/VgWaa8yRP+ydU+EuzgJQ== 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=ydWhXlZMORnCLU0sn1i8n2iMHAycv+gSlFsBeuhicKs=; b=ZGxpelQbA1mAyrl++b2gs6KPY3CYHG8q8NdGkr4UplA9mcajyJBiwVHlRvktF5UaoFXmSkwr9AYAy+OJfwOrmpG5fnFahLk/+UVbK32z2ZzZAlt+TcCIQm8vAdGMBfz4Du1irC4gimnCALCGaS91T9XOR3cKIG83kHXiH8EXlsE= Received: from BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) by MN6PR10MB8069.namprd10.prod.outlook.com (2603:10b6:208:4f9::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.16; Wed, 8 Jan 2025 20:23:52 +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 20:23:52 +0000 Date: Wed, 8 Jan 2025 20:23:50 +0000 From: Lorenzo Stoakes To: Isaac 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: <2ae2ccad-303f-466f-b148-a6b8f6d9a712@lucifer.local> References: <20250107184804.4074147-1-isaacmanjarres@google.com> <20250107184804.4074147-2-isaacmanjarres@google.com> <8bcbd7af-1cd2-4043-ab10-978d568a9b89@lucifer.local> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: LO4P265CA0109.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c3::13) To BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR10MB3366:EE_|MN6PR10MB8069:EE_ X-MS-Office365-Filtering-Correlation-Id: 07bf6826-1c56-49f3-7de0-08dd30225e59 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?rKErNC+t9ADX4UNH8ms9E2/Ayes/r80YEmhfX0sA/K714cMH7vFzuA4fHEzx?= =?us-ascii?Q?m7sWPsQjtSduxYLa6jKnVsjeb/K21bFj+OUKrnHaeUAtRQuCxy5/EZK7C+le?= =?us-ascii?Q?+RuuR4p+Wlpxqx5e3EXRWSv4L3lz97A4KDKbCSssm983c+R8HHqtWTuLIsHL?= =?us-ascii?Q?EMYKh+rFRWYPyOTD//YXRl5cQeT9wMBg8Ru8oWtZQQQn9QGA7KO20syrkoxn?= =?us-ascii?Q?ebvHhIJz1R75czP/0Bkj2wL1R5MUSqHMNsxkv/Rg0BesUQIbIRHmNOB6OfBX?= =?us-ascii?Q?jCVW5QTCMjhDBBIgwsYGVfqffkRBtD62gqllluj8kOARym7GvNxyvsyisGaU?= =?us-ascii?Q?vSpmc8ABPgOhAPwpLxpXNxxN1+4oVB/x+sqwhCicqpVdr8xuMBdHsxKyQKSP?= =?us-ascii?Q?pHAlRmalKllJ4RIvZNdd3OwMoQc2Q/ZXP3jfI56TY0zmcr5UOdSP0Z6HywVP?= =?us-ascii?Q?CrSQ4nvC5pPppWJwWQKKi+G8MOSmg///XKviAVqWvxBLNeVr58pjar7uH7ML?= =?us-ascii?Q?oaO14LsQQX626XQtHTBAZ2/ArUUyHNELK978mtui/wLyX6EUdL5BimGmZuto?= =?us-ascii?Q?oEDHD0nHxiAww/AUhRjXVxQ/a15xzMfb7hfPYLtzZyXjX4m/7bKo3VjXegPP?= =?us-ascii?Q?0rXDaNWAqf7/9jaLZ924h2qapDbPFkNTPSO2rfgC8C0KkNoc0V5Kp7T390w4?= =?us-ascii?Q?ReG/sMSFv0E3PEKq4MQAT7eElnXVXVU4qbu/WXBNcASnEDA6ojLdQCgf/49c?= =?us-ascii?Q?0MTvS6xJIrXn890GhR/r9OIWVzqGl86TRb2bTHdBOxwI8P7h2J64J1kAWi5U?= =?us-ascii?Q?6GVHXnf81wsb6ZqZ6OvGYv4mXaBYNWme0lcQyuUTn179Bko4R+wc2/p2sESs?= =?us-ascii?Q?tKw7FLqpzyr00Yok3PUSLu8oicz+55QehxhWMHQ98S4Qu503MGKjGKA+YeFh?= =?us-ascii?Q?HC5XMMVL+0eXsz4JhPwu1c1O2YlUg+k0bY7qdlAA00Z+zRjC3oa98fqFEJuF?= =?us-ascii?Q?KHG/l+4fXqph3sn29q59aMvvSPhpMj6J8puTzx8cskpzTnyJfjgbZTwEmgDk?= =?us-ascii?Q?TullDs4O4MFPKvrdrDgIZrJ7rMB2w377XwIsx49dygaSMf6e/C3ScMjiuV0c?= =?us-ascii?Q?lzlXfRW1P0ccG8tLzhnVjvEsqw+TBuOnaUx2pQyzxzti3Vc1sN6gxtdQozkg?= =?us-ascii?Q?cYKGNYtA21N9+0Q2N8joB4Ce8+EVa20zKpNxYGC2i+2cd7Rx5i76qHJV0Hpy?= =?us-ascii?Q?nPHsmbuMHb1WwaQN/YmVsu1sG8IENLVsKEp16F/X63T2TneHpancrb/vmbns?= =?us-ascii?Q?FcMuDYJKVEl8yijaaAwGsOzXinVgqQ5ecXiSAkBWSZQCEyDmfszPIf6prkNd?= =?us-ascii?Q?9cxQ3szbqwq774iCpuKrL9ubhc0F?= 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)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?3iJU19CdYjghzLvCWe8Xp+WcEjdWE1Io8FVR6M/UHbaCz6Xkt3T5wUI63I/U?= =?us-ascii?Q?iCsQNRfrXZKLu+B/FA497yx51dtJ/3CD22iOtTuAOtmq6vs45EysWWMroGqt?= =?us-ascii?Q?+nHMXIBUJZvzT5fTHxPV/+nyMZqUuV+cPkYXptfEjnuFMCs/erWMvfUxtkmW?= =?us-ascii?Q?RxXFX4NgdolKkFXuTAwWaSdNZgH3wyq5NfnP381uNd59xy7lAkx8sRSmuutS?= =?us-ascii?Q?jyY1rqLMKzFKkGtKsRcOyW6JgC6/grfZmDWhkpekQcELh98q/Mbb2d6BHyZo?= =?us-ascii?Q?LcrOUTLtY97af2MHb2A6oO10c5oPsAYTtL6aydh+SoUYfDq+iXHXZmdFo2Rg?= =?us-ascii?Q?GOzSwNodhJupcbB10CmLLT4L+bmIQPs0VtpyzeJLmQMmxRA3ElPAWUKW1Ag3?= =?us-ascii?Q?zJSV9TdScWgm60xlY1M8rW8RUxMH6O+tcYD1o//mATd8TgmEfTbUFwBs8kzd?= =?us-ascii?Q?xb5ZAAKZrWrIeTEbGLEVSyVo8KCH44jUqGBBLRnhyGJ+isZ0A+2vNJ1DAwWl?= =?us-ascii?Q?rCfLv0l9/46aBQ6L48ucD9b4rHXp0BTi+XniHXqGOvyXabMK/QBVb4KoggFy?= =?us-ascii?Q?yYWOHVXbHHMwXMQ+/F5HCrxvVPQ7UNp3mKYRxO1/eTp8RC5+pkqdbHMdDKqy?= =?us-ascii?Q?f5Ul5jxp1ae+cnY7fxlMz34pEmbU1qM/qLwLGvxPiG2wtTW14gjL/mcEWmQJ?= =?us-ascii?Q?iIpz5oCs6ytFbDQC6WKU4wUsIKxXF0J2PfSgJK0uELcslWcOM9UMJ76a82mW?= =?us-ascii?Q?KsPT38khGF/zBXETqrS/ANbClmXPEqedPCFurkM81f3P8oswUXOnzXjKvrZF?= =?us-ascii?Q?c4pO8oj/xsFW03LKEhZH8lGM02DAwfT9EAGyTDLpjxXfMMDy/O7W5nSSGtwX?= =?us-ascii?Q?lYlnHrVUZY5zbfOBC40TKlzHtXyPa2ydeCDNBoQKWBhWkvbnQn8MzjRF19xt?= =?us-ascii?Q?067A3XW3QDjWaQcz//FbbDGD4lTNhQpYbLR4yQKJ9oXbzJlNwgRdGY4XzTQx?= =?us-ascii?Q?5ynts2bkxCUZ4em/1NwiU6wgycLJK+TBKbwpl2l0zs5LHeeL5teTsp5o3JjE?= =?us-ascii?Q?L/+RsqxnEA0LaczPe88TsvagsHAg42QWtwkPy9e/HvA+uh0LEgXyVp1PO/G6?= =?us-ascii?Q?ZDrM6iAwBeSlNnlNzNdm4rQo8zSJFrHa8iTyoMMhvPInBvpMety8YiC7AsUO?= =?us-ascii?Q?F7zQag86YFChqlTIc8GDGpqqSnl34kAqM37EikDZ9LhQ6Wf+PdCFT/PB6NJq?= =?us-ascii?Q?Grx9+0hW55KMvsDT2NgTRzuwYxr2qWdoq/3CEE8ggwyNQ/GoNKkvqifWQmYO?= =?us-ascii?Q?wc88uNb9nLp6vKmUrt9LsbWf9nhoRLT26y663qx6a7l35LaL8Hsy6Y0vHKHU?= =?us-ascii?Q?AzwCkmdyiwH9mlTw5wCA/xvBHosNotsxMeJjAUlr54oWdhjM40qT0HIiyyYA?= =?us-ascii?Q?UFwkiZoDLm/3LQsxJI62YBVHQhJjl07QUOo8Ol8PtnUmPlNKugph1+OkZcar?= =?us-ascii?Q?RVZ7Ef3o8MtdaZ1VMMUEo2kxe1jsMnLNDA1E1cj75C+ndANrgk+8AzuzNruU?= =?us-ascii?Q?Q5guVAHO24uZoe4O41jLfl1somRfeTT6q+vZl3dZfYWmYkx9xXuJnsYBz5gk?= =?us-ascii?Q?3A=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: qrcIMCw9t3Frz83/YXK+qC8zfr7WPHjYqBywXqV31iE/m+Mp9KfPsWWKURTL6f2xsfZbatZUDpaGohEQOn699PBVTIE4eV5auEe4iejPQ3KknWJxB42np3KONN6mnengCRDfGQrUlDIWQpqdoFzVoC/IkOeUg6KDkrkH5Y01BkKQ3seG/cjiXdUZZHtrBbESQAg3HuisugyPmp2lmEeSpl5tcdBopqj9ZGJu8mFMDsL3h42NcsCC0Y3ZJ20pHO1xOqMGvs6sabZSNZruoAAuiBmHtKDts7j4vIwRqLAsTgTAPO+Z0lZjLIB7ew9NOreCX738TZlyZhmRKZx/qPgQz8AJK1Zn1KwEJZqV+XXBWtZg8iUss4z4ky3q9D0RJZo+/UJ8j2nSd3OLYog7c2jsNoywSdUBk/zQ7RLOdG5g448yxVHOHF46n43ygoULQ+7UaC9SArFY3BN2EBOoDS1Zjfl7XQ9/N24cd9cZJAnwAKtRtz9cjmU45F79JSaA5m4uns0DDCQ0yphx9UCdMP9jpY1HbdMJOsWKjba8bCgDoFkzNGEMEL8FIahvrlhkb7ZGCR7dlLV8M94GfoIBah467MEtlaXouPPLepj62UjkB5Q= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07bf6826-1c56-49f3-7de0-08dd30225e59 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3366.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jan 2025 20:23:52.8675 (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: 408diDJyV5jC0Y/Qw6AtEoivTQDBHoKGAUqybfUeAS+bmJ2By1LhFFdzvajzVNn+LFr5Tyff8cnA4SoB8TZBLsaK0EB8cXg6oOK6eB6TihA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR10MB8069 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 bulkscore=0 spamscore=0 adultscore=0 mlxscore=0 phishscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2411120000 definitions=main-2501080166 X-Proofpoint-GUID: xeEOYB4Sw6nJtrwfJx3ErfUY3P3fTJQc X-Proofpoint-ORIG-GUID: xeEOYB4Sw6nJtrwfJx3ErfUY3P3fTJQc X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2EA6D40013 X-Rspam-User: X-Stat-Signature: 8wq8rhyinx718zposjnxb5rpguc4oswe X-HE-Tag: 1736367843-285914 X-HE-Meta: U2FsdGVkX194HBGcDL3Pa582a0vfbTBY9L8uTvwrOuH942HuVgX73qq7XQtn0XM1tJpDKk++L4sqdYU47PwIUbvL+pC3FK3PC1kuKyFauFp8P6/6FccB7WOSDXIGpg/YfbU9NPQiWPjgnkJsp5eFSPtZpVQ9Gt7VUTiGOGHVWeLf+qW5IJUY5TxzVbSeDLNdTovWsXVzOxHbkA5/lFvd7iJQKDtv6+3nPhOHwNlpwlAwUc8RoKt0sbnYqJGfmapJT52A0fhuWUomgntAGjjijekxuwNT79E6ONf8x/W0ZPvZFrKSftiyJF6JXeEUte9SK6nr83bFp7fXEvXrxrt1nu65FCqUWzKFqNMTONuc49BJDPQgnW+JW1NBMp7PqfR126zASa1JJgHYKdcclOyis5OgbblE8dW5rnLZzyBZ6P4phnSeCabtPDyZqnKAeQn6CWOuKbg5U7mNDioNayDo4C0mtrnzO2/+Uyf1ZIWd6C93eb4QrYSCFyrzYfjeE3O7kjX7V4U427odRzlxe/6P6eJg+tkqlMLvN8wvEFqQmrEiuWuYEGnmnX4ZUeW57afLRMkU96VwX3bdDKtCX5oYlWjt+C941RV+Zjeq3HZl1mmGRdG2rrkRsuJz3AH0IaUxE0GRTwNQ8IM9zr1YnHdqH5yh14Jkd9GgucYY8gZHdRuW2eDGMHSntkKc5XbExtU5+Gb0vqylAvCU2JhAv0PuXzU2lfV/vCLo22MRfwbHJrUlFpXzE/9g/z/Tiy0uenYIfATgMB1nqjKX4YIbJVXvLaEEThfX643pZEfMWJ/Q7/9amsEojowuPzOmIAf+WVfYdOffzgKQ3iO+7QheK3E5MdwVD1tLgEEUUWHB67yqY9TeBO0lINAHnewo9P8Fr8WU4M9ml+8th7iYMMrV1YtE6YG5HejBtFvna8OoiFvMkgeiMt/+T5L4JyURIlHhDPyaQiZ22kEZmcFAxOUUE6k xGO3QOtB vXAVNyVPhvRL6pt3ekZPEujRDUGY0cjArUID/dRqgBxWKwMOMovAsSF+Vamb+NCQSXKLg6XkJPBoQZt7p8fhfoyZjtJb9u4zDT2Tu6lfBj2xHl7yq+qImQoUHXGgvWi90zOyHMGIv9iN1Eb7qScGL9IIYqfCFrOCeWR3A3I6cUyTrj8RGJl+Xswt9YQPu1ybI/dx0ZIOuSNa+o+ggm78vyvvlhl32tRdIWg3WYMgudAjkFI2UyfU0JVr9UDyWM/m/0oeDlFnUtbtIMXAqN01m5vvh1KN8WyfLFJsIuPCDyqFJxXdY0nR6/lahjl4/qtkXwmAWqPkZtFGfdmgQxZ55m7lf7cBTsZkWO0NJiL4d4/8jAvSzRvWHMbFV2E488jRD7/+ReEdmUfDxgZ5BtSTADEtwpzXKzQR/52dvOeohmMcfhbzfXPWPajf/aEhw6P9qZiA2vvYl30sUO5lcJ8O2ghN91+8hL9kp/WkshbsliXGJc6Kmo4IkPM3+8xccJbq11M2kqNIJTkjM6jwg/FBw/Zd44ktBA9KYkF4t3xHcFjvjnjeN8JFURwuFJMriZy2QHGZ4+YbU90BeSYvoNTKwGdf0GTJFPsdWNl9K X-Bogosity: Ham, tests=bogofilter, spamicity=0.019866, 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 Wed, Jan 08, 2025 at 12:04:40PM -0800, Isaac Manjarres wrote: [ snipping stuff for brevity - thanks for taking a look at the other raised issues! ] > > > +{ > > > + 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? > > > > To make sure I understood correctly, do you mean that I should combine > introducing alloc_name() and changing the handling for how the name is > allocated in the next patch instead and just leave this logic alone > in this patch? It's not actually a huge big deal, I mean just drop the ERR_PTR() stuff as you refactor again just after. But this is optional! > > > > 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. > > I put the flags validation here since the flags are mostly used in this > function, so it made sense to me embed the flags validation into here. > However, I do understand how splitting this out as it was before makes > more sense now, especially since the flags can change. It seems odd > for alloc_file() to have a side effect of changing the flags, so I > will place the flags sanitization back to where it was. Ack sure, I mean the original was horrid, so I get it. But to me makes more sense to divide up the tasks into smaller functions (again, I love the intent of this series, this is a very Lorenzo-style thing to do so very en-vogue-Stoakes which I naturally appreciate :) - and this is just another part that is a little simpler to separate out at the top level. It's not a huge thing but I think improves the code. > > > > > 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 > > > > Absolutely! I disclaim any responsibility for people moaning at you for doing this :P > > > > + > > > + 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. > > > > What if instead, we allocate a buffer on the stack and change > alloc_name() to populate_name() and have it take in a pointer > to that buffer and join the memfd name prefix and copy the > name from userspace into that buffer? That avoids having to > dynamically allocate a buffer that gets freed right away, > and also gets rid of the cleanup, since that memory will be > deallocated when we return from the function. Ah no haha let's not do that, kernel stack space is in short supply. Just a mild 'hmm'. Let's keep it heap allocated right now, max name size is 255 bytes so yeah. > > > > 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? > > > > file only has one reference to it at this point, and in the else branch, > or failure case, fput() is invoked to drop the reference on file, which > will cause it to be freed, so I don't think it's a leak, unless I missed > something? You're right, my mistake! Apologies. > > > Please reinstate the original ordering. > > I'm happy to reinstate the original ordering, but for my knowledge, is > there a reason as to why fd allocation before file structure allocation > is preferred instead of the other way around? Generally I'd prefer us to keep the original ordering (where sane to do so), as a user might, as insane as it sounds, rely upon a certain error being returned first, that is literally check the error code for a specific error, and do something based on that. As silly as that might sound, this is now out in the wild, and once so we should try to keep the behaviour as similar as possible. I think there's some leeway to switching things up if it became so utterly egregious not to do so, but if it's relatively straightforward we should try. To me it makes more sense anyway to: < check if we can reserve an fd > < allocate the file > < assign the fd to the file> But this _may_ just be me... :) > > Thanks, > Isaac >