[CRIU] implementing some kind of --leave-frozen option for c/r in CRIU

[Andrew Vagin]

On Wed, May 18, 2016 at 11:47:01AM -0700, Tycho Andersen wrote:
> On Tue, May 17, 2016 at 10:20:42AM -0700, Andrew Vagin wrote:
> > The profit from this approach is that:
> > * we can unlock network very fast and don't need to enumerate sockets
> >   for that.
> 
> Hmm, actually on a closer look, don't we still need to turn off
> TCP_REPAIR for each socket? So we don't need to do
> rst_unlock_tcp_connections(), but we still need
> cpt_unlock_tcp_connections()?

Yes, you are right. And here is an answer why we can't just remove
iptables rules to unlock network. After unlocking network, we need to
disable repair mode on tcp sockets, because they send window probes at
this moment. If we will not send these probes, tcp connection will stuck
in most cases.

pie/restorer.c
        /* Unlock network before disabling repair mode on sockets */
        network_unlock();

net/ipv4/tcp.c:
        case TCP_REPAIR:
                if (!tcp_can_repair_sock(sk))
                        err = -EPERM;
                else if (val == 1) {
                        tp->repair = 1;
                        sk->sk_reuse = SK_FORCE_REUSE;
                        tp->repair_queue = TCP_NO_QUEUE;
                } else if (val == 0) {
                        tp->repair = 0;
                        sk->sk_reuse = SK_NO_REUSE;
                        tcp_send_window_probe(sk);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

All these mean that we need to resume processes from criu, because it
isn't a trivial operation.

> 
> Tycho