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 4E4038045D for ; Wed, 21 Oct 2026 16:49:34 +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 69LGmHEV022828; Wed, 21 Oct 2026 19:48:18 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69LGmHEV022828 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="DRvNkQjK" Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 69LGmF0U022824 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Wed, 21 Oct 2026 19:48:15 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69LGmF0U022824 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-c3f8e149ccfso89616866b.3 for ; Wed, 21 Oct 2026 09:48:15 -0700 (PDT) X-Gm-Message-State: AFq9FYLFJtiLDt6iO59Dr7aAGCcFat0UxkSe0B1uXDwb4lo+vBw6WerH xxkhRqxvJ6HGdjU6/Z306KrSoAe+vDoEA0PB+9899nO1WM6UkaPLiAnLx19z4qdzGH3rlQ3i46t yYB6v8Q5S+OcfFZyEoq0VFsNlfNnqgmvIgp782xeQABuYy0i+3nh7Uw== X-Gm-Gg: AYBFou1EfG1rTRZ4VNc3CUZogGo2FEh5SYs7HHy8mQus3FtGqz9YVI3hJEsFzqfFo01 NXXuPrX880T2Jren6n/I38shVbMJfAp9ZTM/EuCu8iQERyRg8kjRup/tFcCP9eZiPpzvJv1oUzb ZkQbpyWNZYZ6qmOcpC5MMzPfHL18lzLva0RJihbnkIyNlVAc8O3mTDcSJuwqBbDqjPsWzi+Rxem WF6Iv+Z0PTMeyKbzGBXqM8UyiokzB5qVRzknBvm+OHrYN4njZW0v22sz1nokhYfNGb7PsdXZIDK pG/Zt9907c7DjBFKBJzAvRjjJ3BvAP3MLmc8wqDtFQ7zm0OrAQW08x0/5eGJ6C9+5hIAGBEhNIr +mdl5sQeGJ2NwWN/ygXulgdvJXC/CGvGKU1lIt0lF9pz1FQraa55vigZX1Z+N8u93B0131nT5IM eAhvvmKLYpqi8+mvxlu3WK X-Received: by 2002:a17:907:9608:b0:c2d:bf61:24d1 with SMTP id a640c23a62f3a-c4679102581mr222100466b.1.1792601295498; Wed, 21 Oct 2026 09:48:15 -0700 (PDT) X-Received: by 2002:a17:907:9608:b0:c2d:bf61:24d1 with SMTP id a640c23a62f3a-c4679102581mr222098466b.1.1792601294943; Wed, 21 Oct 2026 09:48:14 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1792601294; cv=pass; d=google.com; s=arc-20260327; b=UFj7EjNbZtpEy0tt0tJ/e5zUKwraKMr8KHcQbIRezDq2Y2Det2X7ohUKTzWwjln7U3 tEN00IgLvhITvB2NYrxzCWwNJBq620qIbftfbaAN7W95ZR8wuhnTEobyXip+RT2T3NC2 AHRhp3Kur6p2yhobW0mo13yMTg8p1GyiuiYZ1Mnv01cQOaZDJKeMF5T7AsV7/l3tY0Nv S81VA45kw++pR8Ps3Tc/pq03KnUgBnyNdks++D/gNuAfYkdGTTd35pQ3wgD98kONXgza NUqS1Mzxq0dFbqxewJfRmMW/koRe6BV0SUwU/hFxFT547DK5OPZY1n1aky+eZ6uFXbOc 57dA== 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=vFvLijhvPyPQeYd6PgpzG2AEfNocMu7OjjLR0PvGG7Q=; fh=K9SIPyNdrhRjA5u4NfE4s8lOioHVbPJAIPkx8BkksJM=; b=RscuYNcypCUnCeTBkLwVtl4lU2fNRyoH+YTLtfYzjfEiLlIbnPVoC4XUivs+XCzTQE OdaCvOKdXcLaEyBVPq71q6yCsJVYAuZ48/W0kL9fdqou3OWrWj8lYIctq+0PaYsqAa2m 6qCQT5PeeKLYk5spnxDudtzSLvj1IXrL1zPZoT3Nbc62jXIgnsGZtsSj3ljDhJ4u/BBr qwAX7EBjjbSVdk4Evz6x3vlI7q3Z4Om0whR67dsYWQa+nzQCpzJIvWsLOfMJJuWd1n3z 6JBHX0OQh0n0n0I4xD/UHezOvvKM0Fj5Dl5peipe1age8B0Tv38MjwC3ymAqW/aQP9zz pc/w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=DRvNkQjK; 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:c201::6 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazlp170130006.outbound.protection.outlook.com. [2a01:111:f403:c201::6]) by mx.google.com with ESMTPS id a640c23a62f3a-c468a6c48bfsi39709066b.246.2026.10.21.09.48.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 09:48:14 -0700 (PDT) Received-SPF: pass (google.com: domain of khorenko@virtuozzo.com designates 2a01:111:f403:c201::6 as permitted sender) client-ip=2a01:111:f403:c201::6; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=DRvNkQjK; 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:c201::6 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=NpfPLgMwngs3aI6Yz3JoO7j6kPXDaXa2FJgMXDmVwoJ5dU6YA+Nt8B5mnBRxTDD8HuyHKIoGNqRRqOy0V2xn9+NwfpZkw5S3GNuQUMcV8Kf4/+LIivFGQ+voaf4HbYVLSaVLBAVSpIP3Aod/TVLYN5tprwUnfze1GRFGo/paCs4FdNdXKmsIfntxpFoKSfwnEUsYA3vWed182GfdGM5nF+EEgEJD3i2HwGIIyJz0EhKG51QQs8BptX9RmveFEXf/5V2+/H5yZ3U3DF3dmjm08B9p8JzrjQeVgZExObqHE6MYMft4KxffGiiiQZptaqMRRe6ZiPsMJsUmrvpMfqM+iw== 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=vFvLijhvPyPQeYd6PgpzG2AEfNocMu7OjjLR0PvGG7Q=; b=K/9yzA07xVk0drei8m9PT9IoxGPuscHGgGFjWfJg8t08KFQs5+sBpp+NwMFS5wk17Ughr4iwvHlWuSEUKcJMQLdthJQY8t3c3aZOXyjBgRXzV2/0LBqZbTUyljjFWyaqI8J9G1tL9ssW2vQVXPpHoRDKzVlUcpXnOzDeUZX/gQ96jadk5Qd/xU3txNIEsN/Nalz07uspv6DtPan/8MjF7ss3RND2aSmDoAa4teMIfZcz3Wq3JNnd38PfpRYUPHC4xi0qRWV8QZ5IqPFc6U5UzkGlWnCAS+4wKd7W3LJwgRmtQIRgzWNxuEdYIbkjwTKPRysMawyBCsoHIbBGfL3/8w== 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=vFvLijhvPyPQeYd6PgpzG2AEfNocMu7OjjLR0PvGG7Q=; b=DRvNkQjKoDHMq1l9Qmh8QjIYbLgULYM1ugI+vd//lln8bFCzQ7U9n6tR9Ji7+GDXcaRLuyvvEGom48pWOINhZcgR8kBJ4E66MK/O51yawmLgSbFHEaP528AejJmT/CFGQEecze/T5XsBQP7p3cg3L7ur1S4syr+pgQdBX9/3MJVElhpg9wDWqkUAPsa17pbboRvvNnZeeScgTvDLC24YZrXXRyDGHRGBGsOXdSC6Vgp6hnPDMOutmqMXew0cwfE0Y4z8TkWrZBmeZJdltuy+S2atE8QI3iipgFCJppUSOdUxdfAu8Wb3TM7n/1dpzXtKsx8fMl3DXg6nLjFDNllWpQ== 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 PAVPR08MB9604.eurprd08.prod.outlook.com (2603:10a6:102:31b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.546.15; Wed, 21 Oct 2026 16:48:13 +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.0546.012; Wed, 21 Oct 2026 16:48:13 +0000 Message-ID: <355cb709-43ca-4855-be06-dff6e6ca8641@virtuozzo.com> Date: Wed, 21 Oct 2026 18:48:10 +0200 User-Agent: Mozilla Thunderbird To: Pavel Tikhomirov , Andrey Drobyshev , Vasileios Almpanis References: <20261014-b4-prep-khorenko-vstor-149847-2-doexec-pinned-memory-v1-0-36f1120f9b57@virtuozzo.com> <20261014-b4-prep-khorenko-vstor-149847-2-doexec-pinned-memory-v1-8-36f1120f9b57@virtuozzo.com> <010701a13b7a1414-cc670e39-401a-4e02-9898-a6f0dd19a8ee-000000@eu-central-1.amazonses.com> Content-Language: en-US, ru, sr From: Konstantin Khorenko In-Reply-To: <010701a13b7a1414-cc670e39-401a-4e02-9898-a6f0dd19a8ee-000000@eu-central-1.amazonses.com> X-ClientProxiedBy: FR4P281CA0197.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:e5::7) To PA6PR08MB10708.eurprd08.prod.outlook.com (2603:10a6:102:3c7::20) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PA6PR08MB10708:EE_|PAVPR08MB9604:EE_ X-MS-Office365-Filtering-Correlation-Id: 7afd5c02-ced2-4419-5ce9-08df2f9318a4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|1800799024|376014|366016|23010399003|56012099006|4143699003|261009223027099003|10067099003|18002099003|6133799003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: G05izfdwIW5Wgr8bio6g68pCIyh9l7wo8tgOGnogyQZwTfhBMpSfNysY/KLHzJn51SBR4VALstil8TLQ7Cj3YoHofuVnZWglgKFTuzBLtmA7A7d6y9nu7qIP32MiMKSOLxoyuUsarc2tXoX0H51m6QlriBNEybT/O99tmF+YUkG31kY6lKOLYlFjWXXyf8EQAbmfEm+Afz2i4WSO8ZT/Ew7mkgNMVa0BFAcOZ8+80VcSD4HOebYHwiiQTFMq8kpt82g2h+2zCnCXoIXrqQc+yEi6zhjRC70svIq0LSw0CUkn9NfrRRB7wmXbMc5jnwg1G5FnOx4f2OdF09H63LXMuRGLCKwLIAIVg8QuqnG4UWRLkJ9gZejeo8BNs015haMD0P1XZfnn2LXaczhCtLlFCvY22sHwzgCINs6h/1lTTNt7rIfsDWYFsFcn6tVue18r00PP/pYyNfMdFRmFH565yPbJT52wdcvM1p7VjgMq4W6+9tk9OabXojCAgoQDgcCYdTQPbFD794kHjQPdH1qQFDLXTsHuZtKil2v5dl1yPwREo+VlraeCX5hJGqHuunwEjHMwvhJ5Phyr6kcZOK+m0OcaGLT80iNO2+sP1dzU6N89I5ehJGzYGBWdSks42KKY 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)(376014)(366016)(23010399003)(56012099006)(4143699003)(261009223027099003)(10067099003)(18002099003)(6133799003)(22082099003)(3023799007); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NDRJVFlLQkFvYVFQVTRBM25jS1JxcTUvL010K1B6L0c0Sm95MHRGZmpTRjZJ?= =?utf-8?B?Rlh3T2VBUk96K25UREVrQVZYbFhaait1bENRYVVWbU5rbCs2QUVlVmJZVjd3?= =?utf-8?B?aHZ6UytaY2x3T210UEh3a1JjdElCZTQ4UW1Jd3ppcjVDYTU1ck1HVUJrQ0lu?= =?utf-8?B?Yjh5dzMyeEpoN3dRMW55VDJPWElWR09rMXdGTTRZYUtkOTdMY1lHQjA0RjFj?= =?utf-8?B?K3J6ei95VEVvWDFEQ3FXNk5MVGUxRzlQdVN5bHlXYS9vbG5KMnQzakdjYWdw?= =?utf-8?B?NUlBRi9kajRqcXBHMEs5M1U0WWxJVnlWUEEzSW1VMWlkNkZ4YmFxRzZia1du?= =?utf-8?B?THkwQTFZNEpkWitjOW1XUzJVUERGc1lnbHFYZ3BqOTdNank1ekx5eTd0OGVB?= =?utf-8?B?aHpZaDMrM09FRjBxa2t5MkVQL09lWUtxV1NzcVpWcjFRODIxTUFxSzYxN1Rq?= =?utf-8?B?NGxFZFluRmludFREVkdwNHNydzkvTGhiZU84US80aUdZRGx6WEpnNEEvMmtz?= =?utf-8?B?cVZNUm81VWR3blZ1aHRsR096YXhEaXNiZGI2REVLYU1xNkVyN09XY1ZxdVlW?= =?utf-8?B?cFZrUzFQVFErc2ZtNEJPdlFKb29QYUpIcDBRQXVqMkVHc0ZhcjFEcm1MQjBB?= =?utf-8?B?dm5SNmcrQ1JhYjdPNWlDYXZDTUxJaXpSLzN4UkdUN0VlYjBBREgxNysyRFUv?= =?utf-8?B?ZC9Fc0pBWHkybWc1cVdONmp3cml6Z05wWktselNZT0g1YW04VzIzbnlkRDI1?= =?utf-8?B?cHl0UXNpK3Y0bDYva1JYU0VNWWpocDJTLzVoQURIRElRNDlmZXRYTHdXTUlh?= =?utf-8?B?ZVJXck9CcFJ5clZBS2RERGEyRDZKRlVBZnhoamNFelMyZHloOEVIZC85eG5N?= =?utf-8?B?alBsOUJOY0wwTlZUUTBHL2FmeUN5REZPQXpGRGV5YlJ0RVAxWFNEa2JhdEI0?= =?utf-8?B?SXZlNm4wbThMYWRmRHJiaVd2ckVjNEVySXNiZVJ4bURHTHNnVmUxTTVhQ1d5?= =?utf-8?B?MUdhM3BnUjc1UXFuNHpwZEhDSE9HOTNqZkwzbzRwVFJVa1o1UzduaWJTWlBN?= =?utf-8?B?ZE8rT3dzdzVwV3A0NWhqbTJEQlU1cS9ucHd3U2tIaDRNK0VJc2xLZllGOEZZ?= =?utf-8?B?M0djZytBSnJJZWpDeHd3WTljYnNzWkhsYmFEbGpVYVhvMlRZekdJcGtSVEJO?= =?utf-8?B?VXUxMFlsYXVlMG5TamlmZlRnb0ZCSFpOeFFBQlYveTZwNmhOWUNueUdKVTha?= =?utf-8?B?ek5BUDhYWkV5STNYZnF1UGcvOXo4ZURVajVKRSszYi9tQjlsSGtKNGRwcVp2?= =?utf-8?B?MmIrZUFsT3pZTktLZUhDeVBSY0dYVG9jenpDWUhLZEFFTlhndkU3WlB3bGRK?= =?utf-8?B?cnAvaXpjRENnL3FNQXpiM21XOTZZZ3FJK0ptbjZwTGw1Zm4xUFNCdTZmdllU?= =?utf-8?B?SnpPTW1iMnpaTW5tRmQzVHlmNTE4Vks0TUh0TEcyZGhUUDhZaEduZkJvRnBZ?= =?utf-8?B?K0lIem00V3RwUXpaR3NGSEVWUklXRGFrUEVtV0xVRkVEd3hLSkMwYSsrWFFt?= =?utf-8?B?RDUwai9LY0IrV2taOWpjNnhSZUYzMm90K1krOTQvektBYkgzMWRiQXRCblZX?= =?utf-8?B?aW9JVkF4cDhzWWFwbHpWNysyWER6T3AzZjJxNEI5d0plQWhrVHp2NFU4ZGkv?= =?utf-8?B?UFdrRFVOTDBGMmZIZmMvUEVGSnBXUk01bFJlVCtqWWJvTmJ2NElqOEhOdWQy?= =?utf-8?B?Z3NXekRSN2haNEtMLzJlOVh1SlZVWGdxRHVFREtJNlg3aFRvV2xnZ1VRL0pO?= =?utf-8?B?WXI2cGZwS2lQNnZHMU42RG9scUx5Y203SlVFa3o4aE0vc24zaFlrbThYMHBO?= =?utf-8?B?SWNhS3BLQitJWWI0eGhwRDZ6K0wvQXgwQ0lwN1o1RExya1owbVJKL1BqMnc3?= =?utf-8?B?VTZRdUd2cUhmaTM5NmNqeExaT0grS0xmUmNyc3N0b1JrdmpoUFdQc1V2dmJi?= =?utf-8?B?TnNnWmlwYTJIV1BnQzdBQUlMTUt6RXdWa1lpVm1JekFwaHB6NVh2Rnk2dTNi?= =?utf-8?B?RVh0Z3dCSDFIN3ZyOEJOQWtwcUZ0SVJ4aEtiV3ZmRmcvaENDZ1NheFFyb2NJ?= =?utf-8?B?QittMU9TTTJmUUlQOFlCY0FFWHZ0WnV6Vk1lQkoxNTUrcHc5bGFGcXpCNzR1?= =?utf-8?B?dTNoNUpsQ0NvcE53SVQyVi9DMW16eXYwUU42MEhXY3YyNFB0SWxkeHA4OFpz?= =?utf-8?B?RW42UURWZENmWGM5VkI4MGl2MmRmbFp0REQxd2krQXB2KzU2a1hwNzZiNE4y?= =?utf-8?B?RzVPc1B5Yi9mQ1V2TzNwMTN6aGFrT2lJQjI5MzgzN0V1NjF5M0h6QT09?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7afd5c02-ced2-4419-5ce9-08df2f9318a4 X-MS-Exchange-CrossTenant-AuthSource: PA6PR08MB10708.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2026 16:48:13.4701 (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: yvqeKkk25ULLYLZRqkcUW51inRIv1BrI9PTLirPBtTHlfaP5eryeHIbahHOabCgprzC9sUUB082X+BnD0kPdeQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9604 X-OZ-Fwd: true Cc: devel@openvz.org Subject: Re: [Devel] [PATCH hci-8.1 8/8] selftests/mm: test memory preservation across exec 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/14/26 19:33, no-reply@sashiko.virtuozzo.com wrote: > Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider: > - [Low] selftests/mm: doexec child diagnostics are lost by _exit()/exec > - [Low] selftests/mm: doexec ignores write() return values > - [Low] selftests/mm: doexec treats any SIGSEGV in allocation sweep as expected > -- > > commit eee32e73516b760bb3007e1b97633a4999581fec > Author: Andrey Drobyshev > > selftests/mm: test memory preservation across exec > > This commit adds doexec, a selftest for MADV_DOEXEC. It checks that memory > backing long-term GUP pins and other mappings survives repeated exec and > fork. It also covers CLONE_VM handling, threads, /proc readers and an > optional allocation-failure sweep. The test is wired into run_vmtests.sh. > > Link: https://virtuozzo.atlassian.net/browse/VSTOR-150231 > >> diff --git a/tools/testing/selftests/mm/doexec.c b/tools/testing/selftests/mm/doexec.c >> new file mode 100644 >> --- /dev/null >> +++ b/tools/testing/selftests/mm/doexec.c > > [ ... ] > >> +static void exec_stage(int fd, char *ram, size_t size, int kind, int stage) >> +{ >> + char fd_arg[32], addr_arg[32], size_arg[32], kind_arg[32], stage_arg[32]; >> + >> [ ... ] >> + execl("/proc/self/exe", "doexec", "--exec", fd_arg, addr_arg, size_arg, >> + kind_arg, stage_arg, NULL); >> + ksft_print_msg("exec: %s\n", strerror(errno)); >> + _exit(KSFT_FAIL); >> +} > > [Severity: Low] > Can the diagnostics printed by the forked children get lost here? They could. In "selftests/mm: broader MADV_DOEXEC coverage", fail() and fail_errno() flush stdout, the failing paths go through them, and the per-case children leave with exit() rather than _exit(). The one ksft_print_msg() still followed by _exit(), in the allocation failure sweep, gets an fflush() in v2 of that series. > > ksft_print_msg() writes through buffered stdio. When stdout is a pipe or a > file, as under run_vmtests.sh or a CI harness, the "exec: ..." message is > still in the buffer when _exit(KSFT_FAIL) runs, and _exit() does not flush > it. > > The same applies to the other messages printed from the per-test children, > for example: > > before_exec() -> "pin: ...", "MADV_DOEXEC: ..." > check_pin() -> "read pin: ...", "CPU/pin mismatch at byte N" > allocation_failures() -> "fail-nth N: ..." > > In main(), the fflush(stdout) calls run in the parent before fork(). They > prevent duplicated output but do not flush what the child prints itself. > Messages printed before the execl() into the --exec stage are likewise > discarded by the exec. > > A failing run would then show only a bare "not ok" line. Would an > fflush(stdout) before each _exit() and execl() in the children be > appropriate? > >> +static int shared_mm_exec(bool own_thread) >> +{ > > [ ... ] > >> + if (own_thread) { >> + if (pthread_create(&thread, NULL, blocked_thread, &pipe_fd[0])) >> + return KSFT_FAIL; >> + check_exec(ram, size, 1, false); >> + write(pipe_fd[1], "x", 1); >> + pthread_join(thread, NULL); >> + return KSFT_FAIL; >> + } > > [ ... ] > >> + write(pipe_fd[1], "x", 1); >> + if (wait_child(pid)) >> + ret = KSFT_FAIL; > > [Severity: Low] > Is it intended that the write() results are ignored here? > > write() is warn_unused_result under glibc _FORTIFY_SOURCE, so this can > produce -Wunused-result warnings. > > If this write ever failed, the CLONE_VM child or thread would stay blocked > in read(), and wait_child() or pthread_join() would hang because the test > has no timeout. > >> +static int clone_race_child(void *arg) >> +{ >> + struct clone_race *race = arg; >> + unsigned int i; >> + >> + for (i = 0; i < 8; i++) { >> + if (__atomic_load_n(race->ram, __ATOMIC_RELAXED) != 0x31) { >> + write(race->report, "x", 1); >> + return KSFT_FAIL; >> + } >> + usleep(1000); >> + } >> + return KSFT_PASS; >> +} > > [Severity: Low] > Should the result of this write() be checked as well? No. v2 of the same series checks them: - a failed wake-up write fails the case and kills the blocked child; - a clone race failure that cannot be written to the report pipe aborts the process, so the supervisor sees a signal instead of a pass; - the writes that disarm fail-nth are checked as well. > > This write is the only signal that the shared memory was stolen. If it fails, > clone_exec_race() sees EOF on the report pipe and passes despite the detected > failure. clone_race_thread() and the --check handler in main() also drop > write() results. > >> + if (argc == 5 && !strcmp(argv[1], "--check")) { >> + char *ram = (char *)(uintptr_t)strtoull(argv[2], NULL, 10); >> + size_t size = strtoull(argv[3], NULL, 10); >> + size_t stride = strtoull(argv[4], NULL, 10), i; >> + int fd = open("/proc/self/fail-nth", O_WRONLY); >> + >> + if (fd >= 0) { >> + write(fd, "0", 1); >> + close(fd); >> + } >> + for (i = 0; i < size; i += stride) >> + if (ram[i] != 0x31) >> + return KSFT_FAIL; >> + return KSFT_PASS; >> + } > > [ ... ] > >> + if (WIFSIGNALED(status) && WTERMSIG(status) == SIGSEGV) >> + fatal++; > > [ ... ] > >> + /* A sweep that injected no recoverable/fatal errors provides no coverage. */ >> + return early && fatal ? KSFT_PASS : KSFT_SKIP; >> +} > > [Severity: Low] > Can the allocation_failures() sweep pass even when the preserved mapping has > been lost? Not with "selftests/mm: broader MADV_DOEXEC coverage" applied: the --check image probes the range with msync() before reading it and exits with "range not preserved", which the sweep reports as an unexpected status. > > do_execveat_common() deliberately raises SIGSEGV when exec fails after the > point of no return: > > if (bprm->point_of_no_return && !fatal_signal_pending(current)) > force_fatal_sig(SIGSEGV); > > So SIGSEGV is a legitimate outcome of the sweep. However, the test cannot > tell that kernel-forced SIGSEGV apart from a user-space fault. > > After a successful preserving exec, the --check image dereferences ram[i] > in main(). If a kernel bug dropped or unmapped the preserved range, that load > would also raise SIGSEGV. allocation_failures() would count it as fatal++. > > The final check is "early && fatal ? KSFT_PASS : KSFT_SKIP", and it requires > at least one SIGSEGV. A regression that loses the mapping can therefore help > the test pass. > > Is there a way to distinguish the two cases? One option is to have the --check > image report a lost mapping without faulting, for example by probing the range > with mincore() or msync() before reading it. > _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel