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 2486C8015B for ; Fri, 18 Sep 2026 14:31:03 +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 68IETRjk000374; Fri, 18 Sep 2026 17:29:29 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68IETRjk000374 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="lf+RMMd8" 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 68IETOqZ000370 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Fri, 18 Sep 2026 17:29:25 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68IETOqZ000370 Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-88f0df42044so9341167b3.2 for ; Fri, 18 Sep 2026 07:29:25 -0700 (PDT) X-Gm-Message-State: AFuF++mhL+EbGn9xb1Y2Ndre18Gi1EeM3U52V5dz8A16OR2I6hpfL+n4 s7gqflkWOIKzCrHTIPcnlvBrckjZjdoFaNr6oR5FIFQuOjGiH2inctEea2w8r/RdPGxBgIbWO/G bcR1pckcQMFa2EenZhQSBcSF3/+8s4QW4K8SP628ymkXclj2M9WBLKg== X-Gm-Gg: AYBFou0B92/NEqt7f/8gXN6CxywL/kubvMfi3Vwu9VtQyLYlO8lvIUlwMSddqSY3pD9 7IlB7/7qVKJ9fNiIBcYhXGG/kWO8kr/bAUWsvRqIQaIq6TZyaVJpHqfzKC5pR1pveITjUZWCeBG Ir1Rzm9G9U5MiWq8KFzwmFklwPDFGRa4Y2wpfDlKFoao2X2R8Pgl5rpyE4mdJkzc/lPetXjxi5S 84SLxLB5UAAW+FzaPFPunL59YCu63viynOq+iRkm1xPypP46i8nnVkQcDHYRtx/DiBc+7aV1xsC TA3FRoBzATDbEroPET1vtrPiQda2hhcwuono+e+gNlMF8PBQwoinGdYG4MXe17njFkLhWxRtoFA 7UBoTpdHD8ykwXziQQYkUDyWDItA3p34TzYJb35NMEvEM6gkzlOIMCsXtmSCYGnl4a/mHA7nbJ0 LUGI+5ybl1DU6ZsUVddBG3nvKqYqZ9cZ07 X-Received: by 2002:a05:690c:e20b:10b0:87e:2404:6b45 with SMTP id 00721157ae682-89736366fb1mr6194887b3.53.1789741763969; Fri, 18 Sep 2026 07:29:23 -0700 (PDT) X-Received: by 2002:a05:690c:e20b:10b0:87e:2404:6b45 with SMTP id 00721157ae682-89736366fb1mr6194807b3.53.1789741763532; Fri, 18 Sep 2026 07:29:23 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1789741763; cv=pass; d=google.com; s=arc-20260327; b=AZqBmu+ElBjOskg4giyoX7gWteM2vlY+8/fz1W7LhI7MT/6GP0yQPnntY9wRHkW7a1 m64njzFU3TDnrE5fP9uc8PRGiAha1zlWA5quhqioZFVpSnd/n2YK6C8MBO+thjCPyx25 EBW/qrCx3InKPZiak2scD1DGt5U263ncLpmZsbiqkerIa/m+dywVm47lQzZTtlHeSRFy XHFn/3uQB1xaQchIbn1I84O6n9rC+6L52d5ddu2yGgFS9kn111pnzKphvkfn42Im3xUE KXIg6YiyisMlZbXGTvY964z84bOaktPUwzxSW9ANU2X4wivzdG6qsDjbRZiy/leXlJab jKfA== 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=LXOmvbQ2yTnI22qc5IT4cJ2GA4/7eCeuCpyfdsJPbPA=; fh=jWAqq0hGIH/vV+Fnu8VAgTGXWmniroiYKNvjUsnkpNg=; b=bzckCyPFcWz4vn5yt/YR6ye9zqgTA+gxyzD3kEVKU27oMkL1DOP5ULJLMwZn38fqxi Im990uzF1PjNmO+4lG8obk84L88kmCHFA8eAnfC+9NaSla7dteTWEJhBU6uc72KQ+RpO SeKbqdjErpTzMEHNy9voTaIYcNXaaCYtQ+JR6nugTctcxc4oaYJDJ7jU+Mxw63gu/uLk WP+W9XcaNwrffqtOCHsIwmELvOf47V25ZW0tcCyvi13v/tEXzZT0NiikknLLaJjZ8Mvq 3LyrUTGS4enuF47ENviQkoNzk5bVSzL/AcUXAGGYhAIoel395h2dlFJ+A8AUTVLhb6HF qm0w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=lf+RMMd8; 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-897ead4c872si6317407b3.81.2026.09.18.07.29.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 07:29:23 -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=lf+RMMd8; 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=DvT7Mo/YDdysw1sFtRWl/4bC/xUYtl58vyqCtB0009BlfY2DKc+pbNDZ8SZrAp6WOmQspOwfHr5ObAMEw9qMgT1mT4Qk6VkVpNygFb3RVkrvS7/qeMv3PV9ntxplvnSPLQTDqbr6B6SffXQB1yYE186EOJcQNPu7YSLTB2e2EKGI0YdQ/6aWtthBY2MwuKgw3Hwf0QoAR7OMqs/hIfd1V5RgpO9xYkbQAyNTkT0cjBgToht4/Qx8fovyDqTGPK4s8QG+fx+pPPHRLIFBADg+7HUyrXu3EkAYZeLf5IExuW+Odacg0h/LXK1C0ySdqi2Ok04hRX2i4a2UaCJX411U+w== 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=LXOmvbQ2yTnI22qc5IT4cJ2GA4/7eCeuCpyfdsJPbPA=; b=GDuGZ7QhT/WhJbkpQFJYyXqPtw3zSbaiF46n15BJuiSL41UoIA7x2mRwQ1boHLfDaUK0ww4x5kS/PFp0rxk+C3t0i/iurPBdcfl7biE1/2mvzIlsUpe3Lbet+9Am8ClrOl4P80Y+WzYZa1s3F8qUl9dQBgbxA/uaf6kvmx1ozp50ZJ6We5EbWUVAuiWloQtG3k5GqUJj078csI9frX6mGjJfqBggeG0aR1qqmDkKmQWw3vOsuzI3wuC0Afb64Wxwvdv7OJeL6J/ZNoNrxt3kQgUrQJ+hoYrpvpjrWIqRE8erv3Ais9Hm9fPD8T0VCnLGzcTNuBR4FrIZzJVMBNeSeQ== 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=LXOmvbQ2yTnI22qc5IT4cJ2GA4/7eCeuCpyfdsJPbPA=; b=lf+RMMd8YvTCq6DzzAEHhwcb2o4N3F5/8gl4XHM3PVWzwNgI2aO2uK9x+ABeGurUYnbmp5F78g6rcT4vbkrOcSGyJsOgR4ovTmRydzfDIOOPLhBGBPWDqIa9YKKbQYRnGV4WjIpZjvXKMNuDKyE/3ioMGHupMpb5+afVV6/UrAcg/mc855zrtTXeSGi6niKL+D67frxG2is1m/aftVa+yrYvqEYu4nLRVaUW3SFOs36c7WFfNCKr02cMfGS+nCcjG7k69eSPzlNsP/sWLv7ZqmCNf9wYnarXdcRlVXQUX907yGlCouGZ7e2x/4nsnLkdLCNe+kftkKNC8qMULoziCA== 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 AM8PR08MB6500.eurprd08.prod.outlook.com (2603:10a6:20b:361::22) 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 14:29:20 +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 14:29:20 +0000 Message-ID: <03c354c6-6acf-4823-8f59-1f0d1aa18faa@virtuozzo.com> Date: Fri, 18 Sep 2026 16:29:18 +0200 User-Agent: Mozilla Thunderbird To: devel@openvz.org References: <1192cb6b90315be4aea86501a203310202147ee2.1789491989.git.vladimir.riabchun@virtuozzo.com> Content-Language: en-US From: Vladimir Riabchun In-Reply-To: <1192cb6b90315be4aea86501a203310202147ee2.1789491989.git.vladimir.riabchun@virtuozzo.com> X-ClientProxiedBy: VIUP296CA0093.AUTP296.PROD.OUTLOOK.COM (2603:10a6:800:35c::14) To DU0PR08MB8470.eurprd08.prod.outlook.com (2603:10a6:10:406::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU0PR08MB8470:EE_|AM8PR08MB6500:EE_ X-MS-Office365-Filtering-Correlation-Id: 2d7fff06-9dde-4077-565a-08df15913a03 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|366016|1800799024|23010399003|376014|4143699003|10067099003|6133799003|56012099006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: mIJ5CUHIlVwdJulkSQitalgyeRuWXBFWSQ0Uj7SaQXeLciQGZZSG8uMpYFJSBmoqQaSTx1n7KbVjpFBUuGioBxvcooq5LG1NlgTo7xHAEp/qnzF+iWy0+n6crwPMTRdB0D4dCKj7PBOeqZzHf0gb+90tsyO/O+67h8MzE2QfXnArvT2l1RH0EG8u0stwZUU4Gd+I1lqJ5ZKgWe1HUmec38qdW4YBLbS7ATPTBUUZLdcsr+pzajMERx4Kbu2cM8kCRv6dT+v2AdWc71zS2yYzfG5bb95JsVwSKjKO0dY3W9C7Tl05DZ9J7ovQq/ErQ7pC+YcobOgexOouYJHmzIpXXjybhdwXmPOz/ePRM06TCdJXAN48hhlargwabk+TU3RD80vbzR1HOGSNB4roSFa3iSeAfDSi0znJQZPFEdGLohTISlRPPwLDUdRFPuP5aBMWeWEOZkerVML4zWLyS5hoKXkZU2fShC18dQAZiGxa57wvN6LGDKyTBSd2QNGMJh9O9qMHkoG0lNBYBXOsRsgYHv1UPrDCqAcqlAbFKMJDWl7ka/EXzCTkNdxbZ+XvEAeKX2lLYBa18w+jAU9ebBSgs4Jha+rAhB5k2eDkME/wjCKeIG5YdD5GqA+Ii6KAqZPrIan9y2Ic6K0bxzD7YxLs4j1uMEcx6ykFgidvH2zczl4= 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)(366016)(1800799024)(23010399003)(376014)(4143699003)(10067099003)(6133799003)(56012099006)(18002099003)(22082099003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N0dwcVRIU1phMVBycmFYMDczcHVUTWNldTF5Vy9tRXVOOHRSd0pWVEMwakk5?= =?utf-8?B?eXhIc1o4bE9WQzNiLzQvVDEydFQwclYxa2hSQUlpWkRocms4b252TUNRaWp0?= =?utf-8?B?YzZuNDZXYmc0Z2dlVmM0KytyUEZaMURLODBsQ3ZnMU5xdm1YZGdjeXhDRExG?= =?utf-8?B?cEl3WWFYWWFlaTl6bTh5RG1qZEU1Zjhvc3ZTSDZ5aW91NG13bFZWN1pLWElB?= =?utf-8?B?UUkxODZpamhITlBZeDY4cTFQbzhlSkJEcU5CeGpxeDdyd0dXYzhOak1nOXYx?= =?utf-8?B?Tm4zWmY0dE9DRHc4UE10UWFiYnhpQnRxUUQreHRpeVhhK3FrSkQ4YWJJTExY?= =?utf-8?B?S0FVeVFTMm9OYTE5WlBmdm5DUHBNYXZEbG9zWmtZNGYxbVB3MHBwZktyZy9B?= =?utf-8?B?UmFoa3VUV1JFQkdNRU9YeVlHNzVKWkZtVE9qdVVZREtaaTE1NjkvRmVkZ1Nt?= =?utf-8?B?NUlBTHBMZ2RHZVBFM0xJbWMxR2ZvSHZMKzN4cFpVVTJOOXRZZDBnNzMzSWxw?= =?utf-8?B?SjRpdVJtb0g0OTJ3dnRyYWxjUkJVcWJmOWV3QktiS3k1RUFzUnZoekJ1dXpj?= =?utf-8?B?YlRMWjYxNU9hZ0FtWGlEbFFWN2RrTEl3aVhlUk9ONU1RakFQdUFKNG9TelJj?= =?utf-8?B?YUY1alhjOEliMDUxOGZTazBESngwQnkxSXBKQkxQcXpuRDFDbmpuOWwrNFVM?= =?utf-8?B?WHFrMXhFa0lkRWpsVE9oUjVpVHFiZWhRQUpxOXV2UHRyMGxGT2NETytvUnNN?= =?utf-8?B?aWFUemNWbStQNzA3UnkyZVZJbzdRbk1IdmtXa1ZObVJPRUUrUmxWSm5iMU5D?= =?utf-8?B?VTFjOXFNczV2VWNoc042M2UxUmxCYXo1bFphMXRkVGd1ZHBSa293SjE4c0VM?= =?utf-8?B?cEdnbi91ZGs0Y1FsaXBJZ2I5bGFRTnQyVmV1U29LWGtyMzkzZE9SZTV2bEFY?= =?utf-8?B?UDBrRUZFYnJjaFpydi9hYzhYNzlncVdjellEWWF3dGJFaXNTWXpGS2tmNnc4?= =?utf-8?B?bXdEZGZWNEJIbk1MOXE4NU5FWFdXSGJleWRqMkh2MGRIcDNxMlhVTE9kNTcr?= =?utf-8?B?N0hCOWk5dkdTN2xaTG1mV1pzdkRZYzgxTWkxZjlVM2dZR3BQdFoyc3NkZllH?= =?utf-8?B?SS9sbGZENS9xaWNzVDRQZWl3N2hWWWE0SjJhYUlHNmdPOWVyWnllZVlNSUFF?= =?utf-8?B?RzUvZHZvcURtUHhPc1prOFlaUktBUkE0dm94NldOTGprUCtLcmUvTnB5bFdE?= =?utf-8?B?TENjKytoaVk1WDVMS3pRN25PRDhZN3VpdzMvWkx6cXJmWG9tL3Y2Y0VGNVlp?= =?utf-8?B?ZXJuYUtsUlZSRER6NXZEeS9MYlM4L0I1NXJMdVBxOVoyM0VXb2J2eXQrOG5j?= =?utf-8?B?QlFPUkdkczR2NStjU1hJdDdvZlpRVVcwdHRONVRnLzBGOHFFME9MdXROaDVu?= =?utf-8?B?WjdqNklHayt5akp1cVhETWRFODlVNW5Oc3QxVTJCNlNGMVNFNEppTVcxNmVS?= =?utf-8?B?RTgxcHJMRGhMaFZZZlhpa2hhdnRINkVsL3dZMnlZaXBqYjBOL1ROWllHU3dn?= =?utf-8?B?dy9VYTBOSEFoREdkN0dDS3o1b21IamtJWHNLdVRGMVNkMHgwemxoMnNyUVI4?= =?utf-8?B?bVQ4N3ZadCt6VnBQUkoxbkxIaS9pVEppREhzQ0pxQVFjSmtSMUo5SnNHak9C?= =?utf-8?B?b01uQXh3ZlVOV2NucFJIdkJQQWdnUFo5bDV5b0lWc1RHV0ZDOTdVelBGQ0hl?= =?utf-8?B?RmdjZS9XOFFjMXJZRGF3QU5uREgzbW5VRDFoWVFkbWI2MEVXR29JUy9PbWFu?= =?utf-8?B?dUxKMmdDQWZhTVpwQTdIZW1pMjFQTktLRWU4ZTJpSjZwWVVkc0lqRnQ2VTBI?= =?utf-8?B?KzJ0MEZDVU1Ib2dHMVJXM0hFZmZVbHJQcU8zQkFtK1Z0a09zRFQ4QWVlRDVy?= =?utf-8?B?OWVNR1ZreU1lVkppeWNLaitnVjZqTDVIalB2Zks4eW9KN2pXbWl0dWViQ0g2?= =?utf-8?B?eUUzQjIyUFlyYmZ2ekRNWjFTcTdlcTBJRGxQY01FNzdaQk9yU0JnMWZJNU56?= =?utf-8?B?RnpOSE4rTDZBQ2ZQZXo2VlBldVhoc3d4akkzQ2lWcGl1V3lrT0J2aDR1N2hm?= =?utf-8?B?WVg0RlBxZWZQbDdsYWNZSGxiakRVb3YybFJGZHpYUHZ6TnRTbmVkWS92MENN?= =?utf-8?B?WmtnOEZpZkhxZEJuWTkrQVZTQ1R0TDBxOEJMa0l1N1VOUU02MkRnQ1J2dktI?= =?utf-8?B?MFdOS2c2eUdkWnJVOHNoUmszRWNUZnVDUDgxMXJ3ak9NWWZZVE1qMTRwM2FB?= =?utf-8?B?TjV4MU9rK3ZTOTRic2hFMlFNTHBWcUFTRDRlWTV1SjFiY1NIK0JUbDBKTytR?= =?utf-8?Q?gP5I7Z+ilTIAZKlM=3D?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d7fff06-9dde-4077-565a-08df15913a03 X-MS-Exchange-CrossTenant-AuthSource: DU0PR08MB8470.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2026 14:29:19.9344 (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: o6VoyeMfBTb/URBlj19mmVmeVW+xLIDNFEto/fPE4goNTLd8Fgvr/8yhSI7+4kh5hbEN5yYvGdzX33Iqt6DcV9fQ6rMtiD9QWgMcwnyryvQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6500 X-OZ-Fwd: true Subject: Re: [Devel] [PATCH VZ10 v9 4/8] ve: Move from global VE mounts limit to per-VE limit 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: > This change unifies mount limit handling with other VE limits. > This will simplify refactoring later and allow more precise limits > control from one place. > > https://virtuozzo.atlassian.net/browse/VSTOR-135520 > > Feature: per-ve failcounters > Signed-off-by: Vladimir Riabchun > --- > include/linux/ve.h | 9 +++-- > kernel/ve/ve.c | 34 ++++++++++++++++++- > kernel/ve/veowner.c | 19 ----------- > tools/testing/selftests/ve/ve_ns_owner_test.c | 6 +++- > 4 files changed, 45 insertions(+), 23 deletions(-) > > diff --git a/include/linux/ve.h b/include/linux/ve.h > index 65c058c0f34d..fabc608e31f5 100644 > --- a/include/linux/ve.h > +++ b/include/linux/ve.h > @@ -96,7 +96,13 @@ struct ve_struct { > atomic_t nd_neigh_nr; > unsigned long meminfo_val; > > + /* > + * Operations with a big amount of mount points can require a lot of time. > + * These operations take the global lock namespace_sem, so they can affect > + * other containers. > + */ > atomic_t mnt_avail_nr; /* number of available VE mounts */ > + int mnt_max_nr; > > #ifdef CONFIG_COREDUMP > char core_pattern[CORENAME_MAX_SIZE]; > @@ -143,8 +149,7 @@ extern int nr_ve; > #define NETNS_MAX_NR_DEFAULT 256 /* number of net-namespaces per-VE */ > #define NETIF_MAX_NR_DEFAULT 256 /* number of net-interfaces per-VE */ > #define BPF_PROG_MAX_NR_DEFAULT 256 /* number of loaded BPF progs per-VE */ > - > -extern unsigned int sysctl_ve_mount_nr; > +#define MNT_MAX_NR_DEFAULT 4096 /* number of mounts per-VE */ > > #ifdef CONFIG_VE > static inline void ve_set_state(struct ve_struct *ve, int new_state) > diff --git a/kernel/ve/ve.c b/kernel/ve/ve.c > index 58a0c4b8e36e..a33e55991e52 100644 > --- a/kernel/ve/ve.c > +++ b/kernel/ve/ve.c > @@ -83,6 +83,7 @@ struct ve_struct ve0 = { > .arp_neigh_nr = ATOMIC_INIT(0), > .nd_neigh_nr = ATOMIC_INIT(0), > .mnt_avail_nr = ATOMIC_INIT(INT_MAX), > + .mnt_max_nr = INT_MAX, > .meminfo_val = VE_MEMINFO_SYSTEM, > #ifdef CONFIG_X86 > .umh_running_helpers = ATOMIC_INIT(0), > @@ -787,7 +788,8 @@ static struct cgroup_subsys_state *ve_create(struct cgroup_subsys_state *parent_ > > atomic_set(&ve->arp_neigh_nr, 0); > atomic_set(&ve->nd_neigh_nr, 0); > - atomic_set(&ve->mnt_avail_nr, sysctl_ve_mount_nr); > + ve->mnt_max_nr = MNT_MAX_NR_DEFAULT; > + atomic_set(&ve->mnt_avail_nr, MNT_MAX_NR_DEFAULT); > > #ifdef CONFIG_COREDUMP > strcpy(ve->core_pattern, "core"); > @@ -1068,6 +1070,30 @@ static s64 ve_mnt_avail_nr_read(struct cgroup_subsys_state *css, struct cftype * > return atomic_read(&css_to_ve(css)->mnt_avail_nr); > } > > +static u64 ve_mnt_max_nr_read(struct cgroup_subsys_state *css, struct cftype *cft) > +{ > + return css_to_ve(css)->mnt_max_nr; > +} > + > +static int ve_mnt_max_nr_write(struct cgroup_subsys_state *css, struct cftype *cft, u64 val) > +{ > + struct ve_struct *ve = css_to_ve(css); > + int delta; > + > + if (!ve_is_super(get_exec_env())) > + return -EPERM; > + > + if (val > INT_MAX) > + return -EOVERFLOW; > + > + down_write(&ve->op_sem); > + delta = val - ve->mnt_max_nr; > + ve->mnt_max_nr = val; > + atomic_add(delta, &ve->mnt_avail_nr); Sashiko says: In the function ve_mnt_max_nr_write, the computation delta = val - ve->mnt_max_nr followed by atomic_add(delta, &ve->mnt_avail_nr) might lead to an integer overflow. What checks or safeguards are in place to ensure that this operation will not lead to an overflow, potentially affecting the VE system state? 0 <= val <= INT_MAX 0 <= ve->mnt_max_nr <= INT_MAX INT_MIN < 0 - INT_MAX <= delta <= INT_MAX - 0 So delta never overflows. Can mnt_avail_nr overflow? No, it can't. By definition mnt_avail_nr = mnt_max_nr - have_mounts. It can't overflow INT_MAX since it's always <= mnt_max_nr <= INT_MAX. It can't overflow INT_MIN - it means we have > |INT_MIN| mounts, which is not the real case. > + up_write(&ve->op_sem); > + return 0; > +} > + > static u64 ve_netif_max_nr_read(struct cgroup_subsys_state *css, struct cftype *cft) > { > return css_to_ve(css)->netif_max_nr; > @@ -1630,6 +1656,12 @@ static struct cftype ve_cftypes[] = { > .name = "mnt_avail_nr", > .read_s64 = ve_mnt_avail_nr_read, > }, > + { > + .name = "mnt_max_nr", > + .flags = CFTYPE_NOT_ON_ROOT, > + .read_u64 = ve_mnt_max_nr_read, > + .write_u64 = ve_mnt_max_nr_write, > + }, > { > .name = "netif_max_nr", > .flags = CFTYPE_NOT_ON_ROOT, > diff --git a/kernel/ve/veowner.c b/kernel/ve/veowner.c > index 1e631baf0de9..c77735f8c035 100644 > --- a/kernel/ve/veowner.c > +++ b/kernel/ve/veowner.c > @@ -48,26 +48,7 @@ static void prepare_proc(void) > * ------------------------------------------------------------------------ > */ > > -/* > - * Operations with a big amount of mount points can require a lot of time. > - * These operations take the global lock namespace_sem, so they can affect > - * other containers. Let us allow no more than sysctl_ve_mount_nr mount > - * points for a VE. > - */ > -unsigned int sysctl_ve_mount_nr = 4096; > -static int ve_mount_nr_min = 0; > -static int ve_mount_nr_max = INT_MAX; > - > static struct ctl_table vz_fs_table[] = { > - { > - .procname = "ve-mount-nr", > - .data = &sysctl_ve_mount_nr, > - .maxlen = sizeof(sysctl_ve_mount_nr), > - .mode = 0644, > - .proc_handler = proc_dointvec_minmax, > - .extra1 = &ve_mount_nr_min, > - .extra2 = &ve_mount_nr_max, > - }, Sashiko says: The removal of sysctl_ve_mount_nr potentially affects users relying on this sysctl for VE mount limits, impacting backward compatibility. Is there an alternative provided for monitoring or configuring VE mount limits dynamically that maintains backward compatibility? This sysctl mechanism doesn't work well with per-VE limits, the only solution to maintain the behavior is to iterate over all VEs and update avail numbers. IMO this doesn't add that much value to have two separate limiting mechanisms in different places. > { > .procname = "fsync-enable", > .data = &ve0.fsync_enable, > diff --git a/tools/testing/selftests/ve/ve_ns_owner_test.c b/tools/testing/selftests/ve/ve_ns_owner_test.c > index c3fa7d7b7f9c..dcff4d54172d 100644 > --- a/tools/testing/selftests/ve/ve_ns_owner_test.c > +++ b/tools/testing/selftests/ve/ve_ns_owner_test.c > @@ -50,7 +50,7 @@ > * any spurious accounting against the parent ve would overflow it. > */ > #define VE_NETNS_MAX 3 > -#define VE_MOUNTS_MAX 4096 > +#define VE_MOUNTS_MAX 32 > > /* > * Synchronisation across the clone() boundary: child does its setup, > @@ -173,6 +173,10 @@ FIXTURE_SETUP(ve_ns_owner) > snprintf(val, sizeof(val), "%d", VE_NETNS_MAX); > ASSERT_EQ(write_file_at(self->cgv2_fd, path, val), 0); > > + snprintf(path, sizeof(path), "%d/ve.mnt_max_nr", self->ctid); > + snprintf(val, sizeof(val), "%d", VE_MOUNTS_MAX); > + ASSERT_EQ(write_file_at(self->cgv2_fd, path, val), 0); > + > /* > * The new ve cgroup has not been entered by anything yet, so its > * mnt_avail_nr counter should be VE_MOUNTS_MAX. Each test below -- Best regards, Riabchun Vladimir Linux Kernel Developer, Virtuozzo _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel