1. 17 3月, 2007 1 次提交
  2. 14 2月, 2007 1 次提交
    • E
      [PATCH] Fix SAK_work workqueue initialization. · 7f1f86a0
      Eric W. Biederman 提交于
      Somewhere in the rewrite of the work queues my cleanup of SAK handling
      got broken.  Maybe I didn't retest it properly or possibly the API
      was changing so fast I missed something.  Regardless currently
      triggering a SAK now generates an ugly BUG_ON and kills the kernel.
      
      Thanks to Alexey Dobriyan <adobriyan@openvz.org> for spotting this.
      
      This modifies the use of SAK_work to initialize it when the data
      structure it resides in is initialized, and to simply call
      schedule_work when we need to generate a SAK.  I update both
      data structures that have a SAK_work member for consistency.
      
      All of the old PREPARE_WORK calls that are now gone.
      
      If we call schedule_work again before it has processed it
      has generated the first SAK it will simply ignore the duplicate
      schedule_work request.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7f1f86a0
  3. 13 2月, 2007 2 次提交
  4. 12 2月, 2007 1 次提交
  5. 14 12月, 2006 1 次提交
    • R
      [PATCH] getting rid of all casts of k[cmz]alloc() calls · 5cbded58
      Robert P. J. Day 提交于
      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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cbded58
  6. 08 12月, 2006 1 次提交
  7. 02 12月, 2006 1 次提交
  8. 22 11月, 2006 1 次提交
    • D
      WorkStruct: Pass the work_struct pointer instead of context data · 65f27f38
      David Howells 提交于
      Pass the work_struct pointer to the work function rather than context data.
      The work function can use container_of() to work out the data.
      
      For the cases where the container of the work_struct may go away the moment the
      pending bit is cleared, it is made possible to defer the release of the
      structure by deferring the clearing of the pending bit.
      
      To make this work, an extra flag is introduced into the management side of the
      work_struct.  This governs auto-release of the structure upon execution.
      
      Ordinarily, the work queue executor would release the work_struct for further
      scheduling or deallocation by clearing the pending bit prior to jumping to the
      work function.  This means that, unless the driver makes some guarantee itself
      that the work_struct won't go away, the work function may not access anything
      else in the work_struct or its container lest they be deallocated..  This is a
      problem if the auxiliary data is taken away (as done by the last patch).
      
      However, if the pending bit is *not* cleared before jumping to the work
      function, then the work function *may* access the work_struct and its container
      with no problems.  But then the work function must itself release the
      work_struct by calling work_release().
      
      In most cases, automatic release is fine, so this is the default.  Special
      initiators exist for the non-auto-release case (ending in _NAR).
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      65f27f38
  9. 03 10月, 2006 2 次提交
  10. 02 10月, 2006 2 次提交
    • J
      [PATCH] const struct tty_operations · b68e31d0
      Jeff Dike 提交于
      As part of an SMP cleanliness pass over UML, I consted a bunch of
      structures in order to not have to document their locking.  One of these
      structures was a struct tty_operations.  In order to const it in UML
      without introducing compiler complaints, the declaration of
      tty_set_operations needs to be changed, and then all of its callers need to
      be fixed.
      
      This patch declares all struct tty_operations in the tree as const.  In all
      cases, they are static and used only as input to tty_set_operations.  As an
      extra check, I ran an i386 allyesconfig build which produced no extra
      warnings.
      
      53 drivers are affected.  I checked the history of a bunch of them, and in
      most cases, there have been only a handful of maintenance changes in the
      last six months.  serial_core.c was the busiest one that I looked at.
      Signed-off-by: NJeff Dike <jdike@addtoit.com>
      Acked-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b68e31d0
    • E
      [PATCH] vt: Make vt_pid a struct pid (making it pid wrap around safe). · bde0d2c9
      Eric W. Biederman 提交于
      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: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bde0d2c9
  11. 30 9月, 2006 4 次提交
  12. 04 7月, 2006 1 次提交
  13. 01 7月, 2006 1 次提交
  14. 27 6月, 2006 7 次提交
    • G
      [PATCH] devfs: Remove the tty_driver devfs_name field as it's no longer needed · f4eaa370
      Greg Kroah-Hartman 提交于
      Also fixes all drivers that set this field.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f4eaa370
    • G
      [PATCH] devfs: Remove the devfs_fs_kernel.h file from the tree · ff23eca3
      Greg Kroah-Hartman 提交于
      Also fixes up all files that #include it.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ff23eca3
    • A
      [PATCH] VT binding: Make VT binding a Kconfig option · 13ae6645
      Antonino A. Daplas 提交于
      To enable this feature, CONFIG_VT_HW_CONSOLE_BINDING must be set to 'y'.  This
      feature will default to 'n' to minimize users accidentally corrupting their
      virtual terminals.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      13ae6645
    • A
      [PATCH] VT binding: Add sysfs control to the VT layer · 6db4063c
      Antonino A. Daplas 提交于
      Add sysfs control to the VT layer.  A new sysfs class, 'vtconsole', and class
      devices 'vtcon[n]' are added.  Each class device file has the following
      attributes:
      
      /sys/class/vtconsole/vtcon[n]/name - read-only attribute showing the
                                           name of the current backend
      
      /sys/class/vtconsole/vtcon[n]/bind - read/write attribute
                   where: 0 - backend is unbound/unbind backend from the VT layer
                          1 - backend is bound/bind backend to the VT layer
      
      In addition, if any of the consoles are in KD_GRAPHICS mode, binding and
      unbinding will not succeed.  KD_GRAPHICS mode usually indicates that the
      underlying console hardware is used for other purposes other than displaying
      text (ie X).  This feature should prevent binding/unbinding from interfering
      with a graphics application using the VT.
      
      [akpm@osdl.org: warning fixes]
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6db4063c
    • A
      [PATCH] VT binding: Add binding/unbinding support for the VT console · 3e795de7
      Antonino A. Daplas 提交于
      The framebuffer console is now able to dynamically bind and unbind from the VT
      console layer.  Due to the way the VT console layer works, the drivers
      themselves decide when to bind or unbind.  However, it was decided that
      binding must be controlled, not by the drivers themselves, but by the VT
      console layer.  With this, dynamic binding is possible for all VT console
      drivers, not just fbcon.
      
      Thus, the VT console layer will impose the following to all VT console
      drivers:
      
      - all registered VT console drivers will be entered in a private list
      - drivers can register themselves to the VT console layer, but they cannot
        decide when to bind or unbind. (Exception: To maintain backwards
        compatibility, take_over_console() will automatically bind the driver after
        registration.)
      - drivers can remove themselves from the list by unregistering from the VT
        console layer. A prerequisite for unregistration is that the driver must not
        be bound.
      
      The following functions are new in the vt.c:
      
      register_con_driver() - public function, this function adds the VT console
      driver to an internal list maintained by the VT console
      
      bind_con_driver() - private function, it binds the driver to the console
      
      take_over_console() is changed to call register_con_driver() followed by a
      bind_con_driver().  This is the only time drivers can decide when to bind to
      the VT layer.  This is to maintain backwards compatibility.
      
      unbind_con_driver() - private function, it unbinds the driver from its
      console.  The vacated consoles will be taken over by the default boot console
      driver.
      
      unregister_con_driver() - public function, removes the driver from the
      internal list maintained by the VT console.  It will only succeed if the
      driver is currently unbound.
      
      con_is_bound() checks if the driver is currently bound or not
      
      give_up_console() is just a wrapper to unregister_con_driver().
      
      There are also 3 additional functions meant to be called only by the tty layer
      for sysfs control:
      
      	vt_bind() - calls bind_con_driver()
      	vt_unbind() - calls unbind_con_driver()
      	vt_show_drivers() - shows the list of registered drivers
      
      Most VT console drivers will continue to work as is, but might have problems
      when unbinding or binding which should be fixable with minimal changes.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3e795de7
    • A
      [PATCH] Detaching fbcon: fix give_up_console() · 1c8ce271
      Antonino A. Daplas 提交于
      To allow for detaching fbcon, it must be able to give up the console.
      However, the function give_up_console() is plain broken.  It just sets the
      entries in the console driver map to NULL, it leaves the vt layer without a
      console driver, and does not decrement the module reference count.  Calling
      give_up_console() is guaranteed to hang the machine..
      
      To fix this problem, ensure that the virtual consoles are not left dangling
      without a driver.  All systems have a default boot driver (either vgacon or
      dummycon) which is never unloaded.  For those vt's that lost their driver, the
      default boot driver is reassigned back to them.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1c8ce271
    • D
      [PATCH] vt: Delay the update of the visible console · 4ee1acce
      David Hollister 提交于
      Delay the update of the visible framebuffer console until all other consoles
      have been initialized in order to avoid losing information.  This only seems
      to be a problem with modules, not with built-in drivers.
      Signed-off-by: NDavid Hollister <david.hollister@amd.com>
      Signed-off-by: NJordan Crouse <jordan.crouse@amd.com>
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4ee1acce
  15. 01 6月, 2006 1 次提交
  16. 01 4月, 2006 1 次提交
  17. 23 3月, 2006 2 次提交
  18. 02 2月, 2006 1 次提交
  19. 11 1月, 2006 1 次提交
    • V
      [PATCH] Fix console blanking · d060a321
      Ville Syrjala 提交于
      Current console blanking code is broken.  It will first do a normal blank,
      then start the VESA blank timer if vesa_off_interval != 0, and then proceed
      to do the VESA blanking directly.  After the timer expires it will do the
      VESA blanking a second time.  Also the vesa_powerdown() function doesn't
      allow all VESA modes to be used.
      
      With this patch the behaviour is:
      1. Blank: vesa_off_interval != 0 -> Do normal blank
                vesa_off_interval == 0 -> Do VESA blank
      2. Start the VESA blank timer if vesa_off_interval != 0 and
         vesa_power_mode != 0.
      
      It also gets rid of the limiting vesa_powerdown() function.
      Signed-off-by: NVille Syrjala <syrjala@sci.fi>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d060a321
  20. 15 9月, 2005 1 次提交
  21. 10 9月, 2005 1 次提交
    • A
      [PATCH] console: Fix buffer copy on vc resize · 3b41dc1a
      Antonino A. Daplas 提交于
      On a vc resize, the contents of the old screen buffer are transferred to the
      new screenbuffer.  If the new screenbuffer is smaller than the old one, only
      the contents from the bottom are copied to new.  If the contents of the old
      buffer are located at the top, then the contents will not be copied to the new
      buffer resulting in a blank screen.
      
      This bug will happen only if the vc in question is not in the foreground.
      Doing an fbset -a or con2fbmap will trigger this bug.
      
      To fix this problem, base the start of the copy from the location of the
      current cursor.  If the cursor is near the top of the buffer, copy the
      contents at the top, and if the cursor is near the bottom of the buffer, then
      copy the contents at the bottom.  In the unlikely case where the new row size
      is greater than 2x smaller than the old one, and the cursor is in the middle,
      copy 1/2 screenful from the top and bottom of the cursor position.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3b41dc1a
  22. 08 9月, 2005 2 次提交
    • A
      [PATCH] vt: fix possible memory corruption in complement_pos · 414edcd3
      Antonino A. Daplas 提交于
      Based on a patch from Andr Pereira de Almeida <andre@cachola.com.br>
      
      It might be possible for the saved pointer (*p) to become invalid in
      between vc_resizes, so saving the screen offset instead of the screen
      pointer is saner.
      
      This bug is very hard to trigger though, but Andre probably did, if he's
      submitting this patch.  Anyway, with Andre's patch, it's still possible for
      the offsets to be still illegal, if the new screen size is smaller than the
      old one.  So I've also added checks if the offsets are still within the
      screenbuffer size.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      414edcd3
    • S
      [PATCH] Console blanking locking fix · 2d237c63
      Stephane Doyon 提交于
      I've had WARN_CONSOLE_UNLOCKED warnings when calling TIOCLINUX
      TIOCL_BLANKSCREEN and TIOCL_UNBLANKSCREEN.
      
      (I'm blind and I use a braille display.  I use those functions to blank my
      laptop's screen so people don't read it, and hopefully to conserve power.)
      
      The warnings are from these places:
      do_blank_screen at drivers/char/vt.c:2754 (Not tainted)
      save_screen at drivers/char/vt.c:575 (Not tainted)
      do_unblank_screen at drivers/char/vt.c:2822 (Not tainted)
      set_palette at drivers/char/vt.c:2908 (Not tainted)
      
      At a glance I would think the following patch ought to fix that.  Tested on
      one machine.  Could you please tell me if this is correct and/or forward
      the patch where appropriate...
      Signed-off-by: NStephane Doyon <s.doyon@videotron.ca>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2d237c63
  23. 28 8月, 2005 1 次提交
    • P
      [PATCH] Remove race between con_open and con_close · f786648b
      Paul Mackerras 提交于
      [ Same race and same patch also by Steven Rostedt <rostedt@goodmis.org> ]
      
      I have a laptop (G3 powerbook) which will pretty reliably hit a race
      between con_open and con_close late in the boot process and oops in
      vt_ioctl due to tty->driver_data being NULL.
      
      What happens is this: process A opens /dev/tty6; it comes into
      con_open() (drivers/char/vt.c) and assign a non-NULL value to
      tty->driver_data.  Then process A closes that and concurrently process
      B opens /dev/tty6.  Process A gets through con_close() and clears
      tty->driver_data, since tty->count == 1.  However, before process A
      can decrement tty->count, we switch to process B (e.g. at the
      down(&tty_sem) call at drivers/char/tty_io.c line 1626).
      
      So process B gets to run and comes into con_open with tty->count == 2,
      as tty->count is incremented (in init_dev) before con_open is called.
      Because tty->count != 1, we don't set tty->driver_data.  Then when the
      process tries to do anything with that fd, it oopses.
      
      The simple and effective fix for this is to test tty->driver_data
      rather than tty->count in con_open.  The testing and setting of
      tty->driver_data is serialized with respect to the clearing of
      tty->driver_data in con_close by the console_sem.  We can't get a
      situation where con_open sees tty->driver_data != NULL and then
      con_close on a different fd clears tty->driver_data, because
      tty->count is incremented before con_open is called.  Thus this patch
      eliminates the race, and in fact with this patch my laptop doesn't
      oops.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      [ Same patch
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
        in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ]
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f786648b
  24. 16 7月, 2005 1 次提交
  25. 19 6月, 2005 1 次提交
  26. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4