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 04AF0CF9C7A for ; Wed, 25 Sep 2024 14:49:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7377C6B0098; Wed, 25 Sep 2024 10:49:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70E856B00AF; Wed, 25 Sep 2024 10:49:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 561636B00B0; Wed, 25 Sep 2024 10:49:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2C97E6B00AF for ; Wed, 25 Sep 2024 10:49:00 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D2B65140417 for ; Wed, 25 Sep 2024 14:48:59 +0000 (UTC) X-FDA: 82603542798.24.FF13A0F Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf19.hostedemail.com (Postfix) with ESMTP id 91DD51A0011 for ; Wed, 25 Sep 2024 14:48:56 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=En3L9ELP; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=YL+oBEYu; spf=pass (imf19.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.177.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=1727275675; a=rsa-sha256; cv=pass; b=T1DsHO4w0g/juj1hVO3YmJHMCJ3COhz3725zmgIKzF74KPu1dq07iatEs+j6n/ZJBsAu3u qI01fGZNRCXC4SF7Vnkz2xE3BpQuh1cZa9l6KCA/95s7jePSW4b/anpKyy2jteVXGUE+F4 8aDQD4KjKsM+I57NGRkCU7nDZdmG6a8= ARC-Authentication-Results: i=2; imf19.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=En3L9ELP; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=YL+oBEYu; spf=pass (imf19.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.177.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=1727275675; 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=C7TaxZMdM+Vrc9/6HMeXMEH9+0m2FssLJNN3swrqhsg=; b=RPwZAj+pfmpXpoJVYCgIgMiCE+GOTlnauLfPp/g/JMjqauEpcoI8d2G3hEenSdWXJKDRH7 2NjKHPEmwLpLxuZ7EPZbUh+8EAfUYJMm/5sZcPmDFLqlYzMKIpWphHtbr2zGfD6Bym+XBy fgQlm0/cC3b9kM4X19Z4AjMxP4JQIqk= Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 48PE0Xjf025800; Wed, 25 Sep 2024 14:48:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h= date:from:to:cc:subject:message-id:references:content-type :in-reply-to:mime-version; s=corp-2023-11-20; bh=C7TaxZMdM+Vrc9/ 6HMeXMEH9+0m2FssLJNN3swrqhsg=; b=En3L9ELPplf6OwjoHo4QevS/2EHmwIU LMP7FmWik6uus2M+i2qegMZ+nlAe5DI496JvthMXav7Sa009FeZxsnTz3C5J/CzV gnyiV8adtLBnSwmp8H2Ixlkp3HN3dr+p9kSQFi7IlxItP9qcSoTLCWevYnnnaqTg Ema9suP5FGElysfQ7hH/46bv82iaXnRW6ihPQbVqgc3x7gadabVpnvIlkLam87Yj UM4ndsRzE9VpmciSD8HFSR0rCgT0N7VDIikc8xySwFHNemv4e+z+VXlWz3wsq0jS h8TdjnIMO6qjhs7dR6g/c6hDMauc8DDUV4As+uzlAHLcZ1WOq6HfvLw== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 41snrt80x4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Sep 2024 14:48:22 +0000 (GMT) Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 48PDhaXN031138; Wed, 25 Sep 2024 14:48:21 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04lp2048.outbound.protection.outlook.com [104.47.73.48]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 41tkc7bccj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Sep 2024 14:48:21 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YwIB6Dabxnn9vNaYQicjMdv4ty+l3N0MMiCru5SIhM48+CHeHiK6rjMAP8fnoZDaWlpSoBS1cjlOb8RJigu/Drs/H51tVgiVOCniJxUFJDC9MvKxt5atjDLgJGPjQdSFsrqBDMq8w5dBfm3q6eTfKUEuda6rdPmQx19kd7Lwbm31sskOSQyPm48zLPmJPjylXpn2hV2OQt9S3/LlQ9QlksOnrkZm+XGyusb1BJtHcUjj7KwFXT4CrKt4SLFSkKDchb0jOAlNEAVfr7QqSYYoNG56ayupMYwg9N7vGbC1pUBetno4KaRQCX/Y9z9fpPal4X2+BBHGR2cwSFey5qXiew== 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=C7TaxZMdM+Vrc9/6HMeXMEH9+0m2FssLJNN3swrqhsg=; b=bSIbcOm9qh7XdlGn8OEoZOElEo9izCGq/TSC941PWVkUzZSm+YlW3Wm33pnQ2LxwY0qqBd9m2QONpcjEFAnvtd4Yc1oaXllO8S/H6SAzHexc/yM+KjukUe3Ev7eZ7lAcBw1XEsIX2aq/0Rn2/y6I8rtvKCQeIlfnkSmyMiliK4PeLMWj7DwS/fphe5wRYhNvFnMFIf/IggMGJ5ffHFSuLmQwd7puy95wdXOWkgpScv2zg4JrVSktbOljGgov5i9EWx1AoBwnhC+kg3VDvhK432iszJdWWsCaeJLts2ogAnQ/TXvq+pWcGyxZeWmTHuZqfBAbS5QS+1wTdPZ0Iz2knw== 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=C7TaxZMdM+Vrc9/6HMeXMEH9+0m2FssLJNN3swrqhsg=; b=YL+oBEYu68AT5860TuZMjJQfYKQ0UjFcFXxabb64voNctc+jUnryndPeTaRUaDkznF9GtG/yY2fcls+vgmLIrHAmhcmYpXtlZ4HvAoEFs2u6YliNUA33+s6R5XI47le/drN5GUYiTl6MNnPxVXgIVOSXU/4SP02vtdNKWz/gOW4= Received: from SJ0PR10MB5613.namprd10.prod.outlook.com (2603:10b6:a03:3d0::5) by PH7PR10MB7009.namprd10.prod.outlook.com (2603:10b6:510:270::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8005.13; Wed, 25 Sep 2024 14:48:12 +0000 Received: from SJ0PR10MB5613.namprd10.prod.outlook.com ([fe80::4239:cf6f:9caa:940e]) by SJ0PR10MB5613.namprd10.prod.outlook.com ([fe80::4239:cf6f:9caa:940e%5]) with mapi id 15.20.8005.010; Wed, 25 Sep 2024 14:48:12 +0000 Date: Wed, 25 Sep 2024 15:48:07 +0100 From: Lorenzo Stoakes To: Shakeel Butt Cc: Pedro Falcato , Andrew Morton , Vlastimil Babka , "Liam R . Howlett" , Suren Baghdasaryan , Arnd Bergmann , linux-api@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , Richard Henderson , Ivan Kokshaysky , Matt Turner , linux-alpha@vger.kernel.org, Thomas Bogendoerfer , linux-mips@vger.kernel.org, "James E . J . Bottomley" , Helge Deller , linux-parisc@vger.kernel.org, Chris Zankel , Max Filippov , christian@brauner.io Subject: Re: [PATCH v2 1/2] mm/madvise: introduce PR_MADV_SELF flag to process_madvise() Message-ID: <7f40a8f6-c2f1-45f2-b9ff-88e169a33906@lucifer.local> References: <1ecf2692b3bcdd693ad61d510ce0437abb43a1bd.1727176176.git.lorenzo.stoakes@oracle.com> <4740dfc7-71da-4eb4-b071-35116288571f@lucifer.local> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: LO4P265CA0081.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bd::9) To SJ0PR10MB5613.namprd10.prod.outlook.com (2603:10b6:a03:3d0::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ0PR10MB5613:EE_|PH7PR10MB7009:EE_ X-MS-Office365-Filtering-Correlation-Id: ec602292-2ca0-4505-258d-08dcdd711467 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?P4/cwAc3Lr/6kTh5XijW9czhVgzamrg3G2q94pEnzZ3JF7G5TI7gaEunRr01?= =?us-ascii?Q?kyHHHan5bsIW32z2LPXS71s+zt/qA0MPhV9t3ePyS1pgqLWMUilJfzySlaY8?= =?us-ascii?Q?h/BvIRqY6V6LKVP3qvJtvXuFDFJf4Xx+4wIrgVX+x+0QWW3oeKas+cgBgfeV?= =?us-ascii?Q?lALXWoxd3myx48rVywfgawywhKwW1XtaB1AnsrEOyk/lz7vm6/LNbwub4tOZ?= =?us-ascii?Q?giJpChm8jrxMuZEEUXnqI9W7MJO/kMSRc2R5LiTvQAvX53yF9YSqBT38D4LX?= =?us-ascii?Q?VpbXxddi3BYEPZvOD7EN5ooAbLihwWtW1keqtHu0vsIA55SFBcT9Y7dljnhR?= =?us-ascii?Q?c1sQhjgt5cLVBF63PPvLfGxWm4DcdXLwzQJmSJSNEqF2x4WUtBFmwRPycoxO?= =?us-ascii?Q?WuDzVtsacf41sUmfMx+VSR28guoNocs/aFhHun6Mw4VD6ZILHmc75aaMVKE4?= =?us-ascii?Q?n+WsyOIZNwUGUlVB05zlBqcxRBuY0bVL1s3OogDEBaJyqIEwiTxYzlIiVzvS?= =?us-ascii?Q?L8PfG2Hxj6HKQWZEUNVS/lJpwEX/5HRfWZ3HRWda+J9Dxm5yOI1VwO1+cQUV?= =?us-ascii?Q?zr/EmCxGYsGSLEQkEiYfkBZ2kn+GxjEjGdzNdD6A5Yex1y7r/hpusPvLoVH2?= =?us-ascii?Q?KoEhXGF2rYbxToeJvGlkCcOpD3oUCSD9qF41tfVU/hvr/NhpTkRqdLFv3N3z?= =?us-ascii?Q?LkzvJ0hbKDtORRNb+uiPTH+jhky+SQ+sUgiUWB0s7XvBWJnHl2p74vgLDmlE?= =?us-ascii?Q?7KRUBPT3fBknkaC9OTnB+feTOch7FUcB1HNMBCVhtqZAn58nHrEyLkJyXtxA?= =?us-ascii?Q?8oJcQBWyasIqtqcLsLKioVwNAqSFHjjmo05eAXx3PQvu0N/0+UPyyjox1z17?= =?us-ascii?Q?R7kd44mnuE2IO2R5OSzmg4sDz03pAJVHdyiFtvTP9QUh2ROx8VzdgyEp+8Np?= =?us-ascii?Q?VylR7vfXt0cTVVf7HNNFyaJ+ywfx+BS9Ph6x9gOM1KBZu38A4iyS6TcWZIIs?= =?us-ascii?Q?oCXYyRi8Bqj4AeLVG2PQbMU2zXoug64YfgNYQsgURdgSzQ+LpwGzG5Gds9VE?= =?us-ascii?Q?5Bgj1wJv1guQCryacog6sarCjHNEyF6K55dI9+t+CN+rNpne0sSzWgLpBScz?= =?us-ascii?Q?k1y5qB5d4KbXjWe09T4Ipo97Ku6iksANIaDe+bepDpBSNBhM3shSvRgiZbOQ?= =?us-ascii?Q?H3eoFsk4DmmKSS6uts1QQVki9dWQLsyaf8f2PZe4JgIt9lu329Vm9vbbpzB9?= =?us-ascii?Q?JcgnQrbBWq4Yv0lMrLqxr1/rhvzs4rvJl9B54JiSz9WahhcAm/PQOnSwrCKV?= =?us-ascii?Q?wXBwpvkrTQvLLctRC5xXOLZCmcnbaPbpRKhGNr7Xj+0WHA=3D=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ0PR10MB5613.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?UpgIfQ9xVmfy73USrWSnL2pbdDDTbOhEpRqCl6Gq2VHHkl7NEq+qeklFX+Hm?= =?us-ascii?Q?zh5ogB0GxBqGTuw5KWhp0voE7/7CxibRO+cnrLJe6DYk34Xo4eUgSWpzShF7?= =?us-ascii?Q?e1XEBw91TkO7tpp1aA3dPRVPv0xf0NF7fostsu94Svfgzpc/KbblCyHHJ6KC?= =?us-ascii?Q?6lIiYSTJOnDjssI9TgdnaOuKJjkm3qjA50Szgb/KpV5nN+E938F2tMb4oyw0?= =?us-ascii?Q?1aTLqLqy9Wcd7ZrEOy8SrKPm2Ed1oD8BkIZ4c8VnGFpJ61wZKq3RF1e8JcDe?= =?us-ascii?Q?4kkY1YnQiqs2p8pzI2gIOuIs/CKuV+DBWi2mQjVmMOdIANyviJpEaQznDJof?= =?us-ascii?Q?JmICOzYmLPtBBQYfTmlDOvL7NC+6f4uUMoapRNDPA4e68KWOTwV4Pp5o1VUS?= =?us-ascii?Q?pG8Wfkop6oS7l90igOtF9DFfU+iz4h3r9PoGAcDDz/Dwy9YzYnN0w1+5nH3a?= =?us-ascii?Q?SHB/RUJQGe7lN2uXuRbolaZMAMliBkiBErTb/WnbQ6+eEoHc3w2LM+ZPAPae?= =?us-ascii?Q?ryBqb9yINdJC/HRPNc5VXJYq07CWTI4SkWLkLFfbqilld4FAyVpHZHgOj46S?= =?us-ascii?Q?zmdbX1E2uKc0lWgZn2ga3s0aJycYWJ+7yifmc/mmLGdt8BEBZ0sq1O+33erl?= =?us-ascii?Q?FKWWCupJWo6b8p1BenPd703l+nfmXbJiyehAE1Q0EKsrrY4nr5O7vwdHBshM?= =?us-ascii?Q?j1oeM+qhJAyibVdcSSCZ8coP4fUKCkwNFCimz8d4DnPOP+2+PzwfMY1e7J0z?= =?us-ascii?Q?PQQ47UZKEqM343rsYSsy1lrWjBtf/xef6alwT+37gF5zPX1Q45zBX2301dBd?= =?us-ascii?Q?debD7iEbLEH3RKZMSuZde8qmvA5eFRiNQaL5tfiK3CiOtcmD1JRDuioF7SKN?= =?us-ascii?Q?J27lrvfNeCBaf4sajNntcBYbVuDlE3aeo9YBLJeP0eaBxNe1ndHOX4zaSbC9?= =?us-ascii?Q?uVQLN0qDgViIeTOzwdusxOvsqW43IN1znBJ4RpET44474EEJECgXCCSee//2?= =?us-ascii?Q?p0yinfweAOG4pdMv2WizT3n5Q64QJd9C3MMHbDJj0fueBDMBRVIMY3fz5zhV?= =?us-ascii?Q?JD7Jfr4rqzk0C9jTWs6H84d4J4rd6T0swvqNKREAtHRifK6rPh/rurk3TjsM?= =?us-ascii?Q?yil4C9Now8D/dmNKfEaYmUSPE0HwT8toEOo/B3EaumPfQcwFwgR9fNjEkSuh?= =?us-ascii?Q?Sah87B7dAFsz6m4nnef8nhQuwxBNVwogQ3hKEfpThoGcwLXBVErZroe3qyz4?= =?us-ascii?Q?YnLqkKDud/QHq9MbRXdUitPCFU9dYPmMy6BUbQkh/vT2NsREdSAmiy0xtBG9?= =?us-ascii?Q?yDrncKM6yGfV/wsnhL0qX/63WTHYm9RwxLJ3TUcCC95pKSeTPnogspJcrQx0?= =?us-ascii?Q?6D6lxHZ7oKjOc+68ETy+t5ZMynN0d3BdVU0FCafLhS2PQAJCkTLNBf3gxwxr?= =?us-ascii?Q?FQlhrVKSBSougl/k63KFmP2BmrxqSOIxlpSSHgeEQ6M92FGU2K6U1D44xDhx?= =?us-ascii?Q?RfoDxJUQlJA+8LTvjxNANkFAIiFlRFq7GNGLUVOj9VgcdWan0fYYjcyVjiXG?= =?us-ascii?Q?/DLLlesZD0YEh8zE0fTZzztiGrzFKKKGN8ZKUgiaQtkiM/GcSH+KPDPTWz10?= =?us-ascii?Q?+A=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: zYnult71UWzSOgqLSqKGEGMDCnd0OVbr2VL7qYQTzl6G1r1rt6UGPV3TwPEa1OUHXA/PcyW3SJL+XxVxJ5bGuTWt7wX+hOcHvY4GGirI1v04i0jufxXNA9u8CY0FfY8XFkBrT2nENuIvCz1v49o/fQNMRzovZ7abR4UXn26CGtmLkhVSVliumqXqx0dF3M78uRDuG7NsD92frn7AV+TqvDF2fwwN7EUn4/QwYntQ8Kx2QhKvnuNm3GR1PWmuzQAkGPAo2g14fzom5bwnp3xwFDghUfpsuMR48OvlXh8HJ+DHi9ol7nnknQzX3SwKX/8xNps/z4LCD4A2e/jdXTz6EbMNjqtxmqeVn8ALBm03aIpqnvLd5pZX5KH1ACiHT/uCsXdCjY0fnpsS0IHfyX/0JgZ7Vik2X3XqwcMJ6EOiDR9F5P7hSrGm/wl1a6TPsBY2bgyz10/oRVNda7NHFGWgBBsLS1myZY0tsT9RMXBBNP+STRoudgT9Ky+JkANUZT9dFsrdfwQr414EaPvF07+ZT71iPV+L78wdEYJdCYIbS0/CdS0JIVmmWYyBwFQYmbOpOnXcRy/Blz5o5OmGbMbfBv5fP00h43numas/0+gX/Kc= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec602292-2ca0-4505-258d-08dcdd711467 X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5613.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2024 14:48:12.4863 (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: uS0LhRBN3x7QGLej4NCTbL1Enp8N9UJi66vFu7paKhgx3cfW9B40hh6vISW8KJzeqS0fho8KAgtSM+gh3VlO467u+SJ1LVQQEuFAL7Q1lgc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB7009 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.60.29 definitions=2024-09-25_10,2024-09-25_02,2024-09-02_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 adultscore=0 mlxscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2408220000 definitions=main-2409250105 X-Proofpoint-GUID: Xwuo8DD0ab77DQ-v1RWa5Ov2GD3BCGRB X-Proofpoint-ORIG-GUID: Xwuo8DD0ab77DQ-v1RWa5Ov2GD3BCGRB X-Stat-Signature: k1gm1be5jiq1mb8wt5pzpknjzo6jf5ni X-Rspamd-Queue-Id: 91DD51A0011 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1727275736-698433 X-HE-Meta: U2FsdGVkX1+G1aoc4RguuUnks3e/RzI9DvT/Rs1Y6s54WXbwrbbZdg0txlol9rEQ+ORj+K82wme40e5K3tIkUIJizS250tfwNL2C1xge+2yfYI6GmvMvEK6BMBuv0wGnYFmQdpHBnSmUJfS0IPDj9nfEo5cP7Q84Jgbz+/vhL7RWP5tW1+OTuTKVmKroT2opbR7a7NlA7QJx037VyKxHpVODnbPdTyB/ZXMiz5i0shvqxZwXza+ZH0KazYWwa59oP+it33m+z4nMnkf2AKOyUmvN9XtSUndX+G+YoQVfUsB+qLjxogIWWmsneuo5yvbxL2IJCMbQdyo4BEoA3UFmpmi843vqHrJfop/oezKEYuQ8Fn0rZrGKna5FYnBK1HzkEnlie0FBdwphNajglJ8nXrmweO/ie8Nzd5ucVSTHr2gwHuYtil3f4fV8oY7ipbo4P4DShUMBsJrvEYoAXBSLlYW1bb368IX9Py6b4luMMA2pEulT+83ax6a8M+aeHdRM2OpC5XOHxDdMsgc9/KtM4qZytMCn5Nk50YA3bjb0OcRUWCoSHLVuE+b+VRDZZc/gPlgMYMstJpbQAe88IJ2a5dnRqB22egP04lB4P2pUMYMWQ4K6qXzrJVVL2zDIOAw1tYfpvZtxn6tN73XqT9EBnfzABUSUsK4EakQ9QG1RcTX0Fk9084pilxifnODlxFjX5r6fKcZFpXMDVgkG+OA3WnZERJQqr9mGNOHG+nLbHKradzhohnc05oZlbpVNnIXKZsuUYS1oJw3O5v+2NCe9KxU5out4HNAfQiUTYqyBEm8Fqhued37kssU5fvRRV7QmVf619E/teYMtVKZFLEVd7fZhgzTiB2mMxOERqOerotuKrOu6WMJwpVYbD7iGCsg4aVapRQms3LFCn7qOj4e7e0mLtw4Q9xKFR3YwXIuJjHFNiOpUNgjLtyMeMB4Z5dWSiM1ungIg6N7Cq5LkcHW xVnd35t0 2TnfYUf63EJIfRS83RLy63K8Tu/nihLeBRuKl/I5+ydQrYr4N0jPEzDHLIrejhw5rbo8TbD1NbgHPlry2MJUBaIwV7MUAuJrgHx1LLn/jxgPROfAhomgTIdw6KuqcRpXp+nJEPAIXdm0yE2k7PS//783JwOQz8ZN86iuljXJQP+j8lWtqB5v2/DoE14F6HAFl8HQ9olU1UF/06hddhnWgFOdUXM/e5JBYRcTV42xADZHUpII2hFQ9WFg0pTlfeNgmDad887OQIN2Co6SFUDjJQQ0to28HbasJfHdkbEWw6s6sddFQAS7PtiL/VI6DBHOnCAfe7XljHQOa9UlBJgrd3MChFIpHWrAxd4oL2ZLt1TRjNO9Eqt3J8A03j8+XZjbrv5CC5FPyahvUUqpqIX45K502KDh8WTB2HkAr06CD4BrCpLlGLRTkz/de//VWxNP4ltighVyPagfr1bUzcXJtQ26h71KI24MPfT7/Wt7LVaZgOX9K1AhA1fqVp8QGR5jFIE7RnZRyCcLduS/Jm2GQHiDcf2GPhLr7eJCaAN75Gud/txgWXovdM9taxehl6+KXAM3mfelPe55jRzr172yXdbwauWbIuMgnUXSyAnLt8XUSnBg= 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 Wed, Sep 25, 2024 at 07:02:59AM GMT, Shakeel Butt wrote: > Cced Christian > > On Tue, Sep 24, 2024 at 02:12:49PM GMT, Lorenzo Stoakes wrote: > > On Tue, Sep 24, 2024 at 01:51:11PM GMT, Pedro Falcato wrote: > > > On Tue, Sep 24, 2024 at 12:16:27PM GMT, Lorenzo Stoakes wrote: > > > > process_madvise() was conceived as a useful means for performing a vector > > > > of madvise() operations on a remote process's address space. > > > > > > > > However it's useful to be able to do so on the current process also. It is > > > > currently rather clunky to do this (requiring a pidfd to be opened for the > > > > current process) and introduces unnecessary overhead in incrementing > > > > reference counts for the task and mm. > > > > > > > > Avoid all of this by providing a PR_MADV_SELF flag, which causes > > > > process_madvise() to simply ignore the pidfd parameter and instead apply > > > > the operation to the current process. > > > > > > > > > > How about simply defining a pseudo-fd PIDFD_SELF in the negative int space? > > > There's precedent for it in the fs space (AT_FDCWD). I think it's more ergonomic > > > and if you take out the errno space we have around 2^31 - 4096 available sentinel > > > values. > > > > > > e.g: > > > > > > /* AT_FDCWD = -10, -1 is dangerous, pick a different value */ > > > #define PIDFD_SELF -11 > > > > > > int pidfd = target_pid == getpid() ? PIDFD_SELF : pidfd_open(...); > > > process_madvise(pidfd, ...); > > > > > > > > > What do you think? > > > > I like the way you're thinking, but I don't think this is something we can > > do in the context of this series. > > > > I mean, I totally accept using a flag here and ignoring the pidfd field is > > _ugly_, no question. But I'm trying to find the smallest change that > > achieves what we want. > > I don't think "smallest change" should be the target. We are changing > user API and we should aim to make it as robust as possible against > possible misuse or making uninteded assumptions. I think introducing a new pidfd sentinel that isn't used anywhere else is far more liable to mistakes than adding an explicit flag. Could you provide examples of possible misuse of this flag or unintended assumptions it confers (other than the -1 thing addressed below). The flag is explicitly 'target this process, ignore pidfd'. We can document it as such (I will patch manpages too). > > The proposed implementation opened the door for the applications to > provide dummy pidfd if PR_MADV_SELF is used. You definitely need to > restrict it to some known value like -1 used by mmap() syscall. Why? mmap() is special in that you have a 'dual' situation with shmem that is both file-backed and private and of course you can do MAP_SHARED | MAP_PRIVATE and have mmap() transparently assign something to you, etc. Here we explicitly have a flag whose semantics are 'ignore pidfd, target self'. If you choose to use a brand new flag that explicitly states this and provide a 'dummy' pidfd which then has nothing done to it - what exactly is the problem? I mean if you feel strongly, we can enforce this, but I'm not sure -1 implying a special case for pidfd is a thing either. On the other hand it would be _weird_ and broken for the user to provide a valid pidfd so maybe we should as it is easy to do and the user has clearly done something wrong. So fine, agreed, I'll add that. > > > > > To add such a sentinel would be a change to the pidfd mechanism as a whole, > > and we'd be left in the awkward situation that no other user of the pidfd > > mechanism would be implementing this, but we'd have to expose this as a > > general sentinel value for all pidfd users. > > There might be future users which can take advantage of this. I can even > imagine pidfd_send_signal() can use PIDFD_SELF as well. I'm confused by this comment - I mean absolutely, as I said I like the idea, but this just proves the point that you'd have to go around and implement this everywhere that uses a pidfd? That is a big undertaking, and not blocked by this change. Nor is maintaining the flag proposed here egregious. Blocking a useful feature because we may in future possibly add a new means of doing the same thing seems a little silly to me. > > > > One nice thing with doing this as a flag is that, later, if somebody is > > willing to do the larger task of having a special sentinel pidfd value to > > mean 'the current process', we could use this in process_madvise() and > > deprecate this flag :) > > > > Once something is added to an API, particularly syscalls, the removal > is almost impossible. And why would it be such a problem to have this flag remain? I said deprecate not remove. And only in the sense that 'you may as well use the sentinel'. The flag is very clear in its meaning, and confers no special problem in remaining supported. It is a private flag that overlaps no others. I mean it'd in effect being a change to a single line 'if pidfd is sentinel or flag is used'. If we can't support that going forward, then we should give up this kernel stuff and frolick in the fields joyously instead... Again, if you can tell me why it'd be such a problem then fine we can address that. But blocking a series and demanding a change to an entire other feature just to support something I'd say requires some pretty specific reasons as to why you have a problem with the change. > > Anyways, I don't have very strong opinion one way or other but whatever > we decide, let's make it robust. I mean... err... it sounds like you do kinda have pretty strong opinions ;) But anyway - as to robustness, again, could you please provide examples of possible misuse of this flag or unintended assumptions it confers (other than the -1 thing addressed above)? I would be happy to address them. If not then let's move forward with this useful feature?