1. 02 Apr, 2015 2 commits
    • Steffen Liebergeld's avatar
      kgdb/x86: Fix reporting of 'si' in kgdb on x86_64 · f59df35f
      Steffen Liebergeld authored
      This patch fixes an error in kgdb for x86_64 which would report
      the value of dx when asked to give the value of si.
      Signed-off-by: default avatarSteffen Liebergeld <steffen.liebergeld@kernkonzept.com>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f59df35f
    • Andy Lutomirski's avatar
      x86/asm/entry/64: Disable opportunistic SYSRET if regs->flags has TF set · 7ea24169
      Andy Lutomirski authored
      When I wrote the opportunistic SYSRET code, I missed an important difference
      between SYSRET and IRET.
      
      Both instructions are capable of setting EFLAGS.TF, but they behave differently
      when doing so:
      
       - IRET will not issue a #DB trap after execution when it sets TF.
         This is critical -- otherwise you'd never be able to make forward progress when
         returning to userspace.
      
       - SYSRET, on the other hand, will trap with #DB immediately after
         returning to CPL3, and the next instruction will never execute.
      
      This breaks anything that opportunistically SYSRETs to a user
      context with TF set.  For example, running this code with TF set
      and a SIGTRAP handler loaded never gets past 'post_nop':
      
      	extern unsigned char post_nop[];
      	asm volatile ("pushfq\n\t"
      		      "popq %%r11\n\t"
      		      "nop\n\t"
      		      "post_nop:"
      		      : : "c" (post_nop) : "r11");
      
      In my defense, I can't find this documented in the AMD or Intel manual.
      
      Fix it by using IRET to restore TF.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 2a23c6b8 ("x86_64, entry: Use sysret to return to userspace when possible")
      Link: http://lkml.kernel.org/r/9472f1ca4c19a38ecda45bba9c91b7168135fcfa.1427923514.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7ea24169
  2. 01 Apr, 2015 1 commit
    • Stefan Lippers-Hollmann's avatar
      x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk · 80313b30
      Stefan Lippers-Hollmann authored
      The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in
      both BIOS and UEFI mode while rebooting unless reboot=pci is
      used. Add a quirk to reboot via the pci method.
      
      The problem is very intermittent and hard to debug, it might succeed
      rebooting just fine 40 times in a row - but fails half a dozen times
      the next day. It seems to be slightly less common in BIOS CSM mode
      than native UEFI (with the CSM disabled), but it does happen in either
      mode. Since I've started testing this patch in late january, rebooting
      has been 100% reliable.
      
      Most of the time it already hangs during POST, but occasionally it
      might even make it through the bootloader and the kernel might even
      start booting, but then hangs before the mode switch. The same symptoms
      occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
      kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
      Upgrading to the most current mainboard firmware of the ASRock
      Q1900DC-ITX, version 1.20, does not improve the situation.
      
      ( Searching the web seems to suggest that other Bay Trail-D mainboards
        might be affected as well. )
      --
      Signed-off-by: default avatarStefan Lippers-Hollmann <s.l-h@gmx.de>
      Cc: <stable@vger.kernel.org>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mirSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      80313b30
  3. 31 Mar, 2015 2 commits
  4. 29 Mar, 2015 7 commits
  5. 28 Mar, 2015 9 commits
  6. 27 Mar, 2015 7 commits
  7. 26 Mar, 2015 12 commits