commit 8c3f48e8c28823378274d2342a2ff1442a4af55f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jan 9 17:46:05 2019 +0100

    Linux 4.20.1

commit 0b8c26bf92188d81e657a998be9fad58aa03dca2
Author: Paul Burton <paul.burton@mips.com>
Date:   Wed Nov 21 19:47:57 2018 -0800

    MIPS: Only include mmzone.h when CONFIG_NEED_MULTIPLE_NODES=y
    
    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: Paul Burton <paul.burton@mips.com>
    Fixes: bb53fdf395ee ("MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14a5a1e46b1e177750c0e040e849b9729c6ee5db
Author: Lukas Wunner <lukas@wunner.de>
Date:   Thu Nov 29 15:14:49 2018 +0100

    spi: bcm2835: Unbreak the build of esoteric configs
    
    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: Lukas Wunner <lukas@wunner.de>
    Signed-off-by: Mark 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 366c2ab4bbb56c66b448bf53bc3fb166cbdf4ef2
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Fri Oct 19 21:22:47 2018 +0300

    tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x
    
    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: Tomas Winkler <tomas.winkler@intel.com>
    Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
    Tested-by: Nayna Jain <nayna@linux.ibm.com> (For TPM 2.0)
    Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13545b0748dc230c0bdf1abe2dd1dbdbd3e8120b
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Tue Oct 16 16:37:16 2018 +0300

    tpm: tpm_try_transmit() refactor error flow.
    
    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: 627448e85c76 ("tpm: separate cmd_ready/go_idle from runtime_pm")
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff96e6a7cdd4dbc07cf9047ec43a48f1d20c44f4
Author: Helge Deller <deller@gmx.de>
Date:   Fri Jan 4 23:32:53 2019 +0100

    parisc: Remap hugepage-aligned pages in set_kernel_text_rw()
    
    commit dfbaecb2b707cfdc5276b548d52b437384bd6483 upstream.
    
    The alternative coding patch for parisc in kernel 4.20 broke booting
    machines with PA8500-PA8700 CPUs. The problem is, that for such machines
    the parisc kernel automatically utilizes huge pages to access kernel
    text code, but the set_kernel_text_rw() function, which is used shortly
    before applying any alternative patches, didn't used the correctly
    hugepage-aligned addresses to remap the kernel text read-writeable.
    
    Fixes: 3847dab77421 ("parisc: Add alternative coding infrastructure")
    Cc: <stable@vger.kernel.org>    [4.20]
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6f21f8afa6e49a9a5c40b20efb7ff83db6285bd
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Jan 3 18:00:39 2019 +0000

    arm64: compat: Don't pull syscall number from regs in arm_compat_syscall
    
    commit 53290432145a8eb143fe29e06e9c1465d43dc723 upstream.
    
    The syscall number may have been changed by a tracer, so we should pass
    the actual number in from the caller instead of pulling it from the
    saved r7 value directly.
    
    Cc: <stable@vger.kernel.org>
    Cc: Pi-Hsun Shih <pihsun@chromium.org>
    Reviewed-by: Dave Martin <Dave.Martin@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 451e2d7f716e7c80a5c7ccaf2ae87dc73fe10d38
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Jan 3 17:45:07 2019 +0000

    arm64: compat: Avoid sending SIGILL for unallocated syscall numbers
    
    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: Pi-Hsun Shih <pihsun@chromium.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b605a3690d0fe4a724754d545c02289cf3fbd661
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Wed Oct 17 21:32:58 2018 +0100

    iommu/arm-smmu-v3: Fix big-endian CMD_SYNC writes
    
    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: 37de98f8f1cf ("iommu/arm-smmu-v3: Use CMD_SYNC completion MSI")
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70bf6988a34ccca8b023a06cfa2d3d3f75b0e12f
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Wed Dec 12 14:11:23 2018 -0600

    KVM: arm/arm64: vgic: Fix off-by-one bug in vgic_get_irq()
    
    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: 41b87599c743 ("KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    [dropped the SPI part which was fixed separately]
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a134af8ec671c57aaa61f23b40fe7f19a3c6234
Author: Christoffer Dall <christoffer.dall@arm.com>
Date:   Tue Dec 11 13:23:57 2018 +0100

    KVM: arm/arm64: Fix VMID alloc race by reverting to lock-less
    
    commit fb544d1ca65a89f7a3895f7531221ceeed74ada7 upstream.
    
    We recently addressed a VMID generation race by introducing a read/write
    lock around accesses and updates to the vmid generation values.
    
    However, kvm_arch_vcpu_ioctl_run() also calls need_new_vmid_gen() but
    does so without taking the read lock.
    
    As far as I can tell, this can lead to the same kind of race:
    
      VM 0, VCPU 0                  VM 0, VCPU 1
      ------------                  ------------
      update_vttbr (vmid 254)
                                    update_vttbr (vmid 1) // roll over
                                    read_lock(kvm_vmid_lock);
                                    force_vm_exit()
      local_irq_disable
      need_new_vmid_gen == false //because vmid gen matches
    
      enter_guest (vmid 254)
                                    kvm_arch.vttbr = <PGD>:<VMID 1>
                                    read_unlock(kvm_vmid_lock);
    
                                    enter_guest (vmid 1)
    
    Which results in running two VCPUs in the same VM with different VMIDs
    and (even worse) other VCPUs from other VMs could now allocate clashing
    VMID 254 from the new generation as long as VCPU 0 is not exiting.
    
    Attempt to solve this by making sure vttbr is updated before another CPU
    can observe the updated VMID generation.
    
    Cc: stable@vger.kernel.org
    Fixes: f0cf47d939d0 "KVM: arm/arm64: Close VMID generation race"
    Reviewed-by: Julien Thierry <julien.thierry@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5c76ff4c7392f9f2c7a17af4e25287d95e5ed67
Author: Christoffer Dall <christoffer.dall@arm.com>
Date:   Tue Dec 11 12:51:03 2018 +0100

    KVM: arm/arm64: vgic-v2: Set active_source to 0 when restoring state
    
    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: Christoffer Dall <christoffer.dall@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32568eca4ab2a8bb52a4080c43c0439444a8a032
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Dec 4 17:11:19 2018 +0000

    KVM: arm/arm64: vgic: Cap SPIs to the VM-defined maximum
    
    commit bea2ef803ade3359026d5d357348842bca9edcf1 upstream.
    
    SPIs should be checked against the VMs specific configuration, and
    not the architectural maximum.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84d1d542e493332c422ceed82c606bb21514dc19
Author: Julien Thierry <julien.thierry@arm.com>
Date:   Mon Nov 26 18:26:44 2018 +0000

    KVM: arm/arm64: vgic: Do not cond_resched_lock() with IRQs disabled
    
    commit 2e2f6c3c0b08eed3fcf7de3c7684c940451bdeb1 upstream.
    
    To change the active state of an MMIO, halt is requested for all vcpus of
    the affected guest before modifying the IRQ state. This is done by calling
    cond_resched_lock() in vgic_mmio_change_active(). However interrupts are
    disabled at this point and we cannot reschedule a vcpu.
    
    We actually don't need any of this, as kvm_arm_halt_guest ensures that
    all the other vcpus are out of the guest. Let's just drop that useless
    code.
    
    Signed-off-by: Julien Thierry <julien.thierry@arm.com>
    Suggested-by: Christoffer Dall <christoffer.dall@arm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4283b4fb446202eb9b50922ccb9ba0d145f02bb2
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date:   Wed Nov 7 02:39:13 2018 +0000

    rtc: m41t80: Correct alarm month range with RTC reads
    
    commit 3cc9ffbb1f51eb4320575a48e4805a8f52e0e26b upstream.
    
    Add the missing adjustment of the month range on alarm reads from the
    RTC, correcting an issue coming from commit 9c6dfed92c3e ("rtc: m41t80:
    add alarm functionality").  The range is 1-12 for hardware and 0-11 for
    `struct rtc_time', and is already correctly handled on alarm writes to
    the RTC.
    
    It was correct up until commit 48e9766726eb ("drivers/rtc/rtc-m41t80.c:
    remove disabled alarm functionality") too, which removed the previous
    implementation of alarm support.
    
    Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
    Fixes: 9c6dfed92c3e ("rtc: m41t80: add alarm functionality")
    References: 48e9766726eb ("drivers/rtc/rtc-m41t80.c: remove disabled alarm functionality")
    Cc: stable@vger.kernel.org # 4.7+
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aefffe86f9592a5988311a8b2e9ae480bfe4a364
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date:   Wed Dec 12 18:57:44 2018 +0100

    ARM: dts: exynos: Specify I2S assigned clocks in proper node
    
    commit 8ac686d7dfed721102860ff2571e6b9f529ae81a upstream.
    
    The assigned parent clocks should be normally specified in the consumer
    device's DT node, this ensures respective driver always sees correct clock
    settings when required.
    
    This patch fixes regression in audio subsystem on Odroid XU3/XU4 boards
    that appeared after commits:
    
    commit 647d04f8e07a ("ASoC: samsung: i2s: Ensure the RCLK rate is properly determined")
    commit 995e73e55f46 ("ASoC: samsung: i2s: Fix rclk_srcrate handling")
    commit 48279c53fd1d ("ASoC: samsung: i2s: Prevent external abort on exynos5433 I2S1 access")
    
    Without this patch the driver gets wrong clock as the I2S function clock
    (op_clk) in probe() and effectively the clock which is finally assigned
    from DT is not being enabled/disabled in the runtime resume/suspend ops.
    
    Without the above listed commits the EXYNOS_I2S_BUS clock was always set
    as parent of CLK_I2S_RCLK_SRC regardless of DT settings so there was no issue
    with not enabled EXYNOS_SCLK_I2S.
    
    Cc: <stable@vger.kernel.org> # 4.17.x
    Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cece5284c04ac8e5e0be8726460bc21d55978e1
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Dec 18 14:59:09 2018 +0000

    arm/arm64: KVM: vgic: Force VM halt when changing the active state of GICv3 PPIs/SGIs
    
    commit 107352a24900fb458152b92a4e72fbdc83fd5510 upstream.
    
    We currently only halt the guest when a vCPU messes with the active
    state of an SPI. This is perfectly fine for GICv2, but isn't enough
    for GICv3, where all vCPUs can access the state of any other vCPU.
    
    Let's broaden the condition to include any GICv3 interrupt that
    has an active state (i.e. all but LPIs).
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ea5e0f56e8ec7365378349e91650c730f84e588
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Dec 13 16:06:14 2018 +0000

    arm64: KVM: Avoid setting the upper 32 bits of VTCR_EL2 to 1
    
    commit df655b75c43fba0f2621680ab261083297fd6d16 upstream.
    
    Although bit 31 of VTCR_EL2 is RES1, we inadvertently end up setting all
    of the upper 32 bits to 1 as well because we define VTCR_EL2_RES1 as
    signed, which is sign-extended when assigning to kvm->arch.vtcr.
    
    Lucky for us, the architecture currently treats these upper bits as RES0
    so, whilst we've been naughty, we haven't set fire to anything yet.
    
    Cc: <stable@vger.kernel.org>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Christoffer Dall <christoffer.dall@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9d01620ae79b26ae4e5b021c2fb36005ae05864
Author: Long Li <longli@microsoft.com>
Date:   Sun Dec 16 23:17:04 2018 +0000

    CIFS: use the correct length when pinning memory for direct I/O for write
    
    commit b6bc8a7b993e62f82415a5e3e4a6469e80fea19c upstream.
    
    The current code attempts to pin memory using the largest possible wsize
    based on the currect SMB credits. This doesn't cause kernel oops but this
    is not optimal as we may pin more pages then actually needed.
    
    Fix this by only pinning what are needed for doing this write I/O.
    
    Signed-off-by: Long Li <longli@microsoft.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Joey Pabalinas <joeypabalinas@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22d99eb586eefb243f0e0959ff6ad6e507d266fc
Author: Long Li <longli@microsoft.com>
Date:   Sun Dec 16 22:41:07 2018 +0000

    CIFS: return correct errors when pinning memory failed for direct I/O
    
    commit 54e94ff94eac887ddb59cfd46b18896da5695e35 upstream.
    
    When pinning memory failed, we should return the correct error code and
    rewind the SMB credits.
    
    Reported-by: Murphy Zhou <jencce.kernel@gmail.com>
    Signed-off-by: Long Li <longli@microsoft.com>
    Cc: stable@vger.kernel.org
    Cc: Murphy Zhou <jencce.kernel@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d66e2ab1eb37f2f316b736fcb36305f761593a9f
Author: Paul Aurich <paul@darkrain42.org>
Date:   Mon Dec 31 14:13:34 2018 -0800

    smb3: fix large reads on encrypted connections
    
    commit 6d2f84eee098540ae857998fe32f29b9e2cd9613 upstream.
    
    When passing a large read to receive_encrypted_read(), ensure that the
    demultiplex_thread knows that a MID was processed.  Without this, those
    operations never complete.
    
    This is a similar issue/fix to lease break handling:
    commit 7af929d6d05ba5564139718e30d5bc96bdbc716a
    ("smb3: fix lease break problem introduced by compounding")
    
    CC: Stable <stable@vger.kernel.org> # 4.19+
    Fixes: b24df3e30cbf ("cifs: update receive_encrypted_standard to handle compounded responses")
    Signed-off-by: Paul Aurich <paul@darkrain42.org>
    Tested-by: Yves-Alexis Perez <corsac@corsac.net>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2048b8ae34a3b1d564b1fd19b3c3bfd9e023bac7
Author: Georgy A Bystrenin <gkot@altlinux.org>
Date:   Fri Dec 21 00:11:42 2018 -0600

    CIFS: Fix error mapping for SMB2_LOCK command which caused OFD lock problem
    
    commit 9a596f5b39593414c0ec80f71b94a226286f084e upstream.
    
    While resolving a bug with locks on samba shares found a strange behavior.
    When a file locked by one node and we trying to lock it from another node
    it fail with errno 5 (EIO) but in that case errno must be set to
    (EACCES | EAGAIN).
    This isn't happening when we try to lock file second time on same node.
    In this case it returns EACCES as expected.
    Also this issue not reproduces when we use SMB1 protocol (vers=1.0 in
    mount options).
    
    Further investigation showed that the mapping from status_to_posix_error
    is different for SMB1 and SMB2+ implementations.
    For SMB1 mapping is [NT_STATUS_LOCK_NOT_GRANTED to ERRlock]
    (See fs/cifs/netmisc.c line 66)
    but for SMB2+ mapping is [STATUS_LOCK_NOT_GRANTED to -EIO]
    (see fs/cifs/smb2maperror.c line 383)
    
    Quick changes in SMB2+ mapping from EIO to EACCES has fixed issue.
    
    BUG: https://bugzilla.kernel.org/show_bug.cgi?id=201971
    
    Signed-off-by: Georgy A Bystrenin <gkot@altlinux.org>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47b27006bb5025091759f11040d3f110ec1f65bb
Author: Huacai Chen <chenhc@lemote.com>
Date:   Tue Dec 25 08:51:01 2018 +0800

    MIPS: Fix a R10000_LLSC_WAR logic in atomic.h
    
    commit db1ce3f5d01d2d6d5714aefba0159d2cb5167a0b upstream.
    
    Commit 4936084c2ee2 ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
    introduce a mistake in atomic64_fetch_##op##_relaxed(), because it
    forget to delete R10000_LLSC_WAR in the if-condition. So fix it.
    
    Fixes: 4936084c2ee2 ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: Joshua Kinard <kumba@gentoo.org>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Steven J . Hill <Steven.Hill@cavium.com>
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Cc: linux-mips@linux-mips.org
    Cc: stable@vger.kernel.org # 4.19+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit febb155bc1d2b74c1b0c2c622bf69a84932eb6ba
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Wed Jan 2 20:43:01 2019 +0200

    MIPS: OCTEON: mark RGMII interface disabled on OCTEON III
    
    commit edefae94b7b9f10d5efe32dece5a36e9d9ecc29e upstream.
    
    Commit 885872b722b7 ("MIPS: Octeon: Add Octeon III CN7xxx
    interface detection") added RGMII interface detection for OCTEON III,
    but it results in the following logs:
    
    [    7.165984] ERROR: Unsupported Octeon model in __cvmx_helper_rgmii_probe
    [    7.173017] ERROR: Unsupported Octeon model in __cvmx_helper_rgmii_probe
    
    The current RGMII routines are valid only for older OCTEONS that
    use GMX/ASX hardware blocks. On later chips AGL should be used,
    but support for that is missing in the mainline. Until that is added,
    mark the interface as disabled.
    
    Fixes: 885872b722b7 ("MIPS: Octeon: Add Octeon III CN7xxx interface detection")
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <jhogan@kernel.org>
    Cc: linux-mips@vger.kernel.org
    Cc: stable@vger.kernel.org # 4.7+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21439032da7c43700d9b1d2377f828acb3b6bdd5
Author: Paul Burton <paul.burton@mips.com>
Date:   Tue Dec 4 23:44:12 2018 +0000

    MIPS: Expand MIPS32 ASIDs to 64 bits
    
    commit ff4dd232ec45a0e45ea69f28f069f2ab22b4908a upstream.
    
    ASIDs have always been stored as unsigned longs, ie. 32 bits on MIPS32
    kernels. This is problematic because it is feasible for the ASID version
    to overflow & wrap around to zero.
    
    We currently attempt to handle this overflow by simply setting the ASID
    version to 1, using asid_first_version(), but we make no attempt to
    account for the fact that there may be mm_structs with stale ASIDs that
    have versions which we now reuse due to the overflow & wrap around.
    
    Encountering this requires that:
    
      1) A struct mm_struct X is active on CPU A using ASID (V,n).
    
      2) That mm is not used on CPU A for the length of time that it takes
         for CPU A's asid_cache to overflow & wrap around to the same
         version V that the mm had in step 1. During this time tasks using
         the mm could either be sleeping or only scheduled on other CPUs.
    
      3) Some other mm Y becomes active on CPU A and is allocated the same
         ASID (V,n).
    
      4) mm X now becomes active on CPU A again, and now incorrectly has the
         same ASID as mm Y.
    
    Where struct mm_struct ASIDs are represented above in the format
    (version, EntryHi.ASID), and on a typical MIPS32 system version will be
    24 bits wide & EntryHi.ASID will be 8 bits wide.
    
    The length of time required in step 2 is highly dependent upon the CPU &
    workload, but for a hypothetical 2GHz CPU running a workload which
    generates a new ASID every 10000 cycles this period is around 248 days.
    Due to this long period of time & the fact that tasks need to be
    scheduled in just the right (or wrong, depending upon your inclination)
    way, this is obviously a difficult bug to encounter but it's entirely
    possible as evidenced by reports.
    
    In order to fix this, simply extend ASIDs to 64 bits even on MIPS32
    builds. This will extend the period of time required for the
    hypothetical system above to encounter the problem from 28 days to
    around 3 trillion years, which feels safely outside of the realms of
    possibility.
    
    The cost of this is slightly more generated code in some commonly
    executed paths, but this is pretty minimal:
    
                             | Code Size Gain | Percentage
      -----------------------|----------------|-------------
        decstation_defconfig |           +270 | +0.00%
            32r2el_defconfig |           +652 | +0.01%
            32r6el_defconfig |          +1000 | +0.01%
    
    I have been unable to measure any change in performance of the LMbench
    lat_ctx or lat_proc tests resulting from the 64b ASIDs on either
    32r2el_defconfig+interAptiv or 32r6el_defconfig+I6500 systems.
    
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Suggested-by: James Hogan <jhogan@kernel.org>
    References: https://lore.kernel.org/linux-mips/80B78A8B8FEE6145A87579E8435D78C30205D5F3@fzex.ruijie.com.cn/
    References: https://lore.kernel.org/linux-mips/1488684260-18867-1-git-send-email-jiwei.sun@windriver.com/
    Cc: Jiwei Sun <jiwei.sun@windriver.com>
    Cc: Yu Huabing <yhb@ruijie.com.cn>
    Cc: stable@vger.kernel.org # 2.6.12+
    Cc: linux-mips@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a98e9410b7fdddc1fe093c9da1079364c0a15f9
Author: Huacai Chen <chenhc@lemote.com>
Date:   Thu Nov 15 15:53:56 2018 +0800

    MIPS: Align kernel load address to 64KB
    
    commit bec0de4cfad21bd284dbddee016ed1767a5d2823 upstream.
    
    KEXEC needs the new kernel's load address to be aligned on a page
    boundary (see sanity_check_segment_list()), but on MIPS the default
    vmlinuz load address is only explicitly aligned to 16 bytes.
    
    Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
    the alignment calculated by calc_vmlinuz_load_addr to 64KB.
    
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Patchwork: https://patchwork.linux-mips.org/patch/21131/
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <james.hogan@mips.com>
    Cc: Steven J . Hill <Steven.Hill@cavium.com>
    Cc: linux-mips@linux-mips.org
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Cc: <stable@vger.kernel.org> # 2.6.36+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23213dea867b017af2cc529fea424f5fcff8209c
Author: Huacai Chen <chenhc@lemote.com>
Date:   Thu Nov 15 15:53:54 2018 +0800

    MIPS: Ensure pmd_present() returns false after pmd_mknotpresent()
    
    commit 92aa0718c9fa5160ad2f0e7b5bffb52f1ea1e51a upstream.
    
    This patch is borrowed from ARM64 to ensure pmd_present() returns false
    after pmd_mknotpresent(). This is needed for THP.
    
    References: 5bb1cc0ff9a6 ("arm64: Ensure pmd_present() returns false after pmd_mknotpresent()")
    Reviewed-by: James Hogan <jhogan@kernel.org>
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Patchwork: https://patchwork.linux-mips.org/patch/21135/
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <james.hogan@mips.com>
    Cc: Steven J . Hill <Steven.Hill@cavium.com>
    Cc: linux-mips@linux-mips.org
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Cc: <stable@vger.kernel.org> # 3.8+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0c4f99279322356a7292c0197ab54634dcd5cc0
Author: Huacai Chen <chenhc@lemote.com>
Date:   Thu Nov 15 15:53:53 2018 +0800

    MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3
    
    commit bb53fdf395eed103f85061bfff3b116cee123895 upstream.
    
    For multi-node Loongson-3 (NUMA configuration), r4k_blast_scache() can
    only flush Node-0's scache. So we add r4k_blast_scache_node() by using
    (CAC_BASE | (node_id << NODE_ADDRSPACE_SHIFT)) instead of CKSEG0 as the
    start address.
    
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    [paul.burton@mips.com: Include asm/mmzone.h from asm/r4kcache.h for
                           nid_to_addrbase(). Add asm/mach-generic/mmzone.h
                           to allow inclusion for all platforms.]
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Patchwork: https://patchwork.linux-mips.org/patch/21129/
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: James Hogan <james.hogan@mips.com>
    Cc: Steven J . Hill <Steven.Hill@cavium.com>
    Cc: linux-mips@linux-mips.org
    Cc: Fuxin Zhang <zhangfx@lemote.com>
    Cc: Zhangjin Wu <wuzhangjin@gmail.com>
    Cc: <stable@vger.kernel.org> # 3.15+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72ffe8facf657ec4e66a74699d498663a26405d6
Author: Paul Burton <paul.burton@mips.com>
Date:   Thu Dec 20 17:45:43 2018 +0000

    MIPS: math-emu: Write-protect delay slot emulation pages
    
    commit adcc81f148d733b7e8e641300c5590a2cdc13bf3 upstream.
    
    Mapping the delay slot emulation page as both writeable & executable
    presents a security risk, in that if an exploit can write to & jump into
    the page then it can be used as an easy way to execute arbitrary code.
    
    Prevent this by mapping the page read-only for userland, and using
    access_process_vm() with the FOLL_FORCE flag to write to it from
    mips_dsemul().
    
    This will likely be less efficient due to copy_to_user_page() performing
    cache maintenance on a whole page, rather than a single line as in the
    previous use of flush_cache_sigtramp(). However this delay slot
    emulation code ought not to be running in any performance critical paths
    anyway so this isn't really a problem, and we can probably do better in
    copy_to_user_page() anyway in future.
    
    A major advantage of this approach is that the fix is small & simple to
    backport to stable kernels.
    
    Reported-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Paul Burton <paul.burton@mips.com>
    Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot instructions")
    Cc: stable@vger.kernel.org # v4.8+
    Cc: linux-mips@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: Rich Felker <dalias@libc.org>
    Cc: David Daney <david.daney@cavium.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 321eceda5c5f80df06a75260da3df2caf37ad55d
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Mon Dec 10 13:45:22 2018 -0500

    tools lib traceevent: Fix processing of dereferenced args in bprintk events
    
    commit f024cf085c423bac7512479f45c34ee9a24af7ce upstream.
    
    In the case that a bprintk event has a dereferenced pointer that is
    stored as a string, and there's more values to process (more args), the
    arg was not updated to point to the next arg after processing the
    dereferenced pointer, and it screwed up what was to be displayed.
    
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: linux-trace-devel@vger.kernel.org
    Cc: stable@vger.kernel.org
    Fixes: 37db96bb49629 ("tools lib traceevent: Handle new pointer processing of bprint strings")
    Link: http://lkml.kernel.org/r/20181210134522.3f71e2ca@gandalf.local.home
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4c007b5f2fb1bfece51f5d1cb9e3598b8aa1d66
Author: Ondrej Jirman <megous@megous.com>
Date:   Fri Dec 7 10:56:01 2018 -0500

    media: v4l2-fwnode: Fix setting V4L2_MBUS_DATA_ACTIVE_HIGH/LOW flag
    
    commit fa09d06522ceac428fdc5c2b57c572f6cfd0a8bb upstream.
    
    When parallel bus is used and data-active is being parsed, incorrect
    flags are cleared.
    
    Clear the correct flag bits.
    
    Fixes: e9be1b863e2c2948deb003df8edd9635b4611a8a (media: v4l: fwnode:
    Use default parallel flags).
    
    Cc: stable@vger.kernel.org # for Kernel 4.20
    Signed-off-by: Ondrej Jirman <megous@megous.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de1b2434a453b077139e5809f2761378698da735
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Thu Nov 8 11:12:47 2018 -0500

    media: v4l2-tpg: array index could become negative
    
    commit e5f71a27fa12c1a1b02ad478a568e76260f1815e upstream.
    
    text[s] is a signed char, so using that as index into the font8x16 array
    can result in negative indices. Cast it to u8 to be safe.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: syzbot+ccf0a61ed12f2a7313ee@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>      # for v4.7 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 314692da7ee9f7a0142182c7746ef60dd9797d5c
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Thu Nov 8 07:23:37 2018 -0500

    media: vb2: check memory model for VIDIOC_CREATE_BUFS
    
    commit 62dcb4f41836bd3c44b5b651bb6df07ea4cb1551 upstream.
    
    vb2_core_create_bufs did not check if the memory model for newly added
    buffers is the same as for already existing buffers. It should return an
    error if they aren't the same.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: syzbot+e1fb118a2ebb88031d21@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>      # for v4.16 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0f7b724295d50cb4da215428642b1724796342e2
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Wed Nov 7 09:04:54 2018 -0500

    media: vim2m: use cancel_delayed_work_sync instead of flush_schedule_work
    
    commit 52117be68b82ee05c96da0a7beec319906ccf6cc upstream.
    
    The use of flush_schedule_work() made no sense and caused a syzkaller error.
    Replace with the correct cancel_delayed_work_sync().
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: syzbot+69780d144754b8071f4b@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>      # for v4.20 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b22c352e849e6e035072066e222dd2f3f69b3fc
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri Nov 9 08:37:44 2018 -0500

    media: vivid: free bitmap_cap when updating std/timings/etc.
    
    commit 560ccb75c2caa6b1039dec1a53cd2ef526f5bf03 upstream.
    
    When vivid_update_format_cap() is called it should free any overlay
    bitmap since the compose size will change.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: syzbot+0cc8e3cc63ca373722c6@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>      # for v3.18 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d70f7e42d104d807b6cf355c6022cd4e4375750e
Author: Luca Ceresoli <luca@lucaceresoli.net>
Date:   Mon Nov 26 11:35:07 2018 -0500

    media: imx274: fix stack corruption in imx274_read_reg
    
    commit cea8c0077d6cf3a0cea2f18a8e914af78d46b2ff upstream.
    
    imx274_read_reg() takes a u8 pointer ("reg") and casts it to pass it
    to regmap_read(), which takes an unsigned int pointer. This results in
    a corrupted stack and random crashes.
    
    Fixes: 0985dd306f72 ("media: imx274: V4l2 driver for Sony imx274 CMOS sensor")
    
    Cc: stable@vger.kernel.org # for 4.15 and up
    Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73fd91290cf2b2621ce6f3f4e0f5f1ccb833813e
Author: Sean Young <sean@mess.org>
Date:   Mon Oct 22 05:01:50 2018 -0400

    media: rc: cec devices do not have a lirc chardev
    
    commit e5bb9d3d755f128956ed467ae50b41d22bb680c6 upstream.
    
    This fixes an oops in ir_lirc_scancode_event().
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
    PGD 0 P4D 0
    Oops: 0000 [#1] SMP PTI
    CPU: 9 PID: 27687 Comm: kworker/9:2 Tainted: P           OE 4.18.12-200.fc28.x86_64 #1
    Hardware name: Supermicro C7X99-OCE-F/C7X99-OCE-F, BIOS 2.1a 06/15/2018
    Workqueue: events pulse8_irq_work_handler [pulse8_cec]
    RIP: 0010:ir_lirc_scancode_event+0x3d/0xb0 [rc_core]
    Code: 8d ae b4 07 00 00 49 81 c6 b8 07 00 00 53 e8 4a df c3 d5 48 89 ef 49 89 45 00 e8 4e 84 41 d6 49 8b 1e 49 89 c4 4c 39 f3 74 58 <8b> 43 38 8b 53 40 89 c1 2b 4b 3c 39 ca 72 41 21 d0 49 8b 7d 00 49
    RSP: 0018:ffffaa10e3c07d58 EFLAGS: 00010017
    RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000018
    RDX: 0000000000000001 RSI: 00316245397fa93c RDI: ffff966d31c8d7b4
    RBP: ffff966d31c8d7b4 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000003 R11: ffffaa10e3c07e28 R12: 0000000000000002
    R13: ffffaa10e3c07d88 R14: ffff966d31c8d7b8 R15: 0000000000000073
    FS:  0000000000000000(0000) GS:ffff966d3f440000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000038 CR3: 00000009d820a003 CR4: 00000000003606e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     ir_do_keydown+0x75/0x260 [rc_core]
     rc_keydown+0x54/0xc0 [rc_core]
     cec_received_msg_ts+0xaa8/0xaf0 [cec]
     process_one_work+0x1a1/0x350
     worker_thread+0x30/0x380
     ? pwq_unbound_release_workfn+0xd0/0xd0
     kthread+0x112/0x130
     ? kthread_create_worker_on_cpu+0x70/0x70
     ret_from_fork+0x35/0x40
    Modules linked in: rc_tt_1500 dvb_usb_dvbsky dvb_usb_v2 uas usb_storage fuse vhost_net vhost tap xt_CHECKSUM iptable_mangle ip6t_REJECT nf_reject_ipv6 tun 8021q garp mrp xt_nat macvlan xfs devlink ebta
     si2157 si2168 cx25840 cx23885 kvm altera_ci tda18271 joydev ir_rc6_decoder rc_rc6_mce crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate intel_uncore altera_stapl m88ds3103 tveeprom cx2341
     mxm_wmi igb crc32c_intel megaraid_sas dca i2c_algo_bit wmi vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio i2c_dev
    CR2: 0000000000000038
    
    Cc: <stable@vger.kernel.org> # v4.16+
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71d49b5560819e738dd99c3e7b5fd739d7c0e3d3
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Wed Nov 14 03:37:53 2018 -0500

    media: cec-pin: fix broken tx_ignore_nack_until_eom error injection
    
    commit ac791f19a273a7fe254a7596f193af6534582a9f upstream.
    
    If the tx_ignore_nack_until_eom error injection was activated,
    then tx_nacked was never set instead of setting it when the last
    byte of the message was transmitted.
    
    As a result the transmit was marked as OK, when it should have
    been NACKed.
    
    Modify the condition so that it always sets tx_nacked when the
    last byte of the message was transmitted.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Cc: <stable@vger.kernel.org>      # for v4.17 and up
    Signed-off-by: Hans Verkuil <hansverk@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b13f60e7852c646261682580e2d11b96b59ce3f7
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri Oct 19 03:55:34 2018 -0400

    media: cec: keep track of outstanding transmits
    
    commit 32804fcb612bf867034a093f459415e485cf044b upstream.
    
    I noticed that repeatedly running 'cec-ctl --playback' would occasionally
    select 'Playback Device 2' instead of 'Playback Device 1', even though there
    were no other Playback devices in the HDMI topology. This happened both with
    'real' hardware and with the vivid CEC emulation, suggesting that this was an
    issue in the core code that claims a logical address.
    
    What 'cec-ctl --playback' does is to first clear all existing logical addresses,
    and immediately after that configure the new desired device type.
    
    The core code will poll the logical addresses trying to find a free address.
    When found it will issue a few standard messages as per the CEC spec and return.
    Those messages are queued up and will be transmitted asynchronously.
    
    What happens is that if you run two 'cec-ctl --playback' commands in quick
    succession, there is still a message of the first cec-ctl command being transmitted
    when you reconfigure the adapter again in the second cec-ctl command.
    
    When the logical addresses are cleared, then all information about outstanding
    transmits inside the CEC core is also cleared, and the core is no longer aware
    that there is still a transmit in flight.
    
    When the hardware finishes the transmit it calls transmit_done and the CEC core
    thinks it is actually in response of a POLL messages that is trying to find a
    free logical address. The result of all this is that the core thinks that the
    logical address for Playback Device 1 is in use, when it is really an earlier
    transmit that ended.
    
    The main transmit thread looks at adap->transmitting to check if a transmit
    is in progress, but that is set to NULL when the adapter is unconfigured.
    adap->transmitting represents the view of userspace, not that of the hardware.
    So when unconfiguring the adapter the message is marked aborted from the point
    of view of userspace, but seen from the PoV of the hardware it is still ongoing.
    
    So introduce a new bool transmit_in_progress that represents the hardware state
    and use that instead of adap->transmitting. Now the CEC core waits until the
    hardware finishes the transmit before starting a new transmit.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Cc: <stable@vger.kernel.org>      # for v4.18 and up
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 954912026803dd698d378c9c4caa0cbbe762e144
Author: Nava kishore Manne <nava.manne@xilinx.com>
Date:   Tue Dec 18 13:18:42 2018 +0100

    serial: uartps: Fix interrupt mask issue to handle the RX interrupts properly
    
    commit 260683137ab5276113fc322fdbbc578024185fee upstream.
    
    This patch Correct the RX interrupt mask value to handle the
    RX interrupts properly.
    
    Fixes: c8dbdc842d30 ("serial: xuartps: Rewrite the interrupt handling logic")
    Signed-off-by: Nava kishore Manne <nava.manne@xilinx.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b47f14427bdfeec863738a84a39a23879a0ee880
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Wed Dec 26 19:54:07 2018 -0800

    f2fs: sanity check of xattr entry size
    
    commit 64beba0558fce7b59e9a8a7afd77290e82a22163 upstream.
    
    There is a security report where f2fs_getxattr() has a hole to expose wrong
    memory region when the image is malformed like this.
    
    f2fs_getxattr: entry->e_name_len: 4, size: 12288, buffer_size: 16384, len: 4
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0acc96eee4b261af534682eeda709a0b2b0b5caf
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sat Dec 22 11:22:26 2018 +0100

    f2fs: fix validation of the block count in sanity_check_raw_super
    
    commit 88960068f25fcc3759455d85460234dcc9d43fef upstream.
    
    Treat "block_count" from struct f2fs_super_block as 64-bit little endian
    value in sanity_check_raw_super() because struct f2fs_super_block
    declares "block_count" as "__le64".
    
    This fixes a bug where the superblock validation fails on big endian
    devices with the following error:
      F2FS-fs (sda1): Wrong segment_count / block_count (61439 > 0)
      F2FS-fs (sda1): Can't find valid F2FS filesystem in 1th superblock
      F2FS-fs (sda1): Wrong segment_count / block_count (61439 > 0)
      F2FS-fs (sda1): Can't find valid F2FS filesystem in 2th superblock
    As result of this the partition cannot be mounted.
    
    With this patch applied the superblock validation works fine and the
    partition can be mounted again:
      F2FS-fs (sda1): Mounted with checkpoint version = 7c84
    
    My little endian x86-64 hardware was able to mount the partition without
    this fix.
    To confirm that mounting f2fs filesystems works on big endian machines
    again I tested this on a 32-bit MIPS big endian (lantiq) device.
    
    Fixes: 0cfe75c5b01199 ("f2fs: enhance sanity_check_raw_super() to avoid potential overflows")
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56a8f57bf771d4a87dc917216fbaeb32b042675f
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Mon Dec 17 17:08:26 2018 -0800

    f2fs: fix missing unlock(sbi->gc_mutex)
    
    commit 8f31b4665c14fe19593601a250275e58c7ad0ef1 upstream.
    
    This fixes missing unlock call.
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bfc9902d3415abef57eb22484561503683783d1
Author: Jia Zhu <zhujia13@huawei.com>
Date:   Tue Nov 27 02:32:32 2018 +0800

    f2fs: fix to update new block address correctly for OPU
    
    commit 73c0a9272a7d2942bcae29d4829bf63277cc57c8 upstream.
    
    Previously, we allocated a new block address for OPU mode in direct_IO.
    
    But the new address couldn't be assigned to @map->m_pblk correctly.
    
    This patch fix it.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 511f52d02f05 ("f2fs: allow out-place-update for direct IO in LFS mode")
    Signed-off-by: Jia Zhu <zhujia13@huawei.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15d381c84bd894314e36acfe7d04f7356f3d9338
Author: Pan Bian <bianpan2016@163.com>
Date:   Thu Nov 22 18:58:46 2018 +0800

    f2fs: read page index before freeing
    
    commit 0ea295dd853e0879a9a30ab61f923c26be35b902 upstream.
    
    The function truncate_node frees the page with f2fs_put_page. However,
    the page index is read after that. So, the patch reads the index before
    freeing the page.
    
    Fixes: bf39c00a9a7f ("f2fs: drop obsolete node page when it is truncated")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d412deb85a4aada382352a8202beb7af8921cd53
Author: Breno Leitao <leitao@debian.org>
Date:   Mon Nov 26 18:12:00 2018 -0200

    powerpc/tm: Unset MSR[TS] if not recheckpointing
    
    commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.
    
    There is a TM Bad Thing bug that can be caused when you return from a
    signal context in a suspended transaction but with ucontext MSR[TS] unset.
    
    This forces regs->msr[TS] to be set at syscall entrance (since the CPU
    state is transactional). It also calls treclaim() to flush the transaction
    state, which is done based on the live (mfmsr) MSR state.
    
    Since user context MSR[TS] is not set, then restore_tm_sigcontexts() is not
    called, thus, not executing recheckpoint, keeping the CPU state as not
    transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU
    state is non transactional, causing the TM Bad Thing with the following
    stack:
    
            [   33.862316] Bad kernel stack pointer 3fffd9dce3e0 at c00000000000c47c
            cpu 0x8: Vector: 700 (Program Check) at [c00000003ff7fd40]
                pc: c00000000000c47c: fast_exception_return+0xac/0xb4
                lr: 00003fff865f442c
                sp: 3fffd9dce3e0
               msr: 8000000102a03031
              current = 0xc00000041f68b700
              paca    = 0xc00000000fb84800   softe: 0        irq_happened: 0x01
                pid   = 1721, comm = tm-signal-sigre
            Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)
            WARNING: exception is not recoverable, can't continue
    
    The same problem happens on 32-bits signal handler, and the fix is very
    similar, if tm_recheckpoint() is not executed, then regs->msr[TS] should be
    zeroed.
    
    This patch also fixes a sparse warning related to lack of indentation when
    CONFIG_PPC_TRANSACTIONAL_MEM is set.
    
    Fixes: 2b0a576d15e0e ("powerpc: Add new transactional memory state to the signal context")
    CC: Stable <stable@vger.kernel.org>     # 3.10+
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Tested-by: Michal Suchánek <msuchanek@suse.de>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cf4b780f0d340c9326d3daf78afb6df2e863810
Author: Eric Biggers <ebiggers@google.com>
Date:   Sat Nov 3 10:30:35 2018 -0700

    KEYS: fix parsing invalid pkey info string
    
    commit 57b0e31453209d746c99e513d80b3d0c44a80891 upstream.
    
    We need to check the return value of match_token() for Opt_err before
    doing anything with it.
    
    [ Not only did the old "-1" value for Opt_err cause problems for the
      __test_and_set_bit(), as fixed in commit 94c13f66e13c ("security:
      don't use a negative Opt_err token index"), but accessing
      "args[0].from" is invalid for the Opt_err case, as pointed out by Eric
      later.  - Linus ]
    
    Reported-by: syzbot+a22e0dc07567662c50bc@syzkaller.appspotmail.com
    Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Cc: stable@kernel.org # 4.20
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33b2f66c27115efcb8f824b01396083cc3c03d4b
Author: Lyude Paul <lyude@redhat.com>
Date:   Sat Nov 24 17:57:05 2018 -0500

    brcmfmac: Fix out of bounds memory access during fw load
    
    commit b72c51a58e6d63ef673ac96b8ab5bc98799c5f7b upstream.
    
    I ended up tracking down some rather nasty issues with f2fs (and other
    filesystem modules) constantly crashing on my kernel down to a
    combination of out of bounds memory accesses, one of which was coming
    from brcmfmac during module load:
    
    [   30.891382] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
    [   30.894437] ==================================================================
    [   30.901581] BUG: KASAN: global-out-of-bounds in brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac]
    [   30.909935] Read of size 1 at addr ffff2000024865df by task kworker/6:2/387
    [   30.916805]
    [   30.918261] CPU: 6 PID: 387 Comm: kworker/6:2 Tainted: G           O      4.20.0-rc3Lyude-Test+ #19
    [   30.927251] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
    [   30.935964] Workqueue: events brcmf_driver_register [brcmfmac]
    [   30.941641] Call trace:
    [   30.944058]  dump_backtrace+0x0/0x3e8
    [   30.947676]  show_stack+0x14/0x20
    [   30.950968]  dump_stack+0x130/0x1c4
    [   30.954406]  print_address_description+0x60/0x25c
    [   30.959066]  kasan_report+0x1b4/0x368
    [   30.962683]  __asan_report_load1_noabort+0x18/0x20
    [   30.967547]  brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac]
    [   30.967639]  brcmf_sdio_probe+0x163c/0x2050 [brcmfmac]
    [   30.978035]  brcmf_ops_sdio_probe+0x598/0xa08 [brcmfmac]
    [   30.983254]  sdio_bus_probe+0x190/0x398
    [   30.983270]  really_probe+0x2a0/0xa70
    [   30.983296]  driver_probe_device+0x1b4/0x2d8
    [   30.994901]  __driver_attach+0x200/0x280
    [   30.994914]  bus_for_each_dev+0x10c/0x1a8
    [   30.994925]  driver_attach+0x38/0x50
    [   30.994935]  bus_add_driver+0x330/0x608
    [   30.994953]  driver_register+0x140/0x388
    [   31.013965]  sdio_register_driver+0x74/0xa0
    [   31.014076]  brcmf_sdio_register+0x14/0x60 [brcmfmac]
    [   31.023177]  brcmf_driver_register+0xc/0x18 [brcmfmac]
    [   31.023209]  process_one_work+0x654/0x1080
    [   31.032266]  worker_thread+0x4f0/0x1308
    [   31.032286]  kthread+0x2a8/0x320
    [   31.039254]  ret_from_fork+0x10/0x1c
    [   31.039269]
    [   31.044226] The buggy address belongs to the variable:
    [   31.044351]  brcmf_firmware_path+0x11f/0xfffffffffffd3b40 [brcmfmac]
    [   31.055601]
    [   31.057031] Memory state around the buggy address:
    [   31.061800]  ffff200002486480: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
    [   31.068983]  ffff200002486500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   31.068993] >ffff200002486580: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
    [   31.068999]                                                     ^
    [   31.069017]  ffff200002486600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   31.096521]  ffff200002486680: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
    [   31.096528] ==================================================================
    [   31.096533] Disabling lock debugging due to kernel taint
    
    It appears that when trying to determine the length of the string in the
    alternate firmware path, we make the mistake of not handling the case
    where the firmware path is empty correctly. Since strlen(mp_path) can
    return 0, we'll end up accessing mp_path[-1] when the firmware_path
    isn't provided through the module arguments.
    
    So, fix this by just setting the end char to '\0' by default, and only
    changing it if we have a non-zero length. Additionally, use strnlen()
    with BRCMF_FW_ALTPATH_LEN instead of strlen() just to be extra safe.
    
    Fixes: 2baa3aaee27f ("brcmfmac: introduce brcmf_fw_alloc_request() function")
    Cc: Hante Meuleman <hante.meuleman@broadcom.com>
    Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
    Cc: Franky Lin <franky.lin@broadcom.com>
    Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
    Cc: Himanshu Jha <himanshujha199640@gmail.com>
    Cc: Dan Haab <dhaab@luxul.com>
    Cc: Jia-Shyr Chuang <saint.chuang@cypress.com>
    Cc: Ian Molton <ian@mnementh.co.uk>
    Cc: <stable@vger.kernel.org> # v4.17+
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea6adaafc995fea63a8932151ac161df63613052
Author: Stijn Tintel <stijn@linux-ipv6.be>
Date:   Tue Dec 4 20:29:05 2018 +0200

    brcmfmac: fix roamoff=1 modparam
    
    commit 8c892df41500469729e0d662816300196e4f463d upstream.
    
    When the update_connect_param callback is set, nl80211 expects the flag
    WIPHY_FLAG_SUPPORTS_FW_ROAM to be set as well. However, this flag is
    only set when modparam roamoff=0, while the callback is set
    unconditionally. Since commit 7f9a3e150ec7 this causes a warning in
    wiphy_register, which breaks brcmfmac.
    
    Disable the update_connect_param callback when roamoff=0 to fix this.
    
    Fixes: 7f9a3e150ec7 ("nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS")
    Cc: Stable <stable@vger.kernel.org> # 4.19+
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa63f2854f978ad220c095ab28f83010ab0af71e
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Dec 11 10:19:45 2018 +0000

    Btrfs: send, fix race with transaction commits that create snapshots
    
    commit be6821f82c3cc36e026f5afd10249988852b35ea upstream.
    
    If we create a snapshot of a snapshot currently being used by a send
    operation, we can end up with send failing unexpectedly (returning
    -ENOENT error to user space for example). The following diagram shows
    how this happens.
    
                CPU 1                                   CPU2                                CPU3
    
     btrfs_ioctl_send()
      (...)
                                         create_snapshot()
                                          -> creates snapshot of a
                                             root used by the send
                                             task
                                          btrfs_commit_transaction()
                                           create_pending_snapshot()
      __get_inode_info()
       btrfs_search_slot()
        btrfs_search_slot_get_root()
         down_read commit_root_sem
    
         get reference on eb of the
         commit root
          -> eb with bytenr == X
    
         up_read commit_root_sem
    
                                            btrfs_cow_block(root node)
                                             btrfs_free_tree_block()
                                              -> creates delayed ref to
                                                 free the extent
    
                                           btrfs_run_delayed_refs()
                                            -> runs the delayed ref,
                                               adds extent to
                                               fs_info->pinned_extents
    
                                           btrfs_finish_extent_commit()
                                            unpin_extent_range()
                                             -> marks extent as free
                                                in the free space cache
    
                                          transaction commit finishes
    
                                                                           btrfs_start_transaction()
                                                                            (...)
                                                                            btrfs_cow_block()
                                                                             btrfs_alloc_tree_block()
                                                                              btrfs_reserve_extent()
                                                                               -> allocates extent at
                                                                                  bytenr == X
                                                                              btrfs_init_new_buffer(bytenr X)
                                                                               btrfs_find_create_tree_block()
                                                                                alloc_extent_buffer(bytenr X)
                                                                                 find_extent_buffer(bytenr X)
                                                                                  -> returns existing eb,
                                                                                     which the send task got
    
                                                                            (...)
                                                                             -> modifies content of the
                                                                                eb with bytenr == X
    
        -> uses an eb that now
           belongs to some other
           tree and no more matches
           the commit root of the
           snapshot, resuts will be
           unpredictable
    
    The consequences of this race can be various, and can lead to searches in
    the commit root performed by the send task failing unexpectedly (unable to
    find inode items, returning -ENOENT to user space, for example) or not
    failing because an inode item with the same number was added to the tree
    that reused the metadata extent, in which case send can behave incorrectly
    in the worst case or just fail later for some reason.
    
    Fix this by performing a copy of the commit root's extent buffer when doing
    a search in the context of a send operation.
    
    CC: stable@vger.kernel.org # 4.4.x: 1fc28d8e2e9: Btrfs: move get root out of btrfs_search_slot to a helper
    CC: stable@vger.kernel.org # 4.4.x: f9ddfd0592a: Btrfs: remove unused check of skip_locking
    CC: stable@vger.kernel.org # 4.4.x
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f680161483625d9aab3e80ec973b26461a5cb21
Author: Josef Bacik <jbacik@fb.com>
Date:   Fri Nov 30 11:52:14 2018 -0500

    btrfs: run delayed items before dropping the snapshot
    
    commit 0568e82dbe2510fc1fa664f58e5c997d3f1e649e upstream.
    
    With my delayed refs patches in place we started seeing a large amount
    of aborts in __btrfs_free_extent:
    
     BTRFS error (device sdb1): unable to find ref byte nr 91947008 parent 0 root 35964  owner 1 offset 0
     Call Trace:
      ? btrfs_merge_delayed_refs+0xaf/0x340
      __btrfs_run_delayed_refs+0x6ea/0xfc0
      ? btrfs_set_path_blocking+0x31/0x60
      btrfs_run_delayed_refs+0xeb/0x180
      btrfs_commit_transaction+0x179/0x7f0
      ? btrfs_check_space_for_delayed_refs+0x30/0x50
      ? should_end_transaction.isra.19+0xe/0x40
      btrfs_drop_snapshot+0x41c/0x7c0
      btrfs_clean_one_deleted_snapshot+0xb5/0xd0
      cleaner_kthread+0xf6/0x120
      kthread+0xf8/0x130
      ? btree_invalidatepage+0x90/0x90
      ? kthread_bind+0x10/0x10
      ret_from_fork+0x35/0x40
    
    This was because btrfs_drop_snapshot depends on the root not being
    modified while it's dropping the snapshot.  It will unlock the root node
    (and really every node) as it walks down the tree, only to re-lock it
    when it needs to do something.  This is a problem because if we modify
    the tree we could cow a block in our path, which frees our reference to
    that block.  Then once we get back to that shared block we'll free our
    reference to it again, and get ENOENT when trying to lookup our extent
    reference to that block in __btrfs_free_extent.
    
    This is ultimately happening because we have delayed items left to be
    processed for our deleted snapshot _after_ all of the inodes are closed
    for the snapshot.  We only run the delayed inode item if we're deleting
    the inode, and even then we do not run the delayed insertions or delayed
    removals.  These can be run at any point after our final inode does its
    last iput, which is what triggers the snapshot deletion.  We can end up
    with the snapshot deletion happening and then have the delayed items run
    on that file system, resulting in the above problem.
    
    This problem has existed forever, however my patches made it much easier
    to hit as I wake up the cleaner much more often to deal with delayed
    iputs, which made us more likely to start the snapshot dropping work
    before the transaction commits, which is when the delayed items would
    generally be run.  Before, generally speaking, we would run the delayed
    items, commit the transaction, and wakeup the cleaner thread to start
    deleting snapshots, which means we were less likely to hit this problem.
    You could still hit it if you had multiple snapshots to be deleted and
    ended up with lots of delayed items, but it was definitely harder.
    
    Fix for now by simply running all the delayed items before starting to
    drop the snapshot.  We could make this smarter in the future by making
    the delayed items per-root, and then simply drop any delayed items for
    roots that we are going to delete.  But for now just a quick and easy
    solution is the safest.
    
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f6d0d312eeb31c2a19e2081b29505b61bc14570
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Nov 28 14:54:28 2018 +0000

    Btrfs: fix fsync of files with multiple hard links in new directories
    
    commit 41bd60676923822de1df2c50b3f9a10171f4338a upstream.
    
    The log tree has a long standing problem that when a file is fsync'ed we
    only check for new ancestors, created in the current transaction, by
    following only the hard link for which the fsync was issued. We follow the
    ancestors using the VFS' dget_parent() API. This means that if we create a
    new link for a file in a directory that is new (or in an any other new
    ancestor directory) and then fsync the file using an old hard link, we end
    up not logging the new ancestor, and on log replay that new hard link and
    ancestor do not exist. In some cases, involving renames, the file will not
    exist at all.
    
    Example:
    
      mkfs.btrfs -f /dev/sdb
      mount /dev/sdb /mnt
    
      mkdir /mnt/A
      touch /mnt/foo
      ln /mnt/foo /mnt/A/bar
      xfs_io -c fsync /mnt/foo
    
      <power failure>
    
    In this example after log replay only the hard link named 'foo' exists
    and directory A does not exist, which is unexpected. In other major linux
    filesystems, such as ext4, xfs and f2fs for example, both hard links exist
    and so does directory A after mounting again the filesystem.
    
    Checking if any new ancestors are new and need to be logged was added in
    2009 by commit 12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes"),
    however only for the ancestors of the hard link (dentry) for which the
    fsync was issued, instead of checking for all ancestors for all of the
    inode's hard links.
    
    So fix this by tracking the id of the last transaction where a hard link
    was created for an inode and then on fsync fallback to a full transaction
    commit when an inode has more than one hard link and at least one new hard
    link was created in the current transaction. This is the simplest solution
    since this is not a common use case (adding frequently hard links for
    which there's an ancestor created in the current transaction and then
    fsync the file). In case it ever becomes a common use case, a solution
    that consists of iterating the fs/subvol btree for each hard link and
    check if any ancestor is new, could be implemented.
    
    This solves many unexpected scenarios reported by Jayashree Mohan and
    Vijay Chidambaram, and for which there is a new test case for fstests
    under review.
    
    Fixes: 12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes")
    CC: stable@vger.kernel.org # 4.4+
    Reported-by: Vijay Chidambaram <vvijay03@gmail.com>
    Reported-by: Jayashree Mohan <jayashree2912@gmail.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 878b83a00743d6c408170976ff58d058565a1164
Author: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Date:   Thu Nov 29 17:31:32 2018 +0800

    btrfs: skip file_extent generation check for free_space_inode in run_delalloc_nocow
    
    commit 27a7ff554e8d349627a90bda275c527b7348adae upstream.
    
    The test case btrfs/001 with inode_cache mount option will encounter the
    following warning:
    
      WARNING: CPU: 1 PID: 23700 at fs/btrfs/inode.c:956 cow_file_range.isra.19+0x32b/0x430 [btrfs]
      CPU: 1 PID: 23700 Comm: btrfs Kdump: loaded Tainted: G        W  O      4.20.0-rc4-custom+ #30
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
      RIP: 0010:cow_file_range.isra.19+0x32b/0x430 [btrfs]
      Call Trace:
       ? free_extent_buffer+0x46/0x90 [btrfs]
       run_delalloc_nocow+0x455/0x900 [btrfs]
       btrfs_run_delalloc_range+0x1a7/0x360 [btrfs]
       writepage_delalloc+0xf9/0x150 [btrfs]
       __extent_writepage+0x125/0x3e0 [btrfs]
       extent_write_cache_pages+0x1b6/0x3e0 [btrfs]
       ? __wake_up_common_lock+0x63/0xc0
       extent_writepages+0x50/0x80 [btrfs]
       do_writepages+0x41/0xd0
       ? __filemap_fdatawrite_range+0x9e/0xf0
       __filemap_fdatawrite_range+0xbe/0xf0
       btrfs_fdatawrite_range+0x1b/0x50 [btrfs]
       __btrfs_write_out_cache+0x42c/0x480 [btrfs]
       btrfs_write_out_ino_cache+0x84/0xd0 [btrfs]
       btrfs_save_ino_cache+0x551/0x660 [btrfs]
       commit_fs_roots+0xc5/0x190 [btrfs]
       btrfs_commit_transaction+0x2bf/0x8d0 [btrfs]
       btrfs_mksubvol+0x48d/0x4d0 [btrfs]
       btrfs_ioctl_snap_create_transid+0x170/0x180 [btrfs]
       btrfs_ioctl_snap_create_v2+0x124/0x180 [btrfs]
       btrfs_ioctl+0x123f/0x3030 [btrfs]
    
    The file extent generation of the free space inode is equal to the last
    snapshot of the file root, so the inode will be passed to cow_file_rage.
    But the inode was created and its extents were preallocated in
    btrfs_save_ino_cache, there are no cow copies on disk.
    
    The preallocated extent is not yet in the extent tree, and
    btrfs_cross_ref_exist will ignore the -ENOENT returned by
    check_committed_ref, so we can directly write the inode to the disk.
    
    Fixes: 78d4295b1eee ("btrfs: lift some btrfs_cross_ref_exist checks in nocow path")
    CC: stable@vger.kernel.org # 4.18+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78dcdf663266723238d2b808e984828105a0faf9
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Nov 26 20:07:17 2018 +0000

    Btrfs: fix deadlock with memory reclaim during scrub
    
    commit a5fb11429167ee6ddeeacc554efaf5776b36433a upstream.
    
    When a transaction commit starts, it attempts to pause scrub and it blocks
    until the scrub is paused. So while the transaction is blocked waiting for
    scrub to pause, we can not do memory allocation with GFP_KERNEL from scrub,
    otherwise we risk getting into a deadlock with reclaim.
    
    Checking for scrub pause requests is done early at the beginning of the
    while loop of scrub_stripe() and later in the loop, scrub_extent() and
    scrub_raid56_parity() are called, which in turn call scrub_pages() and
    scrub_pages_for_parity() respectively. These last two functions do memory
    allocations using GFP_KERNEL. Same problem could happen while scrubbing
    the super blocks, since it calls scrub_pages().
    
    We also can not have any of the worker tasks, created by the scrub task,
    doing GFP_KERNEL allocations, because before pausing, the scrub task waits
    for all the worker tasks to complete (also done at scrub_stripe()).
    
    So make sure GFP_NOFS is used for the memory allocations because at any
    time a scrub pause request can happen from another task that started to
    commit a transaction.
    
    Fixes: 58c4e173847a ("btrfs: scrub: use GFP_KERNEL on the submission path")
    CC: stable@vger.kernel.org # 4.6+
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 63ac0af6096cd2b1d8ec83e348ddbf3748a107dd
Author: Anand Jain <anand.jain@oracle.com>
Date:   Sun Nov 11 22:22:18 2018 +0800

    btrfs: dev-replace: go back to suspend state if another EXCL_OP is running
    
    commit 05c49e6bc1e8866ecfd674ebeeb58cdbff9145c2 upstream.
    
    In a secnario where balance and replace co-exists as below,
    
      - start balance
      - pause balance
      - start replace
      - reboot
    
    and when system restarts, balance resumes first. Then the replace is
    attempted to restart but will fail as the EXCL_OP lock is already held
    by the balance. If so place the replace state back to
    BTRFS_IOCTL_DEV_REPLACE_STATE_SUSPENDED state.
    
    Fixes: 010a47bde9420 ("btrfs: add proper safety check before resuming dev-replace")
    CC: stable@vger.kernel.org # 4.18+
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 658e75a7f0339a4a664e4693e415f675853b0235
Author: Anand Jain <anand.jain@oracle.com>
Date:   Sun Nov 11 22:22:17 2018 +0800

    btrfs: dev-replace: go back to suspended state if target device is missing
    
    commit 0d228ece59a35a9b9e8ff0d40653234a6d90f61e upstream.
    
    At the time of forced unmount we place the running replace to
    BTRFS_IOCTL_DEV_REPLACE_STATE_SUSPENDED state, so when the system comes
    back and expect the target device is missing.
    
    Then let the replace state continue to be in
    BTRFS_IOCTL_DEV_REPLACE_STATE_SUSPENDED state instead of
    BTRFS_IOCTL_DEV_REPLACE_STATE_STARTED as there isn't any matching scrub
    running as part of replace.
    
    Fixes: e93c89c1aaaa ("Btrfs: add new sources for device replace code")
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Anand Jain <anand.jain@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4e87635f1bced872e33100faa99904ae33c9b9d
Author: Macpaul Lin <macpaul.lin@mediatek.com>
Date:   Wed Dec 19 12:11:03 2018 +0800

    cdc-acm: fix abnormal DATA RX issue for Mediatek Preloader.
    
    commit eafb27fa5283599ce6c5492ea18cf636a28222bb upstream.
    
    Mediatek Preloader is a proprietary embedded boot loader for loading
    Little Kernel and Linux into device DRAM.
    
    This boot loader also handle firmware update. Mediatek Preloader will be
    enumerated as a virtual COM port when the device is connected to Windows
    or Linux OS via CDC-ACM class driver. When the USB enumeration has been
    done, Mediatek Preloader will send out handshake command "READY" to PC
    actively instead of waiting command from the download tool.
    
    Since Linux 4.12, the commit "tty: reset termios state on device
    registration" (93857edd9829e144acb6c7e72d593f6e01aead66) causes Mediatek
    Preloader receiving some abnoraml command like "READYXX" as it sent.
    This will be recognized as an incorrect response. The behavior change
    also causes the download handshake fail. This change only affects
    subsequent connects if the reconnected device happens to get the same minor
    number.
    
    By disabling the ECHO termios flag could avoid this problem. However, it
    cannot be done by user space configuration when download tool open
    /dev/ttyACM0. This is because the device running Mediatek Preloader will
    send handshake command "READY" immediately once the CDC-ACM driver is
    ready.
    
    This patch wants to fix above problem by introducing "DISABLE_ECHO"
    property in driver_info. When Mediatek Preloader is connected, the
    CDC-ACM driver could disable ECHO flag in termios to avoid the problem.
    
    Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Johan Hovold <johan@kernel.org>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27564d8d5d12d2ff197055346069c6bdbe08a8c2
Author: Todd Kjos <tkjos@android.com>
Date:   Fri Dec 14 15:58:21 2018 -0800

    binder: fix use-after-free due to ksys_close() during fdget()
    
    commit 80cd795630d6526ba729a089a435bf74a57af927 upstream.
    
    44d8047f1d8 ("binder: use standard functions to allocate fds")
    exposed a pre-existing issue in the binder driver.
    
    fdget() is used in ksys_ioctl() as a performance optimization.
    One of the rules associated with fdget() is that ksys_close() must
    not be called between the fdget() and the fdput(). There is a case
    where this requirement is not met in the binder driver which results
    in the reference count dropping to 0 when the device is still in
    use. This can result in use-after-free or other issues.
    
    If userpace has passed a file-descriptor for the binder driver using
    a BINDER_TYPE_FDA object, then kys_close() is called on it when
    handling a binder_ioctl(BC_FREE_BUFFER) command. This violates
    the assumptions for using fdget().
    
    The problem is fixed by deferring the close using task_work_add(). A
    new variant of __close_fd() was created that returns a struct file
    with a reference. The fput() is deferred instead of using ksys_close().
    
    Fixes: 44d8047f1d87a ("binder: use standard functions to allocate fds")
    Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Todd Kjos <tkjos@google.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23bd93f4061f72baf980ee7e0d1c465790935950
Author: Tejun Heo <tj@kernel.org>
Date:   Thu Nov 8 12:15:15 2018 -0800

    cgroup: fix CSS_TASK_ITER_PROCS
    
    commit e9d81a1bc2c48ea9782e3e8b53875f419766ef47 upstream.
    
    CSS_TASK_ITER_PROCS implements process-only iteration by making
    css_task_iter_advance() skip tasks which aren't threadgroup leaders;
    however, when an iteration is started css_task_iter_start() calls the
    inner helper function css_task_iter_advance_css_set() instead of
    css_task_iter_advance().  As the helper doesn't have the skip logic,
    when the first task to visit is a non-leader thread, it doesn't get
    skipped correctly as shown in the following example.
    
      # ps -L 2030
        PID   LWP TTY      STAT   TIME COMMAND
       2030  2030 pts/0    Sl+    0:00 ./test-thread
       2030  2031 pts/0    Sl+    0:00 ./test-thread
      # mkdir -p /sys/fs/cgroup/x/a/b
      # echo threaded > /sys/fs/cgroup/x/a/cgroup.type
      # echo threaded > /sys/fs/cgroup/x/a/b/cgroup.type
      # echo 2030 > /sys/fs/cgroup/x/a/cgroup.procs
      # cat /sys/fs/cgroup/x/a/cgroup.threads
      2030
      2031
      # cat /sys/fs/cgroup/x/cgroup.procs
      2030
      # echo 2030 > /sys/fs/cgroup/x/a/b/cgroup.threads
      # cat /sys/fs/cgroup/x/cgroup.procs
      2031
      2030
    
    The last read of cgroup.procs is incorrectly showing non-leader 2031
    in cgroup.procs output.
    
    This can be fixed by updating css_task_iter_advance() to handle the
    first advance and css_task_iters_tart() to call
    css_task_iter_advance() instead of the inner helper.  After the fix,
    the same commands result in the following (correct) result:
    
      # ps -L 2062
        PID   LWP TTY      STAT   TIME COMMAND
       2062  2062 pts/0    Sl+    0:00 ./test-thread
       2062  2063 pts/0    Sl+    0:00 ./test-thread
      # mkdir -p /sys/fs/cgroup/x/a/b
      # echo threaded > /sys/fs/cgroup/x/a/cgroup.type
      # echo threaded > /sys/fs/cgroup/x/a/b/cgroup.type
      # echo 2062 > /sys/fs/cgroup/x/a/cgroup.procs
      # cat /sys/fs/cgroup/x/a/cgroup.threads
      2062
      2063
      # cat /sys/fs/cgroup/x/cgroup.procs
      2062
      # echo 2062 > /sys/fs/cgroup/x/a/b/cgroup.threads
      # cat /sys/fs/cgroup/x/cgroup.procs
      2062
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
    Fixes: 8cfd8147df67 ("cgroup: implement cgroup v2 thread support")
    Cc: stable@vger.kernel.org # v4.14+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fbfb5490006aafe55ec3c812205586488692c8a9
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date:   Sat Oct 20 02:01:52 2018 +0300

    crypto: cfb - fix decryption
    
    commit fa4600734b74f74d9169c3015946d4722f8bcf79 upstream.
    
    crypto_cfb_decrypt_segment() incorrectly XOR'ed generated keystream with
    IV, rather than with data stream, resulting in incorrect decryption.
    Test vectors will be added in the next patch.
    
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e8af8a2519d334c928f165394ed8614ebd6628b
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date:   Sat Oct 20 02:01:53 2018 +0300

    crypto: testmgr - add AES-CFB tests
    
    commit 7da66670775d201f633577f5b15a4bbeebaaa2b0 upstream.
    
    Add AES128/192/256-CFB testvectors from NIST SP800-38A.
    
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8737baede531891e37c7a7456b4bf6b34021c1c3
Author: Atul Gupta <atul.gupta@chelsio.com>
Date:   Fri Nov 30 14:31:48 2018 +0530

    crypto: chcr - small packet Tx stalls the queue
    
    commit c35828ea906a7c76632a0211e59c392903cd4615 upstream.
    
    Immediate packets sent to hardware should include the work
    request length in calculating the flits. WR occupy one flit and
    if not accounted result in invalid request which stalls the HW
    queue.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8c2f908c3ef353c04ab6a49a23265729c66ed34
Author: Wenwen Wang <wang6495@umn.edu>
Date:   Thu Oct 18 19:50:43 2018 -0500

    crypto: cavium/nitrox - fix a DMA pool free failure
    
    commit 7172122be6a4712d699da4d261f92aa5ab3a78b8 upstream.
    
    In crypto_alloc_context(), a DMA pool is allocated through dma_pool_alloc()
    to hold the crypto context. The meta data of the DMA pool, including the
    pool used for the allocation 'ndev->ctx_pool' and the base address of the
    DMA pool used by the device 'dma', are then stored to the beginning of the
    pool. These meta data are eventually used in crypto_free_context() to free
    the DMA pool through dma_pool_free(). However, given that the DMA pool can
    also be accessed by the device, a malicious device can modify these meta
    data, especially when the device is controlled to deploy an attack. This
    can cause an unexpected DMA pool free failure.
    
    To avoid the above issue, this patch introduces a new structure
    crypto_ctx_hdr and a new field chdr in the structure nitrox_crypto_ctx hold
    the meta data information of the DMA pool after the allocation. Note that
    the original structure ctx_hdr is not changed to ensure the compatibility.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Wenwen Wang <wang6495@umn.edu>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff6eea06e845c21b94ef9088115ce12e8e0d39fe
Author: Jernej Skrabec <jernej.skrabec@siol.net>
Date:   Sun Nov 4 19:26:40 2018 +0100

    clk: sunxi-ng: Use u64 for calculation of NM rate
    
    commit 65b6657672388b72822e0367f06d41c1e3ffb5bb upstream.
    
    Allwinner H6 SoC has multiplier N range between 1 and 254. Since parent
    rate is 24MHz, intermediate result when calculating final rate easily
    overflows 32 bit variable.
    
    Because of that, introduce function for calculating clock rate which
    uses 64 bit variable for intermediate result.
    
    Fixes: 6174a1e24b0d ("clk: sunxi-ng: Add N-M-factor clock support")
    Fixes: ee28648cb2b4 ("clk: sunxi-ng: Remove the use of rational computations")
    
    CC: <stable@vger.kernel.org>
    Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d089d4ad6f07793358311b7c877ba39ac2e0ffb8
Author: Johan Jonker <jbx9999@hotmail.com>
Date:   Sat Nov 3 23:54:13 2018 +0100

    clk: rockchip: fix typo in rk3188 spdif_frac parent
    
    commit 8b19faf6fae2867e2c177212c541e8ae36aa4d32 upstream.
    
    Fix typo in common_clk_branches.
    Make spdif_pre parent of spdif_frac.
    
    Fixes: 667464208989 ("clk: rockchip: include downstream muxes into fractional dividers")
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Jonker <jbx9999@hotmail.com>
    Acked-by: Elaine Zhang <zhangqing@rock-chips.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b97c2a128c696bad636b21e36991376fe1733939
Author: Lukas Wunner <lukas@wunner.de>
Date:   Thu Nov 8 08:06:10 2018 +0100

    spi: bcm2835: Avoid finishing transfer prematurely in IRQ mode
    
    commit 56c1723426d3cfd4723bfbfce531d7b38bae6266 upstream.
    
    The IRQ handler bcm2835_spi_interrupt() first reads as much as possible
    from the RX FIFO, then writes as much as possible to the TX FIFO.
    Afterwards it decides whether the transfer is finished by checking if
    the TX FIFO is empty.
    
    If very few bytes were written to the TX FIFO, they may already have
    been transmitted by the time the FIFO's emptiness is checked.  As a
    result, the transfer will be declared finished and the chip will be
    reset without reading the corresponding received bytes from the RX FIFO.
    
    The odds of this happening increase with a high clock frequency (such
    that the TX FIFO drains quickly) and either passing "threadirqs" on the
    command line or enabling CONFIG_PREEMPT_RT_BASE (such that the IRQ
    handler may be preempted between filling the TX FIFO and checking its
    emptiness).
    
    Fix by instead checking whether rx_len has reached zero, which means
    that the transfer has been received in full.  This is also more
    efficient as it avoids one bus read access per interrupt.  Note that
    bcm2835_spi_transfer_one_poll() likewise uses rx_len to determine
    whether the transfer has finished.
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Fixes: e34ff011c70e ("spi: bcm2835: move to the transfer_one driver model")
    Cc: stable@vger.kernel.org # v4.1+
    Cc: Mathias Duckeck <m.duckeck@kunbus.de>
    Cc: Frank Pavlic <f.pavlic@kunbus.de>
    Cc: Martin Sperl <kernel@martin.sperl.org>
    Cc: Noralf Trønnes <noralf@tronnes.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8be53306bf634a8b927e7f7b6ba6954f41715d3b
Author: Lukas Wunner <lukas@wunner.de>
Date:   Thu Nov 8 08:06:10 2018 +0100

    spi: bcm2835: Fix book-keeping of DMA termination
    
    commit dbc944115eed48af110646992893dc43321368d8 upstream.
    
    If submission of a DMA TX transfer succeeds but submission of the
    corresponding RX transfer does not, the BCM2835 SPI driver terminates
    the TX transfer but neglects to reset the dma_pending flag to false.
    
    Thus, if the next transfer uses interrupt mode (because it is shorter
    than BCM2835_SPI_DMA_MIN_LENGTH) and runs into a timeout,
    dmaengine_terminate_all() will be called both for TX (once more) and
    for RX (which was never started in the first place).  Fix it.
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Fixes: 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions")
    Cc: stable@vger.kernel.org # v4.2+
    Cc: Mathias Duckeck <m.duckeck@kunbus.de>
    Cc: Frank Pavlic <f.pavlic@kunbus.de>
    Cc: Martin Sperl <kernel@martin.sperl.org>
    Cc: Noralf Trønnes <noralf@tronnes.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6db3f6f7ff0cbdb0e71d357ca056a675c6b310b1
Author: Lukas Wunner <lukas@wunner.de>
Date:   Thu Nov 8 08:06:10 2018 +0100

    spi: bcm2835: Fix race on DMA termination
    
    commit e82b0b3828451c1cd331d9f304c6078fcd43b62e upstream.
    
    If a DMA transfer finishes orderly right when spi_transfer_one_message()
    determines that it has timed out, the callbacks bcm2835_spi_dma_done()
    and bcm2835_spi_handle_err() race to call dmaengine_terminate_all(),
    potentially leading to double termination.
    
    Prevent by atomically changing the dma_pending flag before calling
    dmaengine_terminate_all().
    
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Fixes: 3ecd37edaa2a ("spi: bcm2835: enable dma modes for transfers meeting certain conditions")
    Cc: stable@vger.kernel.org # v4.2+
    Cc: Mathias Duckeck <m.duckeck@kunbus.de>
    Cc: Frank Pavlic <f.pavlic@kunbus.de>
    Cc: Martin Sperl <kernel@martin.sperl.org>
    Cc: Noralf Trønnes <noralf@tronnes.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 242b67ce9091a2af5996c7651acdb0598ed31218
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Dec 19 14:36:58 2018 -0500

    ext4: check for shutdown and r/o file system in ext4_write_inode()
    
    commit 18f2c4fcebf2582f96cbd5f2238f4f354a0e4847 upstream.
    
    If the file system has been shut down or is read-only, then
    ext4_write_inode() needs to bail out early.
    
    Also use jbd2_complete_transaction() instead of ext4_force_commit() so
    we only force a commit if it is needed.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec9639da0bfc8f57ded2f818e57ec0c854bb1516
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Dec 19 14:07:58 2018 -0500

    ext4: force inode writes when nfsd calls commit_metadata()
    
    commit fde872682e175743e0c3ef939c89e3c6008a1529 upstream.
    
    Some time back, nfsd switched from calling vfs_fsync() to using a new
    commit_metadata() hook in export_operations().  If the file system did
    not provide a commit_metadata() hook, it fell back to using
    sync_inode_metadata().  Unfortunately doesn't work on all file
    systems.  In particular, it doesn't work on ext4 due to how the inode
    gets journalled --- the VFS writeback code will not always call
    ext4_write_inode().
    
    So we need to provide our own ext4_nfs_commit_metdata() method which
    calls ext4_write_inode() directly.
    
    Google-Bug-Id: 121195940
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb2e932e80d7f6f40ed719a1e956fdce0ba96a33
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Dec 19 12:29:13 2018 -0500

    ext4: avoid declaring fs inconsistent due to invalid file handles
    
    commit 8a363970d1dc38c4ec4ad575c862f776f468d057 upstream.
    
    If we receive a file handle, either from NFS or open_by_handle_at(2),
    and it points at an inode which has not been initialized, and the file
    system has metadata checksums enabled, we shouldn't try to get the
    inode, discover the checksum is invalid, and then declare the file
    system as being inconsistent.
    
    This can be reproduced by creating a test file system via "mke2fs -t
    ext4 -O metadata_csum /tmp/foo.img 8M", mounting it, cd'ing into that
    directory, and then running the following program.
    
    #define _GNU_SOURCE
    #include <fcntl.h>
    
    struct handle {
            struct file_handle fh;
            unsigned char fid[MAX_HANDLE_SZ];
    };
    
    int main(int argc, char **argv)
    {
            struct handle h = {{8, 1 }, { 12, }};
    
            open_by_handle_at(AT_FDCWD, &h.fh, O_RDONLY);
            return 0;
    }
    
    Google-Bug-Id: 120690101
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a23f2c8f10e87c98d2dbe4b108a218ee16f5f34b
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Wed Dec 19 12:28:13 2018 -0500

    ext4: include terminating u32 in size of xattr entries when expanding inodes
    
    commit a805622a757b6d7f65def4141d29317d8e37b8a1 upstream.
    
    In ext4_expand_extra_isize_ea(), we calculate the total size of the
    xattr header, plus the xattr entries so we know how much of the
    beginning part of the xattrs to move when expanding the inode extra
    size.  We need to include the terminating u32 at the end of the xattr
    entries, or else if there is uninitialized, non-zero bytes after the
    xattr entries and before the xattr values, the list of xattr entries
    won't be properly terminated.
    
    Reported-by: Steve Graham <stgraham2000@gmail.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33338ad8cbef78ce5d45734b707fde219c33a429
Author: ruippan (潘睿) <ruippan@tencent.com>
Date:   Tue Dec 4 01:04:12 2018 -0500

    ext4: fix EXT4_IOC_GROUP_ADD ioctl
    
    commit e647e29196b7f802f8242c39ecb7cc937f5ef217 upstream.
    
    Commit e2b911c53584 ("ext4: clean up feature test macros with
    predicate functions") broke the EXT4_IOC_GROUP_ADD ioctl.  This was
    not noticed since only very old versions of resize2fs (before
    e2fsprogs 1.42) use this ioctl.  However, using a new kernel with an
    enterprise Linux userspace will cause attempts to use online resize to
    fail with "No reserved GDT blocks".
    
    Fixes: e2b911c53584 ("ext4: clean up feature test macros with predicate...")
    Cc: stable@kernel.org # v4.4
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: ruippan (潘睿) <ruippan@tencent.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e12bbca637fef72b196ff5c8b74cd0f0c181461
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Tue Dec 4 00:06:53 2018 -0500

    ext4: missing unlock/put_page() in ext4_try_to_write_inline_data()
    
    commit 132d00becb31e88469334e1e62751c81345280e0 upstream.
    
    In case of error, ext4_try_to_write_inline_data() should unlock
    and release the page it holds.
    
    Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data")
    Cc: stable@kernel.org # 3.8
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec2222187bdc5f23113e57b6fcd516cd5a2dfa62
Author: Pan Bian <bianpan2016@163.com>
Date:   Mon Dec 3 23:28:02 2018 -0500

    ext4: fix possible use after free in ext4_quota_enable
    
    commit 61157b24e60fb3cd1f85f2c76a7b1d628f970144 upstream.
    
    The function frees qf_inode via iput but then pass qf_inode to
    lockdep_set_quota_inode on the failure path. This may result in a
    use-after-free bug. The patch frees df_inode only when it is never used.
    
    Fixes: daf647d2dd5 ("ext4: add lockdep annotations for i_data_sem")
    Cc: stable@kernel.org # 4.6
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81313ed2c705d958744882a269bf4a5e3ddec95e
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Nov 25 17:20:31 2018 -0500

    ext4: add ext4_sb_bread() to disambiguate ENOMEM cases
    
    commit fb265c9cb49e2074ddcdd4de99728aefdd3b3592 upstream.
    
    Today, when sb_bread() returns NULL, this can either be because of an
    I/O error or because the system failed to allocate the buffer.  Since
    it's an old interface, changing would require changing many call
    sites.
    
    So instead we create our own ext4_sb_bread(), which also allows us to
    set the REQ_META flag.
    
    Also fixed a problem in the xattr code where a NULL return in a
    function could also mean that the xattr was not found, which could
    lead to the wrong error getting returned to userspace.
    
    Fixes: ac27a0ec112a ("ext4: initial copy of files from ext3")
    Cc: stable@kernel.org # 2.6.19
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6824c0bfb4e72b4c16cbfb6b7bbf5e19f2e9069
Author: Greg Kurz <groug@kaod.org>
Date:   Tue Dec 11 18:58:21 2018 +0100

    ocxl: Fix endiannes bug in read_afu_name()
    
    commit 2f07229f02d4c55affccd11a61af4fd4b94dc436 upstream.
    
    The AFU Descriptor Template in the PCI config space has a Name Space
    field which is a 24 Byte ASCII character string of descriptive name
    space for the AFU. The OCXL driver read the string four characters at
    a time with pci_read_config_dword().
    
    This optimization is valid on a little-endian system since this is PCI,
    but a big-endian system ends up with each subset of four characters in
    reverse order.
    
    This could be fixed by switching to read characters one by one. Another
    option is to swap the bytes if we're big-endian.
    
    Go for the latter with le32_to_cpu().
    
    Cc: stable@vger.kernel.org      # v4.16
    Signed-off-by: Greg Kurz <groug@kaod.org>
    Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
    Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f35f3bf6807ecbbe6cdcb61a854a439f3c1080e
Author: Greg Kurz <groug@kaod.org>
Date:   Sun Dec 16 22:28:50 2018 +0100

    ocxl: Fix endiannes bug in ocxl_link_update_pe()
    
    commit e1e71e201703500f708bdeaf64660a2a178cb6a0 upstream.
    
    All fields in the PE are big-endian. Use cpu_to_be32() like everywhere
    else something is written to the PE. Otherwise a wrong TID will be used
    by the NPU. If this TID happens to point to an existing thread sharing
    the same mm, it could be woken up by error. This is highly improbable
    though. The likely outcome of this is the NPU not finding the target
    thread and forcing the AFU into sending an interrupt, which userspace
    is supposed to handle anyway.
    
    Fixes: e948e06fc63a ("ocxl: Expose the thread_id needed for wait on POWER9")
    Cc: stable@vger.kernel.org      # v4.18
    Signed-off-by: Greg Kurz <groug@kaod.org>
    Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c56d81862e5f6248a4b17a5e333a400ad5c3c3d
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Tue Nov 27 11:45:49 2018 -0300

    perf env: Also consider env->arch == NULL as local operation
    
    commit 804234f27180dcf9a25cb98a88d5212f65b7f3fd upstream.
    
    We'll set a new machine field based on env->arch, which for live mode,
    like with 'perf top' means we need to use uname() to figure the name of
    the arch, fix perf_env__arch() to consider both (env == NULL) and
    (env->arch == NULL) as local operation.
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: David Ahern <dsahern@gmail.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Wang Nan <wangnan0@huawei.com>
    Cc: stable@vger.kernel.org # 4.19
    Link: https://lkml.kernel.org/n/tip-vcz4ufzdon7cwy8dm2ua53xk@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a83fe7269520650ccaae8f3e3287623ca9cda59
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Nov 11 18:45:24 2018 +0000

    perf pmu: Suppress potential format-truncation warning
    
    commit 11a64a05dc649815670b1be9fe63d205cb076401 upstream.
    
    Depending on which functions are inlined in util/pmu.c, the snprintf()
    calls in perf_pmu__parse_{scale,unit,per_pkg,snapshot}() might trigger a
    warning:
    
      util/pmu.c: In function 'pmu_aliases':
      util/pmu.c:178:31: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size between 0 and 4095 [-Werror=format-truncation=]
        snprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
                                   ^~
    
    I found this when trying to build perf from Linux 3.16 with gcc 8.
    However I can reproduce the problem in mainline if I force
    __perf_pmu__new_alias() to be inlined.
    
    Suppress this by using scnprintf() as has been done elsewhere in perf.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/20181111184524.fux4taownc6ndbx6@decadent.org.uk
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44e85517e61e40a23151909e4c388bfd730a375e
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Nov 6 23:07:12 2018 +0200

    perf script: Use fallbacks for branch stacks
    
    commit 692d0e63324d2954a0c63a812a8588e97023a295 upstream.
    
    Branch stacks do not necessarily have the same cpumode as the 'ip'. Use
    the fallback functions in those cases.
    
    This patch depends on patch "perf tools: Add fallback functions for cases
    where cpumode is insufficient".
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: stable@vger.kernel.org # 4.19
    Link: http://lkml.kernel.org/r/20181106210712.12098-4-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34af13dd2747bc94444f58f26ec1eefb142d564e
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Nov 6 23:07:11 2018 +0200

    perf tools: Use fallback for sample_addr_correlates_sym() cases
    
    commit 225f99e0c811e23836c4911a2ff147e167dd1fe8 upstream.
    
    thread__resolve() is used in the sample_addr_correlates_sym() cases
    where 'addr' is a destination of a branch which does not necessarily
    have the same cpumode as the 'ip'. Use the fallback function in that
    case.
    
    This patch depends on patch "perf tools: Add fallback functions for
    cases where cpumode is insufficient".
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: stable@vger.kernel.org # 4.19
    Link: http://lkml.kernel.org/r/20181106210712.12098-3-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76514a7511955c25f0adb5f42f403a8e71d1334e
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Nov 6 23:07:10 2018 +0200

    perf thread: Add fallback functions for cases where cpumode is insufficient
    
    commit 8e80ad9983caeee09c3a0a1a37e05bff93becce4 upstream.
    
    For branch stacks or branch samples, the sample cpumode might not be
    correct because it applies only to the sample 'ip' and not necessary to
    'addr' or branch stack addresses. Add fallback functions that can be
    used to deal with those cases
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: stable@vger.kernel.org # 4.19
    Link: http://lkml.kernel.org/r/20181106210712.12098-2-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62a448454fac7d9113a68538b004fb3a8ee49c50
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Nov 6 23:07:10 2018 +0200

    perf machine: Record if a arch has a single user/kernel address space
    
    commit ec1891afae740be581ecf5abc8bda74c4549203f upstream.
    
    Some architectures have a single address space for kernel and user
    addresses, which makes it possible to determine if an address is in
    kernel space or user space. Some don't, e.g.: sparc.
    
    Cache that info in perf_env so that, for instance, code needing to
    fallback failed symbol lookups at the kernel space in single address
    space arches can lookup at userspace.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: stable@vger.kernel.org # 4.19
    Link: http://lkml.kernel.org/r/20181106210712.12098-2-adrian.hunter@intel.com
    [ split from a larger patch ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7d25836ab005b02c8ec5edc57ddb71c0e0f3f1c
Author: Alexey Brodkin <alexey.brodkin@synopsys.com>
Date:   Mon Nov 19 14:29:17 2018 +0300

    clocksource/drivers/arc_timer: Utilize generic sched_clock
    
    commit bf287607c80f24387fedb431a346dc67f25be12c upstream.
    
    It turned out we used to use default implementation of sched_clock()
    from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
    by default we had 10 msec granularity of time measurement.
    
    Now given ARC built-in timers are clocked with the same frequency as
    CPU cores we may get much higher precision of time tracking.
    
    Thus we switch to generic sched_clock which really reads ARC hardware
    counters.
    
    This is especially helpful for measuring short events.
    That's what we used to have:
    ------------------------------>8------------------------
    $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
    
     Performance counter stats for '/bin/sh -c /root/lmbench-master/bin/arc/hello':
    
             10.000000      task-clock (msec)         #    2.832 CPUs utilized
                     1      context-switches          #    0.100 K/sec
                     1      cpu-migrations            #    0.100 K/sec
                    63      page-faults               #    0.006 M/sec
               3049480      cycles                    #    0.305 GHz
               1091259      instructions              #    0.36  insn per cycle
                256828      branches                  #   25.683 M/sec
                 27026      branch-misses             #   10.52% of all branches
    
           0.003530687 seconds time elapsed
    
           0.000000000 seconds user
           0.010000000 seconds sys
    ------------------------------>8------------------------
    
    And now we'll see:
    ------------------------------>8------------------------
    $ perf stat /bin/sh -c /root/lmbench-master/bin/arc/hello > /dev/null
    
     Performance counter stats for '/bin/sh -c /root/lmbench-master/bin/arc/hello':
    
              3.004322      task-clock (msec)         #    0.865 CPUs utilized
                     1      context-switches          #    0.333 K/sec
                     1      cpu-migrations            #    0.333 K/sec
                    63      page-faults               #    0.021 M/sec
               2986734      cycles                    #    0.994 GHz
               1087466      instructions              #    0.36  insn per cycle
                255209      branches                  #   84.947 M/sec
                 26002      branch-misses             #   10.19% of all branches
    
           0.003474829 seconds time elapsed
    
           0.003519000 seconds user
           0.000000000 seconds sys
    ------------------------------>8------------------------
    
    Note how much more meaningful is the second output - time spent for
    execution pretty much matches number of cycles spent (we're runnign
    @ 1GHz here).
    
    Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
    Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
    Cc: Vineet Gupta <vgupta@synopsys.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Acked-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8c6405b61392289df1cae1c189c10244b22cf7b4
Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Date:   Fri Sep 28 17:41:26 2018 +0300

    DRM: UDL: get rid of useless vblank initialization
    
    commit 32e932e37e6b6e13b66add307192c7ddd40a781d upstream.
    
    UDL doesn't support vblank functionality so we don't need to
    initialize vblank here (we are able to send page flip
    completion events even without vblank initialization)
    
    Moreover current drm_vblank_init call with num_crtcs > 0 causes
    sending DRM_EVENT_FLIP_COMPLETE event with zero timestamp every
    time. This breaks userspace apps (for example weston) which
    relies on timestamp value.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180928144126.21598-1-Eugeniy.Paltsev@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca8e08ea8120f4d40f36d50b5f7949f99921878f
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Sep 28 16:21:26 2018 -0700

    drm/v3d: Skip debugfs dumping GCA on platforms without GCA.
    
    commit 2f20fa8d12e859a03f68bdd81d75830141bc9ac9 upstream.
    
    Fixes an oops reading this debugfs entry on BCM7278.
    
    Signed-off-by: Eric Anholt <eric@anholt.net>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180928232126.4332-4-eric@anholt.net
    Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 389587243fb1ec1164bf7f58f2ae1936c63c7f7a
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Thu Oct 11 11:12:34 2018 +0200

    platform-msi: Free descriptors in platform_msi_domain_free()
    
    commit 81b1e6e6a8590a19257e37a1633bec098d499c57 upstream.
    
    Since the addition of platform MSI support, there were two helpers
    supposed to allocate/free IRQs for a device:
    
        platform_msi_domain_alloc_irqs()
        platform_msi_domain_free_irqs()
    
    In these helpers, IRQ descriptors are allocated in the "alloc" routine
    while they are freed in the "free" one.
    
    Later, two other helpers have been added to handle IRQ domains on top
    of MSI domains:
    
        platform_msi_domain_alloc()
        platform_msi_domain_free()
    
    Seen from the outside, the logic is pretty close with the former
    helpers and people used it with the same logic as before: a
    platform_msi_domain_alloc() call should be balanced with a
    platform_msi_domain_free() call. While this is probably what was
    intended to do, the platform_msi_domain_free() does not remove/free
    the IRQ descriptor(s) created/inserted in
    platform_msi_domain_alloc().
    
    One effect of such situation is that removing a module that requested
    an IRQ will let one orphaned IRQ descriptor (with an allocated MSI
    entry) in the device descriptors list. Next time the module will be
    inserted back, one will observe that the allocation will happen twice
    in the MSI domain, one time for the remaining descriptor, one time for
    the new one. It also has the side effect to quickly overshoot the
    maximum number of allocated MSI and then prevent any module requesting
    an interrupt in the same domain to be inserted anymore.
    
    This situation has been met with loops of insertion/removal of the
    mvpp2.ko module (requesting 15 MSIs each time).
    
    Fixes: 552c494a7666 ("platform-msi: Allow creation of a MSI-based stacked irq domain")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35e8f97b275d23ed0d1368310d9c97e3d8e5e84b
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Mon Dec 3 13:52:51 2018 -0800

    KVM: nVMX: Free the VMREAD/VMWRITE bitmaps if alloc_kvm_area() fails
    
    commit 1b3ab5ad1b8ad99bae76ec583809c5f5a31c707c upstream.
    
    Fixes: 34a1cd60d17f ("kvm: x86: vmx: move some vmx setting from vmx_init() to hardware_setup()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4890c68cde2ac49e8aeb997d49c2da3f84220327
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Fri Nov 16 21:28:18 2018 +1100

    KVM: PPC: Book3S HV: Fix race between kvm_unmap_hva_range and MMU mode switch
    
    commit 234ff0b729ad882d20f7996591a964965647addf upstream.
    
    Testing has revealed an occasional crash which appears to be caused
    by a race between kvmppc_switch_mmu_to_hpt and kvm_unmap_hva_range_hv.
    The symptom is a NULL pointer dereference in __find_linux_pte() called
    from kvm_unmap_radix() with kvm->arch.pgtable == NULL.
    
    Looking at kvmppc_switch_mmu_to_hpt(), it does indeed clear
    kvm->arch.pgtable (via kvmppc_free_radix()) before setting
    kvm->arch.radix to NULL, and there is nothing to prevent
    kvm_unmap_hva_range_hv() or the other MMU callback functions from
    being called concurrently with kvmppc_switch_mmu_to_hpt() or
    kvmppc_switch_mmu_to_radix().
    
    This patch therefore adds calls to spin_lock/unlock on the kvm->mmu_lock
    around the assignments to kvm->arch.radix, and makes sure that the
    partition-scoped radix tree or HPT is only freed after changing
    kvm->arch.radix.
    
    This also takes the kvm->mmu_lock in kvmppc_rmap_reset() to make sure
    that the clearing of each rmap array (one per memslot) doesn't happen
    concurrently with use of the array in the kvm_unmap_hva_range_hv()
    or the other MMU callbacks.
    
    Fixes: 18c3640cefc7 ("KVM: PPC: Book3S HV: Add infrastructure for running HPT guests on radix host")
    Cc: stable@vger.kernel.org # v4.15+
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f3bb36883518a4dec083647dc0cbf61125e7f68
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Thu Dec 6 17:31:19 2018 +0000

    arm64: KVM: Make VHE Stage-2 TLB invalidation operations non-interruptible
    
    commit c987876a80e7bcb98a839f10dca9ce7fda4feced upstream.
    
    Contrary to the non-VHE version of the TLB invalidation helpers, the VHE
    code  has interrupts enabled, meaning that we can take an interrupt in
    the middle of such a sequence, and start running something else with
    HCR_EL2.TGE cleared.
    
    That's really not a good idea.
    
    Take the heavy-handed option and disable interrupts in
    __tlb_switch_to_guest_vhe, restoring them in __tlb_switch_to_host_vhe.
    The latter also gain an ISB in order to make sure that TGE really has
    taken effect.
    
    Cc: stable@vger.kernel.org
    Acked-by: Christoffer Dall <christoffer.dall@arm.com>
    Reviewed-by: James Morse <james.morse@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4eace9c4ede8be71911cb43649d0b38c3532748b
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Thu Dec 20 14:21:08 2018 -0800

    KVM: x86: Use jmp to invoke kvm_spurious_fault() from .fixup
    
    commit e81434995081fd7efb755fd75576b35dbb0850b1 upstream.
    
    ____kvm_handle_fault_on_reboot() provides a generic exception fixup
    handler that is used to cleanly handle faults on VMX/SVM instructions
    during reboot (or at least try to).  If there isn't a reboot in
    progress, ____kvm_handle_fault_on_reboot() treats any exception as
    fatal to KVM and invokes kvm_spurious_fault(), which in turn generates
    a BUG() to get a stack trace and die.
    
    When it was originally added by commit 4ecac3fd6dc2 ("KVM: Handle
    virtualization instruction #UD faults during reboot"), the "call" to
    kvm_spurious_fault() was handcoded as PUSH+JMP, where the PUSH'd value
    is the RIP of the faulting instructing.
    
    The PUSH+JMP trickery is necessary because the exception fixup handler
    code lies outside of its associated function, e.g. right after the
    function.  An actual CALL from the .fixup code would show a slightly
    bogus stack trace, e.g. an extra "random" function would be inserted
    into the trace, as the return RIP on the stack would point to no known
    function (and the unwinder will likely try to guess who owns the RIP).
    
    Unfortunately, the JMP was replaced with a CALL when the macro was
    reworked to not spin indefinitely during reboot (commit b7c4145ba2eb
    "KVM: Don't spin on virt instruction faults during reboot").  This
    causes the aforementioned behavior where a bogus function is inserted
    into the stack trace, e.g. my builds like to blame free_kvm_area().
    
    Revert the CALL back to a JMP.  The changelog for commit b7c4145ba2eb
    ("KVM: Don't spin on virt instruction faults during reboot") contains
    nothing that indicates the switch to CALL was deliberate.  This is
    backed up by the fact that the PUSH <insn RIP> was left intact.
    
    Note that an alternative to the PUSH+JMP magic would be to JMP back
    to the "real" code and CALL from there, but that would require adding
    a JMP in the non-faulting path to avoid calling kvm_spurious_fault()
    and would add no value, i.e. the stack trace would be the same.
    
    Using CALL:
    
    ------------[ cut here ]------------
    kernel BUG at /home/sean/go/src/kernel.org/linux/arch/x86/kvm/x86.c:356!
    invalid opcode: 0000 [#1] SMP
    CPU: 4 PID: 1057 Comm: qemu-system-x86 Not tainted 4.20.0-rc6+ #75
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
    RIP: 0010:kvm_spurious_fault+0x5/0x10 [kvm]
    Code: <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 49 89 fd 41
    RSP: 0018:ffffc900004bbcc8 EFLAGS: 00010046
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffffffffff
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffff888273fd8000 R08: 00000000000003e8 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000784 R12: ffffc90000371fb0
    R13: 0000000000000000 R14: 000000026d763cf4 R15: ffff888273fd8000
    FS:  00007f3d69691700(0000) GS:ffff888277800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055f89bc56fe0 CR3: 0000000271a5a001 CR4: 0000000000362ee0
    Call Trace:
     free_kvm_area+0x1044/0x43ea [kvm_intel]
     ? vmx_vcpu_run+0x156/0x630 [kvm_intel]
     ? kvm_arch_vcpu_ioctl_run+0x447/0x1a40 [kvm]
     ? kvm_vcpu_ioctl+0x368/0x5c0 [kvm]
     ? kvm_vcpu_ioctl+0x368/0x5c0 [kvm]
     ? __set_task_blocked+0x38/0x90
     ? __set_current_blocked+0x50/0x60
     ? __fpu__restore_sig+0x97/0x490
     ? do_vfs_ioctl+0xa1/0x620
     ? __x64_sys_futex+0x89/0x180
     ? ksys_ioctl+0x66/0x70
     ? __x64_sys_ioctl+0x16/0x20
     ? do_syscall_64+0x4f/0x100
     ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
    Modules linked in: vhost_net vhost tap kvm_intel kvm irqbypass bridge stp llc
    ---[ end trace 9775b14b123b1713 ]---
    
    Using JMP:
    
    ------------[ cut here ]------------
    kernel BUG at /home/sean/go/src/kernel.org/linux/arch/x86/kvm/x86.c:356!
    invalid opcode: 0000 [#1] SMP
    CPU: 6 PID: 1067 Comm: qemu-system-x86 Not tainted 4.20.0-rc6+ #75
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
    RIP: 0010:kvm_spurious_fault+0x5/0x10 [kvm]
    Code: <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 49 89 fd 41
    RSP: 0018:ffffc90000497cd0 EFLAGS: 00010046
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffffffffff
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffff88827058bd40 R08: 00000000000003e8 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000784 R12: ffffc90000369fb0
    R13: 0000000000000000 R14: 00000003c8fc6642 R15: ffff88827058bd40
    FS:  00007f3d7219e700(0000) GS:ffff888277900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f3d64001000 CR3: 0000000271c6b004 CR4: 0000000000362ee0
    Call Trace:
     vmx_vcpu_run+0x156/0x630 [kvm_intel]
     ? kvm_arch_vcpu_ioctl_run+0x447/0x1a40 [kvm]
     ? kvm_vcpu_ioctl+0x368/0x5c0 [kvm]
     ? kvm_vcpu_ioctl+0x368/0x5c0 [kvm]
     ? __set_task_blocked+0x38/0x90
     ? __set_current_blocked+0x50/0x60
     ? __fpu__restore_sig+0x97/0x490
     ? do_vfs_ioctl+0xa1/0x620
     ? __x64_sys_futex+0x89/0x180
     ? ksys_ioctl+0x66/0x70
     ? __x64_sys_ioctl+0x16/0x20
     ? do_syscall_64+0x4f/0x100
     ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
    Modules linked in: vhost_net vhost tap kvm_intel kvm irqbypass bridge stp llc
    ---[ end trace f9daedb85ab3ddba ]---
    
    Fixes: b7c4145ba2eb ("KVM: Don't spin on virt instruction faults during reboot")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b453a2b14ce8e5bd362d97b3f5cc260479684b20
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Dec 4 13:37:27 2018 -0800

    x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()
    
    commit ba6f508d0ec4adb09f0a939af6d5e19cdfa8667d upstream.
    
    Commit:
    
      f77084d96355 "x86/mm/pat: Disable preemption around __flush_tlb_all()"
    
    addressed a case where __flush_tlb_all() is called without preemption
    being disabled. It also left a warning to catch other cases where
    preemption is not disabled.
    
    That warning triggers for the memory hotplug path which is also used for
    persistent memory enabling:
    
     WARNING: CPU: 35 PID: 911 at ./arch/x86/include/asm/tlbflush.h:460
     RIP: 0010:__flush_tlb_all+0x1b/0x3a
     [..]
     Call Trace:
      phys_pud_init+0x29c/0x2bb
      kernel_physical_mapping_init+0xfc/0x219
      init_memory_mapping+0x1a5/0x3b0
      arch_add_memory+0x2c/0x50
      devm_memremap_pages+0x3aa/0x610
      pmem_attach_disk+0x585/0x700 [nd_pmem]
    
    Andy wondered why a path that can sleep was using __flush_tlb_all() [1]
    and Dave confirmed the expectation for TLB flush is for modifying /
    invalidating existing PTE entries, but not initial population [2]. Drop
    the usage of __flush_tlb_all() in phys_{p4d,pud,pmd}_init() on the
    expectation that this path is only ever populating empty entries for the
    linear map. Note, at linear map teardown time there is a call to the
    all-cpu flush_tlb_all() to invalidate the removed mappings.
    
    [1]: https://lkml.kernel.org/r/9DFD717D-857D-493D-A606-B635D72BAC21@amacapital.net
    [2]: https://lkml.kernel.org/r/749919a4-cdb1-48a3-adb4-adb81a5fa0b5@intel.com
    
    [ mingo: Minor readability edits. ]
    
    Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reported-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: <stable@vger.kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: dave.hansen@intel.com
    Fixes: f77084d96355 ("x86/mm/pat: Disable preemption around __flush_tlb_all()")
    Link: http://lkml.kernel.org/r/154395944713.32119.15611079023837132638.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21289a1a7c53a6da096490017e40f894e52f723e
Author: Michal Hocko <mhocko@suse.com>
Date:   Tue Nov 13 19:49:10 2018 +0100

    x86/speculation/l1tf: Drop the swap storage limit restriction when l1tf=off
    
    commit 5b5e4d623ec8a34689df98e42d038a3b594d2ff9 upstream.
    
    Swap storage is restricted to max_swapfile_size (~16TB on x86_64) whenever
    the system is deemed affected by L1TF vulnerability. Even though the limit
    is quite high for most deployments it seems to be too restrictive for
    deployments which are willing to live with the mitigation disabled.
    
    We have a customer to deploy 8x 6,4TB PCIe/NVMe SSD swap devices which is
    clearly out of the limit.
    
    Drop the swap restriction when l1tf=off is specified. It also doesn't make
    much sense to warn about too much memory for the l1tf mitigation when it is
    forcefully disabled by the administrator.
    
    [ tglx: Folded the documentation delta change ]
    
    Fixes: 377eeaa8e11f ("x86/speculation/l1tf: Limit swap file size to MAX_PA/2")
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Pavel Tatashin <pasha.tatashin@soleen.com>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Acked-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: <linux-mm@kvack.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20181113184910.26697-1-mhocko@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f90519235b728d9c29f6ef4f904d4311b4214a3
Author: Patrick Dreyer <Patrick@Dreyer.name>
Date:   Sun Dec 23 10:06:35 2018 -0800

    Input: elan_i2c - add ACPI ID for touchpad in ASUS Aspire F5-573G
    
    commit 7db54c89f0b30a101584e09d3729144e6170059d upstream.
    
    This adds ELAN0501 to the ACPI table to support Elan touchpad found in ASUS
    Aspire F5-573G.
    
    Signed-off-by: Patrick Dreyer <Patrick.Dreyer@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c995d6d6a7bc39ee49ce208881861d4733937057
Author: Sanjeev Chugh <sanjeev_chugh@mentor.com>
Date:   Fri Dec 28 17:04:31 2018 -0800

    Input: atmel_mxt_ts - don't try to free unallocated kernel memory
    
    commit 1e3c336ad8f40f88a8961c434640920fe35cc08b upstream.
    
    If the user attempts to update Atmel device with an invalid configuration
    cfg file, error handling code is trying to free cfg file memory which is
    not allocated yet hence results into kernel crash.
    
    This patch fixes the order of memory free operations.
    
    Signed-off-by: Sanjeev Chugh <sanjeev_chugh@mentor.com>
    Fixes: a4891f105837 ("Input: atmel_mxt_ts - zero terminate config firmware file")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f736abe1d1ead3d7cad713d421c431494be57d70
Author: Sebastian Ott <sebott@linux.ibm.com>
Date:   Thu Oct 18 11:11:08 2018 +0200

    s390/pci: fix sleeping in atomic during hotplug
    
    commit 98dfd32620e970eb576ebce5ea39d905cb005e72 upstream.
    
    When triggered by pci hotplug (PEC 0x306) clp_get_state is called
    with spinlocks held resulting in the following warning:
    
    zpci: n/a: Event 0x306 reconfigured PCI function 0x0
    BUG: sleeping function called from invalid context at mm/page_alloc.c:4324
    in_atomic(): 1, irqs_disabled(): 0, pid: 98, name: kmcheck
    2 locks held by kmcheck/98:
    
    Change the allocation to use GFP_ATOMIC.
    
    Cc: stable@vger.kernel.org # 4.13+
    Signed-off-by: Sebastian Ott <sebott@linux.ibm.com>
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcb3fbe29a71fcddf70fcdc587f173739a3822de
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Dec 3 21:45:14 2018 +0100

    ASoC: intel: cht_bsw_max98090_ti: Add pmc_plt_clk_0 quirk for Chromebook Gnawty
    
    commit 94ea56cff506c769a509c5dd87904c7fe3806a81 upstream.
    
    The Gnawty model Chromebook uses pmc_plt_clk_0 instead of pmc_plt_clk_3
    for the mclk, just like the Clapper and Swanky models.
    
    This commit adds a DMI based quirk for this.
    
    This fixing audio no longer working on these devices after
    commit 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
    that commit fixes us unnecessary keeping unused clocks on, but in case of
    the Gnawty that was breaking audio support since we were not using the
    right clock in the cht_bsw_max98090_ti machine driver.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201787
    Cc: stable@vger.kernel.org
    Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
    Reported-and-tested-by: Jaime Pérez <19.jaime.91@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b21cb55f391d8a4bf3e9cd37aa7993e63b148ab7
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Dec 2 13:21:22 2018 +0100

    ASoC: intel: cht_bsw_max98090_ti: Add pmc_plt_clk_0 quirk for Chromebook Clapper
    
    commit 984bfb398a3af6fa9b7e80165e524933b0616686 upstream.
    
    The Clapper model Chromebook uses pmc_plt_clk_0 instead of pmc_plt_clk_3
    for the mclk, just like the Swanky model.
    
    This commit adds a DMI based quirk for this.
    
    This fixing audio no longer working on these devices after
    commit 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
    that commit fixes us unnecessary keeping unused clocks on, but in case of
    the Clapper that was breaking audio support since we were not using the
    right clock in the cht_bsw_max98090_ti machine driver.
    
    Cc: stable@vger.kernel.org
    Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit edbcfcb5672b156f981e13345bed252e4705f41e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Dec 17 10:08:54 2018 +0300

    staging: bcm2835-audio: double free in init error path
    
    commit 649496b603000135683ee76d7ea499456617bf17 upstream.
    
    We free instance here and in the caller.  It should be only the caller
    which handles it.
    
    Fixes: d7ca3a71545b ("staging: bcm2835-audio: Operate non-atomic PCM ops")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be8af669984625cc4715b17a37ad58da979495f3
Author: Colin Ian King <colin.king@canonical.com>
Date:   Wed Dec 19 16:30:07 2018 +0000

    staging: wilc1000: fix missing read_write setting when reading data
    
    commit c58eef061dda7d843dcc0ad6fea7e597d4c377c0 upstream.
    
    Currently the cmd.read_write setting is not initialized so it contains
    garbage from the stack.  Fix this by setting it to 0 to indicate a
    read is required.
    
    Detected by CoverityScan, CID#1357925 ("Uninitialized scalar variable")
    
    Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Ajay Singh <ajay.kathat@microchip.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4ed1b1629cbcba97add93baf049142295c5519d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Jan 4 10:23:10 2019 -0800

    i915: fix missing user_access_end() in page fault exception case
    
    commit 0b2c8f8b6b0c7530e2866c95862546d0da2057b0 upstream.
    
    When commit fddcd00a49e9 ("drm/i915: Force the slow path after a
    user-write error") unified the error handling for various user access
    problems, it didn't do the user_access_end() that is needed for the
    unsafe_put_user() case.
    
    It's not a huge deal: a missed user_access_end() will only mean that
    SMAP protection isn't active afterwards, and for the error case we'll be
    returning to user mode soon enough anyway.  But it's wrong, and adding
    the proper user_access_end() is trivial enough (and doing it for the
    other error cases where it isn't needed doesn't hurt).
    
    I noticed it while doing the same prep-work for changing
    user_access_begin() that precipitated the access_ok() changes in commit
    96d4f267e40f ("Remove 'type' argument from access_ok() function").
    
    Fixes: fddcd00a49e9 ("drm/i915: Force the slow path after a user-write error")
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: stable@kernel.org # v4.20
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b78ae16c527ae09df3306c47dc060ba629c1bafb
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Mon Nov 26 15:18:25 2018 -0500

    media: dvb-usb-v2: Fix incorrect use of transfer_flags URB_FREE_BUFFER
    
    commit 255095fa7f62ff09b6f61393414535c59c6b4cb0 upstream.
    
    commit 1a0c10ed7bb1 ("media: dvb-usb-v2: stop using coherent memory for
    URBs") incorrectly adds URB_FREE_BUFFER after every urb transfer.
    
    It cannot use this flag because it reconfigures the URBs accordingly
    to suit connected devices. In doing a call to usb_free_urb is made and
    invertedly frees the buffers.
    
    The stream buffer should remain constant while driver is up.
    
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    CC: stable@vger.kernel.org # v4.18+
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7357b247f3ce1eaeb10fc4529fa8b446072773c
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Wed Dec 12 20:13:55 2018 +0300

    usb: roles: Add a description for the class to Kconfig
    
    commit c3788cd9963eb2e77de3c24142fb7c67b61f1a26 upstream.
    
    That makes the USB role switch support option visible and
    selectable for the user. The class driver is also moved to
    drivers/usb/roles/ directory.
    
    This will fix an issue that we have with the Intel USB role
    switch driver on systems that don't have USB Type-C connectors:
    
    Intel USB role switch driver depends on the USB role switch
    class as it should, but since there was no way for the user
    to enable the USB role switch class, there was also no way
    to select that driver. USB Type-C drivers select the USB
    role switch class which makes the Intel USB role switch
    driver available and therefore hides the problem.
    
    So in practice Intel USB role switch driver was depending on
    USB Type-C drivers.
    
    Fixes: f6fb9ec02be1 ("usb: roles: Add Intel xHCI USB role switch driver")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 685689d4f2c6d11441545cdcf9a8b2f84a141761
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Thu Dec 6 19:42:28 2018 +0100

    Revert "usb: dwc3: pci: Use devm functions to get the phy GPIOs"
    
    commit 3004cfd6204927c1294060b849029cf0c2651074 upstream.
    
    Commit 211f658b7b40 ("usb: dwc3: pci: Use devm functions to get
    the phy GPIOs") changed the code to claim the PHY GPIOs permanently
    for Intel Baytrail devices.
    
    This causes issues when the actual PHY driver attempts to claim the
    same GPIO descriptors. For example, tusb1210 now fails to probe with:
    
      tusb1210: probe of dwc3.0.auto.ulpi failed with error -16 (EBUSY)
    
    dwc3-pci needs to turn on the PHY once before dwc3 is loaded, but
    usually the PHY driver will then hold the GPIOs to turn off the
    PHY when requested (e.g. during suspend).
    
    To fix the problem, this reverts the commit to restore the old
    behavior to put the GPIOs immediately after usage.
    
    Link: https://www.spinics.net/lists/linux-usb/msg174681.html
    Cc: stable@vger.kernel.org
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95ea323a41b5e8e2259ffcfb51d26add24d1f16f
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sun Dec 9 20:01:29 2018 +0100

    usb: dwc2: disable power_down on Amlogic devices
    
    commit cc10ce0c51b13d1566d0ec1dcb472fb86330b391 upstream.
    
    Disable power_down by setting the parameter to
    DWC2_POWER_DOWN_PARAM_NONE. This fixes a problem on various Amlogic
    Meson SoCs where USB devices are only recognized when plugged in before
    booting Linux. A hot-plugged USB device was not detected even though the
    device got power (my USB thumb drive for example has an LED which lit
    up).
    
    A similar fix was implemented for Rockchip SoCs in commit c216765d3a1def
    ("usb: dwc2: disable power_down on rockchip devices"). That commit
    suggests that a change in the dwc2 driver is the cause because the
    default value for the "hibernate" parameter (which then got renamed to
    "power_down" to support other modes) was changed in the v4.17 merge
    window with:
    commit 6d23ee9caa6790 ("Merge tag 'usb-for-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-testing").
    
    Cc: <stable@vger.kernel.org> # 4.19
    Acked-by: Minas Harutyunyan <hminas@synopsys.com>
    Suggested-by: Christian Hewitt <christianshewitt@gmail.com>
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f28980d51f193648501e9298daf5fc43833c05e
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Tue Dec 18 20:04:25 2018 +0800

    usb: r8a66597: Fix a possible concurrency use-after-free bug in r8a66597_endpoint_disable()
    
    commit c85400f886e3d41e69966470879f635a2b50084c upstream.
    
    The function r8a66597_endpoint_disable() and r8a66597_urb_enqueue() may
    be concurrently executed.
    The two functions both access a possible shared variable "hep->hcpriv".
    
    This shared variable is freed by r8a66597_endpoint_disable() via the
    call path:
    r8a66597_endpoint_disable
      kfree(hep->hcpriv) (line 1995 in Linux-4.19)
    
    This variable is read by r8a66597_urb_enqueue() via the call path:
    r8a66597_urb_enqueue
      spin_lock_irqsave(&r8a66597->lock)
      init_pipe_info
        enable_r8a66597_pipe
          pipe = hep->hcpriv (line 802 in Linux-4.19)
    
    The read operation is protected by a spinlock, but the free operation
    is not protected by this spinlock, thus a concurrency use-after-free bug
    may occur.
    
    To fix this bug, the spin-lock and spin-unlock function calls in
    r8a66597_endpoint_disable() are moved to protect the free operation.
    
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9df09e1164dbcaa0bd7c06da3e54e9c546d1546c
Author: Jörgen Storvist <jorgen.storvist@gmail.com>
Date:   Fri Dec 21 14:40:44 2018 +0100

    USB: serial: option: add Fibocom NL678 series
    
    commit 4b2c01ad902ec02fa962b233decd2f14be3714ba upstream.
    
    Added USB serial option driver support for Fibocom NL678 series cellular
    module: VID 2cb7 and PIDs 0x0104 and 0x0105.
    Reserved network and ADB interfaces.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=0104 Rev=03.10
    S:  Manufacturer=Fibocom
    S:  Product=Fibocom NL678-E Modem
    S:  SerialNumber=12345678
    C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=0105 Rev=03.10
    S:  Manufacturer=Fibocom
    S:  Product=Fibocom NL678-E Modem
    S:  SerialNumber=12345678
    C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    I:  If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
    I:  If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    I:  If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    
    Signed-off-by: Jörgen Storvist <jorgen.storvist@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28e4b1f91f94caa8c2800321e1c45105a53c6e87
Author: Scott Chen <scott@labau.com.tw>
Date:   Thu Dec 13 06:01:47 2018 -0500

    USB: serial: pl2303: add ids for Hewlett-Packard HP POS pole displays
    
    commit 8d503f206c336677954160ac62f0c7d9c219cd89 upstream.
    
    Add device ids to pl2303 for the HP POS pole displays:
    LM920:   03f0:026b
    TD620:   03f0:0956
    LD960TA: 03f0:4439
    LD220TA: 03f0:4349
    LM940:   03f0:5039
    
    Signed-off-by: Scott Chen <scott@labau.com.tw>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48ea0393aab353e618b9481541b727869d75aa1a
Author: Terin Stock <terin@terinstock.com>
Date:   Sun Sep 9 21:24:31 2018 -0700

    usb: dwc2: host: use hrtimer for NAK retries
    
    commit 6ed30a7d8ec29d3aba46e47aa8b4a44f077dda4e upstream.
    
    Modify the wait delay utilize the high resolution timer API to allow for
    more precisely scheduled callbacks.
    
    A previous commit added a 1ms retry delay after multiple consecutive
    NAKed transactions using jiffies. On systems with a low timer interrupt
    frequency, this delay may be significantly longer than specified,
    resulting in misbehavior with some USB devices.
    
    This scenario was reached on a Raspberry Pi 3B with a Macally FDD-USB
    floppy drive (identified as 0424:0fdc Standard Microsystems Corp.
    Floppy, based on the USB97CFDC USB FDC). With the relay delay, the drive
    would be unable to mount a disk, replying with NAKs until the device was
    reset.
    
    Using ktime, the delta between starting the timer (in dwc2_hcd_qh_add)
    and the callback function can be determined. With the original delay
    implementation, this value was consistently approximately 12ms. (output
    in us).
    
        <idle>-0     [000] ..s.  1600.559974: dwc2_wait_timer_fn: wait_timer delta: 11976
        <idle>-0     [000] ..s.  1600.571974: dwc2_wait_timer_fn: wait_timer delta: 11977
        <idle>-0     [000] ..s.  1600.583974: dwc2_wait_timer_fn: wait_timer delta: 11976
        <idle>-0     [000] ..s.  1600.595974: dwc2_wait_timer_fn: wait_timer delta: 11977
    
    After converting the relay delay to using a higher resolution timer, the
    delay was much closer to 1ms.
    
        <idle>-0     [000] d.h.  1956.553017: dwc2_wait_timer_fn: wait_timer delta: 1002
        <idle>-0     [000] d.h.  1956.554114: dwc2_wait_timer_fn: wait_timer delta: 1002
        <idle>-0     [000] d.h.  1957.542660: dwc2_wait_timer_fn: wait_timer delta: 1004
        <idle>-0     [000] d.h.  1957.543701: dwc2_wait_timer_fn: wait_timer delta: 1002
    
    The floppy drive operates properly with delays up to approximately 5ms,
    and sends NAKs for any delays that are longer.
    
    Fixes: 38d2b5fb75c1 ("usb: dwc2: host: Don't retry NAKed transactions right away")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Acked-by: Minas Harutyunyan <hminas@synopsys.com>
    Signed-off-by: Terin Stock <terin@terinstock.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51eec25c146aa024a973abcd1b3e5986f5df691f
Author: Sameer Pujar <spujar@nvidia.com>
Date:   Wed Dec 26 16:04:49 2018 +0530

    ALSA: hda/tegra: clear pending irq handlers
    
    commit 63d2a9ec310d8bcc955574220d4631aa55c1a80c upstream.
    
    Even after disabling interrupts on the module, it could be possible
    that irq handlers are still running. System hang is seen during
    suspend path. It was found that, there were pending writes on the
    HDA bus and clock was disabled by that time.
    
    Above mentioned issue is fixed by clearing any pending irq handlers
    before disabling clocks and returning from hda suspend.
    
    Suggested-by: Mohan Kumar <mkumard@nvidia.com>
    Suggested-by: Dara Ramesh <dramesh@nvidia.com>
    Signed-off-by: Sameer Pujar <spujar@nvidia.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00854dc84ba116993fd70dcea76ae5d7eb5e0d69
Author: Jian-Hong Pan <jian-hong@endlessm.com>
Date:   Thu Dec 27 16:46:31 2018 +0800

    ALSA: hda/realtek: Enable the headset mic auto detection for ASUS laptops
    
    commit 82b01149ec94d746867d7f9156c44d775d4d2d67 upstream.
    
    The headset mic of ASUS laptops like UX533FD, UX433FN and UX333FA, whose
    CODEC is Realtek ALC294 has jack auto detection feature. This patch
    enables the feature.
    
    Fixes: 4e051106730d ("ALSA: hda/realtek: Enable audio jacks of ASUS UX533FD with ALC294")
    Signed-off-by: Daniel Drake <drake@endlessm.com>
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8668a8e4665e8d824c8206d4dfb15ed3000cb744
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Dec 15 19:03:21 2018 +0900

    ALSA: firewire-lib: use the same print format for 'without_header' tracepoints
    
    commit 5ef108c53e6efd695e32aad969638ccbc35b4be9 upstream.
    
    An initial commit to add tracepoints for packets without CIP headers
    uses different print formats for added tracepoints. However this is not
    convenient for users/developers to prepare debug tools.
    
    This commit uses the same format for the two tracepoints.
    
    Cc: <stable@vger.kernel.org> # v4.12+
    Fixes: b164d2fd6e49 ('ALSA: firewire_lib: add tracepoints for packets without CIP headers')
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 753f6fc8ad8c4f4297bd5be83c7d523ad1b00c36
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Dec 15 19:03:20 2018 +0900

    ALSA: firewire-lib: fix wrong assignment for 'out_packet_without_header' tracepoint
    
    commit aa9a9e39b4f65733bf19d90cbd026e85a74efb99 upstream.
    
    An initial commit to add tracepoints for packets without CIP headers
    introduces a wrong assignment to 'data_blocks' value of
    'out_packet_without_header' tracepoint.
    
    This commit fixes the bug.
    
    Cc: <stable@vger.kernel.org> # v4.12+
    Fixes: b164d2fd6e49 ('ALSA: firewire_lib: add tracepoints for packets without CIP headers')
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad735deced43a3d9f53fefb811068d48efd1dafa
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Dec 15 19:03:19 2018 +0900

    ALSA: firewire-lib: fix wrong handling payload_length as payload_quadlet
    
    commit ada79fa5a0b374dd2c2262137c734da7524a8263 upstream.
    
    In IEC 61883-1/6 engine of ALSA firewire stack, a packet handler has a
    second argument for 'the number of bytes in payload of isochronous
    packet'. However, an incoming packet handler without CIP header uses the
    value as 'the number of quadlets in the payload'. This brings userspace
    applications to receive the number of PCM frames as four times against
    real time.
    
    This commit fixes the bug.
    
    Cc: <stable@vger.kernel.org> # v4.12+
    Fixes: 3b196c394dd ('ALSA: firewire-lib: add no-header packet processing')
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 875d3cbf20f17eaf265ef83429cfa074fcc2bd91
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Dec 15 19:06:48 2018 +0900

    ALSA: fireface: fix for state to fetch PCM frames
    
    commit 3d16200a3e55a39caa1c88419cb559c00316f721 upstream.
    
    According to my memo at hand and saved records, writing 0x00000001 to
    SND_FF_REG_FETCH_PCM_FRAMES disables fetching PCM frames in corresponding
    channel, however current implement uses reversed logic. This results in
    muted volume in device side during playback.
    
    This commit corrects the bug.
    
    Cc: <stable@vger.kernel.org> # v4.12+
    Fixes: 76fdb3a9e13a ('ALSA: fireface: add support for Fireface 400')
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c371e41715c716704a8ff73191480c96aea76a93
Author: Wandrille RONCE <w@ndrille.fr>
Date:   Wed Dec 19 14:52:44 2018 +0100

    ALSA: hda/realtek: Enable audio jacks of ASUS UX391UA with ALC294
    
    commit 9cf6533e8060d3896b88ea14b27f620e6504b84b upstream.
    
    By default, there is no sound on Asus UX391UA on Linux.
    
    This patch adds sound support on Asus UX391UA. Tested working by three
    different users.
    
    The problem has also been described at
    https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1784485
    
    Signed-off-by: Wandrille RONCE <w@ndrille.fr>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aee3217d233364fbf85d038de5aa8335c55465cf
Author: Mantas MikulÄ—nas <grawity@gmail.com>
Date:   Sun Dec 16 15:44:47 2018 +0200

    ALSA: hda: add mute LED support for HP EliteBook 840 G4
    
    commit 40906ebe3af6a48457151b3c6726b480f6a6cb13 upstream.
    
    Tested with 4.19.9.
    
    v2: Changed from CXT_FIXUP_MUTE_LED_GPIO to CXT_FIXUP_HP_DOCK because
        that's what the existing fixups for EliteBooks use.
    
    Signed-off-by: Mantas MikulÄ—nas <grawity@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1573c0daf2e28db03352c77e0528eee9f6f9858
Author: Boris Brezillon <boris.brezillon@bootlin.com>
Date:   Thu Dec 13 20:22:27 2018 +0100

    mtd: rawnand: omap2: Pass the parent of pdev to dma_request_chan()
    
    commit 9b432630e0150b777c423fdef6a7b8d17dfa70b6 upstream.
    
    Commit e1e6255c311b ("mtd: rawnand: omap2: convert driver to
    nand_scan()") moved part of the init code in the ->attach_chip hook
    and at the same time changed the struct device object passed to
    dma_request_chan() (&pdev->dev instead of pdev->dev.parent).
    
    Fixes: e1e6255c311b ("mtd: rawnand: omap2: convert driver to nand_scan()")
    Reported-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ea4f23ccc0168962bc5935ab3c38ab1835d7ecf0
Author: Boris Brezillon <boris.brezillon@bootlin.com>
Date:   Thu Dec 13 11:55:26 2018 +0100

    mtd: rawnand: Fix JEDEC detection
    
    commit b637ef779575a977068025f842ecd480a9671f3f upstream.
    
    nand_jedec_detect() should return 1 when the PARAM page parsing
    succeeds, otherwise the core considers JEDEC detection failed and falls
    back to ID-based detection.
    
    Fixes: 480139d9229e ("mtd: rawnand: get rid of the JEDEC parameter page in nand_chip")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4533824642a5fbbfa7aec87d4a561a571cd1d814
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Tue Dec 11 18:38:28 2018 +0100

    mtd: rawnand: marvell: prevent timeouts on a loaded machine
    
    commit cafb56dd741e61c99709bcd2b193a9a1d36def3b upstream.
    
    marvell_nfc_wait_op() waits for completion during 'timeout_ms'
    milliseconds before throwing an error. While the logic is fine, the
    value of 'timeout_ms' is given by the core and actually correspond to
    the maximum time the NAND chip will take to complete the
    operation. Assuming there is no overhead in the propagation of the
    interrupt signal to the the NAND controller (through the Ready/Busy
    line), this delay does not take into account the latency of the
    operating system. For instance, for a page write, the delay given by
    the core is rounded up to 1ms. Hence, when the machine is over loaded,
    there is chances that this timeout will be reached.
    
    There are two ways to solve this issue that are not incompatible:
    1/ Enlarge the timeout value (if so, how much?).
    2/ Check after the waiting method if we did not miss any interrupt
    because of the OS latency (an interrupt is still pending). In this
    case, we assume the operation exited successfully.
    
    We choose the second approach that is a must in all cases, with the
    possibility to also modify the timeout value to be, e.g. at least 1
    second in all cases.
    
    Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dbd3776668703f29a199b50d71452e3cd348709d
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Dec 10 21:38:16 2018 +0100

    mtd: atmel-quadspi: disallow building on ebsa110
    
    commit 2a9d92fb3a1282a4659f1bb6d5684018846537b7 upstream.
    
    I ran into a link-time error with the atmel-quadspi driver on the
    EBSA110 platform:
    
    drivers/mtd/built-in.o: In function `atmel_qspi_run_command':
    :(.text+0x1ee3c): undefined reference to `_memcpy_toio'
    :(.text+0x1ee48): undefined reference to `_memcpy_fromio'
    
    The problem is that _memcpy_toio/_memcpy_fromio are not available on
    that platform, and we have to prevent building the driver there.
    
    In case we want to backport this to older kernels: between linux-4.8
    and linux-4.20, the Kconfig entry was in drivers/mtd/spi-nor/Kconfig
    but had the same problem.
    
    Link: https://lore.kernel.org/patchwork/patch/812860/
    Fixes: 161aaab8a067 ("mtd: atmel-quadspi: add driver for Atmel QSPI controller")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7708c700cca564534b2eb03c86d44d0d01052216
Author: Diana Craciun <diana.craciun@nxp.com>
Date:   Wed Dec 12 16:03:02 2018 +0200

    powerpc/fsl: Fix spectre_v2 mitigations reporting
    
    commit 7d8bad99ba5a22892f0cad6881289fdc3875a930 upstream.
    
    Currently for CONFIG_PPC_FSL_BOOK3E the spectre_v2 file is incorrect:
    
      $ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
      "Mitigation: Software count cache flush"
    
    Which is wrong. Fix it to report vulnerable for now.
    
    Fixes: ee13cb249fab ("powerpc/64s: Add support for software count cache flush")
    Cc: stable@vger.kernel.org # v4.19+
    Signed-off-by: Diana Craciun <diana.craciun@nxp.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bae543e26fad8e04759aa018f1fb42e9efdc7737
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Wed Dec 12 11:20:49 2018 -0600

    ALSA: emux: Fix potential Spectre v1 vulnerabilities
    
    commit 4aea96f4237cea0c51a8bc87c0db31f0f932f1f0 upstream.
    
    info.mode and info.port are indirectly controlled by user-space,
    hence leading to a potential exploitation of the Spectre variant 1
    vulnerability.
    
    These issues were detected with the help of Smatch:
    
    sound/synth/emux/emux_hwdep.c:72 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs[i]->ctrls' [w] (local cap)
    sound/synth/emux/emux_hwdep.c:75 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs' [w] (local cap)
    sound/synth/emux/emux_hwdep.c:75 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs[info.port]->ctrls' [w] (local cap)
    
    Fix this by sanitizing both info.mode and info.port before using them
    to index emu->portptrs[i]->ctrls, emu->portptrs[info.port]->ctrls and
    emu->portptrs.
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 147ce164dc66fff0e6e136de43948e55dcd3fbeb
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Wed Dec 12 15:36:28 2018 -0600

    ALSA: pcm: Fix potential Spectre v1 vulnerability
    
    commit 94ffb030b6d31ec840bb811be455dd2e26a4f43e upstream.
    
    stream is indirectly controlled by user-space, hence leading to
    a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    sound/core/pcm.c:140 snd_pcm_control_ioctl() warn: potential spectre issue 'pcm->streams' [r] (local cap)
    
    Fix this by sanitizing stream before using it to index pcm->streams
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
    
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c79e32763d802170deedce8da34b5ba858676fa1
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Dec 18 11:52:16 2018 -0600

    ALSA: emu10k1: Fix potential Spectre v1 vulnerabilities
    
    commit 5ae4f61f012a097df93de2285070ec8e34716d29 upstream.
    
    ipcm->substream is indirectly controlled by user-space, hence leading to
    a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    sound/pci/emu10k1/emufx.c:1031 snd_emu10k1_ipcm_poke() warn: potential spectre issue 'emu->fx8010.pcm' [r] (local cap)
    sound/pci/emu10k1/emufx.c:1075 snd_emu10k1_ipcm_peek() warn: potential spectre issue 'emu->fx8010.pcm' [r] (local cap)
    
    Fix this by sanitizing ipcm->substream before using it to index emu->fx8010.pcm
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3aa298d0daa2a20c41dc6e2daf4199d1dd2d593
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Tue Dec 18 11:18:34 2018 -0600

    ALSA: rme9652: Fix potential Spectre v1 vulnerability
    
    commit 0b84304ef5da92add8dc75a1b07879c5374cdb05 upstream.
    
    info->channel is indirectly controlled by user-space, hence leading to
    a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    sound/pci/rme9652/hdsp.c:4100 snd_hdsp_channel_info() warn: potential spectre issue 'hdsp->channel_map' [r] (local cap)
    
    Fix this by sanitizing info->channel before using it to index hdsp->channel_map
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    Also, notice that I refactored the code a bit in order to get rid of the
    following checkpatch warning:
    
    ERROR: do not use assignment in if condition
    FILE: sound/pci/rme9652/hdsp.c:4103:
            if ((mapped_channel = hdsp->channel_map[info->channel]) < 0)
    
    [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66dd9082b74066591ef5e2dd5ec905aeb77ccafa
Author: Michael J. Ruhl <michael.j.ruhl@intel.com>
Date:   Wed Nov 28 10:19:36 2018 -0800

    IB/hfi1: Incorrect sizing of sge for PIO will OOPs
    
    commit dbc2970caef74e8ff41923d302aa6fb5a4812d0e upstream.
    
    An incorrect sge sizing in the HFI PIO path will cause an OOPs similar to
    this:
    
    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [] hfi1_verbs_send_pio+0x3d8/0x530 [hfi1]
    PGD 0
    Oops: 0000 1 SMP
     Call Trace:
     ? hfi1_verbs_send_dma+0xad0/0xad0 [hfi1]
     hfi1_verbs_send+0xdf/0x250 [hfi1]
     ? make_rc_ack+0xa80/0xa80 [hfi1]
     hfi1_do_send+0x192/0x430 [hfi1]
     hfi1_do_send_from_rvt+0x10/0x20 [hfi1]
     rvt_post_send+0x369/0x820 [rdmavt]
     ib_uverbs_post_send+0x317/0x570 [ib_uverbs]
     ib_uverbs_write+0x26f/0x420 [ib_uverbs]
     ? security_file_permission+0x21/0xa0
     vfs_write+0xbd/0x1e0
     ? mntput+0x24/0x40
     SyS_write+0x7f/0xe0
     system_call_fastpath+0x16/0x1b
    
    Fix by adding the missing sizing check to correctly determine the sge
    length.
    
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c96ca4e2064e542940f496696a4e3ec5c81fca92
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Sun Dec 23 21:45:56 2018 -0800

    tipc: fix a double free in tipc_enable_bearer()
    
    [ Upstream commit dc4501ff287547dea7ca10f1c580c741291a8760 ]
    
    bearer_disable() already calls kfree_rcu() to free struct tipc_bearer,
    we don't need to call kfree() again.
    
    Fixes: cb30a63384bc ("tipc: refactor function tipc_enable_bearer()")
    Reported-by: syzbot+b981acf1fb240c0c128b@syzkaller.appspotmail.com
    Cc: Ying Xue <ying.xue@windriver.com>
    Cc: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a912b531d8f3e7d6ced926e55a301ea6defbd410
Author: Deepa Dinamani <deepa.kernel@gmail.com>
Date:   Thu Dec 27 18:55:09 2018 -0800

    sock: Make sock->sk_stamp thread-safe
    
    [ Upstream commit 3a0ed3e9619738067214871e9cb826fa23b2ddb9 ]
    
    Al Viro mentioned (Message-ID
    <20170626041334.GZ10672@ZenIV.linux.org.uk>)
    that there is probably a race condition
    lurking in accesses of sk_stamp on 32-bit machines.
    
    sock->sk_stamp is of type ktime_t which is always an s64.
    On a 32 bit architecture, we might run into situations of
    unsafe access as the access to the field becomes non atomic.
    
    Use seqlocks for synchronization.
    This allows us to avoid using spinlocks for readers as
    readers do not need mutual exclusion.
    
    Another approach to solve this is to require sk_lock for all
    modifications of the timestamps. The current approach allows
    for timestamps to have their own lock: sk_stamp_lock.
    This allows for the patch to not compete with already
    existing critical sections, and side effects are limited
    to the paths in the patch.
    
    The addition of the new field maintains the data locality
    optimizations from
    commit 9115e8cd2a0c ("net: reorganize struct sock for better data
    locality")
    
    Note that all the instances of the sk_stamp accesses
    are either through the ioctl or the syscall recvmsg.
    
    Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 618cdf94999b4de3dccfca50a819b95794a4703d
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Sun Dec 30 12:43:42 2018 -0800

    ptr_ring: wrap back ->producer in __ptr_ring_swap_queue()
    
    [ Upstream commit aff6db454599d62191aabc208930e891748e4322 ]
    
    __ptr_ring_swap_queue() tries to move pointers from the old
    ring to the new one, but it forgets to check if ->producer
    is beyond the new size at the end of the operation. This leads
    to an out-of-bound access in __ptr_ring_produce() as reported
    by syzbot.
    
    Reported-by: syzbot+8993c0fa96d57c399735@syzkaller.appspotmail.com
    Fixes: 5d49de532002 ("ptr_ring: resize support")
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: John Fastabend <john.fastabend@gmail.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87393463eda5b0649d604f0e59fece4418dd7e0e
Author: Willem de Bruijn <willemb@google.com>
Date:   Sat Dec 22 16:53:45 2018 -0500

    packet: validate address length if non-zero
    
    [ Upstream commit 6b8d95f1795c42161dc0984b6863e95d6acf24ed ]
    
    Validate packet socket address length if a length is given. Zero
    length is equivalent to not setting an address.
    
    Fixes: 99137b7888f4 ("packet: validate address length")
    Reported-by: Ido Schimmel <idosch@idosch.org>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e792339a10a65e695e7d5321208ac98061847c64
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Sat Dec 29 13:56:37 2018 -0800

    net/wan: fix a double free in x25_asy_open_tty()
    
    [ Upstream commit d5c7c745f254c6cb98b3b3f15fe789b8bd770c72 ]
    
    When x25_asy_open() fails, it already cleans up by itself,
    so its caller doesn't need to free the memory again.
    
    It seems we still have to call x25_asy_free() to clear the SLF_INUSE
    bit, so just set these pointers to NULL after kfree().
    
    Reported-and-tested-by: syzbot+5e5e969e525129229052@syzkaller.appspotmail.com
    Fixes: 3b780bed3138 ("x25_asy: Free x25_asy on x25_asy_open() failure.")
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 094e75ae2c8cc0f5387bc276c14c99d2ca815ece
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Sat Dec 29 13:56:38 2018 -0800

    netrom: fix locking in nr_find_socket()
    
    [ Upstream commit 7314f5480f3e37e570104dc5e0f28823ef849e72 ]
    
    nr_find_socket(), nr_find_peer() and nr_find_listener() lock the
    sock after finding it in the global list. However, the call path
    requires BH disabled for the sock lock consistently.
    
    Actually the locking is unnecessary at this point, we can just hold
    the sock refcnt to make sure it is not gone after we unlock the global
    list, and lock it later only when needed.
    
    Reported-and-tested-by: syzbot+f621cda8b7e598908efa@syzkaller.appspotmail.com
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 112f239bef5efbb811b667ec182e762bd6c15324
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jan 2 09:20:27 2019 -0800

    isdn: fix kernel-infoleak in capi_unlocked_ioctl
    
    [ Upstream commit d63967e475ae10f286dbd35e189cb241e0b1f284 ]
    
    Since capi_ioctl() copies 64 bytes after calling
    capi20_get_manufacturer() we need to ensure to not leak
    information to user.
    
    BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
    CPU: 0 PID: 11245 Comm: syz-executor633 Not tainted 4.20.0-rc7+ #2
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x173/0x1d0 lib/dump_stack.c:113
     kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
     kmsan_internal_check_memory+0x9d4/0xb00 mm/kmsan/kmsan.c:704
     kmsan_copy_to_user+0xab/0xc0 mm/kmsan/kmsan_hooks.c:601
     _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
     capi_ioctl include/linux/uaccess.h:177 [inline]
     capi_unlocked_ioctl+0x1a0b/0x1bf0 drivers/isdn/capi/capi.c:939
     do_vfs_ioctl+0xebd/0x2bf0 fs/ioctl.c:46
     ksys_ioctl fs/ioctl.c:713 [inline]
     __do_sys_ioctl fs/ioctl.c:720 [inline]
     __se_sys_ioctl+0x1da/0x270 fs/ioctl.c:718
     __x64_sys_ioctl+0x4a/0x70 fs/ioctl.c:718
     do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    RIP: 0033:0x440019
    Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007ffdd4659fb8 EFLAGS: 00000213 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440019
    RDX: 0000000020000080 RSI: 00000000c0044306 RDI: 0000000000000003
    RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
    R10: 0000000000000000 R11: 0000000000000213 R12: 00000000004018a0
    R13: 0000000000401930 R14: 0000000000000000 R15: 0000000000000000
    
    Local variable description: ----data.i@capi_unlocked_ioctl
    Variable was created at:
     capi_ioctl drivers/isdn/capi/capi.c:747 [inline]
     capi_unlocked_ioctl+0x82/0x1bf0 drivers/isdn/capi/capi.c:939
     do_vfs_ioctl+0xebd/0x2bf0 fs/ioctl.c:46
    
    Bytes 12-63 of 64 are uninitialized
    Memory access of size 64 starts at ffff88807ac5fce8
    Data copied to user address 0000000020000080
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Karsten Keil <isdn@linux-pingi.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bc55a3bb32294d64e2a80e6857851c6771013f6
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jan 2 04:24:20 2019 -0800

    net/hamradio/6pack: use mod_timer() to rearm timers
    
    [ Upstream commit 202700e30740c6568b5a6943662f3829566dd533 ]
    
    Using del_timer() + add_timer() is generally unsafe on SMP,
    as noticed by syzbot. Use mod_timer() instead.
    
    kernel BUG at kernel/time/timer.c:1136!
    invalid opcode: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 1026 Comm: kworker/u4:4 Not tainted 4.20.0+ #2
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: events_unbound flush_to_ldisc
    RIP: 0010:add_timer kernel/time/timer.c:1136 [inline]
    RIP: 0010:add_timer+0xa81/0x1470 kernel/time/timer.c:1134
    Code: 4d 89 7d 40 48 c7 85 70 fe ff ff 00 00 00 00 c7 85 7c fe ff ff ff ff ff ff 48 89 85 90 fe ff ff e9 e6 f7 ff ff e8 cf 42 12 00 <0f> 0b e8 c8 42 12 00 0f 0b e8 c1 42 12 00 4c 89 bd 60 fe ff ff e9
    RSP: 0018:ffff8880a7fdf5a8 EFLAGS: 00010293
    RAX: ffff8880a7846340 RBX: dffffc0000000000 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffffffff816f3ee1 RDI: ffff88808a514ff8
    RBP: ffff8880a7fdf760 R08: 0000000000000007 R09: ffff8880a7846c58
    R10: ffff8880a7846340 R11: 0000000000000000 R12: ffff88808a514ff8
    R13: ffff88808a514ff8 R14: ffff88808a514dc0 R15: 0000000000000030
    FS:  0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000000061c500 CR3: 00000000994d9000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     decode_prio_command drivers/net/hamradio/6pack.c:903 [inline]
     sixpack_decode drivers/net/hamradio/6pack.c:971 [inline]
     sixpack_receive_buf drivers/net/hamradio/6pack.c:457 [inline]
     sixpack_receive_buf+0xf9c/0x1470 drivers/net/hamradio/6pack.c:434
     tty_ldisc_receive_buf+0x164/0x1c0 drivers/tty/tty_buffer.c:465
     tty_port_default_receive_buf+0x114/0x190 drivers/tty/tty_port.c:38
     receive_buf drivers/tty/tty_buffer.c:481 [inline]
     flush_to_ldisc+0x3b2/0x590 drivers/tty/tty_buffer.c:533
     process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
     worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
     kthread+0x357/0x430 kernel/kthread.c:246
     ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Andreas Koensgen <ajk@comnets.uni-bremen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f48945b6b093570994f37deade9c17f30d59bd86
Author: Willem de Bruijn <willemb@google.com>
Date:   Sun Dec 30 17:24:36 2018 -0500

    ip: validate header length on virtual device xmit
    
    [ Upstream commit cb9f1b783850b14cbd7f87d061d784a666dfba1f ]
    
    KMSAN detected read beyond end of buffer in vti and sit devices when
    passing truncated packets with PF_PACKET. The issue affects additional
    ip tunnel devices.
    
    Extend commit 76c0ddd8c3a6 ("ip6_tunnel: be careful when accessing the
    inner header") and commit ccfec9e5cb2d ("ip_tunnel: be careful when
    accessing the inner header").
    
    Move the check to a separate helper and call at the start of each
    ndo_start_xmit function in net/ipv4 and net/ipv6.
    
    Minor changes:
    - convert dev_kfree_skb to kfree_skb on error path,
      as dev_kfree_skb calls consume_skb which is not for error paths.
    - use pskb_network_may_pull even though that is pedantic here,
      as the same as pskb_may_pull for devices without llheaders.
    - do not cache ipv6 hdrs if used only once
      (unsafe across pskb_may_pull, was more relevant to earlier patch)
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 081a7c92b24d5923ae666fbdade94b56f80ff3a9
Author: Willem de Bruijn <willemb@google.com>
Date:   Sun Dec 23 12:52:18 2018 -0500

    ieee802154: lowpan_header_create check must check daddr
    
    [ Upstream commit 40c3ff6d5e0809505a067dd423c110c5658c478c ]
    
    Packet sockets may call dev_header_parse with NULL daddr. Make
    lowpan_header_ops.create fail.
    
    Fixes: 87a93e4eceb4 ("ieee802154: change needed headroom/tailroom")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Alexander Aring <aring@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05267524fcb6be51abd4e62dfeedf86a58206376
Author: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date:   Mon Dec 31 15:43:01 2018 -0600

    ibmveth: fix DMA unmap error in ibmveth_xmit_start error path
    
    [ Upstream commit 756af9c642329d54f048bac2a62f829b391f6944 ]
    
    Commit 33a48ab105a7 ("ibmveth: Fix DMA unmap error") fixed an issue in the
    normal code path of ibmveth_xmit_start() that was originally introduced by
    Commit 6e8ab30ec677 ("ibmveth: Add scatter-gather support"). This original
    fix missed the error path where dma_unmap_page is wrongly called on the
    header portion in descs[0] which was mapped with dma_map_single. As a
    result a failure to DMA map any of the frags results in a dmesg warning
    when CONFIG_DMA_API_DEBUG is enabled.
    
    ------------[ cut here ]------------
    DMA-API: ibmveth 30000002: device driver frees DMA memory with wrong function
      [device address=0x000000000a430000] [size=172 bytes] [mapped as page] [unmapped as single]
    WARNING: CPU: 1 PID: 8426 at kernel/dma/debug.c:1085 check_unmap+0x4fc/0xe10
    ...
    <snip>
    ...
    DMA-API: Mapped at:
    ibmveth_start_xmit+0x30c/0xb60
    dev_hard_start_xmit+0x100/0x450
    sch_direct_xmit+0x224/0x490
    __qdisc_run+0x20c/0x980
    __dev_queue_xmit+0x1bc/0xf20
    
    This fixes the API misuse by unampping descs[0] with dma_unmap_single.
    
    Fixes: 6e8ab30ec677 ("ibmveth: Add scatter-gather support")
    Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77768c96dcf860c43b970b87b2a09229f84ea560
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Sat Dec 29 13:56:36 2018 -0800

    ax25: fix a use-after-free in ax25_fillin_cb()
    
    [ Upstream commit c433570458e49bccea5c551df628d058b3526289 ]
    
    There are multiple issues here:
    
    1. After freeing dev->ax25_ptr, we need to set it to NULL otherwise
       we may use a dangling pointer.
    
    2. There is a race between ax25_setsockopt() and device notifier as
       reported by syzbot. Close it by holding RTNL lock.
    
    3. We need to test if dev->ax25_ptr is NULL before using it.
    
    Reported-and-tested-by: syzbot+ae6bb869cbed29b29040@syzkaller.appspotmail.com
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cae5ef1f37a475faf7c40bc6a3c170779f3e0b1
Author: Willem de Bruijn <willemb@google.com>
Date:   Sun Dec 30 17:21:05 2018 -0500

    tap: call skb_probe_transport_header after setting skb->dev
    
    [ Upstream commit 8c76e77f9069f10505c08e02646c3ee11ad79038 ]
    
    The BPF flow dissector expects either skb->sk or skb->dev set on
    all skbs. Delay flow dissection until after skb->dev is set.
    
    This requires calling from within an rcu read-side critical section.
    That is fine, see also the call from tun_xdp_one.
    
    Fixes: d0e13a1488ad ("flow_dissector: lookup netns by skb->sk if skb->dev is NULL")
    Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c1bbe5ddf15ab8c1aa9fa419ba11bd726306820
Author: Ivan Mironov <mironov.ivan@gmail.com>
Date:   Mon Dec 24 20:13:05 2018 +0500

    bnx2x: Fix NULL pointer dereference in bnx2x_del_all_vlans() on some hw
    
    [ Upstream commit 38355a5f9a22bfa5bd5b1bb79805aca39fa53729 ]
    
    This happened when I tried to boot normal Fedora 29 system with latest
    available kernel (from fedora rawhide, plus some unrelated custom
    patches):
    
            BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
            PGD 0 P4D 0
            Oops: 0010 [#1] SMP PTI
            CPU: 6 PID: 1422 Comm: libvirtd Tainted: G          I       4.20.0-0.rc7.git3.hpsa2.1.fc29.x86_64 #1
            Hardware name: HP ProLiant BL460c G6, BIOS I24 05/21/2018
            RIP: 0010:          (null)
            Code: Bad RIP value.
            RSP: 0018:ffffa47ccdc9fbe0 EFLAGS: 00010246
            RAX: 0000000000000000 RBX: 00000000000003e8 RCX: ffffa47ccdc9fbf8
            RDX: ffffa47ccdc9fc00 RSI: ffff97d9ee7b01f8 RDI: ffff97d9f0150b80
            RBP: ffff97d9f0150b80 R08: 0000000000000000 R09: 0000000000000000
            R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003
            R13: ffff97d9ef1e53e8 R14: 0000000000000009 R15: ffff97d9f0ac6730
            FS:  00007f4d224ef700(0000) GS:ffff97d9fa200000(0000) knlGS:0000000000000000
            CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
            CR2: ffffffffffffffd6 CR3: 00000011ece52006 CR4: 00000000000206e0
            Call Trace:
             ? bnx2x_chip_cleanup+0x195/0x610 [bnx2x]
             ? bnx2x_nic_unload+0x1e2/0x8f0 [bnx2x]
             ? bnx2x_reload_if_running+0x24/0x40 [bnx2x]
             ? bnx2x_set_features+0x79/0xa0 [bnx2x]
             ? __netdev_update_features+0x244/0x9e0
             ? netlink_broadcast_filtered+0x136/0x4b0
             ? netdev_update_features+0x22/0x60
             ? dev_disable_lro+0x1c/0xe0
             ? devinet_sysctl_forward+0x1c6/0x211
             ? proc_sys_call_handler+0xab/0x100
             ? __vfs_write+0x36/0x1a0
             ? rcu_read_lock_sched_held+0x79/0x80
             ? rcu_sync_lockdep_assert+0x2e/0x60
             ? __sb_start_write+0x14c/0x1b0
             ? vfs_write+0x159/0x1c0
             ? vfs_write+0xba/0x1c0
             ? ksys_write+0x52/0xc0
             ? do_syscall_64+0x60/0x1f0
             ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    After some investigation I figured out that recently added cleanup code
    tries to call VLAN filtering de-initialization function which exist only
    for newer hardware. Corresponding function pointer is not
    set (== 0) for older hardware, namely these chips:
    
            #define CHIP_NUM_57710                  0x164e
            #define CHIP_NUM_57711                  0x164f
            #define CHIP_NUM_57711E                 0x1650
    
    And I have one of those in my test system:
    
            Broadcom Inc. and subsidiaries NetXtreme II BCM57711E 10-Gigabit PCIe [14e4:1650]
    
    Function bnx2x_init_vlan_mac_fp_objs() from
    drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h decides whether to
    initialize relevant pointers in bnx2x_sp_objs.vlan_obj or not.
    
    This regression was introduced after v4.20-rc7, and still exists in v4.20
    release.
    
    Fixes: 04f05230c5c13 ("bnx2x: Remove configured vlans as part of unload sequence.")
    Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
    Signed-off-by: Ivan Mironov <mironov.ivan@gmail.com>
    Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e81410164d20f3ebf21c6f0320986e8833dbfcf6
Author: Jacopo Mondi <jacopo+renesas@jmondi.org>
Date:   Mon Dec 3 03:44:16 2018 -0500

    media: ov5640: Fix set format regression
    
    commit 07115449919383548d094ff83cc27bd08639a8a1 upstream.
    
    The set_fmt operations updates the sensor format only when the image format
    is changed. When only the image sizes gets changed, the format do not get
    updated causing the sensor to always report the one that was previously in
    use.
    
    Without this patch, updating frame size only fails:
      [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ...]
    
    With this patch applied:
      [fmt:UYVY8_2X8/1024x768@1/30 field:none colorspace:srgb xfer:srgb ...]
    
    Fixes: 6949d864776e ("media: ov5640: do not change mode if format or frame interval is unchanged")
    
    Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Tested-by: Adam Ford <aford173@gmail.com> #imx6 w/ CSI2 interface on 4.19.6 and 4.20-RC5
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1dfa11700357d707e2fcc875067064e2d8a8d0f9
Author: Ihab Zhaika <ihab.zhaika@intel.com>
Date:   Tue Jul 31 09:53:09 2018 +0300

    iwlwifi: add new cards for 9560, 9462, 9461 and killer series
    
    commit f108703cb5f199d0fc98517ac29a997c4c646c94 upstream.
    
    add few PCI ID'S for 9560, 9462, 9461 and killer series.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 452eb4bdf2181b64501b61fdbc9e54ec2c1ad7e3
Author: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date:   Thu Oct 25 19:10:36 2018 +0900

    panic: avoid deadlocks in re-entrant console drivers
    
    commit c7c3f05e341a9a2bd1a92993d4f996cfd6e7348e upstream.
    
    From printk()/serial console point of view panic() is special, because
    it may force CPU to re-enter printk() or/and serial console driver.
    Therefore, some of serial consoles drivers are re-entrant. E.g. 8250:
    
    serial8250_console_write()
    {
            if (port->sysrq)
                    locked = 0;
            else if (oops_in_progress)
                    locked = spin_trylock_irqsave(&port->lock, flags);
            else
                    spin_lock_irqsave(&port->lock, flags);
            ...
    }
    
    panic() does set oops_in_progress via bust_spinlocks(1), so in theory
    we should be able to re-enter serial console driver from panic():
    
            CPU0
            <NMI>
            uart_console_write()
            serial8250_console_write()              // if (oops_in_progress)
                                                    //    spin_trylock_irqsave()
            call_console_drivers()
            console_unlock()
            console_flush_on_panic()
            bust_spinlocks(1)                       // oops_in_progress++
            panic()
            <NMI/>
            spin_lock_irqsave(&port->lock, flags)   // spin_lock_irqsave()
            serial8250_console_write()
            call_console_drivers()
            console_unlock()
            printk()
            ...
    
    However, this does not happen and we deadlock in serial console on
    port->lock spinlock. And the problem is that console_flush_on_panic()
    called after bust_spinlocks(0):
    
    void panic(const char *fmt, ...)
    {
            bust_spinlocks(1);
            ...
            bust_spinlocks(0);
            console_flush_on_panic();
            ...
    }
    
    bust_spinlocks(0) decrements oops_in_progress, so oops_in_progress
    can go back to zero. Thus even re-entrant console drivers will simply
    spin on port->lock spinlock. Given that port->lock may already be
    locked either by a stopped CPU, or by the very same CPU we execute
    panic() on (for instance, NMI panic() on printing CPU) the system
    deadlocks and does not reboot.
    
    Fix this by removing bust_spinlocks(0), so oops_in_progress is always
    set in panic() now and, thus, re-entrant console drivers will trylock
    the port->lock instead of spinning on it forever, when we call them
    from console_flush_on_panic().
    
    Link: http://lkml.kernel.org/r/20181025101036.6823-1-sergey.senozhatsky@gmail.com
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Daniel Wang <wonderfly@google.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
    Cc: Jiri Slaby <jslaby@suse.com>
    Cc: Peter Feiner <pfeiner@google.com>
    Cc: linux-serial@vger.kernel.org
    Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>