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 7E26480024 for ; Wed, 26 Aug 2026 11:14:04 +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 67QBClt6007139; Wed, 26 Aug 2026 14:12:48 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 67QBClt6007139 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="kZEQdfoz" Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 67QBCj9u007135 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Wed, 26 Aug 2026 14:12:46 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 67QBCj9u007135 Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-84a251c2e3eso2047117b3a.1 for ; Wed, 26 Aug 2026 04:12:46 -0700 (PDT) X-Gm-Message-State: AFuF++mElIO8kYoP7bZ4fhvNPyO4veR706EpM7YfWEDMkk8+Re9g/Hfu t6LM4VP76g2xw6HPBfBT+3TyP+VHe97qlmN1toCLO6eqjjHfeTwleBlhveKNi3DThptoEPY0vLd xmIEdu6XNPp1K9NLprsCI8rUoW3pTz1ngZOWBDHXQvhAhvqu8k1E9kw== X-Gm-Gg: AR+sD11XT9L0ipreOQfTn4O0ZzQAos7eSDK7fpVEs2XGoPFiY8Srzk3vn++hw0LbeU1 NqGYEVsrJTRl86YwgOCmvW9yB8GyD3SNVRdAdiza61OZkIBBSwzjTpFljVrJTF2t121+V8hLcG7 xTujn12k+WChN5JMvNYXjznLbYHkLDrJrQy0SmArFtxj5spJ3qvs6ZmaRBiCLy7F5z1VM86v5/V BFdR/xn4jUzqvOHnkfN50od2WoD8O4yfvEeb9JkWPoeSLsRF2J5GWWvGmKd5inikqzY56DMzTJ/ X67RJxWLIDw/lY1NgO07sCMIYYBezCHLGtZLJ8ezwFACv6W8qChGQ3QeB4DDR8TPg1JSxSehLYS ibQGm8lkt5VbHnrOvBrAw+ysVPbrEpHea/58IpRGzQOWqHGSt2Me4H3kb771s5WhzcOZros5+KM zgHzTdeEefVL7HOOhHP551QJyC4A== X-Received: by 2002:a05:6a21:4887:b0:3b3:a66e:3911 with SMTP id adf61e73a8af0-3cd8f2f5c7fmr15877011637.19.1787742765208; Wed, 26 Aug 2026 04:12:45 -0700 (PDT) X-Received: by 2002:a05:6a21:4887:b0:3b3:a66e:3911 with SMTP id adf61e73a8af0-3cd8f2f5c7fmr15876926637.19.1787742764507; Wed, 26 Aug 2026 04:12:44 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1787742764; cv=pass; d=google.com; s=arc-20260327; b=INKNxTjRMEt1mbLNQirqqKSyROYSR6J4e9vD6mk+qOWiePVK9bB4P9hZ0gEwnUivwB SfntArrwz5w2xG+nsDoD6/azu7wUfKZb7Dqa+HhyX/hfmRjuIDZqXBwglVMxxFSHobVj vJnYfmrM14N6xm92IGPeG1SMx5BqGMpEtN7JSfqefKN7TwILuxL70dpAqfHlH7BMDRBR Gq5zWF35tzvC/Mt1YOoarwZ3lGLkhSQzLKhcDACwu2gOtnZVlfcwdVA+5QS5EKU2fQy2 lSdnx/uMxM0vA9wLQ19fE0z+ODYoDMEMGl8lrKPKLkY+uqnNltMGIGEArQC3K2HkH/kw JLqQ== 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=0VSU6o51Jbt78Svim3DZW5IgGowHm6r/TZQbtgZdQ3M=; fh=KF8Hvp+G89lxML9jsXnqek77Z1Lqag7VwmkgrwD04GU=; b=qSzzz8UvXzkL0xZ58qdLYPl7QwSQPQnWoIotUOkwpPaRNH4XAhx2RJujlxIR9PFw0U R5WQcNhfX69pL63/SSldeLjYcGaJyFX3n9fSlDk/APKUiXhgsh9BogtS2+cRUa84P+W7 B0ciVYRnIvfdrAvBbDmMYgaAgJoYmaviXAZHQScIjwFJa7TmxF4YDrUA8IRfSLgxkEtM GqiucYQoq5+Qd/gLI76YaU6VXj5UBTtOnK1zHajhOJqpHucZcMWMKQwFSqk4p3EtVChy NeL15RfSe4LTapcgdPiKApX00m/1Dpe+yL3G6MsFKDXRzr3lRol9bEkE4KOOeM7pywEa ByAg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=kZEQdfoz; 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 41be03b00d2f7-cc1bef984f5si4482164a12.268.2026.08.26.04.12.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Aug 2026 04:12:44 -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=kZEQdfoz; 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=kaK/fSY7/o82YGJUBYrC8cuVB0FXhbOqO9QOnNkxoQm0I940fUU0QsTVGm12RWj9nyT3Vzij663AG1H/FjDW/pmhPWiTMdGF+uMmdBupaWiJATeySkm+05u19sXRefHe1rkM3hYBoPd8hB9TKt1RDTTYo18OEgYeN+LuFkw0NfmikDG2uGGCXc/2OYlQ+sb/hsdS73NaFpGGyJic/zrrTst5GGpRG0/SIbrHuW1SB0BraGzD/8qMj5GjV7f9I/7Ygz4G9TUkvAt7bevLql1FEcTNT1kvpBAQLomyC0ncGsE3MGGz9KWn1DntLiazSoFFZCCW6SrNSzVT+edIRTwoQw== 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=0VSU6o51Jbt78Svim3DZW5IgGowHm6r/TZQbtgZdQ3M=; b=asJEbmv/e0qP6vCFa0F3MlN717i7SrWETwiiPA1T13sw1hKnYz8nKGpis9KLi5j/tTdBO+FttEJe9P9pggRmH4DXL3riwTy+H1mpvYU9WX4+AKfJHEVipu8D1Ck2mNcyF++KxmMKdkZ0LNPakI0/tFiLcXWHjneJzx2w0J1HRLGHxXcmdmQb5SN5xvPFl4UFLsMJaIDhxImLiY5UrADddFQDFEbrWlaw40HO3QvxHZQIygHndqTrU4Zo/i6WUsv1VCWjKemEgK0hFEJxURrp8yoKLH6vKdZubdThYz6GO4VmgbvKkeDUG2PBSSNB0E5Zp29pvFBLRdPosngerFxv5A== 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=0VSU6o51Jbt78Svim3DZW5IgGowHm6r/TZQbtgZdQ3M=; b=kZEQdfoz+zBSwjOxN9HYTNshvVQ7/DdYHbaULEXoOc+vCyMdX+dfXeUPSLeRKEkZUy+menig+EoQ9NFCCRtAe7Ea/Zb5jipaF/iqxeYi77x4yyHuUR7rU7T/+uqndfkKC1aFFtVwZSrmvR84cv7WS+26SYqtqV63XgzbF9WHkTR/E2H23kTvudj/hNGXDclZbQDh+6rznQHCY5cGMk7204C4EbhObk6ohxpMIobV+trj5Xp+cha0lRl3/q+H3d5ADC+ecUXbUo8pGlMzMOxUBlFlI/IAX1Gn2RPNQ95Fg2SNpxy30hBEHxelomBJ5o5xJsPyr17Nbv21IERvTMOsFA== Authentication-Results: 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 GV2PR08MB11444.eurprd08.prod.outlook.com (2603:10a6:150:2c8::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.6; Wed, 26 Aug 2026 11:12:37 +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.0360.005; Wed, 26 Aug 2026 11:12:37 +0000 Message-ID: Date: Wed, 26 Aug 2026 13:12:36 +0200 User-Agent: Mozilla Thunderbird To: Mirian Shilakadze , khorenko@virtuozzo.com References: <20260826110415.41119-1-mirian.shilakadze@virtuozzo.com> Content-Language: en-US From: Pavel Tikhomirov In-Reply-To: <20260826110415.41119-1-mirian.shilakadze@virtuozzo.com> X-ClientProxiedBy: BE1P281CA0097.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:79::18) To AM0PR08MB11804.eurprd08.prod.outlook.com (2603:10a6:20b:747::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM0PR08MB11804:EE_|GV2PR08MB11444:EE_ X-MS-Office365-Filtering-Correlation-Id: b8bbee04-3946-40fd-df6e-08df0362efc1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|10070799003|376014|23010399003|1800799024|366016|6133799003|10067099003|5023799004|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: SCRP+DX4bbwLvGjwQHLuRt9tBmvL7yEC6nSzLCW7EcPVP/XUUBV4FkuwbF7/FHQlC85GkhFbsP66yKXW3SZcF64wptB4MSxSStVn2NO9BLTn5Es5TlwhCiCQmk5/TcxKmFIxhubDozPidXlprAtUIcEPe+NMPamrhM4Ty5IMK/XRls7qnpSW2kFaGUpOD2MixutBosCgPOoEz/6nI5JdUtSjRZBE+RUL9nFGksypoqPmLPPtF2ZqVbMhr9j53gnXDdEPrxII4qpM/JJ0OaY+wgpQ2mRJsuCvrF1ThYRKkWrsahi1bFrD2I7sfSavtVn2YJfHiSS3iI/Do+yCEpYgo6F+EzrNfSHcG8+AbdwSzcbeDNFDhFfGhydOy9DaPM2acSCi3gE+tjtnYFDLjciIQ+EtfLGQy/MjVSCIQHfCNuM5GNnKxlIeQfxYhQMponVPieSC3+4hY2s5RDyz2ffu0OE0lpcM4XVUeZ9FPE+m26Jjbx3Er6kVINA8Zr8D48fQL1PbPoiEZjLJPeSG2/bIeCRrNgpjfi4TO9yVCIfOdhkNLXtOkpv70bdwxidf08qEKk6YEPomXXz9XXgSFEbbn1wiYIBVICjIUeqQBxbZXBddsCmGAyFmyvWd5AiFllZQaJs6lis8ufDlYAFmV0rpheQsAB1Z+69uEUJA2TxgBJ0= 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)(376014)(23010399003)(1800799024)(366016)(6133799003)(10067099003)(5023799004)(56012099006)(22082099003)(18002099003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 2 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TEdKVFNCNEw3MkRpcmhSSDcwd0J1VmVndGVCYlVqQTZ4d0pmRlBqenBhN3JY?= =?utf-8?B?aFdrNytKamVOVytGTldCZDVCSSs1aHUvbUxXOGNHMXF1b0VxVTlhMTdRdEQv?= =?utf-8?B?RWN2MXVuWWRlNmhWSXorYm5QSmNleFR0dkcvc1NWL3NnS1I1T1dvdjBWQ1Bo?= =?utf-8?B?N2NadGVSNVpld2MydG1HcTN0L3gvWjd1emQxSWtuM20xcXF0UW8weEY4MElF?= =?utf-8?B?YVE0TnNnbWZsdHp5b2k2OVVncDFicnJJZnA2QmN3SkQvNlhwaTNBcUtQZUhZ?= =?utf-8?B?OVBuZVI3SFRuM0RjZnRKSWs2eE1TU3ZXN1Jvc2xqc25EVllNbXNWUzZxcHM3?= =?utf-8?B?R1U4dmh4K2pxRVIxWjhoem1ick5BdWl3L2FWMDNxYmUwOUpiM0JVMXVKU0dU?= =?utf-8?B?RDZGcDVqTUgrcTRKT0RpZ3EwLzhvcGlqc0JLUjczN1grd0hvOUpyWjlnNnZB?= =?utf-8?B?VVBoenlleit3OFJxSUc1MjAweHJiZnFod1V4YnJ6R0J2NTVLdkRKam55NTBj?= =?utf-8?B?bDk4bVRTK1lvdW0zWC9rMzhOZ0tVejlSdDhXT2RBS09abXhSdVU5d3hGYi9t?= =?utf-8?B?MExaSk16ajFnYmpMVWdScnc3aitLeEtFSkx4WGxBd1E3Y3Q2ckhGNllqU3RN?= =?utf-8?B?SnRkVXpaeU9SWitmVWozTDJPUUxKb0VvbTJpdU9xM2dPQVppcHE5TVQwVnBk?= =?utf-8?B?V2plbWIrOXU1cHZ2c2ZQa2NqMUFCbTMxKzc2VU9sQllkTFpNMDNMTDlsNmhG?= =?utf-8?B?dVErMVlLNUovcHVaeTE0cFIrYmtobFlWN2QyZmJkQUxQaVRJNHBIMjNrM3du?= =?utf-8?B?bGh6WGk4UnhxbE40VlNmbStacW5hZUZlSEV0cThrZUdYelhrb3ZqejVyNnBF?= =?utf-8?B?QjFSRE55Z1VJdTk5Mzg3RHJnQXB0WEdSVWZwNG50TFdGOSsxOUkxTWQ4Qlpr?= =?utf-8?B?MnZqUklJS1E0NUtPSTBGSks5ZmNCMmhvN2JMN1hWaFViVEM3cTRYdVdzYmM1?= =?utf-8?B?Uk5SREIvdEpOemt1bWVjY1M3N1loWjB3Nkc5YlQ3eEkyV3V1YjdXU0RlVkxB?= =?utf-8?B?QWYyYjNSSEt6MnJzYkk0L3B6a0dQNStjaDV0UGFmMG1xYnVWNDIyRFpnOXRh?= =?utf-8?B?MzNFV3JNWi9GVnlndTJONjFnRjNzbkJwd2E0UjNFRHJTaEN4M1dPeFhGQTJJ?= =?utf-8?B?Z0I0cGJ6Ymc0ZmdqUU4zSkV6OVRsZFI2dXhpQkhoU2h6OERhdTVGeVNjM21m?= =?utf-8?B?MWxTR1FaV3A4bHd4czI3eE1RQlJKTHJnTEo0ay9WT2p4WDVTUktnRzh4cWV4?= =?utf-8?B?a0FYelltcCt2K3lzZmRVdDN0NDFEZWxZQy9NS3NBZS96UXl3ZEpkOXF0bzZK?= =?utf-8?B?TG85MW9xWHoyNDluSVc3NE50WnN6OEwwNVR2UFdBbzgvQ1NTWnRYVkprNTZD?= =?utf-8?B?UHZIMHNITWZRamI5Q1NYaDBRTkdZVkphWGxaUitzWTZ4a3ZXTFNXdlN2ZXBC?= =?utf-8?B?bUFkWGtyeWtjYkhjMlZyMDg3ZHpyVTNBbnNXRVROUGdoNk5jNE9vWkoySURE?= =?utf-8?B?MjlzZXVUWDEzRzRlc2FzQTJjK0lPeUJxVUFBeXZFUGlCNllWUml5VnEraUdm?= =?utf-8?B?aUo3YTNrVnY0S1MwTEp5RktrTUZ5WUEwQ2dEeU5qeVlFQzgvZ1pJZ0tnU2Z2?= =?utf-8?B?MXMwZno5Z3VlM0dtUFhCWnNJcEt6Ly9Qdmlnb2tlcC8reDVrNGNialNPZWtl?= =?utf-8?B?UXlkRW55K2NXODl0aUFYT0d4eGE4UlhSMjI5NVJlRXRqNUtFYThkbTNMQ1hs?= =?utf-8?B?aG9sRXdEWFlUWDVyT2o2SmViYXVwQnN0VG4vL1lVUHQwTjZkVkxwZGI1alk5?= =?utf-8?B?alBOWUZJZEdUckJkNnVERllZVXJIQjRvUmRkVy8wY0l1aEtBanZaTWhhTEl1?= =?utf-8?B?OHEyem5LckI1VG9PQmhYZ29CM0Zlc0tKUFZWalQ1aThyNFBlQk5DTS9VV3lz?= =?utf-8?B?SnBER3JFNmZUVnNVbWVtVU9TYkJ0SmQ0Q1FqeUdhOEt5bVB3VjNodWhyK2hy?= =?utf-8?B?WWg0OE1HZWlkdnJnR2tsVXFzSTNOM1hjcUV1NVhPa3owWHVlbzR4ZzlvR3BI?= =?utf-8?B?M0ZkOFhHajBSOTVLTUZTU2JLRFZGM1R3aEFac0xkQnlvaWxWUUVEVUJneGVB?= =?utf-8?B?S0plRWZEY2Y3NWhnUXdUNWJwNVdLSk1hYUNuK1BWU1QzaHhNY25NcS9HWm80?= =?utf-8?B?bXRCMkhSVnhzendTSFQzOTF6dDM1Z3BGVk9oYVlKQUs4bm5ERElWakRPTFc5?= =?utf-8?B?REZsdU9xOWZadXJVZVVwUkpxUURjRTlDb3ZZdkd4OU1xa3pKMDdwZk5uRXY5?= =?utf-8?Q?9E29KtkiXoofVWD62YyP1w6RZx69ASvhZgSyTMZ85O5Rw?= X-MS-Exchange-AntiSpam-MessageData-1: HR7p3s7iHC5jJCx1L3XL6y+wD1Efp601S3U= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8bbee04-3946-40fd-df6e-08df0362efc1 X-MS-Exchange-CrossTenant-AuthSource: AM0PR08MB11804.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2026 11:12:37.5471 (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: 7qn2taVcoI3+9w8K1ud6+5xjYceuH3umed4C7eUtPlSmDypXeg/9f7EfK3ankMjOmT/YRWZroAw3lMT8ZR3AeYa6qFErvZzRgFQ7E0uPBmI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB11444 X-OZ-Fwd: true Cc: devel@openvz.org Subject: Re: [Devel] [PATCH vz10 v2 0/2] fs/kernfs, ve: stop a container lookup unmounting host filesystems 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 Reviewed-by: Pavel Tikhomirov On 8/26/26 13:04, Mirian Shilakadze wrote: > Starting a container whose configuration carries a bindmount whose source is > a mount with its own superblock unmounts the host's bpffs and tracefs. > libvzctl needs bpffs for the cgroup v2 device controller, so once it is gone > no container on the node can be managed. Every later vzctl command on any > container, including ones that were already running and were never involved, > prints "Unable to find mount point for bpf" twice and then reports a stale > status. Recovery is a manual mount or a reboot. This is VSTOR-142552. > > The container start is not what does it. Any task whose VE is a container's, > resolving a host path under /sys, unmounts what it finds there. setns() on a > container's ve namespace, staying in the host mount namespace, is enough, and > one stat() of /sys/fs/bpf both hides the entry from the caller and destroys > the host's mount. > > kernfs_dop_revalidate() ends with a per VE visibility check and answers it > with the same "return 0" that the staleness checks above it use. Those checks > are properties of the kernfs node and hold for every observer: the node was > deactivated, moved, renamed, or retagged. Visibility is a property of the > calling task's VE, so one host dentry answers "valid" to a ve0 task and > "stale" to a task inside a container. The VFS reads 0 as a global fact and > calls d_invalidate(), which hands every mountpoint under that dentry to > __detach_mounts(), whose mountpoint hash is not scoped to a mount namespace > and whose m_list holds every mount attached at that dentry in any of them. A > per VE answer therefore destroys a global object. > > Patch 1 reports the name as missing from that check, except on a kernfs > instance the VE created, where the dentry is dropped as before. Everywhere > else, the host's sysfs above all, the caller that cannot see the entry is > told the name is missing, which is what the check is for, and the dentry > stays valid for everyone else. What a container is told does not change > either way: the errno for a hidden entry is ENOENT, because today it > arrives after d_invalidate() and a fresh lookup that ends in a negative > dentry. kernfs_iop_lookup() has always answered this same condition with a > plain "not found". > > The one exception is a create attempt on a hidden name, and only on an > instance the VE did not mount, where it now fails with ENOENT rather than > the EACCES it fails with today. On the VE's own instance nothing changes, a > create on a hidden name still fails with EACCES. Both fail either way. > > Patch 2 adds the regression test to the existing ve_perms selftest. It mounts > a tmpfs on the entry the fixture already keeps host only, in its own mount > namespace so the machine running it cannot lose a mount it needs, and > requires that mount to still be there after a VE has looked the entry up. > > Introduced by 3dd8c2499df6 ("ve/kernfs: hide forbidden entries in container") > in 2021 and reachable ever since. It went unreported because nothing in the > management stack held a mount under /sys that anyone would miss, until > libvzctl commit f946fae ("cgroup: switch from cgrou-v1 device controller to > eBPF program") made it depend on bpffs. > > Testing > ======= > > Tested on a VHI 8.0.0 node with the same script, the same container and the > same bindmount on both kernels. > > On stock 6.12.0-211.30.1.14.4.vz10 the start fails with rc=255 and "Cancel > init execution", bpffs and tracefs are both gone afterwards, vzctl status on > that container and on an unrelated one prints "Unable to find mount point for > bpf" twice each, and vzctl exec stops working. Losing tracefs also took the > kprobes the test itself was using. > > With patch 1 on 6.12.0-211.39.1.16.9.vz10 the same start returns rc=0, bpffs > and tracefs are untouched, both status calls are clean, and the bindmount is > present inside the container and read only as requested. The same holds on a > debug build with KASAN and lockdep and on the shipping configuration. > > Under load, 48 processes inside a container's VE entered with setns(), > alongside 48 in ve0, resolved /sys/fs/bpf and a tmpfs mounted on a hidden > sysfs directory, 384000 hidden lookups in total. Every VE process saw ENOENT > on every lookup and every ve0 process saw the entry on every lookup, with no > mixed results. A kprobe on d_invalidate() named only the test's own cgroup > dentries and the /proc pid directories of reaped children, never the hidden > entries, and __detach_mounts() was never called. gcov on fs/kernfs/dir.c, > fs/namei.c, fs/dcache.c and fs/namespace.c agrees: the new return ran 384000 > times, the staleness paths in kernfs_dop_revalidate() never ran, and > __detach_mounts() was never entered. > > Granting a path to a VE through ve.sysfs_permissions still makes it visible > and revoking it hides it again, and the host mount now survives the revoke, > which it did not before. > > ve_perms_test passes 16 of 16 and ve_ns_owner_test 2 of 2, together with the > filesystems, mount, mount_setattr, move_mount_set_group, nsfs and proc > selftests. Patch 2 fails on the unpatched kernel with "the VE lookup > unmounted /sys/power" and passes with patch 1 applied. > > The condition added in v2 was checked on both sides. During a container > start it never fires: of the 13 lookups that answered 0, every one returned > before reaching the visibility check, from the negative dentry branch or > from !kernfs_active(), which are the device mapper and uevent nodes churning > as the disk is set up. The lookups that do reach the check answer ENOENT, 8 > of them, and __detach_mounts() is not called at all. It fires where it is > meant to: a container looking up a hidden entry in its own sysfs instance > gets the dentry dropped and the mount on it detached, while the same lookup > against the host's sysfs answers ENOENT and leaves the mount alone. > > Two of the six ->d_revalidate call sites, __lookup_slow() and lookup_open(), > were not reached at runtime. This tree carries lookup_fast_for_open(), so even > an O_CREAT open resolves the last component through lookup_fast(), which > leaves those two reachable only through a dcache race. Both gate > d_invalidate() on exactly 0, as do the sites that were exercised, > ovl_revalidate_real() and ecryptfs_d_revalidate(). > > v2: > - patch 1: keep the old invalidate on a kernfs instance the VE created, > and only report the name as missing on any other instance (Pavel) > - patch 2: detect the mount with openat2(RESOLVE_NO_XDEV) rather than > reading /proc/self/mountinfo (Pavel) > - dropped Pavel's Reviewed-by from v1, both patches changed > > Mirian Shilakadze (2): > fs/kernfs, ve: hide entries from a VE without invalidating the dentry > selftests/ve: check that hiding an entry does not unmount it > > fs/kernfs/dir.c | 17 ++++++- > tools/testing/selftests/ve/ve_perms_test.c | 52 ++++++++++++++++++++++ > tools/testing/selftests/ve/ve_selftest.h | 40 ++++++++++++++++- > 3 files changed, 105 insertions(+), 4 deletions(-) > -- Best regards, Pavel Tikhomirov Senior Software Developer, Virtuozzo. _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel