Re: Race between release_tty() and vt_disallocate()

[Alan Cox]

> non-pointer value 0x00000028fecaedff. The tty_port belongs to
> a vc_data structure, which gets freed after we find that
> console_driver->ttys[i]->count is zero in the VT_DISALLOCATE
> ioctl. Apparently at the same time, the agetty process owning

That wouldn't actually be a safe check. tty->count isn't a simple
reference count even if the locking were right.

> the tty closes and that leads to  tty->count dropping to zero
> before we call tty_buffer_cancel_work() on the tty_port that
> has now been freed.
> 
> Apparently the locking and/or reference counting between the
> two code paths is insufficient, but I don't understand enough
> about tty locking to come up with a fix that doesn't break other
> things. Please have a look.

I'm actually not sure how we can fix this within the current API. The tty
port is refcounted (see tty_port_put() and tty_port_tty_get()) so
any ioctl would end up returning but the console port resources would not
disappear until that tty finally closed down.

Calling tty_hangup on the tty for the port will close the tty down, but
that in itself is also asynchronous.

The only easy way I can think to keep the current semantics would instead
be to keep the tty port resources around and indexed somewhere but
blackhole input to/output from that port or switching to it and also call
tty_hangup if the port has a tty.

Alan