Quoting Dan Smith (danms@xxxxxxxxxx):
> >> + else if (!ckpt_obj_lookup(ctx, peer->nd_net, CKPT_OBJ_NET_NS)) {
> >> + ret = -EINVAL;
> >> + ckpt_err(ctx, ret,
> >> + "Peer %s of %s not in checkpointed namespaces\n",
> >> + peer->name, dev->name);
>
> SH> I'm not sure this check does what you think it does: note that
> SH> ckpt_netdev_base(), defined in the previous patch, and called
> SH> higher up in this function, is going to checkpoint peer->nd_net.
> SH> :)
>
> Actually, no, ckpt_netdev_base() can't checkpoint peer->nd_net because
> it's device-agnostic and has no knowledge of dev->peer.
Oh, ok.
> The idea here was that we checkpoint a netns when we arrive at it via
> nsproxy. Doing that, we checkpoint the devices within. We encounter
> a veth device, which has a peer, so we decide if:
>
> 1. We won't arrive at the peer later because it is in the init
> namespace, so we checkpoint it now.
> 2. We will arrive at it later because the peer's netns is in the list
> we've already collected, so checkpoint the peer with its namespace
> 3. Neither are true and we won't arrive at it later and therefore we
> can't allow checkpoint to continue
>
> #2 depends on the collect process having put all the task's netns' in
> the hash ahead of time.
Right, that was what I was originally starting to hunt down when I
thought I saw ckpt_netdev_base() checkpointing peer's netns.
So do you actually know that the peer's netns will have been
checkpointed? I'm a little fuzzy about where netns and netdevs
are checkpointed. If you have two private netns's in a container,
with a veth connecting them, and you checkpoint a task in netns 1,
will you fail bc netns 2 hasn't been checkpointed yet bc no task in
it has been checkpointed yet?
-serge
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
