[CRIU] Re: [PATCH 09/10] tty: Introduce deferred dumping of tty peers

[Cyrill Gorcunov]

On Sat, Oct 27, 2012 at 12:21:40AM +0400, Cyrill Gorcunov wrote:
> On Sat, Oct 27, 2012 at 12:18:45AM +0400, Pavel Emelyanov wrote:
> > On 10/27/2012 12:16 AM, Cyrill Gorcunov wrote:
> > > On Sat, Oct 27, 2012 at 12:15:23AM +0400, Pavel Emelyanov wrote:
> > >>> Thus when we start dumping ptmx peer (which belongs to SCREEN)
> > >>> we've not yet constructed the process tree item for children
> > >>> (ie /bin/bash) and the lookup function in tty code (which walks
> > >>> over all process items in a tree) simply fails to find sid of
> > >>> child, because we've not yet dumped it.
> > >>
> > >> Are we talking about this code
> > >>
> > >>         if (pti->sid) {
> > >>                 struct pstree_item *item = find_first_sid(pti->sid);
> > >>                 if (!item || item->pid.virt != pti->sid) {
> > >>                         if (!opts.shell_job) {
> > >>                                 pr_err("Found sid %d pgid %d on slave peer fd %d. "
> > >>                                        "Missing option?\n",
> > >>                                        pti->sid, pti->pgrp, p->fd);
> > >>                                 return -1;
> > >>                         }
> > >>                 }
> > >>         }
> > >>
> > >> in dump_pty_info? The find_first_sid() finds nothing, right?
> > > 
> > > yeah, this is main problem.
> > 
> > OK. Let's move forward. This find_first_sid() is required to make sure
> > that the session leader of tty's session is with us, correct?
> 
> Yes, exactly. We need to figure out if we manage to restore this peer.

Note the moment "item->pid.virt != pti->sid", the item->pid.virt get assigned
when we're dumping the particular task but in our case the master peer lays
upward in tree and when we start dumping it the item->pid.virt = -1 and we
fail.