commit 58b454ebf81e5ae9391957d99cf89566d9eec1b1
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 17 08:37:55 2019 +0200

    Linux 4.14.112

commit aadf60280ad3dd71ca4867cc5de2ee7af16a2bb9
Author: Tomohiro Mayama <parly-gh@iris.mystia.org>
Date:   Sun Mar 10 01:10:12 2019 +0900

    arm64: dts: rockchip: Fix vcc_host1_5v GPIO polarity on rk3328-rock64
    
    commit a8772e5d826d0f61f8aa9c284b3ab49035d5273d upstream.
    
    This patch makes USB ports functioning again.
    
    Fixes: 955bebde057e ("arm64: dts: rockchip: add rk3328-rock64 board")
    Cc: stable@vger.kernel.org
    Suggested-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Tomohiro Mayama <parly-gh@iris.mystia.org>
    Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1debe428dd6d56114abe3333f245c58ac64d89c1
Author: Katsuhiro Suzuki <katsuhiro@katsuster.net>
Date:   Fri Sep 7 00:39:47 2018 +0900

    arm64: dts: rockchip: fix vcc_host1_5v pin assign on rk3328-rock64
    
    commit ef05bcb60c1a8841e38c91923ba998181117a87c upstream.
    
    This patch fixes pin assign of vcc_host1_5v. This regulator is
    controlled by USB20_HOST_DRV signal.
    
    ROCK64 schematic says that GPIO0_A2 pin is used as USB20_HOST_DRV.
    GPIO0_D3 pin is for SPDIF_TX_M0.
    
    Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f51343153e69aad32e0520bd1e77bcc315b6d16
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Tue Mar 26 20:20:58 2019 +0100

    dm table: propagate BDI_CAP_STABLE_WRITES to fix sporadic checksum errors
    
    commit eb40c0acdc342b815d4d03ae6abb09e80c0f2988 upstream.
    
    Some devices don't use blk_integrity but still want stable pages
    because they do their own checksumming.  Examples include rbd and iSCSI
    when data digests are negotiated.  Stacking DM (and thus LVM) on top of
    these devices results in sporadic checksum errors.
    
    Set BDI_CAP_STABLE_WRITES if any underlying device has it set.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b5832ca0c6f7a8de496db56509c2e56721bcb12
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Fri Apr 5 16:20:47 2019 +0100

    PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller
    
    commit 9cde402a59770a0669d895399c13407f63d7d209 upstream.
    
    There is a Marvell 88SE9170 PCIe SATA controller I found on a board here.
    Some quick testing with the ARM SMMU enabled reveals that it suffers from
    the same requester ID mixup problems as the other Marvell chips listed
    already.
    
    Add the PCI vendor/device ID to the list of chips which need the
    workaround.
    
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52abad475c06b54bbd009927aac56ff15f5c2552
Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
Date:   Tue Apr 2 15:21:18 2019 +0000

    x86/perf/amd: Remove need to check "running" bit in NMI handler
    
    commit 3966c3feca3fd10b2935caa0b4a08c7dd59469e5 upstream.
    
    Spurious interrupt support was added to perf in the following commit, almost
    a decade ago:
    
      63e6be6d98e1 ("perf, x86: Catch spurious interrupts after disabling counters")
    
    The two previous patches (resolving the race condition when disabling a
    PMC and NMI latency mitigation) allow for the removal of this older
    spurious interrupt support.
    
    Currently in x86_pmu_stop(), the bit for the PMC in the active_mask bitmap
    is cleared before disabling the PMC, which sets up a race condition. This
    race condition was mitigated by introducing the running bitmap. That race
    condition can be eliminated by first disabling the PMC, waiting for PMC
    reset on overflow and then clearing the bit for the PMC in the active_mask
    bitmap. The NMI handler will not re-enable a disabled counter.
    
    If x86_pmu_stop() is called from the perf NMI handler, the NMI latency
    mitigation support will guard against any unhandled NMI messages.
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: <stable@vger.kernel.org> # 4.14.x-
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Link: https://lkml.kernel.org/r/Message-ID:
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b09d75485316570a05209ddc8fa23e3a998f4cc2
Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
Date:   Tue Apr 2 15:21:16 2019 +0000

    x86/perf/amd: Resolve NMI latency issues for active PMCs
    
    commit 6d3edaae16c6c7d238360f2841212c2b26774d5e upstream.
    
    On AMD processors, the detection of an overflowed PMC counter in the NMI
    handler relies on the current value of the PMC. So, for example, to check
    for overflow on a 48-bit counter, bit 47 is checked to see if it is 1 (not
    overflowed) or 0 (overflowed).
    
    When the perf NMI handler executes it does not know in advance which PMC
    counters have overflowed. As such, the NMI handler will process all active
    PMC counters that have overflowed. NMI latency in newer AMD processors can
    result in multiple overflowed PMC counters being processed in one NMI and
    then a subsequent NMI, that does not appear to be a back-to-back NMI, not
    finding any PMC counters that have overflowed. This may appear to be an
    unhandled NMI resulting in either a panic or a series of messages,
    depending on how the kernel was configured.
    
    To mitigate this issue, add an AMD handle_irq callback function,
    amd_pmu_handle_irq(), that will invoke the common x86_pmu_handle_irq()
    function and upon return perform some additional processing that will
    indicate if the NMI has been handled or would have been handled had an
    earlier NMI not handled the overflowed PMC. Using a per-CPU variable, a
    minimum value of the number of active PMCs or 2 will be set whenever a
    PMC is active. This is used to indicate the possible number of NMIs that
    can still occur. The value of 2 is used for when an NMI does not arrive
    at the LAPIC in time to be collapsed into an already pending NMI. Each
    time the function is called without having handled an overflowed counter,
    the per-CPU value is checked. If the value is non-zero, it is decremented
    and the NMI indicates that it handled the NMI. If the value is zero, then
    the NMI indicates that it did not handle the NMI.
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: <stable@vger.kernel.org> # 4.14.x-
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Link: https://lkml.kernel.org/r/Message-ID:
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58d78a4342ff61a15025283f28ebb390773e7ad8
Author: Lendacky, Thomas <Thomas.Lendacky@amd.com>
Date:   Tue Apr 2 15:21:14 2019 +0000

    x86/perf/amd: Resolve race condition when disabling PMC
    
    commit 914123fa39042e651d79eaf86bbf63a1b938dddf upstream.
    
    On AMD processors, the detection of an overflowed counter in the NMI
    handler relies on the current value of the counter. So, for example, to
    check for overflow on a 48 bit counter, bit 47 is checked to see if it
    is 1 (not overflowed) or 0 (overflowed).
    
    There is currently a race condition present when disabling and then
    updating the PMC. Increased NMI latency in newer AMD processors makes this
    race condition more pronounced. If the counter value has overflowed, it is
    possible to update the PMC value before the NMI handler can run. The
    updated PMC value is not an overflowed value, so when the perf NMI handler
    does run, it will not find an overflowed counter. This may appear as an
    unknown NMI resulting in either a panic or a series of messages, depending
    on how the kernel is configured.
    
    To eliminate this race condition, the PMC value must be checked after
    disabling the counter. Add an AMD function, amd_pmu_disable_all(), that
    will wait for the NMI handler to reset any active and overflowed counter
    after calling x86_pmu_disable_all().
    
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: <stable@vger.kernel.org> # 4.14.x-
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Link: https://lkml.kernel.org/r/Message-ID:
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ab04e849f5b6c2d679a5ae383187997e7e98232
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Thu Apr 4 11:08:40 2019 -0700

    xtensa: fix return_address
    
    commit ada770b1e74a77fff2d5f539bf6c42c25f4784db upstream.
    
    return_address returns the address that is one level higher in the call
    stack than requested in its argument, because level 0 corresponds to its
    caller's return address. Use requested level as the number of stack
    frames to skip.
    
    This fixes the address reported by might_sleep and friends.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b711ae1252a072ed600fee34d0e06230fda0a1f4
Author: Mel Gorman <mgorman@techsingularity.net>
Date:   Tue Mar 19 12:36:10 2019 +0000

    sched/fair: Do not re-read ->h_load_next during hierarchical load calculation
    
    commit 0e9f02450da07fc7b1346c8c32c771555173e397 upstream.
    
    A NULL pointer dereference bug was reported on a distribution kernel but
    the same issue should be present on mainline kernel. It occured on s390
    but should not be arch-specific.  A partial oops looks like:
    
      Unable to handle kernel pointer dereference in virtual kernel address space
      ...
      Call Trace:
        ...
        try_to_wake_up+0xfc/0x450
        vhost_poll_wakeup+0x3a/0x50 [vhost]
        __wake_up_common+0xbc/0x178
        __wake_up_common_lock+0x9e/0x160
        __wake_up_sync_key+0x4e/0x60
        sock_def_readable+0x5e/0x98
    
    The bug hits any time between 1 hour to 3 days. The dereference occurs
    in update_cfs_rq_h_load when accumulating h_load. The problem is that
    cfq_rq->h_load_next is not protected by any locking and can be updated
    by parallel calls to task_h_load. Depending on the compiler, code may be
    generated that re-reads cfq_rq->h_load_next after the check for NULL and
    then oops when reading se->avg.load_avg. The dissassembly showed that it
    was possible to reread h_load_next after the check for NULL.
    
    While this does not appear to be an issue for later compilers, it's still
    an accident if the correct code is generated. Full locking in this path
    would have high overhead so this patch uses READ_ONCE to read h_load_next
    only once and check for NULL before dereferencing. It was confirmed that
    there were no further oops after 10 days of testing.
    
    As Peter pointed out, it is also necessary to use WRITE_ONCE() to avoid any
    potential problems with store tearing.
    
    Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Fixes: 685207963be9 ("sched: Move h_load calculation to task_h_load()")
    Link: https://lkml.kernel.org/r/20190319123610.nsivgf3mjbjjesxb@techsingularity.net
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f0b27cf8a73e8dbc35347891202929b0d202ba0
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Apr 4 18:12:17 2019 +0300

    xen: Prevent buffer overflow in privcmd ioctl
    
    commit 42d8644bd77dd2d747e004e367cb0c895a606f39 upstream.
    
    The "call" variable comes from the user in privcmd_ioctl_hypercall().
    It's an offset into the hypercall_page[] which has (PAGE_SIZE / 32)
    elements.  We need to put an upper bound on it to prevent an out of
    bounds access.
    
    Cc: stable@vger.kernel.org
    Fixes: 1246ae0bb992 ("xen: add variable hypercall caller")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ed78eba4b5474add9c534f25f0dfdfd5a8df38d
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Apr 8 17:56:34 2019 +0100

    arm64: backtrace: Don't bother trying to unwind the userspace stack
    
    commit 1e6f5440a6814d28c32d347f338bfef68bc3e69d upstream.
    
    Calling dump_backtrace() with a pt_regs argument corresponding to
    userspace doesn't make any sense and our unwinder will simply print
    "Call trace:" before unwinding the stack looking for user frames.
    
    Rather than go through this song and dance, just return early if we're
    passed a user register state.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 1149aad10b1e ("arm64: Add dump_backtrace() in show_regs")
    Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e5c0620db8bda12c235548a891f0aadb93ed5a2
Author: Peter Geis <pgwipeout@gmail.com>
Date:   Wed Mar 13 18:45:36 2019 +0000

    arm64: dts: rockchip: fix rk3328 rgmii high tx error rate
    
    commit 6fd8b9780ec1a49ac46e0aaf8775247205e66231 upstream.
    
    Several rk3328 based boards experience high rgmii tx error rates.
    This is due to several pins in the rk3328.dtsi rgmii pinmux that are
    missing a defined pull strength setting.
    This causes the pinmux driver to default to 2ma (bit mask 00).
    
    These pins are only defined in the rk3328.dtsi, and are not listed in
    the rk3328 specification.
    The TRM only lists them as "Reserved"
    (RK3328 TRM V1.1, 3.3.3 Detail Register Description, GRF_GPIO0B_IOMUX,
    GRF_GPIO0C_IOMUX, GRF_GPIO0D_IOMUX).
    However, removal of these pins from the rgmii pinmux definition causes
    the interface to fail to transmit.
    
    Also, the rgmii tx and rx pins defined in the dtsi are not consistent
    with the rk3328 specification, with tx pins currently set to 12ma and
    rx pins set to 2ma.
    
    Fix this by setting tx pins to 8ma and the rx pins to 4ma, consistent
    with the specification.
    Defining the drive strength for the undefined pins eliminated the high
    tx packet error rate observed under heavy data transfers.
    Aligning the drive strength to the TRM values eliminated the occasional
    packet retry errors under iperf3 testing.
    This allows much higher data rates with no recorded tx errors.
    
    Tested on the rk3328-roc-cc board.
    
    Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Peter Geis <pgwipeout@gmail.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8dba39c7a29f7651ad8e61fe0737d7c1ba42225
Author: Will Deacon <will.deacon@arm.com>
Date:   Mon Apr 8 12:45:09 2019 +0100

    arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value
    
    commit 045afc24124d80c6998d9c770844c67912083506 upstream.
    
    Rather embarrassingly, our futex() FUTEX_WAKE_OP implementation doesn't
    explicitly set the return value on the non-faulting path and instead
    leaves it holding the result of the underlying atomic operation. This
    means that any FUTEX_WAKE_OP atomic operation which computes a non-zero
    value will be reported as having failed. Regrettably, I wrote the buggy
    code back in 2011 and it was upstreamed as part of the initial arm64
    support in 2012.
    
    The reasons we appear to get away with this are:
    
      1. FUTEX_WAKE_OP is rarely used and therefore doesn't appear to get
         exercised by futex() test applications
    
      2. If the result of the atomic operation is zero, the system call
         behaves correctly
    
      3. Prior to version 2.25, the only operation used by GLIBC set the
         futex to zero, and therefore worked as expected. From 2.25 onwards,
         FUTEX_WAKE_OP is not used by GLIBC at all.
    
    Fix the implementation by ensuring that the return value is either 0
    to indicate that the atomic operation completed successfully, or -EFAULT
    if we encountered a fault when accessing the user mapping.
    
    Cc: <stable@kernel.org>
    Fixes: 6170a97460db ("arm64: Atomic operations")
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 377b54a6fb64e026ead623dbeb8c814b5bd934b0
Author: David Engraf <david.engraf@sysgo.com>
Date:   Mon Mar 11 08:57:42 2019 +0100

    ARM: dts: at91: Fix typo in ISC_D0 on PC9
    
    commit e7dfb6d04e4715be1f3eb2c60d97b753fd2e4516 upstream.
    
    The function argument for the ISC_D0 on PC9 was incorrect. According to
    the documentation it should be 'C' aka 3.
    
    Signed-off-by: David Engraf <david.engraf@sysgo.com>
    Reviewed-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux")
    Cc: <stable@vger.kernel.org> # v4.4+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84a8a44a6ccdaa955901ea6f3320b7b52ae3ff93
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Fri Mar 15 12:59:09 2019 +0200

    ARM: dts: am335x-evm: Correct the regulators for the audio codec
    
    commit 4f96dc0a3e79ec257a2b082dab3ee694ff88c317 upstream.
    
    Correctly map the regulators used by tlv320aic3106.
    Both 1.8V and 3.3V for the codec is derived from VBAT via fixed regulators.
    
    Cc: <Stable@vger.kernel.org> # v4.14+
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9af55767d7fa0f06e28dc16078800f1cf84b388c
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Fri Mar 15 12:59:17 2019 +0200

    ARM: dts: am335x-evmsk: Correct the regulators for the audio codec
    
    commit 6691370646e844be98bb6558c024269791d20bd7 upstream.
    
    Correctly map the regulators used by tlv320aic3106.
    Both 1.8V and 3.3V for the codec is derived from VBAT via fixed regulators.
    
    Cc: <Stable@vger.kernel.org> # v4.14+
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b69a78ac089b07fb919b464c35c0fcfca242c14
Author: Cornelia Huck <cohuck@redhat.com>
Date:   Mon Apr 8 14:33:22 2019 +0200

    virtio: Honour 'may_reduce_num' in vring_create_virtqueue
    
    commit cf94db21905333e610e479688add629397a4b384 upstream.
    
    vring_create_virtqueue() allows the caller to specify via the
    may_reduce_num parameter whether the vring code is allowed to
    allocate a smaller ring than specified.
    
    However, the split ring allocation code tries to allocate a
    smaller ring on allocation failure regardless of what the
    caller specified. This may cause trouble for e.g. virtio-pci
    in legacy mode, which does not support ring resizing. (The
    packed ring code does not resize in any case.)
    
    Let's fix this by bailing out immediately in the split ring code
    if the requested size cannot be allocated and may_reduce_num has
    not been specified.
    
    While at it, fix a typo in the usage instructions.
    
    Fixes: 2a2d1382fe9d ("virtio: Add improved queue allocation API")
    Cc: stable@vger.kernel.org # v4.6+
    Signed-off-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
    Reviewed-by: Jens Freimann <jfreimann@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82e1fb4d3780333e5e406157b8dc48dfb0734ed1
Author: Kefeng Wang <wangkefeng.wang@huawei.com>
Date:   Thu Apr 4 15:45:12 2019 +0800

    genirq: Initialize request_mutex if CONFIG_SPARSE_IRQ=n
    
    commit e8458e7afa855317b14915d7b86ab3caceea7eb6 upstream.
    
    When CONFIG_SPARSE_IRQ is disable, the request_mutex in struct irq_desc
    is not initialized which causes malfunction.
    
    Fixes: 9114014cf4e6 ("genirq: Add mutex to irq desc to serialize request/free_irq()")
    Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
    Cc: Marc Zyngier <marc.zyngier@arm.com>
    Cc: <linux-arm-kernel@lists.infradead.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190404074512.145533-1-wangkefeng.wang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3559f73ed6db1df2bd8a65ded63246d9e3bb21c9
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Mon Mar 25 11:10:26 2019 -0700

    genirq: Respect IRQCHIP_SKIP_SET_WAKE in irq_chip_set_wake_parent()
    
    commit 325aa19598e410672175ed50982f902d4e3f31c5 upstream.
    
    If a child irqchip calls irq_chip_set_wake_parent() but its parent irqchip
    has the IRQCHIP_SKIP_SET_WAKE flag set an error is returned.
    
    This is inconsistent behaviour vs. set_irq_wake_real() which returns 0 when
    the irqchip has the IRQCHIP_SKIP_SET_WAKE flag set. It doesn't attempt to
    walk the chain of parents and set irq wake on any chips that don't have the
    flag set either. If the intent is to call the .irq_set_wake() callback of
    the parent irqchip, then we expect irqchip implementations to omit the
    IRQCHIP_SKIP_SET_WAKE flag and implement an .irq_set_wake() function that
    calls irq_chip_set_wake_parent().
    
    The problem has been observed on a Qualcomm sdm845 device where set wake
    fails on any GPIO interrupts after applying work in progress wakeup irq
    patches to the GPIO driver. The chain of chips looks like this:
    
         QCOM GPIO -> QCOM PDC (SKIP) -> ARM GIC (SKIP)
    
    The GPIO controllers parent is the QCOM PDC irqchip which in turn has ARM
    GIC as parent.  The QCOM PDC irqchip has the IRQCHIP_SKIP_SET_WAKE flag
    set, and so does the grandparent ARM GIC.
    
    The GPIO driver doesn't know if the parent needs to set wake or not, so it
    unconditionally calls irq_chip_set_wake_parent() causing this function to
    return a failure because the parent irqchip (PDC) doesn't have the
    .irq_set_wake() callback set. Returning 0 instead makes everything work and
    irqs from the GPIO controller can be configured for wakeup.
    
    Make it consistent by returning 0 (success) from irq_chip_set_wake_parent()
    when a parent chip has IRQCHIP_SKIP_SET_WAKE set.
    
    [ tglx: Massaged changelog ]
    
    Fixes: 08b55e2a9208e ("genirq: Add irqchip_set_wake_parent")
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-gpio@vger.kernel.org
    Cc: Lina Iyer <ilina@codeaurora.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190325181026.247796-1-swboyd@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6991eb26278b4b9b599a1611a6f65fa765ff403
Author: Jason Yan <yanaijie@huawei.com>
Date:   Fri Apr 12 10:09:16 2019 +0800

    block: fix the return errno for direct IO
    
    commit a89afe58f1a74aac768a5eb77af95ef4ee15beaa upstream.
    
    If the last bio returned is not dio->bio, the status of the bio will
    not assigned to dio->bio if it is error. This will cause the whole IO
    status wrong.
    
        ksoftirqd/21-117   [021] ..s.  4017.966090:   8,0    C   N 4883648 [0]
              <idle>-0     [018] ..s.  4017.970888:   8,0    C  WS 4924800 + 1024 [0]
              <idle>-0     [018] ..s.  4017.970909:   8,0    D  WS 4935424 + 1024 [<idle>]
              <idle>-0     [018] ..s.  4017.970924:   8,0    D  WS 4936448 + 321 [<idle>]
        ksoftirqd/21-117   [021] ..s.  4017.995033:   8,0    C   R 4883648 + 336 [65475]
        ksoftirqd/21-117   [021] d.s.  4018.001988: myprobe1: (blkdev_bio_end_io+0x0/0x168) bi_status=7
        ksoftirqd/21-117   [021] d.s.  4018.001992: myprobe: (aio_complete_rw+0x0/0x148) x0=0xffff802f2595ad80 res=0x12a000 res2=0x0
    
    We always have to assign bio->bi_status to dio->bio.bi_status because we
    will only check dio->bio.bi_status when we return the whole IO to
    the upper layer.
    
    Fixes: 542ff7bf18c6 ("block: new direct I/O implementation")
    Cc: stable@vger.kernel.org
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Jens Axboe <axboe@kernel.dk>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jason Yan <yanaijie@huawei.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ec54fc43b5a43c6b456b04843f13a2dded1c4f2
Author: Jérôme Glisse <jglisse@redhat.com>
Date:   Wed Apr 10 16:27:51 2019 -0400

    block: do not leak memory in bio_copy_user_iov()
    
    commit a3761c3c91209b58b6f33bf69dd8bb8ec0c9d925 upstream.
    
    When bio_add_pc_page() fails in bio_copy_user_iov() we should free
    the page we just allocated otherwise we are leaking it.
    
    Cc: linux-block@vger.kernel.org
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fc37a0abf1ff4fdf35d1a90fb80ec98c588184a
Author: Anand Jain <anand.jain@oracle.com>
Date:   Tue Apr 2 18:07:40 2019 +0800

    btrfs: prop: fix vanished compression property after failed set
    
    commit 272e5326c7837697882ce3162029ba893059b616 upstream.
    
    The compression property resets to NULL, instead of the old value if we
    fail to set the new compression parameter.
    
      $ btrfs prop get /btrfs compression
        compression=lzo
      $ btrfs prop set /btrfs compression zli
        ERROR: failed to set compression for /btrfs: Invalid argument
      $ btrfs prop get /btrfs compression
    
    This is because the compression property ->validate() is successful for
    'zli' as the strncmp() used the length passed from the userspace.
    
    Fix it by using the expected string length in strncmp().
    
    Fixes: 63541927c8d1 ("Btrfs: add support for inode properties")
    Fixes: 5c1aab1dd544 ("btrfs: Add zstd support")
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    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 979409e6f4590e881b0eee29aab8f22f8047c91c
Author: Anand Jain <anand.jain@oracle.com>
Date:   Tue Apr 2 18:07:38 2019 +0800

    btrfs: prop: fix zstd compression parameter validation
    
    commit 50398fde997f6be8faebdb5f38e9c9c467370f51 upstream.
    
    We let pass zstd compression parameter even if it is not fully valid.
    For example:
    
      $ btrfs prop set /btrfs compression zst
      $ btrfs prop get /btrfs compression
         compression=zst
    
    zlib and lzo are fine.
    
    Fix it by checking the correct prefix length.
    
    Fixes: 5c1aab1dd544 ("btrfs: Add zstd support")
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    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 3eb52487d917d81e7f7ff3e46fafad221e1d3637
Author: Filipe Manana <fdmanana@suse.com>
Date:   Tue Mar 26 10:49:56 2019 +0000

    Btrfs: do not allow trimming when a fs is mounted with the nologreplay option
    
    commit f35f06c35560a86e841631f0243b83a984dc11a9 upstream.
    
    Whan a filesystem is mounted with the nologreplay mount option, which
    requires it to be mounted in RO mode as well, we can not allow discard on
    free space inside block groups, because log trees refer to extents that
    are not pinned in a block group's free space cache (pinning the extents is
    precisely the first phase of replaying a log tree).
    
    So do not allow the fitrim ioctl to do anything when the filesystem is
    mounted with the nologreplay option, because later it can be mounted RW
    without that option, which causes log replay to happen and result in
    either a failure to replay the log trees (leading to a mount failure), a
    crash or some silent corruption.
    
    Reported-by: Darrick J. Wong <darrick.wong@oracle.com>
    Fixes: 96da09192cda ("btrfs: Introduce new mount option to disable tree log replay")
    CC: stable@vger.kernel.org # 4.9+
    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 541e756826fa39fd06f30ee4f1445845ff44ad2d
Author: S.j. Wang <shengjiu.wang@nxp.com>
Date:   Wed Feb 27 06:31:12 2019 +0000

    ASoC: fsl_esai: fix channel swap issue when stream starts
    
    commit 0ff4e8c61b794a4bf6c854ab071a1abaaa80f358 upstream.
    
    There is very low possibility ( < 0.1% ) that channel swap happened
    in beginning when multi output/input pin is enabled. The issue is
    that hardware can't send data to correct pin in the beginning with
    the normal enable flow.
    
    This is hardware issue, but there is no errata, the workaround flow
    is that: Each time playback/recording, firstly clear the xSMA/xSMB,
    then enable TE/RE, then enable xSMB and xSMA (xSMB must be enabled
    before xSMA). Which is to use the xSMA as the trigger start register,
    previously the xCR_TE or xCR_RE is the bit for starting.
    
    Fixes commit 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed031128c2f8267f13d592961acecfae5136968b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Apr 5 18:38:53 2019 -0700

    include/linux/bitrev.h: fix constant bitrev
    
    commit 6147e136ff5071609b54f18982dea87706288e21 upstream.
    
    clang points out with hundreds of warnings that the bitrev macros have a
    problem with constant input:
    
      drivers/hwmon/sht15.c:187:11: error: variable '__x' is uninitialized when used within its own initialization
            [-Werror,-Wuninitialized]
              u8 crc = bitrev8(data->val_status & 0x0F);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      include/linux/bitrev.h:102:21: note: expanded from macro 'bitrev8'
              __constant_bitrev8(__x) :                       \
              ~~~~~~~~~~~~~~~~~~~^~~~
      include/linux/bitrev.h:67:11: note: expanded from macro '__constant_bitrev8'
              u8 __x = x;                     \
                 ~~~   ^
    
    Both the bitrev and the __constant_bitrev macros use an internal
    variable named __x, which goes horribly wrong when passing one to the
    other.
    
    The obvious fix is to rename one of the variables, so this adds an extra
    '_'.
    
    It seems we got away with this because
    
     - there are only a few drivers using bitrev macros
    
     - usually there are no constant arguments to those
    
     - when they are constant, they tend to be either 0 or (unsigned)-1
       (drivers/isdn/i4l/isdnhdlc.o, drivers/iio/amplifiers/ad8366.c) and
       give the correct result by pure chance.
    
    In fact, the only driver that I could find that gets different results
    with this is drivers/net/wan/slic_ds26522.c, which in turn is a driver
    for fairly rare hardware (adding the maintainer to Cc for testing).
    
    Link: http://lkml.kernel.org/r/20190322140503.123580-1-arnd@arndb.de
    Fixes: 556d2f055bf6 ("ARM: 8187/1: add CONFIG_HAVE_ARCH_BITREVERSE to support rbit instruction")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Zhao Qiang <qiang.zhao@nxp.com>
    Cc: Yalin Wang <yalin.wang@sonymobile.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7a46b61d3af4ea98bf35d8791485bf35596b567
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Apr 5 13:17:13 2019 +1000

    drm/udl: add a release method and delay modeset teardown
    
    commit 9b39b013037fbfa8d4b999345d9e904d8a336fc2 upstream.
    
    If we unplug a udl device, the usb callback with deinit the
    mode_config struct, however userspace will still have an open
    file descriptor and a framebuffer on that device. When userspace
    closes the fd, we'll oops because it'll try and look stuff up
    in the object idr which we've destroyed.
    
    This punts destroying the mode objects until release time instead.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-2-airlied@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 753ff72679f0230cf06ee56c920d1dc622acfd1a
Author: Andrei Vagin <avagin@gmail.com>
Date:   Sun Apr 7 21:15:42 2019 -0700

    alarmtimer: Return correct remaining time
    
    commit 07d7e12091f4ab869cc6a4bb276399057e73b0b3 upstream.
    
    To calculate a remaining time, it's required to subtract the current time
    from the expiration time. In alarm_timer_remaining() the arguments of
    ktime_sub are swapped.
    
    Fixes: d653d8457c76 ("alarmtimer: Implement remaining callback")
    Signed-off-by: Andrei Vagin <avagin@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190408041542.26338-1-avagin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 224f5ab9bc035d25a01cc7a4d52722837163a293
Author: Sven Schnelle <svens@stackframe.org>
Date:   Thu Apr 4 18:16:03 2019 +0200

    parisc: regs_return_value() should return gpr28
    
    commit 45efd871bf0a47648f119d1b41467f70484de5bc upstream.
    
    While working on kretprobes for PA-RISC I was wondering while the
    kprobes sanity test always fails on kretprobes. This is caused by
    returning gpr20 instead of gpr28.
    
    Signed-off-by: Sven Schnelle <svens@stackframe.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@vger.kernel.org # 4.14+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1f5209663ec56deec5587013a4795cf42178360
Author: Helge Deller <deller@gmx.de>
Date:   Tue Apr 2 12:13:27 2019 +0200

    parisc: Detect QEMU earlier in boot process
    
    commit d006e95b5561f708d0385e9677ffe2c46f2ae345 upstream.
    
    While adding LASI support to QEMU, I noticed that the QEMU detection in
    the kernel happens much too late. For example, when a LASI chip is found
    by the kernel, it registers the LASI LED driver as well.  But when we
    run on QEMU it makes sense to avoid spending unnecessary CPU cycles, so
    we need to access the running_on_QEMU flag earlier than before.
    
    This patch now makes the QEMU detection the fist task of the Linux
    kernel by moving it to where the kernel enters the C-coding.
    
    Fixes: 310d82784fb4 ("parisc: qemu idle sleep support")
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@vger.kernel.org # v4.14+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1d361d3b1170efe557a418f85adc7a1a24cf401
Author: Peter Geis <pgwipeout@gmail.com>
Date:   Wed Mar 13 19:02:30 2019 +0000

    arm64: dts: rockchip: fix rk3328 sdmmc0 write errors
    
    commit 09f91381fa5de1d44bc323d8bf345f5d57b3d9b5 upstream.
    
    Various rk3328 based boards experience occasional sdmmc0 write errors.
    This is due to the rk3328.dtsi tx drive levels being set to 4ma, vs
    8ma per the rk3328 datasheet default settings.
    
    Fix this by setting the tx signal pins to 8ma.
    Inspiration from tonymac32's patch,
    https://github.com/ayufan-rock64/linux-kernel/commit/dc1212b347e0da17c5460bcc0a56b07d02bac3f8
    
    Fixes issues on the rk3328-roc-cc and the rk3328-rock64 (as per the
    above commit message).
    
    Tested on the rk3328-roc-cc board.
    
    Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Peter Geis <pgwipeout@gmail.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 789185d40eff67b9d89367d1442b62c8f31ce872
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date:   Thu Mar 28 19:40:36 2019 +0000

    hv_netvsc: Fix unwanted wakeup after tx_disable
    
    [ Upstream commit 1b704c4a1ba95574832e730f23817b651db2aa59 ]
    
    After queue stopped, the wakeup mechanism may wake it up again
    when ring buffer usage is lower than a threshold. This may cause
    send path panic on NULL pointer when we stopped all tx queues in
    netvsc_detach and start removing the netvsc device.
    
    This patch fix it by adding a tx_disable flag to prevent unwanted
    queue wakeup.
    
    Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
    Reported-by: Mohammed Gamal <mgamal@redhat.com>
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc280a1edc23afabc04c97c04841d996e0788c6d
Author: Sheena Mira-ato <sheena.mira-ato@alliedtelesis.co.nz>
Date:   Mon Apr 1 13:04:42 2019 +1300

    ip6_tunnel: Match to ARPHRD_TUNNEL6 for dev type
    
    [ Upstream commit b2e54b09a3d29c4db883b920274ca8dca4d9f04d ]
    
    The device type for ip6 tunnels is set to
    ARPHRD_TUNNEL6. However, the ip4ip6_err function
    is expecting the device type of the tunnel to be
    ARPHRD_TUNNEL.  Since the device types do not
    match, the function exits and the ICMP error
    packet is not sent to the originating host. Note
    that the device type for IPv4 tunnels is set to
    ARPHRD_TUNNEL.
    
    Fix is to expect a tunnel device type of
    ARPHRD_TUNNEL6 instead.  Now the tunnel device
    type matches and the ICMP error packet is sent
    to the originating host.
    
    Signed-off-by: Sheena Mira-ato <sheena.mira-ato@alliedtelesis.co.nz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5589e51fc8afb345561b6b880b349e6bc3bbf410
Author: Zubin Mithra <zsm@chromium.org>
Date:   Thu Apr 4 14:33:55 2019 -0700

    ALSA: seq: Fix OOB-reads from strlcpy
    
    commit 212ac181c158c09038c474ba68068be49caecebb upstream.
    
    When ioctl calls are made with non-null-terminated userspace strings,
    strlcpy causes an OOB-read from within strlen. Fix by changing to use
    strscpy instead.
    
    Signed-off-by: Zubin Mithra <zsm@chromium.org>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eea06f38eb464ab6ebdc04ca5980120dd24ee48d
Author: Li RongQing <lirongqing@baidu.com>
Date:   Fri Mar 29 09:18:02 2019 +0800

    net: ethtool: not call vzalloc for zero sized memory request
    
    [ Upstream commit 3d8830266ffc28c16032b859e38a0252e014b631 ]
    
    NULL or ZERO_SIZE_PTR will be returned for zero sized memory
    request, and derefencing them will lead to a segfault
    
    so it is unnecessory to call vzalloc for zero sized memory
    request and not call functions which maybe derefence the
    NULL allocated memory
    
    this also fixes a possible memory leak if phy_ethtool_get_stats
    returns error, memory should be freed before exit
    
    Signed-off-by: Li RongQing <lirongqing@baidu.com>
    Reviewed-by: Wang Li <wangli39@baidu.com>
    Reviewed-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit adbb8bdd392db14dc80ad1ac29f8f1d37ab57a62
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 27 08:21:30 2019 -0700

    netns: provide pure entropy for net_hash_mix()
    
    [ Upstream commit 355b98553789b646ed97ad801a619ff898471b92 ]
    
    net_hash_mix() currently uses kernel address of a struct net,
    and is used in many places that could be used to reveal this
    address to a patient attacker, thus defeating KASLR, for
    the typical case (initial net namespace, &init_net is
    not dynamically allocated)
    
    I believe the original implementation tried to avoid spending
    too many cycles in this function, but security comes first.
    
    Also provide entropy regardless of CONFIG_NET_NS.
    
    Fixes: 0b4419162aa6 ("netns: introduce the net_hash_mix "salt" for hashes")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Amit Klein <aksecurity@gmail.com>
    Reported-by: Benny Pinkas <benny@pinkas.net>
    Cc: Pavel Emelyanov <xemul@openvz.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0349ad0656a3ea2e6ecb55da946a7000f6abdba5
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Thu Apr 4 12:31:35 2019 +0200

    net/sched: act_sample: fix divide by zero in the traffic path
    
    [ Upstream commit fae2708174ae95d98d19f194e03d6e8f688ae195 ]
    
    the control path of 'sample' action does not validate the value of 'rate'
    provided by the user, but then it uses it as divisor in the traffic path.
    Validate it in tcf_sample_init(), and return -EINVAL with a proper extack
    message in case that value is zero, to fix a splat with the script below:
    
     # tc f a dev test0 egress matchall action sample rate 0 group 1 index 2
     # tc -s a s action sample
     total acts 1
    
             action order 0: sample rate 1/0 group 1 pipe
              index 2 ref 1 bind 1 installed 19 sec used 19 sec
             Action statistics:
             Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
             backlog 0b 0p requeues 0
     # ping 192.0.2.1 -I test0 -c1 -q
    
     divide error: 0000 [#1] SMP PTI
     CPU: 1 PID: 6192 Comm: ping Not tainted 5.1.0-rc2.diag2+ #591
     Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
     RIP: 0010:tcf_sample_act+0x9e/0x1e0 [act_sample]
     Code: 6a f1 85 c0 74 0d 80 3d 83 1a 00 00 00 0f 84 9c 00 00 00 4d 85 e4 0f 84 85 00 00 00 e8 9b d7 9c f1 44 8b 8b e0 00 00 00 31 d2 <41> f7 f1 85 d2 75 70 f6 85 83 00 00 00 10 48 8b 45 10 8b 88 08 01
     RSP: 0018:ffffae320190ba30 EFLAGS: 00010246
     RAX: 00000000b0677d21 RBX: ffff8af1ed9ec000 RCX: 0000000059a9fe49
     RDX: 0000000000000000 RSI: 000000000c7e33b7 RDI: ffff8af23daa0af0
     RBP: ffff8af1ee11b200 R08: 0000000074fcaf7e R09: 0000000000000000
     R10: 0000000000000050 R11: ffffffffb3088680 R12: ffff8af232307f80
     R13: 0000000000000003 R14: ffff8af1ed9ec000 R15: 0000000000000000
     FS:  00007fe9c6d2f740(0000) GS:ffff8af23da80000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00007fff6772f000 CR3: 00000000746a2004 CR4: 00000000001606e0
     Call Trace:
      tcf_action_exec+0x7c/0x1c0
      tcf_classify+0x57/0x160
      __dev_queue_xmit+0x3dc/0xd10
      ip_finish_output2+0x257/0x6d0
      ip_output+0x75/0x280
      ip_send_skb+0x15/0x40
      raw_sendmsg+0xae3/0x1410
      sock_sendmsg+0x36/0x40
      __sys_sendto+0x10e/0x140
      __x64_sys_sendto+0x24/0x30
      do_syscall_64+0x60/0x210
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [...]
      Kernel panic - not syncing: Fatal exception in interrupt
    
    Add a TDC selftest to document that 'rate' is now being validated.
    
    Reported-by: Matteo Croce <mcroce@redhat.com>
    Fixes: 5c5670fae430 ("net/sched: Introduce sample tc action")
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Acked-by: Yotam Gigi <yotam.gi@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5df47bb622e1b7cb3e99c7df15a4e1676a6af2c1
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Mon Apr 8 17:39:55 2019 -0400

    bnxt_en: Reset device on RX buffer errors.
    
    [ Upstream commit 8e44e96c6c8e8fb80b84a2ca11798a8554f710f2 ]
    
    If the RX completion indicates RX buffers errors, the RX ring will be
    disabled by firmware and no packets will be received on that ring from
    that point on.  Recover by resetting the device.
    
    Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46281ee85b651b0df686001651b965d17b8e2c67
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Mon Apr 8 17:39:54 2019 -0400

    bnxt_en: Improve RX consumer index validity check.
    
    [ Upstream commit a1b0e4e684e9c300b9e759b46cb7a0147e61ddff ]
    
    There is logic to check that the RX/TPA consumer index is the expected
    index to work around a hardware problem.  However, the potentially bad
    consumer index is first used to index into an array to reference an entry.
    This can potentially crash if the bad consumer index is beyond legal
    range.  Improve the logic to use the consumer index for dereferencing
    after the validity check and log an error message.
    
    Fixes: fa7e28127a5a ("bnxt_en: Add workaround to detect bad opaque in rx completion (part 2)")
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e26c79d2af6e94077beefdfcfbeb3037ac8a9dea
Author: Jakub Kicinski <jakub.kicinski@netronome.com>
Date:   Wed Mar 27 11:38:38 2019 -0700

    nfp: validate the return code from dev_queue_xmit()
    
    [ Upstream commit c8ba5b91a04e3e2643e48501c114108802f21cda ]
    
    dev_queue_xmit() may return error codes as well as netdev_tx_t,
    and it always consumes the skb.  Make sure we always return a
    correct netdev_tx_t value.
    
    Fixes: eadfa4c3be99 ("nfp: add stats and xmit helpers for representors")
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Reviewed-by: John Hurley <john.hurley@netronome.com>
    Reviewed-by: Simon Horman <simon.horman@netronome.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5ba76a58b09c09ed7efc97de18f93d28c04ee4e
Author: Yuval Avnery <yuvalav@mellanox.com>
Date:   Mon Mar 11 06:18:24 2019 +0200

    net/mlx5e: Add a lock on tir list
    
    [ Upstream commit 80a2a9026b24c6bd34b8d58256973e22270bedec ]
    
    Refresh tirs is looping over a global list of tirs while netdevs are
    adding and removing tirs from that list. That is why a lock is
    required.
    
    Fixes: 724b2aa15126 ("net/mlx5e: TIRs management refactoring")
    Signed-off-by: Yuval Avnery <yuvalav@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7143c8997ae84bbed8d8698fd317d537b5c3e23d
Author: Gavi Teitz <gavi@mellanox.com>
Date:   Mon Mar 11 11:56:34 2019 +0200

    net/mlx5e: Fix error handling when refreshing TIRs
    
    [ Upstream commit bc87a0036826a37b43489b029af8143bd07c6cca ]
    
    Previously, a false positive would be caught if the TIRs list is
    empty, since the err value was initialized to -ENOMEM, and was only
    updated if a TIR is refreshed. This is resolved by initializing the
    err value to zero.
    
    Fixes: b676f653896a ("net/mlx5e: Refactor refresh TIRs")
    Signed-off-by: Gavi Teitz <gavi@mellanox.com>
    Reviewed-by: Roi Dayan <roid@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16b7142372d82cb93099e050559967517b84ac6a
Author: Stephen Suryaputra <ssuryaextr@gmail.com>
Date:   Mon Apr 1 09:17:32 2019 -0400

    vrf: check accept_source_route on the original netdevice
    
    [ Upstream commit 8c83f2df9c6578ea4c5b940d8238ad8a41b87e9e ]
    
    Configuration check to accept source route IP options should be made on
    the incoming netdevice when the skb->dev is an l3mdev master. The route
    lookup for the source route next hop also needs the incoming netdev.
    
    v2->v3:
    - Simplify by passing the original netdevice down the stack (per David
      Ahern).
    
    Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
    Reviewed-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ff8616e56d41bffef7408c896d58097e0669fc8
Author: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
Date:   Thu Apr 4 12:24:02 2019 +0000

    tcp: Ensure DCTCP reacts to losses
    
    [ Upstream commit aecfde23108b8e637d9f5c5e523b24fb97035dc3 ]
    
    RFC8257 §3.5 explicitly states that "A DCTCP sender MUST react to
    loss episodes in the same way as conventional TCP".
    
    Currently, Linux DCTCP performs no cwnd reduction when losses
    are encountered. Optionally, the dctcp_clamp_alpha_on_loss resets
    alpha to its maximal value if a RTO happens. This behavior
    is sub-optimal for at least two reasons: i) it ignores losses
    triggering fast retransmissions; and ii) it causes unnecessary large
    cwnd reduction in the future if the loss was isolated as it resets
    the historical term of DCTCP's alpha EWMA to its maximal value (i.e.,
    denoting a total congestion). The second reason has an especially
    noticeable effect when using DCTCP in high BDP environments, where
    alpha normally stays at low values.
    
    This patch replace the clamping of alpha by setting ssthresh to
    half of cwnd for both fast retransmissions and RTOs, at most once
    per RTT. Consequently, the dctcp_clamp_alpha_on_loss module parameter
    has been removed.
    
    The table below shows experimental results where we measured the
    drop probability of a PIE AQM (not applying ECN marks) at a
    bottleneck in the presence of a single TCP flow with either the
    alpha-clamping option enabled or the cwnd halving proposed by this
    patch. Results using reno or cubic are given for comparison.
    
                              |  Link   |   RTT    |    Drop
                     TCP CC   |  speed  | base+AQM | probability
            ==================|=========|==========|============
                        CUBIC |  40Mbps |  7+20ms  |    0.21%
                         RENO |         |          |    0.19%
            DCTCP-CLAMP-ALPHA |         |          |   25.80%
             DCTCP-HALVE-CWND |         |          |    0.22%
            ------------------|---------|----------|------------
                        CUBIC | 100Mbps |  7+20ms  |    0.03%
                         RENO |         |          |    0.02%
            DCTCP-CLAMP-ALPHA |         |          |   23.30%
             DCTCP-HALVE-CWND |         |          |    0.04%
            ------------------|---------|----------|------------
                        CUBIC | 800Mbps |   1+1ms  |    0.04%
                         RENO |         |          |    0.05%
            DCTCP-CLAMP-ALPHA |         |          |   18.70%
             DCTCP-HALVE-CWND |         |          |    0.06%
    
    We see that, without halving its cwnd for all source of losses,
    DCTCP drives the AQM to large drop probabilities in order to keep
    the queue length under control (i.e., it repeatedly faces RTOs).
    Instead, if DCTCP reacts to all source of losses, it can then be
    controlled by the AQM using similar drop levels than cubic or reno.
    
    Signed-off-by: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
    Signed-off-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
    Cc: Bob Briscoe <research@bobbriscoe.net>
    Cc: Lawrence Brakmo <brakmo@fb.com>
    Cc: Florian Westphal <fw@strlen.de>
    Cc: Daniel Borkmann <borkmann@iogearbox.net>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Andrew Shewmaker <agshew@gmail.com>
    Cc: Glenn Judd <glenn.judd@morganstanley.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7bc830b76341b612a664b6649440937f7595190
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sun Mar 31 16:58:15 2019 +0800

    sctp: initialize _pad of sockaddr_in before copying to user memory
    
    [ Upstream commit 09279e615c81ce55e04835970601ae286e3facbe ]
    
    Syzbot report a kernel-infoleak:
    
      BUG: KMSAN: kernel-infoleak in _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
      Call Trace:
        _copy_to_user+0x16b/0x1f0 lib/usercopy.c:32
        copy_to_user include/linux/uaccess.h:174 [inline]
        sctp_getsockopt_peer_addrs net/sctp/socket.c:5911 [inline]
        sctp_getsockopt+0x1668e/0x17f70 net/sctp/socket.c:7562
        ...
      Uninit was stored to memory at:
        sctp_transport_init net/sctp/transport.c:61 [inline]
        sctp_transport_new+0x16d/0x9a0 net/sctp/transport.c:115
        sctp_assoc_add_peer+0x532/0x1f70 net/sctp/associola.c:637
        sctp_process_param net/sctp/sm_make_chunk.c:2548 [inline]
        sctp_process_init+0x1a1b/0x3ed0 net/sctp/sm_make_chunk.c:2361
        ...
      Bytes 8-15 of 16 are uninitialized
    
    It was caused by that th _pad field (the 8-15 bytes) of a v4 addr (saved in
    struct sockaddr_in) wasn't initialized, but directly copied to user memory
    in sctp_getsockopt_peer_addrs().
    
    So fix it by calling memset(addr->v4.sin_zero, 0, 8) to initialize _pad of
    sockaddr_in before copying it to user memory in sctp_v4_addr_to_user(), as
    sctp_v6_addr_to_user() does.
    
    Reported-by: syzbot+86b5c7c236a22616a72f@syzkaller.appspotmail.com
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Tested-by: Alexander Potapenko <glider@google.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be7e16e566f4216b703cb838679024a117a8e059
Author: Bjørn Mork <bjorn@mork.no>
Date:   Wed Mar 27 15:26:01 2019 +0100

    qmi_wwan: add Olicard 600
    
    [ Upstream commit 6289d0facd9ebce4cc83e5da39e15643ee998dc5 ]
    
    This is a Qualcomm based device with a QMI function on interface 4.
    It is mode switched from 2020:2030 using a standard eject message.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2020 ProdID=2031 Rev= 2.32
    S:  Manufacturer=Mobile Connect
    S:  Product=Mobile Connect
    S:  SerialNumber=0123456789ABCDEF
    C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
    E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
    
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94ef6b9842bd6b16b0e38c8aec15da2171f8104f
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Thu Mar 28 07:36:00 2019 +0100

    openvswitch: fix flow actions reallocation
    
    [ Upstream commit f28cd2af22a0c134e4aa1c64a70f70d815d473fb ]
    
    The flow action buffer can be resized if it's not big enough to contain
    all the requested flow actions. However, this resize doesn't take into
    account the new requested size, the buffer is only increased by a factor
    of 2x. This might be not enough to contain the new data, causing a
    buffer overflow, for example:
    
    [   42.044472] =============================================================================
    [   42.045608] BUG kmalloc-96 (Not tainted): Redzone overwritten
    [   42.046415] -----------------------------------------------------------------------------
    
    [   42.047715] Disabling lock debugging due to kernel taint
    [   42.047716] INFO: 0x8bf2c4a5-0x720c0928. First byte 0x0 instead of 0xcc
    [   42.048677] INFO: Slab 0xbc6d2040 objects=29 used=18 fp=0xdc07dec4 flags=0x2808101
    [   42.049743] INFO: Object 0xd53a3464 @offset=2528 fp=0xccdcdebb
    
    [   42.050747] Redzone 76f1b237: cc cc cc cc cc cc cc cc                          ........
    [   42.051839] Object d53a3464: 6b 6b 6b 6b 6b 6b 6b 6b 0c 00 00 00 6c 00 00 00  kkkkkkkk....l...
    [   42.053015] Object f49a30cc: 6c 00 0c 00 00 00 00 00 00 00 00 03 78 a3 15 f6  l...........x...
    [   42.054203] Object acfe4220: 20 00 02 00 ff ff ff ff 00 00 00 00 00 00 00 00   ...............
    [   42.055370] Object 21024e91: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    [   42.056541] Object 070e04c3: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    [   42.057797] Object 948a777a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    [   42.059061] Redzone 8bf2c4a5: 00 00 00 00                                      ....
    [   42.060189] Padding a681b46e: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
    
    Fix by making sure the new buffer is properly resized to contain all the
    requested data.
    
    BugLink: https://bugs.launchpad.net/bugs/1813244
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Acked-by: Pravin B Shelar <pshelar@ovn.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a54dc7b6972eee8dfc73a36d40b4bdb138deed96
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Thu Mar 28 10:35:06 2019 +0100

    net/sched: fix ->get helper of the matchall cls
    
    [ Upstream commit 0db6f8befc32c68bb13d7ffbb2e563c79e913e13 ]
    
    It returned always NULL, thus it was never possible to get the filter.
    
    Example:
    $ ip link add foo type dummy
    $ ip link add bar type dummy
    $ tc qdisc add dev foo clsact
    $ tc filter add dev foo protocol all pref 1 ingress handle 1234 \
            matchall action mirred ingress mirror dev bar
    
    Before the patch:
    $ tc filter get dev foo protocol all pref 1 ingress handle 1234 matchall
    Error: Specified filter handle not found.
    We have an error talking to the kernel
    
    After:
    $ tc filter get dev foo protocol all pref 1 ingress handle 1234 matchall
    filter ingress protocol all pref 1 matchall chain 0 handle 0x4d2
      not_in_hw
            action order 1: mirred (Ingress Mirror to device bar) pipe
            index 1 ref 1 bind 1
    
    CC: Yotam Gigi <yotamg@mellanox.com>
    CC: Jiri Pirko <jiri@mellanox.com>
    Fixes: fd62d9f5c575 ("net/sched: matchall: Fix configuration race")
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8a88799e632045399af886a1b1a5205e5d49897
Author: Mao Wenan <maowenan@huawei.com>
Date:   Thu Mar 28 17:10:56 2019 +0800

    net: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock().
    
    [ Upstream commit cb66ddd156203daefb8d71158036b27b0e2caf63 ]
    
    When it is to cleanup net namespace, rds_tcp_exit_net() will call
    rds_tcp_kill_sock(), if t_sock is NULL, it will not call
    rds_conn_destroy(), rds_conn_path_destroy() and rds_tcp_conn_free() to free
    connection, and the worker cp_conn_w is not stopped, afterwards the net is freed in
    net_drop_ns(); While cp_conn_w rds_connect_worker() will call rds_tcp_conn_path_connect()
    and reference 'net' which has already been freed.
    
    In rds_tcp_conn_path_connect(), rds_tcp_set_callbacks() will set t_sock = sock before
    sock->ops->connect, but if connect() is failed, it will call
    rds_tcp_restore_callbacks() and set t_sock = NULL, if connect is always
    failed, rds_connect_worker() will try to reconnect all the time, so
    rds_tcp_kill_sock() will never to cancel worker cp_conn_w and free the
    connections.
    
    Therefore, the condition !tc->t_sock is not needed if it is going to do
    cleanup_net->rds_tcp_exit_net->rds_tcp_kill_sock, because tc->t_sock is always
    NULL, and there is on other path to cancel cp_conn_w and free
    connection. So this patch is to fix this.
    
    rds_tcp_kill_sock():
    ...
    if (net != c_net || !tc->t_sock)
    ...
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    
    ==================================================================
    BUG: KASAN: use-after-free in inet_create+0xbcc/0xd28
    net/ipv4/af_inet.c:340
    Read of size 4 at addr ffff8003496a4684 by task kworker/u8:4/3721
    
    CPU: 3 PID: 3721 Comm: kworker/u8:4 Not tainted 5.1.0 #11
    Hardware name: linux,dummy-virt (DT)
    Workqueue: krdsd rds_connect_worker
    Call trace:
     dump_backtrace+0x0/0x3c0 arch/arm64/kernel/time.c:53
     show_stack+0x28/0x38 arch/arm64/kernel/traps.c:152
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x120/0x188 lib/dump_stack.c:113
     print_address_description+0x68/0x278 mm/kasan/report.c:253
     kasan_report_error mm/kasan/report.c:351 [inline]
     kasan_report+0x21c/0x348 mm/kasan/report.c:409
     __asan_report_load4_noabort+0x30/0x40 mm/kasan/report.c:429
     inet_create+0xbcc/0xd28 net/ipv4/af_inet.c:340
     __sock_create+0x4f8/0x770 net/socket.c:1276
     sock_create_kern+0x50/0x68 net/socket.c:1322
     rds_tcp_conn_path_connect+0x2b4/0x690 net/rds/tcp_connect.c:114
     rds_connect_worker+0x108/0x1d0 net/rds/threads.c:175
     process_one_work+0x6e8/0x1700 kernel/workqueue.c:2153
     worker_thread+0x3b0/0xdd0 kernel/workqueue.c:2296
     kthread+0x2f0/0x378 kernel/kthread.c:255
     ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:1117
    
    Allocated by task 687:
     save_stack mm/kasan/kasan.c:448 [inline]
     set_track mm/kasan/kasan.c:460 [inline]
     kasan_kmalloc+0xd4/0x180 mm/kasan/kasan.c:553
     kasan_slab_alloc+0x14/0x20 mm/kasan/kasan.c:490
     slab_post_alloc_hook mm/slab.h:444 [inline]
     slab_alloc_node mm/slub.c:2705 [inline]
     slab_alloc mm/slub.c:2713 [inline]
     kmem_cache_alloc+0x14c/0x388 mm/slub.c:2718
     kmem_cache_zalloc include/linux/slab.h:697 [inline]
     net_alloc net/core/net_namespace.c:384 [inline]
     copy_net_ns+0xc4/0x2d0 net/core/net_namespace.c:424
     create_new_namespaces+0x300/0x658 kernel/nsproxy.c:107
     unshare_nsproxy_namespaces+0xa0/0x198 kernel/nsproxy.c:206
     ksys_unshare+0x340/0x628 kernel/fork.c:2577
     __do_sys_unshare kernel/fork.c:2645 [inline]
     __se_sys_unshare kernel/fork.c:2643 [inline]
     __arm64_sys_unshare+0x38/0x58 kernel/fork.c:2643
     __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
     invoke_syscall arch/arm64/kernel/syscall.c:47 [inline]
     el0_svc_common+0x168/0x390 arch/arm64/kernel/syscall.c:83
     el0_svc_handler+0x60/0xd0 arch/arm64/kernel/syscall.c:129
     el0_svc+0x8/0xc arch/arm64/kernel/entry.S:960
    
    Freed by task 264:
     save_stack mm/kasan/kasan.c:448 [inline]
     set_track mm/kasan/kasan.c:460 [inline]
     __kasan_slab_free+0x114/0x220 mm/kasan/kasan.c:521
     kasan_slab_free+0x10/0x18 mm/kasan/kasan.c:528
     slab_free_hook mm/slub.c:1370 [inline]
     slab_free_freelist_hook mm/slub.c:1397 [inline]
     slab_free mm/slub.c:2952 [inline]
     kmem_cache_free+0xb8/0x3a8 mm/slub.c:2968
     net_free net/core/net_namespace.c:400 [inline]
     net_drop_ns.part.6+0x78/0x90 net/core/net_namespace.c:407
     net_drop_ns net/core/net_namespace.c:406 [inline]
     cleanup_net+0x53c/0x6d8 net/core/net_namespace.c:569
     process_one_work+0x6e8/0x1700 kernel/workqueue.c:2153
     worker_thread+0x3b0/0xdd0 kernel/workqueue.c:2296
     kthread+0x2f0/0x378 kernel/kthread.c:255
     ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:1117
    
    The buggy address belongs to the object at ffff8003496a3f80
     which belongs to the cache net_namespace of size 7872
    The buggy address is located 1796 bytes inside of
     7872-byte region [ffff8003496a3f80, ffff8003496a5e40)
    The buggy address belongs to the page:
    page:ffff7e000d25a800 count:1 mapcount:0 mapping:ffff80036ce4b000
    index:0x0 compound_mapcount: 0
    flags: 0xffffe0000008100(slab|head)
    raw: 0ffffe0000008100 dead000000000100 dead000000000200 ffff80036ce4b000
    raw: 0000000000000000 0000000080040004 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff8003496a4580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff8003496a4600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff8003496a4680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
     ffff8003496a4700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff8003496a4780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    Fixes: 467fa15356ac("RDS-TCP: Support multiple RDS-TCP listen endpoints, one per netns.")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Mao Wenan <maowenan@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96d8f6246ca2c7cfbb67ca8bb83f0bb81731b520
Author: Artemy Kovalyov <artemyko@mellanox.com>
Date:   Tue Mar 19 11:24:38 2019 +0200

    net/mlx5: Decrease default mr cache size
    
    [ Upstream commit e8b26b2135dedc0284490bfeac06dfc4418d0105 ]
    
    Delete initialization of high order entries in mr cache to decrease initial
    memory footprint. When required, the administrator can populate the
    entries with memory keys via the /sys interface.
    
    This approach is very helpful to significantly reduce the per HW function
    memory footprint in virtualization environments such as SRIOV.
    
    Fixes: 9603b61de1ee ("mlx5: Move pci device handling from mlx5_ib to mlx5_core")
    Signed-off-by: Artemy Kovalyov <artemyko@mellanox.com>
    Signed-off-by: Moni Shoua <monis@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Reported-by:  Shalom Toledo <shalomt@mellanox.com>
    Acked-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23bfd229819139b6a9635e6efb9d2fa0309b3de2
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Tue Apr 2 08:16:03 2019 +0200

    net-gro: Fix GRO flush when receiving a GSO packet.
    
    [ Upstream commit 0ab03f353d3613ea49d1f924faf98559003670a8 ]
    
    Currently we may merge incorrectly a received GSO packet
    or a packet with frag_list into a packet sitting in the
    gro_hash list. skb_segment() may crash case because
    the assumptions on the skb layout are not met.
    The correct behaviour would be to flush the packet in the
    gro_hash list and send the received GSO packet directly
    afterwards. Commit d61d072e87c8e ("net-gro: avoid reorders")
    sets NAPI_GRO_CB(skb)->flush in this case, but this is not
    checked before merging. This patch makes sure to check this
    flag and to not merge in that case.
    
    Fixes: d61d072e87c8e ("net-gro: avoid reorders")
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 393c8b4c6790c21d7f639c47436b13e975eee7b1
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Mar 29 12:19:46 2019 +0100

    kcm: switch order of device registration to fix a crash
    
    [ Upstream commit 3c446e6f96997f2a95bf0037ef463802162d2323 ]
    
    When kcm is loaded while many processes try to create a KCM socket, a
    crash occurs:
     BUG: unable to handle kernel NULL pointer dereference at 000000000000000e
     IP: mutex_lock+0x27/0x40 kernel/locking/mutex.c:240
     PGD 8000000016ef2067 P4D 8000000016ef2067 PUD 3d6e9067 PMD 0
     Oops: 0002 [#1] SMP KASAN PTI
     CPU: 0 PID: 7005 Comm: syz-executor.5 Not tainted 4.12.14-396-default #1 SLE15-SP1 (unreleased)
     RIP: 0010:mutex_lock+0x27/0x40 kernel/locking/mutex.c:240
     RSP: 0018:ffff88000d487a00 EFLAGS: 00010246
     RAX: 0000000000000000 RBX: 000000000000000e RCX: 1ffff100082b0719
     ...
     CR2: 000000000000000e CR3: 000000004b1bc003 CR4: 0000000000060ef0
     Call Trace:
      kcm_create+0x600/0xbf0 [kcm]
      __sock_create+0x324/0x750 net/socket.c:1272
     ...
    
    This is due to race between sock_create and unfinished
    register_pernet_device. kcm_create tries to do "net_generic(net,
    kcm_net_id)". but kcm_net_id is not initialized yet.
    
    So switch the order of the two to close the race.
    
    This can be reproduced with mutiple processes doing socket(PF_KCM, ...)
    and one process doing module removal.
    
    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Reviewed-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b74c2990d061b3928eea19ba19e89209bb7f2152
Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date:   Thu Apr 4 16:37:53 2019 +0200

    ipv6: sit: reset ip header pointer in ipip6_rcv
    
    [ Upstream commit bb9bd814ebf04f579be466ba61fc922625508807 ]
    
    ipip6 tunnels run iptunnel_pull_header on received skbs. This can
    determine the following use-after-free accessing iph pointer since
    the packet will be 'uncloned' running pskb_expand_head if it is a
    cloned gso skb (e.g if the packet has been sent though a veth device)
    
    [  706.369655] BUG: KASAN: use-after-free in ipip6_rcv+0x1678/0x16e0 [sit]
    [  706.449056] Read of size 1 at addr ffffe01b6bd855f5 by task ksoftirqd/1/=
    [  706.669494] Hardware name: HPE ProLiant m400 Server/ProLiant m400 Server, BIOS U02 08/19/2016
    [  706.771839] Call trace:
    [  706.801159]  dump_backtrace+0x0/0x2f8
    [  706.845079]  show_stack+0x24/0x30
    [  706.884833]  dump_stack+0xe0/0x11c
    [  706.925629]  print_address_description+0x68/0x260
    [  706.982070]  kasan_report+0x178/0x340
    [  707.025995]  __asan_report_load1_noabort+0x30/0x40
    [  707.083481]  ipip6_rcv+0x1678/0x16e0 [sit]
    [  707.132623]  tunnel64_rcv+0xd4/0x200 [tunnel4]
    [  707.185940]  ip_local_deliver_finish+0x3b8/0x988
    [  707.241338]  ip_local_deliver+0x144/0x470
    [  707.289436]  ip_rcv_finish+0x43c/0x14b0
    [  707.335447]  ip_rcv+0x628/0x1138
    [  707.374151]  __netif_receive_skb_core+0x1670/0x2600
    [  707.432680]  __netif_receive_skb+0x28/0x190
    [  707.482859]  process_backlog+0x1d0/0x610
    [  707.529913]  net_rx_action+0x37c/0xf68
    [  707.574882]  __do_softirq+0x288/0x1018
    [  707.619852]  run_ksoftirqd+0x70/0xa8
    [  707.662734]  smpboot_thread_fn+0x3a4/0x9e8
    [  707.711875]  kthread+0x2c8/0x350
    [  707.750583]  ret_from_fork+0x10/0x18
    
    [  707.811302] Allocated by task 16982:
    [  707.854182]  kasan_kmalloc.part.1+0x40/0x108
    [  707.905405]  kasan_kmalloc+0xb4/0xc8
    [  707.948291]  kasan_slab_alloc+0x14/0x20
    [  707.994309]  __kmalloc_node_track_caller+0x158/0x5e0
    [  708.053902]  __kmalloc_reserve.isra.8+0x54/0xe0
    [  708.108280]  __alloc_skb+0xd8/0x400
    [  708.150139]  sk_stream_alloc_skb+0xa4/0x638
    [  708.200346]  tcp_sendmsg_locked+0x818/0x2b90
    [  708.251581]  tcp_sendmsg+0x40/0x60
    [  708.292376]  inet_sendmsg+0xf0/0x520
    [  708.335259]  sock_sendmsg+0xac/0xf8
    [  708.377096]  sock_write_iter+0x1c0/0x2c0
    [  708.424154]  new_sync_write+0x358/0x4a8
    [  708.470162]  __vfs_write+0xc4/0xf8
    [  708.510950]  vfs_write+0x12c/0x3d0
    [  708.551739]  ksys_write+0xcc/0x178
    [  708.592533]  __arm64_sys_write+0x70/0xa0
    [  708.639593]  el0_svc_handler+0x13c/0x298
    [  708.686646]  el0_svc+0x8/0xc
    
    [  708.739019] Freed by task 17:
    [  708.774597]  __kasan_slab_free+0x114/0x228
    [  708.823736]  kasan_slab_free+0x10/0x18
    [  708.868703]  kfree+0x100/0x3d8
    [  708.905320]  skb_free_head+0x7c/0x98
    [  708.948204]  skb_release_data+0x320/0x490
    [  708.996301]  pskb_expand_head+0x60c/0x970
    [  709.044399]  __iptunnel_pull_header+0x3b8/0x5d0
    [  709.098770]  ipip6_rcv+0x41c/0x16e0 [sit]
    [  709.146873]  tunnel64_rcv+0xd4/0x200 [tunnel4]
    [  709.200195]  ip_local_deliver_finish+0x3b8/0x988
    [  709.255596]  ip_local_deliver+0x144/0x470
    [  709.303692]  ip_rcv_finish+0x43c/0x14b0
    [  709.349705]  ip_rcv+0x628/0x1138
    [  709.388413]  __netif_receive_skb_core+0x1670/0x2600
    [  709.446943]  __netif_receive_skb+0x28/0x190
    [  709.497120]  process_backlog+0x1d0/0x610
    [  709.544169]  net_rx_action+0x37c/0xf68
    [  709.589131]  __do_softirq+0x288/0x1018
    
    [  709.651938] The buggy address belongs to the object at ffffe01b6bd85580
                    which belongs to the cache kmalloc-1024 of size 1024
    [  709.804356] The buggy address is located 117 bytes inside of
                    1024-byte region [ffffe01b6bd85580, ffffe01b6bd85980)
    [  709.946340] The buggy address belongs to the page:
    [  710.003824] page:ffff7ff806daf600 count:1 mapcount:0 mapping:ffffe01c4001f600 index:0x0
    [  710.099914] flags: 0xfffff8000000100(slab)
    [  710.149059] raw: 0fffff8000000100 dead000000000100 dead000000000200 ffffe01c4001f600
    [  710.242011] raw: 0000000000000000 0000000000380038 00000001ffffffff 0000000000000000
    [  710.334966] page dumped because: kasan: bad access detected
    
    Fix it resetting iph pointer after iptunnel_pull_header
    
    Fixes: a09a4c8dd1ec ("tunnels: Remove encapsulation offloads on decap")
    Tested-by: Jianlin Shi <jishi@redhat.com>
    Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58ffe3e3248f90dc9ae30ccda9defae0dddd16f7
Author: Junwei Hu <hujunwei4@huawei.com>
Date:   Tue Apr 2 19:38:04 2019 +0800

    ipv6: Fix dangling pointer when ipv6 fragment
    
    [ Upstream commit ef0efcd3bd3fd0589732b67fb586ffd3c8705806 ]
    
    At the beginning of ip6_fragment func, the prevhdr pointer is
    obtained in the ip6_find_1stfragopt func.
    However, all the pointers pointing into skb header may change
    when calling skb_checksum_help func with
    skb->ip_summed = CHECKSUM_PARTIAL condition.
    The prevhdr pointe will be dangling if it is not reloaded after
    calling __skb_linearize func in skb_checksum_help func.
    
    Here, I add a variable, nexthdr_offset, to evaluate the offset,
    which does not changes even after calling __skb_linearize func.
    
    Fixes: 405c92f7a541 ("ipv6: add defensive check for CHECKSUM_PARTIAL skbs in ip_fragment")
    Signed-off-by: Junwei Hu <hujunwei4@huawei.com>
    Reported-by: Wenhao Zhang <zhangwenhao8@huawei.com>
    Reported-by: syzbot+e8ce541d095e486074fc@syzkaller.appspotmail.com
    Reviewed-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad2548c9462f1aa41ddb8b7f61afeb418e64cec7
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Jan 21 17:26:42 2019 +0100

    tty: ldisc: add sysctl to prevent autoloading of ldiscs
    
    commit 7c0cca7c847e6e019d67b7d793efbbe3b947d004 upstream.
    
    By default, the kernel will automatically load the module of any line
    dicipline that is asked for.  As this sometimes isn't the safest thing
    to do, provide a sysctl to disable this feature.
    
    By default, we set this to 'y' as that is the historical way that Linux
    has worked, and we do not want to break working systems.  But in the
    future, perhaps this can default to 'n' to prevent this functionality.
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 429977fd9f7153607230a6040ee12510a525e930
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Apr 5 15:39:26 2019 +0200

    tty: mark Siemens R3964 line discipline as BROKEN
    
    commit c7084edc3f6d67750f50d4183134c4fb5712a5c8 upstream.
    
    The n_r3964 line discipline driver was written in a different time, when
    SMP machines were rare, and users were trusted to do the right thing.
    Since then, the world has moved on but not this code, it has stayed
    rooted in the past with its lovely hand-crafted list structures and
    loads of "interesting" race conditions all over the place.
    
    After attempting to clean up most of the issues, I just gave up and am
    now marking the driver as BROKEN so that hopefully someone who has this
    hardware will show up out of the woodwork (I know you are out there!)
    and will help with debugging a raft of changes that I had laying around
    for the code, but was too afraid to commit as odds are they would break
    things.
    
    Many thanks to Jann and Linus for pointing out the initial problems in
    this codebase, as well as many reviews of my attempts to fix the issues.
    It was a case of whack-a-mole, and as you can see, the mole won.
    
    Reported-by: Jann Horn <jannh@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 8add7054070ab79cb271b336d9660bca0ffcaf85
Author: Yueyi Li <liyueyi@live.com>
Date:   Mon Dec 24 07:40:07 2018 +0000

    arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in linear region
    
    [ Upstream commit c8a43c18a97845e7f94ed7d181c11f41964976a2 ]
    
    When KASLR is enabled (CONFIG_RANDOMIZE_BASE=y), the top 4K of kernel
    virtual address space may be mapped to physical addresses despite being
    reserved for ERR_PTR values.
    
    Fix the randomization of the linear region so that we avoid mapping the
    last page of the virtual address space.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: liyueyi <liyueyi@live.com>
    [will: rewrote commit message; merged in suggestion from Ard]
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Sasha Levin (Microsoft) <sashal@kernel.org>

commit 83b4ccf2ae92a6efc55f978568c08cc3b6fc0b10
Author: Gilad Ben-Yossef <gilad@benyossef.com>
Date:   Sun Jan 7 12:14:22 2018 +0000

    stating: ccree: revert "staging: ccree: fix leak of import() after init()"
    
    commit 293edc27f8bc8a44978e9e95902b07b74f1c7523 upstream
    
    This reverts commit c5f39d07860c ("staging: ccree: fix leak of import()
    after init()") and commit aece09024414 ("staging: ccree: Uninitialized
    return in ssi_ahash_import()").
    
    This is the wrong solution and ends up relying on uninitialized memory,
    although it was not obvious to me at the time.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 56dbdae0c48827f8fa8bb23f6a26c8785bc455c8
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Fri Apr 5 18:38:45 2019 -0700

    lib/string.c: implement a basic bcmp
    
    [ Upstream commit 5f074f3e192f10c9fade898b9b3b8812e3d83342 ]
    
    A recent optimization in Clang (r355672) lowers comparisons of the
    return value of memcmp against zero to comparisons of the return value
    of bcmp against zero.  This helps some platforms that implement bcmp
    more efficiently than memcmp.  glibc simply aliases bcmp to memcmp, but
    an optimized implementation is in the works.
    
    This results in linkage failures for all targets with Clang due to the
    undefined symbol.  For now, just implement bcmp as a tailcail to memcmp
    to unbreak the build.  This routine can be further optimized in the
    future.
    
    Other ideas discussed:
    
     * A weak alias was discussed, but breaks for architectures that define
       their own implementations of memcmp since aliases to declarations are
       not permitted (only definitions). Arch-specific memcmp
       implementations typically declare memcmp in C headers, but implement
       them in assembly.
    
     * -ffreestanding also is used sporadically throughout the kernel.
    
     * -fno-builtin-bcmp doesn't work when doing LTO.
    
    Link: https://bugs.llvm.org/show_bug.cgi?id=41035
    Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp
    Link: https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13
    Link: https://github.com/ClangBuiltLinux/linux/issues/416
    Link: http://lkml.kernel.org/r/20190313211335.165605-1-ndesaulniers@google.com
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Reported-by: Nathan Chancellor <natechancellor@gmail.com>
    Reported-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
    Suggested-by: Arnd Bergmann <arnd@arndb.de>
    Suggested-by: James Y Knight <jyknight@google.com>
    Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
    Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Tested-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: David Laight <David.Laight@ACULAB.COM>
    Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 625c82068a277db442e9fa08727d1670373203f9
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Thu Dec 6 11:12:31 2018 -0800

    x86/vdso: Drop implicit common-page-size linker flag
    
    commit ac3e233d29f7f77f28243af0132057d378d3ea58 upstream.
    
    GNU linker's -z common-page-size's default value is based on the target
    architecture. arch/x86/entry/vdso/Makefile sets it to the architecture
    default, which is implicit and redundant. Drop it.
    
    Fixes: 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu")
    Reported-by: Dmitry Golovin <dima@golovin.in>
    Reported-by: Bill Wendling <morbo@google.com>
    Suggested-by: Dmitry Golovin <dima@golovin.in>
    Suggested-by: Rui Ueyama <ruiu@google.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Acked-by: Andy Lutomirski <luto@kernel.org>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: Fangrui Song <maskray@google.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: x86-ml <x86@kernel.org>
    Link: https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulniers@google.com
    Link: https://bugs.llvm.org/show_bug.cgi?id=38774
    Link: https://github.com/ClangBuiltLinux/linux/issues/31
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d4b1ffc7edb1f963b0223469b0e8b699a197c1f
Author: Alistair Strachan <astrachan@google.com>
Date:   Fri Aug 3 10:39:31 2018 -0700

    x86: vdso: Use $LD instead of $CC to link
    
    commit 379d98ddf41344273d9718556f761420f4dc80b3 upstream.
    
    The vdso{32,64}.so can fail to link with CC=clang when clang tries to find
    a suitable GCC toolchain to link these libraries with.
    
    /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o:
      access beyond end of merged section (782)
    
    This happens because the host environment leaked into the cross compiler
    environment due to the way clang searches for suitable GCC toolchains.
    
    Clang is a retargetable compiler, and each invocation of it must provide
    --target=<something> --gcc-toolchain=<something> to allow it to find the
    correct binutils for cross compilation. These flags had been added to
    KBUILD_CFLAGS, but the vdso code uses CC and not KBUILD_CFLAGS (for various
    reasons) which breaks clang's ability to find the correct linker when cross
    compiling.
    
    Most of the time this goes unnoticed because the host linker is new enough
    to work anyway, or is incompatible and skipped, but this cannot be reliably
    assumed.
    
    This change alters the vdso makefile to just use LD directly, which
    bypasses clang and thus the searching problem. The makefile will just use
    ${CROSS_COMPILE}ld instead, which is always what we want. This matches the
    method used to link vmlinux.
    
    This drops references to DISABLE_LTO; this option doesn't seem to be set
    anywhere, and not knowing what its possible values are, it's not clear how
    to convert it from CC to LD flag.
    
    Signed-off-by: Alistair Strachan <astrachan@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Andy Lutomirski <luto@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: kernel-team@android.com
    Cc: joel@joelfernandes.org
    Cc: Andi Kleen <andi.kleen@intel.com>
    Link: https://lkml.kernel.org/r/20180803173931.117515-1-astrachan@google.com
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1efb2caed0ad8f9dca9a57aa1f9c6517ec38fb61
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Mon Feb 11 11:30:04 2019 -0800

    kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD
    
    commit ad15006cc78459d059af56729c4d9bed7c7fd860 upstream.
    
    This causes an issue when trying to build with `make LD=ld.lld` if
    ld.lld and the rest of your cross tools aren't in the same directory
    (ex. /usr/local/bin) (as is the case for Android's build system), as the
    GCC_TOOLCHAIN_DIR then gets set based on `which $(LD)` which will point
    where LLVM tools are, not GCC/binutils tools are located.
    
    Instead, select the GCC_TOOLCHAIN_DIR based on another tool provided by
    binutils for which LLVM does not provide a substitute for, such as
    elfedit.
    
    Fixes: 785f11aa595b ("kbuild: Add better clang cross build support")
    Link: https://github.com/ClangBuiltLinux/linux/issues/341
    Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
    Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
    Tested-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f8e322e448b493cab180fe6c85a1cbe9c0c2aad
Author: Breno Leitao <leitao@debian.org>
Date:   Mon Apr 8 16:32:38 2019 +1000

    powerpc/tm: Limit TM code inside PPC_TRANSACTIONAL_MEM
    
    [ Upstream commit 897bc3df8c5aebb54c32d831f917592e873d0559 ]
    
    Commit e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint")
    moved a code block around and this block uses a 'msr' variable outside of
    the CONFIG_PPC_TRANSACTIONAL_MEM, however the 'msr' variable is declared
    inside a CONFIG_PPC_TRANSACTIONAL_MEM block, causing a possible error when
    CONFIG_PPC_TRANSACTION_MEM is not defined.
    
            error: 'msr' undeclared (first use in this function)
    
    This is not causing a compilation error in the mainline kernel, because
    'msr' is being used as an argument of MSR_TM_ACTIVE(), which is defined as
    the following when CONFIG_PPC_TRANSACTIONAL_MEM is *not* set:
    
            #define MSR_TM_ACTIVE(x) 0
    
    This patch just fixes this issue avoiding the 'msr' variable usage outside
    the CONFIG_PPC_TRANSACTIONAL_MEM block, avoiding trusting in the
    MSR_TM_ACTIVE() definition.
    
    Cc: stable@vger.kernel.org
    Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
    Fixes: e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint")
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3cb115e638ecc8ff0c626e4a227e297afaacf055
Author: Yan Zhao <yan.y.zhao@intel.com>
Date:   Mon Apr 8 01:12:47 2019 -0400

    drm/i915/gvt: do not let pin count of shadow mm go negative
    
    [ Upstream commit 663a50ceac75c2208d2ad95365bc8382fd42f44d ]
    
    shadow mm's pin count got increased in workload preparation phase, which
    is after workload scanning.
    it will get decreased in complete_current_workload() anyway after
    workload completion.
    Sometimes, if a workload meets a scanning error, its shadow mm pin count
    will not get increased but will get decreased in the end.
    This patch lets shadow mm's pin count not go below 0.
    
    Fixes: 2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization")
    Cc: zhenyuw@linux.intel.com
    Cc: stable@vger.kernel.org #4.14+
    Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b0cc293ed6cb94e024ede2fea081f216eb5b435
Author: Andy Lutomirski <luto@kernel.org>
Date:   Thu Dec 14 13:19:07 2017 -0800

    x86/power: Make restore_processor_context() sane
    
    [ Upstream commit 7ee18d677989e99635027cee04c878950e0752b9 ]
    
    My previous attempt to fix a couple of bugs in __restore_processor_context():
    
      5b06bbcfc2c6 ("x86/power: Fix some ordering bugs in __restore_processor_context()")
    
    ... introduced yet another bug, breaking suspend-resume.
    
    Rather than trying to come up with a minimal fix, let's try to clean it up
    for real.  This patch fixes quite a few things:
    
     - The old code saved a nonsensical subset of segment registers.
       The only registers that need to be saved are those that contain
       userspace state or those that can't be trivially restored without
       percpu access working.  (On x86_32, we can restore percpu access
       by writing __KERNEL_PERCPU to %fs.  On x86_64, it's easier to
       save and restore the kernel's GSBASE.)  With this patch, we
       restore hardcoded values to the kernel state where applicable and
       explicitly restore the user state after fixing all the descriptor
       tables.
    
     - We used to use an unholy mix of inline asm and C helpers for
       segment register access.  Let's get rid of the inline asm.
    
    This fixes the reported s2ram hangs and make the code all around
    more logical.
    
    Analyzed-by: Linus Torvalds <torvalds@linux-foundation.org>
    Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Reported-by: Pavel Machek <pavel@ucw.cz>
    Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Tested-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bpetkov@suse.de>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
    Cc: Zhang Rui <rui.zhang@intel.com>
    Fixes: 5b06bbcfc2c6 ("x86/power: Fix some ordering bugs in __restore_processor_context()")
    Link: http://lkml.kernel.org/r/398ee68e5c0f766425a7b746becfc810840770ff.1513286253.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 28c25a93926066500c9be08197b4535cbdb00165
Author: Andy Lutomirski <luto@kernel.org>
Date:   Thu Dec 14 13:19:06 2017 -0800

    x86/power/32: Move SYSENTER MSR restoration to fix_processor_context()
    
    [ Upstream commit 896c80bef4d3b357814a476663158aaf669d0fb3 ]
    
    x86_64 restores system call MSRs in fix_processor_context(), and
    x86_32 restored them along with segment registers.  The 64-bit
    variant makes more sense, so move the 32-bit code to match the
    64-bit code.
    
    No side effects are expected to runtime behavior.
    
    Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bpetkov@suse.de>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
    Cc: Zhang Rui <rui.zhang@intel.com>
    Link: http://lkml.kernel.org/r/65158f8d7ee64dd6bbc6c1c83b3b34aaa854e3ae.1513286253.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4cafb8a3ee0e9e0ca86f36623a5facfa5b93bd8
Author: Andy Lutomirski <luto@kernel.org>
Date:   Thu Dec 14 13:19:05 2017 -0800

    x86/power/64: Use struct desc_ptr for the IDT in struct saved_context
    
    [ Upstream commit 090edbe23ff57940fca7f57d9165ce57a826bd7a ]
    
    x86_64's saved_context nonsensically used separate idt_limit and
    idt_base fields and then cast &idt_limit to struct desc_ptr *.
    
    This was correct (with -fno-strict-aliasing), but it's confusing,
    served no purpose, and required #ifdeffery. Simplify this by
    using struct desc_ptr directly.
    
    No change in functionality.
    
    Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bpetkov@suse.de>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
    Cc: Zhang Rui <rui.zhang@intel.com>
    Link: http://lkml.kernel.org/r/967909ce38d341b01d45eff53e278e2728a3a93a.1513286253.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3363914c6b2bf9370708ef296a004edc84012f24
Author: Andy Lutomirski <luto@kernel.org>
Date:   Thu Nov 30 07:57:57 2017 -0800

    x86/power: Fix some ordering bugs in __restore_processor_context()
    
    [ Upstream commit 5b06bbcfc2c621da3009da8decb7511500c293ed ]
    
    __restore_processor_context() had a couple of ordering bugs.  It
    restored GSBASE after calling load_gs_index(), and the latter can
    call into tracing code.  It also tried to restore segment registers
    before restoring the LDT, which is straight-up wrong.
    
    Reorder the code so that we restore GSBASE, then the descriptor
    tables, then the segments.
    
    This fixes two bugs.  First, it fixes a regression that broke resume
    under certain configurations due to irqflag tracing in
    native_load_gs_index().  Second, it fixes resume when the userspace
    process that initiated suspect had funny segments.  The latter can be
    reproduced by compiling this:
    
    // SPDX-License-Identifier: GPL-2.0
    /*
     * ldt_echo.c - Echo argv[1] while using an LDT segment
     */
    
    int main(int argc, char **argv)
    {
            int ret;
            size_t len;
            char *buf;
    
            const struct user_desc desc = {
                    .entry_number    = 0,
                    .base_addr       = 0,
                    .limit           = 0xfffff,
                    .seg_32bit       = 1,
                    .contents        = 0, /* Data, grow-up */
                    .read_exec_only  = 0,
                    .limit_in_pages  = 1,
                    .seg_not_present = 0,
                    .useable         = 0
            };
    
            if (argc != 2)
                    errx(1, "Usage: %s STRING", argv[0]);
    
            len = asprintf(&buf, "%s\n", argv[1]);
            if (len < 0)
                    errx(1, "Out of memory");
    
            ret = syscall(SYS_modify_ldt, 1, &desc, sizeof(desc));
            if (ret < -1)
                    errno = -ret;
            if (ret)
                    err(1, "modify_ldt");
    
            asm volatile ("movw %0, %%es" :: "rm" ((unsigned short)7));
            write(1, buf, len);
            return 0;
    }
    
    and running ldt_echo >/sys/power/mem
    
    Without the fix, the latter causes a triple fault on resume.
    
    Fixes: ca37e57bbe0c ("x86/entry/64: Add missing irqflags tracing to native_load_gs_index()")
    Reported-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://lkml.kernel.org/r/6b31721ea92f51ea839e79bd97ade4a75b1eeea2.1512057304.git.luto@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5393c36705010563a97e3a73e28ace83ff515e0
Author: Marek Behún <marek.behun@nic.cz>
Date:   Fri Apr 5 11:07:58 2019 +0200

    net: sfp: move sfp_register_socket call from sfp_remove to sfp_probe
    
    Commit c4ba68b8691e4 backported from upstream to 4.14 stable was
    probably applied wrongly, and instead of calling sfp_register_socket in
    sfp_probe, the socket registering code was put into sfp_remove. This is
    obviously wrong.
    
    The commit first appeared in 4.14.104. Fix it for the next 4.14 release.
    
    Fixes: c4ba68b8691e4 ("net: sfp: do not probe SFP module before we're attached")
    Cc: stable <stable@vger.kernel.org>
    Cc: Russell King <rmk+kernel@armlinux.org.uk>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Marek Behún <marek.behun@nic.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>