[Devel] [PATCH VZ10 6/8] ve/unshare: allow CLONE_NEWVE with other namespace flags

[Pavel Tikhomirov]

The check_unshare_flags() previously rejected CLONE_NEWVE in combination
with anything other than CLONE_NEWUSER. The justification was that
get_exec_env() still returned the previous ve while unshare was creating
new mount and network namespaces, so their ->owner_ve / ve_owner links
would point at the wrong ve. The previous patch fixes that by threading
the freshly allocated ve_namespace from unshare_ve_namespace() down to
copy_mnt_ns() and copy_net_ns() via unshare_nsproxy_namespaces(), so
the guard is no longer needed.

Drop it. unshare(CLONE_NEWUSER | CLONE_NEWVE | CLONE_NEWNS |
CLONE_NEWNET | ...) now works in a single syscall and the resulting
namespaces are owned by the new ve.

https://virtuozzo.atlassian.net/browse/VSTOR-129744
Signed-off-by: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>
Feature: ve: ve generic structures
---
 kernel/fork.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index a1b9fec27579..dfd074a794b5 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -3237,20 +3237,6 @@ static int check_unshare_flags(unsigned long unshare_flags)
 			return -EINVAL;
 	}
 
-	/*
-	 * Unshare creates all namespaces first and only then switches to them.
-	 * So get_exec_env() yet returns previous VE while we are creating
-	 * other namespaces. That leads to network and mount namespace
-	 * initialized incorrectly, having ->owner_ve links set to previous VE.
-	 * To avoid confusion, only allow CLONE_NEWVE together with CLONE_NEWUSER.
-	 * CLONE_NEWUSER is allowed as it should own VE namespace, not vice versa.
-	 */
-	if (unshare_flags & CLONE_NEWVE) {
-		unsigned long allowed_with_ve = CLONE_NEWVE | CLONE_NEWUSER;
-		if (unshare_flags & ~allowed_with_ve)
-			return -EINVAL;
-	}
-
 	return 0;
 }
 
-- 
2.53.0