1. 29 8月, 2005 36 次提交
  2. 28 8月, 2005 4 次提交
    • L
      Merge refs/heads/upstream-fixes from... · 3d52acb3
      Linus Torvalds 提交于
      Merge refs/heads/upstream-fixes from master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 
      3d52acb3
    • 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
    • A
      [PATCH] zfcp: add rports to enable scsi_add_device to work again · 3859f6a2
      Andreas Herrmann 提交于
      This patch fixes a severe problem with 2.6.13-rc7.
      
      Due to recent SCSI changes it is not possible to add any LUNs to the zfcp
      device driver anymore.  With registration of remote ports this is fixed.
      Signed-off-by: NAndreas Herrmann <aherrman@de.ibm.com>
      Acked-by: NJames Bottomley <jejb@steeleye.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3859f6a2
    • J
      [PATCH] sg.c: fix a memory leak in devices seq_file implementation · 729d70f5
      Jan Blunck 提交于
      I know that scsi procfs is legacy code but this is a fix for a memory leak.
      
      While reading through sg.c I realized that the implementation of
      /proc/scsi/sg/devices with seq_file is leaking memory due to freeing the
      pointer returned by the next() iterator method.  Since next() might return
      NULL or an error this is wrong.  This patch fixes it through using the
      seq_files private field for holding the reference to the iterator object.
      
      Here is a small bash script to trigger the leak. Use slabtop to watch
      the size-32 usage grow and grow.
      
      #!/bin/sh
      
      while true; do
      	cat /proc/scsi/sg/devices > /dev/null
      done
      Signed-off-by: NJan Blunck <j.blunck@tu-harburg.de>
      Acked-by: NJames Bottomley <James.Bottomley@steeleye.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      729d70f5