Jon Smirl wrote:
In tty_io.c there is a comment that tty_mutex needs to be held before
changing tty_old_pgrp. If I grep for tty_old_pgrp every place it is
changed except for one is protected by tty_mutex.
In security/selinux/hooks.c it appears to be changed without holding
the lock, is this ok? If it is ok, I can add a comment saying it is.
If someone were to provide me with the proper guidance, I have some
time I could spend working on the tty code. For example from an object
oriented perspective it doesn't look right to me that
disassociate_ctty is a function in the tty layer. It makes more sense
to me that this function would be located in the task code.
How could things be rearranged to avoid the need for sys_setsid() and
daemonize() to directly manipulate tty_mutex? What exactly is
tty_mutex protecting, it appears to be used in multiple contexts.
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.
--
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]