[CRIU] Re: [PATCH 0/5] TTY c/r without controlling terminal

[Cyrill Gorcunov]

On Wed, Sep 12, 2012 at 05:38:25PM +0400, Pavel Emelyanov wrote:
> > +			if (fle->fe->fd == get_service_fd(CTL_TTY_OFF)) {
> > +				tty_restore_ctl_terminal(d);
> > +				close(fle->fe->fd);
> > +				continue;
> > +			}
> > +
> >  			fcntl(fle->fe->fd, F_SETFD, fle->fe->flags);
> >  
> >  			continue;
> > @@ -397,6 +422,11 @@ static int open_fd(int pid, FdinfoEntry *fe, struct file_desc *d)
> >  		}
> >  	}
> >  
> > +	if (fe->fd == get_service_fd(CTL_TTY_OFF)) {
> > +		tty_restore_ctl_terminal(d);
> > +		close(fe->fd);
> > +	}
> > +
> >  	close(sock);
> >  	return 0;
> >  }
> > @@ -423,6 +453,12 @@ static int receive_fd(int pid, FdinfoEntry *fe, struct file_desc *d)
> >  	if (reopen_fd_as(fe->fd, tmp) < 0)
> >  		return -1;
> >  
> > +	if (fe->fd == get_service_fd(CTL_TTY_OFF)) {
> > +		tty_restore_ctl_terminal(d);
> > +		close(fe->fd);
> > +		return 0;
> > +	}
> > +
> >  	fcntl(tmp, F_SETFD, fe->flags);
> >  	return 0;
> >  }
> 
> Why is this thing hangs in the generic code? What's wrong in having it in
> ->open/->post_open callbacks?

Look, say we have a master fd=100 and we hook our controlling terminal fd=1020
on same @fd_info_head (both fd has same id and type thus they will be chained
on @fdesc->fd_info_head).

Depending which pid is lesser we might either call open_fd on fd=1020 and send fd=100
via scm to a task which pid match. For this case we do restore ctl-tty inside
open-fd file engine code. Another case is when we first open fd for fd=100 but
send fd for fd=1020, thus we need to handle ctl tty in receive_fd code. And
last case is where both fd=1020 and fd=100 belong to same pid, for this case
we handle ctl tty inside open_fd &d->fd_info_head loop.

I could move some code to post_open callback but this won't cover all cases.
Again, if only I've not missed something in our file-engine.

	Cyrill