1. 10 Aug, 2010 3 commits
  2. 04 Jun, 2010 1 commit
  3. 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
  4. 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
  5. 19 Nov, 2009 1 commit
  6. 14 Oct, 2009 1 commit
  7. 01 Oct, 2009 1 commit
  8. 19 Sep, 2009 5 commits
  9. 12 Jul, 2009 1 commit
  10. 22 Jun, 2009 1 commit
  11. 06 May, 2009 1 commit
  12. 02 Jan, 2009 1 commit
  13. 13 Oct, 2008 1 commit
  14. 15 Aug, 2008 1 commit
  15. 30 Apr, 2008 1 commit
  16. 17 Oct, 2007 2 commits
  17. 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
  18. 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
  19. 01 Oct, 2007 1 commit
  20. 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
  21. 08 May, 2007 1 commit
  22. 02 Apr, 2007 1 commit
  23. 16 Mar, 2007 1 commit
  24. 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
  25. 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
  26. 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
  27. 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
  28. 27 Aug, 2006 1 commit
  29. 30 Jun, 2006 1 commit
  30. 07 Nov, 2005 1 commit
  31. 30 Oct, 2005 1 commit