[Devel] [PATCH rh8 14/28] ve/kmod/whitelist: Add modules to whitelist for c/r sake

[Konstantin Khorenko]

From: Cyrill Gorcunov <gorcunov at virtuozzo.com>

When doing checpoint/restore during migration we use netlink
sockets with diag functionality to fetch various information
we need. In particular when restoring on the machine where
say netfilter modules are not loaded we fail with

 | [root at s175 ~]# less /vz/dump/rst-iVS9OC-16.05.04-22.32/criu_restore.11.log
 | (00.151066)      1:     Running ip addr restore
 | RTNETLINK answers: File exists
 | RTNETLINK answers: File exists
 | (00.152641)      1:     Running ip route restore
 | (00.175144)      1:     Running ip route restore
 | (00.184676)      1:     Running ip rule delete
 | (00.186448)      1:     Running ip rule delete
 | (00.188191)      1:     Running ip rule delete
 | (00.190054)      1:     Running ip rule restore
 | (00.191964)      1:     Running iptables-restore for iptables-restore
 | (00.200958)      1:     Running ip6tables-restore for ip6tables-restore
 | >(00.203833)      1: Error (net.c:466): Can't open rtnl sock for net dump: Protocol not supported
 | (00.229107) Error (cr-restore.c:1407): 15091 killed by signal 9: Killed
 | (00.229192) Switching to new ns to clean ghosts
 | (00.241142) uns: calling exit_usernsd (-1, 1)
 | (00.241173) uns: daemon calls 0x454950 (15085, -1, 1)
 | (00.241188) uns: `- daemon exits w/ 0
 | (00.241570) uns: daemon stopped
 | (00.241584) Error (cr-restore.c:2248): Restoring FAILED

which stands for the following criu code

 |  	sk = socket(AF_NETLINK, SOCK_RAW, NETLINK_NETFILTER);
 |  	if (sk < 0) {
 |  		pr_perror("Can't open rtnl sock for net dump");
 |  		goto out_img;
 |  	}

because the nfnetlink module is not loaded on the destination machine
we're failing. If we would have been running on node the module would
be uploaded automatically but restore happens in veX context where modules
can't be uploaded.

Thus add modules needed for c/r into whitelist, so the criu will
upload them automatically.

https://jira.sw.ru/browse/PSBM-46789

CC: Vladimir Davydov <vdavydov at virtuozzo.com>
CC: Konstantin Khorenko <khorenko at virtuozzo.com>
CC: Andrey Vagin <avagin at openvz.org>
CC: Pavel Emelyanov <xemul at virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcunov at virtuozzo.com>

+++
ve/kmod: Change modules whitelist to fit their aliases

When we do call for specifed sockets such as netlink netfilter,
dialog sockets and such we imply that the kernel will autoload
them. But previously (e0914131eeb08e6b1953c682be05b9fbcf185f1f
"ve/kmod: Add modules to whitelist for c/r sake")
I put module names instead of their alises used in net subsystem
to determinate which module to load on socket/protocol types.

Fix it putting proper names here.

Thanks to Vladimir to point the problem.

https://jira.sw.ru/browse/PSBM-46789

CC: Konstantin Khorenko <khorenko at virtuozzo.com>
CC: Andrey Vagin <avagin at openvz.org>
CC: Pavel Emelyanov <xemul at virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcunov at virtuozzo.com>
Reviewed-by: Vladimir Davydov <vdavydov at virtuozzo.com>

+++
ve/kmod: Allow netfilter conntrack inside VE

Netfilter conntrack module is used during checkpoint (which
is done on node) so the modules get autoloaded but in case
of migration the restore starts inside veX so we need to allow
the conntrack to be requested from ve context. Thus add them
into whitelist.

Initially missed them in ebc70d73717f592c89ad992f77587d9e118bbee6.

https://jira.sw.ru/browse/PSBM-47359

CC: Vladimir Davydov <vdavydov at virtuozzo.com>
CC: Konstantin Khorenko <khorenko at virtuozzo.com>
CC: Andrey Vagin <avagin at openvz.org>
CC: Pavel Emelyanov <xemul at virtuozzo.com>
Signed-off-by: Cyrill Gorcunov <gorcunov at virtuozzo.com>

https://jira.sw.ru/browse/PSBM-127787

(cherry picked from vz7 commit 7d9c655b08b4397fc04430540fdbc763e56beacb)
Signed-off-by: Konstantin Khorenko <khorenko at virtuozzo.com>
---
 kernel/kmod.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/kernel/kmod.c b/kernel/kmod.c
index 0edf2abd1362..0848a0302b23 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -236,6 +236,31 @@ static const char * const ve0_allowed_mod[] = {
 
 	"fs-binfmt_misc",
 	"fs-overlay",
+
+	/* inet_diag, inet6_diag  */
+	"net-pf-16-proto-4-type-2",	/* PF_NETLINK, NETLINK_SOCK_DIAG, AF_INET */
+	"net-pf-16-proto-4-type-10",	/* PF_NETLINK, NETLINK_SOCK_DIAG, AF_INET6 */
+
+	/* tcp_diag */
+	"net-pf-16-proto-4-type-2-6",	/* PF_NETLINK, NETLINK_SOCK_DIAG, AF_INET - IPPROTO_TCP */
+
+	/* udp_diag */
+	"net-pf-16-proto-4-type-2-17",	/* PF_NETLINK, NETLINK_SOCK_DIAG, AF_INET - IPPROTO_UDP */
+	"net-pf-16-proto-4-type-2-136",	/* PF_NETLINK, NETLINK_SOCK_DIAG, AF_INET - IPPROTO_UDPLITE */
+
+	/* nfnetlink  */
+	"net-pf-16-proto-12",		/* PF_NETLINK, NETLINK_NETFILTER */
+	"nfnetlink-subsys-1",		/* NFNL_SUBSYS_CTNETLINK */
+	"nfnetlink-subsys-2",		/* NFNL_SUBSYS_CTNETLINK_EXP */
+
+	/* unix_diag */
+	"net-pf-16-proto-4-type-1",	/* PF_NETLINK, NETLINK_SOCK_DIAG, AF_LOCAL */
+
+	/* af_packet_diag */
+	"net-pf-16-proto-4-type-17",	/* PF_NETLINK, NETLINK_SOCK_DIAG, AF_PACKET */
+
+	/* netlink_diag */
+	"net-pf-16-proto-4-type-16",	/* PF_NETLINK, NETLINK_SOCK_DIAG, AF_NETLINK */
 };
 
 /*
-- 
2.28.0