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 008CFC28B2E for ; Mon, 10 Mar 2025 15:38:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2E674280004; Mon, 10 Mar 2025 11:38:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 294DB280003; Mon, 10 Mar 2025 11:38:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04AA8280005; Mon, 10 Mar 2025 11:38:29 -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 D297C280004 for ; Mon, 10 Mar 2025 11:38:29 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C8B46568EC for ; Mon, 10 Mar 2025 15:38:29 +0000 (UTC) X-FDA: 83206048338.06.77DB160 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf10.hostedemail.com (Postfix) with ESMTP id 87D45C001C for ; Mon, 10 Mar 2025 15:38:26 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=fk6wlPTI; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=CCaxWWac; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com; spf=pass (imf10.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1741621106; a=rsa-sha256; cv=pass; b=AydX4y+mNs/gg8xtG69zqtcE7DYK8LXUXedLtxwvTrszSVrsbqKstB8o/HYBUpzh1YI0Er r/6QqxKq7xZqrEf2rtMAMrumcbKoDJV6W5ZE8+ZUrzHwFQjY6uboTJk4ulbrv/Fh+ll3gI DyRGWda59n/ZIWNvULvwFQHJOJwHUKE= ARC-Authentication-Results: i=2; imf10.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b=fk6wlPTI; dkim=pass header.d=oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=CCaxWWac; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=oracle.com; spf=pass (imf10.hostedemail.com: domain of lorenzo.stoakes@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=lorenzo.stoakes@oracle.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741621106; 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=kb4MqJ9jsrYbnJZEzJiRlzYaO1N000teEcBwTsmUkHU=; b=SBf/fRtLPqHdu8Wy9joQu3Gfl/uUlbPZ3VD2Q0+uHJE8Zo57zBBwSRbUnBDQOooN9A6b/U WKcUQ0utRVn4PcDwf5cUldIFgMruiDQxZu2oprBLCqHyz8e9Z77Xdcc+CX4vVf28hNYzFq VluHRmkYn5lkatC9FUH3+iPZDkkNnpQ= 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 52AFYFlL024296; Mon, 10 Mar 2025 15:38:24 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=kb4MqJ9jsrYbnJZEzJ iRlzYaO1N000teEcBwTsmUkHU=; b=fk6wlPTIHtHXAvxhyBLIrGyzTkai63N9C0 AZ63zz4GdAAqbBP2eRjKajUxFQllAXcTrMvwzJbMzu9940h/vFckbA4cC072DJBY kckyxwRbU8JTQaZOxcXuoc9iTrnehXGl8gOdm+23PJedggaflqS2DUKQpYIPEx0q BjHBLf+in82iolDLQJr34sWQiSaaWh2AcwS3XhdYPXGN1czKhN5SV1zP+LYzshrO +/wmLCayqc5WnkDNnDsoWLQ4XOWx21d/SUw0er8VJKn7+/jQ5OjZ+WEQDFHLCbJ5 rW9uwxwOaO4Vs4Wzzl+yVtY3duKsnCMDJcQPlJ5Vg+zSNRr9C/Kg== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 458dgt2uv0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 Mar 2025 15:38:24 +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 52AETWsF019363; Mon, 10 Mar 2025 15:38:23 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2044.outbound.protection.outlook.com [104.47.66.44]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 458cbe9acr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 Mar 2025 15:38:23 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VVSa4YS4vUPpHOHbyKHi0AT8U27q17yv6DaGglHbppHXVXpbN+pll8m6+mMNm71EqKADb7NmaW4ka1H46IECfSeUABOugchXRMA6iMxsa1lxOdcyzzJJNtSkOlhoUoZav4RLDrX8B8j4LjsoKYL95fhnkT3O6RBHoGk96sv1vQ9MDmtAFUZhAgziRQT8ypAw0fbRLh9E6TWrqyseLOSMj2Y6vxQoCl7BQ/CT8St+eDk3WOQgljMzGh4vjNiB25ujzUeIq56C8VTrJCDhgAW8yw7i3NjH10zY/oZADAx72MeUyFnF2rtVPYTRihuzDnfqs5XagruzXVK5uELeHfvkeg== 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=kb4MqJ9jsrYbnJZEzJiRlzYaO1N000teEcBwTsmUkHU=; b=xGbtEvAWR/+1vD9plmaQ2lIVdl+eZ26wh/pjOjnYhHWXZbaLxrk2yXzx7oAgSfVgPHWoC0pbbh6fA3MnNTeyz1gZXqO9Sqif6UP7cRKrSl+4vd9U6cEx1IXODFP7Dv51m2Cp+85nBUU5H7x9jFxJ0dHv9FsIv4czXnA40sxeI2cYmgjwEOaPxOrGRZcOAQDg7n3WT1lEc+4ytNK6/K4EE9l4ghL1uOXOiMb0piwYFj0SpenhH/iI7N38ILVozIbl7ECXR20UAa8LtnzxVfd1uYFw4fzPtlabDcTTLsBYk43QjDI5Sd/bSIU1HnEitOVNbm86AseZF+8slzJ04Zyc1A== 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=kb4MqJ9jsrYbnJZEzJiRlzYaO1N000teEcBwTsmUkHU=; b=CCaxWWacGN0ByNONnkLvOnJQtLOcyRf+MFRi6hMFouUvsPEpH67ebG3v75wBEEfL3a1U5+hHJvn4T6GrLc0P+RVEblLLIRG4QM9nRLR0N7qddnOIE9ULegxr5/t4orsTyBKkknBEwWc3XdN0LYNpWG685hTjELn/iKL2uPfqfXk= Received: from MN2PR10MB4112.namprd10.prod.outlook.com (2603:10b6:208:11e::33) by CY5PR10MB6024.namprd10.prod.outlook.com (2603:10b6:930:3c::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8511.26; Mon, 10 Mar 2025 15:38:20 +0000 Received: from MN2PR10MB4112.namprd10.prod.outlook.com ([fe80::3256:3c8c:73a9:5b9c]) by MN2PR10MB4112.namprd10.prod.outlook.com ([fe80::3256:3c8c:73a9:5b9c%7]) with mapi id 15.20.8489.025; Mon, 10 Mar 2025 15:38:20 +0000 Date: Mon, 10 Mar 2025 15:38:17 +0000 From: Lorenzo Stoakes To: Vlastimil Babka Cc: Andrew Morton , "Liam R . Howlett" , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Harry Yoo , Yosry Ahmed Subject: Re: [PATCH v2 5/7] mm/mremap: complete refactor of move_vma() Message-ID: <06e4a72b-d599-4ba0-8cfe-69050b955768@lucifer.local> References: <99922cca-ed8e-4996-8833-a89264783b28@suse.cz> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99922cca-ed8e-4996-8833-a89264783b28@suse.cz> X-ClientProxiedBy: LO2P123CA0024.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::36) To MN2PR10MB4112.namprd10.prod.outlook.com (2603:10b6:208:11e::33) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR10MB4112:EE_|CY5PR10MB6024:EE_ X-MS-Office365-Filtering-Correlation-Id: d6d4fd45-76aa-4a96-b661-08dd5fe995d1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?ieAK3paNu+xRgmS/r2hcqnZI569KuYWi3D0ASR/Gg3uPa0J4RJo5Gxo5uZl7?= =?us-ascii?Q?0Sc4XFUv3nPtZL5eXBZ6bCPeafr+dRVOWpiPEj+EgwmqJbCVTIPSIsjBCznY?= =?us-ascii?Q?Oqfwyx12CHHvvX8ivEy6vvNLo6gD1ZhMjgFaQ6a9OwwKktrSMdhoq+/c+o9j?= =?us-ascii?Q?U0bP5NuuP+7ZzBLRr8b8phr59SOaHxFXkBxfVxgjOiVBQUWXMlb3Ri01UbGl?= =?us-ascii?Q?JURYGe9hLiWxe+QXPFtQ0EI1kW9nEtNvFUq9i9EFMyTq5B8EtWUsrjGCnrHQ?= =?us-ascii?Q?BBeFBuwl7/w0hZupVbQFbqqsXYFm5aQPtmd3QvsV5iSYYsQ+VHSsqX1A17yu?= =?us-ascii?Q?5fcenJdIea+1zK39O6bGwGHSKJ7Af9Hae+p7omSD8IUgL4UN1BFzd/tHmiNs?= =?us-ascii?Q?fImM1wMgGeWviMQfpOT2mAFX1bzMQeccmqJf3zZ11vNsGfdJm0jA2VLMOuSM?= =?us-ascii?Q?yCgoccl5ipSG2rNpFR5V5S3rtO8vkbQKURWHx3ob7wdLv6C9P5f8EUEKdgq+?= =?us-ascii?Q?vsGdREU4vMjBp01ZJB+U9g1PFCvFEI4Em+etZ90ahmum1EgGb1AukoT0F4EY?= =?us-ascii?Q?r4BPy0zbm7S6kA1+NW1r2IxTK8Yq5On7MvXbn2MlF5obg5bC9mgvSHxBSB+1?= =?us-ascii?Q?RmDmhbmG3JLyN9Vjkyg4EDCYKHNCYilWqyTgPGZ5bbCCFj93V1VXf9v3su0A?= =?us-ascii?Q?FG250V6KxA96dtVyjJZqTrBgXL1oE8B8d1YySuRzRKMeSWGW+Oxfvcl3h5A3?= =?us-ascii?Q?EbyclNJi/1GA+Xhs7+1MsWUaqVRB2ZJY1Hh8lAulQir2BQYi91IiDiHruZaL?= =?us-ascii?Q?IrPo8omatBvWbpmO5wbIthrLXYoAYbDlSwbw9NtQ4Wh1BrdHp8IeJN5va0pL?= =?us-ascii?Q?4C9/YKs6qckrDau6dPNunaZmxH50WxYNvFl1CLs2thM9ne28Br44YHXj+Mj6?= =?us-ascii?Q?uy8CjTGiCQk6T0B5FwIpLo3DFIEVvSwzXoymCT3WJ+b6PEj8IVEjLW2Cz6Pn?= =?us-ascii?Q?RCyZKAYBU/34U87Oranc9vCOlEZBQ7n0M1pIDIULaSocYRO2jD91Mbo6dYCJ?= =?us-ascii?Q?oYWkk7vp8DHC1WlBKznlgM+kcXBiDc36oRDDBmLE7j7f2ckX/ypyqe4IcUBQ?= =?us-ascii?Q?Mmhf2WGmCXj26z78MDOlfY8S0ePrYRvewvnHWcOkdTFWQiw3s/zUtJluoGFH?= =?us-ascii?Q?qOdxXs8WCl/SFNxm8ySvqXM8aNFpZNjEd9iUOOXCjSujvvo1l+HmLiIzCP52?= =?us-ascii?Q?DRjpfIk0tiWC2f3qPgbm6gqpu3Tlh3pR5utSKCvMji65ml9g254KnF49Yw5e?= =?us-ascii?Q?qVplJQzoHPMeEjYrZmVP+9p4Qe3Xdsf2Ry4LQu4b7UhhSwaa0AQPQkWzAxvz?= =?us-ascii?Q?WCL6y27G3G5wKI2MzF5XI3Dd6nhJ?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR10MB4112.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?8a7C8kH+2d1S35Zx6NGAVF/ALwkOPjCHHc1hzPGmfPxNhDUuVmrLv6B/jjqZ?= =?us-ascii?Q?UPs+DsQ7NfAb2t+uukZyWvujjuXn0/3moevKFFDQuh50m+k4rhEzEXmuyoBF?= =?us-ascii?Q?swWn3RgeSqPHnu6VrOY0W0p+A+YatP/EzDb3B4SY50JmiILQYSeGhB2shS7/?= =?us-ascii?Q?Uq9ygOp7sDh1bH6keRW9D/Y70DjPHc9dnIpc/fA3xQd2Te0zc18oXNHQpE5X?= =?us-ascii?Q?ddfF4VEjD1Prnf7Fp3SQkqpoCPkwRgp9pOsdGTnQO11Xt2SRjFyNIfwA4sN2?= =?us-ascii?Q?GesZHbZFajg2Orzp5sE9eoN8fTu0ZzSuQAlVB+quArsuwE7Z2HLZJ0NQ9Gbt?= =?us-ascii?Q?aIJ0Av3evpsrFJmlGgcpV832PLFkouQNc9cVgJfvQyWQkNvwlhQ44x6j6wPM?= =?us-ascii?Q?VItZQKFDRPd0aBkl/VCIpeHaUpYZM+BTYf8XCFBVJNZZgrPAKbUfjt/dtVO3?= =?us-ascii?Q?FiHkHuh4i0kEQtHOw8vZdI8oTj0v9KVgojPhlzQfUNY2aYQYS+IwxkYBL/hy?= =?us-ascii?Q?g/RhAvyArCGbJjl6vLdNN35i7fn7/SNgJ8K6ZBCkLUynggbh+f+E3vuKnQgB?= =?us-ascii?Q?E98f3cghxs9WBb2iQ9r7dmQPyc39fnwQIoRIYkq4byL1saDCKuI+L/Q5QCVw?= =?us-ascii?Q?FXco3MRO5Zihhe5bOlX/N8fI0P8YUyJR2NwdinOKEyCvxwnVOz9eeWFNkpQm?= =?us-ascii?Q?DQbEmlzUFlyROoJNZUofwddmMJwbdexkG5RrTe1O5Z2a70tWrYUaZ9VYFixX?= =?us-ascii?Q?as8ral7STR+6IE633W/FWx4dZYn8PUr+5IxIT6GHyc0voFTHzfT4QfsMKWPk?= =?us-ascii?Q?4jNPyl8CrlWkN7V5Yk91oYURtPcYVg/3KqF5OgZfyoeDdUufu3bo5PI47RZy?= =?us-ascii?Q?CMiocXMEza+1z6bEFPUlU66HNsL2rSDzPdZ6xJu1nBrYQAmg4HDHIC2PfFct?= =?us-ascii?Q?b9lHhF813xdL/AscKi0/ThTbfWBSEfaziQ6UpjWwrc5M8Vwi97MqgWr5X4IM?= =?us-ascii?Q?k9ZLW92W06DF+PbQwOn8FKkFB9jlktRsFgb3brIKnBsh4pwfv32VCu8DTic4?= =?us-ascii?Q?2iDzunudDJhDaD6gX7/L1MqltEBKu1NlocrRl05W6Le1knf+DdgzkZ9l5ls9?= =?us-ascii?Q?zYxAqwuXPyqSuLAqOvRCeDi7qjgPL4OtBzWEQSiKpRbUBgopYvVro2+wkb6G?= =?us-ascii?Q?hdGOzoCJ0mgOgdVBgouNGJgWU3BL3R0G3erLunLQjbk6PgaPG2rTAh5QjX29?= =?us-ascii?Q?QidvmrSo8lUeuB74argyXI3BgM6TuFKRR7Pxlvnqib1mlzRDznIP+l8KoeRn?= =?us-ascii?Q?VT/KQyTDBhJqvy9hss9Bqqvj/DNRt15rjqGRDeX3Rim+zHQhR23atLvMXKIb?= =?us-ascii?Q?zP1tK8Kl4H9BuyoRPiaO3DcfeA6SxZvIOYlT3UdXhIb72MDx7F0t9FCXuWC3?= =?us-ascii?Q?JCBrFRkEODRj4DgbtDDC2S4wEoRUUweFqAtfF21V6D/6XDBvAQqMwTCmfvU/?= =?us-ascii?Q?pSwaVjhbdxYCCMDOGT6ZYo3G0vTaeAicTWi8PLtAIUowJJUSL2hjxqqlojux?= =?us-ascii?Q?gSuryeNRkh0zNLpvvTFtXH6B3X1ufsjv8GPcAkEH7ogETJac0ItQ1eYQ8Z4W?= =?us-ascii?Q?nA=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 6I8j/wuvgGdKY0/UWvYLiDgh1oYBvc3CEngDryn+6wOaWDwdvB5HYPYxOY3Vh8AIRYDY1b5VWjcaMFaWd9FOg0z972sPjbIJOodStWy+M4DwsfqdgBlXn0+u3535Rpa16eUJmSaYtbF69Fixe2JLOSJaV7KdiaNNze51g0+Sqez2wMsYjXkoWKlPoeIirsWgUIJqNVIhOSK3Dzi28wT7IoHXJ1KN5lHRjXuySd11wkgS0B9/XyVkrvt/tR0TtNUsB1ER2d2F/SCgVrTqJW5byNaPWLZRjNJauIem95ecO/mffquMhxHeDpqj4OXnLgTkZYWXlyMeH3rCFb83hdZT7/lE5tXnPaB1Vo540QeaK1Xgh7F07oU4p24+HIkkClsD/I9exuoKe4Lhg+vrWj05aYDBSbXTxTCwO4A6mCwbeOAgcHtnhml5I0t4E+24aFcA65qJi2LX/VPa1OcK7xjs0bKVkon/fnhXdtGbvG1bZFUQ0BY2GLe8BUhCmZQY+/C36NZiu08bB0ejCnHlNcochJ53JOZ5Qv2PSPszV8jWxNKZOMOtEx1JX3DXW6c918dYtrYKfSeqHvxm1eu05FIg+KKm6pn645GJRbbrK/F2RkM= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6d4fd45-76aa-4a96-b661-08dd5fe995d1 X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB4112.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2025 15:38:20.3244 (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: 0GFfF/k/qspqoFQgAyySy2zYbkirLNzL6GUqKlFfsCPtSY9wsRtY51yW/lblm4g+y0IxTKONfx86r2A0zv3A/nTx/ilFPoWzUdjBANGUT+E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR10MB6024 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1093,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-03-10_06,2025-03-07_03,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2502100000 definitions=main-2503100122 X-Proofpoint-GUID: cjBggR-2B_vPJOQeU6afn6Sc9kltMtl9 X-Proofpoint-ORIG-GUID: cjBggR-2B_vPJOQeU6afn6Sc9kltMtl9 X-Rspamd-Queue-Id: 87D45C001C X-Rspamd-Server: rspam11 X-Stat-Signature: nb5y6uy767g78gn6ej89xa6j9rrpwyk1 X-Rspam-User: X-HE-Tag: 1741621106-863109 X-HE-Meta: U2FsdGVkX18NJA6dPsC0/Iqa1hDIp34Slprqs1FtrWQFSgHqVfHLiGnfO4Dlc5u69alVAE38aYDMQUOQQmja6nqKPo3jHTC/kQDUuDltBR0iYxPCKfrHtEIGfdtX+u/c8XaRs6Xh01OStKySUHiy4DspaiWEdLP5zAElVQkZeSIdhRynyyEu4obGnyQvyLqEDoJ/ySf/Fz0nZm7wganR9HnXrR4sBHQm2/B4lX0/wMYGghk+aifvRdLDA8hTfk+zhsNffmRcPfKWvs/4OMISJlT70hA6boUu0WtHYCzkYp/Yb3v45M3DJewS3HZaXYlO+Q/ZtC/vQF3TjPiScvqA1VzJPI88L94DU5Bb78g7M93f9W2gRd+cOAvERqbWAgOpYvWCLqTjHzXbAtJCh++Wnk9kEN2BNXnJKXO7QeYcQdX6r1LPRztGuMN0Ojr87p28n6AnTzP/cbrlZQJb392KXPXfc/Y2+VLCCwzisbMpqx+g08WCAfNGLTvYY0QKRGuTQ9bELKzeFVNCMnKr4Z1HGudRSqecwSob1BqVxXGR3ZQsJUEWQ82cQZV8OSzABIXutay9boePZ4Tcax62rir2r7bVy7UNegT80HiYRlZAnFL9otK3w46diLe/h8KPKSVY/AoarCyjgYU3el/3we23vqacnZ6otLXk+51HQSx6Y6I//5WNWI3n6CN7o4gmKAjxaUCXwt5O6d8qu05nD1Auizrr9Mo/YDPlXbwUcjy/bGxWBqSin37OxR5gBDCK18yP84mmmn/xsqRnVkV/ShGStYrGPfxgVTEO7VHh2OCaiNlKC8wo0EM5Vu36txzSaYvp+4r+iJKcNZ/rEDgkJBX+Yiqy1cXB4gtLh3wmpqF3TDsXiVT1/5B8u2bGwbNwnWwiAex7hp9H/iriakwbAwOfibwuUjOdk+kJZ7DXWlShc1bm0e+yBLoY51TfmCJvBQE5K7+M7n3kwQUeMNFB7HD Oppdw/tA Dxhn58OKRkh8ClGfcPc/6w6n9GTTaC8lg+QQxGyXmvEhktHRpPrk+QOVwHYEv+9jTYjkg7UMYhngXaHWWmbuPUxgUgjnF+jt0Xnwg9pjelCz9ac4+rJmLYjBvblWxlHU+H9IPyOTB4RcOG/ihnPO5aF+Db4Y6urBx7Ig1jpHbqRicw/GBCbkXxviADNAntSE2tEvbLD7x1mkTM13VhAjlVSvvuZfSla4bqWzlT8JxhZ5+2tPAhA+PQuVOtzCJRmO6n9v05uvgRQesmX7h9FgQEySEeO5WBDWJkbLRVCB1pd7N8aVN8C54qG1KkYigDu5AHdyGByYAdESpptPm4exhrzjCMb3ljXkFJlMXfB4A9ITB30EwexUjeCLNnQod+6C0VeZfzMQyUithH5TpdC3ztcqX0hCbuGokbUmm+ahuAuNHXhhbSmxlzChaSB44bMBj1QxVz0Jv7SMzHJEBc9PQQbkftrA7TjDUwQyH0KEafkPyadbLY1hsdWv/mo9+KCZhl3RpQYsgq7+941G9hSzY9xYTfyXWw3A2IrGy/yZZBCpfXOxVlnBSpxntVjyMvm19IUOEPdbrKpyi5NO7/MAmLw7+ISk0t+72PMhVOlGpqVTJKBZj8R91zrQwQt4LRUeMzhlaILY+amswCPAQgEs2ZEaI8W4+qpEgymE9 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000049, 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 Mon, Mar 10, 2025 at 04:11:59PM +0100, Vlastimil Babka wrote: > On 3/6/25 11:34, Lorenzo Stoakes wrote: > > We invoke ksm_madvise() with an intentionally dummy flags field, so no > > need to pass around. > > > > Additionally, the code tries to be 'clever' with account_start, > > account_end, using these to both check that vma->vm_start != 0 and that we > > ought to account the newly split portion of VMA post-move, either before > > or after it. > > > > We need to do this because we intentionally removed VM_ACCOUNT on the VMA > > prior to unmapping, so we don't erroneously unaccount memory (we have > > already calculated the correct amount to account and accounted it, any > > subsequent subtraction will be incorrect). > > > > This patch significantly expands the comment (from 2002!) about > > 'concealing' the flag to make it abundantly clear what's going on, as well > > as adding and expanding a number of other comments also. > > > > We can remove account_start, account_end by instead tracking when we > > account (i.e. vma->vm_flags has the VM_ACCOUNT flag set, and this is not > > an MREMAP_DONTUNMAP operation), and figuring out when to reinstate the > > VM_ACCOUNT flag on prior/subsequent VMAs separately. > > > > We additionally break the function into logical pieces and attack the very > > confusing error handling logic (where, for instance, new_addr is set to > > err). > > > > After this change the code is considerably more readable and easy to > > manipulate. > > > > Signed-off-by: Lorenzo Stoakes > > Reviewed-by: Vlastimil Babka Thanks! > > Some nits below: > > > +/* > > + * Unmap source VMA for VMA move, turning it from a copy to a move, being > > + * careful to ensure we do not underflow memory account while doing so if an > > + * accountable move. > > + * > > + * This is best effort, if we fail to unmap then we simply try > > this looks like an unfinished sentence? Damn yeah, will fix. Will wait for rest of your review before either fix-patching or respinning. > > > @@ -1007,51 +1157,15 @@ static unsigned long move_vma(struct vma_remap_struct *vrm) > > */ > > hiwater_vm = mm->hiwater_vm; > > This... > > > - /* Tell pfnmap has moved from this vma */ > > - if (unlikely(vma->vm_flags & VM_PFNMAP)) > > - untrack_pfn_clear(vma); > > - > > - if (unlikely(!err && (vrm->flags & MREMAP_DONTUNMAP))) { > > - /* We always clear VM_LOCKED[ONFAULT] on the old vma */ > > - vm_flags_clear(vma, VM_LOCKED_MASK); > > - > > - /* > > - * anon_vma links of the old vma is no longer needed after its page > > - * table has been moved. > > - */ > > - if (new_vma != vma && vma->vm_start == old_addr && > > - vma->vm_end == (old_addr + old_len)) > > - unlink_anon_vmas(vma); > > - > > - /* Because we won't unmap we don't need to touch locked_vm */ > > - vrm_stat_account(vrm, new_len); > > - return new_addr; > > - } > > - > > - vrm_stat_account(vrm, new_len); > > - > > - vma_iter_init(&vmi, mm, old_addr); > > - if (do_vmi_munmap(&vmi, mm, old_addr, old_len, vrm->uf_unmap, false) < 0) { > > - /* OOM: unable to split vma, just get accounts right */ > > - if (vm_flags & VM_ACCOUNT && !(vrm->flags & MREMAP_DONTUNMAP)) > > - vm_acct_memory(old_len >> PAGE_SHIFT); > > - account_start = account_end = false; > > - } > > + vrm_stat_account(vrm, vrm->new_len); > > + if (unlikely(!err && (vrm->flags & MREMAP_DONTUNMAP))) > > + dontunmap_complete(vrm, new_vma); > > + else > > + unmap_source_vma(vrm); > > > > mm->hiwater_vm = hiwater_vm; > > ... and this AFAICS only applies to the unmap_source_vma() case. And from > the comment it seems only to the "undo destination vma" variant. BTW this > also means the unmap_source_vma() name is rather misleading? I agree it's only meaningful in that case, I am not sure what you mean about the undo destination vma case? We have 3 situations in which we call unmap_source_vma(): 1. normal, no error move. 2. error has occured, so we set the source to destination and vice-versa. 3. MREMAP_DONTUNMAP, error has occured, so we set the source to destination and vice-versa. I _hate_ this error handling where we reverse the source/destination, it's so confusing, but since we are doing that, I still think unmap_source_vma() is meaningful. unmap_old_vma() is possible too, but I think less clear... The beter fix I think is to find a less awful way to do the error handling. > > So I think the whole handling of that hiwater_vm could move to > unmap_source_vma(). It should not matter if we take the snapshot of > hiwater_vm only after vrm_stat_account() bumps the total_vm. Nobody else can > be racing with us to permanently turn that total_vm to a hiwater_vm. > > (this is probably a potential cleanup for a followup-patch anyway) Yup agreed, but let's do it as a follow up as this is how it is in the original code. Will add to the whiteboard TODO... > > > > > - /* Restore VM_ACCOUNT if one or two pieces of vma left */ > > - if (account_start) { > > - vma = vma_prev(&vmi); > > - vm_flags_set(vma, VM_ACCOUNT); > > - } > > - > > - if (account_end) { > > - vma = vma_next(&vmi); > > - vm_flags_set(vma, VM_ACCOUNT); > > - } > > - > > - return new_addr; > > + return err ? (unsigned long)err : vrm->new_addr; > > } > > > > /* > > -- > > 2.48.1 >