[Devel] Re: [PATCH RFC] c/r mounts ns. Except not really.

[Oren Laadan]

Serge E. Hallyn wrote:
> Quoting Serge E. Hallyn (serue at us.ibm.com):
>> We only c/r a mounts ns with objref 0, meaning inherit the existing
>> mounts ns.  We do intend to implement c/r of mounts and mounts
>> namespaces in the kernel.  It shouldn't be ugly or complicate locking
>> to do so.  Just haven't gotten around to it.
>>
>> Why did I bother with this?  Because we can't re-create private
>> mounts yet, and while I don't expect trouble doing so, I think
>> it's more than we want to take on now for v19.  But I'd like
>> as much as possible for everything which we don't support, to not
>> be checkpointable, since not doing so has in the past invited
>> slanderous accusations of being a toy implementation  :)
>>
>> Comments?

This seems to me like the proper intermediary step.

>>
>> Signed-off-by: Serge E. Hallyn <serue at us.ibm.com>

[...]

>> @@ -2323,3 +2324,37 @@ void put_mnt_ns(struct mnt_namespace *ns)
>>  	kfree(ns);
>>  }
>>  EXPORT_SYMBOL(put_mnt_ns);
>> +
>> +#ifdef CONFIG_CHECKPOINT
>> +int checkpoint_mounts_ns(struct ckpt_ctx *ctx, struct mnt_namespace *mnt_ns)
>> +{
>> +	if (mnt_ns == ctx->root_nsproxy->mnt_ns)
>> +		return 0;

As you mention below, this should be CKPT_MNT_NS_INHERIT.

> 
> Technically note that this is not even correct.  If the container
> being checkpointed had a mnt_ns private from its parents, then
> it could have its own mounts which are not checkpointed (and therefore
> can't even be generically restored by userspace).  So really this should
> be returning 0 (which should be CKPT_MNT_NS_INHERIT) only if mnt_ns
> == ctx->root_task->parent->nsproxy->mnt_ns (requiring more careful
> dereferencing since we don't have it pinned).
> 
> Whatever we do here for v19, I intend to do the same thing for
> network devices for v19.  The question is, are we being unprofessional,
> or are we being useful+flexible, by simply ignoring these things at
> checkpoint when we know we won't restore them?

IIRC we agreed that so-called "external" mounts - whatever is mounted
at the root of the container is the responsibility of userspace to have
prepared properly before restart.

So I don't see an issue with ignoring these at checkpoint, with one
exception: leak detection in full-container checkpoint should complain
if the root container fs is shared with parent (above container) tasks.

I think about it this way: at checkpoint, we care about container (or
checkpoint) root and below. Then at restart, we should decide whether
the root task (of the restore) should inherit its initial FS, or
whether it should start with a private one.

Recall that we had/have this dilemma also with UTS namespace, and with
IPC namespace.

Here is one way to do it:  (consider ipc-ns) at checkpoint, for the
kernel will compare every task's ipc-ns to the container's _parent_'s
ipc-ns, and if equal will save CKPT_OBJ_NS_INHERIT. If --inherit-ipc
is given, it will not the state of the parent's namespace, otherwise
it will.

At restart, if --inherit-ipc then whenever the kernel sees objref
that is CKPT_OBJ_NS_INHERIT, it will use the container's parent's
ipc-ns. Otherwise, it will create a new, private namespace for it.
(Also, with --inherit-ipc, if there is namespace state following
the CKPT_OBJ_NS_INHERIT, it should skip it without using it).

Oren.

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers