From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (mail.openvz.org [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id F1B518045D for ; Wed, 28 Oct 2026 15:15:26 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 69SFE9fe021370; Wed, 28 Oct 2026 18:14:10 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69SFE9fe021370 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="bnlURhh6" Received: from mail-yx1-f70.google.com (mail-yx1-f70.google.com [74.125.224.70]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 69SFE4Ik021357 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Wed, 28 Oct 2026 18:14:04 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69SFE4Ik021357 Received: by mail-yx1-f70.google.com with SMTP id 956f58d0204a3-679b96a1e29so1891450d50.0 for ; Wed, 28 Oct 2026 08:14:04 -0700 (PDT) X-Forwarded-Encrypted: i=3; AKwUvByvV79lmtXoFhg6sNpcelobL64b0OJecSugPwgJokuEhmJDLb2m4qBfdEnm8GcGRuBk6pI5QQ==@openvz.org X-Gm-Message-State: AFq9FYKKCFDUd+LVNbpEzBCKG9r72MWYBYdlfeBsOJAvkpbudUyt0Gbb 3EqiRl9HTwzoOXxWUG4PLBDiQ0/kfPf2q055IEv3T3pNe151ywYhLpSBU3zNMSlcdiUxf4DzLLr aSjwGmf3isCyHPUi+kV3fzGz/TRLwALGI3ArZGsGdv2XUFAK5RlDWsA== X-Gm-Gg: AYBFou2WsfeNhzuQf2p0L338Qcd6JpvswJnQJab/DW5yQv5SagrPoq7XaTfelRdA7Me +Z0N7AgLk/bIKmUII+fnQKJN+KeuAejN/LehJ6R0rvhYZ/2+Dq8Sx/CVr+3Kv6tKttZNNKK/tS3 rYkeUup/KGcgkh+1RYIXSpmKfGe2O0cpTaL/hxsbTIRiZkWOuDDlx+cNCwb7Fov5iROO1SZ4Mw7 s6jR5w0j+K7KckLCbDNWFKoLDOBMq9QRzHbAQk7flMj0mM2zjTTGrIzKsXHTpJcs0Duok/WIaCp eRqroTvkzzGjpBGiu98jjAFv7UJAhqHgu0cn/l+dISaWl6y9qvXQJkpiF+dWvilkjamobPl7499 83f6ngHWtJKTOUyykWqw+Z/uTnod1bqcfaYFFnsuVzZ6Aq1ByzmHUdQWWi7vjF429eJtDA0/QrZ co3SlKxIvMrZhSEWTVZG2VMFwy4g== X-Received: by 2002:a05:690e:806:20b0:679:b0d3:9f1d with SMTP id 956f58d0204a3-67a7bc9a2dcmr1565367d50.47.1793200443390; Wed, 28 Oct 2026 08:14:03 -0700 (PDT) X-Received: by 2002:a05:690e:806:20b0:679:b0d3:9f1d with SMTP id 956f58d0204a3-67a7bc9a2dcmr1565347d50.47.1793200442699; Wed, 28 Oct 2026 08:14:02 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1793200442; cv=pass; d=google.com; s=arc-20260327; b=Xsr+I7xGSMRg5TZzLZ5NsX7oB2RIIOqyHDWiSpnB9F1MA5xgVo4jY2o0rWZH3czSnO ERpYrMYeDXfyEap7J+2c1sP/vg2+DUPZwFUHcJNAaHmYfsTVTt3YQExy2h5NMIRtVVm0 w+5RIYsQAYowQ9FzbzpXF93NmLlJPW1cSxLmamtceo3GYOFgXLv4tJcN/lURwQYOEUBN /UUgjS4DNmbIQjlbICIcm2UZon36rOq6TZLIohgMcKy9gjff/zNqK1fTJMOZk3ieaFD5 /qHMuL/hpkLTh0ZqQHZw71w05tgEw1rFu4nSTeLYbR31gaUlSeN8vVUIbljcYUE0ChGh B9Bw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=mime-version:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:date :message-id:dkim-signature; bh=1sl6C4hZoLCfMInJwLRa3GSwwGng5G2JDbiuuc0bU+8=; fh=XJZBkifkCHyRfHgc4tR73Ll/KrY/6ePDIY7RA/i17hc=; b=JaPfDikcUK5ZSs2LeRr2Bx3qARypbVrYDiFRoUm1XomXdk6mEDuAq/FLXLdO63mkIG Ymc27thdrvoBF5P1cEakleEey4s5M/WMk1xQ4VPfg/9auUkzcX8e4162qC6CKaXzz2NX 7q7Rfbaj4k+dZ7ne9yeKWQfoauv+hMuB+ijeXcwdqVovEoM+jRDGT2zZOS8eUbgYgQiu JEkGBgJBvD+EOsmFTKrzg6HOuelh1NVlknB6Jb1IxTH42NCuCgaE5i6Wni/FD1v8jZb0 2pwECeR3Rfd0dV+3TxClfRGY/Nx3U1hZv2V2SBM5qKLetXH+UKtnEsw6ACdmKBmdpVFm 9P2Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=bnlURhh6; arc=pass (i=1 spf=pass spfdomain=virtuozzo.com dkim=pass dkdomain=virtuozzo.com dmarc=pass fromdomain=virtuozzo.com); spf=pass (google.com: domain of ptikhomirov@virtuozzo.com designates 2a01:111:f403:c200::3 as permitted sender) smtp.mailfrom=ptikhomirov@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from DU2PR03CU002.outbound.protection.outlook.com (mail-northeuropeazlp170110003.outbound.protection.outlook.com. [2a01:111:f403:c200::3]) by mx.google.com with ESMTPS id 956f58d0204a3-67a7a1462cbsi2540466d50.238.2026.10.28.08.14.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2026 08:14:02 -0700 (PDT) Received-SPF: pass (google.com: domain of ptikhomirov@virtuozzo.com designates 2a01:111:f403:c200::3 as permitted sender) client-ip=2a01:111:f403:c200::3; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=bnlURhh6; arc=pass (i=1 spf=pass spfdomain=virtuozzo.com dkim=pass dkdomain=virtuozzo.com dmarc=pass fromdomain=virtuozzo.com); spf=pass (google.com: domain of ptikhomirov@virtuozzo.com designates 2a01:111:f403:c200::3 as permitted sender) smtp.mailfrom=ptikhomirov@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=rBCIztvGT5dewRAU/GpjJjvxgB2WKWxVzy2YDJJ0aQdawLr0zw6ImSfT2Zra+WAXcAVWGyVK1FLMilTByd32XkCOAx6DVLXfO+ahJ+gPwhzR38J4eyzSwKJzbLXoR0jp7CgWKnSf9VE/DjQt8K4JLWQodUU9x7EcvCYdWlFgfsjxGyBjS+iB6bs1wgmCMsPypNIBiJNCB7dvShPi10dzk+2cFXuKF5+ICY1NL2nMqIZOjUaKYkoMhX9S5BZt5w12ZBZPuvgs2YxGb9yJEgsIz4bfE6Qpz92+YWGGJulTouC4A8DC8v0KEhSsEEbq64/hIcYYrVyiwV18U83LjdDcHQ== 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=1sl6C4hZoLCfMInJwLRa3GSwwGng5G2JDbiuuc0bU+8=; b=vSHNk3gkjDlcS5vlJcY6ySmbP9WC4cn0xPt7K3dJUFFiZS5iuMakkiw3Xr5ZaLBMG7eC/VeDnQf1CGw6N+zZuKLDMrLAAgrKgrqrZek/ThtTUx0g91d6XLy/tptp7t8MD7YD2LmhDwWifdFaEgfyJvsIzCFuSlOVUHfCawJZRX6D4Lrx/XePUKsaoa2hc1MPjXHPkj4mprFkoMw8AYmTwuCiTpU+30H0PmRsIQtqBGFEQdSu4lJpZbPaR/gA1DgzzamRgHdRC4n05hyV+geD95d1Vmq2H4WqdbVynpbb7147a20JkJNf6R916E3cIx9H/0yZekEshbHCqcGPSqVn5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=virtuozzo.com; dmarc=pass action=none header.from=virtuozzo.com; dkim=pass header.d=virtuozzo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1sl6C4hZoLCfMInJwLRa3GSwwGng5G2JDbiuuc0bU+8=; b=bnlURhh6CLjQMrWWxQxZhvJPrLzW6u6oaYGyC1rzWq1eDTW/1Y0uOiaegBFUFR/fB4cG/LxEJoifvFzerxpDNKVantzFDJ3aYQoX+7Wa4X/sMkBxYPH6d82fEg8HjUiHxNzqN4n9QYABh8pJ2hsvEstvazBoWCPqCJ77MdZBdnP+vXRhQHpJlhyo9bhleJhnbLmN15myb7W/eD9I3wQRu/Ni9x10s2RL6kUUCFgZbniOCacluTOMBKNJ07jPAS681/L01s90w36W63+AA6tz/Tcnqqzb1UztMyE4KTYZ3sC6tKv5shcIYYdCBicRFTh7EBWk9xpJ7CGQNgco4xYlrA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virtuozzo.com; Received: from AM0PR08MB11804.eurprd08.prod.outlook.com (2603:10a6:20b:747::14) by AM9PR08MB6243.eurprd08.prod.outlook.com (2603:10a6:20b:2db::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.22; Wed, 28 Oct 2026 15:13:57 +0000 Received: from AM0PR08MB11804.eurprd08.prod.outlook.com ([fe80::bf46:f137:f6d2:5b3a]) by AM0PR08MB11804.eurprd08.prod.outlook.com ([fe80::bf46:f137:f6d2:5b3a%7]) with mapi id 15.21.0569.007; Wed, 28 Oct 2026 15:13:57 +0000 Message-ID: <480fb7ea-f2b9-4c97-88a1-c2941ffa6c7e@virtuozzo.com> Date: Wed, 28 Oct 2026 16:13:56 +0100 User-Agent: Mozilla Thunderbird To: Konstantin Khorenko References: <20261028-b4-prep-khorenko-vstor-151607-numa-migrate-order-v2-0-b973a82a5b0c@virtuozzo.com> Content-Language: en-US From: Pavel Tikhomirov In-Reply-To: <20261028-b4-prep-khorenko-vstor-151607-numa-migrate-order-v2-0-b973a82a5b0c@virtuozzo.com> X-ClientProxiedBy: BE1P281CA0016.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:15::15) To AM0PR08MB11804.eurprd08.prod.outlook.com (2603:10a6:20b:747::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM0PR08MB11804:EE_|AM9PR08MB6243:EE_ X-MS-Office365-Filtering-Correlation-Id: 552639f9-a5aa-49ca-e9db-08df350616a8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|10070799003|366016|23010399003|1800799024|376014|18002099003|6133799003|22082099003|261026140227099003|261021123027099003|56012099006|10067099003|5023799004|261009223027099003|261022115727099003|261022075727099003|261021121427099003|261022105027099003|261026121527099003; X-Microsoft-Antispam-Message-Info: ocp1s+8nNPOCGk3vdQKu8vk+VNahSzEaF3RRgWWk8J0UmV2J3cm9Zv9eTsSUu/xKmtx2WBb7tdnW6VOO1ADROQiDFhOlx3+W6hzBgTcJH0VSdK3mMGgvxiWQIfzxeQjDKgY3rFZ5dPPLHUONrBWafYp4kgbUf4tTV8THnUOpWJh32gvazsKszQ47ZmLTBkpqa59QR7tp8tZ4QlAsxGQ/CDOa0QDO7TIlEs+CjRTdiZUrgqZulNpD8puhn9OdLv6I7GO4Lb5XHOecAZO81E4WSx4GFlYq9M+jYoM3CruhwKY12fVKXUDqgdpOBisxQ1d2vtYSPxsqLF8UtlEXx07wL3GhlAh1Pqf4VRxRLglLLChA0WLJ4KsKEKMG0IY5zbFC/inSbf8kKgDj7A/3cH7US5+EwPJOgi/e5NjUR1Lt7OvEoTPg/+Q2IwK+uTXkbbzGfCQ/8PtPOySTsdImP0R1OQTEvwjHQdtNtBzo95j8kMeWJbhr7SQ2OLMceei4DYq4QOgZbPr0/CnPUEP5GVrF6xYmR5XtSI/Gu+JrpdPUfTYRLYsKlxQ7PGdkAG8gU2ZlyfNVuLIcsxjwxOk/EvEKEZk1CnDy3G/Afnnn737nqh98RVelBhnD3+ONlsihvHz9 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB11804.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(10070799003)(366016)(23010399003)(1800799024)(376014)(18002099003)(6133799003)(22082099003)(261026140227099003)(261021123027099003)(56012099006)(10067099003)(5023799004)(261009223027099003)(261022115727099003)(261022075727099003)(261021121427099003)(261022105027099003)(261026121527099003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TXFaYU5uTXNjb3N3eWh6SlpMQ0dSTmJVVTRkRlhkTU9MRXBZUWd6bXVyRGFj?= =?utf-8?B?elBLQWJHWUJUTFRIakhoOUZnbEpuQVFPRktzcHBRbEpSRFRGYllpRGp0Qml6?= =?utf-8?B?NUNxdTRnSnlJU0EvQlVzQWg5NHhrOVlvZWM4RHJENkxYaUZxejZEa1JjZ05N?= =?utf-8?B?RlZ1U3VyK0NlT2o0aVlIZXZsRWkzdjJkMUZQbGtBZ291YWJUVzFRTm16WlNM?= =?utf-8?B?VER1ZllVNVBqOHJFcFVyeXJlZ0llRHUrQ1N5NXVWdlFNeVZ3U09qV2hzQWpJ?= =?utf-8?B?dnZCYTVpRXZhRm1heWo5NFVROXRTRnZzOElFS2tXTEVtY2ZMbXZHVS9vUUFB?= =?utf-8?B?cFZ4NlhEMmFxdDFGN21ibldLSHlHbWprOU5tcWJpdnJLRS84Y3Zjb09hbGtq?= =?utf-8?B?Wm5SUTJiRFc1TndiWk1HMEJwRCt5Ykx4TVpvZzBMUkNWVmRwaG80WWpVSzkv?= =?utf-8?B?dE03WGZ1QWlrY1QvRlFzRVNQTmwxY0tEV2Z1MXNkTmI0d3dGY04xdXM4dVh1?= =?utf-8?B?aytXbm9GRThFTW8wVlhWejRhU1g5bEdqbk5PRWlKdXhqYVdGNVNMSFJJV2xk?= =?utf-8?B?eDVwNVVTYzcrd3hBNWlpV2Fkaml5djZFMWtMRW9uOWJVMXdJa3Y5eGNxdEdt?= =?utf-8?B?ZW5VTkgyUXMvRGRDVTJFZ3I2RW5XMGw2dUt0SWt4RUR4WXFETzg3ME1JdFNN?= =?utf-8?B?RTZCWkRBbzM4dmFHYnZUTk9sL3FqcU9ERktKd2dKa2dIY2Yrbzh0bFNGZGY4?= =?utf-8?B?WnJCMXNCTXErMFFSbGlCQU1pck9zeGlqQjdSS29CQVgxc0twTUlmd2d0cG13?= =?utf-8?B?T3FHdjRZTzl4aDV0aUdsOVJDWHlkZXJVS3lmVzl6cFNzY1U3RmY3OHQvZlFZ?= =?utf-8?B?WkFYbkFJZ251ZTF5dkJYY293UjJITG9kZFFZRUgwb2doTGxrRWl3UmVYYjNZ?= =?utf-8?B?MXFHNDRCb2gzSHlZemRYZmFiR1NYNzVwSFJlN1hUTHJNZVlHZ3Jzd2VyTjVt?= =?utf-8?B?Um9hc1NCbHBUV0hEU21RZktLQ0pzN0JpV1lWczVOcEdiQlo3L0IzdUpoRnBW?= =?utf-8?B?cEdlYlpXR3ZyREREWHlWRG1reUpPVXZEWUdZQlZLRkh4ZHpFbVVybnBka3FN?= =?utf-8?B?YjhLellCazg5MEwvTFVDeEZuSmVxUGNNRHp6N0hUMWpKTmVDb0VZQVkraWVX?= =?utf-8?B?aWlhLzhFdTVTazNEd2pQYUdRdmFVcldtY0t1d0xLL1JLZkZ2cVVWUXBkNUsv?= =?utf-8?B?eEFtSzZyWk5oT3J3eFJYY0czTTk0eTR1bFlJc0NHMi93T3RnM1J0M3ZUWmVj?= =?utf-8?B?UDY5ejN4U1E1bFBnbE5RRWw5TlMwL1lWY2ZuSTFsN25qRVpYZGt0TUI0U3JO?= =?utf-8?B?QUN0SlhxUmRPSHRFdEFKSkFBd1pRWTBGRWxJVlNPZHgvZDVMSHRVMXkrOGVn?= =?utf-8?B?MFdqSHFuVVl2RXMyaU5HZmpONzkvdEZHTXNlZjB3SEw3VXU1RnVady9aZWd4?= =?utf-8?B?UU5hVGkvTkV3UVlZNmNEdktaRWJPSjF3KzJwMC9ZcVpaUko5aHNHMElHbDVV?= =?utf-8?B?RkplZE9LV3dreFRXZGtSSXNrZkNyMFBGN0Z1YytDdExOVnJubkVjaWg4dVNY?= =?utf-8?B?Rmo4UCtmZGVSdFNDZnBSTEExcHhwVHZqOEZwSExSTjFEamxhMTZXbGQ3ZjRr?= =?utf-8?B?Wmp2ZnJ0NTRsMFpkZ0NQTXdZMnRabzRMWEM1UmN3S0RRaVB3dmJWNFZ6Wk1y?= =?utf-8?B?U2RxZXJ3Rmo1ajlTM0hDNlMyNnNrVHJxMEJOa0JFNWh4eWd3a2crUVhZRWlx?= =?utf-8?B?aVp5c1pRVmRnSEJ0QmNPR2g2SjV3U0NKMmw5Y0VYcTNjc3J0dDdkNUpVa0p0?= =?utf-8?B?cFFrU2hvdW12M1dXcE50eGVGaTN1MGc4a0E2cFNNaTBNaWFyRmJBaHJoeGhV?= =?utf-8?B?NmI3Y244R2RiQ2RlUW8vU25rZ0xQY1NCNVNpTHNJR1lsS0FtdUc2UVVDeTRY?= =?utf-8?B?dGRDY295WU12TFVmalczTHRER0ZuNmExZ2xjY05SMmFrc3hlK0x2eGw5WHFN?= =?utf-8?B?SlBkL3ZLODhiSElLajJwZHVaaUQ4QTVNeTFpRWRMMzUzYWxpSjZRSWNqOEZO?= =?utf-8?B?Wnp2a2toTjhPQVlGa1p1TEVmYlFWUm9CamxiMUNkR2k3UXJ3dkU2M0pBbEhS?= =?utf-8?B?d3Vhc2pIT1F2aEhtZ1g0dHNNSGkyY3FpZnlLd0cxMml5K3gyc0tLZWhQNDZ4?= =?utf-8?B?RmRzNEFObDVYaG9MbGplclJXVEhhN1A1ZXEwNWsrdUdPdjVIWnFGeXRSNGM3?= =?utf-8?B?b2N3YkVZR0paeFk2ZWdiVWIyRDJPOGIveDlVYXVxM3diaU5VNTlhNkZpMDVH?= =?utf-8?Q?njQxmR3YlIgXiOTzakkcCSDQiVDHuo8DZGz2xAdEAbapi?= X-MS-Exchange-AntiSpam-MessageData-1: ftYuSqDFIRXG+DO3uxjVP6RuB5VxS1OiHkU= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 552639f9-a5aa-49ca-e9db-08df350616a8 X-MS-Exchange-CrossTenant-AuthSource: AM0PR08MB11804.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2026 15:13:57.6851 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 52K+PEHJRUDfakmvb9DxOldP1QYhXjsyUWNLRsB3yRc7CuLA+e8e9LuDc1fC4MM8TY3aVNvsPW6PP9z/x7gattlZ7gtFwS1PC5EzQ3s12qo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6243 X-OZ-Fwd: true Cc: devel@openvz.org Subject: Re: [Devel] [PATCH hci-8.1 v2 0/2] mm/memcontrol: numa_migrate destinations of the source folio order X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org Looks good. (except that sashiko reveiw should be handled) Reviewed-by: Pavel Tikhomirov On 10/28/26 15:17, Konstantin Khorenko wrote: > memory.numa_migrate, our memcg file that vcmmd uses to move a cgroup's > memory between NUMA nodes, allocates a 2 MB destination for every large > folio it migrates. Page cache folios of a smaller order get a > destination of the wrong size, and the page cache falls apart around > it. Patch 1 is the fix, patch 2 a selftest that catches it without > crashing the node. > > What the customer hit > ===================== > > A two-node VMware host runs VMs with vcmmd's NUMA policy enabled, so > every few minutes vcmmd writes memory.numa_migrate for a VM's cgroup. > qemu writes its backup scratch file on NFS, and NFS sizes each page > cache folio to the write, so that file is full of order-1 to order-5 > folios. Closing the scratch file dies in nfs4_evict_inode(): > > kernel BUG at fs/inode.c:737! > RIP: 0010:clear_inode+0x75/0x80 > > mapping->nrpages of the inode is negative, and the vmcore holds > order-9 folios of that file with an index not aligned to 512, the > refcount of a small folio, and whole xarray ranges of live folios that > are no longer in the tree. Reads of the migrated ranges return garbage, > so the backups taken on that host while the policy was active should > be verified. The same crash was filed as VSTOR-151676. > > Where the 2 MB comes from > ========================= > > memcg_numa_migrate_new_folio() is the migrate_pages() allocation > callback. Its large folio branch dates from vz8 and copies the 4.18 > new_page() in mm/mempolicy.c: > > if (thp_migration_supported() && PageTransHuge(page)) > alloc ... HPAGE_PMD_ORDER > > A compound page on the LRU could only be a PMD-sized THP then, so the > test implied the order. Upstream replaced that with folio_order() of > the source when its allocators moved to folios, ffe06786b540 > ("mm/migrate: Use a folio in alloc_migration_target()"). Our copy kept > the shape, only PageTransHuge() became folio_test_large(), which is > folio_test_head() and is true for any order from 1 up. NFS and XFS > large folios, shmem and anonymous mTHP now all reach it. > > Why an oversized destination breaks the page cache > ================================================== > > The two sides of the page cache size the folio differently. > > On insertion __folio_migrate_mapping() takes everything from the > source: nr = folio_nr_pages(old), the xarray state at the old index > with no xas_set_order(), newfolio->index = old->index, > folio_ref_add(newfolio, nr), and xas_store() replaces exactly the slots > the source occupied. folio_copy() copies the source pages only. So a > 2 MB folio enters the cache as, say, a 4-page one: 4 xarray slots, 4 > extra references, nrpages unchanged, 4 pages of valid data. > > Everything afterwards asks the folio itself, and it answers order 9: > > - page_cache_delete(): xas_set_order(index, 9) and nrpages -= 512. > 512 slots wiped instead of 4, with the index rounded down to 512 so > that other live folios lose their slots, and 512 subtracted instead > of 4. That is the negative nrpages and the orphaned folios. > - __remove_mapping(): expects 1 + 512 references and finds 1 + 4. > Reclaim can never free the folio. > - filemap_free_folio(): drops 512 references from a handful at > eviction. The refcount goes negative and the folio leaks. > - reads: folio_file_page() picks the page by its offset inside the > folio, but only the first pages were copied. > > While the folio sits in the cache and is read through its own slots > nothing is visible. It breaks the first time something applies > folio_nr_pages() or folio_order() to it: invalidation, truncate, > reclaim, inode eviction. On NFS cache invalidation is routine (an > attribute change), so the bug shows up there instead of staying a > silent 2 MB leak per folio. > > In short: inserted by the source size, removed by the destination > size. That only works when the two match, which for a real THP they > always did. A debug kernel says the same on the first migration, in > mem_cgroup_migrate(): > > VM_BUG_ON_FOLIO(folio_nr_pages(old) != folio_nr_pages(new)) > > The patches > =========== > > Patch 1 allocates the destination with folio_order() of the source, > GFP_TRANSHUGE_LIGHT for large folios as before. The > thp_migration_supported() test goes: migrate_pages() splits PMD-mappable > folios itself when THP migration is unsupported, and every other large > folio still needs a matching destination. > > Patch 2 adds tools/testing/selftests/ve/ve_numa_migrate_test.c. It > binds a cgroup to one NUMA node, writes a file on a loop-mounted XFS > image in 64K chunks so that the page cache holds large folios, migrates > the cgroup to the other node through memory.numa_migrate and compares > what reads back. memory.current cannot serve as the detector: > mem_cgroup_migrate() only transfers the charge, whatever the size > mismatch. On an unfixed kernel the comparison fails and the test leaves > the image mounted on purpose, since evicting the inode would hit the > BUG_ON. > > The folio sizes are not taken on faith: before the migration the test > reads the compound flags of the file's pages through /proc/self/pagemap > and /proc/kpageflags, and a file without a large folio fails the test. > That is deliberate: a skip would hide that the test no longer reaches > the bug, a failure says the setup needs another way to get large > folios. After the comparison the test polls memory.numa_stat for a few > seconds to see that something was migrated, as memcg flushes its > per-cpu counters lazily. It needs root, two NUMA nodes with memory > (numa=fake=2 is enough), cgroup2 with memory and cpuset, and mkfs.xfs; > it skips otherwise. > > Testing > ======= > > On a VM booted with numa=fake=2: > > - the reproducer (64K and 8K writes on XFS from a node-bound cgroup, > memory.numa_migrate to the other node, unlink) kills the unfixed > debug kernel on the VM_BUG_ON above and the release kernel in > clear_inode(); with patch 1 migration succeeds and unlink and > eviction complete; > - the selftest passes on the fixed kernel and fails on the comparison > on 22.11 without taking the node down. > > Other branches > ============== > > The same patch applies as is to the 20.x branch (the customer's > kernel) and is on pr/khorenko-VSTOR-151607-numa-migrate-order-20.x; > the function is a plain callback, so it is a ReadyKernel candidate. > vz9 carries the same PageTransHuge() code, but 5.14 has no non-PMD > large folios on the LRU, so it is not reachable there. > > https://virtuozzo.atlassian.net/browse/VSTOR-151607 > > Assisted-by: LLM > Signed-off-by: Konstantin Khorenko > --- > Changes in v2: > - Patch 1: the commit message says why the thp_migration_supported() > check goes (Pavel). > - Patch 2: the folio sizes are checked through /proc/self/pagemap and > /proc/kpageflags before the migration; a file without a large folio > fails the test on purpose (Pavel). > - Patch 2: the read-back comparison runs first and the memory.numa_stat > check after it, polled for a few seconds, since memory_numa_stat_show() > flushes the per-cpu counters only past a per-CPU threshold (Vasileios). > - Reviewed-by from Pavel and Vasileios on both patches. > - Link to v1: http://lore.virtuozzo.com/20261028-b4-prep-khorenko-vstor-151607-numa-migrate-order-v1-0-268336526677@virtuozzo.com > > --- > Konstantin Khorenko (2): > mm/memcontrol: allocate numa_migrate targets of the source folio order > selftests/ve: check memory.numa_migrate keeps the folio order > > mm/memcontrol.c | 11 +- > tools/testing/selftests/ve/Makefile | 1 + > tools/testing/selftests/ve/ve_numa_migrate_test.c | 384 ++++++++++++++++++++++ > 3 files changed, 391 insertions(+), 5 deletions(-) > --- > base-commit: b499efa17aa9fb8f20512d1831d1cb61b22e60d3 > change-id: 20261028-b4-prep-khorenko-vstor-151607-numa-migrate-order-4e3a664a89d4 > > Best regards, > -- > Konstantin Khorenko, > Virtuozzo Linux Kernel Team -- Best regards, Pavel Tikhomirov Senior Software Developer, Virtuozzo. _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel