From: Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>
Subject: Re: [Devel] [PATCH VZ10 v6 4/9] selftests/ve: Update ve_ns_owner_test
Date: Wed, 19 Aug 2026 13:16:17 +0000 [thread overview]
Message-ID: <178714537779.798038.8769807417230186057.b4-review@b4> (raw)
In-Reply-To: <65c9774de3be1e5ae8ce8d613e54c1e7844935c4.1787129389.git.vladimir.riabchun@virtuozzo.com>
> Mount accounting interface has changed, now it shows the number
> of available mounts.
>
> https://virtuozzo.atlassian.net/browse/VSTOR-135520
>
> Feature: per-ve failcounters
> Signed-off-by: Vladimir Riabchun <vladimir.riabchun@virtuozzo.com>
>
> diff --git a/tools/testing/selftests/ve/ve_ns_owner_test.c b/tools/testing/selftests/ve/ve_ns_owner_test.c
> index 82c31dff4b1b..adcbc4051442 100644
> --- a/tools/testing/selftests/ve/ve_ns_owner_test.c
> +++ b/tools/testing/selftests/ve/ve_ns_owner_test.c
> @@ -18,7 +18,7 @@
> * with a new netns and mntns, the parent reads the new ve's counters
> * via cgroupfs and asserts they reflect the just-created namespaces:
> * - ve.netns_avail_nr drops by exactly one (the new netns);
> - * - ve.mnt_nr is strictly greater than zero (mounts copied into the
> + * - ve.mnt_avail_nr drops by exactly one (mounts copied into the
> * new mntns are accounted to the new ve).
Does it really drop by exactly one? If we copy mnt namespace, we copy
the whole mount tree not just one mount so we can possibly drop my more
than one.
> *
> * We never assert against the parent ve's counters: those are shared
> @@ -50,6 +50,7 @@
> * any spurious accounting against the parent ve would overflow it.
> */
> #define VE_NETNS_MAX 3
> +#define VE_MOUNTS_MAX 4096
>
> /*
> * Synchronisation across the clone() boundary: child does its setup,
> @@ -106,7 +107,7 @@ static int clone_child_func(void *arg)
> /*
> * Before fix:
> * - clone path: ve.netns_avail_nr stays at VE_NETNS_MAX and
> - * ve.mnt_nr stays at 0 because copy_net_ns()/copy_mnt_ns()
> + * ve.mnt_avail_nr stays at VE_MOUNTS_MAX because copy_net_ns()/copy_mnt_ns()
> * charged the parent ve via get_exec_env().
> * - unshare path: the syscall itself returned -EINVAL, so this
> * check was unreachable.
> @@ -117,16 +118,16 @@ static int clone_child_func(void *arg)
> static void check_new_ve_owner(struct __test_metadata *_metadata,
> int cgv2_fd, int ctid)
> {
> - unsigned long long avail, mnt;
> - char path[PATH_MAX];
> + unsigned long long avail_netns, avail_mnt;
> + char path[64];
>
> snprintf(path, sizeof(path), "%d/ve.netns_avail_nr", ctid);
> - ASSERT_EQ(read_u64_at(cgv2_fd, path, &avail), 0);
> - EXPECT_EQ(avail, VE_NETNS_MAX - 1);
> + ASSERT_EQ(read_u64_at(cgv2_fd, path, &avail_netns), 0);
> + EXPECT_EQ(avail_netns, VE_NETNS_MAX - 1);
>
> - snprintf(path, sizeof(path), "%d/ve.mnt_nr", ctid);
> - ASSERT_EQ(read_u64_at(cgv2_fd, path, &mnt), 0);
> - EXPECT_GT(mnt, 0);
> + snprintf(path, sizeof(path), "%d/ve.mnt_avail_nr", ctid);
> + ASSERT_EQ(read_u64_at(cgv2_fd, path, &avail_mnt), 0);
> + EXPECT_LT(avail_mnt, VE_MOUNTS_MAX);
> }
>
> FIXTURE(ve_ns_owner)
> @@ -137,7 +138,7 @@ FIXTURE(ve_ns_owner)
>
> FIXTURE_SETUP(ve_ns_owner)
> {
> - unsigned long long initial_mnt_nr;
> + unsigned long long initial_mnt_avail_nr;
> char val[16];
> char path[PATH_MAX];
>
> @@ -174,13 +175,13 @@ FIXTURE_SETUP(ve_ns_owner)
>
> /*
> * The new ve cgroup has not been entered by anything yet, so its
> - * mnt_nr counter must start at 0. Each test below verifies that
> + * mnt_avail_nr counter be VE_MOUNTS_MAX. Each test below verifies that
NIT: must be/ should be
--
Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>
next prev parent reply other threads:[~2026-08-19 13:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 9:07 [Devel] [PATCH VZ10 v6 0/9] Add per-VE failcount support Vladimir Riabchun
2026-08-19 9:07 ` [Devel] [PATCH VZ10 v6 1/9] ve/ve.{h, c}: Farewell to spaces as indents Vladimir Riabchun
2026-08-19 9:07 ` [Devel] [PATCH VZ10 v6 2/9] ve/namespace: Fix UAF in alloc_mnt_ns Vladimir Riabchun
2026-08-19 9:07 ` [Devel] [PATCH VZ10 v6 3/9] ve/fs: Rework per-ve mount count Vladimir Riabchun
2026-08-19 13:16 ` Vasileios Almpanis
2026-08-19 9:07 ` [Devel] [PATCH VZ10 v6 4/9] selftests/ve: Update ve_ns_owner_test Vladimir Riabchun
2026-08-19 13:16 ` Vasileios Almpanis [this message]
2026-08-19 9:07 ` [Devel] [PATCH VZ10 v6 5/9] ve: Move from global VE mounts limit to per-VE limit Vladimir Riabchun
2026-08-19 9:07 ` [Devel] [PATCH VZ10 v6 6/9] ve/ve.c: Generate VE resource accessors using macros Vladimir Riabchun
2026-08-19 9:07 ` [Devel] [PATCH VZ10 v6 7/9] ve: Introduce per-VE failcount Vladimir Riabchun
2026-08-19 13:16 ` Vasileios Almpanis
2026-08-19 9:07 ` [Devel] [PATCH VZ10 v6 8/9] selftests/ve: Add more helpers Vladimir Riabchun
2026-08-19 9:07 ` [Devel] [PATCH VZ10 v6 9/9] selftests/ve: Add mount accounting selftest Vladimir Riabchun
2026-08-19 13:16 ` Vasileios Almpanis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178714537779.798038.8769807417230186057.b4-review@b4 \
--to=vasileios.almpanis@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox