1. 16 2月, 2006 9 次提交
    • M
      [PATCH] add asm-generic/mman.h · 5f6164f3
      Michael S. Tsirkin 提交于
      Make new MADV_REMOVE, MADV_DONTFORK, MADV_DOFORK consistent across all
      arches.  The idea is to make it possible to use them portably even before
      distros include them in libc headers.
      
      Move common flags to asm-generic/mman.h
      Signed-off-by: NMichael S. Tsirkin <mst@mellanox.co.il>
      Cc: Roland Dreier <rolandd@cisco.com>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5f6164f3
    • P
      [PATCH] cpuset: oops in exit on null cpuset fix · 06fed338
      Paul Jackson 提交于
      Fix a latent bug in cpuset_exit() handling.  If a task tried to allocate
      memory after calling cpuset_exit(), it oops'd in
      cpuset_update_task_memory_state() on a NULL cpuset pointer.
      
      So set the exiting tasks cpuset to the root cpuset instead of to NULL.
      
      A distro kernel hit this with an added kernel package that had just such a
      hook (allocating memory) in the exit code path.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      06fed338
    • A
      [PATCH] ide: touch softlockup detector during pio · 651c29a1
      Andrew Morton 提交于
      We're getting some softlockup false positives during heavy PIO operations.  So
      poke the lockup detector.
      
      Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      651c29a1
    • B
      [PATCH] kbuild: revert "fix make -jN with multiple targets with O=..." · 36cbbe5e
      Benjamin LaHaise 提交于
      Commit 296e0855:
      
          "kbuild: fix make -jN with multiple targets with O=..."
      
      causes a ~95% increase in build time for the kernel.  Before: 4m21s
      after: 8m1.403s.  Can we revert this until another approach is found?
      
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      36cbbe5e
    • C
      [PATCH] neofb: avoid resetting display config on unblank (v2) · 9f672004
      Christian Trefzer 提交于
      There were two mistakes in the register-read-on-(un)blank approach.
      
      - First, without proper register (un)locking the value read back will always
        be zero, and this is what I missed entirely until just now.  Due to this,
        the logic could not be verified at all and I tried some bogus checks which
        are completely stupid.
      
      - Second, the LCD status bit will always be set to zero when the backlight
        has been turned off.  Reading the value back during unblank will disable the
        LCD unconditionally, regardless of the state it is supposed to be in, since
        we set it to zero beforehand.
      
      So this is what we do now:
      
      - create a new variable in struct neofb_par, and use that to determine
        whether to read back registers (initialized to true)
      
      - before actually blanking the screen, read back the register to sense any
        possible change made through Fn key combo
      
      - use proper neoUnlock() / neoLock() to actually read something
      
      - every call to neofb_blank() determines if we read back next time: blanking
        disables readback, unblanking (FB_BLANK_UNBLANK) enables it
      
      This should give us a nice and clean state machine.  Has been thoroughly
      tested on a Dell Latitude CPiA / NM220 Chip docked to a C/Dock2 with attached
      CRT in all possible combinations of LCD/CRT on/off.  I changed the config via
      Fn key, let the console blank, unblanked by keypress - works flawlessly.
      Signed-off-by: NChristian Trefzer <ctrefzer@gmx.de>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9f672004
    • O
      [PATCH] fix zap_thread's ptrace related problems · 5ecfbae0
      Oleg Nesterov 提交于
      1. The tracee can go from ptrace_stop() to do_signal_stop()
         after __ptrace_unlink(p).
      
      2. It is unsafe to __ptrace_unlink(p) while p->parent may wait
         for tasklist_lock in ptrace_detach().
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5ecfbae0
    • O
      [PATCH] fix kill_proc_info() vs fork() theoretical race · dadac81b
      Oleg Nesterov 提交于
      copy_process:
      
      	attach_pid(p, PIDTYPE_PID, p->pid);
      	attach_pid(p, PIDTYPE_TGID, p->tgid);
      
      What if kill_proc_info(p->pid) happens in between?
      
      copy_process() holds current->sighand.siglock, so we are safe
      in CLONE_THREAD case, because current->sighand == p->sighand.
      
      Otherwise, p->sighand is unlocked, the new process is already
      visible to the find_task_by_pid(), but have a copy of parent's
      'struct pid' in ->pids[PIDTYPE_TGID].
      
      This means that __group_complete_signal() may hang while doing
      
      	do ... while (next_thread() != p)
      
      We can solve this problem if we reverse these 2 attach_pid()s:
      
      	attach_pid() does wmb()
      
      	group_send_sig_info() calls spin_lock(), which
      	provides a read barrier. // Yes ?
      
      I don't think we can hit this race in practice, but still.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dadac81b
    • O
      [PATCH] fix kill_proc_info() vs CLONE_THREAD race · 3f17da69
      Oleg Nesterov 提交于
      There is a window after copy_process() unlocks ->sighand.siglock
      and before it adds the new thread to the thread list.
      
      In that window __group_complete_signal(SIGKILL) will not see the
      new thread yet, so this thread will start running while the whole
      thread group was supposed to exit.
      
      I beleive we have another good reason to place attach_pid(PID/TGID)
      under ->sighand.siglock. We can do the same for
      
      	release_task()->__unhash_process()
      
      	de_thread()->switch_exec_pids()
      
      After that we don't need tasklist_lock to iterate over the thread
      list, and we can simplify things, see for example do_sigaction()
      or sys_times().
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3f17da69
    • L
      7775aa76
  2. 15 2月, 2006 31 次提交