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 444EB8017D for ; Fri, 18 Sep 2026 13:24:32 +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 68IDNBDi032711; Fri, 18 Sep 2026 16:23:12 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68IDNBDi032711 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="p31heFNO" 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 68IDN8qZ032707 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Fri, 18 Sep 2026 16:23:09 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 68IDN8qZ032707 Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-cc1b6f65dacso707162a12.1 for ; Fri, 18 Sep 2026 06:23:09 -0700 (PDT) X-Gm-Message-State: AFuF++nGTA4oFz6OLAhFpyuoRP41R5K/d0M4xMnzKUMxbMPZNSyJs1x0 IrdrgX8mSSPeFTBwqH87xi6aFjxhKkUjV05dmD5Ib/uM+VbTXlutyOfaCsd7q7rWCNnpaTT7pH6 ikimY5WRb0HzrQOPBROEaEk45V/uIC7WuM7+e3HNPgaE8A1IiVpWHyQ== X-Gm-Gg: AYBFou2pks/OlnRZs2dHAM3uEXXS0yfFCiGh8TRHlvlViPKJk6FHwIuDJMcZf+GewJD gsVtjcofXgfgffVkvWNYYMGAPqGOQzIxy8cJCHvxqLjQI8vbvKuZNwijnmOjNJp9BJp99IgpQtQ dNS96kE36tehzhVU4q9z3iHq+/9w789OBbr+BY13hs+Vuz8u860T3cvAEMfCn4axH7IRVvPsxRC gXjBmGMMe+kGhsr1uS+cE0siwYMq5JIkcVPoCJyiFfu6K9E4tCSX71Ztt0YXLtrzXv6pRxWDJt0 IM7pzmbKFmSbFSFYoC/PCdXY5SG5S1FIQBobwK5VKF/DlW9+HZiK+zOKdUnfYaEfonWjtKCkAOw QynexiTVlWCmG27i80ivUBofEyPJPBwkhk2T7/qiila130xtC28iBYvoghcQT5zpKWjiEKlNdWA BkihlmE7Q+DfLkG51m+UPxFqwX9JzERvcDDQ== X-Received: by 2002:a05:6a21:1f87:b0:3d3:ad3c:49a8 with SMTP id adf61e73a8af0-3dd8c515670mr7315211637.22.1789737788308; Fri, 18 Sep 2026 06:23:08 -0700 (PDT) X-Received: by 2002:a05:6a21:1f87:b0:3d3:ad3c:49a8 with SMTP id adf61e73a8af0-3dd8c515670mr7315106637.22.1789737787653; Fri, 18 Sep 2026 06:23:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1789737787; cv=pass; d=google.com; s=arc-20260327; b=DbnlsQZtdM/FrINwclFNsgzu3SJYdAob3qJe54/d+ITLnlq7SlGyiZ1cxYQXdPQgKq iAIgaHruLA21JV3LXyXot+804UD+BklQsD8eUFdYheLu4HenOI58FfWFvxcjQnyzzNOj zYc3gQma3dIZDr0d7ZsjACJ79tPQtDthsU39Oy9k9txZQOaUjml1ybouuWtUPzAc5yEG qD62I2aRbl24dvIl8l9Uo065p3+ewqdCf2toiVYXO3v7VNNKMMLPfrS8sg+tZecT43FU teLbrr6rOI1V9u1iB8+57hGOXdQgaBZycTSG8bIPNcJVOtVV26RXMVf2Nj8uM5TE5DLc gLOw== 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=0r61ZkdT+7gFLlWEny3pFu0tsksqi3fpmA2NAy+cRvY=; fh=jWAqq0hGIH/vV+Fnu8VAgTGXWmniroiYKNvjUsnkpNg=; b=MSixdJinWztvWixagjIa8zcsl6QqK+YBCGPeF2vxm5Zt9AznR8OAhjoUcLkG/iJfuR S/EpLCPAPYSIS6cNxJ1g3IHKsGkqb+UpHQ9iDdSniJXUgEomROk5q4VA/pUQQo1MfEp9 MhK41irC/Fo3t+cPishAkxV6VpXgWOfMHN4MKUJAwqaylN2WOmqjhm7Zvk6kvG1mMlQA NZ5+rXNdrxkuozS0nvBa7Vsf6DWCbQ9g1wYCm25i2amUgKHM9sZ4or6vb0tXvxkvrGYO 5V+4C/pklEFjm7qWYyb0RiHmVnPHphoJnN2uyh6nqqTnrK97FSUGdQNGUYh4f3Od+7wi iEoQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=selector2 header.b=p31heFNO; 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:c200::5 as permitted sender) smtp.mailfrom=vladimir.riabchun@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 41be03b00d2f7-cc5c512d72csi2754202a12.248.2026.09.18.06.23.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Sep 2026 06:23:07 -0700 (PDT) Received-SPF: pass (google.com: domain of vladimir.riabchun@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=p31heFNO; 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:c200::5 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=DUJudK4Lifz/eE8RnTFrxTyEIleBmYXNS/Cp8IbKHGGI0sR+bFwMPI/lRiX1G5vi9t+tWYO6Y5O1iaEjGPc96kakHkL6mHB7raX29rSE1dtts7NUpm8N7DEtwQLmlDAZdJKg4wGJCEAhMOKMh97jTrl33YEXDG/XgbSeLf/gkfkc1qUvtTAFn6fmlE4L1QqhW2ryjBkP7NhvM3LqxMgFDgOpnE4Us1X4JtKpWer8LJdPu1K60TakJn4B1hupEQUIBYcFVmVP5Q/fcKUUYgSaj02ht69wntRT+wDbPJr9789F6yuFh4G+2G3NF0Q/50KtVz28uCSYNg1uMoXGKXFf2w== 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=0r61ZkdT+7gFLlWEny3pFu0tsksqi3fpmA2NAy+cRvY=; b=upEoovpYi364F85zEfMPHvxCP2cIqLz7tpuRffVd0fgJy39Ln38sBZQkBXgyq2Gp8WNS52de4XUQGhW64AsA2XUWMrNMbMRgDOvLaOR951O17a5Oj8tMbEjL/S7oC6Tre8615TfAPKtFddkUNAcFi++X5wo7+NRab5c2gOakQSOQYchXiP5OTPjYKjmX7dQkcMSQnYdKmUZc71Y3RXH0TmCe6qOPQNcks0lYG9uC4aCmo6DW3cWrWMvJabK1A3+/Fz3bAXm4t9J6pv0LiV9EwjztobEr6jutdRs8X+E8ME1TcQJ2wlSnQ55hhXdKO/S3lX8/RtuHyz3klOhw0dmmVw== 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=0r61ZkdT+7gFLlWEny3pFu0tsksqi3fpmA2NAy+cRvY=; b=p31heFNO3c4+sKy4YUSFNfQplr0gYv4LpGkgoW3/axNuKHMwlkq4yKciGZBeLwq+ooaHJhpwOZh+fIU4BI1YY5kwlW9NYhhZ9fapkyM8Q5FjUGUfkWpnfwNpWg6dtbLa8dC6delw0lNWbAs0X86OP+QQrhELF84FRj5/KgPJ/Uv85lKnFJ8TUcw+PcxFCIrB32fQFVYSURjpCJshUrvorvE7ETTAaeeONsTgOQTyDPzezCp7pGBuYSLJgfwx5jjQX0GTQeAszWuQrKGGosEOdT2pMOgbowsDERxdhw+N0XjyduE+g2s66lgtWtCnxpLDjrsKfCVutBBsrLWk+UphEQ== 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 DB8PR08MB5531.eurprd08.prod.outlook.com (2603:10a6:10:11e::18) 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 13:23:01 +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 13:23:01 +0000 Message-ID: <4f0ab7ec-d4f8-404d-bb1c-39ffeada2261@virtuozzo.com> Date: Fri, 18 Sep 2026 15:22:59 +0200 User-Agent: Mozilla Thunderbird To: devel@openvz.org References: <281dbe6b90a8b894dbd63d9368f11e9b5f855888.1789491989.git.vladimir.riabchun@virtuozzo.com> Content-Language: en-US From: Vladimir Riabchun In-Reply-To: <281dbe6b90a8b894dbd63d9368f11e9b5f855888.1789491989.git.vladimir.riabchun@virtuozzo.com> X-ClientProxiedBy: VI6PEPF00000213.AUTP296.PROD.OUTLOOK.COM (2603:10a6:808:1::8ca) To DU0PR08MB8470.eurprd08.prod.outlook.com (2603:10a6:10:406::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU0PR08MB8470:EE_|DB8PR08MB5531:EE_ X-MS-Office365-Filtering-Correlation-Id: 9f4fd434-fce3-4629-0185-08df1587f681 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|376014|23010399003|366016|1800799024|10067099003|4143699003|3023799007|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: TihsSebMFETJYefLWy79EASsZlfI+8lBp6tjlDX6xmyNfISskMNmXdbDD32OOoQ3xcjIu7Iaudb4Ipclh7OEwOOQcbRnwR3sxWQCNa3Htai6eDDk3TcILxi/0/17AEUTJBMeugatty4nmB40Lqt3StbvtGFXE3AZQB0lGaquRTOgiQ0PfaX5O2vvyUR2tZI1vh9udDfinanM5pXb5vpmnGEzE4kSwv7YwOug5Tw9abX/lLsp/4SVGac0i903fbSgYK8pk61iJquQg2Y3mTE6nl08Nfm9/coV+yOWhhUEeeMX75UX3EPbnHxLtIVq9n25sW7BWJax3r0m6txuGvzpeCjjtTyNKuQCGz6KVnQfSD8kjB3PReN5cmmi5uo3Wma1gpGnpk1XZie/YHRfF9ycqd6Q606TYAXFYnQeUGvOqCj6cnD3gk2xG3etD4ZYMa7ICxZuEiFaOJK2rGg6Op4gTbIUsdeDtwOM07O8rKxHWdvnQ7cEK55z9qa4ka9ggk9YHHdwxFmZyUczOBm47Xz2R4fbQnMHLt3LCeYlsIcjga11b1zHobUSlMEXw0TUoF2LGd+oVm+scQM1F1rVqE6rnJ4TGkFOUfzELX8gbvalPlmcqqihsvm6h1fzTP+5FxbDqQpG9MWjvnpbp1Oh9qaiFa+GeJoo7vDebEnQuk/AGmU= 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)(376014)(23010399003)(366016)(1800799024)(10067099003)(4143699003)(3023799007)(56012099006)(22082099003)(18002099003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZXYrd2FYc1pOTkFTQUcrbnBjTTZxdnhHQ2tMTFlqRnZWR3FISGxuNVlycW5N?= =?utf-8?B?b1c1SjdMRy9pY0krQUtMZmhYVkZ2QTYwYkpHT1ViRlQ5UWhwWERkOUFlMHpt?= =?utf-8?B?SElNcXcyZ1RweUMxL2xhemx2dmFJSmpTUjcxRW5NQ1QwZG10RDVidCt4U0FJ?= =?utf-8?B?UENzTEtMQkVPOHR6bDB4T0FMREJOdEZVbkNBSmJmNGJzYUVwYkFjL2N0clZZ?= =?utf-8?B?MS9ZV01ZanZUaTVibTgxMEpVT3hiZFVlYThJVDJDQk42Y00wcTBhb2t4UTUz?= =?utf-8?B?QlJ0OTA2WkhuZm90ZlVZSWF1NHUzOHlLRE9xL3VQOWdBTFR1UWxlR01abnAw?= =?utf-8?B?eC9jZmNlOE1FSmxNUUNLOHo5SGNVNXl2ckhYRmExVmNUaHovd2ZLcWQ4cEpS?= =?utf-8?B?eDVRQmp2di9nc1hBRDdzT1hVdE1JbG5Fek8rR2NteDdmeStBRGdxN3NLZ1U1?= =?utf-8?B?ZldYNURuMEpRNE91TmZ1cnZ2UVhVTFM3RkhZMTEweDJnQy9nU0xFMEVkeVZy?= =?utf-8?B?ZFlJcnZMWkV2aWMrVnVTa3BjaFVleVF4NU9aSktXUUNja0dyazJpVEtiS0FK?= =?utf-8?B?WlEzTWVCSEs5dWt4THFBODd5Qm9yVTUyZGJDd3hub09rNkx2VmhCdlFmbnUw?= =?utf-8?B?M0VhTmJGWUFBN2RUTXo0QTI0VkdBQm9sL1h4MVQzNzY4azFSUXpVdTlOV3BB?= =?utf-8?B?QTlnOUVGN3c3ajVqZFJpYzZyNFUxSFFLOE9jSDAvWFc4WGhuR1RPTmxPTjRQ?= =?utf-8?B?bTQwaFFXejRVeTZMRGpLQTNSVFpNNHM5MmlXTEZUMjB4T0kwenlCWkZLS1ZP?= =?utf-8?B?SVp5WDYxMldyaE1VbGxxdENKQjVuekNHMEloSWkyZ0lYYXFSUlJJd1Q4V0Zv?= =?utf-8?B?VEQrODAzL1dDUHRueDVDQk5lWk52REd5K29hRnJaNTY4WFdyc2xiS1VSdmh2?= =?utf-8?B?UWlpbXBwaXZGaDRiTFNtaDdMeFcxTXAvdStQZmxqVjd1VVdWNDBsTXlIK0Vo?= =?utf-8?B?RzNVbFhSWWs4R25scnl6MHJMcS9LdEFuNC9Kanl2Z3AxU1RhSWpWTmc0VURz?= =?utf-8?B?K1VueTV1cnN3MGF5VUpEYzl6bGsxMFRoWWt0QXhDemp1cVhKbklzZXdNM0J0?= =?utf-8?B?cXI5eFpNcy84UTFZVDdnYXdFeXlINzk2dXJENXBpZ0JLVHRPWjEraElYdWRt?= =?utf-8?B?czBvNU05cEl1U05aRThOaENmR01CZVQwdE5wL2R3QWZXU1kvbjNDVS83bS9L?= =?utf-8?B?L2g3R212eG81aXIrWjIwb0czMmVrbDdMZG9pYzUxdzFuSUYyaU02bHdmaGc5?= =?utf-8?B?QUNXVmh0dUwzTmhQRnF3SFJLL05mYmxWNU1EOUVPcXNhQ2JFTlpWK2lDL2k4?= =?utf-8?B?UiswbVZqS0NZQjVZTE96b1ZyU3NQNW9NS2FRSllPTzllYlVEdlR5bDFGZHN3?= =?utf-8?B?Z0FGZUFLMTJNYTBYZzhnQmlVWGxSQ1RCYmk5WXFqMzQvYm1aclZqQVBia1dY?= =?utf-8?B?WndmRjk4Z2V0ZlBlR3E4VWdFcTkvKzhqOC8zUHpCQ1RKN0lMMUk2cjRKRjZt?= =?utf-8?B?amR1bkNHSThWQkRCOXZCbWI0MkFOeVNoa0FuVm9wNEtmSkVTZ3FBV3MvMkFa?= =?utf-8?B?d2ZMcDNBN1d3YVovRFJ5MjJyQStvL1lMZW5CRW9aLzBUT1RKUk80NDdZK0lv?= =?utf-8?B?NkVLQXhZOU8vbFBuR3VYYkpqK01yeFdhVXhiOEtCWXZDTzh3dzIyMUpQWjll?= =?utf-8?B?OTJtV1YrdFEwbS9QVSthVmZPbFNjZHRRYUEvcXBnMmxIVGRiT1RZSmoyYkhi?= =?utf-8?B?ZlVrV0M0MzZYdXMrUENzSzRzOWpkZzlCZ0JhVlFMMUl5Ymd0NUxHcSt5RFFH?= =?utf-8?B?d3pJYUxjZUk2R2RjeDlaRUtPK3pmSUVzMnBCb3pNZlpsbHNmYjE3cFNnV3VU?= =?utf-8?B?ZDE0VjNZZFd6OWNpUi8zZUZBWjVCQTZBZWJMMm5uV2x4ejdIeEVDd3NNNWtX?= =?utf-8?B?T3M5TDAzSk1qbjE1SlJ2SWJRa2lBSTZnSnVLM012V2NieTJ3SVZxZ1oyN1pm?= =?utf-8?B?WkRtVHhZd05QNHpZSXFRekw1NnNKdjlMQVhWT3RnTHlleE1tL3gzRVlPVkFn?= =?utf-8?B?aldIaEVxM2ZiYnRjcHl6dkxuckp2SVhFK2cvSUc2WjZNdjI1M3FiMFJyRUVM?= =?utf-8?B?YWJCMzBsUmtvWTRab2xyNGJRUE5aaXJRQWlMMlRkR0lwbGZIbWpGNUlkTnNE?= =?utf-8?B?R25zU2hrcGRCcktrN0F4VmFKUDZNWHBzMzhiUFpxTnFUWDFHUVF2WlE4THcz?= =?utf-8?B?NWRoRVhKREhITkEvQU5BTXRvUTJ2d0w5OUpvcHRwdUk2Rzk4S3VsbkloTklT?= =?utf-8?Q?pha3LGyh721eEtaE=3D?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f4fd434-fce3-4629-0185-08df1587f681 X-MS-Exchange-CrossTenant-AuthSource: DU0PR08MB8470.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2026 13:23:01.1739 (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: HIdPSAzfZ3FRXdfN8lsrPN2oKOr85oYenZcPkmGHnrJ/18gHO7ZMRPZMrbU4ESApn0vO4fnGc0WJfWvvi9cRzqegpzbFM9mQzp8LxbuBCbo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5531 X-OZ-Fwd: true Subject: Re: [Devel] [PATCH VZ10 v9 2/8] ve/fs: Rework per-ve mount count 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: > Previous approach with current mounts counter had an issue: > there was a gap between ve_mount_allowed check and ve_mount_nr_inc, > which could allow CT to have more mounts than expected. > > Fix this by tracking the number of available mounts instead > of current ones. This also makes resources accounting > more consistent - we are using ***_avail_nr approach more. > > One more issue with inconsistent ve value is fixed: > ve_mount_allowed always used ve from get_exec_env, but > ve_mount_nr_inc operated with owner_ve. > Now actual ve value is calculated in the beginning of alloc_vfsmnt. > > To avoid incorrect accounting when is_pseudosuper is changed, > update avail_nr count without > 0 check if VE is ve0 or pseudosuper. > This also simplifies ve_mount_put, since increment is > now unconditional. > > https://virtuozzo.atlassian.net/browse/VSTOR-135520 > > Feature: per-ve failcounters > Signed-off-by: Vladimir Riabchun > --- > fs/namespace.c | 78 ++++++++++++++++++++++++++++------------------ > include/linux/ve.h | 2 +- > kernel/ve/ve.c | 12 +++---- > 3 files changed, 54 insertions(+), 38 deletions(-) > > diff --git a/fs/namespace.c b/fs/namespace.c > index 4adc1db84b4c..1d6e66cd7174 100644 > --- a/fs/namespace.c > +++ b/fs/namespace.c > @@ -317,19 +317,22 @@ int mnt_get_count(struct mount *mnt) > #endif > } > > -static inline int ve_mount_allowed(void); > -static inline void ve_mount_nr_inc(struct mount *mnt, struct ve_struct *ve); > -static inline void ve_mount_nr_dec(struct mount *mnt); > +static inline int ve_try_reserve_mount(struct ve_struct *ve); > +static inline void ve_mount_put(struct mount *mnt, struct ve_struct *ve); > static inline void ve_mount_reown(struct mount *mnt, struct ve_struct *ve); > > static struct mount *alloc_vfsmnt(const char *name, struct ve_struct *owner_ve) > { > struct mount *mnt; > + struct ve_struct *ve = owner_ve; > > - if (!ve_mount_allowed()) { > + if (!ve) > + ve = get_exec_env(); > + > + if (!ve_try_reserve_mount(ve)) { > pr_warn_ratelimited( > "CT#%s reached the limit on mounts.\n", > - ve_name(get_exec_env())); > + ve_name(ve)); > return NULL; > } > > @@ -337,6 +340,14 @@ static struct mount *alloc_vfsmnt(const char *name, struct ve_struct *owner_ve) > if (mnt) { > int err; > > +#ifdef CONFIG_VE > + /* > + * Got ve reference in ve_try_reserve_mount, set mnt ve data > + * here, so in case of error ve_mount_put sees correct info. > + */ > + mnt->ve_owner = ve; > +#endif > + > err = mnt_alloc_id(mnt); > if (err) > goto out_free_cache; > @@ -371,7 +382,8 @@ static struct mount *alloc_vfsmnt(const char *name, struct ve_struct *owner_ve) > INIT_LIST_HEAD(&mnt->mnt_umounting); > INIT_HLIST_HEAD(&mnt->mnt_stuck_children); > mnt->mnt.mnt_idmap = &nop_mnt_idmap; > - ve_mount_nr_inc(mnt, owner_ve); > + } else { > + ve_mount_put(mnt, ve); > } > return mnt; Sashiko says: In the function alloc_vfsmnt, can the decrement in ve_try_reserve_mount be invalid if the 'mnt_alloc_id' fails subsequently? This logic might lead to an incorrect mount count when the ve or the mount fails. No, it can't. Passing ve_try_reserve_mount means mnt_avail was updated, so on error path we must unconditionally increment it back. > > @@ -382,6 +394,8 @@ static struct mount *alloc_vfsmnt(const char *name, struct ve_struct *owner_ve) > out_free_id: > mnt_free_id(mnt); > out_free_cache: > + /* Got ve reference in ve_try_reserve_mount */ Sashiko says: The comment suggests that ve_mount_put sees a non-null mount in an error case, however, in test scenarios, isn't it possible for the ve to be incorrect? No. ve is always correct, mnt = NULL is handled correctly by ve_mount_put. > + ve_mount_put(mnt, ve); > kmem_cache_free(mnt_cache, mnt); > return NULL; > } > @@ -751,7 +765,9 @@ int sb_prepare_remount_readonly(struct super_block *sb) > static void free_vfsmnt(struct mount *mnt) > { > mnt_idmap_put(mnt_idmap(&mnt->mnt)); > - ve_mount_nr_dec(mnt); > +#ifdef CONFIG_VE > + ve_mount_put(mnt, mnt->ve_owner); > +#endif > kfree_const(mnt->mnt_devname); > #ifdef CONFIG_SMP > free_percpu(mnt->mnt_pcp); > @@ -3214,7 +3230,7 @@ int ve_devmnt_process(struct ve_struct *ve, dev_t dev, void **data_pp, int remou > if (devmnt->dev == dev) { > err = ve_devmnt_check(data, devmnt->allowed_options); > /* > - * In case of @is_pseudouser set, ie restore procedure, > + * In case of @is_pseudosuper set, ie restore procedure, > * we don't check for allowed options filtering, since > * restore mode is special. > */ > @@ -3353,30 +3369,30 @@ int ve_devmnt_verify(struct ve_struct *ve, dev_t dev, char *opts, bool new_mount > return err; > } > > -static inline int ve_mount_allowed(void) > -{ > - struct ve_struct *ve = get_exec_env(); > - > - return ve_is_super(ve) || ve->is_pseudosuper || > - atomic_read(&ve->mnt_nr) < (int)sysctl_ve_mount_nr; > -} > - > -static inline void ve_mount_nr_inc(struct mount *mnt, struct ve_struct *ve) > +static inline int ve_try_reserve_mount(struct ve_struct *ve) > { > - if (!ve) > - ve = get_exec_env(); > + int ret = ve_is_super(ve) || ve->is_pseudosuper; > + /* Ignore limits in ve0 and pseudosuper cases, but still count. */ > + if (ret) > + atomic_dec(&ve->mnt_avail_nr); > + else > + ret = atomic_dec_if_positive(&ve->mnt_avail_nr) >= 0; Sashiko says: Is there a chance that, in ve_try_reserve_mount, the return logic misleads the condition when ve is either ve0 or pseudosuper, thus bypassing necessary checks? This counting might allow unexpected mounts while avoiding constraints. We want to ignore avail checks in ve0 and pseudosuper case. > > - mnt->ve_owner = get_ve(ve); > - atomic_inc(&ve->mnt_nr); > + if (ret) > + get_ve(ve); > + return ret; > } > > -static inline void ve_mount_nr_dec(struct mount *mnt) > +static inline void ve_mount_put(struct mount *mnt, struct ve_struct *ve) > { > - struct ve_struct *ve = mnt->ve_owner; > - > - atomic_dec(&ve->mnt_nr); > + /* > + * ve argument is needed to reuse this function in alloc_vfsmnt error path. > + * Other users should pass mnt->ve_owner value. > + */ > + atomic_inc(&ve->mnt_avail_nr); Sashio says: The unconditional increment in ve_mount_put may cause unintended changes in mnt_avail_nr when ve conditions are different. Could this result in inaccurate resource tracking? No, ve_mount_put is called only when ve_try_reserve_mount is 1. It means it decremented avail counter. > put_ve(ve); > - mnt->ve_owner = NULL; > + if (mnt) > + mnt->ve_owner = NULL; > } > > ... -- Best regards, Riabchun Vladimir Linux Kernel Developer, Virtuozzo _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel