1. 27 8月, 2015 1 次提交
  2. 26 8月, 2015 1 次提交
    • G
      powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case · 4d9aac39
      Guilherme G. Piccoli 提交于
      Since commit 1851617c ("PCI/MSI: Disable MSI at enumeration even if
      kernel doesn't support MSI"), the setup of dev->msi_cap/msix_cap and the
      disable of MSI/MSI-X interrupts isn't being done at PCI probe time, as
      the logic responsible for this was moved in the aforementioned commit
      from pci_device_add() to pci_setup_device(). The latter function is not
      reachable on PowerPC pseries platform during Open Firmware PCI probing
      time.
      
      This exhibits as drivers not being able to enable MSI, eg:
      
        bnx2x 0000:01:00.0: no msix capability found
      
      This patch calls pci_msi_setup_pci_dev() explicitly to disable MSI/MSI-X
      during PCI probe time on pSeries platform.
      
      Fixes: 1851617c ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
      [mpe: Flesh out change log and clarify comment]
      Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      4d9aac39
  3. 22 8月, 2015 3 次提交
    • T
      x86/apic: Fix fallout from x2apic cleanup · a57e456a
      Thomas Gleixner 提交于
      In the recent x2apic cleanup I got two things really wrong:
      1) The safety check in __disable_x2apic which allows the function to
         be called unconditionally is backwards. The check is there to
         prevent access to the apic MSR in case that the machine has no
         apic. Though right now it returns if the machine has an apic and
         therefor the disabling of x2apic is never invoked.
      
      2) x2apic_disable() sets x2apic_mode to 0 after registering the local
         apic. That's wrong, because register_lapic_address() checks x2apic
         mode and therefor takes the wrong code path.
      
      This results in boot failures on machines with x2apic preenabled by
      BIOS and can also lead to an fatal MSR access on machines without
      apic.
      
      The solutions are simple:
      1) Correct the sanity check for apic availability
      2) Clear x2apic_mode _before_ calling register_lapic_address()
      
      Fixes: 659006bf 'x86/x2apic: Split enable and setup function'
      Reported-and-tested-by: NJavier Monteagudo <javiermon@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1224764
      Cc: stable@vger.kernel.org # 4.0+
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      a57e456a
    • I
      x86/fpu/math-emu: Fix crash in fork() · 827409b2
      Ingo Molnar 提交于
      During later stages of math-emu bootup the following crash triggers:
      
      	 math_emulate: 0060:c100d0a8
      	 Kernel panic - not syncing: Math emulation needed in kernel
      	 CPU: 0 PID: 1511 Comm: login Not tainted 4.2.0-rc7+ #1012
      	 [...]
      	 Call Trace:
      	  [<c181d50d>] dump_stack+0x41/0x52
      	  [<c181c918>] panic+0x77/0x189
      	  [<c1003530>] ? math_error+0x140/0x140
      	  [<c164c2d7>] math_emulate+0xba7/0xbd0
      	  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
      	  [<c1109c3c>] ? __alloc_pages_nodemask+0x12c/0x870
      	  [<c136ac20>] ? proc_clear_tty+0x40/0x70
      	  [<c136ac6e>] ? session_clear_tty+0x1e/0x30
      	  [<c1003530>] ? math_error+0x140/0x140
      	  [<c1003575>] do_device_not_available+0x45/0x70
      	  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
      	  [<c18258e6>] error_code+0x5a/0x60
      	  [<c1003530>] ? math_error+0x140/0x140
      	  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
      	  [<c100c205>] arch_dup_task_struct+0x25/0x30
      	  [<c1048cea>] copy_process.part.51+0xea/0x1480
      	  [<c115a8e5>] ? dput+0x175/0x200
      	  [<c136af70>] ? no_tty+0x30/0x30
      	  [<c1157242>] ? do_vfs_ioctl+0x322/0x540
      	  [<c104a21a>] _do_fork+0xca/0x340
      	  [<c1057b06>] ? SyS_rt_sigaction+0x66/0x90
      	  [<c104a557>] SyS_clone+0x27/0x30
      	  [<c1824a80>] sysenter_do_call+0x12/0x12
      
      The reason is the incorrect assumption in fpu_copy(), that FNSAVE
      can be executed from math-emu kernels as well.
      
      Don't try to copy the registers, the soft state will be copied
      by fork anyway, so the child task inherits the parent task's
      soft math state.
      
      With this fix applied math-emu kernels boot up fine on modern
      hardware and the 'no387 nofxsr' boot options.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Bobby Powers <bobbypowers@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      827409b2
    • I
      x86/fpu/math-emu: Fix math-emu boot crash · 5fc96038
      Ingo Molnar 提交于
      On a math-emu bootup the following crash occurs:
      
      	Initializing CPU#0
      	------------[ cut here ]------------
      	kernel BUG at arch/x86/kernel/traps.c:779!
      	invalid opcode: 0000 [#1] SMP
      	[...]
      	EIP is at do_device_not_available+0xe/0x70
      	[...]
      	Call Trace:
      	 [<c18238e6>] error_code+0x5a/0x60
      	 [<c1002bd0>] ? math_error+0x140/0x140
      	 [<c100bbd9>] ? fpu__init_cpu+0x59/0xa0
      	 [<c1012322>] cpu_init+0x202/0x330
      	 [<c104509f>] ? __native_set_fixmap+0x1f/0x30
      	 [<c1b56ab0>] trap_init+0x305/0x346
      	 [<c1b548af>] start_kernel+0x1a5/0x35d
      	 [<c1b542b4>] i386_start_kernel+0x82/0x86
      
      The reason is that in the following commit:
      
        b1276c48 ("x86/fpu: Initialize fpregs in fpu__init_cpu_generic()")
      
      I failed to consider math-emu's limitation that it cannot execute the
      FNINIT instruction in kernel mode.
      
      The long term fix might be to allow math-emu to execute (certain) kernel
      mode FPU instructions, but for now apply the safe (albeit somewhat ugly)
      fix: initialize the emulation state explicitly without trapping out to
      the FPU emulator.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      5fc96038
  4. 21 8月, 2015 1 次提交
  5. 20 8月, 2015 2 次提交
  6. 19 8月, 2015 1 次提交
  7. 18 8月, 2015 4 次提交
    • M
      ARM: 8418/1: add boot image dependencies to not generate invalid images · 3939f334
      Masahiro Yamada 提交于
      U-Boot is often used to boot the kernel on ARM boards, but uImage
      is not built by "make all", so we are often inclined to do
      "make all uImage" to generate DTBs, modules and uImage in a single
      command, but we should notice a pitfall behind it.  In fact,
      "make all uImage" could generate an invalid uImage if it is run with
      the parallel option (-j).
      
      You can reproduce this problem with the following procedure:
      
      [1] First, build "all" and "uImage" separately.
          You will get a valid uImage
      
        $ git clean -f -x -d
        $ export CROSS_COMPILE=<your-tools-prefix>
        $ make -s -j8 ARCH=arm multi_v7_defconfig
        $ make -s -j8 ARCH=arm all
        $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 uImage
          CHK     include/config/kernel.release
          CHK     include/generated/uapi/linux/version.h
          CHK     include/generated/utsrelease.h
        make[1]: `include/generated/mach-types.h' is up to date.
          CHK     include/generated/timeconst.h
          CHK     include/generated/bounds.h
          CHK     include/generated/asm-offsets.h
          CALL    scripts/checksyscalls.sh
          CHK     include/generated/compile.h
          Kernel: arch/arm/boot/Image is ready
          Kernel: arch/arm/boot/zImage is ready
          UIMAGE  arch/arm/boot/uImage
        Image Name:   Linux-4.2.0-rc5-00156-gdd2384a7-d
        Created:      Sat Aug  8 23:21:35 2015
        Image Type:   ARM Linux Kernel Image (uncompressed)
        Data Size:    6138648 Bytes = 5994.77 kB = 5.85 MB
        Load Address: 80208000
        Entry Point:  80208000
          Image arch/arm/boot/uImage is ready
        $ ls -l arch/arm/boot/*Image
        -rwxrwxr-x 1 masahiro masahiro 13766656 Aug  8 23:20 arch/arm/boot/Image
        -rw-rw-r-- 1 masahiro masahiro  6138712 Aug  8 23:21 arch/arm/boot/uImage
        -rwxrwxr-x 1 masahiro masahiro  6138648 Aug  8 23:20 arch/arm/boot/zImage
      
      [2] Update some source file(s)
      
        $ touch init/main.c
      
      [3] Then, re-build "all" and "uImage" simultaneously.
          You will get an invalid uImage at random.
      
        $ make -j8 ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage
          CHK     include/config/kernel.release
          CHK     include/generated/uapi/linux/version.h
          CHK     include/generated/utsrelease.h
        make[1]: `include/generated/mach-types.h' is up to date.
          CHK     include/generated/timeconst.h
          CHK     include/generated/bounds.h
          CHK     include/generated/asm-offsets.h
          CALL    scripts/checksyscalls.sh
          CC      init/main.o
          CHK     include/generated/compile.h
          LD      init/built-in.o
          LINK    vmlinux
          LD      vmlinux.o
          MODPOST vmlinux.o
          GEN     .version
          CHK     include/generated/compile.h
          UPD     include/generated/compile.h
          CC      init/version.o
          LD      init/built-in.o
          KSYM    .tmp_kallsyms1.o
          KSYM    .tmp_kallsyms2.o
          LD      vmlinux
          SORTEX  vmlinux
          SYSMAP  System.map
          OBJCOPY arch/arm/boot/Image
          Building modules, stage 2.
          Kernel: arch/arm/boot/Image is ready
          GZIP    arch/arm/boot/compressed/piggy.gzip
          AS      arch/arm/boot/compressed/piggy.gzip.o
          Kernel: arch/arm/boot/Image is ready
          LD      arch/arm/boot/compressed/vmlinux
          GZIP    arch/arm/boot/compressed/piggy.gzip
          OBJCOPY arch/arm/boot/zImage
          Kernel: arch/arm/boot/zImage is ready
          UIMAGE  arch/arm/boot/uImage
        Image Name:   Linux-4.2.0-rc5-00156-gdd2384a7-d
        Created:      Sat Aug  8 23:23:14 2015
        Image Type:   ARM Linux Kernel Image (uncompressed)
        Data Size:    26472 Bytes = 25.85 kB = 0.03 MB
        Load Address: 80208000
        Entry Point:  80208000
          Image arch/arm/boot/uImage is ready
          MODPOST 192 modules
          AS      arch/arm/boot/compressed/piggy.gzip.o
          LD      arch/arm/boot/compressed/vmlinux
          OBJCOPY arch/arm/boot/zImage
          Kernel: arch/arm/boot/zImage is ready
        $ ls -l arch/arm/boot/*Image
        -rwxrwxr-x 1 masahiro masahiro 13766656 Aug  8 23:23 arch/arm/boot/Image
        -rw-rw-r-- 1 masahiro masahiro    26536 Aug  8 23:23 arch/arm/boot/uImage
        -rwxrwxr-x 1 masahiro masahiro  6138648 Aug  8 23:23 arch/arm/boot/zImage
      
      Please notice the uImage is extremely small when this issue is
      encountered.  Besides, "Kernel: arch/arm/boot/zImage is ready" is
      displayed twice, before and after the uImage log.
      
      The root cause of this is the race condition between zImage and
      uImage.  Actually, uImage depends on zImage, but the dependency
      between the two is only described in arch/arm/boot/Makefile.
      Because arch/arm/boot/Makefile is not included from the top-level
      Makefile, it cannot know the dependency between zImage and uImage.
      
      Consequently, when we run make with the parallel option, Kbuild
      updates vmlinux first, and then two different threads descends into
      the arch/arm/boot/Makefile almost at the same time, one for updating
      zImage and the other for uImage.  While one thread is re-generating
      zImage, the other also tries to update zImage before creating uImage
      on top of that.  zImage is overwritten by the slower thread and then
      uImage is created based on the half-written zImage.
      
      This is the reason why "Kernel: arch/arm/boot/zImage is ready" is
      displayed twice, and a broken uImage is created.
      
      The same problem could happen on bootpImage.
      
      This commit adds dependencies among Image, zImage, uImage, and
      bootpImage to arch/arm/Makefile, which is included from the
      top-level Makefile.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3939f334
    • N
      ARM: 8414/1: __copy_to_user_memcpy: fix mmap semaphore usage · 0f64b247
      Nicolas Pitre 提交于
      The mmap semaphore should not be taken when page faults are disabled.
      Since pagefault_disable() no longer disables preemption, we now need
      to use faulthandler_disabled() in place of in_atomic().
      Signed-off-by: NNicolas Pitre <nico@linaro.org>
      Tested-by: NMark Salter <msalter@redhat.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      0f64b247
    • R
      MIPS: Fix LLVM build issue. · 158d3b2a
      Ralf Baechle 提交于
      Matthew Fortune <Matthew.Fortune@imgtec.com> reports:
      
      The genex.S file appears to mix the case of a macro between its definition and
      use. A cut down example of this is below. The macro __build_clear_none has
      lower case 'build' but ends up being instantiated with upper case BUILD. Can
      this be fixed on master. It has been picked up by the LLVM integrated assembler
      which is currently case sensitive. We are likely to fix the assembler as well
      but the code is currently inconsistent in the kernel.
      
       .macro __build_clear_none
       .endm
      
       .macro __BUILD_HANDLER exception handler clear verbose ext
       .align 5
       .globl handle_\exception; .align 2; .type handle_\exception, @function; .ent
      handle_\exception, 0; handle_\exception: .frame $29, 184, $29
       .set noat
       .globl handle_\exception\ext; .type handle_\exception\ext, @function;
      handle_\exception\ext:
       __BUILD_clear_\clear
       .endm
      
       .macro BUILD_HANDLER exception handler clear verbose
       __BUILD_HANDLER \exception \handler \clear \verbose _int
       .endm
      
      BUILD_HANDLER ftlb ftlb none silent
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Reported-by: NMatthew Fortune <Matthew.Fortune@imgtec.com>
      158d3b2a
    • A
      Revert "sched/x86_64: Don't save flags on context switch" · 512255a2
      Andy Lutomirski 提交于
      This reverts commit:
      
        2c7577a7 ("sched/x86_64: Don't save flags on context switch")
      
      It was a nice speedup.  It's also not quite correct: SYSENTER
      enables interrupts too early.
      
      We can re-add this optimization once the SYSENTER code is beaten
      into shape, which should happen in 4.3 or 4.4.
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org # v3.19
      Link: http://lkml.kernel.org/r/85f56651f59f76624e80785a8fd3bdfdd089a818.1439838962.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      512255a2
  8. 17 8月, 2015 1 次提交
  9. 16 8月, 2015 1 次提交
  10. 15 8月, 2015 2 次提交
  11. 14 8月, 2015 4 次提交
  12. 12 8月, 2015 2 次提交
    • M
      perf/x86/intel/cqm: Do not access cpu_data() from CPU_UP_PREPARE handler · d7a702f0
      Matt Fleming 提交于
      Tony reports that booting his 144-cpu machine with maxcpus=10 triggers
      the following WARN_ON():
      
      [   21.045727] WARNING: CPU: 8 PID: 647 at arch/x86/kernel/cpu/perf_event_intel_cqm.c:1267 intel_cqm_cpu_prepare+0x75/0x90()
      [   21.045744] CPU: 8 PID: 647 Comm: systemd-udevd Not tainted 4.2.0-rc4 #1
      [   21.045745] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRHSXSD1.86B.0066.R00.1506021730 06/02/2015
      [   21.045747]  0000000000000000 0000000082771b09 ffff880856333ba8 ffffffff81669b67
      [   21.045748]  0000000000000000 0000000000000000 ffff880856333be8 ffffffff8107b02a
      [   21.045750]  ffff88085b789800 ffff88085f68a020 ffffffff819e2470 000000000000000a
      [   21.045750] Call Trace:
      [   21.045757]  [<ffffffff81669b67>] dump_stack+0x45/0x57
      [   21.045759]  [<ffffffff8107b02a>] warn_slowpath_common+0x8a/0xc0
      [   21.045761]  [<ffffffff8107b15a>] warn_slowpath_null+0x1a/0x20
      [   21.045762]  [<ffffffff81036725>] intel_cqm_cpu_prepare+0x75/0x90
      [   21.045764]  [<ffffffff81036872>] intel_cqm_cpu_notifier+0x42/0x160
      [   21.045767]  [<ffffffff8109a33d>] notifier_call_chain+0x4d/0x80
      [   21.045769]  [<ffffffff8109a44e>] __raw_notifier_call_chain+0xe/0x10
      [   21.045770]  [<ffffffff8107b538>] _cpu_up+0xe8/0x190
      [   21.045771]  [<ffffffff8107b65a>] cpu_up+0x7a/0xa0
      [   21.045774]  [<ffffffff8165e920>] cpu_subsys_online+0x40/0x90
      [   21.045777]  [<ffffffff81433b37>] device_online+0x67/0x90
      [   21.045778]  [<ffffffff81433bea>] online_store+0x8a/0xa0
      [   21.045782]  [<ffffffff81430e78>] dev_attr_store+0x18/0x30
      [   21.045785]  [<ffffffff8126b6ba>] sysfs_kf_write+0x3a/0x50
      [   21.045786]  [<ffffffff8126ad40>] kernfs_fop_write+0x120/0x170
      [   21.045789]  [<ffffffff811f0b77>] __vfs_write+0x37/0x100
      [   21.045791]  [<ffffffff811f38b8>] ? __sb_start_write+0x58/0x110
      [   21.045795]  [<ffffffff81296d2d>] ? security_file_permission+0x3d/0xc0
      [   21.045796]  [<ffffffff811f1279>] vfs_write+0xa9/0x190
      [   21.045797]  [<ffffffff811f2075>] SyS_write+0x55/0xc0
      [   21.045800]  [<ffffffff81067300>] ? do_page_fault+0x30/0x80
      [   21.045804]  [<ffffffff816709ae>] entry_SYSCALL_64_fastpath+0x12/0x71
      [   21.045805] ---[ end trace fe228b836d8af405 ]---
      
      The root cause is that CPU_UP_PREPARE is completely the wrong notifier
      action from which to access cpu_data(), because smp_store_cpu_info()
      won't have been executed by the target CPU at that point, which in turn
      means that ->x86_cache_max_rmid and ->x86_cache_occ_scale haven't been
      filled out.
      
      Instead let's invoke our handler from CPU_STARTING and rename it
      appropriately.
      Reported-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Kanaka Juvva <kanaka.d.juvva@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vikas Shivappa <vikas.shivappa@intel.com>
      Link: http://lkml.kernel.org/r/1438863163-14083-1-git-send-email-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d7a702f0
    • P
      perf/x86/intel: Fix memory leak on hot-plug allocation fail · dbc72b7a
      Peter Zijlstra 提交于
      We fail to free the shared_regs allocation if the constraint_list
      allocation fails.
      
      Cure this and be more consistent in NULL-ing the pointers after free.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      dbc72b7a
  13. 11 8月, 2015 3 次提交
  14. 10 8月, 2015 5 次提交
  15. 08 8月, 2015 4 次提交
  16. 07 8月, 2015 5 次提交
    • H
      KVM: x86: Use adjustment in guest cycles when handling MSR_IA32_TSC_ADJUST · d7add054
      Haozhong Zhang 提交于
      When kvm_set_msr_common() handles a guest's write to
      MSR_IA32_TSC_ADJUST, it will calcuate an adjustment based on the data
      written by guest and then use it to adjust TSC offset by calling a
      call-back adjust_tsc_offset(). The 3rd parameter of adjust_tsc_offset()
      indicates whether the adjustment is in host TSC cycles or in guest TSC
      cycles. If SVM TSC scaling is enabled, adjust_tsc_offset()
      [i.e. svm_adjust_tsc_offset()] will first scale the adjustment;
      otherwise, it will just use the unscaled one. As the MSR write here
      comes from the guest, the adjustment is in guest TSC cycles. However,
      the current kvm_set_msr_common() uses it as a value in host TSC
      cycles (by using true as the 3rd parameter of adjust_tsc_offset()),
      which can result in an incorrect adjustment of TSC offset if SVM TSC
      scaling is enabled. This patch fixes this problem.
      Signed-off-by: NHaozhong Zhang <haozhong.zhang@intel.com>
      Cc: stable@vger.linux.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d7add054
    • P
      KVM: x86: zero IDT limit on entry to SMM · 18c3626e
      Paolo Bonzini 提交于
      The recent BlackHat 2015 presentation "The Memory Sinkhole"
      mentions that the IDT limit is zeroed on entry to SMM.
      
      This is not documented, and must have changed some time after 2010
      (see http://www.ssi.gouv.fr/uploads/IMG/pdf/IT_Defense_2010_final.pdf).
      KVM was not doing it, but the fix is easy.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      18c3626e
    • N
      KVM: s390: Fix assumption that kvm_set_irq_routing is always run successfully · 152b2839
      Nicholas Krause 提交于
      This fixes the assumption that kvm_set_irq_routing is always run
      successfully by instead making it equal to the variable r which
      we use for returning in the function kvm_arch_vm_ioctl instead
      of making r equal to zero when calling this particular function
      and incorrectly making the caller of kvm_arch_vm_ioctl think
      the function has run successfully.
      Signed-off-by: NNicholas Krause <xerofoify@gmail.com>
      Message-Id: <1438880754-27149-1-git-send-email-xerofoify@gmail.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      152b2839
    • V
      ARCv2: spinlock/rwlock/atomics: reduce 1 instruction in exponential backoff · 10971638
      Vineet Gupta 提交于
      The increment of delay counter was 2 instructions:
      Arithmatic Shfit Left (ASL) + set to 1 on overflow
      
      This can be done in 1 using ROtate Left (ROL)
      Suggested-by: NNigel Topham <ntopham@synopsys.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      10971638
    • D
      sparc64: Fix userspace FPU register corruptions. · 44922150
      David S. Miller 提交于
      If we have a series of events from userpsace, with %fprs=FPRS_FEF,
      like follows:
      
      ETRAP
      	ETRAP
      		VIS_ENTRY(fprs=0x4)
      		VIS_EXIT
      		RTRAP (kernel FPU restore with fpu_saved=0x4)
      	RTRAP
      
      We will not restore the user registers that were clobbered by the FPU
      using kernel code in the inner-most trap.
      
      Traps allocate FPU save slots in the thread struct, and FPU using
      sequences save the "dirty" FPU registers only.
      
      This works at the initial trap level because all of the registers
      get recorded into the top-level FPU save area, and we'll return
      to userspace with the FPU disabled so that any FPU use by the user
      will take an FPU disabled trap wherein we'll load the registers
      back up properly.
      
      But this is not how trap returns from kernel to kernel operate.
      
      The simplest fix for this bug is to always save all FPU register state
      for anything other than the top-most FPU save area.
      
      Getting rid of the optimized inner-slot FPU saving code ends up
      making VISEntryHalf degenerate into plain VISEntry.
      
      Longer term we need to do something smarter to reinstate the partial
      save optimizations.  Perhaps the fundament error is having trap entry
      and exit allocate FPU save slots and restore register state.  Instead,
      the VISEntry et al. calls should be doing that work.
      
      This bug is about two decades old.
      Reported-by: NJames Y Knight <jyknight@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44922150