1. 12 Jul, 2017 28 commits
  2. 05 Jul, 2017 12 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.36 · 9f86f302
      Greg Kroah-Hartman authored
      9f86f302
    • Wanpeng Li's avatar
      KVM: nVMX: Fix exception injection · a29fd27c
      Wanpeng Li authored
      commit d4912215 upstream.
      
       WARNING: CPU: 3 PID: 2840 at arch/x86/kvm/vmx.c:10966 nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel]
       CPU: 3 PID: 2840 Comm: qemu-system-x86 Tainted: G           OE   4.12.0-rc3+ #23
       RIP: 0010:nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel]
       Call Trace:
        ? kvm_check_async_pf_completion+0xef/0x120 [kvm]
        ? rcu_read_lock_sched_held+0x79/0x80
        vmx_queue_exception+0x104/0x160 [kvm_intel]
        ? vmx_queue_exception+0x104/0x160 [kvm_intel]
        kvm_arch_vcpu_ioctl_run+0x1171/0x1ce0 [kvm]
        ? kvm_arch_vcpu_load+0x47/0x240 [kvm]
        ? kvm_arch_vcpu_load+0x62/0x240 [kvm]
        kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
        ? kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
        ? __fget+0xf3/0x210
        do_vfs_ioctl+0xa4/0x700
        ? __fget+0x114/0x210
        SyS_ioctl+0x79/0x90
        do_syscall_64+0x81/0x220
        entry_SYSCALL64_slow_path+0x25/0x25
      
      This is triggered occasionally by running both win7 and win2016 in L2, in
      addition, EPT is disabled on both L1 and L2. It can't be reproduced easily.
      
      Commit 0b6ac343 (KVM: nVMX: Correct handling of exception injection) mentioned
      that "KVM wants to inject page-faults which it got to the guest. This function
      assumes it is called with the exit reason in vmcs02 being a #PF exception".
      Commit e011c663 (KVM: nVMX: Check all exceptions for intercept during delivery to
      L2) allows to check all exceptions for intercept during delivery to L2. However,
      there is no guarantee the exit reason is exception currently, when there is an
      external interrupt occurred on host, maybe a time interrupt for host which should
      not be injected to guest, and somewhere queues an exception, then the function
      nested_vmx_check_exception() will be called and the vmexit emulation codes will
      try to emulate the "Acknowledge interrupt on exit" behavior, the warning is
      triggered.
      
      Reusing the exit reason from the L2->L0 vmexit is wrong in this case,
      the reason must always be EXCEPTION_NMI when injecting an exception into
      L1 as a nested vmexit.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Fixes: e011c663 ("KVM: nVMX: Check all exceptions for intercept during delivery to L2")
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a29fd27c
    • Radim Krčmář's avatar
      KVM: x86: zero base3 of unusable segments · d1d3756f
      Radim Krčmář authored
      commit f0367ee1 upstream.
      
      Static checker noticed that base3 could be used uninitialized if the
      segment was not present (useable).  Random stack values probably would
      not pass VMCS entry checks.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 1aa36616 ("KVM: x86 emulator: consolidate segment accessors")
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1d3756f
    • Radim Krčmář's avatar
      KVM: x86/vPMU: fix undefined shift in intel_pmu_refresh() · f3c3ec96
      Radim Krčmář authored
      commit 34b0dadb upstream.
      
      Static analysis noticed that pmu->nr_arch_gp_counters can be 32
      (INTEL_PMC_MAX_GENERIC) and therefore cannot be used to shift 'int'.
      
      I didn't add BUILD_BUG_ON for it as we have a better checker.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 25462f7f ("KVM: x86/vPMU: Define kvm_pmu_ops to support vPMU function dispatch")
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f3c3ec96
    • Ladi Prosek's avatar
      KVM: x86: fix emulation of RSM and IRET instructions · 1eeb7942
      Ladi Prosek authored
      commit 6ed071f0 upstream.
      
      On AMD, the effect of set_nmi_mask called by emulate_iret_real and em_rsm
      on hflags is reverted later on in x86_emulate_instruction where hflags are
      overwritten with ctxt->emul_flags (the kvm_set_hflags call). This manifests
      as a hang when rebooting Windows VMs with QEMU, OVMF, and >1 vcpu.
      
      Instead of trying to merge ctxt->emul_flags into vcpu->arch.hflags after
      an instruction is emulated, this commit deletes emul_flags altogether and
      makes the emulator access vcpu->arch.hflags using two new accessors. This
      way all changes, on the emulator side as well as in functions called from
      the emulator and accessing vcpu state with emul_to_vcpu, are preserved.
      
      More details on the bug and its manifestation with Windows and OVMF:
      
        It's a KVM bug in the interaction between SMI/SMM and NMI, specific to AMD.
        I believe that the SMM part explains why we started seeing this only with
        OVMF.
      
        KVM masks and unmasks NMI when entering and leaving SMM. When KVM emulates
        the RSM instruction in em_rsm, the set_nmi_mask call doesn't stick because
        later on in x86_emulate_instruction we overwrite arch.hflags with
        ctxt->emul_flags, effectively reverting the effect of the set_nmi_mask call.
        The AMD-specific hflag of interest here is HF_NMI_MASK.
      
        When rebooting the system, Windows sends an NMI IPI to all but the current
        cpu to shut them down. Only after all of them are parked in HLT will the
        initiating cpu finish the restart. If NMI is masked, other cpus never get
        the memo and the initiating cpu spins forever, waiting for
        hal!HalpInterruptProcessorsStarted to drop. That's the symptom we observe.
      
      Fixes: a584539b ("KVM: x86: pass the whole hflags field to emulator and back")
      Signed-off-by: default avatarLadi Prosek <lprosek@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1eeb7942
    • Mark Salter's avatar
      arm64: fix NULL dereference in have_cpu_die() · 982d8d92
      Mark Salter authored
      commit 335d2c2d upstream.
      
      Commit 5c492c3f ("arm64: smp: Add function to determine if cpus are
      stuck in the kernel") added a helper function to determine if die() is
      supported in cpu_ops. This function assumes a cpu will have a valid
      cpu_ops entry, but that may not be the case for cpu0 is spin-table or
      parking protocol is used to boot secondary cpus. In that case, there
      is a NULL dereference if have_cpu_die() is called by cpu0. So add a
      check for a valid cpu_ops before dereferencing it.
      
      Fixes: 5c492c3f ("arm64: smp: Add function to determine if cpus are stuck in the kernel")
      Signed-off-by: default avatarMark Salter <msalter@redhat.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      982d8d92
    • Kamal Dasu's avatar
      mtd: nand: brcmnand: Check flash #WP pin status before nand erase/program · a4bfcab3
      Kamal Dasu authored
      commit 9d2ee0a6 upstream.
      
      On brcmnand controller v6.x and v7.x, the #WP pin is controlled through
      the NAND_WP bit in CS_SELECT register.
      
      The driver currently assumes that toggling the #WP pin is
      instantaneously enabling/disabling write-protection, but it actually
      takes some time to propagate the new state to the internal NAND chip
      logic. This behavior is sometime causing data corruptions when an
      erase/program operation is executed before write-protection has really
      been disabled.
      
      Fixes: 27c5b17c ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
      Signed-off-by: default avatarKamal Dasu <kdasu.kdev@gmail.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a4bfcab3
    • Jaedon Shin's avatar
      i2c: brcmstb: Fix START and STOP conditions · de586233
      Jaedon Shin authored
      commit 2de3ec4f upstream.
      
      The BSC data buffers to send and receive data are each of size 32 bytes
      or 8 bytes 'xfersz' depending on SoC. The problem observed for all the
      combined message transfer was if length of data transfer was a multiple
      of 'xfersz' a repeated START was being transmitted by BSC driver. Fixed
      this by appropriately setting START/STOP conditions for such transfers.
      
      Fixes: dd1aa252 ("i2c: brcmstb: Add Broadcom settop SoC i2c controller driver")
      Signed-off-by: default avatarJaedon Shin <jaedon.shin@gmail.com>
      Acked-by: default avatarKamal Dasu <kdasu.kdev@gmail.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de586233
    • Rafał Miłecki's avatar
      brcmfmac: avoid writing channel out of allocated array · 8ee78501
      Rafał Miłecki authored
      commit 77c0d0cd upstream.
      
      Our code was assigning number of channels to the index variable by
      default. If firmware reported channel we didn't predict this would
      result in using that initial index value and writing out of array. This
      never happened so far (we got a complete list of supported channels) but
      it means possible memory corruption so we should handle it anyway.
      
      This patch simply detects unexpected channel and ignores it.
      
      As we don't try to create new entry now, it's also safe to drop hw_value
      and center_freq assignment. For known channels we have these set anyway.
      
      I decided to fix this issue by assigning NULL or a target channel to the
      channel variable. This was one of possible ways, I prefefred this one as
      it also avoids using channel[index] over and over.
      
      Fixes: 58de92d2 ("brcmfmac: use static superset of channels for wiphy bands")
      Signed-off-by: default avatarRafał Miłecki <rafal@milecki.pl>
      Acked-by: default avatarArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ee78501
    • Arnd Bergmann's avatar
      infiniband: hns: avoid gcc-7.0.1 warning for uninitialized data · 65fc82ce
      Arnd Bergmann authored
      commit 5b0ff9a0 upstream.
      
      hns_roce_v1_cq_set_ci() calls roce_set_bit() on an uninitialized field,
      which will then change only a few of its bits, causing a warning with
      the latest gcc:
      
      infiniband/hw/hns/hns_roce_hw_v1.c: In function 'hns_roce_v1_cq_set_ci':
      infiniband/hw/hns/hns_roce_hw_v1.c:1854:23: error: 'doorbell[1]' is used uninitialized in this function [-Werror=uninitialized]
        roce_set_bit(doorbell[1], ROCEE_DB_OTHERS_H_ROCEE_DB_OTH_HW_SYNS_S, 1);
      
      The code is actually correct since we always set all bits of the
      port_vlan field, but gcc correctly points out that the first
      access does contain uninitialized data.
      
      This initializes the field to zero first before setting the
      individual bits.
      
      Fixes: 9a443537 ("IB/hns: Add driver files for hns RoCE driver")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      65fc82ce
    • Josh Poimboeuf's avatar
      objtool: Fix another GCC jump table detection issue · 3e51ccba
      Josh Poimboeuf authored
      commit 5c51f4ae upstream.
      
      Arnd Bergmann reported a (false positive) objtool warning:
      
        drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: rxe_responder()+0xfe: sibling call from callable instruction with changed frame pointer
      
      The issue is in find_switch_table().  It tries to find a switch
      statement's jump table by walking backwards from an indirect jump
      instruction, looking for a relocation to the .rodata section.  In this
      case it stopped walking prematurely: the first .rodata relocation it
      encountered was for a variable (resp_state_name) instead of a jump
      table, so it just assumed there wasn't a jump table.
      
      The fix is to ignore any .rodata relocation which refers to an ELF
      object symbol.  This works because the jump tables are anonymous and
      have no symbols associated with them.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Tested-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 3732710f ("objtool: Improve rare switch jump table pattern detection")
      Link: http://lkml.kernel.org/r/20170302225723.3ndbsnl4hkqbne7a@trebleSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e51ccba
    • Sudeep Holla's avatar
      clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled · 92e66676
      Sudeep Holla authored
      commit 67bcc2c5 upstream.
      
      Currently we add the virtual cpufreq device unconditionally even when
      the SCPI DVFS clock provider node is disabled. This will cause cpufreq
      driver to throw errors when it gets initailised on boot/modprobe and
      also when the CPUs are hot-plugged back in.
      
      This patch fixes the issue by adding the virtual cpufreq device only if
      the SCPI DVFS clock provider is available and registered.
      
      Fixes: 9490f01e ("clk: scpi: add support for cpufreq virtual device")
      Reported-by: default avatarMichał Zegan <webczat_200@poczta.onet.pl>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Tested-by: default avatarMichał Zegan <webczat_200@poczta.onet.pl>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92e66676