The commit is pushed to "branch-rh8-4.18.0-240.1.1.vz8.5.x-ovz" and will appear
at https://src.openvz.org/scm/ovz/vzkernel.git
after rh8-4.18.0-240.1.1.vz8.5.35
------>
commit b7204691875013e109d250519edbe7ba8701156c
Author: Pavel Tikhomirov <[email protected]>
Date: Mon Jun 7 15:54:02 2021 +0300
ve: add a comment about possible pseudosuper race
Signed-off-by: Pavel Tikhomirov <[email protected]>
Reviewed-by: Kirill Tkhai <[email protected]>
(cherry-picked from vz7 commit fdac6d1dd408 ("ve: add a comment about
possible
pseudosuper race"))
To_merge: 96c59ccc5780 ("ve/cgroup: Add pseudosuper state for restore sake")
https://jira.sw.ru/browse/PSBM-127848
Signed-off-by: Valeriy Vdovin <[email protected]>
---
kernel/ve/ve.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/kernel/ve/ve.c b/kernel/ve/ve.c
index 350ff2990af5..12e91e6ee1a1 100644
--- a/kernel/ve/ve.c
+++ b/kernel/ve/ve.c
@@ -1228,6 +1228,18 @@ static int ve_pseudosuper_write(struct
cgroup_subsys_state *css, struct cftype *
return -EBUSY;
}
ve->is_pseudosuper = val;
+ /*
+ * In CRIU we do unset pseudosuper on ve cgroup just before doing
+ * ptrace(PTRACE_DETACH) to release restored process, what if one of
+ * them will see pseudosuper flag still set to 1?
+ *
+ * To be 100% sure that these will never happen we need to call
+ * synchronize_sched_expedited(); here to make cross cpu memory
+ * barrier.
+ *
+ * For now we rely on userspace that ptrace from CRIU will do wake-up
+ * on CT tasks which should imply memory barrier.
+ */
up_write(&ve->op_sem);
return 0;
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
