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 9AB3680726 for ; Wed, 7 Oct 2026 17:48:46 +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 697HlPWQ009924; Wed, 7 Oct 2026 20:47:26 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 697HlPWQ009924 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="FtT9YQBe" Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 697HlMRR009920 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Wed, 7 Oct 2026 20:47:23 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 697HlMRR009920 Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-cc42a07d04aso3007303a12.1 for ; Wed, 07 Oct 2026 10:47:22 -0700 (PDT) X-Gm-Message-State: AFq9FYKiO6RRgCCWMkL2wM/e1uy51waf1rb689Q2v+NZgQbnc6/NI8au ee7PeKeabZRsOdfwbPeApfgYXRRP8mFx0GwzXuzu4ojUEmiHyakv/uIvkLzkzbYuhkH1eFOy6D8 QRiP3m4HgYwdXglY7uTC7ijvsj8JdtjiDz0C1sbjk0FaGcaj/pRSZLg== X-Gm-Gg: AYBFou3EqHR8xvLi+s0MBiRHXsPkXvmgzRGzUETTU8gd8WUQEF9UACHuDTQx/m8c015 jfO/UXgkkDo7PGkuSJD+grv8RW4w87R74p2JXjR4SiX1lhxylr5zjsTzcERhVRNWqxmKX5tZF9q QXDnkCjVGVIqx5jgfb4yklzqUhmQmDVRHakIUlTTKrg09thcc7S015CLlfpMBNIIhCUss/lPZP+ UWncspufDVBb5CQsLrERCysdRBq9vR0ZLYJnxbJcHmGYXOaGVgu5E9sTuk+ev3j6mFXLhMOpU5U FefjUgKPQCwD7uBbhW3g6KDS5HEVlRmNsJv1rXIIzpbc+8/NSCAhlseWd1yJ/667pCNKo33N/7g pnkbllORgdCuNKVcKxlYngnlzLlNovUo4rnygUViZKk8g+MSD1PaV5He5kCI2Uc3+s1dStAvaPj 35Af0ZWpmKUihhgHMHokRj X-Received: by 2002:a17:903:4b46:b0:2dd:c100:80ba with SMTP id d9443c01a7336-2e60059e5f8mr24590735ad.53.1791395241459; Wed, 07 Oct 2026 10:47:21 -0700 (PDT) X-Received: by 2002:a17:903:4b46:b0:2dd:c100:80ba with SMTP id d9443c01a7336-2e60059e5f8mr24590525ad.53.1791395240601; Wed, 07 Oct 2026 10:47:20 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1791395240; cv=pass; d=google.com; s=arc-20260327; b=fY7+VDqyte2UewxVmNCX8Wxpc1/ptOFtxpiX/rk70ILR/wx93BDczVSWFYq68+CUgj Lwkr0IC9qHbzcXOgfkCN9lZjjr8ljJ4NsWScUIEorYp4bLGL2Cky3Krly3ziIGvZGp/V BLmu/3L9S9kIo9wZRsz8q+JmrkRvRCaAjjt73OiR5DDHhN16PreFkeO9udr6jE6o7iiB 43Y2zlu8D+7LBAdYmIEjmPCjDU2tD/SOrLXK41lW1XjFsn2ykI68q6G/ijxz572HBTAJ 5ZY2ya9sK6HTUfkGkdfNBX+EBcRuO1jB2WHUZPW6Dc1UDM6J+CyFJQ1NA11+zes6KIa3 IkMA== 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=hnTHqgvlQWBV9vlPwJ/iKGMo0EYlXca5PGjuAA2KNdw=; fh=Nfzp9ifTzubHI3C1WIlafmQnLkV1xHQKgBls+XHPcbk=; b=AzwPjdNoM4BdAK4MeYHXU1+4Rb8k7ovvIumuUAZgB22lGNG/EYiS3nMrg7zv9zY0hD ifGLSepyu3XXVdmxu/7O2c0o9RnubNE6+sEVkb7WAgFDRHnWwkVw4K0dRER1jB9z2Jf+ QlwAoB4P8r5GwQGR1wRwrnaL8kUB4FGvCksGDXA95JyWKJfyLKWrPQ+G3+nOeiA4GjGS Q/v6YrYunGBb/+JgqJOGSI730ngfEIy/WrU6Q3vahmFOvSIsuq9yTivw138AXnU9ZTvs u7lF7P0jWVFDVA3ndEbnxY5JI4qgaXflFTtiXuHGOXgoGIFyHxzaPemhq8f2nHqw7wSj hEsw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=FtT9YQBe; 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 khorenko@virtuozzo.com designates 2a01:111:f403:c200::5 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from DUZPR83CU001.outbound.protection.outlook.com (mail-northeuropeazlp170120005.outbound.protection.outlook.com. [2a01:111:f403:c200::5]) by mx.google.com with ESMTPS id d9443c01a7336-2e60443e8c5si48005625ad.8.2026.10.07.10.47.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Oct 2026 10:47:20 -0700 (PDT) Received-SPF: pass (google.com: domain of khorenko@virtuozzo.com designates 2a01:111:f403:c200::5 as permitted sender) client-ip=2a01:111:f403:c200::5; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=FtT9YQBe; 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 khorenko@virtuozzo.com designates 2a01:111:f403:c200::5 as permitted sender) smtp.mailfrom=khorenko@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=LnNdcahF+POGcUCvk2P1fbtFQbdjh8jgG5ZCGdyq8ePAF3mi0j/SPgYpg5c5kkUMLfmQa9a2b5TittpawmC483bL+opOcLuy9elSdgBEB37EhFL+05XBee+sgPhqBv/8frcAOTyT9zSgY8JooIe5pfbM/mq6keI/WFJVqccyCwoAaCnVkPG/KXHQDb2HO7gg+esDjHEp+6vO6+nn0u5caaN/lUdmObkToaNBrn9VRDyCXZi4kH420RZk1JVuG5WUwZ54KHwJQLf00Fdl7n80GkmmDSQL5FiYvvoc9FsZNmAgn13Q7vp0eU6p+86bJzU4BkhZ5ka6PQm7NqfC6wNWQQ== 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=hnTHqgvlQWBV9vlPwJ/iKGMo0EYlXca5PGjuAA2KNdw=; b=eZ8gW+dWbtAAJ95DOJy/dBKDeG8iDL8wY83oc+hR/4m7nweGcy3BCepGgK6xMuEFfeYX154JJ7kmCOcZqlGKoWq8prn0gDYO2frFyZZ4CJcaChtDWvz6ziKoorL8ubXxCYbZpZUHhcjgOEmnwuLwvVTp7gpEZHQqjDk7XKi1NH6DCzaiZHnxBYwbEBfQUFTzkI0u9QokhwY+IC84NJkRXXe1w3a4XPPkWYpN9xVY4SF9DdBuy2Ges2FkAgU+q6JKIF9zpN6Yi3Othgym+qMQgMO1DeTak8XDQGyrsZBMr3tB2QQuPBzn1ogRVbyNkZWvK2I/ptJKkjmXGowBlbWc3A== 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=hnTHqgvlQWBV9vlPwJ/iKGMo0EYlXca5PGjuAA2KNdw=; b=FtT9YQBeug9rYmMfUwmc2h4SxckoCabTVj896u/1jWviiZk+7MnH4PpYH1cmBA4uu71WScW5qQY+7tDsKimp88z62fkaNuBecew4ZRH3igJBVhNwe6TzXQ7q4x1KlQShDdmpLZ44IMx3rvJ+CRWpDJL+48qShnBSEKHNs0SPajRsjkFGXnZZCmwYhD9O4OxT4aEXLucbj0JSA6fAoY/dpRT26srAnEaROtxdqMvqIZH2fzW6bfnlXY7dr+MnNt48SDOBr9FILFOnooqLiV4XWhMsNeKgCo5fxica03cizBz6xG4kicJ5RCuOpeKgykZeeaguWWVLda3x6UVSEbYXSA== Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=virtuozzo.com; Received: from PA6PR08MB10708.eurprd08.prod.outlook.com (2603:10a6:102:3c7::20) by AM7PR08MB5318.eurprd08.prod.outlook.com (2603:10a6:20b:104::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.522.6; Wed, 7 Oct 2026 17:47:16 +0000 Received: from PA6PR08MB10708.eurprd08.prod.outlook.com ([fe80::1999:c6db:dc55:494a]) by PA6PR08MB10708.eurprd08.prod.outlook.com ([fe80::1999:c6db:dc55:494a%5]) with mapi id 15.21.0522.002; Wed, 7 Oct 2026 17:47:16 +0000 Message-ID: <59a534bf-3fc0-42ab-ba9b-0a11b09c1c27@virtuozzo.com> Date: Wed, 7 Oct 2026 19:47:14 +0200 User-Agent: Mozilla Thunderbird To: "Eva Kurchatova (Virtuozzo)" References: <20261006221704.2507107-1-eva.kurchatova@virtuozzo.com> <20261006221704.2507107-3-eva.kurchatova@virtuozzo.com> <010701a113529f6f-5fdc0168-31d1-4819-80ce-ccd514ae0344-000000@eu-central-1.amazonses.com> <2710d3de-218c-449e-a7c4-0004e3a60879@virtuozzo.com> Content-Language: en-US, ru, sr From: Konstantin Khorenko In-Reply-To: <2710d3de-218c-449e-a7c4-0004e3a60879@virtuozzo.com> X-ClientProxiedBy: AM8P189CA0026.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:218::31) To PA6PR08MB10708.eurprd08.prod.outlook.com (2603:10a6:102:3c7::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PA6PR08MB10708:EE_|AM7PR08MB5318:EE_ X-MS-Office365-Filtering-Correlation-Id: 4c1f2ddc-3c75-4630-f132-08df249b06a0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|1800799024|366016|376014|23010399003|22082099003|18002099003|56012099006|5023799004|4143699003|10067099003|6133799003; X-Microsoft-Antispam-Message-Info: 4fipw+AwTl169C/GAkQuGPo0jQtd2GKtzib5XWPGD36wF4/AZhCsoqPw5YVAJxWedBn7c1wmak2TvJCIymig+naORyx/315aVLf74HJidaEGYeznZGmJgVMAORCscL5qlko7AebZOlopTNe87zjGV4L43eVT8PTkH5ZLbDtR5xMSVoiH63ZeOCs5l2Bxwwnb8+404/Dg8eHAZA5hsrIRyM+ZgurqDSfbKaz0O2nYgl9y+UU63WlqgoqS+5ewEi75xhJ/8b7FPTKfS8gJ5eN56ptte/jiUu/cVFCsz7tvwJDvBQh3s6+oQ0HQXVVDTyeG9oBtcA+BrXOTBZl9DA0/nHjSNY8acwd6bZGLFrJsLPt2pJb3VoybTz/jdtI2o0+pwIM39BRJl2C/krwfVCwoQ+2abA9By2QEY415QWeH//c9wr5O5A/Tj7nK+qq1a4hZu5spOOosB8g5FaGrYXxGB1Q9gxzyv8vwKmb9twIRiUpMotUEgbPU0DqruASlrgAi67BGoXYP7hDE56YMkYqJ6xs5ykXIDeEt5lJZOqlHYDgwkDEsz0pWWkMZyvqZaMycAYV9ajwgyvhnmZqh1w/jX5c/CROT2KvTmNZpYQwsMbOzRJ2LWizBoQaCxPhoh1lO7VRf0tilqO5owfyoNLAcSdxZXw9DtGnsBnrbk8z6kFQ= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA6PR08MB10708.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(22082099003)(18002099003)(56012099006)(5023799004)(4143699003)(10067099003)(6133799003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SWNSN0Q5T2NrOUNkQnJvUXh2VjhYNFUwelM5QWVnQW5PbXF5cE1BL0RkT1lh?= =?utf-8?B?N1hqQWxVekZHZ1VteWNPUXpiZFBWZllyMU1xbklUZHliUXFYY0c4anRTUUgx?= =?utf-8?B?SmpSRm9yUXBDamZLZWZnZncyWVhhMGNIa0VNUERLWkRIRFpiQnk2bWl4UFJG?= =?utf-8?B?MHFaQk9lRHBWYUlnTWgvVWJtcGYvbitxNkpmVko3ZmVQN3JGNlU1SElDTmJu?= =?utf-8?B?a25lMnBrN0kxK0tnLzJ3Snk4SXp5c3FOc0NEWkY3VnJ0ZDZnZzNuQzlWSUFS?= =?utf-8?B?LzBGWGJjM3NhTk1raDBySE9qeFJvaWZLT1NSWll3bU11d3NSUzl0azNwOWRa?= =?utf-8?B?L3B0SDQ1UW9xb2xkM1hiSExSUmVQTDJ4UG1HREhDNTdiTkRCckhZTS9CWnRL?= =?utf-8?B?UHpmcmc1QkdzcE44RThYQkpsQTFUNFFGR0xXb2xlN3R3ZGhjMjgrWE5kVDF1?= =?utf-8?B?L1F0TG5jK0J6VEhoKzl2STVEdFJQQmlQR29zZkIxWUYxcGNnZS80YWlpNnJt?= =?utf-8?B?WTFwa1h4TS95YWlEOEVnTXliSTgwS2VwYis4RXhIY2FwRCtEQjFtWlFuaDZs?= =?utf-8?B?Y3R6YmRXcEY0VGNRRThLVEV0VUhDN0N6cTBzRGR3dTgxSjZ4ZktYWTM1Qkgw?= =?utf-8?B?bWFiNHk4U1R3KzNnbEFUYlR4Z3RTYnhpaHRRMHZtRW0wR2xFOXNRVnRCcWc2?= =?utf-8?B?WDJHOCtHOTd6V2VJTm05TWFmNVMyZDZaYWxFRTQ2NDM3c01LQlp4V0I1L3E1?= =?utf-8?B?Lzgrd1NiVmdGT0dzeVVXYXFKYldnNnZtNWNlWjNmeGxIYzA0Tm5FRVJYUmxa?= =?utf-8?B?UnBwM2tnS1Z1ZUE0b1FTMmVqTHVnVjZraEpTNjk2WVZQYmx0Zi9RbmFLZUNs?= =?utf-8?B?UWMzLzdubmxyM3BPY0w2N0cvSVZlNDRWU0Faak9IUG9UZlRYRlRnZFlzUWVn?= =?utf-8?B?K2o0YWg5NHNFZGI3YmVvWDBGNFo5MkJ1bzE1Vk9wQkVONzNZQlpkQlIwZ2Q1?= =?utf-8?B?ZzRBZDBsSlQwTnNZRm5BL0tJMVpKSDJPYnJFQ3RBbUpsNjVtY0MrRjhOcXhG?= =?utf-8?B?UjgvQjNNcHFBcmlDejk5Q0NGZnkvaHE3TW9iM0wvTmZTM0xEeVdKeG1JOEZu?= =?utf-8?B?MDIySUpKc0pKOUwzMk85MjFzZCtsWkFiejJDVFlnVHlyUDFrYmdqNzkrbW91?= =?utf-8?B?QVZYZjUyR2FRMnZjalhvZzJtSEFoTStjTyt2ZFViV09HUjRnYnBNMXZUbGdv?= =?utf-8?B?TE5iNkpUbElHSjNDMDRhbXdWaVk5ejhYY1VvZ0MxS3pVMkNOSWNkd3hqVXJV?= =?utf-8?B?M2NlbXBjNTk4c2wwSE9tVGhpSUhjK0hNR2NXcUdZWm1nMHcvTXcwY1VaQVRr?= =?utf-8?B?WTJQdmZDTHRteFVVWUpwU0dxbXNMWXZCOEx2MXFOZ1pSSWJJbll4Z09NWFJ0?= =?utf-8?B?Ym9oS2R3SldNYkRjcnRBRjgyRG5iMklNejBDTEllYkdJV0NRYWMyYTByczBD?= =?utf-8?B?eGJCL0tSMEFxQWlaZjJmWkEwTkJCSnU4RStTS2wyaFZobzBycXI2bVhnSTI5?= =?utf-8?B?T1BLbWVWakcva0VxYUJJTm84NlNSMmVXSEJNbWIyaEVrNm1QeU13bEFVTXFU?= =?utf-8?B?VXZkZFRIOWNUWm5hQ1J3ODA4dU01RVdPS3phdmpqUXgxbXZWQ1NGb3Zmb3k5?= =?utf-8?B?dmdQOG5jS3drT2h3b2dwVmdFSFI4d2ZHSHd1QkMwZEs2UTVwczV6ZlI0TFR3?= =?utf-8?B?eWUxZXhZK1dXVVgzelJoaXRibTRnbEhwdEplZkU2eVJocExYa254aG5EZk93?= =?utf-8?B?cldKMUZSMkdsaDg3ZHlBdFV1QUJlZ2xXZ1orcy9NQkFlbmQwUWRKcE9sVEVE?= =?utf-8?B?K0djSTdJUlVPaHovUGVjMWhkdkp4VjB0Rkc0bzdzeDJlTjA0c1JCUHVKcjdz?= =?utf-8?B?SDdJb0xiS3llMGF2azBiN2hRam9RWklWcU9oQ1RhblpvYTZMRW9NcFZxN3l3?= =?utf-8?B?b3RyeGpyclVwUzV6T01nTG96SGw0VXNocWtWZ3UycHBhYkIvbjE3NTVBR29X?= =?utf-8?B?VGVvTEJLRVU3VzF2ZjR2YmNDSGtIVzVMeHFtdUNqVW9HZE9KT0Zkdi9iM1Fp?= =?utf-8?B?RWFRT1F5ajJDT1h2V2JjOFdmWi9oQ1l1VmtUcWdLZzZ4QlhPVlhFS095UlFs?= =?utf-8?B?TkhSOXZZZ1A3bmdqMWYrOS9taDRwcWU2ZUd3SjJSV01ZRmdybUVQemo3WXB3?= =?utf-8?B?a1A2Z0hPZlRxT3RycDFIK3BIY0lEYVFkYlhCbUVleXdDcTdXY1MrVjc1Sk1L?= =?utf-8?B?eWZRRnZ5dkpWT3VQWS82cFhVRDY3bENMaVY4VTNJV2pmSEN1MDRLUT09?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c1f2ddc-3c75-4630-f132-08df249b06a0 X-MS-Exchange-CrossTenant-AuthSource: PA6PR08MB10708.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2026 17:47:16.2016 (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: kUWxeDZ6TEnF5ppB4Zxu+8TmTczn63C509/71dDlesK8154nysEPs7gQaGoUquTExsAYQ9UFKsRYrSvHA+ycoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5318 X-OZ-Fwd: true Cc: devel@openvz.org Subject: Re: [Devel] [PATCH hci-8.1 v7 2/2] selftests: ve: introduce vtty pair teardown stress test 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 On 10/7/26 00:42, Eva Kurchatova (Virtuozzo) wrote: > > On 10/7/26 01:25, no-reply@sashiko.virtuozzo.com wrote: >> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider: >> - [Medium] selftests/ve: kmsg_check() fails on any unrelated kernel warning or log overrun >> - [Low] selftests/ve: veid_in_use() relies on ENOKEY from an ioctl key marked unused >> - [Low] selftests/ve: 30s default run has little margin under the 45s runner timeout >> -- >> >> commit cfcd5cbc2bcb13ed42052dd5ac26511475fe149f >> Author: Eva Kurchatova >> >> selftests: ve: introduce vtty pair teardown stress test >> >> This adds ve_vtty_stress, a selftest that opens and closes a vtty pair from >> the master end (vzctl ioctl) and the slave end (inside a VE) at the same >> time. It also scans /dev/kmsg for warnings and splats while the test runs. >> >> Link: https://virtuozzo.atlassian.net/browse/VSTOR-144771 >> >>> diff --git a/tools/testing/selftests/ve/Makefile b/tools/testing/selftests/ve/Makefile >>> --- a/tools/testing/selftests/ve/Makefile >>> +++ b/tools/testing/selftests/ve/Makefile >> [ ... ] >> >>> TEST_GEN_PROGS += ve_vtty_stress >> [Severity: Low] >> The ve selftest directory has no settings file, so the kselftest runner's >> default per-test timeout applies. I believe that default is 45 seconds, >> but I have not checked it in this tree. >> >> The test runs for 30 seconds by default. >> >> After that it blocks reading the child's count and then runs destroy_ve(), >> which may retry for about a second. Setup also happens before the run. >> >> Is there enough margin on a slow or loaded host? A timeout kill would be >> reported as a failure that has nothing to do with vtty. >> >> A larger VE_VTTY_SECS or argv[1] value would exceed the default timeout >> unless the runner is configured otherwise. The commit message says the >> default stays "under the timeout of the suite". Could a settings file be >> added to back that up? > > Yes, the test run time is 30 seconds, which gives enough room to shut > down before the 45 second timeout, and I am not sure why would we > need a settings file to extend that. Whenever this test is invoked with > altered duration, it is expected to be ran manually for bisecting > purposes, etc. Timeout: agreed, no settings file. The run is a fixed wall-clock deadline, a slow kernel does not stretch it. >>> diff --git a/tools/testing/selftests/ve/ve_vtty_stress.c b/tools/testing/selftests/ve/ve_vtty_stress.c >>> new file mode 100644 >>> --- /dev/null >>> +++ b/tools/testing/selftests/ve/ve_vtty_stress.c >> [ ... ] >> >>> +/* Any key but the tty one makes ve_configure() look a running VE up */ >>> +static bool veid_in_use(int ctl_fd, unsigned int veid) >>> +{ >>> + struct vzctl_ve_configure c = { >>> + .veid = veid, >>> + .key = VE_CONFIGURE_OS_RELEASE, >>> + }; >>> + >>> + return ioctl(ctl_fd, VZCTL_VE_CONFIGURE, &c) < 0 && errno == ENOKEY; >>> +} >> [Severity: Low] >> VE_CONFIGURE_OS_RELEASE is defined as "2 /* unused */" in >> include/uapi/linux/vzcalluser.h. In kernel/ve/vecalls.c, ve_configure() >> behaves like this: >> >> if (key == VE_CONFIGURE_OPEN_TTY) >> return vtty_open_master(veid, val); >> >> ve = get_ve_by_id(veid); >> if (!ve) >> return -EINVAL; >> >> put_ve(ve); >> return err; /* err is -ENOKEY */ >> >> So veid_in_use() treats ENOKEY as "a running VE holds this veid". Is it >> safe to depend on the return code of a key that is documented as unused? >> >> If that key is later rejected earlier, for example with -ENOTTY or -EINVAL, >> veid_in_use() will always return false. The only guard against taking over >> a running container's vtty pair would then disappear without any notice. >> >> Also, a VE that has ve.veid set but is not started is not in ve_idr, so the >> probe cannot see it. The commit message only mentions "one started later" >> as the case that is not seen. >> >> [ ... ] > > I would like to hear Konstantin Khorenko opinion, as I am not sure about > this ioctl() API stability or why it would be marked as unused. Either this patch > un-obsoletes that call, or a dedicated ioctl() for checking VEID state should be > implemented. No ioctl, old or new. Just do not check at all. name="vtty-$(uuidgen)" prlctl create "$name" --vmtype ct --ostemplate almalinux-10-x86_64 prlctl start "$name" This is how a container gets a unique id in real life. Take a random veid in the test the same way and drop the probe. > >>> +static int kmsg_check(int fd) >>> +{ >>> + /* How a warning, a splat or a sanitizer report starts in a record */ >>> + static const char *const reports[] = { >>> + "WARNING: ", "Oops", ";BUG", "kernel BUG at", "UBSAN: ", >>> + "soft lockup - ", "general protection fault", "INFO: task ", >>> + "rcu: INFO: ", >>> + }; >> [ ... ] >> >>> + for (;;) { >>> + r = read(fd, buf, sizeof(buf) - 1); >>> + if (r < 0) { >>> + /* The ring wrapped since the last read, records are gone */ >>> + if (errno == EPIPE) { >>> + ksft_print_msg("kernel log overrun, records lost\n"); >>> + found++; >>> + continue; >>> + } >> [ ... ] >> >>> + for (i = 0; i < ARRAY_SIZE(reports); i++) { >>> + if (!strstr(buf, reports[i])) >>> + continue; >>> + ksft_print_msg("kernel log: %s", buf); >>> + found++; >>> + break; >>> + } >>> + } >>> + return found; >>> +} >> [Severity: Medium] >> Only the "vtty" checks in kmsg_check() are tied to vtty. The reports[] >> patterns are matched with strstr() anywhere in a record. kmsg_open() seeks >> to the end of /dev/kmsg, so every record from any subsystem is read for the >> whole run. >> >> Can a warning or hung-task report from an unrelated subsystem, or from a >> test running at the same time on a shared CI host, fail this test even when >> the vtty code is correct? >> >> The EPIPE branch counts a ring overrun as a complaint. If other log traffic >> overruns the ring, does the verdict then depend on host log volume instead >> of on vtty behaviour? >> >> The log is drained only about once per second from the master loop. The >> final message "kernel complained %d time(s)" does not say that the cause >> may be unrelated to vtty. >> >> The commit message accepts the overrun rule deliberately. Could the >> matching be narrowed, or the failure message made to say that the report >> may be unrelated? > > The test intentionally considers any symptom of a buggy kernel a problem, > since memory corruption in the original issue can surface in various ways. > Sure, this can report a failure due to some unrelated kernel bug, but that > would be still a kernel bug that will be investigated and fixed. An overrun > of the kernel kmsg ring during 1-second interval is an enormous amount > of messages that can't appear under normal circumstances. kmsg part is fine, leave it. _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel