summaryrefslogtreecommitdiff
path: root/net
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2006-10-02 02:17:14 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2006-10-02 07:57:14 -0700
commitbde0d2c98bcfc9acc83ac79c33a6ac1335b95a92 (patch)
tree1bacec61e5bd5fadaef630e95e8cc1ae618b94ff /net
parent81af8d67d4fc35b1ee6e0feb1f1b34b3a33eeb44 (diff)
downloadlwn-bde0d2c98bcfc9acc83ac79c33a6ac1335b95a92.tar.gz
lwn-bde0d2c98bcfc9acc83ac79c33a6ac1335b95a92.zip
[PATCH] vt: Make vt_pid a struct pid (making it pid wrap around safe).
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>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions