[lkml]   [2017]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Race between release_tty() and vt_disallocate()
> 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.


 \ /
  Last update: 2017-08-14 14:40    [W:0.068 / U:7.792 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site