TTY: tty_port questions

Hi!

While moving UML's console driver to tty_port some strange things happened. So, I have a few questions. :-)

The original driver did not implement tty_operations->hangup(). If I implement it and call tty_port_hangup(), as Alan suggested, the login fails on all TTYs except tty0. It fails because the opened TTY returns EIO upon read()/write() after /bin/login called vhangup().

The call chain is: vhangup() -> tty_vhangup_self() -> tty_vhangup() -> __tty_hangup()

Within __tty_hangup() something happens that I don't fully understand:

if (cons_filp) { if (tty->ops->close) for (n = 0; n < closecount; n++) tty->ops->close(tty, cons_filp); } else if (tty->ops->hangup) (tty->ops->hangup)(tty);

Login on tty0 works because cons_filp is not NULL and tty->ops->close() is called. On the other hand login fails on every other TTY because cons_filp remains NULL and the TTY hangs up.

Is there something missing in my hangup function?

If I omit tty_operations->hangup() and leave it, like the old driver, NULL non-tty0 TTYs cannot be opened. (getty terminates immediately because it cannot open any TTY.) open() retuns -EIO because the TTY_CLOSING is set in tty->flags.

How can this be?

Quoted 31 lines

Hi!

While moving UML's console driver to tty_port some strange things happened. So, I have a few questions. :-)

The original driver did not implement tty_operations->hangup(). If I implement it and call tty_port_hangup(), as Alan suggested, the login fails on all TTYs except tty0. It fails because the opened TTY returns EIO upon read()/write() after /bin/login called vhangup().

The call chain is: vhangup() -> tty_vhangup_self() -> tty_vhangup() -> __tty_hangup()

Within __tty_hangup() something happens that I don't fully understand:

if (cons_filp) { if (tty->ops->close) for (n = 0; n < closecount; n++) tty->ops->close(tty, cons_filp); } else if (tty->ops->hangup) (tty->ops->hangup)(tty);

Login on tty0 works because cons_filp is not NULL and tty->ops->close() is called. On the other hand login fails on every other TTY because cons_filp remains NULL and the TTY hangs up.

Is there something missing in my hangup function?

If I omit tty_operations->hangup() and leave it, like the old driver, NULL non-tty0 TTYs cannot be opened. (getty terminates immediately because it cannot open any TTY.) open() retuns -EIO because the TTY_CLOSING is set in tty->flags.

Quoted 1 line

How can this be?

Hmm, it looks like some process is sitting on a TTY which was hung. And the system offers this hung TTY to others on further opens. Could you check that there is no process with open TTY after the vhangup?

Am 10.03.2012 23:51, schrieb Jiri Slaby:

Quoted 33 lines · Richard Weinberger

Quoted 31 lines

Hi!

While moving UML's console driver to tty_port some strange things happened. So, I have a few questions. :-)

The original driver did not implement tty_operations->hangup(). If I implement it and call tty_port_hangup(), as Alan suggested, the login fails on all TTYs except tty0. It fails because the opened TTY returns EIO upon read()/write() after /bin/login called vhangup().

The call chain is: vhangup() -> tty_vhangup_self() -> tty_vhangup() -> __tty_hangup()

Within __tty_hangup() something happens that I don't fully understand:

if (cons_filp) { if (tty->ops->close) for (n = 0; n < closecount; n++) tty->ops->close(tty, cons_filp); } else if (tty->ops->hangup) (tty->ops->hangup)(tty);

Login on tty0 works because cons_filp is not NULL and tty->ops->close() is called. On the other hand login fails on every other TTY because cons_filp remains NULL and the TTY hangs up.

Is there something missing in my hangup function?

If I omit tty_operations->hangup() and leave it, like the old driver, NULL non-tty0 TTYs cannot be opened. (getty terminates immediately because it cannot open any TTY.) open() retuns -EIO because the TTY_CLOSING is set in tty->flags.

Quoted 6 lines

Quoted 1 line

How can this be?

Hmm, it looks like some process is sitting on a TTY which was hung. And the system offers this hung TTY to others on further opens. Could you check that there is no process with open TTY after the vhangup?

"lsof | grep tty" does not show anything else than tty0. :-\

Am 11.03.2012 00:21, schrieb Richard Weinberger:

Quoted 41 lines

Am 10.03.2012 23:51, schrieb Jiri Slaby:

Quoted 39 lines · Richard Weinberger

Quoted 25 lines

Hi!

While moving UML's console driver to tty_port some strange things happened. So, I have a few questions. :-)

The original driver did not implement tty_operations->hangup(). If I implement it and call tty_port_hangup(), as Alan suggested, the login fails on all TTYs except tty0. It fails because the opened TTY returns EIO upon read()/write() after /bin/login called vhangup().

The call chain is: vhangup() -> tty_vhangup_self() -> tty_vhangup() -> __tty_hangup()

Within __tty_hangup() something happens that I don't fully understand:

if (cons_filp) { if (tty->ops->close) for (n = 0; n< closecount; n++) tty->ops->close(tty, cons_filp); } else if (tty->ops->hangup) (tty->ops->hangup)(tty);

Login on tty0 works because cons_filp is not NULL and tty->ops->close() is called. On the other hand login fails on every other TTY because cons_filp remains NULL and the TTY hangs up.

Quoted 8 lines

Is there something missing in my hangup function?

If I omit tty_operations->hangup() and leave it, like the old driver, NULL non-tty0 TTYs cannot be opened. (getty terminates immediately because it cannot open any TTY.) open() retuns -EIO because the TTY_CLOSING is set in tty->flags.

How can this be?

Hmm, it looks like some process is sitting on a TTY which was hung. And the system offers this hung TTY to others on further opens. Could you check that there is no process with open TTY after the vhangup?

Quoted 2 lines

"lsof | grep tty" does not show anything else than tty0. :-\

BTW: When I start the kernel with /bin/sh as init, opening and writing to any TTY works fine. It looks like Fedora 16's userspace does something that makes the TTYs unhappy.

Thanks,
//richard

Another question, what is the purpose of tty_port->console? It seems to have no user.

Is tty_port really the right thing for a console driver like in the UML case?

Quoted 2 lines

Another question, what is the purpose of tty_port->console? It seems to have no user.

So the tty_port layer can in future know about whether it is a console without a tty necessarily being present or referenceable.

Quoted 2 lines

Is tty_port really the right thing for a console driver like in the UML case?

It will be. In order to fix the tty locking mess we need to shove a lot of stuff whose lifetime is the lifetime of the physical port somewhere else - the tty_port is that structure.

Quoted 9 lines · Alan Cox

Quoted 2 lines

Another question, what is the purpose of tty_port->console? It seems to have no user.

So the tty_port layer can in future know about whether it is a console without a tty necessarily being present or referenceable.

Quoted 2 lines

Is tty_port really the right thing for a console driver like in the UML case?

Quoted 4 lines

It will be. In order to fix the tty locking mess we need to shove a lot of stuff whose lifetime is the lifetime of the physical port somewhere else - the tty_port is that structure.

"It will be" in terms of "not now"? ;-)

Quoted 6 lines

Quoted 4 lines

It will be. In order to fix the tty locking mess we need to shove a lot of stuff whose lifetime is the lifetime of the physical port somewhere else - the tty_port is that structure.

"It will be" in terms of "not now"? ;-)

As in, it's the very next step on.

Quoted 5 lines · Alan Cox

Quoted 5 lines

Quoted 4 lines

It will be. In order to fix the tty locking mess we need to shove a lot of stuff whose lifetime is the lifetime of the physical port somewhere else - the tty_port is that structure.

Quoted 3 lines

Quoted 1 line

"It will be" in terms of "not now"? ;-)

As in, it's the very next step on.

FWIW, uml console in default config is basically "start xterm for each VC". What do you suggest to do on vhangup() on one of those?

Quoted 11 lines · On Sat, 24 Mar 2012 23:20:01 +0000 Al Viro <[email protected]> wrote:

Quoted 8 lines · Alan Cox

Quoted 6 lines

Quoted 4 lines

It will be. In order to fix the tty locking mess we need to shove a lot of stuff whose lifetime is the lifetime of the physical port somewhere else - the tty_port is that structure.

"It will be" in terms of "not now"? ;-)

As in, it's the very next step on.

Quoted 2 lines

FWIW, uml console in default config is basically "start xterm for each VC". What do you suggest to do on vhangup() on one of those?

What posix says must happen. Which is that the running processes get a hangup. So a vhangup() would ensure there were no old apps on the UML guess talking to the xterm (eg stealing login credentials, or abusing TIOCSTI etc).

The fact it's an xterm isn't really relevant. That's just the physical interface and vhangup is about breaking the logical link. The xterm would continue, no reason for it to do otherwise I can see ?

Quoted 7 lines

Quoted 2 lines

FWIW, uml console in default config is basically "start xterm for each VC". What do you suggest to do on vhangup() on one of those?

What posix says must happen. Which is that the running processes get a hangup. So a vhangup() would ensure there were no old apps on the UML guess talking to the xterm (eg stealing login credentials, or abusing TIOCSTI etc).

Looks like Debian's /bin/login is violating POSIX. AFACT it does not call vhangup() at all.

Quoted 4 lines

The fact it's an xterm isn't really relevant. That's just the physical interface and vhangup is about breaking the logical link. The xterm would continue, no reason for it to do otherwise I can see ?

As I wrote in my very first mail, if I implement tty_operations->hangup() a vhangup() closes the current TTY and the shiny new login shell dies because read/write() returns EIO.

Quoted 7 lines · Richard Weinberger

Quoted 7 lines

Quoted 2 lines

FWIW, uml console in default config is basically "start xterm for each VC". What do you suggest to do on vhangup() on one of those?

What posix says must happen. Which is that the running processes get a hangup. So a vhangup() would ensure there were no old apps on the UML guess talking to the xterm (eg stealing login credentials, or abusing TIOCSTI etc).

IIRC, vhangup(2) is Linux-specific, so I would be surprised if POSIX had anything on it...

login(1) from util-linux does vhangup(); login(1) from shadow doesn't.

The thing is, we don't want to do that when port is in use. And we definitely don't want somebody to open the damn thing when it's halfway through getting set up. I don't see any natural way to do that exclusion with tty_port - port->{count,block_open} is protected only by a spinlock and port setup we need to do is blocking...

How is tty_port supposed to work wrt hotplug? I.e. are those guys (OK, the structures they are embedded into) supposed to live as long as tty_driver lives? AFAICS, for serial we have an extra layer atop of those guys (uart_port) and that's where removals seem to act, but there seems to be more to it...

Suppose we handle uml reconfig requests as port removal + port addition; what's needed to make sure that port is out of use and we can play with it without stepping on anyone's toes? Something along the lines of what uart_remove_one_port() is doing? I.e. tty_unregister_device() + tty_vhangup()? But serial_core seems to be open-coding tty_port_open() for some reason and _there_ we have port->count updates under port->mutex, so the situation might be different...

Serial had pre-exising gunge not all of which has been cleaned, just as it still has its own buffers that want to be using kfifo.

Best examples are probably USB serial and neatest may well be the sdio serial card driver.

* TTY layer allocates tty on demand (open() time) and feeds them
to ->install(), which is where we associate the suckers with tty_port, grabbing a reference to the latter and shoving it into ->driver_data (OK, it or that to struct it's embedded into - all the same)

* ->open()/->close()/->hungup() simply call tty_port_...()
[BTW, is there any reason why you do not set ->driver_data to port and use container_of() in the places that want other parts of containing

* removal does tty_unregister_device() + prevents ->install() from
finding it + (under port->mutex) does tty_hangup() on associated tty (if any). BTW, I really don't like the look of that place - tty_hangup() is async (otherwise it'd deadlock instantly), so what the devil is protecting tty from being freed before __tty_hangup() is done with it? And when should

* ->activate() plays strange games with TTY_IO_ERROR; why do we
bother, seeing that it's under port->mutex and anybody trying to open the same tty will wait anyway?