[Devel] Re: [RFC][PATCH 3/3] c/r: [pty 2/2] support for pseudo terminals

[Serge E. Hallyn]

Quoting Oren Laadan (orenl at librato.com):
> 
> 
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (orenl at librato.com):
> >> Thanks for the patches (the first was already in). I'll leave
> >> out the change to signed type, though.
> > 
> > Yup, "oops".
> > 
> >> Serge E. Hallyn wrote:
> >>> All right, I'm not sure how to go about this - i want to have a conversation
> >>> involving patches without making it seem like I want any of the patches
> >>> pushed yet :)  To get this working on s390, I needed the two attached
> >>> patches.  Then the testcase under git://git.sr71.net/~hallyn/cr_tests.git
> >>> under cr_tests/pty/ passes with your code.
> >>>
> >>> I'd still like to get a more invasive approach working where we directly
> >>> ask the pty code to create the pty with the right index.  I'm playing with
> >>> it right now, but of course having some trouble figuring out what to do
> >>> for the master end and how best to construct a filp to pass to
> >>> the main pty_create function.  I'll take a few more stabs and send out
> >>> what I have later (or announce defeat).
> >>>
> >>> There is certainly something to be said for the un-invasiveness of
> >>> your approach (and that it works).
> >>>
> >>> In either case, we will need to figure out how to deal with devpts
> >>> namespaces.  Perhaps we separately checkpoint a 'devpts_mnt'.  It
> >>> just stores the mountpoint of the mount.  At restart, we don't
> >>> recreate those, we just confirm that the mountpoints still exist.
> >>> Then, each pty entry has a ref to its devpts mount, and we use the
> >>> mountpoint to construct ${mountpoint}/ptmx and pass that to
> >>> filp_open() or ptmx_create)( to create the pty entry.
> >> Yes, I was thinking along these lines. I think it's very much
> >> related to the whole mount-namespaces issues; I guess it's time
> >> to address both.
> > 
> > Ooooh, I'm not sure it is :)  In fact my approach to devpts should
> > artfully avoid having to address generic mounts namespaces :)
> 
> lol .. I suppose I misinterpreted then. Perhaps you can take a
> stab at it ?

Sure, should be pretty simple.  May wait until next week though,
if only to wait for comments on the requested_id vs. ptmx_create().

OTOH - if we're going to consider spitting out full mountinfo in
the ckpt image (per below), then I'll wait until we've discussed
that more too.

> > Well, if we *were* to address mountsns now, I'd suggest we simply
> > store meaningful /proc/pid/mountinfo data for each task in the
> > checkpoint image, and just verify it at restart, returning error
> > if they're not the same.  That way we can continue to defer
> > the decision on whether mktree or the kernel will restore mounts.
> 
> What is "meaningful" data, and how would you "verify" it ?

Meaningful data is, for each task,
	mount ns id
	for each mount,
		mount source, targets, types, propagation (peer group
		and relation to it).
Also for the container init, whether its netns is shared with its
parent, and any mounts which are new in it over its parent.

> At restart the mount data may be substantially (and intentionally)
> different. For instance, what used to be a local mount at checkpoint
> may be an NFS mount at restart....

Yup.  OTOH if a task in the container did
	'mount --bind dataset.bak/b dataset/a'
then that should be safe to repeat.

Whereas the nfs mount presumably is for the whole job's fs, which
likely was not mounted by the job itself.

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