1. 13 1月, 2019 31 次提交
  2. 10 1月, 2019 9 次提交
    • G
      Linux 4.19.14 · f630d3cc
      Greg Kroah-Hartman 提交于
      f630d3cc
    • P
      MIPS: Only include mmzone.h when CONFIG_NEED_MULTIPLE_NODES=y · a4a929aa
      Paul Burton 提交于
      commit 66a4059ba72c23ae74a7c702894ff76c4b7eac1f upstream.
      
      MIPS' asm/mmzone.h includes the machine/platform mmzone.h
      unconditionally, but since commit bb53fdf395ee ("MIPS: c-r4k: Add
      r4k_blast_scache_node for Loongson-3") is included by asm/rk4cache.h for
      all r4k-style configs regardless of CONFIG_NEED_MULTIPLE_NODES.
      
      This is problematic when CONFIG_NEED_MULTIPLE_NODES=n because both the
      loongson3 & ip27 mmzone.h headers unconditionally define the NODE_DATA
      preprocessor macro which is aready defined by linux/mmzone.h, resulting
      in the following build error:
      
        In file included from ./arch/mips/include/asm/mmzone.h:10,
                         from ./arch/mips/include/asm/r4kcache.h:23,
                         from arch/mips/mm/c-r4k.c:33:
        ./arch/mips/include/asm/mach-loongson64/mmzone.h:48: error: "NODE_DATA" redefined [-Werror]
         #define NODE_DATA(n)  (&__node_data[(n)]->pglist)
      
        In file included from ./include/linux/topology.h:32,
                         from ./include/linux/irq.h:19,
                         from ./include/asm-generic/hardirq.h:13,
                         from ./arch/mips/include/asm/hardirq.h:16,
                         from ./include/linux/hardirq.h:9,
                         from arch/mips/mm/c-r4k.c:11:
        ./include/linux/mmzone.h:907: note: this is the location of the previous definition
         #define NODE_DATA(nid)  (&contig_page_data)
      
      Resolve this by only including the machine mmzone.h when
      CONFIG_NEED_MULTIPLE_NODES=y, which also removes the need for the empty
      mach-generic version of the header which we delete.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Fixes: bb53fdf395ee ("MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3")
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a4a929aa
    • L
      spi: bcm2835: Unbreak the build of esoteric configs · feb0be15
      Lukas Wunner 提交于
      commit 29bdedfd9cf40e59456110ca417a8cb672ac9b92 upstream.
      
      Commit e82b0b382845 ("spi: bcm2835: Fix race on DMA termination") broke
      the build with COMPILE_TEST=y on arches whose cmpxchg() requires 32-bit
      operands (xtensa, older arm ISAs).
      
      Fix by changing the dma_pending flag's type from bool to unsigned int.
      
      Fixes: e82b0b382845 ("spi: bcm2835: Fix race on DMA termination")
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Cc: Frank Pavlic <f.pavlic@kunbus.de>
      Cc: Martin Sperl <kernel@martin.sperl.org>
      Cc: Noralf Trønnes <noralf@tronnes.org>
      Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      feb0be15
    • T
      tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x · 62977aad
      Tomas Winkler 提交于
      commit 2ba5780ce30549cf57929b01d8cba6fe656e31c5 upstream.
      
      tpm_i2c_nuvoton calculated commands duration using TPM 1.x
      values via tpm_calc_ordinal_duration() also for TPM 2.x chips.
      Call tpm2_calc_ordinal_duration() for retrieving ordinal
      duration for TPM 2.X chips.
      
      Cc: stable@vger.kernel.org
      Cc: Nayna Jain <nayna@linux.vnet.ibm.com>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Reviewed-by: NNayna Jain <nayna@linux.ibm.com>
      Tested-by: Nayna Jain <nayna@linux.ibm.com> (For TPM 2.0)
      Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      62977aad
    • T
      tpm: tpm_try_transmit() refactor error flow. · 7f4a7b1b
      Tomas Winkler 提交于
      commit 01f54664a4db0d612de0ece8e0022f21f9374e9b upstream.
      
      First, rename out_no_locality to out_locality for bailing out on
      both tpm_cmd_ready() and tpm_request_locality() failure.
      Second, ignore the return value of go_to_idle() as  it may override
      the return value of the actual tpm operation, the go_to_idle() error
      will be caught on any consequent command.
      Last, fix the wrong 'goto out', that jumped back instead of forward.
      
      Cc: stable@vger.kernel.org
      Fixes: 627448e8 ("tpm: separate cmd_ready/go_idle from runtime_pm")
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Reviewed-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Tested-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f4a7b1b
    • W
      arm64: compat: Avoid sending SIGILL for unallocated syscall numbers · 920735c6
      Will Deacon 提交于
      commit 169113ece0f29ebe884a6cfcf57c1ace04d8a36a upstream.
      
      The ARM Linux kernel handles the EABI syscall numbers as follows:
      
        0           - NR_SYSCALLS-1	: Invoke syscall via syscall table
        NR_SYSCALLS - 0xeffff		: -ENOSYS (to be allocated in future)
        0xf0000     - 0xf07ff		: Private syscall or -ENOSYS if not allocated
        > 0xf07ff			: SIGILL
      
      Our compat code gets this wrong and ends up sending SIGILL in response
      to all syscalls greater than NR_SYSCALLS which have a value greater
      than 0x7ff in the bottom 16 bits.
      
      Fix this by defining the end of the ARM private syscall region and
      checking the syscall number against that directly. Update the comment
      while we're at it.
      
      Cc: <stable@vger.kernel.org>
      Cc: Dave Martin <Dave.Martin@arm.com>
      Reported-by: NPi-Hsun Shih <pihsun@chromium.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      920735c6
    • R
      iommu/arm-smmu-v3: Fix big-endian CMD_SYNC writes · 1817b2cc
      Robin Murphy 提交于
      commit 3cd508a8c1379427afb5e16c2e0a7c986d907853 upstream.
      
      When we insert the sync sequence number into the CMD_SYNC.MSIData field,
      we do so in CPU-native byte order, before writing out the whole command
      as explicitly little-endian dwords. Thus on big-endian systems, the SMMU
      will receive and write back a byteswapped version of sync_nr, which would
      be perfect if it were targeting a similarly-little-endian ITS, but since
      it's actually writing back to memory being polled by the CPUs, they're
      going to end up seeing the wrong thing.
      
      Since the SMMU doesn't care what the MSIData actually contains, the
      minimal-overhead solution is to simply add an extra byteswap initially,
      such that it then writes back the big-endian format directly.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 37de98f8 ("iommu/arm-smmu-v3: Use CMD_SYNC completion MSI")
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1817b2cc
    • G
      KVM: arm/arm64: vgic: Fix off-by-one bug in vgic_get_irq() · f318d0cf
      Gustavo A. R. Silva 提交于
      commit c23b2e6fc4ca346018618266bcabd335c0a8a49e upstream.
      
      When using the nospec API, it should be taken into account that:
      
      "...if the CPU speculates past the bounds check then
       * array_index_nospec() will clamp the index within the range of [0,
       * size)."
      
      The above is part of the header for macro array_index_nospec() in
      linux/nospec.h
      
      Now, in this particular case, if intid evaluates to exactly VGIC_MAX_SPI
      or to exaclty VGIC_MAX_PRIVATE, the array_index_nospec() macro ends up
      returning VGIC_MAX_SPI - 1 or VGIC_MAX_PRIVATE - 1 respectively, instead
      of VGIC_MAX_SPI or VGIC_MAX_PRIVATE, which, based on the original logic:
      
      	/* SGIs and PPIs */
      	if (intid <= VGIC_MAX_PRIVATE)
       		return &vcpu->arch.vgic_cpu.private_irqs[intid];
      
       	/* SPIs */
      	if (intid <= VGIC_MAX_SPI)
       		return &kvm->arch.vgic.spis[intid - VGIC_NR_PRIVATE_IRQS];
      
      are valid values for intid.
      
      Fix this by calling array_index_nospec() macro with VGIC_MAX_PRIVATE + 1
      and VGIC_MAX_SPI + 1 as arguments for its parameter size.
      
      Fixes: 41b87599 ("KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()")
      Cc: stable@vger.kernel.org
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      [dropped the SPI part which was fixed separately]
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f318d0cf
    • C
      KVM: arm/arm64: vgic-v2: Set active_source to 0 when restoring state · 47ffaa7d
      Christoffer Dall 提交于
      commit 60c3ab30d8c2ff3a52606df03f05af2aae07dc6b upstream.
      
      When restoring the active state from userspace, we don't know which CPU
      was the source for the active state, and this is not architecturally
      exposed in any of the register state.
      
      Set the active_source to 0 in this case.  In the future, we can expand
      on this and exposse the information as additional information to
      userspace for GICv2 if anyone cares.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47ffaa7d