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 C6DD5C83F34 for ; Thu, 17 Jul 2025 19:52:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C6C46B008A; Thu, 17 Jul 2025 15:52:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 475F26B0092; Thu, 17 Jul 2025 15:52:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2EF7B6B008C; Thu, 17 Jul 2025 15:52:15 -0400 (EDT) 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 1A8ED6B0089 for ; Thu, 17 Jul 2025 15:52:15 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A5572C01FE for ; Thu, 17 Jul 2025 19:52:14 +0000 (UTC) X-FDA: 83674802988.05.7E5C5DE Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf21.hostedemail.com (Postfix) with ESMTP id BC8C21C0008 for ; Thu, 17 Jul 2025 19:52:10 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2025-04-25 header.b=lh7eQbsl; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b="DY9Fy/cu"; dmarc=pass (policy=reject) header.from=oracle.com; spf=pass (imf21.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") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1752781931; a=rsa-sha256; cv=pass; b=WQY1OTVt38sNtwfjyJQcNxWg+cDR1RRIsofdo0TK6RDL0LqB9F2WGmwl0fdJNj0rqaXP46 uZQqrQ7jXAYEg9krvDuPTwb1poHMf+r4Ah5oCZ+XgzIZa6H2frC1yxn1WNlQSEQ8XcVX/Z 6pnzXHyOrAqDPM88A1Qmq7xpIMc847o= ARC-Authentication-Results: i=2; imf21.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2025-04-25 header.b=lh7eQbsl; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b="DY9Fy/cu"; dmarc=pass (policy=reject) header.from=oracle.com; spf=pass (imf21.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") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752781931; 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=Of7qKS8PsGwvb/Z2BQqnm8opP3aSd2mFcm48dB77LFI=; b=R4676JxsSoR0uQjj79Ht2oE3ms0snaT2i8JrhjYIVihKZ+niM6JkCirI5ugfHDw8sor4CT vm8UTAS7gMFsphDKoT6Yl0uH3bSnCAI1/hYlZHUWdr5cpXU7jEZjJc7pFhCQNmjSypddS7 pFo0A+P/mhnbCo7CQCpOahqFXAe7Dgc= 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 56HJXlAa027463; Thu, 17 Jul 2025 19:51:58 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-2025-04-25; bh=Of7qKS8PsGwvb/Z2BQ qnm8opP3aSd2mFcm48dB77LFI=; b=lh7eQbslI++nPXA/w7NJ40NBCNRar/TL6V kJyXZ5sA9cV23pS5/1mYsIT3y1R+eKRGT8FFH5ywWS30uKdtWIxtcuIY8FT0eB8h SrEHPYA9tr0eTG+x48lCnvnrmyoMdDxfQ7HMx1eowL5cgb0LQhnDuKYCgHVq7dhe g1oOOkbNrna0O6yRpbV5/ViyKYeVR9ctR2qUd95yTzZfV6nNrKQh5cfAmJBkIYcl ld5qUAT0kkVaFpIeME9jjEuvTfoWJU+yzqgmczKdDmkY52fjp9mGlbhvYYBZFSxs MmyY54lRSLhhOKZvtL7qF/lRTWbg1N9N2FfgbipyOaXQpUEFr1RA== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 47uk1b3vyd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Jul 2025 19:51:58 +0000 (GMT) Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 56HJQmAI011570; Thu, 17 Jul 2025 19:51:57 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10on2047.outbound.protection.outlook.com [40.107.93.47]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 47ue5d7kny-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Jul 2025 19:51:57 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TCmyxgAq4hUcCriY2ECBTFaXmAXkJY/BRYT4/RDbb1Ape3iDvc7SjFJUZZS71QOyD+uK9EON+YjO9BJOx21a8h6YW0TZ6Y9kgYAeI90xhWRBBJqBQvOE/nP5z56TBngBSfJVmJjvQBUt9YT4WEn/kezwjilQRssamFFGCW8OrtCrHBNvxAdN3BErmdzzId83crI2bpZ8O0wqi/a1ssyTZjfniP4kIl0BIA1GjPyQO1a+0A0mv3EHrtkr0/n1ekIrQaujlROVVm+mzpQfQ15MudkLhUw1jA8twMCcRQf7VWMa/JD9N2LJhjyjYK2xvGVzKhYaOpEjsiozr7grQ5t/qg== 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=Of7qKS8PsGwvb/Z2BQqnm8opP3aSd2mFcm48dB77LFI=; b=WAIRzepUgkfWYy4zprlX3UsqPmbLnJSSZdBCu3+1Gy7o+WwgpG9RnluL99Q83i9Jaw9REl7aU/5vAka7d1AYVeMX5QOz3XsGBsnUq7z0fIJJbOp7hEuIg+xbkElst/2qzuTlTEx7w5DQolRjTSmTu232uWAIDKv/Dg7fwj8CoWL5DKltnJCrSPXEzjF91a4WtImWq1b13bKiRQCb1QEBrTjjAUqKPzZfVDGDWgMbZH3Pud1Gbxu95y9F9cgzqsAJe89rysU0BtIYHAnb+zTBkIIJftj8bHJO+zcbkyxVcIWskWwY0z6nTYA850LuQWV/wqDarGUqpUh94CnlDSikhw== 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=Of7qKS8PsGwvb/Z2BQqnm8opP3aSd2mFcm48dB77LFI=; b=DY9Fy/cuPLKqAbtYZLLSPGzuPeDj75/bW03oUkgcTRTouNJsjXqqx+/h4NcQCQoQOB+lffabopBJI6Uq5y1RRUwBDINlVbGtdFouA5s8koR4NAXquHsfcQfUZfXIiIBElvutKQIXo3kk5NWkpi9NalPGelupjUk1Y4Qb0iEIwHA= Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16) by SA2PR10MB4412.namprd10.prod.outlook.com (2603:10b6:806:117::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8922.39; Thu, 17 Jul 2025 19:51:54 +0000 Received: from DM4PR10MB8218.namprd10.prod.outlook.com ([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com ([fe80::2650:55cf:2816:5f2%6]) with mapi id 15.20.8922.037; Thu, 17 Jul 2025 19:51:54 +0000 Date: Thu, 17 Jul 2025 20:51:51 +0100 From: Lorenzo Stoakes To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, xen-devel@lists.xenproject.org, linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Jann Horn , Pedro Falcato , Hugh Dickins , Oscar Salvador , Lance Yang Subject: Re: [PATCH v2 7/9] mm/memory: factor out common code from vm_normal_page_*() Message-ID: <1aef6483-18e6-463b-a197-34dd32dd6fbd@lucifer.local> References: <20250717115212.1825089-1-david@redhat.com> <20250717115212.1825089-8-david@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250717115212.1825089-8-david@redhat.com> X-ClientProxiedBy: LO4P265CA0100.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bc::12) To DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|SA2PR10MB4412:EE_ X-MS-Office365-Filtering-Correlation-Id: bad37e64-796d-4c0f-3fdf-08ddc56b617f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|366016|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?/a+FpqH99qvE24hMjSvrwVwzpuV/6K/LKRa2Uk0el+8jZH8Ht9JeZNcYgcdb?= =?us-ascii?Q?WVa2oug6HCTuxHyFAoWFo5O2z94eLlXfPQwWSCgjh3CV8a4EG7nrJAf2n+oe?= =?us-ascii?Q?/crH3IytG3An/YwbstPB5oRnwL0TNDBUMGrgMBGiAn3NKjg/uIErMP2BySir?= =?us-ascii?Q?OYrE6htFKMUYtGHW5bAurxfG2yk1oCaM/YO3kZJWrQHzk2U3d9m/TlJshxYy?= =?us-ascii?Q?gGjWctYcRhYM0QGn4Cb2E+cqrFi7nb1OnkrOKd/N+r5m7xWO0nlLYAOLDXAm?= =?us-ascii?Q?cTznwO9o5EkfoSYzwT1JloqCqL2CZ6xjgol+Gn1EtfiUhjfn5hFd6Vd0wnn/?= =?us-ascii?Q?bvGRzpFUH51MRhiITlDOO7H7otrafxJWA0DJmKjSaFbDXa0h7cShPuRJLRCb?= =?us-ascii?Q?AkAPIADVJcFP48DYJSAFJhxrdkVH7b3pnxX75coNtLPAPnTqbbTcBWx8Ly58?= =?us-ascii?Q?BKzScB0MGlPhNFMlvLjKKEbIQ7czGL35oe29YYJKPGdkUfw0AOcT2wMHaicx?= =?us-ascii?Q?E1Qkg184u/qZLvyj5H/hTe4os6WGm7mNuMxxUd/U6LViP5EaL3gLCnT7ItTd?= =?us-ascii?Q?c9YcHfhuP8WWNJS91obro97WxZvq3f8o0KnW3dFEma8uq4r6PYS4rscyor7P?= =?us-ascii?Q?GAVVaLKN4SqlMM6xsfr9vjuUiaW5jDBJHN8ye2CWRwyk3NxVNMq5E1WM771c?= =?us-ascii?Q?2SkzWTlgezHmRYeuZkpaz8d/CltV63V30Es0vlF+3awupAbFl4xrW4HVaElG?= =?us-ascii?Q?YFpWQaLfSWdEv9sTPXIsaErJ/1QwaOzp1gbsJrTQacx8CGTreAtzgZSIy32k?= =?us-ascii?Q?/LVh61DKbi7nlE+iRA5WZT5EpxhAJvXThR7BHZUiGpJ4gvqtXeSEZ75c95mc?= =?us-ascii?Q?V6DNoKfyDqt78gHXF/jCarbhWNVKX3Nskk32MBQgwNIZ2bwgaoG+Q8MtvoMo?= =?us-ascii?Q?a88KtqZ1s6lt56FMl0irOd0Gw8JhnrA0cQvlMh9pDDtr47tdYJcPwIlrkxRI?= =?us-ascii?Q?P7og4J0O8Jjp1r6VAqAE6knjgqBD3sjLvCyrmY7ezWPrd72DShG1yislEFiN?= =?us-ascii?Q?8MzqEn8ffXa0GkArV+wStXIHWHzAxBMY5lPOPA0/VnbmCxmxQgXxsOkSdKez?= =?us-ascii?Q?rWUyHy42JmqXyactkYIHImK9dXquJjh+VHPFYdi6KUTPujARTw12JbzLyt2t?= =?us-ascii?Q?4hLG//yC7k2mmm+LX3PyngKS/C47YHC9rjtX7v9cHZW+dXN92940NunfuBOQ?= =?us-ascii?Q?ZmzSn3JPiLl9acYdni5FJteHyuFpqv/2L56tYDiJf7m4bZ335NUgaf7kl5y5?= =?us-ascii?Q?cNk99O80H/kkFd/E3vxN/UGaxmIW4yQF/zT82lxOzBBo7qG52JdlvYhxaCbj?= =?us-ascii?Q?tfst+WVAAE5cAxdqNJPucTMUhIKdh4wDCCQ/J30Y65J/C7swAF6ZYNt3XZby?= =?us-ascii?Q?/P313ilvo/A=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tPuaCgd34wC26uZUxeNBrjnCk2hWt5TvWCE1RbmYwG2Z566xYbY4bPQZmnOh?= =?us-ascii?Q?PfADUeJj1UHai+L5AxlbmBZ4WjQAlElQPOnG9hBHp+8qCsqI7BPyVdKxqhX6?= =?us-ascii?Q?nfPdygg2UNEeK8yaX1JN5ctRvaosOfPyD2KezmhG2BWKeKgw3z5qf+ABOA/+?= =?us-ascii?Q?UmxGaopCO6BM9RfY2QunPJZq40BrFh6VcomjcNEDO3LG0V4xiplOBWgLvIL+?= =?us-ascii?Q?3zVH4AiqDMboOZDAveYX3OmLk944mmkW6L+5HPPR9PJFcGPDJwzUPUkh6rwT?= =?us-ascii?Q?vmq+Iz0Ls2uUmJOjhwDvW72qiGVG/BH5I+mnH1QH/neFAhOtCcrGYnfatfFK?= =?us-ascii?Q?f71IRV4h3WtW4Vu1VYNDO2Ljmfd7tGhQRqdYiOeXZn9uowHPLUJj5i1aua+x?= =?us-ascii?Q?j0KPrMuelocx087V5eZicdTIhK9/QMnrZT4YwktlN7+bRtbhK+vCDrLnhBhr?= =?us-ascii?Q?dz34WbhfV7F2QUEkyMwKvYEb8t7VnWNpLGPXA06j4/kqFgGiExfnK4E/tFF3?= =?us-ascii?Q?Rfo05mynC7vkF8ur48mNaYWeRTrzAhaXWMZJgL0/BbjEeJGo1kWU6ZU/ACXu?= =?us-ascii?Q?0RMUCfrtKU6brdw9HhpqP706HJT1QrLHtIXkVuKqTxmQp4eu7GeykEj6BJWF?= =?us-ascii?Q?4QrTQZh8qK53RAMtzytsBDd2LtdObr5rf+UyFIlvlRiRyvx68Wp5LtYZDYPO?= =?us-ascii?Q?nIPtpHC/uSLOjVNtC7hO3xBSViAlGLbFVMtZ4DTKrMZbRHAnJD51ShXa8IIH?= =?us-ascii?Q?fUyDFOmsotulv+RJ/q6xxSYjd6sVCokmaPtUhP3WH7IhEtDfs1v80UcaWw4m?= =?us-ascii?Q?cDaS9668Q9EktZ5xEmRnW2afimNPHNgM3T80ZiyyQ+KuUmF4meDRUIM30eYh?= =?us-ascii?Q?XJDAX0W4jc7kj4Yq01e+jKFHGDH783HO4M50qLjn8CSI28ZmMS/9yfe8F/k4?= =?us-ascii?Q?xym4Wb/zaLZQWNynBhUrd8KzW5uB2rrTrcpVasPF6xy7Gh2eyUxF4OMCSa/K?= =?us-ascii?Q?5hksi+HjBHV4GuE4E/IJHJpTy1JFfHmctTqzLIKmknceCCKIsoKOnCJH2XwD?= =?us-ascii?Q?FSdQbtwn+9/MooIrqKGAd25fSW/hF4oj1cKpH9vgnvx3Cu1/K3BteSEhyyuH?= =?us-ascii?Q?3j3I+878mXQjaLRUwi0oX3j9Ig1cGl0XGkmQYc8d6/RyoRb6c+6XCuaBn49n?= =?us-ascii?Q?uRIKhlIdt5khQd/7uSOrKOWE7aVxyUJk0m0zWhjmq/PkTxrgGbLYcaqc7c+W?= =?us-ascii?Q?m9HFMNjWG2i+bxlv3Ll24eNmXFxbqhd8zsBpUaex4inq7t6h8A5LBnC6FKD+?= =?us-ascii?Q?2KJb5nZHmycYKbC/XLf7VzkYW44iLPie4nSyk+6KOGVAbFRkRLN1CUHs6Bk4?= =?us-ascii?Q?UGKnM0YQU78pSg6N7yBcREOclP7CXNlAxi9HtCe/jyx1FiA3TEgWQE62Z6Ks?= =?us-ascii?Q?H14xNoFFWFgikJBBsRGjNu+8213A2u9VA4tpoNKp+hF+Ru9gxjPQv9s6PbTw?= =?us-ascii?Q?LWngLG9YG6Df4+fFSxZN4Xh0LNRZS2nGGkGrGvrVpW2+7E3PK11uvYhdK7MN?= =?us-ascii?Q?6jdxb9RuxOUHnWO95LCIxrSDi9V+hfj3adWOTNa2gfjYTTU95Lz5Lg0h7tlk?= =?us-ascii?Q?sQ=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 0wVze2nyR5zmV2f7Zja3KC3HDb0xuLCgHLqiVAPc5HoGSJfXRbNCfUkIlyx27+W92Ij7+Epcuv0y5g6z+UxO665yV3VaVJ1n98CD7wImIElTeWOxX1OXZhRdygwf+f5fqE1aNvqSdY6en+7Ccydaik3O3g7x8X14AvzlTJmCT7cR+1RZfhM1sJ3m+SQRJcpcy4KbS/bw6PBFjnP7VKn9rWJu3RtAILtFTzwsEy4QLq1q2R4Ji3JSoPFThlPhA+BHcbYDzH0tY1RiadQmq0bfwu7kGmY7VCdVZl+pyYq3d7W8T+I7niWXiw1h6vKihedjZt+g9SIVc+XvjTH+s/lmyaURlGZGQ79kKfZDyisV6ppJp3bOhlumYL8WbZoPBoiZ8NSTr1IsOpsl5mNPozTnkoFuMtiDv0PJv6Ic484R4whERYPbFS0JPBLCIHgn2ncSqPR1gUqZv/EEMtBP1TnNiR9eL+28iZMrk5y0g1NiG21b222MidRleVbdRLWrLPhn07avh+Vkdm7d4puUxZUSJ8oKUqWZRGNWJrI32qkzHcCC5oQ1QxhMddmblq1HJw5VbkJeljegkA+Wf89SDuDuSj1klyV/NTQxge1VlEqdR44= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: bad37e64-796d-4c0f-3fdf-08ddc56b617f X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2025 19:51:54.6194 (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: HAx/23H7d2CqvmHoTlh9PNXnTiHy4ulfSxEZeShbvFSbmxQE/zC1djrbyzry4N41/aISljLlB2nfnRqIOfyi4Fd32NwgxSc3YjnehNdwhP8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR10MB4412 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.1.9,FMLib:17.12.80.40 definitions=2025-07-17_03,2025-07-17_02,2025-03-28_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 adultscore=0 phishscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2507170175 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNzE3MDE3NiBTYWx0ZWRfX0CA/fgqNgnvD rVWHRFNe4J87MPj1ijDJoeA5F+sEamMlXP027WRlF0aTrZk9sQCQwEBFdUuqg5d6bgNw2BBPk9Z 6WolwCH3LqN4LLbTczxj9UnCUlERHG87iVWgGN5AUNKZi9qn2MNKTbnG1/mBM9EnB9x9AIfRSfS jbATDnclnhPhdWlxvxfHM1lMb5ga9dvIt5/XOc6aGvRYuEe968fn45UJpdCDd8X/CJVrlcNS7em RH0hlAOdSboqr/hUQdw77kqSRr7Z0qAAm/HCk5zzC3cuEIxrf/ietxj+sga43UMNSZooDC7OpLk 2PHBuxispLxHrhqQ1LP7i6FlW/pr0gjpzPTlQUa2OOZ6HkU/qC8jKAfyUcvXG1e56nAPxln9lgj keOebTxLsGcurtY0QvvySckdzc4GWf/Ghb7peWVmZkikQEGVksN5co5QNcT0k72dC+W91j/C X-Proofpoint-GUID: l1KstOOfNrL9lwbA4zWHNbm8F9RWiAlL X-Proofpoint-ORIG-GUID: l1KstOOfNrL9lwbA4zWHNbm8F9RWiAlL X-Authority-Analysis: v=2.4 cv=J8mq7BnS c=1 sm=1 tr=0 ts=6879545e b=1 cx=c_pps a=qoll8+KPOyaMroiJ2sR5sw==:117 a=qoll8+KPOyaMroiJ2sR5sw==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19 a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=Wb1JkmetP80A:10 a=GoEa3M9JfhUA:10 a=20KFwNOVAAAA:8 a=mUPUarKZXQvfMSChq2YA:9 a=CjuIK1q_8ugA:10 cc=ntf awl=host:12062 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: BC8C21C0008 X-Stat-Signature: ed9e6q7wgr5gqp4nxyccbcb9ddyakejr X-HE-Tag: 1752781930-100538 X-HE-Meta: U2FsdGVkX1/ifayqr7KIRaMtqqAVMeCpcQ6VIl7eQke3cIMotUY5Td+JQPNQxFv63O8fWpjrCW0Wp/G4Sp1ARCKIk9K+uWFwwot6KZP869d2rwbL3BRM1ocKzEMhx6SCjmh6T5CgWvlHIiBKOYjUuG4ACKn2nqBGxthxiTX/29Xh7bgg2PBTM0U4/Uu4XkkbCsTqG02gaosyiWCDT34kSMaZNRk4ZUVco2eSjWpTJ1afZZhXcHqJO2gOLw1g+A4IAXI3RwRxVxNfr9+EdXUNB7nrHy6svEOMX9Inv2JeP+J1USKpk42ggD+YMfZ6UcXLcgNYkAt6cZXlUSqwnYT7d1NSP/PA1PwDuBMIR2siQru2e2k84GxOUpWBhK1MjpgF6kMMOiVCPaC4GXSEsOEHru4HpfIPeXdt71kyW9pLyf3ZlzLhruhn2iv6KVAy1ws+VCcEwZy8NJrCC5BmOw/XqdQgevLsskZnPs3HGr8+9qY/kbtWGgCNPeWZ0irS+e+bR80JimQthY+2NSsGLHlAlnZVOH6XBZDVkYBJAzLT+6jpYXhW1PfHaVJDmY3CwhPPRJ3WzdgAnmZMAsQFVfvZFByG8FCGNqiOp7ObCz/wOIadt2QAlxt88OIdLwLuFfZukSN/AUw/aeB121POZA5VD+ynk2UIeXIBQjquxOFEls6c2HJqw5ZJ/ZfXYynrTLj199Ixnxw/xks6rQW5tlUlnJPINKgq8rkd7g9yR9uXyPVkoiSdZd+5rEl5pz/n6Ik65PPONZCkHuZXwfdFHYmlb4YltMPVZVODnyUT4GgOW6wl7Rm/FCPLgyMAzavbYAVFsJrAo0jJgxA7jjEaaq1Cq7z36SM5KSmWlu0PAbyylB/8nEQH100dTDkNXL82FkCNwW5C2aZBRZhMseD6nlfNOTlR3gy84A6u9ulvHnFJV0oC1lizJ042OYabhMOulZdWT9zthpoHRQbLLqjOReZ Yxv4Z7q3 OF1uQUCtgecNQ0Ft2Jpnzi9XK5J6t2gK0c2e8gDTV642VX3U1b/0QDd+1jeE7J+0grrpaqQhGScGqKd0+KOJtdalvcdnoJon28OoRp6y0eYQ6eA4CndCk5LiL2151MhUj4gQZiZXFfgtkVBzxqEPQnBhzt1vndN3JbLpL/fqMk9PTEOSp14pn8t8+Vga1MgkwGN4RxLpZ2tgHB/Ex27T1CmfXF0PxO/tH1wpodARQS23fJs/aO70bgUs96MP/GBgBEUkb0AxQpoNvDzFWJpaEiNJBcYt01wapNWpfbS7c51AmPU1/ngOuVaPxCtLBTRmlY387h1HuVYQtthtPdO1DgUsZrPOVQzCBEX2RrFP+eY3Rlndhu+4+mXb0UsjmeUHe/OKaIGad+CS8BZaFDCEMipxDxNNF2W45hxTmr/7mN2JjwRFDxBhrC5ctvu/logkJ8YsLkRp7Sqog18jdDPYDLQytV6n5srUoHICE5QnXEGKcDzxMbQg2Eb7Ot6PA3wgr9t4UwO7zUEHgDmUlLL1S+k0+06YYDCaPNTVE9ihdbGhN/g0GP++s6IWsT9GXw45+T72X1gJyVHx9NYth1SLAI9A2cIZQHkiXFPtd9JLu+9zgbkTwjk0CRgtzU5Vcn1na+OuReI8DsNXc/xw92YOnHoZv8D9IZuGwVuoZ84xOVVE6kk1Y/JmMW9Jg6iUobk5f5jI+rw7K4D13QXmOwzQXLGDTt83KLIkuFDK1efr6dIlJyTxKSK4g2+afvw== 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 Thu, Jul 17, 2025 at 01:52:10PM +0200, David Hildenbrand wrote: > Let's reduce the code duplication and factor out the non-pte/pmd related > magic into vm_normal_page_pfn(). > > To keep it simpler, check the pfn against both zero folios. We could > optimize this, but as it's only for the !CONFIG_ARCH_HAS_PTE_SPECIAL > case, it's not a compelling micro-optimization. > > With CONFIG_ARCH_HAS_PTE_SPECIAL we don't have to check anything else, > really. > > It's a good question if we can even hit the !CONFIG_ARCH_HAS_PTE_SPECIAL > scenario in the PMD case in practice: but doesn't really matter, as > it's now all unified in vm_normal_page_pfn(). > > Add kerneldoc for all involved functions. > > No functional change intended. > > Reviewed-by: Oscar Salvador > Signed-off-by: David Hildenbrand > --- > mm/memory.c | 183 +++++++++++++++++++++++++++++++--------------------- > 1 file changed, 109 insertions(+), 74 deletions(-) > > diff --git a/mm/memory.c b/mm/memory.c > index 08d16ed7b4cc7..c43ae5e4d7644 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -590,8 +590,13 @@ static void print_bad_page_map(struct vm_area_struct *vma, > add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE); > } > > -/* > - * vm_normal_page -- This function gets the "struct page" associated with a pte. > +/** > + * vm_normal_page_pfn() - Get the "struct page" associated with a PFN in a > + * non-special page table entry. This is a bit nebulous/confusing, I mean you'll get PTE entries with PTE special bit that'll have a PFN but just no struct page/folio to look at, or should not be touched. So the _pfn() bit doesn't really properly describe what it does. I wonder if it'd be better to just separate out the special handler, have that return a boolean indicating special of either form, and then separate other shared code separately from that? > + * @vma: The VMA mapping the @pfn. > + * @addr: The address where the @pfn is mapped. > + * @pfn: The PFN. > + * @entry: The page table entry value for error reporting purposes. > * > * "Special" mappings do not wish to be associated with a "struct page" (either > * it doesn't exist, or it exists but they don't want to touch it). In this > @@ -603,10 +608,10 @@ static void print_bad_page_map(struct vm_area_struct *vma, > * (such as GUP) can still identify these mappings and work with the > * underlying "struct page". > * > - * There are 2 broad cases. Firstly, an architecture may define a pte_special() > - * pte bit, in which case this function is trivial. Secondly, an architecture > - * may not have a spare pte bit, which requires a more complicated scheme, > - * described below. > + * There are 2 broad cases. Firstly, an architecture may define a "special" > + * page table entry bit (e.g., pte_special()), in which case this function is > + * trivial. Secondly, an architecture may not have a spare page table > + * entry bit, which requires a more complicated scheme, described below. Strikes me this bit of the comment should be with vm_normal_page(). As this implies the 2 broad cases are handled here and this isn't the case. > * > * A raw VM_PFNMAP mapping (ie. one that is not COWed) is always considered a > * special mapping (even if there are underlying and valid "struct pages"). > @@ -639,15 +644,72 @@ static void print_bad_page_map(struct vm_area_struct *vma, > * don't have to follow the strict linearity rule of PFNMAP mappings in > * order to support COWable mappings. > * > + * This function is not expected to be called for obviously special mappings: > + * when the page table entry has the "special" bit set. Hmm this is is a bit weird though, saying "obviously" special, because you're handling "special" mappings here, but only for architectures that don't specify the PTE special bit. So it makes it quite nebulous what constitutes 'obviously' here, really you mean pte_special(). > + * > + * Return: Returns the "struct page" if this is a "normal" mapping. Returns > + * NULL if this is a "special" mapping. > + */ > +static inline struct page *vm_normal_page_pfn(struct vm_area_struct *vma, > + unsigned long addr, unsigned long pfn, unsigned long long entry) > +{ > + /* > + * With CONFIG_ARCH_HAS_PTE_SPECIAL, any special page table mappings > + * (incl. shared zero folios) are marked accordingly and are handled > + * by the caller. > + */ > + if (!IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) { > + if (unlikely(vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))) { > + if (vma->vm_flags & VM_MIXEDMAP) { > + /* If it has a "struct page", it's "normal". */ > + if (!pfn_valid(pfn)) > + return NULL; > + } else { > + unsigned long off = (addr - vma->vm_start) >> PAGE_SHIFT; > + > + /* Only CoW'ed anon folios are "normal". */ > + if (pfn == vma->vm_pgoff + off) > + return NULL; > + if (!is_cow_mapping(vma->vm_flags)) > + return NULL; > + } > + } > + > + if (is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)) This handles zero/zero huge page handling for non-pte_special() case only. I wonder if we even need to bother having these marked special generally since you can just check the PFN every time anyway. > + return NULL; > + } > + > + /* Cheap check for corrupted page table entries. */ > + if (pfn > highest_memmap_pfn) { > + print_bad_page_map(vma, addr, entry, NULL); > + return NULL; > + } > + /* > + * NOTE! We still have PageReserved() pages in the page tables. > + * For example, VDSO mappings can cause them to exist. > + */ > + VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); > + return pfn_to_page(pfn); > +} > + > +/** > + * vm_normal_page() - Get the "struct page" associated with a PTE > + * @vma: The VMA mapping the @pte. > + * @addr: The address where the @pte is mapped. > + * @pte: The PTE. > + * > + * Get the "struct page" associated with a PTE. See vm_normal_page_pfn() > + * for details. > + * > + * Return: Returns the "struct page" if this is a "normal" mapping. Returns > + * NULL if this is a "special" mapping. > */ > struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, > pte_t pte) > { > unsigned long pfn = pte_pfn(pte); > > - if (IS_ENABLED(CONFIG_ARCH_HAS_PTE_SPECIAL)) { > - if (likely(!pte_special(pte))) > - goto check_pfn; > + if (unlikely(pte_special(pte))) { > if (vma->vm_ops && vma->vm_ops->find_special_page) > return vma->vm_ops->find_special_page(vma, addr); > if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)) > @@ -658,44 +720,21 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, > print_bad_page_map(vma, addr, pte_val(pte), NULL); > return NULL; > } > - > - /* !CONFIG_ARCH_HAS_PTE_SPECIAL case follows: */ > - > - if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) { > - if (vma->vm_flags & VM_MIXEDMAP) { > - if (!pfn_valid(pfn)) > - return NULL; > - if (is_zero_pfn(pfn)) > - return NULL; > - goto out; > - } else { > - unsigned long off; > - off = (addr - vma->vm_start) >> PAGE_SHIFT; > - if (pfn == vma->vm_pgoff + off) > - return NULL; > - if (!is_cow_mapping(vma->vm_flags)) > - return NULL; > - } > - } > - > - if (is_zero_pfn(pfn)) > - return NULL; > - > -check_pfn: > - if (unlikely(pfn > highest_memmap_pfn)) { > - print_bad_page_map(vma, addr, pte_val(pte), NULL); > - return NULL; > - } > - > - /* > - * NOTE! We still have PageReserved() pages in the page tables. > - * eg. VDSO mappings can cause them to exist. > - */ > -out: > - VM_WARN_ON_ONCE(is_zero_pfn(pfn)); > - return pfn_to_page(pfn); > + return vm_normal_page_pfn(vma, addr, pfn, pte_val(pte)); > } > > +/** > + * vm_normal_folio() - Get the "struct folio" associated with a PTE > + * @vma: The VMA mapping the @pte. > + * @addr: The address where the @pte is mapped. > + * @pte: The PTE. > + * > + * Get the "struct folio" associated with a PTE. See vm_normal_page_pfn() > + * for details. > + * > + * Return: Returns the "struct folio" if this is a "normal" mapping. Returns > + * NULL if this is a "special" mapping. > + */ Nice to add a comment, but again feels weird to have the whole explanation in vm_normal_page_pfn() but then to invoke vm_normal_page()... > struct folio *vm_normal_folio(struct vm_area_struct *vma, unsigned long addr, > pte_t pte) > { > @@ -707,6 +746,18 @@ struct folio *vm_normal_folio(struct vm_area_struct *vma, unsigned long addr, > } > > #ifdef CONFIG_PGTABLE_HAS_HUGE_LEAVES > +/** > + * vm_normal_page_pmd() - Get the "struct page" associated with a PMD > + * @vma: The VMA mapping the @pmd. > + * @addr: The address where the @pmd is mapped. > + * @pmd: The PMD. > + * > + * Get the "struct page" associated with a PMD. See vm_normal_page_pfn() > + * for details. > + * > + * Return: Returns the "struct page" if this is a "normal" mapping. Returns > + * NULL if this is a "special" mapping. > + */ > struct page *vm_normal_page_pmd(struct vm_area_struct *vma, unsigned long addr, > pmd_t pmd) > { > @@ -721,37 +772,21 @@ struct page *vm_normal_page_pmd(struct vm_area_struct *vma, unsigned long addr, > print_bad_page_map(vma, addr, pmd_val(pmd), NULL); > return NULL; > } > - > - if (unlikely(vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP))) { > - if (vma->vm_flags & VM_MIXEDMAP) { > - if (!pfn_valid(pfn)) > - return NULL; > - goto out; > - } else { > - unsigned long off; > - off = (addr - vma->vm_start) >> PAGE_SHIFT; > - if (pfn == vma->vm_pgoff + off) > - return NULL; > - if (!is_cow_mapping(vma->vm_flags)) > - return NULL; > - } > - } > - > - if (is_huge_zero_pfn(pfn)) > - return NULL; > - if (unlikely(pfn > highest_memmap_pfn)) { > - print_bad_page_map(vma, addr, pmd_val(pmd), NULL); > - return NULL; > - } > - > - /* > - * NOTE! We still have PageReserved() pages in the page tables. > - * eg. VDSO mappings can cause them to exist. > - */ > -out: > - return pfn_to_page(pfn); > + return vm_normal_page_pfn(vma, addr, pfn, pmd_val(pmd)); Hmm this seems broken, because you're now making these special on arches with pte_special() right? But then you're invoking the not-special function? Also for non-pte_special() arches you're kind of implying they _maybe_ could be special. > } > > +/** > + * vm_normal_folio_pmd() - Get the "struct folio" associated with a PMD > + * @vma: The VMA mapping the @pmd. > + * @addr: The address where the @pmd is mapped. > + * @pmd: The PMD. > + * > + * Get the "struct folio" associated with a PMD. See vm_normal_page_pfn() > + * for details. > + * > + * Return: Returns the "struct folio" if this is a "normal" mapping. Returns > + * NULL if this is a "special" mapping. > + */ > struct folio *vm_normal_folio_pmd(struct vm_area_struct *vma, > unsigned long addr, pmd_t pmd) > { > -- > 2.50.1 >