1. 22 6月, 2007 1 次提交
    • T
      posix-timers: Prevent softirq starvation by small intervals and SIG_IGN · 58229a18
      Thomas Gleixner 提交于
      posix-timers which deliver an ignored signal are currently rearmed in
      the timer softirq: This is necessary because the timer needs to be
      delivered again when SIG_IGN is removed. This is not a problem, when
      the interval is reasonable.
      
      With high resolution timers enabled one might arm a posix timer with a
      very small interval and ignore the signal. This might lead to a
      softirq starvation when the interval is so small that the timer is
      requeued onto the softirq pending list right away.
      
      This problem was pointed out by Jan Kiszka. Thanks Jan !
      
      The correct solution would be to stop the timer, when the signal is
      ignored and rearm it when SIG_IGN is removed. Unfortunately this
      requires modification in sigaction and involves non trivial sighand
      locking. It's too late in the release cycle for such a change.
      
      For now we just keep the timer running and enforce that the timer only
      fires every jiffie. This does not break anything as we keep the
      overrun counter correct. It adds a little inaccuracy to the
      timer_gettime() interface, but...
      
      The more complex change is necessary anyway to fix another short
      coming of the current implementation, which I discovered while looking
      at this problem: A pending signal is discarded when SIG_IGN is set. In
      case that a posixtimer signal is pending then it is discarded as well,
      but when SIG_IGN is removed later nothing rearms the timer. This is
      not new, it's that way since posix timers have been merged. So nothing
      to worry about right now.
      
      I have a working solution to fix all of this, but the impact is too
      large for both stable and 2.6.22. I'm going to send it out for review
      in the next days.
      
      This should go into 2.6.21.stable as well.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Jan Kiszka <jan.kiszka@web.de>
      Cc: Ulrich Drepper <drepper@redhat.com>
      Cc: Stable Team <stable@kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      58229a18
  2. 09 5月, 2007 1 次提交
  3. 17 2月, 2007 2 次提交
  4. 12 2月, 2007 1 次提交
  5. 08 12月, 2006 1 次提交
  6. 04 10月, 2006 1 次提交
  7. 30 9月, 2006 1 次提交
  8. 27 3月, 2006 3 次提交
  9. 23 3月, 2006 1 次提交
  10. 17 3月, 2006 1 次提交
  11. 02 2月, 2006 4 次提交
  12. 15 1月, 2006 1 次提交
  13. 11 1月, 2006 5 次提交
  14. 14 11月, 2005 1 次提交
  15. 31 10月, 2005 1 次提交
  16. 22 10月, 2005 1 次提交
    • R
      [PATCH] Call exit_itimers from do_exit, not __exit_signal · 25f407f0
      Roland McGrath 提交于
      When I originally moved exit_itimers into __exit_signal, that was the only
      place where we could reliably know it was the last thread in the group
      dying, without races.  Since then we've gotten the signal_struct.live
      counter, and do_exit can reliably do group-wide cleanup work.
      
      This patch moves the call to do_exit, where it's made without locks.  This
      avoids the deadlock issues that the old __exit_signal code's comment talks
      about, and the one that Oleg found recently with process CPU timers.
      
      [ This replaces e03d13e9, which is why
        it was just reverted. ]
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      25f407f0
  17. 08 9月, 2005 1 次提交
    • O
      [PATCH] fix send_sigqueue() vs thread exit race · e752dd6c
      Oleg Nesterov 提交于
      posix_timer_event() first checks that the thread (SIGEV_THREAD_ID case)
      does not have PF_EXITING flag, then it calls send_sigqueue() which locks
      task list.  But if the thread exits in between the kernel will oops
      (->sighand == NULL after __exit_sighand).
      
      This patch moves the PF_EXITING check into the send_sigqueue(), it must be
      done atomically under tasklist_lock.  When send_sigqueue() detects exiting
      thread it returns -1.  In that case posix_timer_event will send the signal
      to thread group.
      
      Also, this patch fixes task_struct use-after-free in posix_timer_event.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e752dd6c
  18. 05 8月, 2005 1 次提交
  19. 29 7月, 2005 1 次提交
    • G
      [PATCH] posix timers: fix normalization problem · 78fa74a2
      George Anzinger 提交于
      (We found this (after a customer complained) and it is in the kernel.org
      kernel.  Seems that for CLOCK_MONOTONIC absolute timers and clock_nanosleep
      calls both the request time and wall_to_monotonic are subtracted prior to
      the normalize resulting in an overflow in the existing normalize test.
      This causes the result to be shifted ~4 seconds ahead instead of ~2 seconds
      back in time.)
      
      The normalize code in posix-timers.c fails when the tv_nsec member is ~1.2
      seconds negative.  This can happen on absolute timers (and
      clock_nanosleeps) requested on CLOCK_MONOTONIC (both the request time and
      wall_to_monotonic are subtracted resulting in the possibility of a number
      close to -2 seconds.)
      
      This fix uses the set_normalized_timespec() (which does not have an
      overflow problem) to fix the problem and as a side effect makes the code
      cleaner.
      Signed-off-by: NGeorge Anzinger <george@mvista.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      78fa74a2
  20. 24 6月, 2005 1 次提交
  21. 18 6月, 2005 1 次提交
  22. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4