[Devel] [PATCH RHEL10 COMMIT] ve/cgroup: expose ve.mnt_nr cgroup file

[Konstantin Khorenko]

The commit is pushed to "branch-rh10-6.12.0-55.52.1.5.x.vz10-ovz" and will appear at git at bitbucket.org:openvz/vzkernel.git
after rh10-6.12.0-55.52.1.5.24.vz10
------>
commit 3443a4a41fc13e1daea5420d78a603ba29508136
Author: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
Date:   Wed Apr 29 15:41:41 2026 +0200

    ve/cgroup: expose ve.mnt_nr cgroup file
    
    Expose the existing per-ve atomic ve->mnt_nr counter as a read-only
    ve.mnt_nr cgroup file, alongside ve.netns_avail_nr.
    
    The counter is bumped/decremented by ve_mount_nr_inc/dec for every
    mount accounted to this ve; until now it was only readable from
    kernel space. Exposing it lets userspace and selftests observe per-ve
    mount accounting for diagnostics and regression coverage of
    clone(CLONE_NEWVE | CLONE_NEWNS) ownership wiring.
    
    https://virtuozzo.atlassian.net/browse/VSTOR-129744
    Signed-off-by: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
    Reviewed-by: Vasileios Almpanis <vasileios.almpanis at virtuozzo.com>
    
    Feature: ve: ve generic structures
    ======
    Patchset description:
    ve: fix owner_ve of net/mnt namespaces created together with CLONE_NEWVE
    
    When CLONE_NEWVE is combined with CLONE_NEWNET and/or CLONE_NEWNS in a
    single clone3() or unshare(), copy_net_ns() and copy_mnt_ns() resolve
    the owning ve via get_exec_env(), which still points at the parent ve
    at that point. The freshly created net/mnt namespaces end up wired to
    the wrong ve, and unshare(CLONE_NEWVE | CLONE_NEW{NS,NET}) is rejected
    outright by check_unshare_flags().
    
    Fix it by threading the new ve from copy_namespaces() and
    unshare_nsproxy_namespaces() down into copy_net_ns() and copy_mnt_ns(),
    so the correct ve is charged for the new netns and for every mount in
    the new mntns.
    
    Patches 1-4 are pure plumbing (signature changes, no behaviour change).
    Patch 5 is the actual fix that forwards the new ve. Patch 6 drops the
    now-redundant CLONE_NEWVE-alone restriction in check_unshare_flags().
    Patch 7 exposes ve.mnt_nr via cgroupfs to make per-ve mount accounting
    observable from userspace. Patch 8 adds a selftest covering both the
    clone3() and unshare() paths.
    
    Verified with crash on a vzctl-started container: task_ve,
    nsproxy->net_ns->owner_ve, nsproxy->mnt_ns->ve_owner and
    nsproxy->mnt_ns->root.ve_owner all resolve to the new ve.
    The new selftest passes both cases.
---
 kernel/ve/ve.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/kernel/ve/ve.c b/kernel/ve/ve.c
index 106fc225c60de..198c82f010cc1 100644
--- a/kernel/ve/ve.c
+++ b/kernel/ve/ve.c
@@ -1276,6 +1276,11 @@ static u64 ve_netns_avail_nr_read(struct cgroup_subsys_state *css, struct cftype
 	return atomic_read(&css_to_ve(css)->netns_avail_nr);
 }
 
+static u64 ve_mnt_nr_read(struct cgroup_subsys_state *css, struct cftype *cft)
+{
+	return atomic_read(&css_to_ve(css)->mnt_nr);
+}
+
 static u64 ve_netif_max_nr_read(struct cgroup_subsys_state *css, struct cftype *cft)
 {
 	return css_to_ve(css)->netif_max_nr;
@@ -1762,6 +1767,10 @@ static struct cftype ve_cftypes[] = {
 		.name			= "netns_avail_nr",
 		.read_u64		= ve_netns_avail_nr_read,
 	},
+	{
+		.name			= "mnt_nr",
+		.read_u64		= ve_mnt_nr_read,
+	},
 	{
 		.name			= "netif_max_nr",
 		.flags			= CFTYPE_NOT_ON_ROOT,