1. 12 Jul, 2017 31 commits
  2. 05 Jul, 2017 9 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.11.9 · f82a53b8
      Greg Kroah-Hartman authored
      f82a53b8
    • David S. Miller's avatar
      hsi: Fix build regression due to netdev destructor fix. · f2912563
      David S. Miller authored
      commit ed66e50d upstream.
      
      > ../drivers/hsi/clients/ssi_protocol.c:1069:5: error: 'struct net_device' has no member named 'destructor'
      Reported-by: default avatarMark Brown <broonie@kernel.org>
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2912563
    • Steffen Klassert's avatar
      esp4: Fix udpencap for local TCP packets. · a5afcf85
      Steffen Klassert authored
      [ Upstream commit 0e78a873 ]
      
      Locally generated TCP packets are usually cloned, so we
      do skb_cow_data() on this packets. After that we need to
      reload the pointer to the esp header. On udpencap this
      header has an offset to skb_transport_header, so take this
      offset into account.
      
      This is a backport of:
      commit 0e78a873 ("esp4: Fix udpencap for local TCP packets.")
      
      Fixes: 67d349ed ("net/esp4: Fix invalid esph pointer crash")
      Fixes: fca11ebd ("esp4: Reorganize esp_output")
      Reported-by: default avatarDon Bowman <db@donbowman.ca>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5afcf85
    • Wanpeng Li's avatar
      KVM: nVMX: Fix exception injection · b9a1254c
      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>
      b9a1254c
    • Radim Krčmář's avatar
      KVM: x86: zero base3 of unusable segments · bde69037
      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>
      bde69037
    • Radim Krčmář's avatar
      KVM: x86/vPMU: fix undefined shift in intel_pmu_refresh() · 02800188
      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>
      02800188
    • Ladi Prosek's avatar
      KVM: x86: fix emulation of RSM and IRET instructions · 3d2a8efd
      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>
      3d2a8efd
    • Thomas Petazzoni's avatar
      mtd: nand: fsmc: fix NAND width handling · 51c3bb1d
      Thomas Petazzoni authored
      commit ee56874f upstream.
      
      In commit eea62819 ("mtd: Add device-tree support to fsmc_nand"),
      Device Tree support was added to the fmsc_nand driver. However, this
      code has a bug in how it handles the bank-width DT property to set the
      bus width.
      
      Indeed, in the function fsmc_nand_probe_config_dt() that parses the
      Device Tree, it sets pdata->width to either 8 or 16 depending on the
      value of the bank-width DT property.
      
      Then, the ->probe() function will test if pdata->width is equal to
      FSMC_NAND_BW16 (which is 2) to set NAND_BUSWIDTH_16 in
      nand->options. Therefore, with the DT probing, this condition will never
      match.
      
      This commit fixes that by removing the "width" field from
      fsmc_nand_platform_data and instead have the fsmc_nand_probe_config_dt()
      function directly set the appropriate nand->options value.
      
      It is worth mentioning that if this commit gets backported to older
      kernels, prior to the drop of non-DT probing, then non-DT probing will
      be broken because nand->options will no longer be set to
      NAND_BUSWIDTH_16.
      
      Fixes: eea62819 ("mtd: Add device-tree support to fsmc_nand")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51c3bb1d
    • Kamal Dasu's avatar
      mtd: nand: brcmnand: Check flash #WP pin status before nand erase/program · f34b2f6f
      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>
      f34b2f6f