1. 02 5月, 2007 1 次提交
  2. 30 4月, 2007 1 次提交
  3. 29 4月, 2007 3 次提交
  4. 27 4月, 2007 1 次提交
  5. 26 4月, 2007 4 次提交
  6. 24 4月, 2007 6 次提交
  7. 18 4月, 2007 1 次提交
  8. 13 4月, 2007 3 次提交
  9. 10 4月, 2007 1 次提交
  10. 09 4月, 2007 1 次提交
  11. 03 4月, 2007 1 次提交
  12. 29 3月, 2007 1 次提交
  13. 28 3月, 2007 1 次提交
  14. 27 3月, 2007 1 次提交
  15. 19 3月, 2007 2 次提交
    • E
      [PATCH] tty: Fix two reported pid leaks · d9c1e9a8
      Eric W. Biederman 提交于
      These leaks were reported by: Catalin Marinas <catalin.marians@gmail.com>
      and I have been able to very by inspection they are possible.
      
      When converting tty_io.c to store pids as struct pid pointers instead
      of pid_t values it appears I overlooked two places where we stop using
      the pid value.  The very obvious one is in do_tty_hangup, and the one
      the less obvious one in __proc_set_tty.
      
      When looking into the code __proc_set_tty only has pids that need to
      be put because of failures of other parts of the code to properly
      perform hangup processing.   Fixing the leak here in __proc_set_tty
      is easy and obviously correct so I am doing that first.
      
      Fixing the places that should be performing hangup processing is much
      less obviously correct.  So those I'm aiming those patches at -mm.
      for now, so the can age a while before they are merged.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d9c1e9a8
    • A
      [PATCH] machzwd warning fix · bad77057
      Andrew Morton 提交于
      drivers/char/watchdog/machzwd.c: In function 'zf_ioctl':
      drivers/char/watchdog/machzwd.c:327: warning: passing argument 1 of 'zf_ping' makes integer from pointer without a cast
      
      Also some coding-style repairs.
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Acked-by: NWim Van Sebroeck <wim@iguana.be>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bad77057
  16. 17 3月, 2007 3 次提交
    • B
      [PATCH] Initialise SAK member for each virtual console to prevent oops · c2c88f10
      Bernhard Walle 提交于
      Initialise the SAK member of the vc_cons variable on all virtual terminals,
      not only the first one.  This prevents an oops when trying Sysrq-C on e.g.
      the second virtual terminal:
      
        kernel BUG at kernel/workqueue.c:212!
        invalid opcode: 0000 [1] SMP
        CPU 0
        Modules linked in: i915 drm deflate zlib_deflate twofish twofish_common serpent blowfish des ce
        Pid: 0, comm: swapper Not tainted 2.6.21-rc3-default #15
        RIP: 0010:[<ffffffff8028c955>]  [<ffffffff8028c955>] queue_work+0x32/0x51
        RSP: 0018:ffffffff805fada8  EFLAGS: 00010013
        RAX: ffffffff80683f38 RBX: ffffffff804ae700 RCX: 0000000000000000
        RDX: 0000000000000000 RSI: ffffffff80683f30 RDI: ffff81000134a840
        RBP: 0000000000000001 R08: 0000000000000005 R09: 0000000000000002
        R10: ffffffff805990e0 R11: ffff810037f4c0f0 R12: 000000000000006b
        R13: ffff81007aa23000 R14: 0000000000000001 R15: 0000000000000096
        FS:  0000000000000000(0000) GS:ffffffff804d8000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
        CR2: 00002b72026e9000 CR3: 0000000079175000 CR4: 00000000000006e0
        Process swapper (pid: 0, threadinfo ffffffff8059e000, task ffffffff80490840)
        Stack:  0000000000000096 ffffffff803635db ffffffff805fadf8 0000000000000001
         ffff8100013c2e40 0000000000000025 ffff81007c931c00 ffff81007aa23000
         0000000000000001 ffffffff8035e3ee 0000000000000092 ffff810037cc8000
        Call Trace:
         <IRQ>  [<ffffffff803635db>] __handle_sysrq+0x98/0x129
         [<ffffffff8035e3ee>] kbd_event+0x32e/0x56a
         [<ffffffff8037d502>] input_event+0x422/0x44a
         [<ffffffff80381d71>] atkbd_interrupt+0x449/0x503
         [<ffffffff8037a42d>] serio_interrupt+0x37/0x6f
         [<ffffffff8037affb>] i8042_interrupt+0x1f4/0x20a
         [<ffffffff8026bd20>] smp_send_timer_broadcast_ipi+0x2d/0x4e
         [<ffffffff8020eee5>] handle_IRQ_event+0x25/0x53
         [<ffffffff802a924c>] handle_edge_irq+0xe4/0x128
         [<ffffffff802562ac>] call_softirq+0x1c/0x28
         [<ffffffff802632eb>] do_IRQ+0x6c/0xd3
         [<ffffffff8024f4e7>] mwait_idle+0x0/0x45
         [<ffffffff80255631>] ret_from_intr+0x0/0xa
         <EOI>  [<ffffffff80248a4d>] datagram_poll+0x0/0xc8
         [<ffffffff8024f529>] mwait_idle+0x42/0x45
         [<ffffffff80242c05>] cpu_idle+0x8b/0xae
         [<ffffffff805a8779>] start_kernel+0x2b9/0x2c5
         [<ffffffff805a815e>] _sinittext+0x15e/0x162
      
        Code: 0f 0b eb fe 48 8b 07 48 63 d2 48 f7 d0 48 8b 3c d0 e8 13 ff
        RIP  [<ffffffff8028c955>] queue_work+0x32/0x51
         RSP <ffffffff805fada8>
        Kernel panic - not syncing: Aiee, killing interrupt handler!
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Acked-by: NEric Biederman <ebiederm@xmission.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c2c88f10
    • A
      [PATCH] swsusp: fix suspend when console is in VT_AUTO+KD_GRAPHICS mode · b257bc05
      Andrew Johnson 提交于
      When the console is in VT_AUTO+KD_GRAPHICS mode, switching to the
      SUSPEND_CONSOLE fails, resulting in vt_waitactive() waiting indefinitely or
      until the task is interrupted.  This patch tests if a console switch can
      occur in set_console() and returns early if a console switch is not
      possible.
      
      [akpm@linux-foundation.org: cleanup]
      Signed-off-by: NAndrew Johnson <ajohnson@intrinsyc.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b257bc05
    • R
      [CHAR] lcd: Fix two warnings. · 2c35f813
      Ralf Baechle 提交于
      In file included from drivers/char/lcd.c:23:
      include/linux/mc146818rtc.h:104:1: warning: "RTC_IO_EXTENT" redefined
      drivers/char/lcd.c:15:1: warning: this is the location of the previous definition
      drivers/char/lcd.c:35: warning: 'lcd_lock' defined but not used
      
      c316eb1e deleted the last code using
      lcd_lock, so delete definition of lcd_lock.
      
      The definition of RTC_IO_EXTENT is unused and probably always was only
      debree copied from drivers/char/rtc.c.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      2c35f813
  17. 15 3月, 2007 1 次提交
  18. 11 3月, 2007 1 次提交
  19. 08 3月, 2007 1 次提交
  20. 07 3月, 2007 2 次提交
  21. 05 3月, 2007 3 次提交
  22. 02 3月, 2007 1 次提交
    • A
      [PATCH] tty_io: fix race in master pty close/slave pty close path · 5a39e8c6
      Aristeu Sergio Rozanski Filho 提交于
      This patch fixes a possible race that leads to double freeing an idr index.
       When the master begin to close, release_dev() is called and then
      pty_close() is called:
      
              if (tty->driver->close)
                      tty->driver->close(tty, filp);
      
      This is done without helding any locks other than BKL.  Inside pty_close(),
      being a master close, the devpts entry will be removed:
      
      #ifdef CONFIG_UNIX98_PTYS
                      if (tty->driver == ptm_driver)
                              devpts_pty_kill(tty->index);
      #endif
      
      But devpts_pty_kill() will call get_node() that may sleep while waiting for
      &devpts_root->d_inode->i_sem.  When this happens and the slave is being
      opened, tty_open() just found the driver and index:
      
              driver = get_tty_driver(device, &index);
              if (!driver) {
                      mutex_unlock(&tty_mutex);
                      return -ENODEV;
              }
      
      This part of the code is already protected under tty_mute.  The problem is
      that the slave close already got an index.  Then init_dev() is called and
      blocks waiting for the same &devpts_root->d_inode->i_sem.
      
      When the master close resumes, it removes the devpts entry, and the
      relation between idr index and the tty is gone.  The master then sleeps
      waiting for the tty_mutex on release_dev().
      
      Slave open resumes and found no tty for that index.  As result, a NULL tty
      is returned and init_dev() doesn't flow to fast_track:
      
              /* check whether we're reopening an existing tty */
              if (driver->flags & TTY_DRIVER_DEVPTS_MEM) {
                      tty = devpts_get_tty(idx);
                      if (tty && driver->subtype == PTY_TYPE_MASTER)
                              tty = tty->link;
              } else {
                      tty = driver->ttys[idx];
              }
              if (tty) goto fast_track;
      
      The result of this, is that a new tty will be created and init_dev() returns
      sucessfull. After returning, tty_mutex is dropped and master close may resume.
      
      Master close finds it's the only use and both sides are closing, then releases
      the tty and the index. At this point, the idr index is free, but slave still
      has it.
      
      Slave open then calls pty_open() and finds that tty->link->count is 0,
      because there's no master and returns error.  Then tty_open() calls
      release_dev() which executes without any warning, as it was a case of last
      slave close when the master is already closed (master->count == 0,
      slave->count == 1).  The tty is then released with the already released idr
      index.
      
      This normally would only issue a warning on idr_remove() but in case of a
      customer's critical application, it's never too simple:
      
      thread1: opens master, gets index X
      thread1: begin closing master
      thread2: begin opening slave with index X
      thread1: finishes closing master, index X released
      thread3: opens master, gets index X, just released
      thread2: fails opening slave, releases index X         <----
      thread4: opens master, gets index X, init_dev() then find an already in use
      	 and healthy tty and fails
      
      If no more indexes are released, ptmx_open() will keep failing, as the
      first free index available is X, and it will make init_dev() fail because
      you're trying to "reopen a master" which isn't valid.
      
      The patch notices when this race happens and make init_dev() fail
      imediately.  The init_dev() function is called with tty_mutex held, so it's
      safe to continue with tty till the end of function because release_dev()
      won't make any further changes without grabbing the tty_mutex.
      
      Without the patch, on some machines it's possible get easily idr warnings
      like this one:
      
      idr_remove called for id=15 which is not allocated.
       [<c02555b9>] idr_remove+0x139/0x170
       [<c02a1b62>] release_mem+0x182/0x230
       [<c02a28e7>] release_dev+0x4b7/0x700
       [<c02a0ea7>] tty_ldisc_enable+0x27/0x30
       [<c02a1e64>] init_dev+0x254/0x580
       [<c02a0d64>] check_tty_count+0x14/0xb0
       [<c02a4f05>] tty_open+0x1c5/0x340
       [<c02a4d40>] tty_open+0x0/0x340
       [<c017388f>] chrdev_open+0xaf/0x180
       [<c017c2ac>] open_namei+0x8c/0x760
       [<c01737e0>] chrdev_open+0x0/0x180
       [<c0167bc9>] __dentry_open+0xc9/0x210
       [<c0167e2c>] do_filp_open+0x5c/0x70
       [<c0167a91>] get_unused_fd+0x61/0xd0
       [<c0167e93>] do_sys_open+0x53/0x100
       [<c0167f97>] sys_open+0x27/0x30
       [<c010303b>] syscall_call+0x7/0xb
      
      using this test application available on:
       http://www.ruivo.org/~aris/pty_sodomizer.cSigned-off-by: NAristeu Sergio Rozanski Filho <aris@ruivo.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5a39e8c6