1. 28 Aug, 2005 2 commits
    • Linus Torvalds's avatar
      Merge refs/heads/upstream-fixes from... · 3d52acb3
      Linus Torvalds authored
      Merge refs/heads/upstream-fixes from master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 
      3d52acb3
    • Paul Mackerras's avatar
      [PATCH] Remove race between con_open and con_close · f786648b
      Paul Mackerras authored
      [ 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: default avatarPaul Mackerras <paulus@samba.org>
      [ Same patch
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
        in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f786648b
  2. 27 Aug, 2005 16 commits
  3. 26 Aug, 2005 15 commits
  4. 25 Aug, 2005 1 commit
    • Michael Chan's avatar
      [TG3]: Fix ethtool loopback test lockup · d4ef1608
      Michael Chan authored
      The tg3_abort_hw() call in tg3_test_loopback() is causing lockups on
      some devices. tg3_abort_hw() disables the memory arbiter, causing
      tg3_reset_hw() to hang when it tries to write the pre-reset signature.
      tg3_abort_hw() should only be called after the pre-reset signature has
      been written. This is all done in tg3_reset_hw() so the tg3_abort_hw()
      call is unnecessary and can be removed.
      
      [ Also bump driver version and release date. -DaveM ]
      Signed-off-by: default avatarMichael Chan <mchan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4ef1608
  5. 24 Aug, 2005 6 commits