Messages in this thread | | | Date | Tue, 27 Jun 2006 23:29:28 -0400 | From | "Jon Smirl" <> | Subject | Re: tty_mutex and tty_old_pgrp |
| |
On 6/27/06, Paul Fulghum <paulkf@microgate.com> wrote: > No one has leaped in here with any wisdom, but the people > who wrote that code may be dead or otherwise employed. > > If you have knowledge of how those bits work, > I encourage to you dig through the code and determine > what needs to be done. It is certainly an area that can > use more review. > > I did see a comment that tty_mutex protects the creation > and destruction of tty structures, so I assume the coverage > of tty_old_pgrp has some relation to that. Unfortunately, > I have seen other locks get borrowed for multiple purposes.
I'm having trouble divining the use of tty_mutex. In most cases it is protecting pgrp, tty_old_pgrp and tty fields in signal_struct. sys_setsid(), disassociate_ctty(), daemonize(), tty::release_dev(), tty_open() use it this way. But it is also used to protect tty::init_dev() which makes no use of the signal_struct fields. Then there is the use in vt::con_close() which also does not involved the signal_struct fields.
Why does this need to be protected? exit.c mutex_lock(&tty_mutex); current->signal->tty = NULL; mutex_unlock(&tty_mutex);
After looking at all of this for a couple of hours it looks to me like tty_mutex could be removed if ref counts were used to control when the tty_struct gets destroyed. I think the problem being addressed is dangling pointers in signal_struct::tty when a tty is being closed. Ref counts would delay the freeing of tty_struct until all the references were released.
-- Jon Smirl jonsmirl@gmail.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |