Skip to content

L
linux

Linux-御风守护者 / linux
与 Fork 源项目一致

从无法访问的项目Fork

通知 1
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 03 1月, 2009 6 次提交
  3. 02 1月, 2009 1 次提交
  5. 01 1月, 2009 1 次提交
  7. 31 12月, 2008 8 次提交
  9. 30 12月, 2008 7 次提交
  11. 27 12月, 2008 3 次提交
  13. 26 12月, 2008 4 次提交
  15. 25 12月, 2008 2 次提交
  17. 24 12月, 2008 3 次提交
  19. 23 12月, 2008 1 次提交
    • H
      x86: prioritize the FPU traps for the error code · adf77bac
      由 H. Peter Anvin 提交于 
      In the case of multiple FPU errors, prioritize the error codes,
instead of returning __SI_FAULT, which ends up pushing a 0 as the
error code to userspace, a POSIX violation.

For i386, we will simply return if there are no errors at all; for
x86-64 this is probably a "can't happen" (and the code should be
unified), but for this patch, return __SI_FAULT|SI_KERNEL if this ever
happens.
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      adf77bac
  21. 20 12月, 2008 4 次提交
    • D
      x86: fix resume (S2R) broken by Intel microcode module, on A110L · 280a9ca5
      由 Dmitry Adamushko 提交于 
      Impact: fix deadlock

This is in response to the following bug report:

Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12100
Subject         : resume (S2R) broken by Intel microcode module, on A110L
Submitter       : Andreas Mohr <andi@lisas.de>
Date            : 2008-11-25 08:48 (19 days old)
Handled-By      : Dmitry Adamushko <dmitry.adamushko@gmail.com>

[ The deadlock scenario has been discovered by Andreas Mohr ]

I think I might have a logical explanation why the system:

  (http://bugzilla.kernel.org/show_bug.cgi?id=12100)

might hang upon resuming, OTOH it should have likely hanged each and every time.

(1) possible deadlock in microcode_resume_cpu() if either 'if' section is
taken;

(2) now, I don't see it in spec. and can't experimentally verify it (newer
ucodes don't seem to be available for my Core2duo)... but logically-wise, I'd
think that when read upon resuming, the 'microcode revision' (MSR 0x8B) should
be back to its original one (we need to reload ucode anyway so it doesn't seem
logical if a cpu doesn't drop the version)... if so, the comparison with
memcmp() for the full 'struct cpu_signature' is wrong... and that's how one of
the aforementioned 'if' sections might have been triggered - leading to a
deadlock.

Obviously, in my tests I simulated loading/resuming with the ucode of the same
version (just to see that the file is loaded/re-loaded upon resuming) so this
issue has never popped up.

I'd appreciate if someone with an appropriate system might give a try to the
2nd patch (titled "fix a comparison && deadlock...").

In any case, the deadlock situation is a must-have fix.
Reported-by: NAndreas Mohr <andi@lisas.de>
Signed-off-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
Tested-by: NAndreas Mohr <andi@lisas.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Cc: <stable@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      280a9ca5
    • M
      x86, bts: memory accounting · c5dee617
      由 Markus Metzger 提交于 
      Impact: move the BTS buffer accounting to the mlock bucket

Add alloc_locked_buffer() and free_locked_buffer() functions to mm/mlock.c
to kalloc a buffer and account the locked memory to current.

Account the memory for the BTS buffer to the tracer.
Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c5dee617
    • M
      x86, bts: add fork and exit handling · bf53de90
      由 Markus Metzger 提交于 
      Impact: introduce new ptrace facility

Add arch_ptrace_untrace() function that is called when the tracer
detaches (either voluntarily or when the tracing task dies);
ptrace_disable() is only called on a voluntary detach.

Add ptrace_fork() and arch_ptrace_fork(). They are called when a
traced task is forked.

Clear DS and BTS related fields on fork.

Release DS resources and reclaim memory in ptrace_untrace(). This
releases resources already when the tracing task dies. We used to do
that when the traced task dies.
Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      bf53de90
    • J
      x86: common.c boot_cpu_stack and boot_exception_stacks should be static · 34945ede
      由 Jaswinder Singh 提交于 
      Impact: cleanup, avoid sparse warnings, reduce kernel size a bit

Fixes these sparse warnings:

 arch/x86/kernel/cpu/common.c:869:6: warning: symbol 'boot_cpu_stack' was not declared. Should it be static?
 arch/x86/kernel/cpu/common.c:910:6: warning: symbol 'boot_exception_stacks' was not declared. Should it be static?
Signed-off-by: NJaswinder Singh <jaswinder@infradead.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      34945ede