1. 17 12月, 2008 1 次提交
  2. 08 12月, 2008 1 次提交
  3. 26 11月, 2008 4 次提交
  4. 23 11月, 2008 3 次提交
  5. 21 11月, 2008 1 次提交
  6. 12 11月, 2008 1 次提交
  7. 08 11月, 2008 1 次提交
  8. 06 11月, 2008 1 次提交
  9. 30 10月, 2008 3 次提交
  10. 27 10月, 2008 1 次提交
  11. 03 10月, 2008 2 次提交
  12. 25 9月, 2008 3 次提交
  13. 24 9月, 2008 2 次提交
  14. 14 9月, 2008 3 次提交
  15. 06 9月, 2008 5 次提交
  16. 31 7月, 2008 3 次提交
  17. 27 7月, 2008 2 次提交
    • R
      x86: tracehook: TIF_NOTIFY_RESUME · 59e52130
      Roland McGrath 提交于
      This adds TIF_NOTIFY_RESUME support for x86, both 64-bit and 32-bit.
      When set, we call tracehook_notify_resume() on the way to user mode.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      59e52130
    • R
      x86: tracehook_signal_handler · 36a03308
      Roland McGrath 提交于
      This makes the x86 signal handling code use tracehook_signal_handler() in
      place of calling into ptrace guts.  The call is moved after the sa_mask
      processing, but there is no other change.  This cleanup doesn't matter to
      existing debuggers, but is the sensible thing: have all facets of the
      handler setup complete before the debugger inspects the task again.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      36a03308
  18. 22 7月, 2008 1 次提交
  19. 20 7月, 2008 1 次提交
    • P
      sched, x86: clean up hrtick implementation · 31656519
      Peter Zijlstra 提交于
      random uvesafb failures were reported against Gentoo:
      
        http://bugs.gentoo.org/show_bug.cgi?id=222799
      
      and Mihai Moldovan bisected it back to:
      
      > 8f4d37ec is first bad commit
      > commit 8f4d37ec
      > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
      > Date:   Fri Jan 25 21:08:29 2008 +0100
      >
      >    sched: high-res preemption tick
      
      Linus suspected it to be hrtick + vm86 interaction and observed:
      
      > Btw, Peter, Ingo: I think that commit is doing bad things. They aren't
      > _incorrect_ per se, but they are definitely bad.
      >
      > Why?
      >
      > Using random _TIF_WORK_MASK flags is really impolite for doing
      > "scheduling" work. There's a reason that arch/x86/kernel/entry_32.S
      > special-cases the _TIF_NEED_RESCHED flag: we don't want to exit out of
      > vm86 mode unnecessarily.
      >
      > See the "work_notifysig_v86" label, and how it does that
      > "save_v86_state()" thing etc etc.
      
      Right, I never liked having to fiddle with those TIF flags. Initially I
      needed it because the hrtimer base lock could not nest in the rq lock.
      That however is fixed these days.
      
      Currently the only reason left to fiddle with the TIF flags is remote
      wakeups. We cannot program a remote cpu's hrtimer. I've been thinking
      about using the new and improved IPI function call stuff to implement
      hrtimer_start_on().
      
      However that does require that smp_call_function_single(.wait=0) works
      from interrupt context - /me looks at the latest series from Jens - Yes
      that does seem to be supported, good.
      
      Here's a stab at cleaning this stuff up ...
      
      Mihai reported test success as well.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Tested-by: NMihai Moldovan <ionic@ionic.de>
      Cc: Michal Januszewski <spock@gentoo.org>
      Cc: Antonino Daplas <adaplas@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      31656519
  20. 19 7月, 2008 1 次提交