From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (unknown [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id 62AA98017D for ; Fri, 18 Sep 2026 15:07:54 +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 68IF6Ucg000514; Fri, 18 Sep 2026 18:06:31 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68IF6Ucg000514 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="J07xfE9H" Received: from mail-yw1-f198.google.com (mail-yw1-f198.google.com [209.85.128.198]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 68IF6SUo000510 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Fri, 18 Sep 2026 18:06:29 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68IF6SUo000510 Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-88eaf831140so10508467b3.3 for ; Fri, 18 Sep 2026 08:06:29 -0700 (PDT) X-Gm-Message-State: AFuF++nNTg5oAUDn/c3M6VxnxSBNScZ1TQ5lmhBJu3ag46t3ZzV1J6t2 hlaSRV+QKhCDQYHKszY3JIaB+/x1WXlB1PCAfadmj9y1iLsYBGaEyillL04qsP+o53D1U9Jldpn 9sPZuochrlA/MC2WSuC15O2rvVSjmbQ9zz6uvNmFhwOZDFczxB/Bggw== X-Gm-Gg: AYBFou3J2UoZVUmpQ4clD8OwLbIh8JUVf2RuXkJq3XMvHtyUFlm7qXxuXlGDo5yt8Is MFBnNIZxAa4Vbbl64uuIC/cOc84LHinHE31iAOzBBPnzdu535ed4l6OqQnQvBJXwhzPCKT7UBks kd1JPIqtlvtVsgOj+If9C0aQQtaVtYZteeVp1/wzDOyWDQkh3vc+dROs+AHZksOrDrZsWTtzY8m okT9UWsWBBO3Zo53hHFq8QeoFg3UBAA47BaCtmjlJ4qzXa6F+sh4NHNGJVEuJq0zEB5VpLXbA3L WeM8ZZMDyZNySWDaWunLnaJl1UHHU3TkkqN5DEuoa6nSqqwDCounAIshTB3j32zovZB/S7S2gVx aJvlbKu7BQ3r8ELa1vkuV94HvrEj2dX+8hnK4KPEeZDtu8X203Xcm/n/HpO68EkBQRiTwFvmch2 uf/EWUMY3D6h55DK8XoAUBEXhwah1ewRyn X-Received: by 2002:a05:690c:c3a5:b0:87a:db19:62e1 with SMTP id 00721157ae682-89731ba4b1dmr6163527b3.26.1789743987824; Fri, 18 Sep 2026 08:06:27 -0700 (PDT) X-Received: by 2002:a05:690c:c3a5:b0:87a:db19:62e1 with SMTP id 00721157ae682-89731ba4b1dmr6163347b3.26.1789743987249; Fri, 18 Sep 2026 08:06:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1789743987; cv=pass; d=google.com; s=arc-20260327; b=LR6oiSnCAncjp8hme9cD5LVeiJ7uCvVKCeDaCjuYxyqsSA0Pn54HeDs5MmJWOPnAI7 /ob6HdLGKlfK82KLjbRPdX9uqpHcWCPsln5FzDSAqvbOEwaVnbSn3Js9t7tx74lc1QK2 sFehsxDP+Df9GtsVTSPRd5ZoRk6f7DqcGW+ZMSh0WK6g5qxZxyfgJpoRcf+cJl3g0QRG A35yukYYbvq58sggJJUOqOUhy1ZTaiQoMGhTPzMcuPWqMB50wbA6zZ/xCLU63mIdMv/3 HIxWmx1JVINiXfiT5CTiAhUjsMd71M9m1zQdA6Wwv4ZabhHuKiiMeNU+pS0005VLjT6c fA+w== 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=EBp4IaUMtcg4LcF96r3omoQ1vCFNMqCMwdXp05ny3XY=; fh=jWAqq0hGIH/vV+Fnu8VAgTGXWmniroiYKNvjUsnkpNg=; b=s7CzhFPypqYU3bOYw20ZWeg6qzndV5fZNM/VwaP8xjx5NRpNzaALk+guoJG+I9TdJH 4lgPyLZWhsJ/KWn2RWvrFTQ0phzYPsiATS3xF/ozsAWbM5/C0qWL724n7NwFEZJPkwxR su+q94TtqxRo+CyCKUrCNsV9YzcYMgPMo2YZDuaGZli4UQeb9pYYu/VjcQ4p86yhsk9Z Itr0JoHGDsRypXv3DNsjWiRR8hwfCsxBZEJqYTHXxXo2ChTZEI4DqFUOBoMrj2afw93B Fq8gSu8fvCKuHB9TzcNlvauzLyRM1DBgc/mFdekKrZaJs0ZjusqNdPwEtqUwEPPCjGTr OKkA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=J07xfE9H; 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 vladimir.riabchun@virtuozzo.com designates 2a01:111:f403:c201::3 as permitted sender) smtp.mailfrom=vladimir.riabchun@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from AS8PR04CU009.outbound.protection.outlook.com (mail-westeuropeazlp170110003.outbound.protection.outlook.com. [2a01:111:f403:c201::3]) by mx.google.com with ESMTPS id 00721157ae682-897ebc22ac2si6553487b3.160.2026.09.18.08.06.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 08:06:27 -0700 (PDT) Received-SPF: pass (google.com: domain of vladimir.riabchun@virtuozzo.com designates 2a01:111:f403:c201::3 as permitted sender) client-ip=2a01:111:f403:c201::3; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=J07xfE9H; 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 vladimir.riabchun@virtuozzo.com designates 2a01:111:f403:c201::3 as permitted sender) smtp.mailfrom=vladimir.riabchun@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=UqP303P27ei6+/3hzbfPNMnZTwnp603XLoMuRjKQnqL/i/SHUAsztgDOwOyuJNxQgU/JnlZKB+MHO0XbZsCGpMAB3/zG0StF5hjZ8wSlSWeh2u77G31Cf78rZ9ecjMMpKuPxXg0XD6Ekupulyt2aPH2BCCXysps+2tJPfM0q015WPeHCQpTw4UsnukPDa3AvbU4JqZi2kQIHM0C3w/5PJae3PsWxekhoPfh4Ymdftxsd7e+Zpa5x6nXPyHhoKQe9M/0uUvCRpLbfgDaR4I3SBVxVEf/OXzpqgxWmUin5S9fwEb1UhEUMKhUfRc77LNYWByOwf7f2bpJFYPkHKh/SHQ== 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=EBp4IaUMtcg4LcF96r3omoQ1vCFNMqCMwdXp05ny3XY=; b=vyu0knyOnNJWIUBtoBHVtmok6bbTczbn/1dPU+Pyuds6ZclaFkxt44hbHRUHUcmSLkfN+Pz1485P4pqIp7vsaFneIX77TfDtwvWq0klnP3+h3GRhdJxxDzrQ+TtpM6EXKyaJv1D48yfzfA2NfhG3FYT7MpZ93yCOwKy4T/GHf9geDO9ysZwjc5FY6EGeXClyEnG11SOTsphXIhTdINb3qYDvsEknTDeTDveIzWpYyhNOktvfhWGex3TAFe7yLFu861L5NATJml7CTrv++pug02knsvYFITJgdjm0VjKvG11yHeVNzTHWbzYv0z1YxMlkTNfdGB9KFZ1i1JRijKbZEA== 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=EBp4IaUMtcg4LcF96r3omoQ1vCFNMqCMwdXp05ny3XY=; b=J07xfE9H4QW6ijabvcvZ+NEFHBdJa02Zy7Dc7yseajNyc5MjlR7SF5njJowcQcEJECPi2FwOOvc3jyYjaXrlwfjPqvSmt5FzEuAlJHRJjaO7g7Vk+wsB+iVkCaB8Ut0xgykCS5T/K2JEZ2EUvKEKGY7F9kn1i/ilEcWNKqU8wORQqKPsKWQ2i4/5nsfu6pqCDudHh0zYPQDvnxn6clsc0bcueiPtXnR+BS4090NpHuU6BUU59NrRH4cqALpsZrBlXFAA7uGu0A1gvBP6WbnRsrKKotIwlj0fw10C9Mi/jo/mQEChNuCE/xv2k9vCwe4zqpFZde0wg/UeMW+u5P1EJg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virtuozzo.com; Received: from DU0PR08MB8470.eurprd08.prod.outlook.com (2603:10a6:10:406::17) by ZR6PR08MB661270.eurprd08.prod.outlook.com (2603:10a6:910:de::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.5; Fri, 18 Sep 2026 15:06:24 +0000 Received: from DU0PR08MB8470.eurprd08.prod.outlook.com ([fe80::3db0:9d70:4641:5f47]) by DU0PR08MB8470.eurprd08.prod.outlook.com ([fe80::3db0:9d70:4641:5f47%4]) with mapi id 15.21.0428.011; Fri, 18 Sep 2026 15:06:23 +0000 Message-ID: Date: Fri, 18 Sep 2026 17:06:22 +0200 User-Agent: Mozilla Thunderbird To: devel@openvz.org References: <3d74194715f906abca9da70b881731a51025081e.1789491990.git.vladimir.riabchun@virtuozzo.com> Content-Language: en-US From: Vladimir Riabchun In-Reply-To: <3d74194715f906abca9da70b881731a51025081e.1789491990.git.vladimir.riabchun@virtuozzo.com> X-ClientProxiedBy: VI4PEPF00000163.AUTP296.PROD.OUTLOOK.COM (2603:10a6:808:1::872) To DU0PR08MB8470.eurprd08.prod.outlook.com (2603:10a6:10:406::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU0PR08MB8470:EE_|ZR6PR08MB661270:EE_ X-MS-Office365-Filtering-Correlation-Id: 82a1598c-d371-4dac-43b2-08df15966793 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|1800799024|366016|23010399003|376014|10067099003|5023799004|6133799003|3023799007|56012099006|18002099003|22082099003|4143699003; X-Microsoft-Antispam-Message-Info: dXBygvFQr/BNJwBsms3BPxP3kQfNN7hYL04CtO3/987kSBZot6SFiay72XH06YyrDpfjzk/rQXY5Cx0YUdIBinyFu8EkI1dxHZpDVcsqhUut27lFlZ5F9x9VqFUgMbbS7D62EQqvX2bmkQW2LIih5bz3e5t4iVf5TLpLpKcQGHMzsMcxjVJeCt48nJ373Lv97t8dCfFgIH4ZsIJX2lhhj5oWw2Yzcpa1UHNKXzFOm1hTgm5ylgBYhWuZy5qFjcRdMKJNOwYgkD4UCU+37klDPwoGmHzLMLy1k9y5M5pO4wSQuHbHa4Hhtovn3KGu0EJQjcdwZl0EiBYRKcxkMB3oV2h8PhhCwDLPaa2bN1IGSUWekdpwGBlpnk5ISRnZT8+u/5BnRKS+ZzN64zhL5TMtQv7SR7/uTkwgJc8MKu+HSxsQ0P5QQWog6eZjbglwndrd6Z6dRO26BrXyT6GM37IyhcSpRMidztJgp2rDi/70OZ0GB+vXdkaHWwdqYcFKkCYxO4zimKBAXdOZfh6JigOXaSwG3+zaVLEI2k05mHg70endgSfgRQT4+Uyh+gtBj8agFq48f+b/0t/KGeqt32XNMbX7YcPkg6hwkz71dn1Nv9rQlQ7zByxRg5+pHy2T6wyinGF80VYNZIQILJ22LuHrrUji9Ql6eDlW0fqGCuAu8jQ= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0PR08MB8470.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(366016)(23010399003)(376014)(10067099003)(5023799004)(6133799003)(3023799007)(56012099006)(18002099003)(22082099003)(4143699003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M1FMRmNtbmZMWWNCUkdERFp2czZmU3IxWThma2RmbjNheFNFV0s2ei9wTm5j?= =?utf-8?B?dlkxUFA0cEZtNTdpWk1LSWc2cTZ6YkRpaDVZbXk5b0VUU2lveTVtV2k4eHlP?= =?utf-8?B?UnEyMnNHM1E1ZWQ0MTNPdFhsRElJNE1hQ1VITTZkUUtrTHJUYmIvQjFxUFIr?= =?utf-8?B?SUVaYVhDU0VYVldDTUtJbjJQNzA2cjA2ck05Rlo3ajMyQ0k0alpRcm9Ta09U?= =?utf-8?B?eXdtaDAxWlY2eGs2S0sxcjY3aUdPdzFSRWVSb1BUKzVZQ2VBeGh6ZTVlN2lz?= =?utf-8?B?VnFlbTZDbGQwa1pNV2N1dGhBYkJCMEZzU3o2NjVnMkU3U29BNjk4cENFaEIr?= =?utf-8?B?dlBSRTdlNHhMQWgwNHk1bk1DcE1ZR3RvWkl5RWkyV05GR1EyZklaSXFhUWtm?= =?utf-8?B?WkxWNFZ4VjlldVUxKzFHY0MyOFNJcCtteHFvaCthczd0U2tLSkdCd0tpZ2lH?= =?utf-8?B?UE5HK1kxNWF1K29ueEkrcFpPZkVSWnYxd3prdEFHdDRVWktFcW1ua0ZFUnBK?= =?utf-8?B?ZldMVWt6NWtHaTJ2M01kRUhLZytSK0hSVFB5WlU3eDJWbHJGZDBvMmJGTTho?= =?utf-8?B?VTZueGhScWVKakRPSVdvSW9XMmplVHpldkhjbXVrbFBKWG93K1BhZm1mczN1?= =?utf-8?B?S2ttMEJkeUdzaDNkcVNmQmlUUzZPRnFVOTRESnE5YzFPWWtjL1JyQ2FLRVB6?= =?utf-8?B?WExLZFBSWFpMbDdXMWYyU0Z2NjBXcmhnbnFsZ3BNcnppcUxmMjVsY1N5cXpQ?= =?utf-8?B?RThrU0JCTE1NcUN1emhBMzVvNFhWMXJIVHVEcThMdFp0VDdzUlplOG00dkhk?= =?utf-8?B?eG9DeGpMTGJyK1pnWUNKNGZkNnlnanF5YlNtT1R3OHJxL05yOGhwN1BtR2lO?= =?utf-8?B?dmZTWXV2N0NWMjNwMHBydWVoRkdHRWQwdGRVSHNDM3VLN2twS011MVRqNE9B?= =?utf-8?B?QXlheGVUNWVJRCtwcG4yb1hRWTlXajl1T3RYZzJodlhVNkRoQXBBNzZkemNF?= =?utf-8?B?TWFlWXVRUkhSQmJicFE5OVkzZXdwQitXT3VwN1BZUzJ5MmF3Mld1ZUdLcjhz?= =?utf-8?B?a3R4SmIvU2VWUTBsRkZSOEwyMXBkVCt0NDVHdWtvanhEMmVUMUV3QVNnTzEv?= =?utf-8?B?amNXUU1WeEd5S2s0cC9mdUphQjcxLzZHWm1HRllucEdLWGN6cFcvdjFPUkRM?= =?utf-8?B?YnE4NVBubDZnUXlvUFNjTXlzM0Erb2xEeDBYT0JHdVZ3WDV2dG5lVTdXempU?= =?utf-8?B?Wmt2SWZka3Y5bldhN3d4OUViQzVIcVNSeURKeEYwME56QytXRHZHa2NVOCtZ?= =?utf-8?B?RkdNdDB0eEk4VXBTZ0hTTFFwNWRtL29PSkdlclRvYytsN3dwU002dmQ3d3Yr?= =?utf-8?B?UEYveDduU2k1WE9VdlNMalB2VnE2STQrdW5YdVN3Ulg1Y0ZwUTlJdTE0ekky?= =?utf-8?B?NjhpUGJBeWgwUElkS2IyV3BPTnpESXZnQmVoK1oyaEdXMW1QVzlDT3R0clJr?= =?utf-8?B?SkdGT1pjVFNvRUJGdXhlVGRLNTlBNFY5WGNGMWp3R1U4Wjc1NkJJOTVxSjh3?= =?utf-8?B?dkZpQ3d1VXRsN0REWVk0VnY1bldjUWdnWGlkbUZpWE95MjluQzFBclhWdWRo?= =?utf-8?B?enp4bndzUDcxR1NBNW9KRzdTV05LcU5QaEp6cGZRL3FoSXRBSGZLZWxUblVZ?= =?utf-8?B?OTM3ZWRPOWZLRmk5VVZXazlVM1NVbVB6eWI5cjk3cDhWOXB0dGwrbTJuM2t6?= =?utf-8?B?cUhjWGJBY1gvWjE1Zy8rWmpmanhpYVRMeW1SOTRoaENkTk43RVpkTnd2TjNC?= =?utf-8?B?cVhsbHM5cDJwMTVkd3FBZ1Y4U1Q5eHlIOWNxZ0xlWVl5M0hxMmd5V2JLTXJq?= =?utf-8?B?VXZuTEZKZzdjREx5WEplcHRBamZVZTY2R0wvOGlKVm5IR0NlM1VIUnc0MmRs?= =?utf-8?B?Z0s4Z21waUQvZUF1NnJ6YWdKRFN3Q0Uzd0d5NFJsZ2w3RlFWd0EwdGFabmk3?= =?utf-8?B?ZHBLL1NqcW1kQWs3ZVo4M2FtTWRvTWV3UmhZRlF1SVpiRXBvNkZmOUFlMlZI?= =?utf-8?B?c2V1YjVjWXNDZFcxdnh3OXFZUWxaRzE2ejdaL3RzUFVHNXNkN3hHNC9hMkVQ?= =?utf-8?B?ZU1HZC9tNVEyRkVqOXJXN2pib1RXS2VxTTJCQ1hMakZPd05tMHZvNXZlbUQ3?= =?utf-8?B?eStkVHhuTFhVTWZ5RUM1NUlpVDZQUjYrUDJ4Z2Z4Q3NIVGxqVEg5Q3JDUE9x?= =?utf-8?B?RXNTSU01QnYxTlRZeVRHcVd2OWRSbmdaeVZaVnZMZ3MzTGVPb3p2L2JrZFZD?= =?utf-8?B?eXc1bkYyQ2FTdDRwVlp1R3NJVVlPaVlHOTUyc05Jbkp5MnFQRFhPZXV0d0lC?= =?utf-8?Q?gjBWcC9ejHzzmIgI=3D?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82a1598c-d371-4dac-43b2-08df15966793 X-MS-Exchange-CrossTenant-AuthSource: DU0PR08MB8470.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2026 15:06:23.8280 (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: 4gQ7GinR9LyYetUy1pdhGgGKiZugAduIPIVNDraBtsU3M+buuUsRwYPyQmyA376CiN2NZf73SVeuyvgh/oMiZkHiRbkLjG+IPH5q7671zj0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR6PR08MB661270 X-OZ-Fwd: true Subject: Re: [Devel] [PATCH VZ10 v9 8/8] selftests/ve: Add mount accounting selftest 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org Sashiko review: On 9/15/26 19:22, Vladimir Riabchun wrote: > There are 6 test cases, covered in the new test: > 1. Simple mount accouting correctness, just mount/umount. > 2. Verification of correct limit hits and changes, including > negative values. > 3. Partial mounts test, when mount limit is hit in the middle > of creation. > 4. Test that enabled pseudosuper allows overuse. > 5. Test that pseudosuper doesn't affect mount accounting. > 6. Failcount feature verification. > > https://virtuozzo.atlassian.net/browse/VSTOR-135520 > > Feature: per-ve failcounters > Signed-off-by: Vladimir Riabchun > --- > tools/testing/selftests/ve/.gitignore | 1 + > tools/testing/selftests/ve/Makefile | 1 + > .../selftests/ve/ve_mount_accounting_test.c | 550 ++++++++++++++++++ > tools/testing/selftests/ve/ve_selftest.h | 21 + > 4 files changed, 573 insertions(+) > create mode 100644 tools/testing/selftests/ve/ve_mount_accounting_test.c > > diff --git a/tools/testing/selftests/ve/.gitignore b/tools/testing/selftests/ve/.gitignore > index afa4c568c2c9..3df4d05888dc 100644 > --- a/tools/testing/selftests/ve/.gitignore > +++ b/tools/testing/selftests/ve/.gitignore > @@ -1,2 +1,3 @@ > ve_ns_owner_test > ve_perms_test > +ve_mount_accounting_test > diff --git a/tools/testing/selftests/ve/Makefile b/tools/testing/selftests/ve/Makefile > index ec40cbc7b3a1..c6efe7c4b4fb 100644 > --- a/tools/testing/selftests/ve/Makefile > +++ b/tools/testing/selftests/ve/Makefile > @@ -4,5 +4,6 @@ CFLAGS += -g -Wall -O2 > > TEST_GEN_PROGS += ve_ns_owner_test > TEST_GEN_PROGS += ve_perms_test > +TEST_GEN_PROGS += ve_mount_accounting_test > > include ../lib.mk > diff --git a/tools/testing/selftests/ve/ve_mount_accounting_test.c b/tools/testing/selftests/ve/ve_mount_accounting_test.c > new file mode 100644 > index 000000000000..6ba13dcdcc87 > --- /dev/null > +++ b/tools/testing/selftests/ve/ve_mount_accounting_test.c > @@ -0,0 +1,550 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * ve_mount_accounting selftests > + * > + * Tests to check the correctness of mount accounting. > + */ > +#define _GNU_SOURCE > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "../kselftest_harness.h" > +#include "ve_selftest.h" > + > +#define TMP_DIR "/ve-mnt-tmp/" > +#define VE_MOUNTS_MAX 128 > + > +/* > + * These values take a while to calculate, the first test will > + * do this and store the values for those who come after. > + */ > +int *need_avail; > + > +FIXTURE(ve_mnt_acc) > +{ > + int cgv2_fd; > + int ctid; > + struct namespace_ctx ns_ctx; > + int orig_have_mnt; > +}; > + > +/* > + * free_vfsmnt is called via call_rcu, so we need to ensure > + * that all pending call_rcu tasks are finished. > + * However, one barrier is not enough: > + * mntput_no_expire > + * init_task_work(&mnt->mnt_rcu, __cleanup_mnt); > + * task_work_add(task, &mnt->mnt_rcu, TWA_RESUME) > + * OR > + * schedule_delayed_work(&delayed_mntput_work, 1) > + * # Both later call cleanup_mnt > + * cleanup_mnt > + * call_rcu(&mnt->mnt_rcu, delayed_free_vfsmnt); > + * > + * We can't enforce workqueue flush from userspace, so instead > + * read several times until the value is the one we expect. > + */ Sashiko says: This segment of the `wait_on_mnt_avail` function can potentially lead to an infinite wait if the value `mnt_avail_nr` does not match the expected value before timeout. While this isn't a bug introduced by this patch, could we include some mechanism to handle timeouts more gracefully, such as an error code return or retry limit? Something is off here. 1. There was no bug before this patch. 2. Retry and error return mechanism is what this code does. > +static int wait_on_mnt_avail(FIXTURE_DATA(ve_mnt_acc) * self, int expected) > +{ > +#define WAIT_TIMEOUT_NS (4096UL * 1000 * 1000) > + char path_avail[64]; > + int mnt_avail_nr = 0; > + struct timespec delay = { .tv_nsec = 1000000 }; > + > + snprintf(path_avail, sizeof(path_avail), "%d/ve.mnt_avail_nr", self->ctid); > + > + while (delay.tv_nsec <= WAIT_TIMEOUT_NS) { > + if (read_s32_at(self->cgv2_fd, path_avail, &mnt_avail_nr)) { > + fprintf(stderr, "Failed to read from %s\n", path_avail); > + return 1; > + } > + if (mnt_avail_nr == expected) > + return 0; > + > + do_rcu_barrier(); > + if (nanosleep(&delay, NULL)) { > + fprintf(stderr, "nanosleep failed: %s\n", strerror(errno)); > + return 1; > + } > + delay.tv_nsec *= 2; > + } > + fprintf(stderr, "Didn't get expected value at %s\n", path_avail); > + fprintf(stderr, "Expected %d, last read %d\n", expected, mnt_avail_nr); > + return -1; > +} > + > +static int set_pseudosuper(FIXTURE_DATA(ve_mnt_acc) * self, int value) > +{ > + char path[64]; > + > + snprintf(path, sizeof(path), "%d/ve.pseudosuper", self->ctid); > + return write_u64_at(self->cgv2_fd, path, value); > +} > + Sashiko says: In `_create_mount`, can the clean-up logic be more robust to ensure that filesystem resources are consistently freed in the event of an error or unexpected behavior? No more cleanup here is possible. > +static int _create_mount(void *id_ptr) > +{ > + char path[PATH_MAX]; > + int id = *(int *)id_ptr, ret; > + > + snprintf(path, sizeof(path), TMP_DIR "%d", id); > + > + if (mkdir(path, 0755) < 0) { > + fprintf(stderr, "Failed to create directory %s: %s\n", path, strerror(errno)); > + return -1; > + } > + ret = mount("tmpfs", path, "tmpfs", 0, "size=1M"); > + if (!ret) > + return 0; > + fprintf(stderr, "Failed to mount tmpfs to %s: %s\n", path, strerror(errno)); > + > + rmdir(path); > + return -1; > +} > + > +/* Create a mount and wait until mount counter is valid */ > +static int create_mount(FIXTURE_DATA(ve_mnt_acc) * self, int id) > +{ > + int ret, avail_before; > + char path[64]; > + > + snprintf(path, sizeof(path), "%d/ve.mnt_avail_nr", self->ctid); > + > + if (read_s32_at(self->cgv2_fd, path, &avail_before)) { > + fprintf(stderr, "Failed to read mnt_avail_nr in create_mount\n"); > + return 1; > + } > + Sashiko says: Would it be beneficial to include comprehensive error handling in `create_mount` to cover cases when `run_in_ve` fails? No, it wouldn't. Nothing we can do in this case and nothing needs to be handled - no resources created. > + ret = run_in_ve(self->cgv2_fd, self->ctid, &self->ns_ctx, > + CLONE_NEWVE | CLONE_NEWNS, _create_mount, &id); > + > + if (ret) > + wait_on_mnt_avail(self, avail_before); > + else > + ret = wait_on_mnt_avail(self, avail_before - 1); > + return ret; > +} > + Sashiko says: Does the `_destroy_mount` function correctly handle subsequent errors that may occur during the unmount and directory removal stages? Yes, it does. > +static int _destroy_mount(void *id_ptr) > +{ > + char path[PATH_MAX]; > + struct stat st; > + int id = *(int *)id_ptr; > + > + snprintf(path, sizeof(path), TMP_DIR "%d", id); > + > + if (stat(path, &st)) > + return 1; > + if (umount(path)) { > + fprintf(stderr, "failed to umount directory %s: %s\n", path, strerror(errno)); > + return -1; > + } > + if (rmdir(path)) { > + fprintf(stderr, "failed to remove directory %s: %s\n", path, strerror(errno)); > + return -1; > + } > + return 0; > +} > + > ... > + > +int main(int argc, char **argv) > +{ > + need_avail = mmap(NULL, sizeof(int), > + PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0); > + > + if (need_avail == MAP_FAILED) { > + fprintf(stderr, "Failed to mmap shared region: %s\n", strerror(errno)); > + return 1; > + } > + *need_avail = -1; > + > + return test_harness_run(argc, argv); Sashiko says: Does the `main` function properly handle the memory allocated by `mmap`, especially considering that there might not be a corresponding `munmap` to free the memory? Doesn't matter, we can free need_avail only when test_harness_run finishes. It is easier to just exit. > +} > diff --git a/tools/testing/selftests/ve/ve_selftest.h b/tools/testing/selftests/ve/ve_selftest.h > index bf9b89b59a6c..8cc9b3238aaf 100644 > --- a/tools/testing/selftests/ve/ve_selftest.h > +++ b/tools/testing/selftests/ve/ve_selftest.h > @@ -413,4 +413,25 @@ static inline int is_mounted(const char *path) > return errno == EXDEV ? 1 : -1; > } > Sashiko says: Could write operations within `do_rcu_barrier` be improperly assumed to be atomic leading to potential scheduling issues when invoked in contexts that might sleep? No, they couldn't. This is user-space code. > +static inline int do_rcu_barrier(void) > +{ > + int fd; > + > + errno = 0; > + fd = open("/sys/module/rcutree/parameters/do_rcu_barrier", O_WRONLY); > + > + if (fd < 0) { > + fprintf(stderr, "Failed to open do_rcu_barrier: %s\n", strerror(errno)); > + return -1; > + } > + errno = 0; > + if (write(fd, "1", 2) != 2) { > + fprintf(stderr, "Failed to issue rcu_barrier: %s\n", strerror(errno)); > + close(fd); > + return -1; > + } > + close(fd); > + return 0; > +} > + > #endif /* __SELFTESTS_VE_VE_SELFTEST_H */ -- Best regards, Riabchun Vladimir Linux Kernel Developer, Virtuozzo _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel