commit 1b940bbc5c55551a3420f403a2b10cb884cffb01
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Aug 5 09:59:52 2020 +0200

    Linux 5.4.56
    
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df35e878d0a51755fb500e2e8e29c7ebb0239756
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Mar 2 12:09:38 2020 -0300

    perf bench: Share some global variables to fix build with gcc 10
    
    commit e4d9b04b973b2dbce7b42af95ea70d07da1c936d upstream.
    
    Noticed with gcc 10 (fedora rawhide) that those variables were not being
    declared as static, so end up with:
    
      ld: /tmp/build/perf/bench/epoll-wait.o:/git/perf/tools/perf/bench/epoll-wait.c:93: multiple definition of `end'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
      ld: /tmp/build/perf/bench/epoll-wait.o:/git/perf/tools/perf/bench/epoll-wait.c:93: multiple definition of `start'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
      ld: /tmp/build/perf/bench/epoll-wait.o:/git/perf/tools/perf/bench/epoll-wait.c:93: multiple definition of `runtime'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
      ld: /tmp/build/perf/bench/epoll-ctl.o:/git/perf/tools/perf/bench/epoll-ctl.c:38: multiple definition of `end'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
      ld: /tmp/build/perf/bench/epoll-ctl.o:/git/perf/tools/perf/bench/epoll-ctl.c:38: multiple definition of `start'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
      ld: /tmp/build/perf/bench/epoll-ctl.o:/git/perf/tools/perf/bench/epoll-ctl.c:38: multiple definition of `runtime'; /tmp/build/perf/bench/futex-hash.o:/git/perf/tools/perf/bench/futex-hash.c:40: first defined here
      make[4]: *** [/git/perf/tools/build/Makefile.build:145: /tmp/build/perf/bench/perf-in.o] Error 1
    
    Prefix those with bench__ and add them to bench/bench.h, so that we can
    share those on the tools needing to access those variables from signal
    handlers.
    
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: http://lore.kernel.org/lkml/20200303155811.GD13702@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 702d1b287fd24c5df4e25edf2896e72ec840f57a
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Mar 2 11:23:03 2020 -0300

    perf env: Do not return pointers to local variables
    
    commit ebcb9464a2ae3a547e97de476575c82ece0e93e2 upstream.
    
    It is possible to return a pointer to a local variable when looking up
    the architecture name for the running system and no normalization is
    done on that value, i.e. we may end up returning the uts.machine local
    variable.
    
    While this doesn't happen on most arches, as normalization takes place,
    lets fix this by making that a static variable and optimize it a bit by
    not always running uname(), only the first time.
    
    Noticed in fedora rawhide running with:
    
      [perfbuilder@a5ff49d6e6e4 ~]$ gcc --version
      gcc (GCC) 10.0.1 20200216 (Red Hat 10.0.1-0.8)
    
    Reported-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73d2d6b421dfdc66b4615452a94efcece27a3c21
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Mar 2 11:13:19 2020 -0300

    perf tests bp_account: Make global variable static
    
    commit cff20b3151ccab690715cb6cf0f5da5cccb32adf upstream.
    
    To fix the build with newer gccs, that without this patch exit with:
    
        LD       /tmp/build/perf/tests/perf-in.o
      ld: /tmp/build/perf/tests/bp_account.o:/git/perf/tools/perf/tests/bp_account.c:22: multiple definition of `the_var'; /tmp/build/perf/tests/bp_signal.o:/git/perf/tools/perf/tests/bp_signal.c:38: first defined here
      make[4]: *** [/git/perf/tools/build/Makefile.build:145: /tmp/build/perf/tests/perf-in.o] Error 1
    
    First noticed in fedora:rawhide/32 with:
    
      [perfbuilder@a5ff49d6e6e4 ~]$ gcc --version
      gcc (GCC) 10.0.1 20200216 (Red Hat 10.0.1-0.8)
    
    Reported-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39568546706f3cb647c99b1f3e271c958aea3414
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Jul 29 10:53:28 2020 +0200

    x86/i8259: Use printk_deferred() to prevent deadlock
    
    commit bdd65589593edd79b6a12ce86b3b7a7c6dae5208 upstream.
    
    0day reported a possible circular locking dependency:
    
    Chain exists of:
      &irq_desc_lock_class --> console_owner --> &port_lock_key
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&port_lock_key);
                                   lock(console_owner);
                                   lock(&port_lock_key);
      lock(&irq_desc_lock_class);
    
    The reason for this is a printk() in the i8259 interrupt chip driver
    which is invoked with the irq descriptor lock held, which reverses the
    lock operations vs. printk() from arbitrary contexts.
    
    Switch the printk() to printk_deferred() to avoid that.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/87365abt2v.fsf@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01ac46c6baf0e3da71bb36255bc924acbc762662
Author: Wanpeng Li <wanpengli@tencent.com>
Date:   Fri Jul 31 11:12:19 2020 +0800

    KVM: LAPIC: Prevent setting the tscdeadline timer if the lapic is hw disabled
    
    commit d2286ba7d574ba3103a421a2f9ec17cb5b0d87a1 upstream.
    
    Prevent setting the tscdeadline timer if the lapic is hw disabled.
    
    Fixes: bce87cce88 (KVM: x86: consolidate different ways to test for in-kernel LAPIC)
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
    Message-Id: <1596165141-28874-1-git-send-email-wanpengli@tencent.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd412846a6ecc0ed1876c04a6ed93c5205c9bdf9
Author: Will Deacon <will@kernel.org>
Date:   Thu Jul 23 11:17:14 2020 +0100

    KVM: arm64: Don't inherit exec permission across page-table levels
    
    commit b757b47a2fcba584d4a32fd7ee68faca510ab96f upstream.
    
    If a stage-2 page-table contains an executable, read-only mapping at the
    pte level (e.g. due to dirty logging being enabled), a subsequent write
    fault to the same page which tries to install a larger block mapping
    (e.g. due to dirty logging having been disabled) will erroneously inherit
    the exec permission and consequently skip I-cache invalidation for the
    rest of the block.
    
    Ensure that exec permission is only inherited by write faults when the
    new mapping is of the same size as the existing one. A subsequent
    instruction abort will result in I-cache invalidation for the entire
    block mapping.
    
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Tested-by: Quentin Perret <qperret@google.com>
    Reviewed-by: Quentin Perret <qperret@google.com>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200723101714.15873-1-will@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1aff51292ee881f79b226915ef15bdcb87a95fe2
Author: Xie He <xie.he.0141@gmail.com>
Date:   Fri Jul 24 09:33:47 2020 -0700

    drivers/net/wan: lapb: Corrected the usage of skb_cow
    
    [ Upstream commit 8754e1379e7089516a449821f88e1fe1ebbae5e1 ]
    
    This patch fixed 2 issues with the usage of skb_cow in LAPB drivers
    "lapbether" and "hdlc_x25":
    
    1) After skb_cow fails, kfree_skb should be called to drop a reference
    to the skb. But in both drivers, kfree_skb is not called.
    
    2) skb_cow should be called before skb_push so that is can ensure the
    safety of skb_push. But in "lapbether", it is incorrectly called after
    skb_push.
    
    More details about these 2 issues:
    
    1) The behavior of calling kfree_skb on failure is also the behavior of
    netif_rx, which is called by this function with "return netif_rx(skb);".
    So this function should follow this behavior, too.
    
    2) In "lapbether", skb_cow is called after skb_push. This results in 2
    logical issues:
       a) skb_push is not protected by skb_cow;
       b) An extra headroom of 1 byte is ensured after skb_push. This extra
          headroom has no use in this function. It also has no use in the
          upper-layer function that this function passes the skb to
          (x25_lapb_receive_frame in net/x25/x25_dev.c).
    So logically skb_cow should instead be called before skb_push.
    
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Martin Schiller <ms@dev.tdt.de>
    Signed-off-by: Xie He <xie.he.0141@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f88c909dc28cf7a3160cd62bcc23aace5d4fbe3d
Author: Atish Patra <atish.patra@wdc.com>
Date:   Wed Jul 15 16:30:07 2020 -0700

    RISC-V: Set maximum number of mapped pages correctly
    
    [ Upstream commit d0d8aae64566b753c4330fbd5944b88af035f299 ]
    
    Currently, maximum number of mapper pages are set to the pfn calculated
    from the memblock size of the memblock containing kernel. This will work
    until that memblock spans the entire memory. However, it will be set to
    a wrong value if there are multiple memblocks defined in kernel
    (e.g. with efi runtime services).
    
    Set the the maximum value to the pfn calculated from dram size.
    
    Signed-off-by: Atish Patra <atish.patra@wdc.com>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3043abb5baad736d9255d06f8475666c8f7d649
Author: Andrea Righi <andrea.righi@canonical.com>
Date:   Fri Jul 24 10:59:10 2020 +0200

    xen-netfront: fix potential deadlock in xennet_remove()
    
    [ Upstream commit c2c633106453611be07821f53dff9e93a9d1c3f0 ]
    
    There's a potential race in xennet_remove(); this is what the driver is
    doing upon unregistering a network device:
    
      1. state = read bus state
      2. if state is not "Closed":
      3.    request to set state to "Closing"
      4.    wait for state to be set to "Closing"
      5.    request to set state to "Closed"
      6.    wait for state to be set to "Closed"
    
    If the state changes to "Closed" immediately after step 1 we are stuck
    forever in step 4, because the state will never go back from "Closed" to
    "Closing".
    
    Make sure to check also for state == "Closed" in step 4 to prevent the
    deadlock.
    
    Also add a 5 sec timeout any time we wait for the bus state to change,
    to avoid getting stuck forever in wait_event().
    
    Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7b488d65d39d94ae66b93cca9fc655aaa2ea1bb
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Wed Jul 22 21:58:39 2020 -0500

    cxgb4: add missing release on skb in uld_send()
    
    [ Upstream commit e6827d1abdc9b061a57d7b7d3019c4e99fabea2f ]
    
    In the implementation of uld_send(), the skb is consumed on all
    execution paths except one. Release skb when returning NET_XMIT_DROP.
    
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f4e6b874b57a510ad38bd06b7f7ba1d209f57ad
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Fri Jul 17 09:04:26 2020 -0500

    x86/stacktrace: Fix reliable check for empty user task stacks
    
    [ Upstream commit 039a7a30ec102ec866d382a66f87f6f7654f8140 ]
    
    If a user task's stack is empty, or if it only has user regs, ORC
    reports it as a reliable empty stack.  But arch_stack_walk_reliable()
    incorrectly treats it as unreliable.
    
    That happens because the only success path for user tasks is inside the
    loop, which only iterates on non-empty stacks.  Generally, a user task
    must end in a user regs frame, but an empty stack is an exception to
    that rule.
    
    Thanks to commit 71c95825289f ("x86/unwind/orc: Fix error handling in
    __unwind_start()"), unwind_start() now sets state->error appropriately.
    So now for both ORC and FP unwinders, unwind_done() and !unwind_error()
    always means the end of the stack was successfully reached.  So the
    success path for kthreads is no longer needed -- it can also be used for
    empty user tasks.
    
    Reported-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Link: https://lkml.kernel.org/r/f136a4e5f019219cbc4f4da33b30c2f44fa65b84.1594994374.git.jpoimboe@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32344d2993b0228e238dff163d7447dcf250f147
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Fri Jul 17 09:04:25 2020 -0500

    x86/unwind/orc: Fix ORC for newly forked tasks
    
    [ Upstream commit 372a8eaa05998cd45b3417d0e0ffd3a70978211a ]
    
    The ORC unwinder fails to unwind newly forked tasks which haven't yet
    run on the CPU.  It correctly reads the 'ret_from_fork' instruction
    pointer from the stack, but it incorrectly interprets that value as a
    call stack address rather than a "signal" one, so the address gets
    incorrectly decremented in the call to orc_find(), resulting in bad ORC
    data.
    
    Fix it by forcing 'ret_from_fork' frames to be signal frames.
    
    Reported-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Link: https://lkml.kernel.org/r/f91a8778dde8aae7f71884b5df2b16d552040441.1594994374.git.jpoimboe@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a14d6a9ddf33c13bb58cda5fb0ad8edae628b9f8
Author: Raviteja Narayanam <raviteja.narayanam@xilinx.com>
Date:   Fri Jul 3 19:25:49 2020 +0530

    Revert "i2c: cadence: Fix the hold bit setting"
    
    [ Upstream commit 0db9254d6b896b587759e2c844c277fb1a6da5b9 ]
    
    This reverts commit d358def706880defa4c9e87381c5bf086a97d5f9.
    
    There are two issues with "i2c: cadence: Fix the hold bit setting" commit.
    
    1. In case of combined message request from user space, when the HOLD
    bit is cleared in cdns_i2c_mrecv function, a STOP condition is sent
    on the bus even before the last message is started. This is because when
    the HOLD bit is cleared, the FIFOS are empty and there is no pending
    transfer. The STOP condition should occur only after the last message
    is completed.
    
    2. The code added by the commit is redundant. Driver is handling the
    setting/clearing of HOLD bit in right way before the commit.
    
    The setting of HOLD bit based on 'bus_hold_flag' is taken care in
    cdns_i2c_master_xfer function even before cdns_i2c_msend/cdns_i2c_recv
    functions.
    
    The clearing of HOLD bit is taken care at the end of cdns_i2c_msend and
    cdns_i2c_recv functions based on bus_hold_flag and byte count.
    Since clearing of HOLD bit is done after the slave address is written to
    the register (writing to address register triggers the message transfer),
    it is ensured that STOP condition occurs at the right time after
    completion of the pending transfer (last message).
    
    Signed-off-by: Raviteja Narayanam <raviteja.narayanam@xilinx.com>
    Acked-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df366abb9c8f4c852b0bca9691810be9335fa153
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Jul 21 15:23:12 2020 +0900

    net: ethernet: ravb: exit if re-initialization fails in tx timeout
    
    [ Upstream commit 015c5d5e6aa3523c758a70eb87b291cece2dbbb4 ]
    
    According to the report of [1], this driver is possible to cause
    the following error in ravb_tx_timeout_work().
    
    ravb e6800000.ethernet ethernet: failed to switch device to config mode
    
    This error means that the hardware could not change the state
    from "Operation" to "Configuration" while some tx and/or rx queue
    are operating. After that, ravb_config() in ravb_dmac_init() will fail,
    and then any descriptors will be not allocaled anymore so that NULL
    pointer dereference happens after that on ravb_start_xmit().
    
    To fix the issue, the ravb_tx_timeout_work() should check
    the return values of ravb_stop_dma() and ravb_dmac_init().
    If ravb_stop_dma() fails, ravb_tx_timeout_work() re-enables TX and RX
    and just exits. If ravb_dmac_init() fails, just exits.
    
    [1]
    https://lore.kernel.org/linux-renesas-soc/20200518045452.2390-1-dirk.behme@de.bosch.com/
    
    Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac7c3b8f34ec6bad54f83ccb2ecf86a6f82d5fdc
Author: Liam Beguin <liambeguin@gmail.com>
Date:   Sat Jul 18 16:10:21 2020 -0400

    parisc: add support for cmpxchg on u8 pointers
    
    [ Upstream commit b344d6a83d01c52fddbefa6b3b4764da5b1022a0 ]
    
    The kernel test bot reported[1] that using set_mask_bits on a u8 causes
    the following issue on parisc:
    
            hppa-linux-ld: drivers/phy/ti/phy-tusb1210.o: in function `tusb1210_probe':
            >> (.text+0x2f4): undefined reference to `__cmpxchg_called_with_bad_pointer'
            >> hppa-linux-ld: (.text+0x324): undefined reference to `__cmpxchg_called_with_bad_pointer'
            hppa-linux-ld: (.text+0x354): undefined reference to `__cmpxchg_called_with_bad_pointer'
    
    Add support for cmpxchg on u8 pointers.
    
    [1] https://lore.kernel.org/patchwork/patch/1272617/#1468946
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Liam Beguin <liambeguin@gmail.com>
    Tested-by: Dave Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a0ba41317c893ad29293a1503d7e5ea635d4a249
Author: Ming Lei <ming.lei@redhat.com>
Date:   Mon Jul 20 10:54:35 2020 +0800

    scsi: core: Run queue in case of I/O resource contention failure
    
    [ Upstream commit 3f0dcfbcd2e162fc0a11c1f59b7acd42ee45f126 ]
    
    I/O requests may be held in scheduler queue because of resource contention.
    The starvation scenario was handled properly in the regular completion
    path but we failed to account for it during I/O submission. This lead to
    the hang captured below. Make sure we run the queue when resource
    contention is encountered in the submission path.
    
    [   39.054963] scsi 13:0:0:0: rejecting I/O to dead device
    [   39.058700] scsi 13:0:0:0: rejecting I/O to dead device
    [   39.087855] sd 13:0:0:1: [sdd] Synchronizing SCSI cache
    [   39.088909] scsi 13:0:0:1: rejecting I/O to dead device
    [   39.095351] scsi 13:0:0:1: rejecting I/O to dead device
    [   39.096962] scsi 13:0:0:1: rejecting I/O to dead device
    [  247.021859] INFO: task scsi-stress-rem:813 blocked for more than 122 seconds.
    [  247.023258]       Not tainted 5.8.0-rc2 #8
    [  247.024069] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [  247.025331] scsi-stress-rem D    0   813    802 0x00004000
    [  247.025334] Call Trace:
    [  247.025354]  __schedule+0x504/0x55f
    [  247.027987]  schedule+0x72/0xa8
    [  247.027991]  blk_mq_freeze_queue_wait+0x63/0x8c
    [  247.027994]  ? do_wait_intr_irq+0x7a/0x7a
    [  247.027996]  blk_cleanup_queue+0x4b/0xc9
    [  247.028000]  __scsi_remove_device+0xf6/0x14e
    [  247.028002]  scsi_remove_device+0x21/0x2b
    [  247.029037]  sdev_store_delete+0x58/0x7c
    [  247.029041]  kernfs_fop_write+0x10d/0x14f
    [  247.031281]  vfs_write+0xa2/0xdf
    [  247.032670]  ksys_write+0x6b/0xb3
    [  247.032673]  do_syscall_64+0x56/0x82
    [  247.034053]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  247.034059] RIP: 0033:0x7f69f39e9008
    [  247.036330] Code: Bad RIP value.
    [  247.036331] RSP: 002b:00007ffdd8116498 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [  247.037613] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f69f39e9008
    [  247.039714] RDX: 0000000000000002 RSI: 000055cde92a0ab0 RDI: 0000000000000001
    [  247.039715] RBP: 000055cde92a0ab0 R08: 000000000000000a R09: 00007f69f3a79e80
    [  247.039716] R10: 000000000000000a R11: 0000000000000246 R12: 00007f69f3abb780
    [  247.039717] R13: 0000000000000002 R14: 00007f69f3ab6740 R15: 0000000000000002
    
    Link: https://lore.kernel.org/r/20200720025435.812030-1-ming.lei@redhat.com
    Cc: linux-block@vger.kernel.org
    Cc: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ac155dcf048d97738cefbfbcff66dfb9c8e46d3
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Sat Jul 18 00:31:49 2020 -0500

    nfc: s3fwrn5: add missing release on skb in s3fwrn5_recv_frame
    
    [ Upstream commit 1e8fd3a97f2d83a7197876ceb4f37b4c2b00a0f3 ]
    
    The implementation of s3fwrn5_recv_frame() is supposed to consume skb on
    all execution paths. Release skb before returning -ENODEV.
    
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50c5f89637bc1301c90eda92b748a1f84dbb3637
Author: Paolo Pisati <paolo.pisati@canonical.com>
Date:   Thu Jul 16 17:51:14 2020 +0200

    selftests: net: ip_defrag: modprobe missing nf_defrag_ipv6 support
    
    [ Upstream commit aba69d49fb49c9166596dd78926514173b7f9ab5 ]
    
    Fix ip_defrag.sh when CONFIG_NF_DEFRAG_IPV6=m:
    
    $ sudo ./ip_defrag.sh
    + set -e
    + mktemp -u XXXXXX
    + readonly NETNS=ns-rGlXcw
    + trap cleanup EXIT
    + setup
    + ip netns add ns-rGlXcw
    + ip -netns ns-rGlXcw link set lo up
    + ip netns exec ns-rGlXcw sysctl -w net.ipv4.ipfrag_high_thresh=9000000
    + ip netns exec ns-rGlXcw sysctl -w net.ipv4.ipfrag_low_thresh=7000000
    + ip netns exec ns-rGlXcw sysctl -w net.ipv4.ipfrag_time=1
    + ip netns exec ns-rGlXcw sysctl -w net.ipv6.ip6frag_high_thresh=9000000
    + ip netns exec ns-rGlXcw sysctl -w net.ipv6.ip6frag_low_thresh=7000000
    + ip netns exec ns-rGlXcw sysctl -w net.ipv6.ip6frag_time=1
    + ip netns exec ns-rGlXcw sysctl -w net.netfilter.nf_conntrack_frag6_high_thresh=9000000
    + cleanup
    + ip netns del ns-rGlXcw
    
    $ ls -la /proc/sys/net/netfilter/nf_conntrack_frag6_high_thresh
    ls: cannot access '/proc/sys/net/netfilter/nf_conntrack_frag6_high_thresh': No such file or directory
    
    $ sudo modprobe nf_defrag_ipv6
    $ ls -la /proc/sys/net/netfilter/nf_conntrack_frag6_high_thresh
    -rw-r--r-- 1 root root 0 Jul 14 12:34 /proc/sys/net/netfilter/nf_conntrack_frag6_high_thresh
    
    Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
    Reviewed-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78c7532b80c6ca2d267cf0bf29d940a30b23e349
Author: Laurence Oberman <loberman@redhat.com>
Date:   Tue Jul 14 18:08:05 2020 -0400

    qed: Disable "MFW indication via attention" SPAM every 5 minutes
    
    [ Upstream commit 1d61e21852d3161f234b9656797669fe185c251b ]
    
    This is likely firmware causing this but its starting to annoy customers.
    Change the message level to verbose to prevent the spam.
    Note that this seems to only show up with ISCSI enabled on the HBA via the
    qedi driver.
    
    Signed-off-by: Laurence Oberman <loberman@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e4620df9cbcd72c4faf24273fff417fc4ee3dfb
Author: Paolo Pisati <paolo.pisati@canonical.com>
Date:   Tue Jul 14 17:40:55 2020 +0200

    selftests: fib_nexthop_multiprefix: fix cleanup() netns deletion
    
    [ Upstream commit 651149f60376758a4759f761767965040f9e4464 ]
    
    During setup():
    ...
            for ns in h0 r1 h1 h2 h3
            do
                    create_ns ${ns}
            done
    ...
    
    while in cleanup():
    ...
            for n in h1 r1 h2 h3 h4
            do
                    ip netns del ${n} 2>/dev/null
            done
    ...
    
    and after removing the stderr redirection in cleanup():
    
    $ sudo ./fib_nexthop_multiprefix.sh
    ...
    TEST: IPv4: host 0 to host 3, mtu 1400                              [ OK ]
    TEST: IPv6: host 0 to host 3, mtu 1400                              [ OK ]
    Cannot remove namespace file "/run/netns/h4": No such file or directory
    $ echo $?
    1
    
    and a non-zero return code, make kselftests fail (even if the test
    itself is fine):
    
    ...
    not ok 34 selftests: net: fib_nexthop_multiprefix.sh # exit=1
    ...
    
    Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
    Reviewed-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b235c1d90225d1422911a7e4d97fa5be8f987d1
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Mon Jul 13 13:05:13 2020 +0200

    usb: hso: Fix debug compile warning on sparc32
    
    [ Upstream commit e0484010ec05191a8edf980413fc92f28050c1cc ]
    
    On sparc32, tcflag_t is "unsigned long", unlike on all other
    architectures, where it is "unsigned int":
    
        drivers/net/usb/hso.c: In function ‘hso_serial_set_termios’:
        include/linux/kern_levels.h:5:18: warning: format ‘%d’ expects argument of type ‘unsigned int’, but argument 4 has type ‘tcflag_t {aka long unsigned int}’ [-Wformat=]
        drivers/net/usb/hso.c:1393:3: note: in expansion of macro ‘hso_dbg’
           hso_dbg(0x16, "Termios called with: cflags new[%d] - old[%d]\n",
           ^~~~~~~
        include/linux/kern_levels.h:5:18: warning: format ‘%d’ expects argument of type ‘unsigned int’, but argument 5 has type ‘tcflag_t {aka long unsigned int}’ [-Wformat=]
        drivers/net/usb/hso.c:1393:3: note: in expansion of macro ‘hso_dbg’
           hso_dbg(0x16, "Termios called with: cflags new[%d] - old[%d]\n",
           ^~~~~~~
    
    As "unsigned long" is 32-bit on sparc32, fix this by casting all tcflag_t
    parameters to "unsigned int".
    While at it, use "%u" to format unsigned numbers.
    
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cac2b7ad091562ab873642b4181c8457c1b39a15
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Sat Aug 1 07:07:50 2020 +0000

    vxlan: fix memleak of fdb
    
    [ Upstream commit fda2ec62cf1aa7cbee52289dc8059cd3662795da ]
    
    When vxlan interface is deleted, all fdbs are deleted by vxlan_flush().
    vxlan_flush() flushes fdbs but it doesn't delete fdb, which contains
    all-zeros-mac because it is deleted by vxlan_uninit().
    But vxlan_uninit() deletes only the fdb, which contains both all-zeros-mac
    and default vni.
    So, the fdb, which contains both all-zeros-mac and non-default vni
    will not be deleted.
    
    Test commands:
        ip link add vxlan0 type vxlan dstport 4789 external
        ip link set vxlan0 up
        bridge fdb add to 00:00:00:00:00:00 dst 172.0.0.1 dev vxlan0 via lo \
                src_vni 10000 self permanent
        ip link del vxlan0
    
    kmemleak reports as follows:
    unreferenced object 0xffff9486b25ced88 (size 96):
      comm "bridge", pid 2151, jiffies 4294701712 (age 35506.901s)
      hex dump (first 32 bytes):
        02 00 00 00 ac 00 00 01 40 00 09 b1 86 94 ff ff  ........@.......
        46 02 00 00 00 00 00 00 a7 03 00 00 12 b5 6a 6b  F.............jk
      backtrace:
        [<00000000c10cf651>] vxlan_fdb_append.part.51+0x3c/0xf0 [vxlan]
        [<000000006b31a8d9>] vxlan_fdb_create+0x184/0x1a0 [vxlan]
        [<0000000049399045>] vxlan_fdb_update+0x12f/0x220 [vxlan]
        [<0000000090b1ef00>] vxlan_fdb_add+0x12a/0x1b0 [vxlan]
        [<0000000056633c2c>] rtnl_fdb_add+0x187/0x270
        [<00000000dd5dfb6b>] rtnetlink_rcv_msg+0x264/0x490
        [<00000000fc44dd54>] netlink_rcv_skb+0x4a/0x110
        [<00000000dff433e7>] netlink_unicast+0x18e/0x250
        [<00000000b87fb421>] netlink_sendmsg+0x2e9/0x400
        [<000000002ed55153>] ____sys_sendmsg+0x237/0x260
        [<00000000faa51c66>] ___sys_sendmsg+0x88/0xd0
        [<000000006c3982f1>] __sys_sendmsg+0x4e/0x80
        [<00000000a8f875d2>] do_syscall_64+0x56/0xe0
        [<000000003610eefa>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    unreferenced object 0xffff9486b1c40080 (size 128):
      comm "bridge", pid 2157, jiffies 4294701754 (age 35506.866s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 f8 dc 42 b2 86 94 ff ff  ..........B.....
        6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
      backtrace:
        [<00000000a2981b60>] vxlan_fdb_create+0x67/0x1a0 [vxlan]
        [<0000000049399045>] vxlan_fdb_update+0x12f/0x220 [vxlan]
        [<0000000090b1ef00>] vxlan_fdb_add+0x12a/0x1b0 [vxlan]
        [<0000000056633c2c>] rtnl_fdb_add+0x187/0x270
        [<00000000dd5dfb6b>] rtnetlink_rcv_msg+0x264/0x490
        [<00000000fc44dd54>] netlink_rcv_skb+0x4a/0x110
        [<00000000dff433e7>] netlink_unicast+0x18e/0x250
        [<00000000b87fb421>] netlink_sendmsg+0x2e9/0x400
        [<000000002ed55153>] ____sys_sendmsg+0x237/0x260
        [<00000000faa51c66>] ___sys_sendmsg+0x88/0xd0
        [<000000006c3982f1>] __sys_sendmsg+0x4e/0x80
        [<00000000a8f875d2>] do_syscall_64+0x56/0xe0
        [<000000003610eefa>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 3ad7a4b141eb ("vxlan: support fdb and learning in COLLECT_METADATA mode")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1df0000b30cd25e23fdd1e0a6c5987cd0b3213c7
Author: Wei Li <liwei391@huawei.com>
Date:   Fri Jul 24 15:11:10 2020 +0800

    perf tools: Fix record failure when mixed with ARM SPE event
    
    [ Upstream commit bd3c628f8fafa6cbd6a1ca440034b841f0080160 ]
    
    When recording with cache-misses and arm_spe_x event, I found that it
    will just fail without showing any error info if i put cache-misses
    after 'arm_spe_x' event.
    
      [root@localhost 0620]# perf record -e cache-misses \
                                    -e arm_spe_0/ts_enable=1,pct_enable=1,pa_enable=1,load_filter=1,jitter=1,store_filter=1,min_latency=0/ sleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.067 MB perf.data ]
      [root@localhost 0620]#
      [root@localhost 0620]# perf record -e arm_spe_0/ts_enable=1,pct_enable=1,pa_enable=1,load_filter=1,jitter=1,store_filter=1,min_latency=0/ \
                                         -e  cache-misses sleep 1
      [root@localhost 0620]#
    
    The current code can only work if the only event to be traced is an
    'arm_spe_x', or if it is the last event to be specified. Otherwise the
    last event type will be checked against all the arm_spe_pmus[i]->types,
    none will match and an out of bound 'i' index will be used in
    arm_spe_recording_init().
    
    We don't support concurrent multiple arm_spe_x events currently, that
    is checked in arm_spe_recording_options(), and it will show the relevant
    info. So add the check and record of the first found 'arm_spe_pmu' to
    fix this issue here.
    
    Fixes: ffd3d18c20b8 ("perf tools: Add ARM Statistical Profiling Extensions (SPE) support")
    Signed-off-by: Wei Li <liwei391@huawei.com>
    Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Tested-by-by: Leo Yan <leo.yan@linaro.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Hanjun Guo <guohanjun@huawei.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Kim Phillips <kim.phillips@arm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Link: http://lore.kernel.org/lkml/20200724071111.35593-2-liwei391@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 568995fb61e7f1d0484148c2475e9c4716c2abd5
Author: Xin Xiong <xiongx18@fudan.edu.cn>
Date:   Thu Jul 30 18:29:41 2020 +0800

    net/mlx5e: fix bpf_prog reference count leaks in mlx5e_alloc_rq
    
    [ Upstream commit e692139e6af339a1495ef401b2d95f7f9d1c7a44 ]
    
    The function invokes bpf_prog_inc(), which increases the reference
    count of a bpf_prog object "rq->xdp_prog" if the object isn't NULL.
    
    The refcount leak issues take place in two error handling paths. When
    either mlx5_wq_ll_create() or mlx5_wq_cyc_create() fails, the function
    simply returns the error code and forgets to drop the reference count
    increased earlier, causing a reference count leak of "rq->xdp_prog".
    
    Fix this issue by jumping to the error handling path err_rq_wq_destroy
    while either function fails.
    
    Fixes: 422d4c401edd ("net/mlx5e: RX, Split WQ objects for different RQ types")
    Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
    Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e68b7b9b03fb4a4a33abf830e50ec8a0e58e7f3c
Author: Wang Hai <wanghai38@huawei.com>
Date:   Thu Jul 30 15:30:00 2020 +0800

    net: gemini: Fix missing clk_disable_unprepare() in error path of gemini_ethernet_port_probe()
    
    [ Upstream commit 85496a29224188051b6135eb38da8afd4c584765 ]
    
    Fix the missing clk_disable_unprepare() before return
    from gemini_ethernet_port_probe() in the error handling case.
    
    Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1158aa743a0b871ed2f827bbdf827a78855c5eb4
Author: Lu Wei <luwei32@huawei.com>
Date:   Wed Jul 29 11:50:05 2020 +0800

    net: nixge: fix potential memory leak in nixge_probe()
    
    [ Upstream commit 366228ed01f6882cc203e3d5b40010dfae0be1c3 ]
    
    If some processes in nixge_probe() fail, free_netdev(dev)
    needs to be called to aviod a memory leak.
    
    Fixes: 87ab207981ec ("net: nixge: Separate ctrl and dma resources")
    Fixes: abcd3d6fc640 ("net: nixge: Fix error path for obtaining mac address")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Lu Wei <luwei32@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9acd96f14a49f59401478eefe158aec489e0161f
Author: Alain Michaud <alainm@chromium.org>
Date:   Mon Jul 27 20:48:55 2020 +0000

    Bluetooth: fix kernel oops in store_pending_adv_report
    
    [ Upstream commit a2ec905d1e160a33b2e210e45ad30445ef26ce0e ]
    
    Fix kernel oops observed when an ext adv data is larger than 31 bytes.
    
    This can be reproduced by setting up an advertiser with advertisement
    larger than 31 bytes.  The issue is not sensitive to the advertisement
    content.  In particular, this was reproduced with an advertisement of
    229 bytes filled with 'A'.  See stack trace below.
    
    This is fixed by not catching ext_adv as legacy adv are only cached to
    be able to concatenate a scanable adv with its scan response before
    sending it up through mgmt.
    
    With ext_adv, this is no longer necessary.
    
      general protection fault: 0000 [#1] SMP PTI
      CPU: 6 PID: 205 Comm: kworker/u17:0 Not tainted 5.4.0-37-generic #41-Ubuntu
      Hardware name: Dell Inc. XPS 15 7590/0CF6RR, BIOS 1.7.0 05/11/2020
      Workqueue: hci0 hci_rx_work [bluetooth]
      RIP: 0010:hci_bdaddr_list_lookup+0x1e/0x40 [bluetooth]
      Code: ff ff e9 26 ff ff ff 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 07 48 89 e5 48 39 c7 75 0a eb 24 48 8b 00 48 39 f8 74 1c 44 8b 06 <44> 39 40 10 75 ef 44 0f b7 4e 04 66 44 39 48 14 75 e3 38 50 16 75
      RSP: 0018:ffffbc6a40493c70 EFLAGS: 00010286
      RAX: 4141414141414141 RBX: 000000000000001b RCX: 0000000000000000
      RDX: 0000000000000000 RSI: ffff9903e76c100f RDI: ffff9904289d4b28
      RBP: ffffbc6a40493c70 R08: 0000000093570362 R09: 0000000000000000
      R10: 0000000000000000 R11: ffff9904344eae38 R12: ffff9904289d4000
      R13: 0000000000000000 R14: 00000000ffffffa3 R15: ffff9903e76c100f
      FS: 0000000000000000(0000) GS:ffff990434580000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007feed125a000 CR3: 00000001b860a003 CR4: 00000000003606e0
      Call Trace:
        process_adv_report+0x12e/0x560 [bluetooth]
        hci_le_meta_evt+0x7b2/0xba0 [bluetooth]
        hci_event_packet+0x1c29/0x2a90 [bluetooth]
        hci_rx_work+0x19b/0x360 [bluetooth]
        process_one_work+0x1eb/0x3b0
        worker_thread+0x4d/0x400
        kthread+0x104/0x140
    
    Fixes: c215e9397b00 ("Bluetooth: Process extended ADV report event")
    Reported-by: Andy Nguyen <theflow@google.com>
    Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
    Reported-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
    Signed-off-by: Alain Michaud <alainm@chromium.org>
    Tested-by: Sonny Sasaka <sonnysasaka@chromium.org>
    Acked-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3bb2f52ad9e74f3de153ca2a51c3d6fbe4dcf160
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Thu Jul 30 10:56:49 2020 +0100

    arm64: csum: Fix handling of bad packets
    
    [ Upstream commit 05fb3dbda187bbd9cc1cd0e97e5d6595af570ac6 ]
    
    Although iph is expected to point to at least 20 bytes of valid memory,
    ihl may be bogus, for example on reception of a corrupt packet. If it
    happens to be less than 5, we really don't want to run away and
    dereference 16GB worth of memory until it wraps back to exactly zero...
    
    Fixes: 0e455d8e80aa ("arm64: Implement optimised IP checksum helpers")
    Reported-by: guodeqing <geffrey.guo@huawei.com>
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a90b436a0c9b7cebf024c5bb52f99821e305605
Author: Sami Tolvanen <samitolvanen@google.com>
Date:   Thu Jul 30 08:37:01 2020 -0700

    arm64/alternatives: move length validation inside the subsection
    
    [ Upstream commit 966a0acce2fca776391823381dba95c40e03c339 ]
    
    Commit f7b93d42945c ("arm64/alternatives: use subsections for replacement
    sequences") breaks LLVM's integrated assembler, because due to its
    one-pass design, it cannot compute instruction sequence lengths before the
    layout for the subsection has been finalized. This change fixes the build
    by moving the .org directives inside the subsection, so they are processed
    after the subsection layout is known.
    
    Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement sequences")
    Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1078
    Link: https://lore.kernel.org/r/20200730153701.3892953-1-samitolvanen@google.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a50753aacb52631d3d5dc6d39b1aacaa66dc9c6
Author: Remi Pommarel <repk@triplefau.lt>
Date:   Sat Jul 4 15:54:19 2020 +0200

    mac80211: mesh: Free pending skb when destroying a mpath
    
    [ Upstream commit 5e43540c2af0a0c0a18e39579b1ad49541f87506 ]
    
    A mpath object can hold reference on a list of skb that are waiting for
    mpath resolution to be sent. When destroying a mpath this skb list
    should be cleaned up in order to not leak memory.
    
    Fixing that kind of leak:
    
    unreferenced object 0xffff0000181c9300 (size 1088):
      comm "openvpn", pid 1782, jiffies 4295071698 (age 80.416s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 f9 80 36 00 00 00 00 00  ..........6.....
        02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
      backtrace:
        [<000000004bc6a443>] kmem_cache_alloc+0x1a4/0x2f0
        [<000000002caaef13>] sk_prot_alloc.isra.39+0x34/0x178
        [<00000000ceeaa916>] sk_alloc+0x34/0x228
        [<00000000ca1f1d04>] inet_create+0x198/0x518
        [<0000000035626b1c>] __sock_create+0x134/0x328
        [<00000000a12b3a87>] __sys_socket+0xb0/0x158
        [<00000000ff859f23>] __arm64_sys_socket+0x40/0x58
        [<00000000263486ec>] el0_svc_handler+0xd0/0x1a0
        [<0000000005b5157d>] el0_svc+0x8/0xc
    unreferenced object 0xffff000012973a40 (size 216):
      comm "openvpn", pid 1782, jiffies 4295082137 (age 38.660s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 c0 06 16 00 00 ff ff 00 93 1c 18 00 00 ff ff  ................
      backtrace:
        [<000000004bc6a443>] kmem_cache_alloc+0x1a4/0x2f0
        [<0000000023c8c8f9>] __alloc_skb+0xc0/0x2b8
        [<000000007ad950bb>] alloc_skb_with_frags+0x60/0x320
        [<00000000ef90023a>] sock_alloc_send_pskb+0x388/0x3c0
        [<00000000104fb1a3>] sock_alloc_send_skb+0x1c/0x28
        [<000000006919d2dd>] __ip_append_data+0xba4/0x11f0
        [<0000000083477587>] ip_make_skb+0x14c/0x1a8
        [<0000000024f3d592>] udp_sendmsg+0xaf0/0xcf0
        [<000000005aabe255>] inet_sendmsg+0x5c/0x80
        [<000000008651ea08>] __sys_sendto+0x15c/0x218
        [<000000003505c99b>] __arm64_sys_sendto+0x74/0x90
        [<00000000263486ec>] el0_svc_handler+0xd0/0x1a0
        [<0000000005b5157d>] el0_svc+0x8/0xc
    
    Fixes: 2bdaf386f99c (mac80211: mesh: move path tables into if_mesh)
    Signed-off-by: Remi Pommarel <repk@triplefau.lt>
    Link: https://lore.kernel.org/r/20200704135419.27703-1-repk@triplefau.lt
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f15e3e62c80e180282f0cbc5559264e11c328b7
Author: Remi Pommarel <repk@triplefau.lt>
Date:   Sat Jul 4 15:50:07 2020 +0200

    mac80211: mesh: Free ie data when leaving mesh
    
    [ Upstream commit 6a01afcf8468d3ca2bd8bbb27503f60dcf643b20 ]
    
    At ieee80211_join_mesh() some ie data could have been allocated (see
    copy_mesh_setup()) and need to be cleaned up when leaving the mesh.
    
    This fixes the following kmemleak report:
    
    unreferenced object 0xffff0000116bc600 (size 128):
      comm "wpa_supplicant", pid 608, jiffies 4294898983 (age 293.484s)
      hex dump (first 32 bytes):
        30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00  0...............
        00 0f ac 08 00 00 00 00 c4 65 40 00 00 00 00 00  .........e@.....
      backtrace:
        [<00000000bebe439d>] __kmalloc_track_caller+0x1c0/0x330
        [<00000000a349dbe1>] kmemdup+0x28/0x50
        [<0000000075d69baa>] ieee80211_join_mesh+0x6c/0x3b8 [mac80211]
        [<00000000683bb98b>] __cfg80211_join_mesh+0x1e8/0x4f0 [cfg80211]
        [<0000000072cb507f>] nl80211_join_mesh+0x520/0x6b8 [cfg80211]
        [<0000000077e9bcf9>] genl_family_rcv_msg+0x374/0x680
        [<00000000b1bd936d>] genl_rcv_msg+0x78/0x108
        [<0000000022c53788>] netlink_rcv_skb+0xb0/0x1c0
        [<0000000011af8ec9>] genl_rcv+0x34/0x48
        [<0000000069e41f53>] netlink_unicast+0x268/0x2e8
        [<00000000a7517316>] netlink_sendmsg+0x320/0x4c0
        [<0000000069cba205>] ____sys_sendmsg+0x354/0x3a0
        [<00000000e06bab0f>] ___sys_sendmsg+0xd8/0x120
        [<0000000037340728>] __sys_sendmsg+0xa4/0xf8
        [<000000004fed9776>] __arm64_sys_sendmsg+0x44/0x58
        [<000000001c1e5647>] el0_svc_handler+0xd0/0x1a0
    
    Fixes: c80d545da3f7 (mac80211: Let userspace enable and configure vendor specific path selection.)
    Signed-off-by: Remi Pommarel <repk@triplefau.lt>
    Link: https://lore.kernel.org/r/20200704135007.27292-1-repk@triplefau.lt
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe58e3dd6e119c6d41fd535429b0f1e83b5433d2
Author: Andrii Nakryiko <andriin@fb.com>
Date:   Tue Jul 28 21:09:12 2020 -0700

    bpf: Fix map leak in HASH_OF_MAPS map
    
    [ Upstream commit 1d4e1eab456e1ee92a94987499b211db05f900ea ]
    
    Fix HASH_OF_MAPS bug of not putting inner map pointer on bpf_map_elem_update()
    operation. This is due to per-cpu extra_elems optimization, which bypassed
    free_htab_elem() logic doing proper clean ups. Make sure that inner map is put
    properly in optimized case as well.
    
    Fixes: 8c290e60fa2a ("bpf: fix hashmap extra_elems logic")
    Signed-off-by: Andrii Nakryiko <andriin@fb.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/bpf/20200729040913.2815687-1-andriin@fb.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43c390b751ba49916c65308c582ae3f997148efe
Author: Thomas Falcon <tlfalcon@linux.ibm.com>
Date:   Wed Jul 29 16:36:32 2020 -0500

    ibmvnic: Fix IRQ mapping disposal in error path
    
    [ Upstream commit 27a2145d6f826d1fad9de06ac541b1016ced3427 ]
    
    RX queue IRQ mappings are disposed in both the TX IRQ and RX IRQ
    error paths. Fix this and dispose of TX IRQ mappings correctly in
    case of an error.
    
    Fixes: ea22d51a7831 ("ibmvnic: simplify and improve driver probe function")
    Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea559138b33151e9aa60142487f57d08dc2aede9
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Wed Jul 29 12:26:46 2020 +0300

    mlxsw: core: Free EMAD transactions using kfree_rcu()
    
    [ Upstream commit 3c8ce24b037648a5a15b85888b259a74b05ff97d ]
    
    The lifetime of EMAD transactions (i.e., 'struct mlxsw_reg_trans') is
    managed using RCU. They are freed using kfree_rcu() once the transaction
    ends.
    
    However, in case the transaction failed it is freed immediately after being
    removed from the active transactions list. This is problematic because it is
    still possible for a different CPU to dereference the transaction from an RCU
    read-side critical section while traversing the active transaction list in
    mlxsw_emad_rx_listener_func(). In which case, a use-after-free is triggered
    [1].
    
    Fix this by freeing the transaction after a grace period by calling
    kfree_rcu().
    
    [1]
    BUG: KASAN: use-after-free in mlxsw_emad_rx_listener_func+0x969/0xac0 drivers/net/ethernet/mellanox/mlxsw/core.c:671
    Read of size 8 at addr ffff88800b7964e8 by task syz-executor.2/2881
    
    CPU: 0 PID: 2881 Comm: syz-executor.2 Not tainted 5.8.0-rc4+ #44
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
    Call Trace:
     <IRQ>
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0xf6/0x16e lib/dump_stack.c:118
     print_address_description.constprop.0+0x1c/0x250 mm/kasan/report.c:383
     __kasan_report mm/kasan/report.c:513 [inline]
     kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
     mlxsw_emad_rx_listener_func+0x969/0xac0 drivers/net/ethernet/mellanox/mlxsw/core.c:671
     mlxsw_core_skb_receive+0x571/0x700 drivers/net/ethernet/mellanox/mlxsw/core.c:2061
     mlxsw_pci_cqe_rdq_handle drivers/net/ethernet/mellanox/mlxsw/pci.c:595 [inline]
     mlxsw_pci_cq_tasklet+0x12a6/0x2520 drivers/net/ethernet/mellanox/mlxsw/pci.c:651
     tasklet_action_common.isra.0+0x13f/0x3e0 kernel/softirq.c:550
     __do_softirq+0x223/0x964 kernel/softirq.c:292
     asm_call_on_stack+0x12/0x20 arch/x86/entry/entry_64.S:711
     </IRQ>
     __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
     run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
     do_softirq_own_stack+0x109/0x140 arch/x86/kernel/irq_64.c:77
     invoke_softirq kernel/softirq.c:387 [inline]
     __irq_exit_rcu kernel/softirq.c:417 [inline]
     irq_exit_rcu+0x16f/0x1a0 kernel/softirq.c:429
     sysvec_apic_timer_interrupt+0x4e/0xd0 arch/x86/kernel/apic/apic.c:1091
     asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:587
    RIP: 0010:arch_local_irq_restore arch/x86/include/asm/irqflags.h:85 [inline]
    RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 [inline]
    RIP: 0010:_raw_spin_unlock_irqrestore+0x3b/0x40 kernel/locking/spinlock.c:191
    Code: e8 2a c3 f4 fc 48 89 ef e8 12 96 f5 fc f6 c7 02 75 11 53 9d e8 d6 db 11 fd 65 ff 0d 1f 21 b3 56 5b 5d c3 e8 a7 d7 11 fd 53 9d <eb> ed 0f 1f 00 55 48 89 fd 65 ff 05 05 21 b3 56 ff 74 24 08 48 8d
    RSP: 0018:ffff8880446ffd80 EFLAGS: 00000286
    RAX: 0000000000000006 RBX: 0000000000000286 RCX: 0000000000000006
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffa94ecea9
    RBP: ffff888012934408 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000001 R11: fffffbfff57be301 R12: 1ffff110088dffc1
    R13: ffff888037b817c0 R14: ffff88802442415a R15: ffff888024424000
     __do_sys_perf_event_open+0x1b5d/0x2bd0 kernel/events/core.c:11874
     do_syscall_64+0x56/0xa0 arch/x86/entry/common.c:384
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    RIP: 0033:0x473dbd
    Code: Bad RIP value.
    RSP: 002b:00007f21e5e9cc28 EFLAGS: 00000246 ORIG_RAX: 000000000000012a
    RAX: ffffffffffffffda RBX: 000000000057bf00 RCX: 0000000000473dbd
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000040
    RBP: 000000000057bf00 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000003 R11: 0000000000000246 R12: 000000000057bf0c
    R13: 00007ffd0493503f R14: 00000000004d0f46 R15: 00007f21e5e9cd80
    
    Allocated by task 871:
     save_stack+0x1b/0x40 mm/kasan/common.c:48
     set_track mm/kasan/common.c:56 [inline]
     __kasan_kmalloc mm/kasan/common.c:494 [inline]
     __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:467
     kmalloc include/linux/slab.h:555 [inline]
     kzalloc include/linux/slab.h:669 [inline]
     mlxsw_core_reg_access_emad+0x70/0x1410 drivers/net/ethernet/mellanox/mlxsw/core.c:1812
     mlxsw_core_reg_access+0xeb/0x540 drivers/net/ethernet/mellanox/mlxsw/core.c:1991
     mlxsw_sp_port_get_hw_xstats+0x335/0x7e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1130
     update_stats_cache+0xf4/0x140 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1173
     process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
     worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
     kthread+0x355/0x470 kernel/kthread.c:291
     ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293
    
    Freed by task 871:
     save_stack+0x1b/0x40 mm/kasan/common.c:48
     set_track mm/kasan/common.c:56 [inline]
     kasan_set_free_info mm/kasan/common.c:316 [inline]
     __kasan_slab_free+0x12c/0x170 mm/kasan/common.c:455
     slab_free_hook mm/slub.c:1474 [inline]
     slab_free_freelist_hook mm/slub.c:1507 [inline]
     slab_free mm/slub.c:3072 [inline]
     kfree+0xe6/0x320 mm/slub.c:4052
     mlxsw_core_reg_access_emad+0xd45/0x1410 drivers/net/ethernet/mellanox/mlxsw/core.c:1819
     mlxsw_core_reg_access+0xeb/0x540 drivers/net/ethernet/mellanox/mlxsw/core.c:1991
     mlxsw_sp_port_get_hw_xstats+0x335/0x7e0 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1130
     update_stats_cache+0xf4/0x140 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:1173
     process_one_work+0xa3e/0x17a0 kernel/workqueue.c:2269
     worker_thread+0x9e/0x1050 kernel/workqueue.c:2415
     kthread+0x355/0x470 kernel/kthread.c:291
     ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:293
    
    The buggy address belongs to the object at ffff88800b796400
     which belongs to the cache kmalloc-512 of size 512
    The buggy address is located 232 bytes inside of
     512-byte region [ffff88800b796400, ffff88800b796600)
    The buggy address belongs to the page:
    page:ffffea00002de500 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 head:ffffea00002de500 order:2 compound_mapcount:0 compound_pincount:0
    flags: 0x100000000010200(slab|head)
    raw: 0100000000010200 dead000000000100 dead000000000122 ffff88806c402500
    raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff88800b796380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff88800b796400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff88800b796480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                              ^
     ffff88800b796500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88800b796580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    Fixes: caf7297e7ab5 ("mlxsw: core: Introduce support for asynchronous EMAD register access")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reviewed-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57f498ced73160972866120ce3b021218353e0d4
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Wed Jul 29 12:26:45 2020 +0300

    mlxsw: core: Increase scope of RCU read-side critical section
    
    [ Upstream commit 7d8e8f3433dc8d1dc87c1aabe73a154978fb4c4d ]
    
    The lifetime of the Rx listener item ('rxl_item') is managed using RCU,
    but is dereferenced outside of RCU read-side critical section, which can
    lead to a use-after-free.
    
    Fix this by increasing the scope of the RCU read-side critical section.
    
    Fixes: 93c1edb27f9e ("mlxsw: Introduce Mellanox switch driver core")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reviewed-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f424eda470530a070fb0a4e9e868770022f3c86
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Fri Jul 24 16:15:43 2020 -0700

    mlx4: disable device on shutdown
    
    [ Upstream commit 3cab8c65525920f00d8f4997b3e9bb73aecb3a8e ]
    
    It appears that not disabling a PCI device on .shutdown may lead to
    a Hardware Error with particular (perhaps buggy) BIOS versions:
    
        mlx4_en: eth0: Close port called
        mlx4_en 0000:04:00.0: removed PHC
        reboot: Restarting system
        {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
        {1}[Hardware Error]: event severity: fatal
        {1}[Hardware Error]:  Error 0, type: fatal
        {1}[Hardware Error]:   section_type: PCIe error
        {1}[Hardware Error]:   port_type: 4, root port
        {1}[Hardware Error]:   version: 1.16
        {1}[Hardware Error]:   command: 0x4010, status: 0x0143
        {1}[Hardware Error]:   device_id: 0000:00:02.2
        {1}[Hardware Error]:   slot: 0
        {1}[Hardware Error]:   secondary_bus: 0x04
        {1}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x2f06
        {1}[Hardware Error]:   class_code: 000604
        {1}[Hardware Error]:   bridge: secondary_status: 0x2000, control: 0x0003
        {1}[Hardware Error]:   aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00000000
        {1}[Hardware Error]:   aer_uncor_severity: 0x00062030
        {1}[Hardware Error]:   TLP Header: 40000018 040000ff 791f4080 00000000
    [hw error repeats]
        Kernel panic - not syncing: Fatal hardware error!
        CPU: 0 PID: 2189 Comm: reboot Kdump: loaded Not tainted 5.6.x-blabla #1
        Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 05/05/2017
    
    Fix the mlx4 driver.
    
    This is a very similar problem to what had been fixed in:
    commit 0d98ba8d70b0 ("scsi: hpsa: disable device during shutdown")
    to address https://bugzilla.kernel.org/show_bug.cgi?id=199779.
    
    Fixes: 2ba5fbd62b25 ("net/mlx4_core: Handle AER flow properly")
    Reported-by: Jake Lawrence <lawja@fb.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3883876d3f154d4eb3c9a4406c0489996806e0d
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Jul 24 20:12:53 2020 +1000

    rhashtable: Fix unprotected RCU dereference in __rht_ptr
    
    [ Upstream commit 1748f6a2cbc4694523f16da1c892b59861045b9d ]
    
    The rcu_dereference call in rht_ptr_rcu is completely bogus because
    we've already dereferenced the value in __rht_ptr and operated on it.
    This causes potential double readings which could be fatal.  The RCU
    dereference must occur prior to the comparison in __rht_ptr.
    
    This patch changes the order of RCU dereference so that it is done
    first and the result is then fed to __rht_ptr.  The RCU marking
    changes have been minimised using casts which will be removed in
    a follow-up patch.
    
    Fixes: ba6306e3f648 ("rhashtable: Remove RCU marking from...")
    Reported-by: "Gong, Sishuai" <sishuai@purdue.edu>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1d629d329107a499798037982156fd5457b3a44
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jul 28 14:10:30 2020 +0200

    net: lan78xx: fix transfer-buffer memory leak
    
    [ Upstream commit 63634aa679ba8b5e306ad0727120309ae6ba8a8e ]
    
    The interrupt URB transfer-buffer was never freed on disconnect or after
    probe errors.
    
    Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
    Cc: Woojung.Huh@microchip.com <Woojung.Huh@microchip.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9db3040eb952550538b1ec65d20eb99490e73352
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jul 28 14:10:29 2020 +0200

    net: lan78xx: add missing endpoint sanity check
    
    [ Upstream commit 8d8e95fd6d69d774013f51e5f2ee10c6e6d1fc14 ]
    
    Add the missing endpoint sanity check to prevent a NULL-pointer
    dereference should a malicious device lack the expected endpoints.
    
    Note that the driver has a broken endpoint-lookup helper,
    lan78xx_get_endpoints(), which can end up accepting interfaces in an
    altsetting without endpoints as long as *some* altsetting has a bulk-in
    and a bulk-out endpoint.
    
    Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
    Cc: Woojung.Huh@microchip.com <Woojung.Huh@microchip.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32ec4441cca199525b3f23b2d99e750329d25778
Author: Alaa Hleihel <alaa@mellanox.com>
Date:   Wed Jul 15 11:46:30 2020 +0300

    net/mlx5e: Fix kernel crash when setting vf VLANID on a VF dev
    
    [ Upstream commit 350a63249d270b1f5bd05c7e2a24cd8de0f9db20 ]
    
    After the cited commit, function 'mlx5_eswitch_set_vport_vlan' started
    to acquire esw->state_lock.
    However, esw is not defined for VF devices, hence attempting to set vf
    VLANID on a VF dev will cause a kernel panic.
    
    Fix it by moving up the (redundant) esw validation from function
    '__mlx5_eswitch_set_vport_vlan' since the rest of the callers now have
    and use a valid esw.
    
    For example with vf device eth4:
     # ip link set dev eth4 vf 0 vlan 0
    
    Trace of the panic:
     [  411.409842] BUG: unable to handle page fault for address: 00000000000011b8
     [  411.449745] #PF: supervisor read access in kernel mode
     [  411.452348] #PF: error_code(0x0000) - not-present page
     [  411.454938] PGD 80000004189c9067 P4D 80000004189c9067 PUD 41899a067 PMD 0
     [  411.458382] Oops: 0000 [#1] SMP PTI
     [  411.460268] CPU: 4 PID: 5711 Comm: ip Not tainted 5.8.0-rc4_for_upstream_min_debug_2020_07_08_22_04 #1
     [  411.462447] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
     [  411.464158] RIP: 0010:__mutex_lock+0x4e/0x940
     [  411.464928] Code: fd 41 54 49 89 f4 41 52 53 89 d3 48 83 ec 70 44 8b 1d ee 03 b0 01 65 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 45 85 db 75 0a <48> 3b 7f 60 0f 85 7e 05 00 00 49 8d 45 68 41 56 41 b8 01 00 00 00
     [  411.467678] RSP: 0018:ffff88841fcd74b0 EFLAGS: 00010246
     [  411.468562] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
     [  411.469715] RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000001158
     [  411.470812] RBP: ffff88841fcd7550 R08: ffffffffa00fa1ce R09: 0000000000000000
     [  411.471835] R10: ffff88841fcd7570 R11: 0000000000000000 R12: 0000000000000002
     [  411.472862] R13: 0000000000001158 R14: ffffffffa00fa1ce R15: 0000000000000000
     [  411.474004] FS:  00007faee7ca6b80(0000) GS:ffff88846fc00000(0000) knlGS:0000000000000000
     [  411.475237] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     [  411.476129] CR2: 00000000000011b8 CR3: 000000041909c006 CR4: 0000000000360ea0
     [  411.477260] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     [  411.478340] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
     [  411.479332] Call Trace:
     [  411.479760]  ? __nla_validate_parse.part.6+0x57/0x8f0
     [  411.482825]  ? mlx5_eswitch_set_vport_vlan+0x3e/0xa0 [mlx5_core]
     [  411.483804]  mlx5_eswitch_set_vport_vlan+0x3e/0xa0 [mlx5_core]
     [  411.484733]  mlx5e_set_vf_vlan+0x41/0x50 [mlx5_core]
     [  411.485545]  do_setlink+0x613/0x1000
     [  411.486165]  __rtnl_newlink+0x53d/0x8c0
     [  411.486791]  ? mark_held_locks+0x49/0x70
     [  411.487429]  ? __lock_acquire+0x8fe/0x1eb0
     [  411.488085]  ? rcu_read_lock_sched_held+0x52/0x60
     [  411.488998]  ? kmem_cache_alloc_trace+0x16d/0x2d0
     [  411.489759]  rtnl_newlink+0x47/0x70
     [  411.490357]  rtnetlink_rcv_msg+0x24e/0x450
     [  411.490978]  ? netlink_deliver_tap+0x92/0x3d0
     [  411.491631]  ? validate_linkmsg+0x330/0x330
     [  411.492262]  netlink_rcv_skb+0x47/0x110
     [  411.492852]  netlink_unicast+0x1ac/0x270
     [  411.493551]  netlink_sendmsg+0x336/0x450
     [  411.494209]  sock_sendmsg+0x30/0x40
     [  411.494779]  ____sys_sendmsg+0x1dd/0x1f0
     [  411.495378]  ? copy_msghdr_from_user+0x5c/0x90
     [  411.496082]  ___sys_sendmsg+0x87/0xd0
     [  411.496683]  ? lock_acquire+0xb9/0x3a0
     [  411.497322]  ? lru_cache_add+0x5/0x170
     [  411.497944]  ? find_held_lock+0x2d/0x90
     [  411.498568]  ? handle_mm_fault+0xe46/0x18c0
     [  411.499205]  ? __sys_sendmsg+0x51/0x90
     [  411.499784]  __sys_sendmsg+0x51/0x90
     [  411.500341]  do_syscall_64+0x59/0x2e0
     [  411.500938]  ? asm_exc_page_fault+0x8/0x30
     [  411.501609]  ? rcu_read_lock_sched_held+0x52/0x60
     [  411.502350]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
     [  411.503093] RIP: 0033:0x7faee73b85a7
     [  411.503654] Code: Bad RIP value.
    
    Fixes: 0e18134f4f9f ("net/mlx5e: Eswitch, use state_lock to synchronize vlan change")
    Signed-off-by: Alaa Hleihel <alaa@mellanox.com>
    Reviewed-by: Roi Dayan <roid@mellanox.com>
    Reviewed-by: Vlad Buslov <vladbu@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 475cbcef491ace969e1ba7d30f4743f9840a5937
Author: Ron Diskin <rondi@mellanox.com>
Date:   Sun Apr 5 13:58:40 2020 +0300

    net/mlx5e: Modify uplink state on interface up/down
    
    [ Upstream commit 7d0314b11cdd92bca8b89684c06953bf114605fc ]
    
    When setting the PF interface up/down, notify the firmware to update
    uplink state via MODIFY_VPORT_STATE, when E-Switch is enabled.
    
    This behavior will prevent sending traffic out on uplink port when PF is
    down, such as sending traffic from a VF interface which is still up.
    Currently when calling mlx5e_open/close(), the driver only sends PAOS
    command to notify the firmware to set the physical port state to
    up/down, however, it is not sufficient. When VF is in "auto" state, it
    follows the uplink state, which was not updated on mlx5e_open/close()
    before this patch.
    
    When switchdev mode is enabled and uplink representor is first enabled,
    set the uplink port state value back to its FW default "AUTO".
    
    Fixes: 63bfd399de55 ("net/mlx5e: Send PAOS command on interface up/down")
    Signed-off-by: Ron Diskin <rondi@mellanox.com>
    Reviewed-by: Roi Dayan <roid@mellanox.com>
    Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43608372b84d7f0142ee8b2f56277a60f0f0a2a5
Author: Eran Ben Elisha <eranbe@mellanox.com>
Date:   Wed Jul 8 11:10:01 2020 +0300

    net/mlx5: Verify Hardware supports requested ptp function on a given pin
    
    [ Upstream commit 071995c877a8646209d55ff8edddd2b054e7424c ]
    
    Fix a bug where driver did not verify Hardware pin capabilities for
    PTP functions.
    
    Fixes: ee7f12205abc ("net/mlx5e: Implement 1PPS support")
    Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
    Reviewed-by: Ariel Levkovich <lariel@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8901896f69d4595952cbf43f3f61a4bd2ca198a6
Author: Aya Levin <ayal@mellanox.com>
Date:   Wed Jul 1 12:21:53 2020 +0300

    net/mlx5e: Fix error path of device attach
    
    [ Upstream commit 5cd39b6e9a420329a9a408894be7ba8aa7dd755e ]
    
    On failure to attach the netdev, fix the rollback by re-setting the
    device's state back to MLX5E_STATE_DESTROYING.
    
    Failing to attach doesn't stop statistics polling via .ndo_get_stats64.
    In this case, although the device is not attached, it falsely continues
    to query the firmware for counters. Setting the device's state back to
    MLX5E_STATE_DESTROYING prevents the firmware counters query.
    
    Fixes: 26e59d8077a3 ("net/mlx5e: Implement mlx5e interface attach/detach callbacks")
    Signed-off-by: Aya Levin <ayal@mellanox.com>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00bedd730d1f038911c607c4e559078bf214d6b9
Author: Parav Pandit <parav@mellanox.com>
Date:   Sat Jun 27 13:29:28 2020 +0300

    net/mlx5: E-switch, Destroy TSAR when fail to enable the mode
    
    [ Upstream commit 2b8e9c7c3fd0e31091edb1c66cc06ffe4988ca21 ]
    
    When either esw_legacy_enable() or esw_offloads_enable() fails,
    code missed to destroy the created TSAR.
    
    Hence, add the missing call to destroy the TSAR.
    
    Fixes: 610090ebce92 ("net/mlx5: E-switch, Initialize TSAR Qos hardware block before its user vports")
    Signed-off-by: Parav Pandit <parav@mellanox.com>
    Reviewed-by: Roi Dayan <roid@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d70f9a3cc32ca515de4048adb544c997af9f2250
Author: Guojia Liao <liaoguojia@huawei.com>
Date:   Tue Jul 28 10:16:51 2020 +0800

    net: hns3: fix aRFS FD rules leftover after add a user FD rule
    
    [ Upstream commit efe3fa45f770f1d66e2734ee7a3523c75694ff04 ]
    
    When user had created a FD rule, all the aRFS rules should be clear up.
    HNS3 process flow as below:
    1.get spin lock of fd_ruls_list
    2.clear up all aRFS rules
    3.release lock
    4.get spin lock of fd_ruls_list
    5.creat a rules
    6.release lock;
    
    There is a short period of time between step 3 and step 4, which would
    creatting some new aRFS FD rules if driver was receiving packet.
    So refactor the fd_rule_lock to fix it.
    
    Fixes: 441228875706 ("net: hns3: refine the flow director handle")
    Signed-off-by: Guojia Liao <liaoguojia@huawei.com>
    Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 475b8d619268df9d26f1ab4e98bbac1d61233a25
Author: Yonglong Liu <liuyonglong@huawei.com>
Date:   Tue Jul 28 10:16:49 2020 +0800

    net: hns3: fix a TX timeout issue
    
    [ Upstream commit a7e90ee5965fafc53d36e8b3205f08c88d7bc11f ]
    
    When the queue depth and queue parameters are modified, there is
    a low probability that TX timeout occurs. The two operations cause
    the link to be down or up when the watchdog is still working. All
    queues are stopped when the link is down. After the carrier is on,
    all queues are woken up. If the watchdog detects the link between
    the carrier on and wakeup queues, a false TX timeout occurs.
    
    So fix this issue by modifying the sequence of carrier on and queue
    wakeup, which is symmetrical to the link down action.
    
    Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
    Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
    Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5fc02e8d1bfd2841a5f802a42c966b0830cbb2bb
Author: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Date:   Thu Jul 23 01:13:19 2020 +0200

    sh: Fix validation of system call number
    
    [ Upstream commit 04a8a3d0a73f51c7c2da84f494db7ec1df230e69 ]
    
    The slow path for traced system call entries accessed a wrong memory
    location to get the number of the maximum allowed system call number.
    Renumber the numbered "local" label for the correct location to avoid
    collisions with actual local labels.
    
    Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
    Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Fixes: f3a8308864f920d2 ("sh: Add a few missing irqflags tracing markers.")
    Signed-off-by: Rich Felker <dalias@libc.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f2674997dfb9e427cdb11e771b272755cacf22d
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jul 17 13:10:07 2020 +0200

    sh/tlb: Fix PGTABLE_LEVELS > 2
    
    [ Upstream commit c7bcbc8ab9cb20536b8f50c62a48cebda965fdba ]
    
    Geert reported that his SH7722-based Migo-R board failed to boot after
    commit:
    
      c5b27a889da9 ("sh/tlb: Convert SH to generic mmu_gather")
    
    That commit fell victim to copying the wrong pattern --
    __pmd_free_tlb() used to be implemented with pmd_free().
    
    Fixes: c5b27a889da9 ("sh/tlb: Convert SH to generic mmu_gather")
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Rich Felker <dalias@libc.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 222dbeca05fbc9d9b614b516ca0d65663d4c6c29
Author: Tanner Love <tannerlove@google.com>
Date:   Mon Jul 27 12:25:30 2020 -0400

    selftests/net: so_txtime: fix clang issues for target arch PowerPC
    
    [ Upstream commit b4da96ffd30bd4a305045ba5c9b0de5d4aa20dc7 ]
    
    On powerpcle, int64_t maps to long long. Clang 9 threw:
    warning: absolute value function 'labs' given an argument of type \
    'long long' but has parameter of type 'long' which may cause \
    truncation of value [-Wabsolute-value]
            if (labs(tstop - texpect) > cfg_variance_us)
    
    Tested: make -C tools/testing/selftests TARGETS="net" run_tests
    
    Fixes: af5136f95045 ("selftests/net: SO_TXTIME with ETF and FQ")
    Signed-off-by: Tanner Love <tannerlove@google.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d817b2c8d3cf541351c0e7fefecf7b104c47f08b
Author: Tanner Love <tannerlove@google.com>
Date:   Mon Jul 27 12:25:29 2020 -0400

    selftests/net: psock_fanout: fix clang issues for target arch PowerPC
    
    [ Upstream commit 64f9ede2274980076423583683d44480909b7a40 ]
    
    Clang 9 threw:
    warning: format specifies type 'unsigned short' but the argument has \
    type 'int' [-Wformat]
                    typeflags, PORT_BASE, PORT_BASE + port_off);
    
    Tested: make -C tools/testing/selftests TARGETS="net" run_tests
    
    Fixes: 77f65ebdca50 ("packet: packet fanout rollover during socket overload")
    Signed-off-by: Tanner Love <tannerlove@google.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22f84cce95276bb202ccf0dceb3b2bd9de4af1af
Author: Tanner Love <tannerlove@google.com>
Date:   Mon Jul 27 12:25:28 2020 -0400

    selftests/net: rxtimestamp: fix clang issues for target arch PowerPC
    
    [ Upstream commit 955cbe91bcf782c09afe369c95a20f0a4b6dcc3c ]
    
    The signedness of char is implementation-dependent. Some systems
    (including PowerPC and ARM) use unsigned char. Clang 9 threw:
    warning: result of comparison of constant -1 with expression of type \
    'char' is always true [-Wtautological-constant-out-of-range-compare]
                                      &arg_index)) != -1) {
    
    Tested: make -C tools/testing/selftests TARGETS="net" run_tests
    
    Fixes: 16e781224198 ("selftests/net: Add a test to validate behavior of rx timestamps")
    Signed-off-by: Tanner Love <tannerlove@google.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 831c904a0f6837619dcbb13bb83f6b6aaf913f61
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Thu Jul 23 16:42:26 2020 -0700

    nvme-tcp: fix possible hang waiting for icresp response
    
    [ Upstream commit adc99fd378398f4c58798a1c57889872967d56a6 ]
    
    If the controller died exactly when we are receiving icresp
    we hang because icresp may never return. Make sure to set a
    high finite limit.
    
    Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver")
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a1d0084cbe17cb1b919e48edb854983eafe02fc
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Tue Jul 21 15:40:38 2020 +0100

    ARM: dts: armada-38x: fix NETA lockup when repeatedly switching speeds
    
    [ Upstream commit 09781ba0395c46b1c844f47e405e3ce7856f5989 ]
    
    To support the change in "phy: armada-38x: fix NETA lockup when
    repeatedly switching speeds" we need to update the DT with the
    additional register.
    
    Fixes: 14dc100b4411 ("phy: armada38x: add common phy support")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 731e013e33b3d8ba075b06aedb5264a0fc4b77e4
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Fri Jul 17 10:34:27 2020 +0200

    xfrm: Fix crash when the hold queue is used.
    
    [ Upstream commit 101dde4207f1daa1fda57d714814a03835dccc3f ]
    
    The commits "xfrm: Move dst->path into struct xfrm_dst"
    and "net: Create and use new helper xfrm_dst_child()."
    changed xfrm bundle handling under the assumption
    that xdst->path and dst->child are not a NULL pointer
    only if dst->xfrm is not a NULL pointer. That is true
    with one exception. If the xfrm hold queue is used
    to wait until a SA is installed by the key manager,
    we create a dummy bundle without a valid dst->xfrm
    pointer. The current xfrm bundle handling crashes
    in that case. Fix this by extending the NULL check
    of dst->xfrm with a test of the DST_XFRM_QUEUE flag.
    
    Fixes: 0f6c480f23f4 ("xfrm: Move dst->path into struct xfrm_dst")
    Fixes: b92cf4aab8e6 ("net: Create and use new helper xfrm_dst_child().")
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4c902887f1d8ea3eebbbdfb3b7c85964a3eadec
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Sat Jul 4 15:08:29 2020 +0200

    ARM: dts sunxi: Relax a bit the CMA pool allocation range
    
    [ Upstream commit 92025b90f18d45e26b7f17d68756b1abd771b9d3 ]
    
    The hardware codec on the A10, A10s, A13 and A20 needs buffer in the
    first 256MB of RAM. This was solved by setting the CMA pool at a fixed
    address in that range.
    
    However, in recent kernels there's something else that comes in and
    reserve some range that end up conflicting with our default pool
    requirement, and thus makes its reservation fail.
    
    The video codec will then use buffers from the usual default pool,
    outside of the range it can access, and will fail to decode anything.
    
    Since we're only concerned about that 256MB, we can however relax the
    allocation to just specify the range that's allowed, and not try to
    enforce a specific address.
    
    Fixes: 5949bc5602cc ("ARM: dts: sun4i-a10: Add Video Engine and reserved memory nodes")
    Fixes: 960432010156 ("ARM: dts: sun5i: Add Video Engine and reserved memory nodes")
    Fixes: c2a641a74850 ("ARM: dts: sun7i-a20: Add Video Engine and reserved memory nodes")
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Acked-by: Chen-Yu Tsai <wens@csie.org>
    Link: https://lore.kernel.org/r/20200704130829.34297-1-maxime@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0307da6866606b8cfacda062c47cdf6588b6dfac
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon Jun 22 16:40:29 2020 +0800

    xfrm: policy: match with both mark and mask on user interfaces
    
    [ Upstream commit 4f47e8ab6ab796b5380f74866fa5287aca4dcc58 ]
    
    In commit ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list"),
    it would take 'priority' to make a policy unique, and allow duplicated
    policies with different 'priority' to be added, which is not expected
    by userland, as Tobias reported in strongswan.
    
    To fix this duplicated policies issue, and also fix the issue in
    commit ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list"),
    when doing add/del/get/update on user interfaces, this patch is to change
    to look up a policy with both mark and mask by doing:
    
      mark.v == pol->mark.v && mark.m == pol->mark.m
    
    and leave the check:
    
      (mark & pol->mark.m) == pol->mark.v
    
    for tx/rx path only.
    
    As the userland expects an exact mark and mask match to manage policies.
    
    v1->v2:
      - make xfrm_policy_mark_match inline and fix the changelog as
        Tobias suggested.
    
    Fixes: 295fae568885 ("xfrm: Allow user space manipulation of SPD mark")
    Fixes: ed17b8d377ea ("xfrm: fix a warning in xfrm_policy_insert_list")
    Reported-by: Tobias Brunner <tobias@strongswan.org>
    Tested-by: Tobias Brunner <tobias@strongswan.org>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbb13adb07affddc2cf2559ef0697cf0ef2c1974
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Tue Apr 28 16:12:08 2020 +0800

    net/x25: Fix null-ptr-deref in x25_disconnect
    
    commit 8999dc89497ab1c80d0718828e838c7cd5f6bffe upstream.
    
    We should check null before do x25_neigh_put in x25_disconnect,
    otherwise may cause null-ptr-deref like this:
    
     #include <sys/socket.h>
     #include <linux/x25.h>
    
     int main() {
        int sck_x25;
        sck_x25 = socket(AF_X25, SOCK_SEQPACKET, 0);
        close(sck_x25);
        return 0;
     }
    
    BUG: kernel NULL pointer dereference, address: 00000000000000d8
    CPU: 0 PID: 4817 Comm: t2 Not tainted 5.7.0-rc3+ #159
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-
    RIP: 0010:x25_disconnect+0x91/0xe0
    Call Trace:
     x25_release+0x18a/0x1b0
     __sock_release+0x3d/0xc0
     sock_close+0x13/0x20
     __fput+0x107/0x270
     ____fput+0x9/0x10
     task_work_run+0x6d/0xb0
     exit_to_usermode_loop+0x102/0x110
     do_syscall_64+0x23c/0x260
     entry_SYSCALL_64_after_hwframe+0x49/0xb3
    
    Reported-by: syzbot+6db548b615e5aeefdce2@syzkaller.appspotmail.com
    Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69cd304cfa5cfb0f130488af579c143382432766
Author: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Date:   Sat Apr 25 21:06:25 2020 +0800

    net/x25: Fix x25_neigh refcnt leak when x25 disconnect
    
    commit 4becb7ee5b3d2829ed7b9261a245a77d5b7de902 upstream.
    
    x25_connect() invokes x25_get_neigh(), which returns a reference of the
    specified x25_neigh object to "x25->neighbour" with increased refcnt.
    
    When x25 connect success and returns, the reference still be hold by
    "x25->neighbour", so the refcount should be decreased in
    x25_disconnect() to keep refcount balanced.
    
    The reference counting issue happens in x25_disconnect(), which forgets
    to decrease the refcnt increased by x25_get_neigh() in x25_connect(),
    causing a refcnt leak.
    
    Fix this issue by calling x25_neigh_put() before x25_disconnect()
    returns.
    
    Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2fd34d4311033120fa502aa8bd4723cdeee0103
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Jul 25 02:06:23 2020 +0100

    libtraceevent: Fix build with binutils 2.35
    
    commit 39efdd94e314336f4acbac4c07e0f37bdc3bef71 upstream.
    
    In binutils 2.35, 'nm -D' changed to show symbol versions along with
    symbol names, with the usual @@ separator.  When generating
    libtraceevent-dynamic-list we need just the names, so strip off the
    version suffix if present.
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: linux-trace-devel@vger.kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ec69499b7589d8701eb7563d11a4efffd6252bc
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date:   Thu Jul 30 15:20:26 2020 -0400

    rds: Prevent kernel-infoleak in rds_notify_queue_get()
    
    commit bbc8a99e952226c585ac17477a85ef1194501762 upstream.
    
    rds_notify_queue_get() is potentially copying uninitialized kernel stack
    memory to userspace since the compiler may leave a 4-byte hole at the end
    of `cmsg`.
    
    In 2016 we tried to fix this issue by doing `= { 0 };` on `cmsg`, which
    unfortunately does not always initialize that 4-byte hole. Fix it by using
    memset() instead.
    
    Cc: stable@vger.kernel.org
    Fixes: f037590fff30 ("rds: fix a leak of kernel memory")
    Fixes: bdbe6fbc6a2f ("RDS: recv.c")
    Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a9428427da1775ae79baa8414fdb31db546a384
Author: Steve Cohen <cohens@codeaurora.org>
Date:   Mon Jul 20 18:30:50 2020 -0400

    drm: hold gem reference until object is no longer accessed
    
    commit 8490d6a7e0a0a6fab5c2d82d57a3937306660864 upstream.
    
    A use-after-free in drm_gem_open_ioctl can happen if the
    GEM object handle is closed between the idr lookup and
    retrieving the size from said object since a local reference
    is not being held at that point. Hold the local reference
    while the object can still be accessed to fix this and
    plug the potential security hole.
    
    Signed-off-by: Steve Cohen <cohens@codeaurora.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/1595284250-31580-1-git-send-email-cohens@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7eef3b463d88256b0fc5adc74f8d7859dae3cc07
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Fri Jul 3 16:13:41 2020 +0200

    drm/dbi: Fix SPI Type 1 (9-bit) transfer
    
    commit 900ab59e2621053b009f707f80b2c19ce0af5dee upstream.
    
    The function mipi_dbi_spi1_transfer() will transfer its payload as 9-bit
    data, the 9th (MSB) bit being the data/command bit. In order to do that,
    it unpacks the 8-bit values into 16-bit values, then sets the 9th bit if
    the byte corresponds to data, clears it otherwise. The 7 MSB are
    padding. The array of now 16-bit values is then passed to the SPI core
    for transfer.
    
    This function was broken since its introduction, as the length of the
    SPI transfer was set to the payload size before its conversion, but the
    payload doubled in size due to the 8-bit -> 16-bit conversion.
    
    Fixes: 02dd95fe3169 ("drm/tinydrm: Add MIPI DBI support")
    Cc: <stable@vger.kernel.org> # 5.4+
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200703141341.1266263-1-paul@crapouillou.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ea180f1c7ec137310ea2e66300485dbda93baad
Author: Peilin Ye <yepeilin.cs@gmail.com>
Date:   Tue Jul 28 15:29:24 2020 -0400

    drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
    
    commit 543e8669ed9bfb30545fd52bc0e047ca4df7fb31 upstream.
    
    Compiler leaves a 4-byte hole near the end of `dev_info`, causing
    amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
    when `size` is greater than 356.
    
    In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
    unfortunately does not initialize that 4-byte hole. Fix it by using
    memset() instead.
    
    Cc: stable@vger.kernel.org
    Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
    Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
    Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1b4bdde2bdcc0dd89d7ab193b3da5093d8ff79a
Author: Mazin Rezk <mnrzk@protonmail.com>
Date:   Mon Jul 27 05:40:46 2020 +0000

    drm/amd/display: Clear dm_state for fast updates
    
    commit fde9f39ac7f1ffd799a96ffa1e06b2051f0898f1 upstream.
    
    This patch fixes a race condition that causes a use-after-free during
    amdgpu_dm_atomic_commit_tail. This can occur when 2 non-blocking commits
    are requested and the second one finishes before the first. Essentially,
    this bug occurs when the following sequence of events happens:
    
    1. Non-blocking commit #1 is requested w/ a new dm_state #1 and is
    deferred to the workqueue.
    
    2. Non-blocking commit #2 is requested w/ a new dm_state #2 and is
    deferred to the workqueue.
    
    3. Commit #2 starts before commit #1, dm_state #1 is used in the
    commit_tail and commit #2 completes, freeing dm_state #1.
    
    4. Commit #1 starts after commit #2 completes, uses the freed dm_state
    1 and dereferences a freelist pointer while setting the context.
    
    Since this bug has only been spotted with fast commits, this patch fixes
    the bug by clearing the dm_state instead of using the old dc_state for
    fast updates. In addition, since dm_state is only used for its dc_state
    and amdgpu_dm_atomic_commit_tail will retain the dc_state if none is found,
    removing the dm_state should not have any consequences in fast updates.
    
    This use-after-free bug has existed for a while now, but only caused a
    noticeable issue starting from 5.7-rc1 due to 3202fa62f ("slub: relocate
    freelist pointer to middle of object") moving the freelist pointer from
    dm_state->base (which was unused) to dm_state->context (which is
    dereferenced).
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207383
    Fixes: bd200d190f45 ("drm/amd/display: Don't replace the dc_state for fast updates")
    Reported-by: Duncan <1i5t5.duncan@cox.net>
    Signed-off-by: Mazin Rezk <mnrzk@protonmail.com>
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22d3202e51a7fe6551efc45ed77b4e7c015f5709
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Jul 30 11:02:30 2020 -0400

    Revert "drm/amdgpu: Fix NULL dereference in dpm sysfs handlers"
    
    commit 87004abfbc27261edd15716515d89ab42198b405 upstream.
    
    This regressed some working configurations so revert it.  Will
    fix this properly for 5.9 and backport then.
    
    This reverts commit 38e0c89a19fd13f28d2b4721035160a3e66e270b.
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cea6633d5382ca93bf49e817f903b705820a5d77
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Mon Jul 27 12:01:27 2020 -0400

    virtio_balloon: fix up endian-ness for free cmd id
    
    commit 168c358af2f8c5a37f8b5f877ba2cc93995606ee upstream.
    
    free cmd id is read using virtio endian, spec says all fields
    in balloon are LE. Fix it up.
    
    Fixes: 86a559787e6f ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT")
    Cc: stable@vger.kernel.org
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Wei Wang <wei.w.wang@intel.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2f787f904e0c40b15e60eff142c647cd4d43ce8
Author: Michael Trimarchi <michael@amarulasolutions.com>
Date:   Fri Jul 17 13:33:52 2020 +0530

    ARM: dts: imx6qdl-icore: Fix OTG_ID pin and sdcard detect
    
    commit 4a601da92c2a782e5c022680d476104586b74994 upstream.
    
    The current pin muxing scheme muxes GPIO_1 pad for USB_OTG_ID
    because of which when card is inserted, usb otg is enumerated
    and the card is never detected.
    
    [   64.492645] cfg80211: failed to load regulatory.db
    [   64.492657] imx-sdma 20ec000.sdma: external firmware not found, using ROM firmware
    [   76.343711] ci_hdrc ci_hdrc.0: EHCI Host Controller
    [   76.349742] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 2
    [   76.388862] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
    [   76.396650] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.08
    [   76.405412] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
    [   76.412763] usb usb2: Product: EHCI Host Controller
    [   76.417666] usb usb2: Manufacturer: Linux 5.8.0-rc1-next-20200618 ehci_hcd
    [   76.424623] usb usb2: SerialNumber: ci_hdrc.0
    [   76.431755] hub 2-0:1.0: USB hub found
    [   76.435862] hub 2-0:1.0: 1 port detected
    
    The TRM mentions GPIO_1 pad should be muxed/assigned for card detect
    and ENET_RX_ER pad for USB_OTG_ID for proper operation.
    
    This patch fixes pin muxing as per TRM and is tested on a
    i.Core 1.5 MX6 DL SOM.
    
    [   22.449165] mmc0: host does not support reading read-only switch, assuming write-enable
    [   22.459992] mmc0: new high speed SDHC card at address 0001
    [   22.469725] mmcblk0: mmc0:0001 EB1QT 29.8 GiB
    [   22.478856]  mmcblk0: p1 p2
    
    Fixes: 6df11287f7c9 ("ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
    Signed-off-by: Suniel Mahesh <sunil@amarulasolutions.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9274613114a80e460351efa703a018386a6660f
Author: Fabio Estevam <festevam@gmail.com>
Date:   Mon Jul 13 11:23:24 2020 -0300

    ARM: dts: imx6sx-sdb: Fix the phy-mode on fec2
    
    commit c696afd331be1acb39206aba53048f2386b781fc upstream.
    
    Commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") fixed the
    phy-mode for fec1, but missed to fix it for the fec2 node.
    
    Fix fec2 to also use "rgmii-id" as the phy-mode.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode")
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4738c67a5696a3e91f2352b8ac881577ee7bb71
Author: Fabio Estevam <festevam@gmail.com>
Date:   Mon Jul 13 11:23:25 2020 -0300

    ARM: dts: imx6sx-sabreauto: Fix the phy-mode on fec2
    
    commit d36f260718d83928e6012247a7e1b9791cdb12ff upstream.
    
    Commit 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") fixed the
    phy-mode for fec1, but missed to fix it for the fec2 node.
    
    Fix fec2 to also use "rgmii-id" as the phy-mode.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode")
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b7e4a5ba95d52ffb8d97a4761bdf118ac1e43af
Author: Will Deacon <will@kernel.org>
Date:   Thu Jun 18 11:16:45 2020 +0100

    ARM: 8986/1: hw_breakpoint: Don't invoke overflow handler on uaccess watchpoints
    
    commit eec13b42d41b0f3339dcf0c4da43734427c68620 upstream.
    
    Unprivileged memory accesses generated by the so-called "translated"
    instructions (e.g. LDRT) in kernel mode can cause user watchpoints to fire
    unexpectedly. In such cases, the hw_breakpoint logic will invoke the user
    overflow handler which will typically raise a SIGTRAP back to the current
    task. This is futile when returning back to the kernel because (a) the
    signal won't have been delivered and (b) userspace can't handle the thing
    anyway.
    
    Avoid invoking the user overflow handler for watchpoints triggered by
    kernel uaccess routines, and instead single-step over the faulting
    instruction as we would if no overflow handler had been installed.
    
    Cc: <stable@vger.kernel.org>
    Fixes: f81ef4a920c8 ("ARM: 6356/1: hw-breakpoint: add ARM backend for the hw-breakpoint framework")
    Reported-by: Luis Machado <luis.machado@linaro.org>
    Tested-by: Luis Machado <luis.machado@linaro.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8fa0b0370474e51335a4f274cda70c976c73230
Author: Pi-Hsun Shih <pihsun@chromium.org>
Date:   Wed Dec 4 16:13:07 2019 +0800

    wireless: Use offsetof instead of custom macro.
    
    commit 6989310f5d4327e8595664954edd40a7f99ddd0d upstream.
    
    Use offsetof to calculate offset of a field to take advantage of
    compiler built-in version when possible, and avoid UBSAN warning when
    compiling with Clang:
    
    ==================================================================
    UBSAN: Undefined behaviour in net/wireless/wext-core.c:525:14
    member access within null pointer of type 'struct iw_point'
    CPU: 3 PID: 165 Comm: kworker/u16:3 Tainted: G S      W         4.19.23 #43
    Workqueue: cfg80211 __cfg80211_scan_done [cfg80211]
    Call trace:
     dump_backtrace+0x0/0x194
     show_stack+0x20/0x2c
     __dump_stack+0x20/0x28
     dump_stack+0x70/0x94
     ubsan_epilogue+0x14/0x44
     ubsan_type_mismatch_common+0xf4/0xfc
     __ubsan_handle_type_mismatch_v1+0x34/0x54
     wireless_send_event+0x3cc/0x470
     ___cfg80211_scan_done+0x13c/0x220 [cfg80211]
     __cfg80211_scan_done+0x28/0x34 [cfg80211]
     process_one_work+0x170/0x35c
     worker_thread+0x254/0x380
     kthread+0x13c/0x158
     ret_from_fork+0x10/0x18
    ===================================================================
    
    Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/r/20191204081307.138765-1-pihsun@chromium.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d3472f74d229b499bbec854c2ebca802326f9007
Author: Wang Hai <wanghai38@huawei.com>
Date:   Fri Jun 12 17:08:33 2020 +0800

    9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work
    
    commit 74d6a5d5662975aed7f25952f62efbb6f6dadd29 upstream.
    
    p9_read_work and p9_fd_cancelled may be called concurrently.
    In some cases, req->req_list may be deleted by both p9_read_work
    and p9_fd_cancelled.
    
    We can fix it by ignoring replies associated with a cancelled
    request and ignoring cancelled request if message has been received
    before lock.
    
    Link: http://lkml.kernel.org/r/20200612090833.36149-1-wanghai38@huawei.com
    Fixes: 60ff779c4abb ("9p: client: remove unused code and any reference to "cancelled" function")
    Cc: <stable@vger.kernel.org> # v3.12+
    Reported-by: syzbot+77a25acfa0382e06ab23@syzkaller.appspotmail.com
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96f105943cff8816436fc814b3e150b2bfc5a991
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Fri Jul 10 06:36:16 2020 -0400

    vhost/scsi: fix up req type endian-ness
    
    commit 295c1b9852d000580786375304a9800bd9634d15 upstream.
    
    vhost/scsi doesn't handle type conversion correctly
    for request type when using virtio 1.0 and up for BE,
    or cross-endian platforms.
    
    Fix it up using vhost_32_to_cpu.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 951117a2079bf0f725e0f297d4bfb5a9a1371864
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Tue Jul 28 14:38:48 2020 -0400

    IB/rdmavt: Fix RQ counting issues causing use of an invalid RWQE
    
    commit 54a485e9ec084da1a4b32dcf7749c7d760ed8aa5 upstream.
    
    The lookaside count is improperly initialized to the size of the
    Receive Queue with the additional +1.  In the traces below, the
    RQ size is 384, so the count was set to 385.
    
    The lookaside count is then rarely refreshed.  Note the high and
    incorrect count in the trace below:
    
    rvt_get_rwqe: [hfi1_0] wqe ffffc900078e9008 wr_id 55c7206d75a0 qpn c
            qpt 2 pid 3018 num_sge 1 head 1 tail 0, count 385
    rvt_get_rwqe: (hfi1_rc_rcv+0x4eb/0x1480 [hfi1] <- rvt_get_rwqe) ret=0x1
    
    The head,tail indicate there is only one RWQE posted although the count
    says 385 and we correctly return the element 0.
    
    The next call to rvt_get_rwqe with the decremented count:
    
    rvt_get_rwqe: [hfi1_0] wqe ffffc900078e9058 wr_id 0 qpn c
            qpt 2 pid 3018 num_sge 0 head 1 tail 1, count 384
    rvt_get_rwqe: (hfi1_rc_rcv+0x4eb/0x1480 [hfi1] <- rvt_get_rwqe) ret=0x1
    
    Note that the RQ is empty (head == tail) yet we return the RWQE at tail 1,
    which is not valid because of the bogus high count.
    
    Best case, the RWQE has never been posted and the rc logic sees an RWQE
    that is too small (all zeros) and puts the QP into an error state.
    
    In the worst case, a server slow at posting receive buffers might fool
    rvt_get_rwqe() into fetching an old RWQE and corrupt memory.
    
    Fix by deleting the faulty initialization code and creating an
    inline to fetch the posted count and convert all callers to use
    new inline.
    
    Fixes: f592ae3c999f ("IB/rdmavt: Fracture single lock used for posting and processing RWQEs")
    Link: https://lore.kernel.org/r/20200728183848.22226.29132.stgit@awfm-01.aw.intel.com
    Reported-by: Zhaojuan Guo <zguo@redhat.com>
    Cc: <stable@vger.kernel.org> # 5.4.x
    Reviewed-by: Kaike Wan <kaike.wan@intel.com>
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Tested-by: Honggang Li <honli@redhat.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc731d26281161d543875afa1fa6cee88431163b
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jul 28 10:20:33 2020 +0200

    ALSA: hda/hdmi: Fix keep_power assignment for non-component devices
    
    commit c2c3657f0aedb8736a0fb7b2b1985adfb86e7802 upstream.
    
    It's been reported that, when neither nouveau nor Nvidia graphics
    driver is used, the screen starts flickering.  And, after comparing
    between the working case (stable 4.4.x) and the broken case, it turned
    out that the problem comes from the audio component binding.  The
    Nvidia and AMD audio binding code clears the bus->keep_power flag
    whenever snd_hdac_acomp_init() succeeds.  But this doesn't mean that
    the component is actually bound, but it merely indicates that it's
    ready for binding.  So, when both nouveau and Nvidia are blacklisted
    or not ready, the driver keeps running without the audio component but
    also with bus->keep_power = false.  This made the driver runtime PM
    kicked in and powering down when unused, which results in flickering
    in the graphics side, as it seems.
    
    For fixing the bug, this patch moves the bus->keep_power flag change
    into generic_acomp_notifier_set() that is the function called from the
    master_bind callback of component ops; i.e. it's guaranteed that the
    binding succeeded.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208609
    Fixes: 5a858e79c911 ("ALSA: hda - Disable audio component for legacy Nvidia HDMI codecs")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200728082033.23933-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a67b05c6f30d85ba19440c1339507d8356f68f7
Author: Kailang Yang <kailang@realtek.com>
Date:   Wed Jul 29 15:09:27 2020 +0800

    ALSA: hda/realtek - Fixed HP right speaker no sound
    
    commit 5649625344fe1f4695eace7c37d011e317bf66d5 upstream.
    
    HP NB right speaker had no sound output.
    This platform was connected to I2S Amp for speaker out.(None Realtek I2S Amp IC)
    EC need to check codec GPIO1 pin to initial I2S Amp.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/01285f623ac7447187482fb4a8ecaa7c@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09832a9e0b762585a744b4ee393bc7978b03581b
Author: PeiSen Hou <pshou@realtek.com>
Date:   Mon Jul 27 13:56:47 2020 +0200

    ALSA: hda/realtek: Fix add a "ultra_low_power" function for intel reference board (alc256)
    
    commit 6fa38ef1534e7e9320aa15e329eb1404ab2f70ac upstream.
    
    Intel requires to enable power saving mode for intel reference board (alc256)
    
    Signed-off-by: PeiSen Hou <pshou@realtek.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200727115647.10967-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9f147c937a5cab7288d1c988631d4dfa95effd0
Author: Armas Spann <zappel@retarded.farm>
Date:   Fri Jul 24 16:08:37 2020 +0200

    ALSA: hda/realtek: typo_fix: enable headset mic of ASUS ROG Zephyrus G14(GA401) series with ALC289
    
    commit 293a92c1d9913248b9987b68f3a5d6d2f0aae62b upstream.
    
    This patch fixes a small typo I accidently submitted with the initial patch. The board should be named GA401 not G401.
    
    Fixes: ff53664daff2 ("ALSA: hda/realtek: enable headset mic of ASUS ROG Zephyrus G14(G401) series with ALC289")
    Signed-off-by: Armas Spann <zappel@retarded.farm>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200724140837.302763-1-zappel@retarded.farm
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd76d30f51fb55b4b493e77a555ddf90f2dd33e0
Author: Armas Spann <zappel@retarded.farm>
Date:   Fri Jul 24 16:06:16 2020 +0200

    ALSA: hda/realtek: enable headset mic of ASUS ROG Zephyrus G15(GA502) series with ALC289
    
    commit 4b43d05a1978a93a19374c6e6b817c9c1ff4ba4b upstream.
    
    This patch adds support for headset mic to the ASUS ROG Zephyrus
    G15(GA502) notebook series by adding the corresponding
    vendor/pci_device id, as well as adding a new fixup for the used
    realtek ALC289. The fixup stets the correct pin to get the headset mic
    correctly recognized on audio-jack.
    
    Signed-off-by: Armas Spann <zappel@retarded.farm>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200724140616.298892-1-zappel@retarded.farm
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d84a8cf8a02d60312fe6a955f43604132860c99
Author: Laurence Tratt <laurie@tratt.net>
Date:   Sun Jun 21 08:50:05 2020 +0100

    ALSA: usb-audio: Add implicit feedback quirk for SSL2
    
    commit 3da87ec67a491b9633a82045896c076b794bf938 upstream.
    
    As expected, this requires the same quirk as the SSL2+ in order for the
    clock to sync. This was suggested by, and tested on an SSL2, by Dmitry.
    
    Suggested-by: Dmitry <dpavlushko@gmail.com>
    Signed-off-by: Laurence Tratt <laurie@tratt.net>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200621075005.52mjjfc6dtdjnr3h@overdrive.tratt.net
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47e20933814feeb75543eb514437989cea53ec52
Author: Jan Kara <jack@suse.cz>
Date:   Wed Apr 1 21:04:40 2020 -0700

    mm/filemap.c: don't bother dropping mmap_sem for zero size readahead
    
    commit 5c72feee3e45b40a3c96c7145ec422899d0e8964 upstream.
    
    When handling a page fault, we drop mmap_sem to start async readahead so
    that we don't block on IO submission with mmap_sem held.  However there's
    no point to drop mmap_sem in case readahead is disabled.  Handle that case
    to avoid pointless dropping of mmap_sem and retrying the fault.  This was
    actually reported to block mlockall(MCL_CURRENT) indefinitely.
    
    Fixes: 6b4c9f446981 ("filemap: drop the mmap_sem for all blocking operations")
    Reported-by: Minchan Kim <minchan@kernel.org>
    Reported-by: Robert Stupp <snazy@gmx.de>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Minchan Kim <minchan@kernel.org>
    Link: http://lkml.kernel.org/r/20200212101356.30759-1-jack@suse.cz
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: SeongJae Park <sjpark@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14021055427493bb9bf7be6774636dee86c5e02a
Author: Robert Hancock <hancockrwd@gmail.com>
Date:   Tue Jul 21 20:18:03 2020 -0600

    PCI/ASPM: Disable ASPM on ASMedia ASM1083/1085 PCIe-to-PCI bridge
    
    commit b361663c5a40c8bc758b7f7f2239f7a192180e7c upstream.
    
    Recently ASPM handling was changed to allow ASPM on PCIe-to-PCI/PCI-X
    bridges.  Unfortunately the ASMedia ASM1083/1085 PCIe to PCI bridge device
    doesn't seem to function properly with ASPM enabled.  On an Asus PRIME
    H270-PRO motherboard, it causes errors like these:
    
      pcieport 0000:00:1c.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
      pcieport 0000:00:1c.0: AER:   device [8086:a292] error status/mask=00003000/00002000
      pcieport 0000:00:1c.0: AER:    [12] Timeout
      pcieport 0000:00:1c.0: AER: Corrected error received: 0000:00:1c.0
      pcieport 0000:00:1c.0: AER: can't find device of ID00e0
    
    In addition to flooding the kernel log, this also causes the machine to
    wake up immediately after suspend is initiated.
    
    The device advertises ASPM L0s and L1 support in the Link Capabilities
    register, but the ASMedia web page for ASM1083 [1] claims "No PCIe ASPM
    support".
    
    Windows 10 (build 2004) enables L0s, but it also logs correctable PCIe
    errors.
    
    Add a quirk to disable ASPM for this device.
    
    [1] https://www.asmedia.com.tw/eng/e_show_products.php?cate_index=169&item=114
    
    [bhelgaas: commit log]
    Fixes: 66ff14e59e8a ("PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges")
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208667
    Link: https://lore.kernel.org/r/20200722021803.17958-1-hancockrwd@gmail.com
    Signed-off-by: Robert Hancock <hancockrwd@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ff65580d477d4275b652799c472e763bd09992a
Author: Abhishek Ambure <aambure@codeaurora.org>
Date:   Thu Oct 3 16:45:22 2019 +0300

    ath10k: enable transmit data ack RSSI for QCA9884
    
    commit cc78dc3b790619aa05f22a86a9152986bd73698c upstream.
    
    For all data packets transmitted, host gets htt tx completion event. Some QCA9984
    firmware releases support WMI_SERVICE_TX_DATA_ACK_RSSI, which gives data
    ack rssi values to host through htt event of data tx completion. Data ack rssi
    values are valid if A0 bit is set in HTT rx message. So enable the feature also
    for QCA9884.
    
    Tested HW: QCA9984
    Tested FW: 10.4-3.9.0.2-00044
    
    Signed-off-by: Abhishek Ambure <aambure@codeaurora.org>
    Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
    [kvalo@codeaurora.org: improve commit log]
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98cef10fbcca40e70f9f389a4bea42384376376b
Author: Sasha Levin <sashal@kernel.org>
Date:   Thu Jul 30 18:55:53 2020 -0400

    sunrpc: check that domain table is empty at module unload.
    
    [ Upstream commit f45db2b909c7e76f35850e78f017221f30282b8e ]
    
    The domain table should be empty at module unload.  If it isn't there is
    a bug somewhere.  So check and report.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=206651
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84da97713b9112c9529a941b230219b759e6f206
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Wed Sep 25 12:02:41 2019 -0300

    media: rc: prevent memory leak in cx23888_ir_probe
    
    [ Upstream commit a7b2df76b42bdd026e3106cf2ba97db41345a177 ]
    
    In cx23888_ir_probe if kfifo_alloc fails the allocated memory for state
    should be released.
    
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecfa7fa198fc66731ded5dabefccc8e9e2f3b311
Author: Navid Emamdoost <navid.emamdoost@gmail.com>
Date:   Thu Sep 19 11:04:48 2019 -0500

    crypto: ccp - Release all allocated memory if sha type is invalid
    
    [ Upstream commit 128c66429247add5128c03dc1e144ca56f05a4e2 ]
    
    Release all allocated memory if sha type is invalid:
    In ccp_run_sha_cmd, if the type of sha is invalid, the allocated
    hmac_buf should be released.
    
    v2: fix the goto.
    
    Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
    Acked-by: Gary R Hook <gary.hook@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>