[CRIU] [PATCHv2 1/9] compat/vDSO/restorer: flush rt symtable from criu

[Dmitry Safonov]

What's happening here:
- rt_symtable is filled in criu on init
- in restorer we map compatible vDSO blob and refilling rt_symtable
  (in case of restoring 32-bit application)
- compatible and native symtables may (and it's very likely) have
  different symbols
- the symtable's values for symbols which are present in native vDSO,
  but absent in compatible vdso will be preserved from criu's process
  (which is not right)
- if saved compat vDSO blob has some symbols, which has native vDSO, but
  does not have compat restorer's blob, they may confuse restorer

Impact: re-init rt symtable for compatible tasks in restorer.

While, I belive I will optimize this out in future by filling
compatible symtable (and thus, making two rt symtabs) on criu init,
yet fix this by reinitialization.

Cc: Cyrill Gorcunov <gorcunov at openvz.org>
Signed-off-by: Dmitry Safonov <dsafonov at virtuozzo.com>
---
 criu/pie/parasite-vdso.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/criu/pie/parasite-vdso.c b/criu/pie/parasite-vdso.c
index f838f826d24c..c51a11b9236e 100644
--- a/criu/pie/parasite-vdso.c
+++ b/criu/pie/parasite-vdso.c
@@ -80,7 +80,7 @@ int vdso_map_compat(unsigned long map_at, unsigned long park_size,
 		struct vdso_symtable *sym_rt)
 {
 	unsigned long search_vdso;
-	int ret;
+	int i, ret;
 
 	pr_debug("Mapping compatible vDSO at %lx\n", map_at);
 
@@ -88,6 +88,9 @@ int vdso_map_compat(unsigned long map_at, unsigned long park_size,
 	if (ret)
 		return ret;
 
+	for (i = 0; i < VDSO_SYMBOL_MAX; i++)
+		sym_rt->symbols[i].offset = VDSO_BAD_ADDR;
+
 	/*
 	 * We could map VVAR firstly, or VDSO.
 	 * Try to find VDSO pages in this couple of parking pages.
-- 
2.9.0