From patchwork Wed Oct 23 16:24:37 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lorenzo Stoakes X-Patchwork-Id: 13847466 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 90BCFCFA44F for ; Wed, 23 Oct 2024 16:25:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B0936B0088; Wed, 23 Oct 2024 12:25:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 039C86B0089; Wed, 23 Oct 2024 12:25:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA73E6B008A; Wed, 23 Oct 2024 12:25:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B3AD16B0088 for ; Wed, 23 Oct 2024 12:25:17 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2BEE3A0D58 for ; Wed, 23 Oct 2024 16:24:45 +0000 (UTC) X-FDA: 82705391664.02.F4B834E Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf06.hostedemail.com (Postfix) with ESMTP id 629C9180024 for ; Wed, 23 Oct 2024 16:25:01 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=l3WCRLf9; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=frhKhE+Z; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf06.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-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729700562; 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: references:dkim-signature; bh=YIaSkUfezHF43aJ89agPvSR9qTUn5gfna/f60qXuHk0=; b=IqLzQf1+jzI/t9H9PDDoRjM2A2WGdfxfzuvVRLdCKwzlM+uvbfXZA948yJnRL8R/6+EGLn 8ed3PpFBOtzYRd6vHzXUb8/05j5LHeA6AEDGyn96x4l53cexW7MwEyI4a8Qpcv7MHcVt/r 2UeeO+JnJdCp8v8wSqZiX+L+8syi93s= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1729700562; a=rsa-sha256; cv=pass; b=qNeY+b7LXqDcFV+HzFyvmRpHzQLm27Gh8aPiKvuvcNequi60IRA7sIeDIq56lFT8JRu8uN vbMcWAYG1rANJ9nTqLMUl5lSfwKhlqnt9EHSq1GiUK5vDUrQtNZWumpcoiroUvCDvaHmfO uTu2NzvkdNLsTb2xyvzdFWSpJ7vLBGE= ARC-Authentication-Results: i=2; imf06.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=l3WCRLf9; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=frhKhE+Z; arc=pass ("microsoft.com:s=arcselector10001:i=1"); spf=pass (imf06.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 Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 49NFfexa001648; Wed, 23 Oct 2024 16:24:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to; s=corp-2023-11-20; bh=YIaSkUfezHF43aJ8 9agPvSR9qTUn5gfna/f60qXuHk0=; b=l3WCRLf9oxSgFp7BDmGpScb4xpww1KWS hp8p5oipfZPX1wKT+x2hXTYyhxGLpms0nEu6mcGnNDJcWYISzkFC4u8bIEMxJ7s/ PZ+6QUIC6/LSxDnl9Y5988LpQ75Y0ZULtAupMSlqbQf35gkJ9x0sHdCetIzIzPwV lVqw4puxn1ZzUHNFFK/QLqtAmdOlWq7VWNUA6I3Mw3nhN2PHs3wzg1QjBR06wG1c R9JwM9gWgHWG9IgLrMBySri9J5RFl/rFXDvgygkorGEn7vkdCYlC4ZLqMxHxCxke b4qBW/mUsvMlMDsbSqXX+uokEZLSY7UMWNQVap1XhM5NAHUQk9dXqA== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 42c57qgkr4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2024 16:24:54 +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 49NGDJOC018405; Wed, 23 Oct 2024 16:24:54 GMT Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2168.outbound.protection.outlook.com [104.47.57.168]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 42emhjs6v9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 23 Oct 2024 16:24:54 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MsP5+WL5H4J/sWVF7M+W/62X7SUbcpb5MuGWDQEtp7dfrbpCDdgXIo994ZWMXDtIDLmF2dqFdQAVA1Cz/E1B5rQMgJSz5iMCmwWndl7QNyZwxmTHsiRmsjdpRuWnAtQLm2wuCgjsr2f1X23/cih3tRgduLQJ63pk75pG5WjT1ZQCOHrGOziMAO4SpxfqTwn6cjPuREQglajCl2KZrxtF39jbupo9jAnZb2uL6Yvgxxq/WR3vlZX6UELrOP7yJk1xE2ayiQHCJstkxNgqOXqt89uj+phS7KWnB1HACGtThkggpafkJH3JrAr/cfprUuObfgpJAl9AFLuQVngIsJTx/w== 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=YIaSkUfezHF43aJ89agPvSR9qTUn5gfna/f60qXuHk0=; b=ArJ7Ib21CrPu3B5H/EZflv/TvVQbZxuZ51vKou9dWsMrLTvCZhqODVEwGCvc1ZuIxdPgUmEGeeWzXIXIwNRMF9c8ewdi3FzwRBDakm1+7n9630i3S74gHRU2zhraekuYFRmDOsiU9bbJi7JKgwS/3+FaXnqPsWnuaLuFhOn2vp27P/qwLZ+uynLviy3x5YCKdb5APsVIfY3I3fNoNABKDwA6yoMDKIHqPEBvOwg/OfUMQhtjRy0WeFLUxAuo3sVyqwFIiMk+xu/r8p5fMHf16aJf7E33/2MrLLTDVd2CWWo6EXB941wIg1OTbMUr/RDBuEkV02QFCPGPWBssHN3hHg== 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=YIaSkUfezHF43aJ89agPvSR9qTUn5gfna/f60qXuHk0=; b=frhKhE+Z3UPOSp6GWc1Axw/6KTghS75sORJyU/w7ESY0SzQaMoH8c7psCAFdVqvAWA7BBuvMRIVfp3M7wm2Okmkv+MNkJpX8FytBYeGZtoPmGsx4RpfwMc46dYc7EIpcEMP2ZBRRGXkOhQKUnlI/OH0MlPY07Hr7gPN5jQUBOBc= Received: from BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) by MN2PR10MB4320.namprd10.prod.outlook.com (2603:10b6:208:1d5::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8093.16; Wed, 23 Oct 2024 16:24:51 +0000 Received: from BYAPR10MB3366.namprd10.prod.outlook.com ([fe80::baf2:dff1:d471:1c9]) by BYAPR10MB3366.namprd10.prod.outlook.com ([fe80::baf2:dff1:d471:1c9%6]) with mapi id 15.20.8069.024; Wed, 23 Oct 2024 16:24:50 +0000 From: Lorenzo Stoakes To: Andrew Morton Cc: Suren Baghdasaryan , "Liam R . Howlett" , Matthew Wilcox , Vlastimil Babka , "Paul E . McKenney" , Jann Horn , David Hildenbrand , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Muchun Song , Richard Henderson , Matt Turner , Thomas Bogendoerfer , "James E . J . Bottomley" , Helge Deller , Chris Zankel , Max Filippov , Arnd Bergmann , linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-arch@vger.kernel.org, Shuah Khan , Christian Brauner , linux-kselftest@vger.kernel.org, Sidhartha Kumar , Jeff Xu , Christoph Hellwig , linux-api@vger.kernel.org, John Hubbard Subject: [PATCH v3 0/5] implement lightweight guard pages Date: Wed, 23 Oct 2024 17:24:37 +0100 Message-ID: X-Mailer: git-send-email 2.47.0 X-ClientProxiedBy: LO2P265CA0019.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::31) To BYAPR10MB3366.namprd10.prod.outlook.com (2603:10b6:a03:14f::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BYAPR10MB3366:EE_|MN2PR10MB4320:EE_ X-MS-Office365-Filtering-Correlation-Id: a55a89e1-d097-4825-a5bb-08dcf37f35e2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|10070799003|1800799024|7416014|376014|366016; X-Microsoft-Antispam-Message-Info: k76CuCBAKdz2KU0J216SG7zVb28L1I830iRV4F4/iQV+KjVSsj3Y0kbcZKC3dzDcSxg5ZvwSx+EazYftX3tFfqNiWeM3ksDztLKEpLE3SYLdgLKBcaouG2ZChfZSchnQUPpci86D9wmhAnTCpzQ4W63oOBG0/mwOX0hTFVnJW41oba8su9eWUtnFtL/XZUepp47779PuHL3Bs4mz6Q2DCwWehxqIBwzTM1ir6cMfxROBlCiEzdCjiAbqSGwW9OYgCCxnjI5Hib+qjHmSC4A2t17etYsidaBsGtsO/Eqafyz232kT2ntl/ptK2ICtMUrmCPi1sM0VHhMgvsCEWJXoL/TOyXQzWcnvHay+JoXamCugEXwN3Dz/4AkQDcoMZlrkkqa/jSSNZoSUL/rHP8+p59kePN8QfUKrGXFNBG+T1PcNekz2WccNWGDEq/3r4/9YtKCi24ML7dyvUAcjeWrL8UNTxhmT79BRalQVGf+CR78oSJMfG4faMp39Vkyr1QHnlPzHnebT0OxhBjyawIhwkmG+YlVtN9pmfmdZdh+yBFshJk/suyz7s+4xOku2RbD1PDqdqay1LkJ8Nbg0gLXVHcSLDPF0WwE+PgcyDPz99nqec4eeKGOozpp3x+6j8TyxrK81YI1Wh9ZCLg5AW8/bRe3xF25cv2hyIPVN+QRacAFSiaZ/Z9o/53JCJ+sg6kUBgjjOUzQJAo1PNYWOMm1iqlrifzl0CQAFndioA4zQI7Ye1QLsKma41JBFJyD50+b3OpwHDYqxKZbJfHLN9f0rlhHL9pCFn7UbF/7q/fU7oRm2sbv+8NRuLVdRnHdzQ4pkwempDM7dGXqX6sEmKU6GxSLsN+gvt4w1CNW1khYfTlbWLOTAHbYclTUDjIqanhAHattPEoXF5Xi5FPIFHGqilkaCjqkgfE842MHggQDDGhgM7EdrKBIbjPFi2CUE9k7nCEZZseR1cXlSoAUfrejHWgiLrgwoNIs3P/B3USi4vPGgFXvung4O5yrZmNtAxT8NKQqzkA3BVBPHDUUrq2fq9qQ0Z/DWWSsIpYNdNEjH7+8OqVN05YpOHzF34QzODLtLDNGGdEJ+uKBL15BWztl8kUMBWaIZ4PQSHi1Qvo6LLKN7cgcCIW9xI8zObm8iRwaQ1w3IMHMHYk1zXQsWNkNNZBQ+xMakUJexXLxLpzD8KQzYTJYYS7kcjsvQExHfkBPks1rU7gFb7ctmWGNiumMEgf8R5wRQK8c73XmYV4yOaD6p+LfFVvpEkhj2rKLbkrAck8LV8tvxLa/9G1szkHEGnXfPWdBQfLSy4r6EvNrU9WL9WVtrMCKJFXO8mptaH8dN 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)(10070799003)(1800799024)(7416014)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: s5OsK3DIT5Z5e0r4Cf83Jb3PlskuxCSl5kMn6pWO8yWgSS5fXOfqt9e6k+qwa0f+p6dENvNEuE11gNVbzCEpCAx0997GV1Qz3Zsa6/h/b/7oAk5oMoYPdOzvxdy+6mFdpz/0R2mv9nTD8fMF57aJjdERf/ISKIYfV6VjK/ED6tIwvYeLJcCurW5QjfVMp2TgeCZ+gVbHxCsm9b98b78J97HXaRZkOq++2BnCnpFO/WbYx5Gx/voEkqNro9I2XLcS19Pe0Rb3Jk+4gMoVzOWkhPADK2HihddyqasC1uCDrbSUVCrf0lW0JmU6Pnks4ocXJgPutyVAEH+5JHkPA9xIbgl2tneeJWBInAGJG2Zhxt7D0QrK6nI4iNJAEvkm/tp2GwAh8r+tj2uviIe6QgmQOJQErkqTxnRLKThN1ca2FiIGmGvoEO+/aFD2qW0srm9KEvOos3hsUOicYZoguJ2RqjDymkUisZW1tIacdQfrRaucrKY4pPiZKOW0q6Dm3/zri3eZ4XTfbb9Kj5svpT9jS+3QPtkYsHuLTBRNkArx9w0aaaFvLcP9pZ79AOkt/6WJThSIL4CcaqSb6SrIz4G2e4ZEWWcyBPHQ+s7vAuQeSOs8YTosjgVS2xjDHTqsGOrkDPrcziE04gw8REfpq7DbEjfKhlfiEmrTsNvtNIWKycnzreIaLe4ZpMiG78Be6H7XtlxfLwE/DH6cCSbOUw6Qf2S4ahvxuE9JPlIk1kK+wunLFIe1uup+mPUap6guEaHW0Ar905GtO+zXjTLDyKZDiXPq/BZh0Nu3PmjaJqInAanhSBCkv0EAo81W65xCPnxEs1QTIDnPB9iC/jFk1V1oQA1qq+oYXBvWMQsIN/OopNzOU+i/HQ1piLmR/l2jE51CFrORMMRNe2bVzLCHQlBs34+MBXfRitqIzT+h/z2g39Iq2ZElfyULxECFs20KkB74PSrmemcE7++ZhVtN2chEsWNwCd9T/8MFWUru97hpEwDmLUim6/go7gmO31YXBQ8ewIPhyzRKELvW27KAtH3nRS14oH1orS7Wy5VEAHzAMnNBrW4SKLj2O03Nb2x8LnFhI6HMcE2EEf6vMX0BDMxaQvTee/ykzItJ/mmeIYQFz9ZI7b2VdjTLxlJvMnz+VYz/EIwPPVHnwGTkudOOCIKzKF9bZnfRYIAtPcbyhua4HIzBFV9XZn+Fyg1W8Wpb2tVCfeTdI4k8208HO6otVDYoZZO3G3eKY6oVeqOMUR9ZBBMKT1dZxltpHxWyqupJctXhwhSaKhwoWYg5ZEQzk82vTutDXS3xh9l/tcy+KL2noLQ4jWAg7EWIdD7kbxIlOudh34vfsKPtU7zqdBM5AK6g4RyRxuPbMI6npoAurXzNE9kStl4/NaKv7/JQLxbU0ptb1DXG5N5uxnTb41Kfjf6/Wo6S4i6MYtTtEKJYh8G3ddvyym8uB4vG7yCWaVAFrqcuenwZmgnX56vHLuDxPUD+iY/ztoF22DyV3ditNhaEueCLIhgpsGtzZhQJsOQ6poNG17e51icQ7WpBUT5vBnzvgkwqxrAgz3SFc/sRYBWZRwmBWCZkXv8CosTAvQWO80JHHcbrs4LlttNQfXDftqRsflI+TTW97jFfwPkNQDtH88s/fq5stZ0ZXGOvOGoIeYzLBzqYtE1TSDSXdwlfbxzurw== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: qw81qFO4D9qow7prB4+wNLLbwnapz+s9TDdJUHlEe1boiVBvVLWjMdXO1newNITtQhCFWQSQyp3N+B8eNVGEb/XOKZXHy2mgFBF1Clzg2cumL7x6xLghv7JYyBW9sNpcMFuf73dZRIBRwxCNfekXFH4yqd7QDDncNe1a3KWfsjEApGB4tcgBj8Dp7TllhFwlkVo/QoKrTo9O04XA0Ai8B/gcmmHrusP16WbxEQc1fYmhSqibgWB4TcAk7PYnqvVROqyVpcouftUqDv43mOihkmhWlb5eNEcG/ZSPPuq3jWkuCB56R74844XtfFWrhE5lHlh8BeWqbivBs4/grulTGYT2u52SMoKOac8FN9xojCuAprXOs/BpP0G5SyDYWzSBEvnS3u10Bba5cjg8k7t445i/jk8/oKw98BnnGYEODI9/aeJhkYFDwKD4QWgfb4EvdIb/+HOk807xLL4OtXRT7nUj1bEH7xe9PTbe1cTYfQc69chw2iVOpsdxT2MKYsiefUDynn27iGHJlKBcMrOhsqU8KeeEXPYlIfHN+SwpdS6EBWaMYmnU2bFy6UFR0GQ0zwFmbxBo21uxqS5LKMNXbET2GvVQMeO4T+VEHW8BxRU= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: a55a89e1-d097-4825-a5bb-08dcf37f35e2 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3366.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2024 16:24:50.8740 (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: ySgkCgvYSXvccX6Htpw7qYpquYSIOdlIzlEELLbWvZjS39Xgcxr8MG0TeWtk1BnGg5smsO84QarksCa95UoqbB3M0ZbST3Ygieifll5yKtQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR10MB4320 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1051,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-10-23_13,2024-10-23_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 bulkscore=0 adultscore=0 mlxlogscore=999 mlxscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2409260000 definitions=main-2410230095 X-Proofpoint-ORIG-GUID: aUfmOqLDCU4lQJMW5_VDKlQyGvaaFwqN X-Proofpoint-GUID: aUfmOqLDCU4lQJMW5_VDKlQyGvaaFwqN X-Rspamd-Queue-Id: 629C9180024 X-Stat-Signature: qscqodnbgom5xmorz9stb5kteqi4ok84 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729700701-651623 X-HE-Meta: U2FsdGVkX1/fbxLnjB7fBoTvdUhVNz29vSpSLuOT3ey4ng+OWcHZrUPxqVCSp4nAbzGd014QE/3BPaSiA4cn1v/YRFgW1XYrTCCBuzNjCRXG1XH6hw/X7Ev3RBCSlrQ7DtTKw9Qz5PIhWAKjnTOLKdEid7GCo8N0/bkDig8C2mwGdAR1/mE3jqQqvreNsoryOLRBwIbWa6m8iDThxZCm5VusCUsaJJrTijIrX19YuoS+wzFwLU2FmjTgSF4GLnstWMk2cMQGJaehETgJRqGqlqLip2oQdtOn6nGwJL1f1NfssuOKAMw4kjJnDAoakKXbY0p2tct7jdTjH18fabX7Q0D8UEJ7AbABbDz6w3fAamR5BOIsIP+njsPZ0fZJW25wSZYYCDRKs91lzs4AKdYxqpjHVdBCsKk15rMD15a8D1bkAafe13pOAYK9kJZygc7w0RnWDNt8ooQYwNiLP8c1rFrDWhxLLwY1G2GCBI+wyUtCBYZKXAndHX4LUbq+Lo/qJ2Tihqr4lcn7/92NbAD6FZ7TQFvs2+rnSo1rvnCAhmT6OuIKJ71OE5E2JoO0joX5KuFQ4regkMLQV1mgvYp76T29MZcdzvTl3LrMbUgOzLGKPFEn564rIU3q0Oe/RQFTlb5N1d2vnwCA9UYLAOTXPCv3dgepZTuQeUE2wHhIDCIrvZzY0d2A+I2vezXp8TBAGHv6ZG+K33V8cJ5u1uwTHGwpzjEfv2PAgwFoVsPyHqLterekMmocGx79uv58J2GFuH883SrmV7hvsE0MdGXBHRuCxQvIhJeS3IGqfGLc7Wt1E/jDgcVox/HEaUESVpKIK/MX22mveYDmKxTww4H197FPXCAkXH5FVuZW0svppBtXRSmO8YQuZfTB4sum+tehx01W83Ilb3xKFFSSny/9NV2HvAPOI33AFUy5bCW1M/3WogmaZXVqYGnLCcZLdnURVT/PPE7jFhr7Y2kQq7t 2MfL/NV/ IUN960pxc7y8nlhL4WRPeoUyamQlLyYU/4IHyiemkbZiIKl3AK8Kvv+bdII37o7HYbTkR1HK0j+orFh7B8XB1R4iOwauIRwv6+2AAQA4S5qZYjLYXTI7EsDXyBpcQY2x4rNXq0F4eRjSFe6vO0UyJIApUwv0gA9XcoTv1G0s9AABLtEIMFD06oRnwJhn4vuBAwxxHe0cJxiOj8I/DkTAGYfHxfkQjhOVZZ+groc8CthB4TYoFPWOdRW0O90cqQrwT/5PFmhNXI3ph+W+7QmDHGiq4uiUvO+YqiLNVnbeqGNho14IiH/0uRG8Pga4ximfTCVXa7OMHe2styHXeKFfcgL9TIA5V9X2GA37ldIe65bNDxFAWX0cl9KHjQtxLyL7iji3ncnE+gEuZiE95PaokuL+bcvhTB3wDX3/sOyUDHqNoKzqMkZlQXhTXAWNGNQf5gB1UCH7uGMulNYR7lLWjIJEyXV/CQbZZ2K85fKjhKaAqFIUlTyA3PPAiG/HMVhgBq93a/8LJzlOeH3sRfJoiWBGq3lxlbdg+zbVXD81xr1CnfA6dUIzsBVv74Oih4GEfg92bA+A2u68No8ij+eY+M9xobw== 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: Userland library functions such as allocators and threading implementations often require regions of memory to act as 'guard pages' - mappings which, when accessed, result in a fatal signal being sent to the accessing process. The current means by which these are implemented is via a PROT_NONE mmap() mapping, which provides the required semantics however incur an overhead of a VMA for each such region. With a great many processes and threads, this can rapidly add up and incur a significant memory penalty. It also has the added problem of preventing merges that might otherwise be permitted. This series takes a different approach - an idea suggested by Vlasimil Babka (and before him David Hildenbrand and Jann Horn - perhaps more - the provenance becomes a little tricky to ascertain after this - please forgive any omissions!) - rather than locating the guard pages at the VMA layer, instead placing them in page tables mapping the required ranges. Early testing of the prototype version of this code suggests a 5 times speed up in memory mapping invocations (in conjunction with use of process_madvise()) and a 13% reduction in VMAs on an entirely idle android system and unoptimised code. We expect with optimisation and a loaded system with a larger number of guard pages this could significantly increase, but in any case these numbers are encouraging. This way, rather than having separate VMAs specifying which parts of a range are guard pages, instead we have a VMA spanning the entire range of memory a user is permitted to access and including ranges which are to be 'guarded'. After mapping this, a user can specify which parts of the range should result in a fatal signal when accessed. By restricting the ability to specify guard pages to memory mapped by existing VMAs, we can rely on the mappings being torn down when the mappings are ultimately unmapped and everything works simply as if the memory were not faulted in, from the point of view of the containing VMAs. This mechanism in effect poisons memory ranges similar to hardware memory poisoning, only it is an entirely software-controlled form of poisoning. The mechanism is implemented via madvise() behaviour - MADV_GUARD_INSTALL which installs page table-level guard page markers - and MADV_GUARD_REMOVE - which clears them. Guard markers can be installed across multiple VMAs and any existing mappings will be cleared, that is zapped, before installing the guard page markers in the page tables. There is no concept of 'nested' guard markers, multiple attempts to install guard markers in a range will, after the first attempt, have no effect. Importantly, removing guard markers over a range that contains both guard markers and ordinary backed memory has no effect on anything but the guard markers (including leaving huge pages un-split), so a user can safely remove guard markers over a range of memory leaving the rest intact. The actual mechanism by which the page table entries are specified makes use of existing logic - PTE markers, which are used for the userfaultfd UFFDIO_POISON mechanism. Unfortunately PTE_MARKER_POISONED is not suited for the guard page mechanism as it results in VM_FAULT_HWPOISON semantics in the fault handler, so we add our own specific PTE_MARKER_GUARD and adapt existing logic to handle it. We also extend the generic page walk mechanism to allow for installation of PTEs (carefully restricted to memory management logic only to prevent unwanted abuse). We ensure that zapping performed by MADV_DONTNEED and MADV_FREE do not remove guard markers, nor does forking (except when VM_WIPEONFORK is specified for a VMA which implies a total removal of memory characteristics). It's important to note that the guard page implementation is emphatically NOT a security feature, so a user can remove the markers if they wish. We simply implement it in such a way as to provide the least surprising behaviour. An extensive set of self-tests are provided which ensure behaviour is as expected and additionally self-documents expected behaviour of guard ranges. Suggested-by: Vlastimil Babka Suggested-by: Jann Horn Suggested-by: David Hildenbrand v3 * Cleaned up mm/pagewalk.c logic a bit to make things clearer, as suggested by Vlastiml. * Explicitly avoid splitting THP on PTE installation, as suggested by Vlastimil. Note this has no impact on the guard pages logic, which has page table entry handlers at PUD, PMD and PTE level. * Added WARN_ON_ONCE() to mm/hugetlb.c path where we don't expect a guard marker, as suggested by Vlastimil. * Reverted change to is_poisoned_swp_entry() to exclude guard pages which has the effect of MADV_FREE _not_ clearing guard pages. After discussion with Vlastimil, it became apparent that the ability to 'cancel' the freeing operation by writing to the mapping after having issued an MADV_FREE would mean that we would risk unexpected behaviour should the guard pages be removed, so we now do not remove markers here at all. * Added comment to PTE_MARKER_GUARD to highlight that memory tagged with the marker behaves as if it were a region mapped PROT_NONE, as highlighted by David. * Rename poison -> install, unpoison -> remove (i.e. MADV_GUARD_INSTALL / MADV_GUARD_REMOVE over MADV_GUARD_POISON / MADV_GUARD_REMOVE) at the request of David and John who both find the poison analogy confusing/overloaded. * After a lot of discussion, replace the looping behaviour should page faults race with guard page installation with a modest reattempt followed by returning -ERESTARTNOINTR to have the operation abort and re-enter, relieving lock contention and avoiding the possibility of allowing a malicious sandboxed process to impact the mmap lock or stall the overall process more than necessary, as suggested by Jann and Vlastimil having raised the issue. * Adjusted the page table walker so a populated huge PUD or PMD is correctly treated as being populated, necessitating a zap. In v2 we incorrectly skipped over these, which would cause the logic to wrongly proceed as if nothing were populated and the install succeeded. Instead, explicitly check to see if a huge page - if so, do not split but rather abort the operation and let zap take care of things. * Updated the guard remove logic to not unnecessarily split huge pages either. * Added a debug check to assert that the number of installed PTEs matches expectation, accounting for any existing guard pages. * Adapted vector_madvise() used by the process_madvise() system call to handle -ERESTARTNOINTR correctly. v2 * The macros in kselftest_harness.h seem to be broken - __EXPECT() is terminated by '} while (0); OPTIONAL_HANDLER(_assert)' meaning it is not safe in single line if / else or for /which blocks, however working around this results in checkpatch producing invalid warnings, as reported by Shuah. * Fixing these macros is out of scope for this series, so compromise and instead rewrite test blocks so as to use multiple lines by separating out a decl in most cases. This has the side effect of, for the most part, making things more readable. * Heavily document the use of the volatile keyword - we can't avoid checkpatch complaining about this, so we explain it, as reported by Shuah. * Updated commit message to highlight that we skip tests we lack permissions for, as reported by Shuah. * Replaced a perror() with ksft_exit_fail_perror(), as reported by Shuah. * Added user friendly messages to cases where tests are skipped due to lack of permissions, as reported by Shuah. * Update the tool header to include the new MADV_GUARD_POISON/UNPOISON defines and directly include asm-generic/mman.h to get the platform-neutral versions to ensure we import them. * Finally fixed Vlastimil's email address in Suggested-by tags from suze to suse, as reported by Vlastimil. * Added linux-api to cc list, as reported by Vlastimil. https://lore.kernel.org/all/cover.1729440856.git.lorenzo.stoakes@oracle.com/ v1 * Un-RFC'd as appears no major objections to approach but rather debate on implementation. * Fixed issue with arches which need mmu_context.h and tlbfush.h. header imports in pagewalker logic to be able to use update_mmu_cache() as reported by the kernel test bot. * Added comments in page walker logic to clarify who can use ops->install_pte and why as well as adding a check_ops_valid() helper function, as suggested by Christoph. * Pass false in full parameter in pte_clear_not_present_full() as suggested by Jann. * Stopped erroneously requiring a write lock for the poison operation as suggested by Jann and Suren. * Moved anon_vma_prepare() to the start of madvise_guard_poison() to be consistent with how this is used elsewhere in the kernel as suggested by Jann. * Avoid returning -EAGAIN if we are raced on page faults, just keep looping and duck out if a fatal signal is pending or a conditional reschedule is needed, as suggested by Jann. * Avoid needlessly splitting huge PUDs and PMDs by specifying ACTION_CONTINUE, as suggested by Jann. https://lore.kernel.org/all/cover.1729196871.git.lorenzo.stoakes@oracle.com/ RFC https://lore.kernel.org/all/cover.1727440966.git.lorenzo.stoakes@oracle.com/ Lorenzo Stoakes (5): mm: pagewalk: add the ability to install PTEs mm: add PTE_MARKER_GUARD PTE marker mm: madvise: implement lightweight guard page mechanism tools: testing: update tools UAPI header for mman-common.h selftests/mm: add self tests for guard page feature arch/alpha/include/uapi/asm/mman.h | 3 + arch/mips/include/uapi/asm/mman.h | 3 + arch/parisc/include/uapi/asm/mman.h | 3 + arch/xtensa/include/uapi/asm/mman.h | 3 + include/linux/mm_inline.h | 2 +- include/linux/pagewalk.h | 18 +- include/linux/swapops.h | 24 +- include/uapi/asm-generic/mman-common.h | 3 + mm/hugetlb.c | 4 + mm/internal.h | 12 + mm/madvise.c | 225 ++++ mm/memory.c | 18 +- mm/mprotect.c | 6 +- mm/mseal.c | 1 + mm/pagewalk.c | 227 +++- tools/include/uapi/asm-generic/mman-common.h | 3 + tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + tools/testing/selftests/mm/guard-pages.c | 1239 ++++++++++++++++++ 19 files changed, 1720 insertions(+), 76 deletions(-) create mode 100644 tools/testing/selftests/mm/guard-pages.c --- 2.47.0