Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 10 Aug, 2010 3 commits
  3. 04 Jun, 2010 1 commit
  5. 19 Mar, 2010 1 commit
    • Greg Kroah-Hartman's avatar
      Revert "tty: Add a new VT mode which is like VT_PROCESS but doesn't require a... · 87a6aca5
      Greg Kroah-Hartman authored 
      Revert "tty: Add a new VT mode which is like VT_PROCESS but doesn't require a VT_RELDISP ioctl call"

This reverts commit eec9fe7d.

Ari writes as the reason this should be reverted:
	The problems with this patch include:
	1. There's at least one subtlety I overlooked - switching
	between X servers (i.e. from one X VT to another) still requires
	the cooperation of both X servers. I was assuming that KMS
	eliminated this.
	2. It hasn't been tested at all (no X server patch exists which
	uses the new mode).

As he was the original author of the patch, I'll revert it.

Cc: Ari Entlich <atrigent@ccs.neu.edu>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      87a6aca5
  7. 02 Mar, 2010 1 commit
    • Ari Entlich's avatar
      tty: Add a new VT mode which is like VT_PROCESS but doesn't require a VT_RELDISP ioctl call · eec9fe7d
      Ari Entlich authored 
      This new VT mode (VT_PROCESS_AUTO) does everything that VT_PROCESS does
except that it doesn't wait for a VT_RELDISP ioctl before switching
away from a VT with that mode.

If the X server eventually uses this new mode, debugging and crash
recovery should become easier. This is because even when currently in
the VT of a frozen X server it would still be possible to switch out
by doing SysRq-r and then CTRL-<number of a text vt>, sshing in and
doing chvt <number of a text vt>, or any other method of VT switching.
The general concensus on #xorg-devel seems to be that it should be
safe to use this with X now that we have KMS.

This also moves the VT_ACKACQ define to a more appropriate place,
for clarity's sake.
Signed-off-by: default avatarAri Entlich <atrigent@ccs.neu.edu>
Acked-by: default avatarAlan Cox <alan@linux.intel.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      eec9fe7d
  9. 19 Nov, 2009 1 commit
  11. 14 Oct, 2009 1 commit
  13. 01 Oct, 2009 1 commit
  15. 19 Sep, 2009 5 commits
  17. 12 Jul, 2009 1 commit
  19. 22 Jun, 2009 1 commit
  21. 06 May, 2009 1 commit
  23. 02 Jan, 2009 1 commit
  25. 13 Oct, 2008 1 commit
  27. 15 Aug, 2008 1 commit
  29. 30 Apr, 2008 1 commit
  31. 17 Oct, 2007 2 commits
  33. 16 Oct, 2007 1 commit
    • Antonino A. Daplas's avatar
      vt/vgacon: Check if screen resize request comes from userspace · e400b6ec
      Antonino A. Daplas authored 
      Various console drivers are able to resize the screen via the con_resize()
hook.  This hook is also visible in userspace via the TIOCWINSZ, VT_RESIZE and
VT_RESIZEX ioctl's.  One particular utility, SVGATextMode, expects that
con_resize() of the VGA console will always return success even if the
resulting screen is not compatible with the hardware.  However, this
particular behavior of the VGA console, as reported in Kernel Bugzilla Bug
7513, can cause undefined behavior if the user starts with a console size
larger than 80x25.

To work around this problem, add an extra parameter to con_resize().  This
parameter is ignored by drivers except for vgacon.  If this parameter is
non-zero, then the resize request came from a VT_RESIZE or VT_RESIZEX ioctl
and vgacon will always return success.  If this parameter is zero, vgacon will
return -EINVAL if the requested size is not compatible with the hardware.  The
latter is the more correct behavior.

With this change, SVGATextMode should still work correctly while in-kernel and
stty resize calls can expect correct behavior from vgacon.
Signed-off-by: default avatarAntonino Daplas <adaplas@gmail.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e400b6ec
  35. 07 Oct, 2007 1 commit
    • Linus Torvalds's avatar
      VT_WAITACTIVE: Avoid returning EINTR when not necessary · 70cb9793
      Linus Torvalds authored 
      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: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      70cb9793
  37. 01 Oct, 2007 1 commit
  39. 29 Sep, 2007 1 commit
    • Jan Lübbe's avatar
      fix console change race exposed by CFS · a64314e6
      Jan Lübbe authored 
      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: default avatarJan Lübbe <jluebbe@lasnet.de>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a64314e6
  41. 08 May, 2007 1 commit
  43. 02 Apr, 2007 1 commit
  45. 17 Mar, 2007 1 commit
  47. 11 Feb, 2007 1 commit
    • Eric W. Biederman's avatar
      [PATCH] vt: refactor console SAK processing · 8b6312f4
      Eric W. Biederman authored 
      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 <oleg@tv-sign.ru>
Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8b6312f4
  49. 13 Dec, 2006 2 commits
    • Robert P. J. Day's avatar
      [PATCH] getting rid of all casts of k[cmz]alloc() calls · 5cbded58
      Robert P. J. Day authored 
      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 <rmk@arm.linux.org.uk>, Ian Molton <spyro@f2s.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Greg KH <greg@kroah.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Paul Fulghum <paulkf@microgate.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Karsten Keil <kkeil@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: Ian Kent <raven@themaw.net>
Cc: Steven French <sfrench@us.ibm.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Jaroslav Kysela <perex@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      5cbded58
    • Eric W. Biederman's avatar
      [PATCH] vt: fix comments to not refer to kill_proc · 3dfcaf16
      Eric W. Biederman authored 
      The code has been fixed to use kill_pid instead of kill_proc fix the
comments as well.
Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3dfcaf16
  51. 02 Oct, 2006 2 commits
    • Eric W. Biederman's avatar
      [PATCH] vt: Make vt_pid a struct pid (making it pid wrap around safe). · bde0d2c9
      Eric W. Biederman authored 
      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: default avatarEric W. Biederman <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      bde0d2c9
    • Eric W. Biederman's avatar
      [PATCH] vt: rework the console spawning variables · 81af8d67
      Eric W. Biederman authored 
      This is such a rare path it took me a while to figure out how to test
this after soring out the locking.

This patch does several things.
- The variables used are moved into a structure and declared in vt_kern.h
- A spinlock is added so we don't have SMP races updating the values.
- Instead of raw pid_t value a struct_pid is used to guard against
  pid wrap around issues, if the daemon to spawn a new console dies.
Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      81af8d67
  53. 29 Sep, 2006 1 commit
    • Alan Cox's avatar
      [PATCH] tty locking on resize · ca9bda00
      Alan Cox authored 
      The current kernel serializes console resizes but does not serialize the
resize against the tty structure updates.  This means that while two
parallel resizes cannot mess up the console you can get incorrect results
reported.

Secondly while doing this I added vc_lock_resize() to lock and resize the
console.  This leaves all knowledge of the console_sem in the vt/console
driver and kicks it out of the tty layer, which is good

Thirdly while doing this I decided I couldn't stand "disallocate" any
longer so I switched it to "deallocate".
Signed-off-by: default avatarAlan Cox <alan@redhat.com>
Cc: Paul Fulghum <paulkf@microgate.com>
Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ca9bda00
  55. 27 Aug, 2006 1 commit
  57. 30 Jun, 2006 1 commit
  59. 07 Nov, 2005 1 commit
  61. 31 Oct, 2005 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7