I took a good hard look at the locking and it appears the locking on vt_pid
is the console semaphore. Every modified path is called under the console
semaphore except reset_vc when it is called from fn_SAK or do_SAK both of
which appear to be in interrupt context. In addition I need to be careful
because in the presence of an oops the console_sem may be arbitrarily
dropped.
Which leads me to conclude the current locking is inadequate for my needs.
Given the weird cases we could hit because of oops printing instead of
introducing an extra spin lock to protect the data and keep the pid to
signal and the signal to send in sync, I have opted to use xchg on just the
struct pid * pointer instead.
Due to console_sem we will stay in sync between vt_pid and vt_mode except
for a small window during a SAK, or oops handling. SAK handling should
kill any user space process that care, and oops handling we are broken
anyway. Besides the worst that can happen is that I try to send the wrong
signal.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h
allows all of the framebuffer and VT console drivers to remove their
dependency on tty.h.
[akpm@osdl.org: fix alpha build]
Signed-off-by: Jon Smirl <jonsmir@gmail.com>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Eric W. Biederman