kernel.git/drivers/char/vt_ioctl.c, branch linux-2.6.23.y

VT_WAITACTIVE: Avoid returning EINTR when not necessary

2007-10-07T23:02:55Z

We should generally prefer to return ERESTARTNOHAND rather than EINTR, so that processes with unhandled signals that get ignored don't return EINTR. This can help with X startup issues: Fatal server error: xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call although the real fix is having the X server always retry EINTR regardless (since EINTR does happen for signals that have handlers installed). Keithp has a patch for that. Regardless, ERESTARTNOHAND is the correct thing to use. Signed-off-by: Linus Torvalds

VT ioctl race fix

2007-10-01T14:52:23Z

When calling the RELDISP VT ioctl, we are reading vt_newvt while the console workqueue could be messing with it (through change_console()). We fix this race by taking the console semaphore before reading vt_newvt. Signed-off-by: Samuel Ortiz Acked-by: Antonino Daplas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fix console change race exposed by CFS

2007-09-29T17:00:15Z

The new behaviour of CFS exposes a race which occurs if a switch is requested when vt_mode.mode is VT_PROCESS. The process with vc->vt_pid is signaled before vc->vt_newvt is set. This causes the switch to fail when triggered by the monitoing process because the target is still -1. [ If the signal sending fails, the subsequent "reset_vc(vc)" will then reset vt_newvt to -1, so this works for that case too. - Linus ] Signed-off-by: Jan Lübbe Signed-off-by: Linus Torvalds

drivers/char: use __set_current_state()

2007-05-08T18:15:13Z

use __set_current_state(TASK_*) instead of current->state = TASK_*, Signed-off-by: Milind Arun Choudhary Cc: Jiri Slaby Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] vt: fix potential race in VT_WAITACTIVE handler

2007-04-02T17:06:09Z

On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0 if fg_console has already been updated in redraw_screen() but the console switch itself hasn't been completed. Fix this by checking fg_console in vt_waitactive() with the console sem held. Signed-off-by: Michal Januszewski Acked-by: Antonino Daplas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] swsusp: fix suspend when console is in VT_AUTO+KD_GRAPHICS mode

2007-03-17T02:25:05Z

When the console is in VT_AUTO+KD_GRAPHICS mode, switching to the SUSPEND_CONSOLE fails, resulting in vt_waitactive() waiting indefinitely or until the task is interrupted. This patch tests if a console switch can occur in set_console() and returns early if a console switch is not possible. [akpm@linux-foundation.org: cleanup] Signed-off-by: Andrew Johnson Acked-by: Pavel Machek Cc: "Antonino A. Daplas" Cc: "Rafael J. Wysocki" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] vt: refactor console SAK processing

2007-02-11T18:51:24Z

This does several things. - It moves looking up of the current foreground console into process context where we can safely take the semaphore that protects this operation. - It uses the new flavor of work queue processing. - This generates a factor of do_SAK, __do_SAK that runs immediately. - This calls __do_SAK with the console semaphore held ensuring nothing else happens to the console while we process the SAK operation. - With the console SAK processing moved into process context this patch removes the xchg operations that I used to attempt to attomically update struct pid, because of the strange locking used in the SAK processing. With SAK using the normal console semaphore nothing special is needed. Cc: Oleg Nesterov Signed-off-by: Eric W. Biederman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] getting rid of all casts of k[cmz]alloc() calls

2006-12-13T17:05:58Z

Run this: #!/bin/sh for f in $(grep -Erl "$[^$]*\) *k[cmz]alloc" *) ; do echo "De-casting $f..." perl -pi -e "s/ ?= ?$[^$]*\) *(k[cmz]alloc) *\(/ = \1\(/" $f done And then go through and reinstate those cases where code is casting pointers to non-pointers. And then drop a few hunks which conflicted with outstanding work. Cc: Russell King , Ian Molton Cc: Mikael Starvik Cc: Yoshinori Sato Cc: Roman Zippel Cc: Geert Uytterhoeven Cc: Ralf Baechle Cc: Paul Mackerras Cc: Kyle McMartin Cc: Benjamin Herrenschmidt Cc: Martin Schwidefsky Cc: "David S. Miller" Cc: Jeff Dike Cc: Greg KH Cc: Jens Axboe Cc: Paul Fulghum Cc: Alan Cox Cc: Karsten Keil Cc: Mauro Carvalho Chehab Cc: Jeff Garzik Cc: James Bottomley Cc: Ian Kent Cc: Steven French Cc: David Woodhouse Cc: Neil Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] vt: fix comments to not refer to kill_proc

2006-12-13T17:05:47Z

The code has been fixed to use kill_pid instead of kill_proc fix the comments as well. Signed-off-by: Eric W. Biederman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] vt: Make vt_pid a struct pid (making it pid wrap around safe).

2006-10-02T14:57:14Z

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 Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds