1. 22 3月, 2020 1 次提交
  2. 20 3月, 2020 2 次提交
    • G
      KVM: PPC: Fix kernel crash with PR KVM · 1d0c32ec
      Greg Kurz 提交于
      With PR KVM, shutting down a VM causes the host kernel to crash:
      
      [  314.219284] BUG: Unable to handle kernel data access on read at 0xc00800000176c638
      [  314.219299] Faulting instruction address: 0xc008000000d4ddb0
      cpu 0x0: Vector: 300 (Data Access) at [c00000036da077a0]
          pc: c008000000d4ddb0: kvmppc_mmu_pte_flush_all+0x68/0xd0 [kvm_pr]
          lr: c008000000d4dd94: kvmppc_mmu_pte_flush_all+0x4c/0xd0 [kvm_pr]
          sp: c00000036da07a30
         msr: 900000010280b033
         dar: c00800000176c638
       dsisr: 40000000
        current = 0xc00000036d4c0000
        paca    = 0xc000000001a00000   irqmask: 0x03   irq_happened: 0x01
          pid   = 1992, comm = qemu-system-ppc
      Linux version 5.6.0-master-gku+ (greg@palmb) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #17 SMP Wed Mar 18 13:49:29 CET 2020
      enter ? for help
      [c00000036da07ab0] c008000000d4fbe0 kvmppc_mmu_destroy_pr+0x28/0x60 [kvm_pr]
      [c00000036da07ae0] c0080000009eab8c kvmppc_mmu_destroy+0x34/0x50 [kvm]
      [c00000036da07b00] c0080000009e50c0 kvm_arch_vcpu_destroy+0x108/0x140 [kvm]
      [c00000036da07b30] c0080000009d1b50 kvm_vcpu_destroy+0x28/0x80 [kvm]
      [c00000036da07b60] c0080000009e4434 kvm_arch_destroy_vm+0xbc/0x190 [kvm]
      [c00000036da07ba0] c0080000009d9c2c kvm_put_kvm+0x1d4/0x3f0 [kvm]
      [c00000036da07c00] c0080000009da760 kvm_vm_release+0x38/0x60 [kvm]
      [c00000036da07c30] c000000000420be0 __fput+0xe0/0x310
      [c00000036da07c90] c0000000001747a0 task_work_run+0x150/0x1c0
      [c00000036da07cf0] c00000000014896c do_exit+0x44c/0xd00
      [c00000036da07dc0] c0000000001492f4 do_group_exit+0x64/0xd0
      [c00000036da07e00] c000000000149384 sys_exit_group+0x24/0x30
      [c00000036da07e20] c00000000000b9d0 system_call+0x5c/0x68
      
      This is caused by a use-after-free in kvmppc_mmu_pte_flush_all()
      which dereferences vcpu->arch.book3s which was previously freed by
      kvmppc_core_vcpu_free_pr(). This happens because kvmppc_mmu_destroy()
      is called after kvmppc_core_vcpu_free() since commit ff030fdf
      ("KVM: PPC: Move kvm_vcpu_init() invocation to common code").
      
      The kvmppc_mmu_destroy() helper calls one of the following depending
      on the KVM backend:
      
      - kvmppc_mmu_destroy_hv() which does nothing (Book3s HV)
      
      - kvmppc_mmu_destroy_pr() which undoes the effects of
        kvmppc_mmu_init() (Book3s PR 32-bit)
      
      - kvmppc_mmu_destroy_pr() which undoes the effects of
        kvmppc_mmu_init() (Book3s PR 64-bit)
      
      - kvmppc_mmu_destroy_e500() which does nothing (BookE e500/e500mc)
      
      It turns out that this is only relevant to PR KVM actually. And both
      32 and 64 backends need vcpu->arch.book3s to be valid when calling
      kvmppc_mmu_destroy_pr(). So instead of calling kvmppc_mmu_destroy()
      from kvm_arch_vcpu_destroy(), call kvmppc_mmu_destroy_pr() at the
      beginning of kvmppc_core_vcpu_free_pr(). This is consistent with
      kvmppc_mmu_init() being the last call in kvmppc_core_vcpu_create_pr().
      
      For the same reason, if kvmppc_core_vcpu_create_pr() returns an
      error then this means that kvmppc_mmu_init() was either not called
      or failed, in which case kvmppc_mmu_destroy() should not be called.
      Drop the line in the error path of kvm_arch_vcpu_create().
      
      Fixes: ff030fdf ("KVM: PPC: Move kvm_vcpu_init() invocation to common code")
      Signed-off-by: NGreg Kurz <groug@kaod.org>
      Reviewed-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/158455341029.178873.15248663726399374882.stgit@bahia.lan
      1d0c32ec
    • V
      arm64: compat: Fix syscall number of compat_clock_getres · 3568b889
      Vincenzo Frascino 提交于
      The syscall number of compat_clock_getres was erroneously set to 247
      (__NR_io_cancel!) instead of 264. This causes the vDSO fallback of
      clock_getres() to land on the wrong syscall for compat tasks.
      
      Fix the numbering.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 53c489e1 ("arm64: compat: Add missing syscall numbers")
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NVincenzo Frascino <vincenzo.frascino@arm.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      3568b889
  3. 19 3月, 2020 1 次提交
    • W
      arm64: kpti: Fix "kpti=off" when KASLR is enabled · c8355785
      Will Deacon 提交于
      Enabling KASLR forces the use of non-global page-table entries for kernel
      mappings, as this is a decision that we have to make very early on before
      mapping the kernel proper. When used in conjunction with the "kpti=off"
      command-line option, it is possible to use non-global kernel mappings but
      with the kpti trampoline disabled.
      
      Since commit 09e3c22a ("arm64: Use a variable to store non-global
      mappings decision"), arm64_kernel_unmapped_at_el0() reflects only the use of
      non-global mappings and does not take into account whether the kpti
      trampoline is enabled. This breaks context switching of the TPIDRRO_EL0
      register for 64-bit tasks, where the clearing of the register is deferred to
      the ret-to-user code, but it also breaks the ARM SPE PMU driver which
      helpfully recommends passing "kpti=off" on the command line!
      
      Report whether or not KPTI is actually enabled in
      arm64_kernel_unmapped_at_el0() and check the 'arm64_use_ng_mappings' global
      variable directly when determining the protection flags for kernel mappings.
      
      Cc: Mark Brown <broonie@kernel.org>
      Reported-by: NHongbo Yao <yaohongbo@huawei.com>
      Tested-by: NHongbo Yao <yaohongbo@huawei.com>
      Fixes: 09e3c22a ("arm64: Use a variable to store non-global mappings decision")
      Signed-off-by: NWill Deacon <will@kernel.org>
      c8355785
  4. 18 3月, 2020 2 次提交
    • C
      arm64: smp: fix crash_smp_send_stop() behaviour · f50b7dac
      Cristian Marussi 提交于
      On a system configured to trigger a crash_kexec() reboot, when only one CPU
      is online and another CPU panics while starting-up, crash_smp_send_stop()
      will fail to send any STOP message to the other already online core,
      resulting in fail to freeze and registers not properly saved.
      
      Moreover even if the proper messages are sent (case CPUs > 2)
      it will similarly fail to account for the booting CPU when executing
      the final stop wait-loop, so potentially resulting in some CPU not
      been waited for shutdown before rebooting.
      
      A tangible effect of this behaviour can be observed when, after a panic
      with kexec enabled and loaded, on the following reboot triggered by kexec,
      the cpu that could not be successfully stopped fails to come back online:
      
      [  362.291022] ------------[ cut here ]------------
      [  362.291525] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
      [  362.292023] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      [  362.292400] Modules linked in:
      [  362.292970] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted 5.6.0-rc4-00003-gc780b890948a #105
      [  362.293136] Hardware name: Foundation-v8A (DT)
      [  362.293382] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
      [  362.294063] pc : has_cpuid_feature+0xf0/0x348
      [  362.294177] lr : verify_local_elf_hwcaps+0x84/0xe8
      [  362.294280] sp : ffff800011b1bf60
      [  362.294362] x29: ffff800011b1bf60 x28: 0000000000000000
      [  362.294534] x27: 0000000000000000 x26: 0000000000000000
      [  362.294631] x25: 0000000000000000 x24: ffff80001189a25c
      [  362.294718] x23: 0000000000000000 x22: 0000000000000000
      [  362.294803] x21: ffff8000114aa018 x20: ffff800011156a00
      [  362.294897] x19: ffff800010c944a0 x18: 0000000000000004
      [  362.294987] x17: 0000000000000000 x16: 0000000000000000
      [  362.295073] x15: 00004e53b831ae3c x14: 00004e53b831ae3c
      [  362.295165] x13: 0000000000000384 x12: 0000000000000000
      [  362.295251] x11: 0000000000000000 x10: 00400032b5503510
      [  362.295334] x9 : 0000000000000000 x8 : ffff800010c7e204
      [  362.295426] x7 : 00000000410fd0f0 x6 : 0000000000000001
      [  362.295508] x5 : 00000000410fd0f0 x4 : 0000000000000000
      [  362.295592] x3 : 0000000000000000 x2 : ffff8000100939d8
      [  362.295683] x1 : 0000000000180420 x0 : 0000000000180480
      [  362.296011] Call trace:
      [  362.296257]  has_cpuid_feature+0xf0/0x348
      [  362.296350]  verify_local_elf_hwcaps+0x84/0xe8
      [  362.296424]  check_local_cpu_capabilities+0x44/0x128
      [  362.296497]  secondary_start_kernel+0xf4/0x188
      [  362.296998] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
      [  362.298652] SMP: stopping secondary CPUs
      [  362.300615] Starting crashdump kernel...
      [  362.301168] Bye!
      [    0.000000] Booting Linux on physical CPU 0x0000000003 [0x410fd0f0]
      [    0.000000] Linux version 5.6.0-rc4-00003-gc780b890948a (crimar01@e120937-lin) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #105 SMP PREEMPT Fri Mar 6 17:00:42 GMT 2020
      [    0.000000] Machine model: Foundation-v8A
      [    0.000000] earlycon: pl11 at MMIO 0x000000001c090000 (options '')
      [    0.000000] printk: bootconsole [pl11] enabled
      .....
      [    0.138024] rcu: Hierarchical SRCU implementation.
      [    0.153472] its@2f020000: unable to locate ITS domain
      [    0.154078] its@2f020000: Unable to locate ITS domain
      [    0.157541] EFI services will not be available.
      [    0.175395] smp: Bringing up secondary CPUs ...
      [    0.209182] psci: failed to boot CPU1 (-22)
      [    0.209377] CPU1: failed to boot: -22
      [    0.274598] Detected PIPT I-cache on CPU2
      [    0.278707] GICv3: CPU2: found redistributor 1 region 0:0x000000002f120000
      [    0.285212] CPU2: Booted secondary processor 0x0000000001 [0x410fd0f0]
      [    0.369053] Detected PIPT I-cache on CPU3
      [    0.372947] GICv3: CPU3: found redistributor 2 region 0:0x000000002f140000
      [    0.378664] CPU3: Booted secondary processor 0x0000000002 [0x410fd0f0]
      [    0.401707] smp: Brought up 1 node, 3 CPUs
      [    0.404057] SMP: Total of 3 processors activated.
      
      Make crash_smp_send_stop() account also for the online status of the
      calling CPU while evaluating how many CPUs are effectively online: this way
      the right number of STOPs is sent and all other stopped-cores's registers
      are properly saved.
      
      Fixes: 78fd584c ("arm64: kdump: implement machine_crash_shutdown()")
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      f50b7dac
    • C
      arm64: smp: fix smp_send_stop() behaviour · d0bab0c3
      Cristian Marussi 提交于
      On a system with only one CPU online, when another one CPU panics while
      starting-up, smp_send_stop() will fail to send any STOP message to the
      other already online core, resulting in a system still responsive and
      alive at the end of the panic procedure.
      
      [  186.700083] CPU3: shutdown
      [  187.075462] CPU2: shutdown
      [  187.162869] CPU1: shutdown
      [  188.689998] ------------[ cut here ]------------
      [  188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
      [  188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      [  188.692444] Modules linked in:
      [  188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 #104
      [  188.693175] Hardware name: Foundation-v8A (DT)
      [  188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
      [  188.694183] pc : has_cpuid_feature+0xf0/0x348
      [  188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8
      [  188.694410] sp : ffff800011b1bf60
      [  188.694536] x29: ffff800011b1bf60 x28: 0000000000000000
      [  188.694707] x27: 0000000000000000 x26: 0000000000000000
      [  188.694801] x25: 0000000000000000 x24: ffff80001189a25c
      [  188.694905] x23: 0000000000000000 x22: 0000000000000000
      [  188.694996] x21: ffff8000114aa018 x20: ffff800011156a38
      [  188.695089] x19: ffff800010c944a0 x18: 0000000000000004
      [  188.695187] x17: 0000000000000000 x16: 0000000000000000
      [  188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa
      [  188.695371] x13: 0000000000000002 x12: 0000000000002592
      [  188.695472] x11: 0000000000000080 x10: 00400032b5503510
      [  188.695572] x9 : 0000000000000000 x8 : ffff800010c80204
      [  188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001
      [  188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000
      [  188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8
      [  188.695919] x1 : 0000000000180420 x0 : 0000000000180480
      [  188.696253] Call trace:
      [  188.696410]  has_cpuid_feature+0xf0/0x348
      [  188.696504]  verify_local_elf_hwcaps+0x84/0xe8
      [  188.696591]  check_local_cpu_capabilities+0x44/0x128
      [  188.696666]  secondary_start_kernel+0xf4/0x188
      [  188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
      [  188.698639] ---[ end trace 3f12ca47652f7b72 ]---
      [  188.699160] Kernel panic - not syncing: Attempted to kill the idle task!
      [  188.699546] Kernel Offset: disabled
      [  188.699828] CPU features: 0x00004,20c02008
      [  188.700012] Memory Limit: none
      [  188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
      
      [root@arch ~]# echo Helo
      Helo
      [root@arch ~]# cat /proc/cpuinfo | grep proce
      processor	: 0
      
      Make smp_send_stop() account also for the online status of the calling CPU
      while evaluating how many CPUs are effectively online: this way, the right
      number of STOPs is sent, so enforcing a proper freeze of the system at the
      end of panic even under the above conditions.
      
      Fixes: 08e875c1 ("arm64: SMP support")
      Reported-by: NDave Martin <Dave.Martin@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      d0bab0c3
  5. 14 3月, 2020 3 次提交
    • V
      KVM: nVMX: avoid NULL pointer dereference with incorrect EVMCS GPAs · 95fa1010
      Vitaly Kuznetsov 提交于
      When an EVMCS enabled L1 guest on KVM will tries doing enlightened VMEnter
      with EVMCS GPA = 0 the host crashes because the
      
      evmcs_gpa != vmx->nested.hv_evmcs_vmptr
      
      condition in nested_vmx_handle_enlightened_vmptrld() will evaluate to
      false (as nested.hv_evmcs_vmptr is zeroed after init). The crash will
      happen on vmx->nested.hv_evmcs pointer dereference.
      
      Another problematic EVMCS ptr value is '-1' but it only causes host crash
      after nested_release_evmcs() invocation. The problem is exactly the same as
      with '0', we mistakenly think that the EVMCS pointer hasn't changed and
      thus nested.hv_evmcs_vmptr is valid.
      
      Resolve the issue by adding an additional !vmx->nested.hv_evmcs
      check to nested_vmx_handle_enlightened_vmptrld(), this way we will
      always be trying kvm_vcpu_map() when nested.hv_evmcs is NULL
      and this is supposed to catch all invalid EVMCS GPAs.
      
      Also, initialize hv_evmcs_vmptr to '0' in nested_release_evmcs()
      to be consistent with initialization where we don't currently
      set hv_evmcs_vmptr to '-1'.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      95fa1010
    • N
      KVM: x86: Initializing all kvm_lapic_irq fields in ioapic_write_indirect · 0c22056f
      Nitesh Narayan Lal 提交于
      Previously all fields of structure kvm_lapic_irq were not initialized
      before it was passed to kvm_bitmap_or_dest_vcpus(). Which will cause
      an issue when any of those fields are used for processing a request.
      For example not initializing the msi_redir_hint field before passing
      to the kvm_bitmap_or_dest_vcpus(), may lead to a misbehavior of
      kvm_apic_map_get_dest_lapic(). This will specifically happen when the
      kvm_lowest_prio_delivery() returns TRUE due to a non-zero garbage
      value of msi_redir_hint, which should not happen as the request belongs
      to APIC fixed delivery mode and we do not want to deliver the
      interrupt only to the lowest priority candidate.
      
      This patch initializes all the fields of kvm_lapic_irq based on the
      values of ioapic redirect_entry object before passing it on to
      kvm_bitmap_or_dest_vcpus().
      
      Fixes: 7ee30bc1 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs")
      Signed-off-by: NNitesh Narayan Lal <nitesh@redhat.com>
      Reviewed-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      [Set level to false since the value doesn't really matter. Suggested
       by Vitaly Kuznetsov. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      0c22056f
    • S
      KVM: VMX: Condition ENCLS-exiting enabling on CPU support for SGX1 · 7a57c09b
      Sean Christopherson 提交于
      Enable ENCLS-exiting (and thus set vmcs.ENCLS_EXITING_BITMAP) only if
      the CPU supports SGX1.  Per Intel's SDM, all ENCLS leafs #UD if SGX1
      is not supported[*], i.e. intercepting ENCLS to inject a #UD is
      unnecessary.
      
      Avoiding ENCLS-exiting even when it is reported as supported by the CPU
      works around a reported issue where SGX is "hard" disabled after an S3
      suspend/resume cycle, i.e. CPUID.0x7.SGX=0 and the VMCS field/control
      are enumerated as unsupported.  While the root cause of the S3 issue is
      unknown, it's definitely _not_ a KVM (or kernel) bug, i.e. this is a
      workaround for what is most likely a hardware or firmware issue.  As a
      bonus side effect, KVM saves a VMWRITE when first preparing vmcs01 and
      vmcs02.
      
      Note, SGX must be disabled in BIOS to take advantage of this workaround
      
      [*] The additional ENCLS CPUID check on SGX1 exists so that SGX can be
          globally "soft" disabled post-reset, e.g. if #MC bits in MCi_CTL are
          cleared.  Soft disabled meaning disabling SGX without clearing the
          primary CPUID bit (in leaf 0x7) and without poking into non-SGX
          CPU paths, e.g. for the VMCS controls.
      
      Fixes: 0b665d30 ("KVM: vmx: Inject #UD for SGX ENCLS instruction in guest")
      Reported-by: NToni Spets <toni.spets@iki.fi>
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      7a57c09b
  6. 13 3月, 2020 2 次提交
    • P
      x86/vector: Remove warning on managed interrupt migration · 469ff207
      Peter Xu 提交于
      The vector management code assumes that managed interrupts cannot be
      migrated away from an online CPU. free_moved_vector() has a WARN_ON_ONCE()
      which triggers when a managed interrupt vector association on a online CPU
      is cleared. The CPU offline code uses a different mechanism which cannot
      trigger this.
      
      This assumption is not longer correct because the new CPU isolation feature
      which affects the placement of managed interrupts must be able to move a
      managed interrupt away from an online CPU.
      
      There are two reasons why this can happen:
      
        1) When the interrupt is activated the affinity mask which was
           established in irq_create_affinity_masks() is handed in to
           the vector allocation code. This mask contains all CPUs to which
           the interrupt can be made affine to, but this does not take the
           CPU isolation 'managed_irq' mask into account.
      
           When the interrupt is finally requested by the device driver then the
           affinity is checked again and the CPU isolation 'managed_irq' mask is
           taken into account, which moves the interrupt to a non-isolated CPU if
           possible.
      
        2) The interrupt can be affine to an isolated CPU because the
           non-isolated CPUs in the calculated affinity mask are not online.
      
           Once a non-isolated CPU which is in the mask comes online the
           interrupt is migrated to this non-isolated CPU
      
      In both cases the regular online migration mechanism is used which triggers
      the WARN_ON_ONCE() in free_moved_vector().
      
      Case #1 could have been addressed by taking the isolation mask into
      account, but that would require a massive code change in the activation
      logic and the eventual migration event was accepted as a reasonable
      tradeoff when the isolation feature was developed. But even if #1 would be
      addressed, #2 would still trigger it.
      
      Of course the warning in free_moved_vector() was overlooked at that time
      and the above two cases which have been discussed during patch review have
      obviously never been tested before the final submission.
      
      So keep it simple and remove the warning.
      
      [ tglx: Rewrote changelog and added a comment to free_moved_vector() ]
      
      Fixes: 11ea68f5 ("genirq, sched/isolation: Isolate from handling managed interrupts")
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: Ming Lei <ming.lei@redhat.com>                                                                                                                                                                       
      Link: https://lkml.kernel.org/r/20200312205830.81796-1-peterx@redhat.com
      469ff207
    • C
      powerpc/kasan: Fix shadow memory protection with CONFIG_KASAN_VMALLOC · af3d0a68
      Christophe Leroy 提交于
      With CONFIG_KASAN_VMALLOC, new page tables are created at the time
      shadow memory for vmalloc area is unmapped. If some parts of the
      page table still have entries to the zero page shadow memory, the
      entries are wrongly marked RW.
      
      With CONFIG_KASAN_VMALLOC, almost the entire kernel address space
      is managed by KASAN. To make it simple, just create KASAN page tables
      for the entire kernel space at kasan_init(). That doesn't use much
      more space, and that's anyway already done for hash platforms.
      
      Fixes: 3d4247fc ("powerpc/32: Add support of KASAN_VMALLOC")
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/ef5248fc1f496c6b0dfdb59380f24968f25f75c5.1583513368.git.christophe.leroy@c-s.fr
      af3d0a68
  7. 12 3月, 2020 3 次提交
    • K
      perf/amd/uncore: Replace manual sampling check with CAP_NO_INTERRUPT flag · f967140d
      Kim Phillips 提交于
      Enable the sampling check in kernel/events/core.c::perf_event_open(),
      which returns the more appropriate -EOPNOTSUPP.
      
      BEFORE:
      
        $ sudo perf record -a -e instructions,l3_request_g1.caching_l3_cache_accesses true
        Error:
        The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (l3_request_g1.caching_l3_cache_accesses).
        /bin/dmesg | grep -i perf may provide additional information.
      
      With nothing relevant in dmesg.
      
      AFTER:
      
        $ sudo perf record -a -e instructions,l3_request_g1.caching_l3_cache_accesses true
        Error:
        l3_request_g1.caching_l3_cache_accesses: PMU Hardware doesn't support sampling/overflow-interrupts. Try 'perf stat'
      
      Fixes: c43ca509 ("perf/x86/amd: Add support for AMD NB and L2I "uncore" counters")
      Signed-off-by: NKim Phillips <kim.phillips@amd.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20200311191323.13124-1-kim.phillips@amd.com
      f967140d
    • E
      ARC: define __ALIGN_STR and __ALIGN symbols for ARC · 8d92e992
      Eugeniy Paltsev 提交于
      The default defintions use fill pattern 0x90 for padding which for ARC
      generates unintended "ldh_s r12,[r0,0x20]" corresponding to opcode 0x9090
      
      So use ".align 4" which insert a "nop_s" instruction instead.
      
      Cc: stable@vger.kernel.org
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      8d92e992
    • V
      ARC: show_regs: reduce lines of output · 204c7ece
      Vineet Gupta 提交于
      Before
      ------
      
      | CPU: 1 PID: 29061 Comm: tst-dynarray-at Not tainted 5.6.0-rc1-00002-g941fcc018ca6-dirty #12
      |
      | [ECR   ]: 0x00090000 =>
      | [EFA   ]: 0x00000000
      | [ERET  ]: 0x2004aa6c
      |     @off 0x2aa6c in [/lib/libc-2.31.9000.so]
            VMA: 0x20020000 to 0x20122000
      | [STAT32]: 0x80080a82 [IE U     ]
      | BTA: 0x2004aa18 SP: 0x5ffff8a8  FP: 0x5ffff8fc
      | LPS: 0x2008788e LPE: 0x20087896 LPC: 0x00000000
      | r00: 0x00000000 r01: 0x5ffff8a8 r02: 0x00000000
      | r03: 0x00000008 r04: 0xffffffff r05: 0x00000000
      | r06: 0x00000000 r07: 0x00000000 r08: 0x00000087
      | r09: 0x00000000 r10: 0x2010691c r11: 0x00000020
      | r12: 0x2003b214 r13: 0x5ffff8a8 r14: 0x20126e68
      | r15: 0x2001f26c r16: 0x2012a000 r17: 0x00000001
      | r18: 0x5ffff8fc r19: 0x00000000 r20: 0x5ffff948
      | r21: 0x00000001 r22: 0xffffffff r23: 0x5fffff8c
      | r24: 0x4008c2a8 r25: 0x2001f6e0
      
      After
      -----
      
      | CPU: 1 PID: 29061 Comm: tst-dynarray-at Not tainted 5.6.0-rc1-00002-g941fcc018ca6-dirty #12
      |   @off 0x2aa6c in [/lib/libc-2.31.9000.so]  VMA: 0x20020000 to 0x20122000
      | ECR: 0x00090000 EFA: 0x00000000 ERET: 0x2004aa6c
      | STAT32: 0x80080a82 [IE U     ]  BTA: 0x2004aa18
      | BLK: 0x2003b214  SP: 0x5ffff8a8  FP: 0x5ffff8fc
      | LPS: 0x2008788e LPE: 0x20087896 LPC: 0x00000000
      | r00: 0x00000000 r01: 0x5ffff8a8 r02: 0x00000000
      | r03: 0x00000008 r04: 0xffffffff r05: 0x00000000
      | r06: 0x00000000 r07: 0x00000000 r08: 0x00000087
      | r09: 0x00000000 r10: 0x2010691c r11: 0x00000020
      | r12: 0x2003b214 r13: 0x5ffff8a8 r14: 0x20126e68
      | r15: 0x2001f26c r16: 0x2012a000 r17: 0x00000001
      | r18: 0x5ffff8fc r19: 0x00000000 r20: 0x5ffff948
      | r21: 0x00000001 r22: 0xffffffff r23: 0x5fffff8c
      | r24: 0x4008c2a8 r25: 0x2001f6e0 BTA: 0x2004aa18
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      204c7ece
  8. 11 3月, 2020 2 次提交
  9. 07 3月, 2020 3 次提交
  10. 06 3月, 2020 7 次提交
  11. 05 3月, 2020 5 次提交
    • J
      KVM: fix Kconfig menu text for -Werror · a754acc3
      Jason A. Donenfeld 提交于
      This was evidently copy and pasted from the i915 driver, but the text
      wasn't updated.
      
      Fixes: 4f337faf ("KVM: allow disabling -Werror")
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      a754acc3
    • J
      crypto: x86/curve25519 - support assemblers with no adx support · 1579f1bc
      Jason A. Donenfeld 提交于
      Some older version of GAS do not support the ADX instructions, similarly
      to how they also don't support AVX and such. This commit adds the same
      build-time detection mechanisms we use for AVX and others for ADX, and
      then makes sure that the curve25519 library dispatcher calls the right
      functions.
      Reported-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      1579f1bc
    • M
      powerpc/mm: Fix missing KUAP disable in flush_coherent_icache() · 59bee45b
      Michael Ellerman 提交于
      Stefan reported a strange kernel fault which turned out to be due to a
      missing KUAP disable in flush_coherent_icache() called from
      flush_icache_range().
      
      The fault looks like:
      
        Kernel attempted to access user page (7fffc30d9c00) - exploit attempt? (uid: 1009)
        BUG: Unable to handle kernel data access on read at 0x7fffc30d9c00
        Faulting instruction address: 0xc00000000007232c
        Oops: Kernel access of bad area, sig: 11 [#1]
        LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
        CPU: 35 PID: 5886 Comm: sigtramp Not tainted 5.6.0-rc2-gcc-8.2.0-00003-gfc37a163 #79
        NIP:  c00000000007232c LR: c00000000003b7fc CTR: 0000000000000000
        REGS: c000001e11093940 TRAP: 0300   Not tainted  (5.6.0-rc2-gcc-8.2.0-00003-gfc37a163)
        MSR:  900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 28000884  XER: 00000000
        CFAR: c0000000000722fc DAR: 00007fffc30d9c00 DSISR: 08000000 IRQMASK: 0
        GPR00: c00000000003b7fc c000001e11093bd0 c0000000023ac200 00007fffc30d9c00
        GPR04: 00007fffc30d9c18 0000000000000000 c000001e11093bd4 0000000000000000
        GPR08: 0000000000000000 0000000000000001 0000000000000000 c000001e1104ed80
        GPR12: 0000000000000000 c000001fff6ab380 c0000000016be2d0 4000000000000000
        GPR16: c000000000000000 bfffffffffffffff 0000000000000000 0000000000000000
        GPR20: 00007fffc30d9c00 00007fffc30d8f58 00007fffc30d9c18 00007fffc30d9c20
        GPR24: 00007fffc30d9c18 0000000000000000 c000001e11093d90 c000001e1104ed80
        GPR28: c000001e11093e90 0000000000000000 c0000000023d9d18 00007fffc30d9c00
        NIP flush_icache_range+0x5c/0x80
        LR  handle_rt_signal64+0x95c/0xc2c
        Call Trace:
          0xc000001e11093d90 (unreliable)
          handle_rt_signal64+0x93c/0xc2c
          do_notify_resume+0x310/0x430
          ret_from_except_lite+0x70/0x74
        Instruction dump:
        409e002c 7c0802a6 3c62ff31 3863f6a0 f8010080 48195fed 60000000 48fe4c8d
        60000000 e8010080 7c0803a6 7c0004ac <7c00ffac> 7c0004ac 4c00012c 38210070
      
      This path through handle_rt_signal64() to setup_trampoline() and
      flush_icache_range() is only triggered by 64-bit processes that have
      unmapped their VDSO, which is rare.
      
      flush_icache_range() takes a range of addresses to flush. In
      flush_coherent_icache() we implement an optimisation for CPUs where we
      know we don't actually have to flush the whole range, we just need to
      do a single icbi.
      
      However we still execute the icbi on the user address of the start of
      the range we're flushing. On CPUs that also implement KUAP (Power9)
      that leads to the spurious fault above.
      
      We should be able to pass any address, including a kernel address, to
      the icbi on these CPUs, which would avoid any interaction with KUAP.
      But I don't want to make that change in a bug fix, just in case it
      surfaces some strange behaviour on some CPU.
      
      So for now just disable KUAP around the icbi. Note the icbi is treated
      as a load, so we allow read access, not write as you'd expect.
      
      Fixes: 890274c2 ("powerpc/64s: Implement KUAP for Radix MMU")
      Cc: stable@vger.kernel.org # v5.2+
      Reported-by: NStefan Berger <stefanb@linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200303235708.26004-1-mpe@ellerman.id.au
      59bee45b
    • A
      riscv: Fix range looking for kernel image memblock · a160eed4
      Alexandre Ghiti 提交于
      When looking for the memblock where the kernel lives, we should check
      that the memory range associated to the memblock entirely comprises the
      kernel image and not only intersects with it.
      Signed-off-by: NAlexandre Ghiti <alex@ghiti.fr>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      a160eed4
    • D
      riscv: Force flat memory model with no-mmu · aa273420
      Damien Le Moal 提交于
      Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
      a nommu kernel. Since the sparsemem model does not make sense anyway
      for the nommu case, do not allow selecting this option to always use
      the flatmem model.
      Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      Reviewed-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      aa273420
  12. 04 3月, 2020 7 次提交
  13. 03 3月, 2020 2 次提交
新手
引导
客服 返回
顶部