1. 20 6月, 2006 4 次提交
  2. 18 6月, 2006 3 次提交
    • O
      [PATCH] arm_timer: remove a racy and obsolete PF_EXITING check · f53ae1dc
      Oleg Nesterov 提交于
      arm_timer() checks PF_EXITING to prevent BUG_ON(->exit_state)
      in run_posix_cpu_timers().
      
      However, for some reason it does so only for CPUCLOCK_PERTHREAD
      case (which is imho wrong).
      
      Also, this check is not reliable, PF_EXITING could be set on
      another cpu without any locks/barriers just after the check,
      so it can't prevent from attaching the timer to the exiting
      task.
      
      The previous patch makes this check unneeded.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f53ae1dc
    • O
      [PATCH] run_posix_cpu_timers: remove a bogus BUG_ON() · 30f1e3dd
      Oleg Nesterov 提交于
      do_exit() clears ->it_##clock##_expires, but nothing prevents
      another cpu to attach the timer to exiting process after that.
      arm_timer() tries to protect against this race, but the check
      is racy.
      
      After exit_notify() does 'write_unlock_irq(&tasklist_lock)' and
      before do_exit() calls 'schedule() local timer interrupt can find
      tsk->exit_state != 0. If that state was EXIT_DEAD (or another cpu
      does sys_wait4) interrupted task has ->signal == NULL.
      
      At this moment exiting task has no pending cpu timers, they were
      cleanuped in __exit_signal()->posix_cpu_timers_exit{,_group}(),
      so we can just return from irq.
      
      John Stultz recently confirmed this bug, see
      
      	http://marc.theaimsgroup.com/?l=linux-kernel&m=115015841413687Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      30f1e3dd
    • O
      [PATCH] check_process_timers: fix possible lockup · 8f17fc20
      Oleg Nesterov 提交于
      If the local timer interrupt happens just after do_exit() sets PF_EXITING
      (and before it clears ->it_xxx_expires) run_posix_cpu_timers() will call
      check_process_timers() with tasklist_lock + ->siglock held and
      
      	check_process_timers:
      
      		t = tsk;
      		do {
      			....
      
      			do {
      				t = next_thread(t);
      			} while (unlikely(t->flags & PF_EXITING));
      		} while (t != tsk);
      
      the outer loop will never stop.
      
      Actually, the window is bigger.  Another process can attach the timer
      after ->it_xxx_expires was cleared (see the next commit) and the 'if
      (PF_EXITING)' check in arm_timer() is racy (see the one after that).
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8f17fc20
  3. 01 6月, 2006 1 次提交
  4. 22 5月, 2006 4 次提交
    • L
      Revert "[PATCH] sched: fix interactive task starvation" · f1adad78
      Linus Torvalds 提交于
      This reverts commit 5ce74abe (and its
      dependent commit 8a5bc075), because of
      audio underruns.
      
      Reported by Rene Herman <rene.herman@keyaccess.nl>, who also pinpointed
      the exact cause of the underruns:
      
        "Audio underruns galore, with only ogg123 and firefox (browsing the
         GIT tree online is also a nice trigger by the way).
      
         If I back it out, everything is fine for me again."
      
      Cc: Rene Herman <rene.herman@keyaccess.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Acked-by: NCon Kolivas <kernel@kolivas.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f1adad78
    • Z
      [PATCH] Fix a NO_IDLE_HZ timer bug · 0662b713
      Zachary Amsden 提交于
      Under certain timing conditions, a race during boot occurs where timer
      ticks are being processed on remote CPUs.  The remote timer ticks can
      increment jiffies, and if this happens during a window when a timeout is
      very close to expiring but a local tick has not yet been delivered, you can
      end up with
      
      1) No softirq pending
      2) A local timer wheel which is not synced to jiffies
      3) No high resolution timer active
      4) A local timer which is supposed to fire before the current jiffies value.
      
      In this circumstance, the comparison in next_timer_interrupt overflows,
      because the base of the comparison for high resolution timers is jiffies,
      but for the softirq timer wheel, it is relative the the current base of the
      wheel (jiffies_base).
      Signed-off-by: NZachary Amsden <zach@vmware.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0662b713
    • P
      [PATCH] cpuset: might_sleep_if check in cpuset_zones_allowed · 92d1dbd2
      Paul Jackson 提交于
      It's too easy to incorrectly call cpuset_zone_allowed() in an atomic
      context without __GFP_HARDWALL set, and when done, it is not noticed until
      a tight memory situation forces allocations to be tried outside the current
      cpuset.
      
      Add a 'might_sleep_if()' check, to catch this earlier on, instead of
      waiting for a similar check in the mutex_lock() code, which is only rarely
      invoked.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      92d1dbd2
    • P
      [PATCH] cpuset: update cpuset_zones_allowed comment · 36be57ff
      Paul Jackson 提交于
      Update the kernel/cpuset.c:cpuset_zone_allowed() comment.
      
      The rule for when mm/page_alloc.c should call cpuset_zone_allowed()
      was intended to be:
      
        Don't call cpuset_zone_allowed() if you can't sleep, unless you
        pass in the __GFP_HARDWALL flag set in gfp_flag, which disables
        the code that might scan up ancestor cpusets and sleep.
      
      The explanation of this rule in the comment above cpuset_zone_allowed() was
      stale, as a result of a restructuring of some __alloc_pages() code in
      November 2005.
      
      Rewrite that comment ...
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      36be57ff
  5. 16 5月, 2006 2 次提交
  6. 12 5月, 2006 1 次提交
    • L
      ptrace_attach: fix possible deadlock schenario with irqs · f358166a
      Linus Torvalds 提交于
      Eric Biederman points out that we can't take the task_lock while holding
      tasklist_lock for writing, because another CPU that holds the task lock
      might take an interrupt that then tries to take tasklist_lock for writing.
      
      Which would be a nasty deadlock, with one CPU spinning forever in an
      interrupt handler (although admittedly you need to really work at
      triggering it ;)
      
      Since the ptrace_attach() code is special and very unusual, just make it
      be extra careful, and use trylock+repeat to avoid the possible deadlock.
      
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f358166a
  7. 08 5月, 2006 1 次提交
    • L
      Fix ptrace_attach()/ptrace_traceme()/de_thread() race · f5b40e36
      Linus Torvalds 提交于
      This holds the task lock (and, for ptrace_attach, the tasklist_lock)
      over the actual attach event, which closes a race between attacking to a
      thread that is either doing a PTRACE_TRACEME or getting de-threaded.
      
      Thanks to Oleg Nesterov for reminding me about this, and Chris Wright
      for noticing a lost return value in my first version.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f5b40e36
  8. 01 5月, 2006 12 次提交
  9. 28 4月, 2006 2 次提交
  10. 26 4月, 2006 2 次提交
  11. 20 4月, 2006 5 次提交
  12. 15 4月, 2006 2 次提交
  13. 14 4月, 2006 1 次提交