[Devel] [RFC rh7 v4] ve/tty: vt -- Implement per VE support for console and terminals

[Cyrill Gorcunov]

On Mon, Aug 24, 2015 at 01:34:18PM +0300, Vladimir Davydov wrote:
> 
> Yes, please. Let's make vtty_lookup slave-only. This way the code will
> be easier to understand IMO.

Done already, gonna send new version soon.

> > > 2. What's the point in checking TTY_HUPPING and TTY_LDISC_CHANGING for
> > >    'tty->link'? We are opening 'tty' here.
> > 
> > Because if the link is started hupping or changing line discipline
> > there is no much sence to return such pair, it's almost dead. Simply
> > notify the user that there is no such tty present at moment and make
> > it repeat the attempt.
> 
> Why does the generic lookup method (tty_driver_lookup_tty), which is
> used e.g. by legacy pty, not check that then?

Because it's generic method. It should not do such things. In tty_reopen
it test only for own pair end bits because it doesn't know what is allowed
and what is not for particular driver: such things are left to the driver
itself. Anyway I reworked this moment and while I still think that testing
both ends for all three bits is good idea lets stick with pcs6 scheme
and test for closing only. I'll show in next patch which is upcoming.

> > 
> > Which gives you a way to spam the kernel. Simply start open/close ttys
> > in a cycle and there is a small window which allow to create more than
> > 12 ttys as far as I can tell.
> 
> Why is it bad?

Because it's a way for dos. I dropped off this idea but rather
switch to pcs6 scheme where only one master can be opened from the
node (opening from the container does check for exiting on its own
as you mentioned already) and we zap exiting pair in vtty map and
allocate a new one.

> > Instead with the approach above we don't allow to open pair while
> > previous session is not complete. Am I wrong?
> 
> If a process inside a container closes and then immediately reopens a
> vtty, it does not expect to get -EIO simply because it is advancing too
> fast.

How it that? I mean, application (getty and such) always care about eio
and such things. moreover if we would have a real hardware such as one of
uart chip under us, instead of pseudoemulation layer as it now, receiving
eio due to line problem is perfectly valid here, so that application using
terminals must be ready to receive any kind of io errors (and it does
actually). But this is a side word -- I dropped this code, if we don't
find usable vtty (it's exiting) we allocate new pair. There is still
a tiny small dos window but to use it one have to be node's admin
so it's safe from container's pov.