1. 20 Jan, 2009 1 commit
  2. 18 Jan, 2009 2 commits
  3. 16 Dec, 2008 1 commit
  4. 11 Nov, 2008 1 commit
    • Ivan Vecera's avatar
      x86: call machine_shutdown and stop all CPUs in native_machine_halt · d3ec5cae
      Ivan Vecera authored
      Impact: really halt all CPUs on halt
      Function machine_halt (resp. native_machine_halt) is empty for x86
      architectures. When command 'halt -f' is invoked, the message "System
      halted." is displayed but this is not really true because all CPUs are
      still running.
      There are also similar inconsistencies for other arches (some uses
      power-off for halt or forever-loop with IRQs enabled/disabled).
      IMO there should be used the same approach for all architectures OR
      what does the message "System halted" really mean?
      This patch fixes it for x86.
      Signed-off-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  5. 23 Oct, 2008 2 commits
  6. 13 Oct, 2008 1 commit
  7. 22 Jul, 2008 1 commit
    • Vegard Nossum's avatar
      x86: consolidate header guards · 77ef50a5
      Vegard Nossum authored
      This patch is the result of an automatic script that consolidates the
      format of all the headers in include/asm-x86/.
      The format:
      1. No leading underscore. Names with leading underscores are reserved.
      2. Pathname components are separated by two underscores. So we can
         distinguish between mm_types.h and mm/types.h.
      3. Everything except letters and numbers are turned into single
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
  8. 11 Jul, 2008 1 commit
    • Ingo Molnar's avatar
      x86: fix savesegment() bug causing crashes on 64-bit · d9fc3fd3
      Ingo Molnar authored
      i spent a fair amount of time chasing a 64-bit bootup crash that manifested
      itself as bootup segfaults:
        S10network[1825]: segfault at 7f3e2b5d16b8 ip 00000031108748c9 sp 00007fffb9c14c70 error 4 in libc-2.7.so[3110800000+14d000]
      eventually causing init to die and panic the system:
        Kernel panic - not syncing: Attempted to kill init!
        Pid: 1, comm: init Not tainted 2.6.26-rc9-tip #13878
      after a maratonic bisection session, the bad commit turned out to be:
      | b7675791859075418199c7af86a116ea34eaf5bd is first bad commit
      | commit b7675791859075418199c7af86a116ea34eaf5bd
      | Author: Jeremy Fitzhardinge <jeremy@goop.org>
      | Date:   Wed Jun 25 00:19:00 2008 -0400
      |     x86: remove open-coded save/load segment operations
      |     This removes a pile of buggy open-coded implementations of savesegment
      |     and loadsegment.
      after some more bisection of this patch itself, it turns out that what
      makes the difference are the savesegment() changes to __switch_to().
      Taking a look at this portion of arch/x86/kernel/process_64.o revealed
      this crutial difference:
      | good:    99c:       8c e0                   mov    %fs,%eax
      |          99e:       89 45 cc                mov    %eax,-0x34(%rbp)
      | bad:     99c:       8c 65 cc                mov    %fs,-0x34(%rbp)
      which is due to:
      |                 unsigned fsindex;
      | -               asm volatile("movl %%fs,%0" : "=r" (fsindex));
      | +               savesegment(fs, fsindex);
      savesegment() is implemented as:
       #define savesegment(seg, value)                                \
                asm("mov %%" #seg ",%0":"=rm" (value) : : "memory")
      note the "m" modifier - it allows GCC to generate the segment move
      into a memory operand as well.
      But regarding segment operands there's a subtle detail in the x86
      instruction set: the above 16-bit moves are zero-extend, but only
      if it goes to a register.
      If it goes to a memory operand, -0x34(%rbp) in the above case, there's
      no zero-extend to 32-bit and the instruction will only save 16 bits
      instead of the intended 32-bit.
      The other 16 bits is random data - which can cause problems when that
      value is used later on.
      The solution is to only allow segment operands to go to registers.
      This fix allows my test-system to boot up without crashing.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  9. 08 Jul, 2008 2 commits
  10. 27 May, 2008 1 commit
  11. 26 May, 2008 1 commit
    • Ingo Molnar's avatar
      x86: fix stackprotector canary updates during context switches · e0032087
      Ingo Molnar authored
      fix a bug noticed and fixed by pageexec@freemail.hu.
      if built with -fstack-protector-all then we'll have canary checks built
      into the __switch_to() function. That does not work well with the
      canary-switching code there: while we already use the %rsp of the
      new task, we still call __switch_to() whith the previous task's canary
      value in the PDA, hence the __switch_to() ssp prologue instructions
      will store the previous canary. Then we update the PDA and upon return
      from __switch_to() the canary check triggers and we panic.
      so update the canary after we have called __switch_to(), where we are
      at the same stackframe level as the last stackframe of the next
      (and now freshly current) task.
      Note: this means that we call __switch_to() [and its sub-functions]
      still with the old canary, but that is not a problem, both the previous
      and the next task has a high-quality canary. The only (mostly academic)
      disadvantage is that the canary of one task may leak onto the stack of
      another task, increasing the risk of information leaks, were an attacker
      able to read the stack of specific tasks (but not that of others).
      To solve this we'll have to reorganize the way we switch tasks, and move
      the PDA setting into the switch_to() assembly code. That will happen in
      another patch.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  12. 25 May, 2008 1 commit
  13. 17 Apr, 2008 4 commits
  14. 04 Feb, 2008 3 commits
  15. 30 Jan, 2008 9 commits
  16. 11 Oct, 2007 1 commit