1. 26 9月, 2006 19 次提交
  2. 23 9月, 2006 1 次提交
  3. 19 9月, 2006 1 次提交
    • I
      [PATCH] genirq core: fix handle_level_irq() · 86998aa6
      Ingo Molnar 提交于
      while porting the -rt tree to 2.6.18-rc7 i noticed the following
      screaming-IRQ scenario on an SMP system:
      
       2274  0Dn.:1 0.001ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.010ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.020ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.029ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.039ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.048ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.058ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.068ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.077ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.087ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
       2274  0Dn.:1 0.097ms: do_IRQ+0xc/0x103  <= (ret_from_intr+0x0/0xf)
      
      as it turns out, the bug is caused by handle_level_irq(), which if it
      races with another CPU already handling this IRQ, it _unmasks_ the IRQ
      line on the way out. This is not how 2.6.17 works, and we introduced
      this bug in one of the early genirq cleanups right before it went into
      -mm. (the bug was not in the genirq patchset for a long time, and we
      didnt notice the bug due to the lack of -rt rebase to the new genirq
      code. -rt, and hardirq-preemption in particular opens up such races much
      wider than anything else.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      86998aa6
  4. 17 9月, 2006 2 次提交
  5. 13 9月, 2006 2 次提交
  6. 12 9月, 2006 4 次提交
  7. 09 9月, 2006 1 次提交
    • T
      [PATCH] Use the correct restart option for futex_lock_pi · c5780e97
      Thomas Gleixner 提交于
      The current implementation of futex_lock_pi returns -ERESTART_RESTARTBLOCK
      in case that the lock operation has been interrupted by a signal.  This
      results in a return of -EINTR to userspace in case there is an handler for
      the signal.  This is wrong, because userspace expects that the lock
      function does not return in any case of signal delivery.
      
      This was not caught by my insufficient test case, but triggered a nasty
      userspace problem in an high load application scenario.  Unfortunately also
      glibc does not check for this invalid return value.
      
      Using -ERSTARTNOINTR makes sure, that the interrupted syscall is restarted.
       The restart block related code can be safely removed, as the possible
      timeout argument is an absolute time value.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c5780e97
  8. 07 9月, 2006 3 次提交
  9. 03 9月, 2006 1 次提交
  10. 02 9月, 2006 2 次提交
  11. 28 8月, 2006 4 次提交
    • N
      [PATCH] cpuset: oom panic fix · 0d673a5a
      Nick Piggin 提交于
      cpuset_excl_nodes_overlap always returns 0 if current is exiting.  This caused
      customer's systems to panic in the OOM killer when processes were having
      trouble getting memory for the final put_user in mm_release.  Even though
      there were lots of processes to kill.
      
      Change to returning 1 in this case.  This achieves parity with !CONFIG_CPUSETS
      case, and was observed to fix the problem.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Acked-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0d673a5a
    • P
      [PATCH] cpuset: top_cpuset tracks hotplug changes to cpu_online_map · 4c4d50f7
      Paul Jackson 提交于
      Change the list of cpus allowed to tasks in the top (root) cpuset to
      dynamically track what cpus are online, using a CPU hotplug notifier.  Make
      this top cpus file read-only.
      
      On systems that have cpusets configured in their kernel, but that aren't
      actively using cpusets (for some distros, this covers the majority of
      systems) all tasks end up in the top cpuset.
      
      If that system does support CPU hotplug, then these tasks cannot make use
      of CPUs that are added after system boot, because the CPUs are not allowed
      in the top cpuset.  This is a surprising regression over earlier kernels
      that didn't have cpusets enabled.
      
      In order to keep the behaviour of cpusets consistent between systems
      actively making use of them and systems not using them, this patch changes
      the behaviour of the 'cpus' file in the top (root) cpuset, making it read
      only, and making it automatically track the value of cpu_online_map.  Thus
      tasks in the top cpuset will have automatic use of hot plugged CPUs allowed
      by their cpuset.
      
      Thanks to Anton Blanchard and Nathan Lynch for reporting this problem,
      driving the fix, and earlier versions of this patch.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Cc: Nathan Lynch <ntl@pobox.com>
      Cc: Anton Blanchard <anton@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4c4d50f7
    • Y
      [PATCH] Remove redundant up() in stop_machine() · 4edb9a14
      Yingchao Zhou 提交于
      An up() is called in kernel/stop_machine.c on failure, and also in the
      caller (unconditionally).
      Signed-off-by: NZhou Yingchao <yingchao.zhou@gmail.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4edb9a14
    • O
      [PATCH] futex_find_get_task(): remove an obscure EXIT_ZOMBIE check · d015baeb
      Oleg Nesterov 提交于
      futex_find_get_task:
      
      	if (p->state == EXIT_ZOMBIE || p->exit_state == EXIT_ZOMBIE)
      		return NULL;
      
      I can't understand this.  First, p->state can't be EXIT_ZOMBIE.  The
      ->exit_state check looks strange too.  Sub-threads or tasks whose ->parent
      ignores SIGCHLD go directly to EXIT_DEAD state (I am ignoring a ptrace
      case).  Why EXIT_DEAD tasks should be ok?  Yes, EXIT_ZOMBIE is more
      important (a task may stay zombie for a long time), but this doesn't mean
      we should explicitely ignore other EXIT_XXX states.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d015baeb