> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
