commit 70154d2f82a9058e8316b6e106071c72fcc58718
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jun 3 08:59:17 2021 +0200

    Linux 5.4.124
    
    Link: https://lore.kernel.org/r/20210531130647.887605866@linuxfoundation.org
    Tested-by: Hulk Robot <hulkrobot@huawei.com>、
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Jason Self <jason@bluehome.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23c7e3235a3a5d6297374ab48cc74f63d0a3f275
Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date:   Sat Apr 10 09:20:45 2021 +0800

    usb: core: reduce power-on-good delay time of root hub
    
    commit 90d28fb53d4a51299ff324dede015d5cb11b88a2 upstream.
    
    Return the exactly delay time given by root hub descriptor,
    this helps to reduce resume time etc.
    
    Due to the root hub descriptor is usually provided by the host
    controller driver, if there is compatibility for a root hub,
    we can fix it easily without affect other root hub
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Link: https://lore.kernel.org/r/1618017645-12259-1-git-send-email-chunfeng.yun@mediatek.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 241abccc8a3353e6bd5529fc9ffb03b33c101da9
Author: Chinmay Agarwal <chinagar@codeaurora.org>
Date:   Thu Apr 22 01:12:22 2021 +0530

    neighbour: Prevent Race condition in neighbour subsytem
    
    commit eefb45eef5c4c425e87667af8f5e904fbdd47abf upstream.
    
    Following Race Condition was detected:
    
    <CPU A, t0>: Executing: __netif_receive_skb() ->__netif_receive_skb_core()
    -> arp_rcv() -> arp_process().arp_process() calls __neigh_lookup() which
    takes a reference on neighbour entry 'n'.
    Moves further along, arp_process() and calls neigh_update()->
    __neigh_update(). Neighbour entry is unlocked just before a call to
    neigh_update_gc_list.
    
    This unlocking paves way for another thread that may take a reference on
    the same and mark it dead and remove it from gc_list.
    
    <CPU B, t1> - neigh_flush_dev() is under execution and calls
    neigh_mark_dead(n) marking the neighbour entry 'n' as dead. Also n will be
    removed from gc_list.
    Moves further along neigh_flush_dev() and calls
    neigh_cleanup_and_release(n), but since reference count increased in t1,
    'n' couldn't be destroyed.
    
    <CPU A, t3>- Code hits neigh_update_gc_list, with neighbour entry
    set as dead.
    
    <CPU A, t4> - arp_process() finally calls neigh_release(n), destroying
    the neighbour entry and we have a destroyed ntry still part of gc_list.
    
    Fixes: eb4e8fac00d1("neighbour: Prevent a dead entry from updating gc_list")
    Signed-off-by: Chinmay Agarwal <chinagar@codeaurora.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c36980ba68172d623da8427a7dc81257bba4f1c
Author: Johan Hovold <johan@kernel.org>
Date:   Wed May 19 14:47:17 2021 +0200

    net: hso: bail out on interrupt URB allocation failure
    
    commit 4d52ebc7ace491d58f96d1f4a1cb9070c506b2e7 upstream.
    
    Commit 31db0dbd7244 ("net: hso: check for allocation failure in
    hso_create_bulk_serial_device()") recently started returning an error
    when the driver fails to allocate resources for the interrupt endpoint
    and tiocmget functionality.
    
    For consistency let's bail out from probe also if the URB allocation
    fails.
    
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1bd48a2af84e9eec0139cb73de4c26b5cbe8d78e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu May 13 21:40:38 2021 +0200

    Revert "Revert "ALSA: usx2y: Fix potential NULL pointer dereference""
    
    commit 27b57bb76a897be80494ee11ee4e85326d19383d upstream.
    
    This reverts commit 4667a6fc1777ce071504bab570d3599107f4790f.
    
    Takashi writes:
            I have already started working on the bigger cleanup of this driver
            code based on 5.13-rc1, so could you drop this revert?
    
    I missed our previous discussion about this, my fault for applying it.
    
    Reported-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 866648d965f0aeab17b6536cbc86a11f00ff0a41
Author: Yunsheng Lin <linyunsheng@huawei.com>
Date:   Tue May 18 19:36:03 2021 +0800

    net: hns3: check the return of skb_checksum_help()
    
    commit 9bb5a495424fd4bfa672eb1f31481248562fa156 upstream.
    
    Currently skb_checksum_help()'s return is ignored, but it may
    return error when it fails to allocate memory when linearizing.
    
    So adds checking for the return of skb_checksum_help().
    
    Fixes: 76ad4f0ee747("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC")
    Fixes: 3db084d28dc0("net: hns3: Fix for vxlan tx checksum bug")
    Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
    Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72cda5259f5e28090cc18d0852191dd1289c3a5c
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date:   Fri Sep 25 15:24:39 2020 -0700

    drivers/net/ethernet: clean up unused assignments
    
    commit 7c8c0291f84027558bd5fca5729cbcf288c510f4 upstream.
    
    As part of the W=1 compliation series, these lines all created
    warnings about unused variables that were assigned a value. Most
    of them are from register reads, but some are just picking up
    a return value from a function and never doing anything with it.
    
    Fixed warnings:
    .../ethernet/brocade/bna/bnad.c:3280:6: warning: variable ‘rx_count’ set but not used [-Wunused-but-set-variable]
    .../ethernet/brocade/bna/bnad.c:3280:6: warning: variable ‘rx_count’ set but not used [-Wunused-but-set-variable]
    .../ethernet/cortina/gemini.c:512:6: warning: variable ‘val’ set but not used [-Wunused-but-set-variable]
    .../ethernet/cortina/gemini.c:2110:21: warning: variable ‘config0’ set but not used [-Wunused-but-set-variable]
    .../ethernet/cavium/liquidio/octeon_device.c:1327:6: warning: variable ‘val32’ set but not used [-Wunused-but-set-variable]
    .../ethernet/cavium/liquidio/octeon_device.c:1358:6: warning: variable ‘val32’ set but not used [-Wunused-but-set-variable]
    .../ethernet/dec/tulip/media.c:322:8: warning: variable ‘setup’ set but not used [-Wunused-but-set-variable]
    .../ethernet/dec/tulip/de4x5.c:4928:13: warning: variable ‘r3’ set but not used [-Wunused-but-set-variable]
    .../ethernet/micrel/ksz884x.c:1652:7: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable]
    .../ethernet/micrel/ksz884x.c:1652:7: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable]
    .../ethernet/micrel/ksz884x.c:1652:7: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable]
    .../ethernet/micrel/ksz884x.c:1652:7: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable]
    .../ethernet/micrel/ksz884x.c:4981:6: warning: variable ‘rx_status’ set but not used [-Wunused-but-set-variable]
    .../ethernet/micrel/ksz884x.c:6510:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
    .../ethernet/micrel/ksz884x.c:6087: warning: cannot understand function prototype: 'struct hw_regs '
    .../ethernet/microchip/lan743x_main.c:161:6: warning: variable ‘int_en’ set but not used [-Wunused-but-set-variable]
    .../ethernet/microchip/lan743x_main.c:1702:6: warning: variable ‘int_sts’ set but not used [-Wunused-but-set-variable]
    .../ethernet/microchip/lan743x_main.c:3041:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
    .../ethernet/natsemi/ns83820.c:603:6: warning: variable ‘tbisr’ set but not used [-Wunused-but-set-variable]
    .../ethernet/natsemi/ns83820.c:1207:11: warning: variable ‘tanar’ set but not used [-Wunused-but-set-variable]
    .../ethernet/marvell/mvneta.c:754:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable]
    .../ethernet/neterion/vxge/vxge-traffic.c:33:6: warning: variable ‘val64’ set but not used [-Wunused-but-set-variable]
    .../ethernet/neterion/vxge/vxge-traffic.c:160:6: warning: variable ‘val64’ set but not used [-Wunused-but-set-variable]
    .../ethernet/neterion/vxge/vxge-traffic.c:490:6: warning: variable ‘val32’ set but not used [-Wunused-but-set-variable]
    .../ethernet/neterion/vxge/vxge-traffic.c:2378:6: warning: variable ‘val64’ set but not used [-Wunused-but-set-variable]
    .../ethernet/packetengines/yellowfin.c:1063:18: warning: variable ‘yf_size’ set but not used [-Wunused-but-set-variable]
    .../ethernet/realtek/8139cp.c:1242:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
    .../ethernet/mellanox/mlx4/en_tx.c:858:6: warning: variable ‘ring_cons’ set but not used [-Wunused-but-set-variable]
    .../ethernet/sis/sis900.c:792:6: warning: variable ‘status’ set but not used [-Wunused-but-set-variable]
    .../ethernet/sfc/falcon/farch.c:878:11: warning: variable ‘rx_ev_pkt_type’ set but not used [-Wunused-but-set-variable]
    .../ethernet/sfc/falcon/farch.c:877:23: warning: variable ‘rx_ev_mcast_pkt’ set but not used [-Wunused-but-set-variable]
    .../ethernet/sfc/falcon/farch.c:877:7: warning: variable ‘rx_ev_hdr_type’ set but not used [-Wunused-but-set-variable]
    .../ethernet/sfc/falcon/farch.c:876:7: warning: variable ‘rx_ev_other_err’ set but not used [-Wunused-but-set-variable]
    .../ethernet/sfc/falcon/farch.c:1646:21: warning: variable ‘buftbl_min’ set but not used [-Wunused-but-set-variable]
    .../ethernet/sfc/falcon/farch.c:2535:32: warning: variable ‘spec’ set but not used [-Wunused-but-set-variable]
    .../ethernet/via/via-velocity.c:880:6: warning: variable ‘curr_status’ set but not used [-Wunused-but-set-variable]
    .../ethernet/ti/tlan.c:656:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
    .../ethernet/ti/davinci_emac.c:1230:6: warning: variable ‘num_tx_pkts’ set but not used [-Wunused-but-set-variable]
    .../ethernet/synopsys/dwc-xlgmac-common.c:516:8: warning: variable ‘str’ set but not used [-Wunused-but-set-variable]
    .../ethernet/ti/cpsw_new.c:1662:22: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable]
    
    The register reads should be OK, because the current
    implementation of readl and friends will always execute even
    without an lvalue.
    
    When it makes sense, just remove the lvalue assignment and the
    local. Other times, just remove the offending code, and
    occasionally, just mark the variable as maybe unused since it
    could be used in an ifdef or debug scenario.
    
    Only compile tested with W=1.
    
    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Acked-by: Edward Cree <ecree@solarflare.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [fixes gcc-11 build warnings - gregkh]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 776fba1486be884dab42e7000bbeed7737adc13f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 31 08:35:11 2021 +0200

    i915: fix build warning in intel_dp_get_link_status()
    
    There is a build warning using gcc-11 showing a mis-match in the .h and .c
    definitions of intel_dp_get_link_status():
      CC [M]  drivers/gpu/drm/i915/display/intel_dp.o
    drivers/gpu/drm/i915/display/intel_dp.c:4139:56: warning: argument 2 of type ‘u8[6]’ {aka ‘unsigned char[6]’} with mismatched bound [-Warray-parameter=]
     4139 | intel_dp_get_link_status(struct intel_dp *intel_dp, u8 link_status[DP_LINK_STATUS_SIZE])
          |                                                     ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    In file included from drivers/gpu/drm/i915/display/intel_dp.c:51:
    drivers/gpu/drm/i915/display/intel_dp.h:105:57: note: previously declared as ‘u8 *’ {aka ‘unsigned char *’}
      105 | intel_dp_get_link_status(struct intel_dp *intel_dp, u8 *link_status);
          |                                                     ~~~~^~~~~~~~~~~
    
    This was fixed accidentally commit b30edfd8d0b4 ("drm/i915: Switch to LTTPR
    non-transparent mode link training") by getting rid of the function entirely,
    but that is not a viable backport for a stable kernel, so just fix up the
    function definition to remove the build warning entirely.  There is no
    functional change for this, and it fixes up one of the last 'make allmodconfig'
    build warnings when using gcc-11 on this kernel tree.
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c561d83be40faf4f5dd356ad018e79968b86cd59
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat May 8 11:30:22 2021 -0700

    drm/i915/display: fix compiler warning about array overrun
    
    commit fec4d42724a1bf3dcba52307e55375fdb967b852 upstream.
    
    intel_dp_check_mst_status() uses a 14-byte array to read the DPRX Event
    Status Indicator data, but then passes that buffer at offset 10 off as
    an argument to drm_dp_channel_eq_ok().
    
    End result: there are only 4 bytes remaining of the buffer, yet
    drm_dp_channel_eq_ok() wants a 6-byte buffer.  gcc-11 correctly warns
    about this case:
    
      drivers/gpu/drm/i915/display/intel_dp.c: In function ‘intel_dp_check_mst_status’:
      drivers/gpu/drm/i915/display/intel_dp.c:3491:22: warning: ‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4 [-Wstringop-overread]
       3491 |                     !drm_dp_channel_eq_ok(&esi[10], intel_dp->lane_count)) {
            |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/gpu/drm/i915/display/intel_dp.c:3491:22: note: referencing argument 1 of type ‘const u8 *’ {aka ‘const unsigned char *’}
      In file included from drivers/gpu/drm/i915/display/intel_dp.c:38:
      include/drm/drm_dp_helper.h:1466:6: note: in a call to function ‘drm_dp_channel_eq_ok’
       1466 | bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE],
            |      ^~~~~~~~~~~~~~~~~~~~
           6:14 elapsed
    
    This commit just extends the original array by 2 zero-initialized bytes,
    avoiding the warning.
    
    There may be some underlying bug in here that caused this confusion, but
    this is at least no worse than the existing situation that could use
    random data off the stack.
    
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3d5ff235ec502181d7d2467028a5be820154b17
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun May 16 17:54:17 2021 -0700

    MIPS: ralink: export rt_sysc_membase for rt2880_wdt.c
    
    [ Upstream commit fef532ea0cd871afab7d9a7b6e9da99ac2c24371 ]
    
    rt2880_wdt.c uses (well, attempts to use) rt_sysc_membase. However,
    when this watchdog driver is built as a loadable module, there is a
    build error since the rt_sysc_membase symbol is not exported.
    Export it to quell the build error.
    
    ERROR: modpost: "rt_sysc_membase" [drivers/watchdog/rt2880_wdt.ko] undefined!
    
    Fixes: 473cf939ff34 ("watchdog: add ralink watchdog driver")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Wim Van Sebroeck <wim@iguana.be>
    Cc: John Crispin <john@phrozen.org>
    Cc: linux-mips@vger.kernel.org
    Cc: linux-watchdog@vger.kernel.org
    Acked-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86a62df8f4d4512c3d20e072fc7747b03bf945e8
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun May 16 17:01:08 2021 -0700

    MIPS: alchemy: xxs1500: add gpio-au1000.h header file
    
    [ Upstream commit ff4cff962a7eedc73e54b5096693da7f86c61346 ]
    
    board-xxs1500.c references 2 functions without declaring them, so add
    the header file to placate the build.
    
    ../arch/mips/alchemy/board-xxs1500.c: In function 'board_setup':
    ../arch/mips/alchemy/board-xxs1500.c:56:2: error: implicit declaration of function 'alchemy_gpio1_input_enable' [-Werror=implicit-function-declaration]
       56 |  alchemy_gpio1_input_enable();
    ../arch/mips/alchemy/board-xxs1500.c:57:2: error: implicit declaration of function 'alchemy_gpio2_enable'; did you mean 'alchemy_uart_enable'? [-Werror=implicit-function-declaration]
       57 |  alchemy_gpio2_enable();
    
    Fixes: 8e026910fcd4 ("MIPS: Alchemy: merge GPR/MTX-1/XXS1500 board code into single files")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: linux-mips@vger.kernel.org
    Cc: Manuel Lauss <manuel.lauss@googlemail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Acked-by: Manuel Lauss <manuel.lauss@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2221f233cc9e8af2f6f2448bcd791cad4f7f317c
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Sun May 23 14:38:53 2021 +0000

    sch_dsmark: fix a NULL deref in qdisc_reset()
    
    [ Upstream commit 9b76eade16423ef06829cccfe3e100cfce31afcd ]
    
    If Qdisc_ops->init() is failed, Qdisc_ops->reset() would be called.
    When dsmark_init(Qdisc_ops->init()) is failed, it possibly doesn't
    initialize dsmark_qdisc_data->q. But dsmark_reset(Qdisc_ops->reset())
    uses dsmark_qdisc_data->q pointer wihtout any null checking.
    So, panic would occur.
    
    Test commands:
        sysctl net.core.default_qdisc=dsmark -w
        ip link add dummy0 type dummy
        ip link add vw0 link dummy0 type virt_wifi
        ip link set vw0 up
    
    Splat looks like:
    KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
    CPU: 3 PID: 684 Comm: ip Not tainted 5.12.0+ #910
    RIP: 0010:qdisc_reset+0x2b/0x680
    Code: 1f 44 00 00 48 b8 00 00 00 00 00 fc ff df 41 57 41 56 41 55 41 54
    55 48 89 fd 48 83 c7 18 53 48 89 fa 48 c1 ea 03 48 83 ec 20 <80> 3c 02
    00 0f 85 09 06 00 00 4c 8b 65 18 0f 1f 44 00 00 65 8b 1d
    RSP: 0018:ffff88800fda6bf8 EFLAGS: 00010282
    RAX: dffffc0000000000 RBX: ffff8880050ed800 RCX: 0000000000000000
    RDX: 0000000000000003 RSI: ffffffff99e34100 RDI: 0000000000000018
    RBP: 0000000000000000 R08: fffffbfff346b553 R09: fffffbfff346b553
    R10: 0000000000000001 R11: fffffbfff346b552 R12: ffffffffc0824940
    R13: ffff888109e83800 R14: 00000000ffffffff R15: ffffffffc08249e0
    FS:  00007f5042287680(0000) GS:ffff888119800000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055ae1f4dbd90 CR3: 0000000006760002 CR4: 00000000003706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     ? rcu_read_lock_bh_held+0xa0/0xa0
     dsmark_reset+0x3d/0xf0 [sch_dsmark]
     qdisc_reset+0xa9/0x680
     qdisc_destroy+0x84/0x370
     qdisc_create_dflt+0x1fe/0x380
     attach_one_default_qdisc.constprop.41+0xa4/0x180
     dev_activate+0x4d5/0x8c0
     ? __dev_open+0x268/0x390
     __dev_open+0x270/0x390
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a052751302b75e2539eb87ec31c696c067a2398d
Author: Stefan Roese <sr@denx.de>
Date:   Sat May 22 09:56:30 2021 +0200

    net: ethernet: mtk_eth_soc: Fix packet statistics support for MT7628/88
    
    [ Upstream commit ad79fd2c42f7626bdf6935cd72134c2a5a59ff2d ]
    
    The MT7628/88 SoC(s) have other (limited) packet counter registers than
    currently supported in the mtk_eth_soc driver. This patch adds support
    for reading these registers, so that the packet statistics are correctly
    updated.
    
    Additionally the defines for the non-MT7628 variant packet counter
    registers are added and used in this patch instead of using hard coded
    values.
    
    Signed-off-by: Stefan Roese <sr@denx.de>
    Fixes: 296c9120752b ("net: ethernet: mediatek: Add MT7628/88 SoC support")
    Cc: Felix Fietkau <nbd@nbd.name>
    Cc: John Crispin <john@phrozen.org>
    Cc: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
    Cc: Reto Schneider <code@reto-schneider.ch>
    Cc: Reto Schneider <reto.schneider@husqvarnagroup.com>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 162b11831f77d141e3e67294d7e83770a071158f
Author: kernel test robot <lkp@intel.com>
Date:   Sun May 23 02:09:00 2021 +0800

    ALSA: usb-audio: scarlett2: snd_scarlett_gen2_controls_create() can be static
    
    [ Upstream commit 2b899f31f1a6db2db4608bac2ac04fe2c4ad89eb ]
    
    sound/usb/mixer_scarlett_gen2.c:2000:5: warning: symbol 'snd_scarlett_gen2_controls_create' was not declared. Should it be static?
    
    Fixes: 265d1a90e4fb ("ALSA: usb-audio: scarlett2: Improve driver startup messages")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/r/20210522180900.GA83915@f59a3af2f1d9
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3bfb58517d06e7baf65be1cd2e1498dc11147915
Author: Francesco Ruggeri <fruggeri@arista.com>
Date:   Fri May 21 13:21:14 2021 -0700

    ipv6: record frag_max_size in atomic fragments in input path
    
    [ Upstream commit e29f011e8fc04b2cdc742a2b9bbfa1b62518381a ]
    
    Commit dbd1759e6a9c ("ipv6: on reassembly, record frag_max_size")
    filled the frag_max_size field in IP6CB in the input path.
    The field should also be filled in case of atomic fragments.
    
    Fixes: dbd1759e6a9c ('ipv6: on reassembly, record frag_max_size')
    Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8bb1077448d43a871ed667520763e3b9f9b7975d
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Date:   Fri May 21 16:45:58 2021 +0200

    net: lantiq: fix memory corruption in RX ring
    
    [ Upstream commit c7718ee96dbc2f9c5fc3b578abdf296dd44b9c20 ]
    
    In a situation where memory allocation or dma mapping fails, an
    invalid address is programmed into the descriptor. This can lead
    to memory corruption. If the memory allocation fails, DMA should
    reuse the previous skb and mapping and drop the packet. This patch
    also increments rx drop counter.
    
    Fixes: fe1a56420cf2 ("net: lantiq: Add Lantiq / Intel VRX200 Ethernet driver ")
    Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fda8f74d39751654e5acac95d1ab6874db949865
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed May 19 17:20:27 2021 +0300

    scsi: libsas: Use _safe() loop in sas_resume_port()
    
    [ Upstream commit 8c7e7b8486cda21269d393245883c5e4737d5ee7 ]
    
    If sas_notify_lldd_dev_found() fails then this code calls:
    
            sas_unregister_dev(port, dev);
    
    which removes "dev", our list iterator, from the list.  This could lead to
    an endless loop.  We need to use list_for_each_entry_safe().
    
    Link: https://lore.kernel.org/r/YKUeq6gwfGcvvhty@mwanda
    Fixes: 303694eeee5e ("[SCSI] libsas: suspend / resume support")
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf20c704a26eb763daf6bfb10369a4f11fef2d9a
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date:   Thu May 20 11:18:35 2021 -0700

    ixgbe: fix large MTU request from VF
    
    [ Upstream commit 63e39d29b3da02e901349f6cd71159818a4737a6 ]
    
    Check that the MTU value requested by the VF is in the supported
    range of MTUs before attempting to set the VF large packet enable,
    otherwise reject the request. This also avoids unnecessary
    register updates in the case of the 82599 controller.
    
    Fixes: 872844ddb9e4 ("ixgbe: Enable jumbo frames support w/ SR-IOV")
    Co-developed-by: Piotr Skajewski <piotrx.skajewski@intel.com>
    Signed-off-by: Piotr Skajewski <piotrx.skajewski@intel.com>
    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Co-developed-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a143b92d1dc0dfba1c310c9212a30dd272f037a
Author: Jussi Maki <joamaki@gmail.com>
Date:   Wed May 19 15:47:42 2021 +0000

    bpf: Set mac_len in bpf_skb_change_head
    
    [ Upstream commit 84316ca4e100d8cbfccd9f774e23817cb2059868 ]
    
    The skb_change_head() helper did not set "skb->mac_len", which is
    problematic when it's used in combination with skb_redirect_peer().
    Without it, redirecting a packet from a L3 device such as wireguard to
    the veth peer device will cause skb->data to point to the middle of the
    IP header on entry to tcp_v4_rcv() since the L2 header is not pulled
    correctly due to mac_len=0.
    
    Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure")
    Signed-off-by: Jussi Maki <joamaki@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20210519154743.2554771-2-joamaki@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 272729d56b2d308de38dab5760515c1653a09e60
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu May 20 08:08:24 2021 +0300

    ASoC: cs35l33: fix an error code in probe()
    
    [ Upstream commit 833bc4cf9754643acc69b3c6b65988ca78df4460 ]
    
    This error path returns zero (success) but it should return -EINVAL.
    
    Fixes: 3333cb7187b9 ("ASoC: cs35l33: Initial commit of the cs35l33 CODEC driver.")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/YKXuyGEzhPT35R3G@mwanda
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ee1d6e23108303e426ede13e19cbc1007abfae4
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed May 19 17:16:50 2021 +0300

    staging: emxx_udc: fix loop in _nbu2ss_nuke()
    
    [ Upstream commit e0112a7c9e847ada15a631b88e279d547e8f26a7 ]
    
    The _nbu2ss_ep_done() function calls:
    
            list_del_init(&req->queue);
    
    which means that the loop will never exit.
    
    Fixes: ca3d253eb967 ("Staging: emxx_udc: Iterate list using list_for_each_entry")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YKUd0sDyjm/lkJfJ@mwanda
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0bf49b3c8d8b3a43ce09f1b2db70e5484d31fcdf
Author: Raju Rangoju <rajur@chelsio.com>
Date:   Wed May 19 16:48:31 2021 +0530

    cxgb4: avoid accessing registers when clearing filters
    
    [ Upstream commit 88c380df84fbd03f9b137c2b9d0a44b9f2f553b0 ]
    
    Hardware register having the server TID base can contain
    invalid values when adapter is in bad state (for example,
    due to AER fatal error). Reading these invalid values in the
    register can lead to out-of-bound memory access. So, fix
    by using the saved server TID base when clearing filters.
    
    Fixes: b1a79360ee86 ("cxgb4: Delete all hash and TCAM filters before resource cleanup")
    Signed-off-by: Raju Rangoju <rajur@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68b5fc6ec52f6dd47b32ce86a48a4f80c6fd29cd
Author: David Awogbemila <awogbemila@google.com>
Date:   Mon May 17 14:08:15 2021 -0700

    gve: Correct SKB queue index validation.
    
    [ Upstream commit fbd4a28b4fa66faaa7f510c0adc531d37e0a7848 ]
    
    SKBs with skb_get_queue_mapping(skb) == tx_cfg.num_queues should also be
    considered invalid.
    
    Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
    Signed-off-by: David Awogbemila <awogbemila@google.com>
    Acked-by: Willem de Brujin <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f4752e4d8db048693b165ce35aad7239984b4c6
Author: Catherine Sullivan <csully@google.com>
Date:   Mon May 17 14:08:14 2021 -0700

    gve: Upgrade memory barrier in poll routine
    
    [ Upstream commit f81781835f0adfae8d701545386030d223efcd6f ]
    
    As currently written, if the driver checks for more work (via
    gve_tx_poll or gve_rx_poll) before the device posts work and the
    irq doorbell is not unmasked
    (via iowrite32be(GVE_IRQ_ACK | GVE_IRQ_EVENT, ...)) before the device
    attempts to raise an interrupt, an interrupt is lost and this could
    potentially lead to the traffic being completely halted. For
    example, if a tx queue has already been stopped, the driver won't get
    the chance to complete work and egress will be halted.
    
    We need a full memory barrier in the poll
    routine to ensure that the irq doorbell is unmasked before the driver
    checks for more work.
    
    Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
    Signed-off-by: Catherine Sullivan <csully@google.com>
    Signed-off-by: David Awogbemila <awogbemila@google.com>
    Acked-by: Willem de Brujin <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 821149ee88c206fa37e79c1868cc270518484876
Author: David Awogbemila <awogbemila@google.com>
Date:   Mon May 17 14:08:13 2021 -0700

    gve: Add NULL pointer checks when freeing irqs.
    
    [ Upstream commit 5218e919c8d06279884aa0baf76778a6817d5b93 ]
    
    When freeing notification blocks, we index priv->msix_vectors.
    If we failed to allocate priv->msix_vectors (see abort_with_msix_vectors)
    this could lead to a NULL pointer dereference if the driver is unloaded.
    
    Fixes: 893ce44df565 ("gve: Add basic driver framework for Compute Engine Virtual NIC")
    Signed-off-by: David Awogbemila <awogbemila@google.com>
    Acked-by: Willem de Brujin <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6abd1d1983f27e9abe4918130fef0b19c1e5dd71
Author: David Awogbemila <awogbemila@google.com>
Date:   Mon May 17 14:08:12 2021 -0700

    gve: Update mgmt_msix_idx if num_ntfy changes
    
    [ Upstream commit e96b491a0ffa35a8a9607c193fa4d894ca9fb32f ]
    
    If we do not get the expected number of vectors from
    pci_enable_msix_range, we update priv->num_ntfy_blks but not
    priv->mgmt_msix_idx. This patch fixes this so that priv->mgmt_msix_idx
    is updated accordingly.
    
    Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
    Signed-off-by: David Awogbemila <awogbemila@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 13c4d8986125973884f9a99cf8875d89ba76875c
Author: Catherine Sullivan <csully@google.com>
Date:   Mon May 17 14:08:11 2021 -0700

    gve: Check TX QPL was actually assigned
    
    [ Upstream commit 5aec55b46c6238506cdf0c60cd0e42ab77a1e5e0 ]
    
    Correctly check the TX QPL was assigned and unassigned if
    other steps in the allocation fail.
    
    Fixes: f5cedc84a30d (gve: Add transmit and receive support)
    Signed-off-by: Catherine Sullivan <csully@google.com>
    Signed-off-by: David Awogbemila <awogbemila@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 37d697759958d111439080bab7e14d2b0e7b39f5
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Sun May 16 14:44:42 2021 +0000

    mld: fix panic in mld_newpack()
    
    [ Upstream commit 020ef930b826d21c5446fdc9db80fd72a791bc21 ]
    
    mld_newpack() doesn't allow to allocate high order page,
    only order-0 allocation is allowed.
    If headroom size is too large, a kernel panic could occur in skb_put().
    
    Test commands:
        ip netns del A
        ip netns del B
        ip netns add A
        ip netns add B
        ip link add veth0 type veth peer name veth1
        ip link set veth0 netns A
        ip link set veth1 netns B
    
        ip netns exec A ip link set lo up
        ip netns exec A ip link set veth0 up
        ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0
        ip netns exec B ip link set lo up
        ip netns exec B ip link set veth1 up
        ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1
        for i in {1..99}
        do
            let A=$i-1
            ip netns exec A ip link add ip6gre$i type ip6gre \
            local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100
            ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i
            ip netns exec A ip link set ip6gre$i up
    
            ip netns exec B ip link add ip6gre$i type ip6gre \
            local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100
            ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i
            ip netns exec B ip link set ip6gre$i up
        done
    
    Splat looks like:
    kernel BUG at net/core/skbuff.c:110!
    invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
    CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891
    Workqueue: ipv6_addrconf addrconf_dad_work
    RIP: 0010:skb_panic+0x15d/0x15f
    Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83
    41 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff <0f> 0b 48 8b 6c 24 20 89
    34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20
    RSP: 0018:ffff88810091f820 EFLAGS: 00010282
    RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000
    RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb
    RBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031
    R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028
    R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0
    FS:  0000000000000000(0000) GS:ffff888117c00000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600
     ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600
     skb_put.cold.104+0x22/0x22
     ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600
     ? rcu_read_lock_sched_held+0x91/0xc0
     mld_newpack+0x398/0x8f0
     ? ip6_mc_hdr.isra.26.constprop.46+0x600/0x600
     ? lock_contended+0xc40/0xc40
     add_grhead.isra.33+0x280/0x380
     add_grec+0x5ca/0xff0
     ? mld_sendpack+0xf40/0xf40
     ? lock_downgrade+0x690/0x690
     mld_send_initial_cr.part.34+0xb9/0x180
     ipv6_mc_dad_complete+0x15d/0x1b0
     addrconf_dad_completed+0x8d2/0xbb0
     ? lock_downgrade+0x690/0x690
     ? addrconf_rs_timer+0x660/0x660
     ? addrconf_dad_work+0x73c/0x10e0
     addrconf_dad_work+0x73c/0x10e0
    
    Allowing high order page allocation could fix this problem.
    
    Fixes: 72e09ad107e7 ("ipv6: avoid high order allocations")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0fb7437789185bf4466c99be9e8f7b593c99c9f
Author: Andy Gospodarek <gospo@broadcom.com>
Date:   Sat May 15 03:25:18 2021 -0400

    bnxt_en: Include new P5 HV definition in VF check.
    
    [ Upstream commit ab21494be9dc7d62736c5fcd06be65d49df713ee ]
    
    Otherwise, some of the recently added HyperV VF IDs would not be
    recognized as VF devices and they would not initialize properly.
    
    Fixes: 7fbf359bb2c1 ("bnxt_en: Add PCI IDs for Hyper-V VF devices.")
    Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
    Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7b5b4e26bf58a72b1a63d15debc5715ccd5432b
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 15 15:16:05 2021 +0800

    net: bnx2: Fix error return code in bnx2_init_board()
    
    [ Upstream commit 28c66b6da4087b8cfe81c2ec0a46eb6116dafda9 ]
    
    Fix to return -EPERM from the error handling case instead of 0, as done
    elsewhere in this function.
    
    Fixes: b6016b767397 ("[BNX2]: New Broadcom gigabit network driver.")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a79654b9076353fa2f55028e1f8e873c018a4c8
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri May 14 17:24:48 2021 +0300

    net: hso: check for allocation failure in hso_create_bulk_serial_device()
    
    [ Upstream commit 31db0dbd72444abe645d90c20ecb84d668f5af5e ]
    
    In current kernels, small allocations never actually fail so this
    patch shouldn't affect runtime.
    
    Originally this error handling code written with the idea that if
    the "serial->tiocmget" allocation failed, then we would continue
    operating instead of bailing out early.  But in later years we added
    an unchecked dereference on the next line.
    
            serial->tiocmget->serial_state_notification = kzalloc();
            ^^^^^^^^^^^^^^^^^^
    
    Since these allocations are never going fail in real life, this is
    mostly a philosophical debate, but I think bailing out early is the
    correct behavior that the user would want.  And generally it's safer to
    bail as soon an error happens.
    
    Fixes: af0de1303c4e ("usb: hso: obey DMA rules in tiocmget")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48da4c0577fe8e9d474a9a1b479f6582b2044c5a
Author: Yunsheng Lin <linyunsheng@huawei.com>
Date:   Fri May 14 11:17:01 2021 +0800

    net: sched: fix tx action reschedule issue with stopped queue
    
    [ Upstream commit dcad9ee9e0663d74a89b25b987f9c7be86432812 ]
    
    The netdev qeueue might be stopped when byte queue limit has
    reached or tx hw ring is full, net_tx_action() may still be
    rescheduled if STATE_MISSED is set, which consumes unnecessary
    cpu without dequeuing and transmiting any skb because the
    netdev queue is stopped, see qdisc_run_end().
    
    This patch fixes it by checking the netdev queue state before
    calling qdisc_run() and clearing STATE_MISSED if netdev queue is
    stopped during qdisc_run(), the net_tx_action() is rescheduled
    again when netdev qeueue is restarted, see netif_tx_wake_queue().
    
    As there is time window between netif_xmit_frozen_or_stopped()
    checking and STATE_MISSED clearing, between which STATE_MISSED
    may set by net_tx_action() scheduled by netif_tx_wake_queue(),
    so set the STATE_MISSED again if netdev queue is restarted.
    
    Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking")
    Reported-by: Michal Kubecek <mkubecek@suse.cz>
    Acked-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 515e7c595d846a504af127d4fa30179f3a54498b
Author: Yunsheng Lin <linyunsheng@huawei.com>
Date:   Fri May 14 11:17:00 2021 +0800

    net: sched: fix tx action rescheduling issue during deactivation
    
    [ Upstream commit 102b55ee92f9fda4dde7a45d2b20538e6e3e3d1e ]
    
    Currently qdisc_run() checks the STATE_DEACTIVATED of lockless
    qdisc before calling __qdisc_run(), which ultimately clear the
    STATE_MISSED when all the skb is dequeued. If STATE_DEACTIVATED
    is set before clearing STATE_MISSED, there may be rescheduling
    of net_tx_action() at the end of qdisc_run_end(), see below:
    
    CPU0(net_tx_atcion)  CPU1(__dev_xmit_skb)  CPU2(dev_deactivate)
              .                   .                     .
              .            set STATE_MISSED             .
              .           __netif_schedule()            .
              .                   .           set STATE_DEACTIVATED
              .                   .                qdisc_reset()
              .                   .                     .
              .<---------------   .              synchronize_net()
    clear __QDISC_STATE_SCHED  |  .                     .
              .                |  .                     .
              .                |  .            some_qdisc_is_busy()
              .                |  .               return *false*
              .                |  .                     .
      test STATE_DEACTIVATED   |  .                     .
    __qdisc_run() *not* called |  .                     .
              .                |  .                     .
       test STATE_MISS         |  .                     .
     __netif_schedule()--------|  .                     .
              .                   .                     .
              .                   .                     .
    
    __qdisc_run() is not called by net_tx_atcion() in CPU0 because
    CPU2 has set STATE_DEACTIVATED flag during dev_deactivate(), and
    STATE_MISSED is only cleared in __qdisc_run(), __netif_schedule
    is called at the end of qdisc_run_end(), causing tx action
    rescheduling problem.
    
    qdisc_run() called by net_tx_action() runs in the softirq context,
    which should has the same semantic as the qdisc_run() called by
    __dev_xmit_skb() protected by rcu_read_lock_bh(). And there is a
    synchronize_net() between STATE_DEACTIVATED flag being set and
    qdisc_reset()/some_qdisc_is_busy in dev_deactivate(), we can safely
    bail out for the deactived lockless qdisc in net_tx_action(), and
    qdisc_reset() will reset all skb not dequeued yet.
    
    So add the rcu_read_lock() explicitly to protect the qdisc_run()
    and do the STATE_DEACTIVATED checking in net_tx_action() before
    calling qdisc_run_begin(). Another option is to do the checking in
    the qdisc_run_end(), but it will add unnecessary overhead for
    non-tx_action case, because __dev_queue_xmit() will not see qdisc
    with STATE_DEACTIVATED after synchronize_net(), the qdisc with
    STATE_DEACTIVATED can only be seen by net_tx_action() because of
    __netif_schedule().
    
    The STATE_DEACTIVATED checking in qdisc_run() is to avoid race
    between net_tx_action() and qdisc_reset(), see:
    commit d518d2ed8640 ("net/sched: fix race between deactivation
    and dequeue for NOLOCK qdisc"). As the bailout added above for
    deactived lockless qdisc in net_tx_action() provides better
    protection for the race without calling qdisc_run() at all, so
    remove the STATE_DEACTIVATED checking in qdisc_run().
    
    After qdisc_reset(), there is no skb in qdisc to be dequeued, so
    clear the STATE_MISSED in dev_reset_queue() too.
    
    Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking")
    Acked-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
    V8: Clearing STATE_MISSED before calling __netif_schedule() has
        avoid the endless rescheduling problem, but there may still
        be a unnecessary rescheduling, so adjust the commit log.
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c25c7621fb78887b4d28f86a19719c024e3665a
Author: Yunsheng Lin <linyunsheng@huawei.com>
Date:   Fri May 14 11:16:59 2021 +0800

    net: sched: fix packet stuck problem for lockless qdisc
    
    [ Upstream commit a90c57f2cedd52a511f739fb55e6244e22e1a2fb ]
    
    Lockless qdisc has below concurrent problem:
        cpu0                 cpu1
         .                     .
    q->enqueue                 .
         .                     .
    qdisc_run_begin()          .
         .                     .
    dequeue_skb()              .
         .                     .
    sch_direct_xmit()          .
         .                     .
         .                q->enqueue
         .             qdisc_run_begin()
         .            return and do nothing
         .                     .
    qdisc_run_end()            .
    
    cpu1 enqueue a skb without calling __qdisc_run() because cpu0
    has not released the lock yet and spin_trylock() return false
    for cpu1 in qdisc_run_begin(), and cpu0 do not see the skb
    enqueued by cpu1 when calling dequeue_skb() because cpu1 may
    enqueue the skb after cpu0 calling dequeue_skb() and before
    cpu0 calling qdisc_run_end().
    
    Lockless qdisc has below another concurrent problem when
    tx_action is involved:
    
    cpu0(serving tx_action)     cpu1             cpu2
              .                   .                .
              .              q->enqueue            .
              .            qdisc_run_begin()       .
              .              dequeue_skb()         .
              .                   .            q->enqueue
              .                   .                .
              .             sch_direct_xmit()      .
              .                   .         qdisc_run_begin()
              .                   .       return and do nothing
              .                   .                .
     clear __QDISC_STATE_SCHED    .                .
     qdisc_run_begin()            .                .
     return and do nothing        .                .
              .                   .                .
              .            qdisc_run_end()         .
    
    This patch fixes the above data race by:
    1. If the first spin_trylock() return false and STATE_MISSED is
       not set, set STATE_MISSED and retry another spin_trylock() in
       case other CPU may not see STATE_MISSED after it releases the
       lock.
    2. reschedule if STATE_MISSED is set after the lock is released
       at the end of qdisc_run_end().
    
    For tx_action case, STATE_MISSED is also set when cpu1 is at the
    end if qdisc_run_end(), so tx_action will be rescheduled again
    to dequeue the skb enqueued by cpu2.
    
    Clear STATE_MISSED before retrying a dequeuing when dequeuing
    returns NULL in order to reduce the overhead of the second
    spin_trylock() and __netif_schedule() calling.
    
    Also clear the STATE_MISSED before calling __netif_schedule()
    at the end of qdisc_run_end() to avoid doing another round of
    dequeuing in the pfifo_fast_dequeue().
    
    The performance impact of this patch, tested using pktgen and
    dummy netdev with pfifo_fast qdisc attached:
    
     threads  without+this_patch   with+this_patch      delta
        1        2.61Mpps            2.60Mpps           -0.3%
        2        3.97Mpps            3.82Mpps           -3.7%
        4        5.62Mpps            5.59Mpps           -0.5%
        8        2.78Mpps            2.77Mpps           -0.3%
       16        2.22Mpps            2.22Mpps           -0.0%
    
    Fixes: 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking")
    Acked-by: Jakub Kicinski <kuba@kernel.org>
    Tested-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a04790d104e264c460db17509234f811c5b17a6f
Author: Jim Ma <majinjing3@gmail.com>
Date:   Fri May 14 11:11:02 2021 +0800

    tls splice: check SPLICE_F_NONBLOCK instead of MSG_DONTWAIT
    
    [ Upstream commit 974271e5ed45cfe4daddbeb16224a2156918530e ]
    
    In tls_sw_splice_read, checkout MSG_* is inappropriate, should use
    SPLICE_*, update tls_wait_data to accept nonblock arguments instead
    of flags for recvmsg and splice.
    
    Fixes: c46234ebb4d1 ("tls: RX path for ktls")
    Signed-off-by: Jim Ma <majinjing3@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5c01181700ab93b3892c0a2730915a3bc1f582f3
Author: Tao Liu <thomas.liu@ucloud.cn>
Date:   Thu May 13 21:08:00 2021 +0800

    openvswitch: meter: fix race when getting now_ms.
    
    [ Upstream commit e4df1b0c24350a0f00229ff895a91f1072bd850d ]
    
    We have observed meters working unexpected if traffic is 3+Gbit/s
    with multiple connections.
    
    now_ms is not pretected by meter->lock, we may get a negative
    long_delta_ms when another cpu updated meter->used, then:
        delta_ms = (u32)long_delta_ms;
    which will be a large value.
    
        band->bucket += delta_ms * band->rate;
    then we get a wrong band->bucket.
    
    OpenVswitch userspace datapath has fixed the same issue[1] some
    time ago, and we port the implementation to kernel datapath.
    
    [1] https://patchwork.ozlabs.org/project/openvswitch/patch/20191025114436.9746-1-i.maximets@ovn.org/
    
    Fixes: 96fbc13d7e77 ("openvswitch: Add meter infrastructure")
    Signed-off-by: Tao Liu <thomas.liu@ucloud.cn>
    Suggested-by: Ilya Maximets <i.maximets@ovn.org>
    Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bfdc481d8123f35a0fade7453c9641f2305b643
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu May 13 09:24:55 2021 +0200

    net: mdio: octeon: Fix some double free issues
    
    [ Upstream commit e1d027dd97e1e750669cdc0d3b016a4f54e473eb ]
    
    'bus->mii_bus' has been allocated with 'devm_mdiobus_alloc_size()' in the
    probe function. So it must not be freed explicitly or there will be a
    double free.
    
    Remove the incorrect 'mdiobus_free' in the error handling path of the
    probe function and in remove function.
    
    Suggested-By: Andrew Lunn <andrew@lunn.ch>
    Fixes: 35d2aeac9810 ("phy: mdio-octeon: Use devm_mdiobus_alloc_size()")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e0fba911ca7dd80ca069c8280354bea9ad63a72
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu May 13 09:44:49 2021 +0200

    net: mdio: thunder: Fix a double free issue in the .remove function
    
    [ Upstream commit a93a0a15876d2a077a3bc260b387d2457a051f24 ]
    
    'bus->mii_bus' have been allocated with 'devm_mdiobus_alloc_size()' in the
    probe function. So it must not be freed explicitly or there will be a
    double free.
    
    Remove the incorrect 'mdiobus_free' in the remove function.
    
    Fixes: 379d7ac7ca31 ("phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20255d41ac560397b6a07d8d87dcc5e2efc7672a
Author: Fugang Duan <fugang.duan@nxp.com>
Date:   Wed May 12 10:43:59 2021 +0800

    net: fec: fix the potential memory leak in fec_enet_init()
    
    [ Upstream commit 619fee9eb13b5d29e4267cb394645608088c28a8 ]
    
    If the memory allocated for cbd_base is failed, it should
    free the memory allocated for the queues, otherwise it causes
    memory leak.
    
    And if the memory allocated for the queues is failed, it can
    return error directly.
    
    Fixes: 59d0f7465644 ("net: fec: init multi queue date structure")
    Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
    Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41f7f37ddefe47e157faeb1cd71e850883bba33c
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue May 11 10:35:21 2021 +0200

    net: really orphan skbs tied to closing sk
    
    [ Upstream commit 098116e7e640ba677d9e345cbee83d253c13d556 ]
    
    If the owing socket is shutting down - e.g. the sock reference
    count already dropped to 0 and only sk_wmem_alloc is keeping
    the sock alive, skb_orphan_partial() becomes a no-op.
    
    When forwarding packets over veth with GRO enabled, the above
    causes refcount errors.
    
    This change addresses the issue with a plain skb_orphan() call
    in the critical scenario.
    
    Fixes: 9adc89af724f ("net: let skb_orphan_partial wake-up waiters.")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 694f68527e755385b8281548ce742065867b4ad9
Author: Eric Farman <farman@linux.ibm.com>
Date:   Tue May 11 21:56:29 2021 +0200

    vfio-ccw: Check initialized flag in cp_init()
    
    [ Upstream commit c6c82e0cd8125d30f2f1b29205c7e1a2f1a6785b ]
    
    We have a really nice flag in the channel_program struct that
    indicates if it had been initialized by cp_init(), and use it
    as a guard in the other cp accessor routines, but not for a
    duplicate call into cp_init(). The possibility of this occurring
    is low, because that flow is protected by the private->io_mutex
    and FSM CP_PROCESSING state. But then why bother checking it
    in (for example) cp_prefetch() then?
    
    Let's just be consistent and check for that in cp_init() too.
    
    Fixes: 71189f263f8a3 ("vfio-ccw: make it safe to access channel programs")
    Signed-off-by: Eric Farman <farman@linux.ibm.com>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Acked-by: Matthew Rosato <mjrosato@linux.ibm.com>
    Message-Id: <20210511195631.3995081-2-farman@linux.ibm.com>
    Signed-off-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5e4479228b52b324984d68fa45733612dddd2fa
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Tue May 11 14:28:55 2021 +0100

    ASoC: cs42l42: Regmap must use_single_read/write
    
    [ Upstream commit 0fad605fb0bdc00d8ad78696300ff2fbdee6e048 ]
    
    cs42l42 does not support standard burst transfers so the use_single_read
    and use_single_write flags must be set in the regmap config.
    
    Because of this bug, the patch:
    
    commit 0a0eb567e1d4 ("ASoC: cs42l42: Minor error paths fixups")
    
    broke cs42l42 probe() because without the use_single_* flags it causes
    regmap to issue a burst read.
    
    However, the missing use_single_* could cause problems anyway because the
    regmap cache can attempt burst transfers if these flags are not set.
    
    Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20210511132855.27159-1-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87803141fb3e5d74ab0f624690bde55c577cedfe
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Sun May 9 22:33:38 2021 +0300

    net: dsa: fix error code getting shifted with 4 in dsa_slave_get_sset_count
    
    [ Upstream commit b94cbc909f1d80378a1f541968309e5c1178c98b ]
    
    DSA implements a bunch of 'standardized' ethtool statistics counters,
    namely tx_packets, tx_bytes, rx_packets, rx_bytes. So whatever the
    hardware driver returns in .get_sset_count(), we need to add 4 to that.
    
    That is ok, except that .get_sset_count() can return a negative error
    code, for example:
    
    b53_get_sset_count
    -> phy_ethtool_get_sset_count
       -> return -EIO
    
    -EIO is -5, and with 4 added to it, it becomes -1, aka -EPERM. One can
    imagine that certain error codes may even become positive, although
    based on code inspection I did not see instances of that.
    
    Check the error code first, if it is negative return it as-is.
    
    Based on a similar patch for dsa_master_get_strings from Dan Carpenter:
    https://patchwork.kernel.org/project/netdevbpf/patch/YJaSe3RPgn7gKxZv@mwanda/
    
    Fixes: 91da11f870f0 ("net: Distributed Switch Architecture protocol support")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4450f733dc3dfb54225383d9f648f5338a46071a
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat May 8 07:38:22 2021 +0200

    net: netcp: Fix an error message
    
    [ Upstream commit ddb6e00f8413e885ff826e32521cff7924661de0 ]
    
    'ret' is known to be 0 here.
    The expected error code is stored in 'tx_pipe->dma_queue', so use it
    instead.
    
    While at it, switch from %d to %pe which is more user friendly.
    
    Fixes: 84640e27f230 ("net: netcp: Add Keystone NetCP core ethernet driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit de2bf5de17be2b552d18ddea9a16b233f4f009e3
Author: Lang Yu <Lang.Yu@amd.com>
Date:   Mon May 17 12:47:20 2021 +0800

    drm/amd/amdgpu: fix a potential deadlock in gpu reset
    
    [ Upstream commit 9c2876d56f1ce9b6b2072f1446fb1e8d1532cb3d ]
    
    When amdgpu_ib_ring_tests failed, the reset logic called
    amdgpu_device_ip_suspend twice, then deadlock occurred.
    Deadlock log:
    
    [  805.655192] amdgpu 0000:04:00.0: amdgpu: ib ring test failed (-110).
    [  806.290952] [drm] free PSP TMR buffer
    
    [  806.319406] ============================================
    [  806.320315] WARNING: possible recursive locking detected
    [  806.321225] 5.11.0-custom #1 Tainted: G        W  OEL
    [  806.322135] --------------------------------------------
    [  806.323043] cat/2593 is trying to acquire lock:
    [  806.323825] ffff888136b1cdc8 (&adev->dm.dc_lock){+.+.}-{3:3}, at: dm_suspend+0xb8/0x1d0 [amdgpu]
    [  806.325668]
                   but task is already holding lock:
    [  806.326664] ffff888136b1cdc8 (&adev->dm.dc_lock){+.+.}-{3:3}, at: dm_suspend+0xb8/0x1d0 [amdgpu]
    [  806.328430]
                   other info that might help us debug this:
    [  806.329539]  Possible unsafe locking scenario:
    
    [  806.330549]        CPU0
    [  806.330983]        ----
    [  806.331416]   lock(&adev->dm.dc_lock);
    [  806.332086]   lock(&adev->dm.dc_lock);
    [  806.332738]
                    *** DEADLOCK ***
    
    [  806.333747]  May be due to missing lock nesting notation
    
    [  806.334899] 3 locks held by cat/2593:
    [  806.335537]  #0: ffff888100d3f1b8 (&attr->mutex){+.+.}-{3:3}, at: simple_attr_read+0x4e/0x110
    [  806.337009]  #1: ffff888136b1fd78 (&adev->reset_sem){++++}-{3:3}, at: amdgpu_device_lock_adev+0x42/0x94 [amdgpu]
    [  806.339018]  #2: ffff888136b1cdc8 (&adev->dm.dc_lock){+.+.}-{3:3}, at: dm_suspend+0xb8/0x1d0 [amdgpu]
    [  806.340869]
                   stack backtrace:
    [  806.341621] CPU: 6 PID: 2593 Comm: cat Tainted: G        W  OEL    5.11.0-custom #1
    [  806.342921] Hardware name: AMD Celadon-CZN/Celadon-CZN, BIOS WLD0C23N_Weekly_20_12_2 12/23/2020
    [  806.344413] Call Trace:
    [  806.344849]  dump_stack+0x93/0xbd
    [  806.345435]  __lock_acquire.cold+0x18a/0x2cf
    [  806.346179]  lock_acquire+0xca/0x390
    [  806.346807]  ? dm_suspend+0xb8/0x1d0 [amdgpu]
    [  806.347813]  __mutex_lock+0x9b/0x930
    [  806.348454]  ? dm_suspend+0xb8/0x1d0 [amdgpu]
    [  806.349434]  ? amdgpu_device_indirect_rreg+0x58/0x70 [amdgpu]
    [  806.350581]  ? _raw_spin_unlock_irqrestore+0x47/0x50
    [  806.351437]  ? dm_suspend+0xb8/0x1d0 [amdgpu]
    [  806.352437]  ? rcu_read_lock_sched_held+0x4f/0x80
    [  806.353252]  ? rcu_read_lock_sched_held+0x4f/0x80
    [  806.354064]  mutex_lock_nested+0x1b/0x20
    [  806.354747]  ? mutex_lock_nested+0x1b/0x20
    [  806.355457]  dm_suspend+0xb8/0x1d0 [amdgpu]
    [  806.356427]  ? soc15_common_set_clockgating_state+0x17d/0x19 [amdgpu]
    [  806.357736]  amdgpu_device_ip_suspend_phase1+0x78/0xd0 [amdgpu]
    [  806.360394]  amdgpu_device_ip_suspend+0x21/0x70 [amdgpu]
    [  806.362926]  amdgpu_device_pre_asic_reset+0xb3/0x270 [amdgpu]
    [  806.365560]  amdgpu_device_gpu_recover.cold+0x679/0x8eb [amdgpu]
    
    Signed-off-by: Lang Yu <Lang.Yu@amd.com>
    Acked-by: Christian KÃnig <christian.koenig@amd.com>
    Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7398c2aab4da960761ec182d04d6d5abbb4a226e
Author: xinhui pan <xinhui.pan@amd.com>
Date:   Tue May 18 10:56:07 2021 +0800

    drm/amdgpu: Fix a use-after-free
    
    [ Upstream commit 1e5c37385097c35911b0f8a0c67ffd10ee1af9a2 ]
    
    looks like we forget to set ttm->sg to NULL.
    Hit panic below
    
    [ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
    [ 1235.989074] Call Trace:
    [ 1235.991751]  sg_free_table+0x17/0x20
    [ 1235.995667]  amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu]
    [ 1236.002288]  amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu]
    [ 1236.008464]  ttm_tt_destroy+0x1e/0x30 [ttm]
    [ 1236.013066]  ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm]
    [ 1236.018783]  ttm_bo_release+0x262/0xa50 [ttm]
    [ 1236.023547]  ttm_bo_put+0x82/0xd0 [ttm]
    [ 1236.027766]  amdgpu_bo_unref+0x26/0x50 [amdgpu]
    [ 1236.032809]  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu]
    [ 1236.040400]  kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu]
    [ 1236.046912]  kfd_ioctl+0x463/0x690 [amdgpu]
    
    Signed-off-by: xinhui pan <xinhui.pan@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dde2656e0bbb2ac7d83a7bd95a8d5c3c95bbc009
Author: Jingwen Chen <Jingwen.Chen2@amd.com>
Date:   Mon May 17 16:16:10 2021 +0800

    drm/amd/amdgpu: fix refcount leak
    
    [ Upstream commit fa7e6abc75f3d491bc561734312d065dc9dc2a77 ]
    
    [Why]
    the gem object rfb->base.obj[0] is get according to num_planes
    in amdgpufb_create, but is not put according to num_planes
    
    [How]
    put rfb->base.obj[0] in amdgpu_fbdev_destroy according to num_planes
    
    Signed-off-by: Jingwen Chen <Jingwen.Chen2@amd.com>
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6d92ebb3eafa871d00dc4ea7bf528ecca720605
Author: Chris Park <Chris.Park@amd.com>
Date:   Tue May 4 16:20:55 2021 -0400

    drm/amd/display: Disconnect non-DP with no EDID
    
    [ Upstream commit 080039273b126eeb0185a61c045893a25dbc046e ]
    
    [Why]
    Active DP dongles return no EDID when dongle
    is connected, but VGA display is taken out.
    Current driver behavior does not remove the
    active display when this happens, and this is
    a gap between dongle DTP and dongle behavior.
    
    [How]
    For active DP dongles and non-DP scenario,
    disconnect sink on detection when no EDID
    is read due to timeout.
    
    Signed-off-by: Chris Park <Chris.Park@amd.com>
    Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
    Acked-by: Stylon Wang <stylon.wang@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 63c61d89660a328ed267dde960186aa57cb99844
Author: Steve French <stfrench@microsoft.com>
Date:   Sat May 15 09:52:22 2021 -0500

    SMB3: incorrect file id in requests compounded with open
    
    [ Upstream commit c0d46717b95735b0eacfddbcca9df37a49de9c7a ]
    
    See MS-SMB2 3.2.4.1.4, file ids in compounded requests should be set to
    0xFFFFFFFFFFFFFFFF (we were treating it as u32 not u64 and setting
    it incorrectly).
    
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reported-by: Stefan Metzmacher <metze@samba.org>
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07160b004a0b28b7dadef18780ac6760b39fe4ff
Author: Teava Radu <rateava@gmail.com>
Date:   Tue May 4 20:57:46 2021 +0200

    platform/x86: touchscreen_dmi: Add info for the Mediacom Winpad 7.0 W700 tablet
    
    [ Upstream commit 39a6172ea88b3117353ae16cbb0a53cd80a9340a ]
    
    Add touchscreen info for the Mediacom Winpad 7.0 W700 tablet.
    Tested on 5.11 hirsute.
    Note: it's hw clone to Wintron surftab 7.
    
    Signed-off-by: Teava Radu <rateava@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20210504185746.175461-6-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1dcd53a45e14b04677611345fc1fd60d1afc1cf
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed May 19 13:15:21 2021 +0300

    platform/x86: intel_punit_ipc: Append MODULE_DEVICE_TABLE for ACPI
    
    [ Upstream commit bc1eca606d8084465e6f89fd646cc71defbad490 ]
    
    The intel_punit_ipc driver might be compiled as a module.
    When udev handles the event of the devices appearing
    the intel_punit_ipc module is missing.
    
    Append MODULE_DEVICE_TABLE for ACPI case to fix the loading issue.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20210519101521.79338-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit feb5d3618a1839767146cac2621fdedaf6960a24
Author: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Date:   Fri May 14 23:30:47 2021 +0530

    platform/x86: hp-wireless: add AMD's hardware id to the supported list
    
    [ Upstream commit f048630bdd55eb5379ef35f971639fe52fabe499 ]
    
    Newer AMD based laptops uses AMDI0051 as the hardware id to support the
    airplane mode button. Adding this to the supported list.
    
    Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Link: https://lore.kernel.org/r/20210514180047.1697543-1-Shyam-sundar.S-k@amd.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ed102453aa1cd12fefde8f6b60b9519b0b1f003
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Fri May 14 10:56:16 2021 -0400

    btrfs: do not BUG_ON in link_to_fixup_dir
    
    [ Upstream commit 91df99a6eb50d5a1bc70fff4a09a0b7ae6aab96d ]
    
    While doing error injection testing I got the following panic
    
      kernel BUG at fs/btrfs/tree-log.c:1862!
      invalid opcode: 0000 [#1] SMP NOPTI
      CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
      RIP: 0010:link_to_fixup_dir+0xd5/0xe0
      RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216
      RAX: fffffffffffffffb RBX: 00000000fffffffb RCX: ffff8f595287faf0
      RDX: ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000
      RBP: ffff8f5953af9450 R08: 0000000000000019 R09: 0000000000000001
      R10: 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800
      R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065
      FS:  00007fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fc5287f47c0 CR3: 000000011275e002 CR4: 0000000000370ee0
      Call Trace:
       replay_one_buffer+0x409/0x470
       ? btree_read_extent_buffer_pages+0xd0/0x110
       walk_up_log_tree+0x157/0x1e0
       walk_log_tree+0xa6/0x1d0
       btrfs_recover_log_trees+0x1da/0x360
       ? replay_one_extent+0x7b0/0x7b0
       open_ctree+0x1486/0x1720
       btrfs_mount_root.cold+0x12/0xea
       ? __kmalloc_track_caller+0x12f/0x240
       legacy_get_tree+0x24/0x40
       vfs_get_tree+0x22/0xb0
       vfs_kern_mount.part.0+0x71/0xb0
       btrfs_mount+0x10d/0x380
       ? vfs_parse_fs_string+0x4d/0x90
       legacy_get_tree+0x24/0x40
       vfs_get_tree+0x22/0xb0
       path_mount+0x433/0xa10
       __x64_sys_mount+0xe3/0x120
       do_syscall_64+0x3d/0x80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    We can get -EIO or any number of legitimate errors from
    btrfs_search_slot(), panicing here is not the appropriate response.  The
    error path for this code handles errors properly, simply return the
    error.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a103713429035da799fa05c7da113f969c0df992
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Apr 14 14:45:43 2021 +0200

    openrisc: Define memory barrier mb
    
    [ Upstream commit 8b549c18ae81dbc36fb11e4aa08b8378c599ca95 ]
    
    This came up in the discussion of the requirements of qspinlock on an
    architecture.  OpenRISC uses qspinlock, but it was noticed that the
    memmory barrier was not defined.
    
    Peter defined it in the mail thread writing:
    
        As near as I can tell this should do. The arch spec only lists
        this one instruction and the text makes it sound like a completion
        barrier.
    
    This is correct so applying this patch.
    
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    [shorne@gmail.com:Turned the mail into a patch]
    Signed-off-by: Stafford Horne <shorne@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fed34fb07c4ba959290579b2c56ef1f61ef668ca
Author: Matt Wang <wwentao@vmware.com>
Date:   Tue May 11 03:04:37 2021 +0000

    scsi: BusLogic: Fix 64-bit system enumeration error for Buslogic
    
    [ Upstream commit 56f396146af278135c0ff958c79b5ee1bd22453d ]
    
    Commit 391e2f25601e ("[SCSI] BusLogic: Port driver to 64-bit")
    introduced a serious issue for 64-bit systems.  With this commit,
    64-bit kernel will enumerate 8*15 non-existing disks.  This is caused
    by the broken CCB structure.  The change from u32 data to void *data
    increased CCB length on 64-bit system, which introduced an extra 4
    byte offset of the CDB.  This leads to incorrect response to INQUIRY
    commands during enumeration.
    
    Fix disk enumeration failure by reverting the portion of the commit
    above which switched the data pointer from u32 to void.
    
    Link: https://lore.kernel.org/r/C325637F-1166-4340-8F0F-3BCCD59D4D54@vmware.com
    Acked-by: Khalid Aziz <khalid@gonehiking.org>
    Signed-off-by: Matt Wang <wwentao@vmware.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55575c08502f291cdeff09428189b84084ffa91b
Author: Boris Burkov <boris@bur.io>
Date:   Tue Apr 6 15:31:18 2021 -0700

    btrfs: return whole extents in fiemap
    
    [ Upstream commit 15c7745c9a0078edad1f7df5a6bb7b80bc8cca23 ]
    
      `xfs_io -c 'fiemap <off> <len>' <file>`
    
    can give surprising results on btrfs that differ from xfs.
    
    btrfs prints out extents trimmed to fit the user input. If the user's
    fiemap request has an offset, then rather than returning each whole
    extent which intersects that range, we also trim the start extent to not
    have start < off.
    
    Documentation in filesystems/fiemap.txt and the xfs_io man page suggests
    that returning the whole extent is expected.
    
    Some cases which all yield the same fiemap in xfs, but not btrfs:
      dd if=/dev/zero of=$f bs=4k count=1
      sudo xfs_io -c 'fiemap 0 1024' $f
        0: [0..7]: 26624..26631
      sudo xfs_io -c 'fiemap 2048 1024' $f
        0: [4..7]: 26628..26631
      sudo xfs_io -c 'fiemap 2048 4096' $f
        0: [4..7]: 26628..26631
      sudo xfs_io -c 'fiemap 3584 512' $f
        0: [7..7]: 26631..26631
      sudo xfs_io -c 'fiemap 4091 5' $f
        0: [7..6]: 26631..26630
    
    I believe this is a consequence of the logic for merging contiguous
    extents represented by separate extent items. That logic needs to track
    the last offset as it loops through the extent items, which happens to
    pick up the start offset on the first iteration, and trim off the
    beginning of the full extent. To fix it, start `off` at 0 rather than
    `start` so that we keep the iteration/merging intact without cutting off
    the start of the extent.
    
    after the fix, all the above commands give:
    
      0: [0..7]: 26624..26631
    
    The merging logic is exercised by fstest generic/483, and I have written
    a new fstest for checking we don't have backwards or zero-length fiemaps
    for cases like those above.
    
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3dea6dc1e14381631d90a31452deb22413e2201
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:36 2021 +0200

    brcmfmac: properly check for bus register errors
    
    [ Upstream commit 419b4a142a7ece36cebcd434f8ce2af59ef94b85 ]
    
    The brcmfmac driver ignores any errors on initialization with the
    different busses by deferring the initialization to a workqueue and
    ignoring all possible errors that might happen.  Fix up all of this by
    only allowing the module to load if all bus registering worked properly.
    
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-70-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26fb7a61de4e5694ff98e3d022f03657fcdfb060
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:35 2021 +0200

    Revert "brcmfmac: add a check for the status of usb_register"
    
    [ Upstream commit 30a350947692f794796f563029d29764497f2887 ]
    
    This reverts commit 42daad3343be4a4e1ee03e30a5f5cc731dadfef5.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    The original commit here did nothing to actually help if usb_register()
    failed, so it gives a "false sense of security" when there is none.  The
    correct solution is to correctly unwind from this error.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-69-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4bab5d15bf5830977186977321482cdb919c3f0
Author: Tom Seewald <tseewald@gmail.com>
Date:   Mon May 3 13:57:32 2021 +0200

    net: liquidio: Add missing null pointer checks
    
    [ Upstream commit dbc97bfd3918ed9268bfc174cae8a7d6b3d51aad ]
    
    The functions send_rx_ctrl_cmd() in both liquidio/lio_main.c and
    liquidio/lio_vf_main.c do not check if the call to
    octeon_alloc_soft_command() fails and returns a null pointer. Both
    functions also return void so errors are not propagated back to the
    caller.
    
    Fix these issues by updating both instances of send_rx_ctrl_cmd() to
    return an integer rather than void, and have them return -ENOMEM if an
    allocation failure occurs. Also update all callers of send_rx_ctrl_cmd()
    so that they now check the return value.
    
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Tom Seewald <tseewald@gmail.com>
    Link: https://lore.kernel.org/r/20210503115736.2104747-66-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ba7505496713d664bee84b95559a59b28be11a4
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:31 2021 +0200

    Revert "net: liquidio: fix a NULL pointer dereference"
    
    [ Upstream commit 4fd798a5a89114c1892574c50f2aebd49bc5b4f5 ]
    
    This reverts commit fe543b2f174f34a7a751aa08b334fe6b105c4569.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    While the original commit does keep the immediate "NULL dereference"
    from happening, it does not properly propagate the error back to the
    callers, AND it does not fix this same identical issue in the
    drivers/net/ethernet/cavium/liquidio/lio_vf_main.c for some reason.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Cc: David S. Miller <davem@davemloft.net>
    Link: https://lore.kernel.org/r/20210503115736.2104747-65-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d771def6c305c24fcd422534d7956ea1958e3026
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:30 2021 +0200

    media: gspca: properly check for errors in po1030_probe()
    
    [ Upstream commit dacb408ca6f0e34df22b40d8dd5fae7f8e777d84 ]
    
    If m5602_write_sensor() or m5602_write_bridge() fail, do not continue to
    initialize the device but return the error to the calling funtion.
    
    Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-64-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44b17737b7aac01dc8c9935a0f9c744d215f5884
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:29 2021 +0200

    Revert "media: gspca: Check the return value of write_bridge for timeout"
    
    [ Upstream commit 8e23e83c752b54e98102627a1cc09281ad71a299 ]
    
    This reverts commit a21a0eb56b4e8fe4a330243af8030f890cde2283.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    Different error values should never be "OR" together and expect anything
    sane to come out of the result.
    
    Cc: Aditya Pakki <pakki001@umn.edu>
    Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-63-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6068eadc1d22de2a97802118507d2451b4370ef
Author: Alaa Emad <alaaemadhossney.ae@gmail.com>
Date:   Mon May 3 13:57:28 2021 +0200

    media: gspca: mt9m111: Check write_bridge for timeout
    
    [ Upstream commit e932f5b458eee63d013578ea128b9ff8ef5f5496 ]
    
    If m5602_write_bridge times out, it will return a negative error value.
    So properly check for this and handle the error correctly instead of
    just ignoring it.
    
    Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Alaa Emad <alaaemadhossney.ae@gmail.com>
    Link: https://lore.kernel.org/r/20210503115736.2104747-62-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f19375e9a8f2c5ce5095d0b0d96e128d530c08cb
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:27 2021 +0200

    Revert "media: gspca: mt9m111: Check write_bridge for timeout"
    
    [ Upstream commit d8c3be2fb2079d0cb4cd29d6aba58dbe54771e42 ]
    
    This reverts commit 656025850074f5c1ba2e05be37bda57ba2b8d491.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    Different error values should never be "OR" together and expect anything
    sane to come out of the result.
    
    Cc: Aditya Pakki <pakki001@umn.edu>
    Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-61-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 193c790eccfc45f9132dcae1be766b455286ce2f
Author: Alaa Emad <alaaemadhossney.ae@gmail.com>
Date:   Mon May 3 13:57:26 2021 +0200

    media: dvb: Add check on sp8870_readreg return
    
    [ Upstream commit c6d822c56e7fd29e6fa1b1bb91b98f6a1e942b3c ]
    
    The function sp8870_readreg returns a negative value when i2c_transfer
    fails so properly check for this and return the error if it happens.
    
    Cc: Sean Young <sean@mess.org>
    Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Signed-off-by: Alaa Emad <alaaemadhossney.ae@gmail.com>
    Link: https://lore.kernel.org/r/20210503115736.2104747-60-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d5e27f0e03148effd7a0438c8b43bd49c73d833
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:25 2021 +0200

    Revert "media: dvb: Add check on sp8870_readreg"
    
    [ Upstream commit 47e4ff06fa7f5ba4860543a2913bbd0c164640aa ]
    
    This reverts commit 467a37fba93f2b4fe3ab597ff6a517b22b566882.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    This commit is not properly checking for an error at all, so if a
    read succeeds from this device, it will error out.
    
    Cc: Aditya Pakki <pakki001@umn.edu>
    Cc: Sean Young <sean@mess.org>
    Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-59-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b3a68a1cf37f2722b4376114ca444505e2ee62f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:24 2021 +0200

    ASoC: cs43130: handle errors in cs43130_probe() properly
    
    [ Upstream commit 2da441a6491d93eff8ffff523837fd621dc80389 ]
    
    cs43130_probe() does not do any valid error checking of things it
    initializes, OR what it does, it does not unwind properly if there are
    errors.
    
    Fix this up by moving the sysfs files to an attribute group so the
    driver core will correctly add/remove them all at once and handle errors
    with them, and correctly check for creating a new workqueue and
    unwinding if that fails.
    
    Cc: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-58-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e4ac4e151f1224a42838f776492bb45b591580e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:23 2021 +0200

    Revert "ASoC: cs43130: fix a NULL pointer dereference"
    
    [ Upstream commit fdda0dd2686ecd1f2e616c9e0366ea71b40c485d ]
    
    This reverts commit a2be42f18d409213bb7e7a736e3ef6ba005115bb.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    The original patch here is not correct, sysfs files that were created
    are not unwound.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Cc: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-57-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3aa60a0335eaabedda41201dd88b7338eba9ab45
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:20 2021 +0200

    libertas: register sysfs groups properly
    
    [ Upstream commit 7e79b38fe9a403b065ac5915465f620a8fb3de84 ]
    
    The libertas driver was trying to register sysfs groups "by hand" which
    causes them to be created _after_ the device is initialized and
    announced to userspace, which causes races and can prevent userspace
    tools from seeing the sysfs files correctly.
    
    Fix this up by using the built-in sysfs_groups pointers in struct
    net_device which were created for this very reason, fixing the race
    condition, and properly allowing for any error that might have occured
    to be handled properly.
    
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-54-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0c75f951f81b76b8e56e36f2c76163b209f7ff5
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:19 2021 +0200

    Revert "libertas: add checks for the return value of sysfs_create_group"
    
    [ Upstream commit 46651077765c80a0d6f87f3469129a72e49ce91b ]
    
    This reverts commit 434256833d8eb988cb7f3b8a41699e2fe48d9332.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    The original commit was incorrect, the error needs to be propagated back
    to the caller AND if the second group call fails, the first needs to be
    removed.  There are much better ways to solve this, the driver should
    NOT be calling sysfs_create_group() on its own as it is racing userspace
    and loosing.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-53-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c52bc7482e3bd28780257fd5a769754beebc886
Author: Phillip Potter <phil@philpotter.co.uk>
Date:   Mon May 3 13:57:18 2021 +0200

    dmaengine: qcom_hidma: comment platform_driver_register call
    
    [ Upstream commit 4df2a8b0ad634d98a67e540a4e18a60f943e7d9f ]
    
    Place a comment in hidma_mgmt_init explaining why success must
    currently be assumed, due to the cleanup issue that would need to
    be considered were this module ever to be unloadable or were this
    platform_driver_register call ever to fail.
    
    Acked-By: Vinod Koul <vkoul@kernel.org>
    Acked-By: Sinan Kaya <okaya@kernel.org>
    Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
    Link: https://lore.kernel.org/r/20210503115736.2104747-52-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e829b7253e4dea76e9eeec2ecfb56cb980803ac6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:17 2021 +0200

    Revert "dmaengine: qcom_hidma: Check for driver register failure"
    
    [ Upstream commit 43ed0fcf613a87dd0221ec72d1ade4d6544f2ffc ]
    
    This reverts commit a474b3f0428d6b02a538aa10b3c3b722751cb382.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    The original change is NOT correct, as it does not correctly unwind from
    the resources that was allocated before the call to
    platform_driver_register().
    
    Cc: Aditya Pakki <pakki001@umn.edu>
    Acked-By: Vinod Koul <vkoul@kernel.org>
    Acked-By: Sinan Kaya <okaya@kernel.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-51-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4bc94e60d78709c9d3a62d4d3f9a4dce83232151
Author: Phillip Potter <phil@philpotter.co.uk>
Date:   Mon May 3 13:57:14 2021 +0200

    isdn: mISDN: correctly handle ph_info allocation failure in hfcsusb_ph_info
    
    [ Upstream commit 5265db2ccc735e2783b790d6c19fb5cee8c025ed ]
    
    Modify return type of hfcusb_ph_info to int, so that we can pass error
    value up the call stack when allocation of ph_info fails. Also change
    three of four call sites to actually account for the memory failure.
    The fourth, in ph_state_nt, is infeasible to change as it is in turn
    called by ph_state which is used as a function pointer argument to
    mISDN_initdchannel, which would necessitate changing its signature
    and updating all the places where it is used (too many).
    
    Fixes original flawed commit (38d22659803a) from the University of
    Minnesota.
    
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
    Link: https://lore.kernel.org/r/20210503115736.2104747-48-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b8872d4972f0acb0332e980b874ed776223f4f2
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:13 2021 +0200

    Revert "isdn: mISDN: Fix potential NULL pointer dereference of kzalloc"
    
    [ Upstream commit 36a2c87f7ed9e305d05b9a5c044cc6c494771504 ]
    
    This reverts commit 38d22659803a033b1b66cd2624c33570c0dde77d.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    While it looks like the original change is correct, it is not, as none
    of the setup actually happens, and the error value is not propagated
    upwards.
    
    Cc: Aditya Pakki <pakki001@umn.edu>
    Cc: David S. Miller <davem@davemloft.net>
    Link: https://lore.kernel.org/r/20210503115736.2104747-47-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 85b2c436a143378f0fc770e4b5f36a10765ee1a9
Author: Anirudh Rayabharam <mail@anirudhrb.com>
Date:   Mon May 3 13:57:10 2021 +0200

    ath6kl: return error code in ath6kl_wmi_set_roam_lrssi_cmd()
    
    [ Upstream commit 54433367840b46a1555c8ed36c4c0cfc5dbf1358 ]
    
    Propagate error code from failure of ath6kl_wmi_cmd_send() to the
    caller.
    
    Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-44-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b74d4ae8f5382886bbec0b2a2dedf4171c4c20bf
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:09 2021 +0200

    Revert "ath6kl: return error code in ath6kl_wmi_set_roam_lrssi_cmd()"
    
    [ Upstream commit efba106f89fc6848726716c101f4c84e88720a9c ]
    
    This reverts commit fc6a6521556c8250e356ddc6a3f2391aa62dc976.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    The change being reverted does NOTHING as the caller to this function
    does not even look at the return value of the call.  So the "claim" that
    this fixed an an issue is not true.  It will be fixed up properly in a
    future patch by propagating the error up the stack correctly.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-43-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a34338fcaad6f2c424bdeb61f12f8569e1e4a79e
Author: Phillip Potter <phil@philpotter.co.uk>
Date:   Mon May 3 13:57:08 2021 +0200

    isdn: mISDNinfineon: check/cleanup ioremap failure correctly in setup_io
    
    [ Upstream commit c446f0d4702d316e1c6bf621f70e79678d28830a ]
    
    Move hw->cfg.mode and hw->addr.mode assignments from hw->ci->cfg_mode
    and hw->ci->addr_mode respectively, to be before the subsequent checks
    for memory IO mode (and possible ioremap calls in this case).
    
    Also introduce ioremap error checks at both locations. This allows
    resources to be properly freed on ioremap failure, as when the caller
    of setup_io then subsequently calls release_io via its error path,
    release_io can now correctly determine the mode as it has been set
    before the ioremap call.
    
    Finally, refactor release_io function so that it will call
    release_mem_region in the memory IO case, regardless of whether or not
    hw->cfg.p/hw->addr.p are NULL. This means resources are then properly
    released on failure.
    
    This properly implements the original reverted commit (d721fe99f6ad)
    from the University of Minnesota, whilst also implementing the ioremap
    check for the hw->ci->cfg_mode if block as well.
    
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
    Link: https://lore.kernel.org/r/20210503115736.2104747-42-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3d74e622e63e4c23838e65c835b356c2a491296
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:07 2021 +0200

    Revert "isdn: mISDNinfineon: fix potential NULL pointer dereference"
    
    [ Upstream commit abd7bca23bd4247124265152d00ffd4b2b0d6877 ]
    
    This reverts commit d721fe99f6ada070ae8fc0ec3e01ce5a42def0d9.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    The original commit was incorrect, it should have never have used
    "unlikely()" and if it ever does trigger, resources are left grabbed.
    
    Given there are no users for this code around, I'll just revert this and
    leave it "as is" as the odds that ioremap() will ever fail here is
    horrendiously low.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Cc: David S. Miller <davem@davemloft.net>
    Link: https://lore.kernel.org/r/20210503115736.2104747-41-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5dc20457707bdbc190ebdb9483e35831eb71bc2b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:57:03 2021 +0200

    Revert "ALSA: usx2y: Fix potential NULL pointer dereference"
    
    [ Upstream commit 4667a6fc1777ce071504bab570d3599107f4790f ]
    
    This reverts commit a2c6433ee5a35a8de6d563f6512a26f87835ea0f.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    The original patch was incorrect, and would leak memory if the error
    path the patch added was hit.
    
    Cc: Aditya Pakki <pakki001@umn.edu>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20210503115736.2104747-37-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea4c563657d7802b6c269dff7fe8b39f68130863
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:56:59 2021 +0200

    Revert "ALSA: gus: add a check of the status of snd_ctl_add"
    
    [ Upstream commit 1dacca7fa1ebea47d38d20cd2df37094805d2649 ]
    
    This reverts commit 0f25e000cb4398081748e54f62a902098aa79ec1.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    The original commit did nothing if there was an error, except to print
    out a message, which is pointless.  So remove the commit as it gives a
    "false sense of doing something".
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20210503115736.2104747-33-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70bf2a067915935b77592878239be0ad28700316
Author: Tom Seewald <tseewald@gmail.com>
Date:   Mon May 3 13:56:56 2021 +0200

    char: hpet: add checks after calling ioremap
    
    [ Upstream commit b11701c933112d49b808dee01cb7ff854ba6a77a ]
    
    The function hpet_resources() calls ioremap() two times, but in both
    cases it does not check if ioremap() returned a null pointer. Fix this
    by adding null pointer checks and returning an appropriate error.
    
    Signed-off-by: Tom Seewald <tseewald@gmail.com>
    Link: https://lore.kernel.org/r/20210503115736.2104747-30-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07d2945a35516933278a997f5bbdf2dd5a06969a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:56:55 2021 +0200

    Revert "char: hpet: fix a missing check of ioremap"
    
    [ Upstream commit 566f53238da74801b48e985788e5f7c9159e5940 ]
    
    This reverts commit 13bd14a41ce3105d5b1f3cd8b4d1e249d17b6d9b.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    While this is technically correct, it is only fixing ONE of these errors
    in this function, so the patch is not fully correct.  I'll leave this
    revert and provide a fix for this later that resolves this same
    "problem" everywhere in this function.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Link: https://lore.kernel.org/r/20210503115736.2104747-29-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b1da7ad9ad5876ab91ade23d8e021d97ff967ded
Author: Du Cheng <ducheng2@gmail.com>
Date:   Mon May 3 13:56:46 2021 +0200

    net: caif: remove BUG_ON(dev == NULL) in caif_xmit
    
    [ Upstream commit 65a67792e3416f7c5d7daa47d99334cbb19a7449 ]
    
    The condition of dev == NULL is impossible in caif_xmit(), hence it is
    for the removal.
    
    Explanation:
    The static caif_xmit() is only called upon via a function pointer
    `ndo_start_xmit` defined in include/linux/netdevice.h:
    ```
    struct net_device_ops {
        ...
        netdev_tx_t     (*ndo_start_xmit)(struct sk_buff *skb, struct net_device *dev);
        ...
    }
    ```
    
    The exhausive list of call points are:
    ```
    drivers/net/ethernet/qualcomm/rmnet/rmnet_map_command.c
        dev->netdev_ops->ndo_start_xmit(skb, dev);
        ^                                    ^
    
    drivers/infiniband/ulp/opa_vnic/opa_vnic_netdev.c
        struct opa_vnic_adapter *adapter = opa_vnic_priv(netdev);
                                 ^                       ^
        return adapter->rn_ops->ndo_start_xmit(skb, netdev); // adapter would crash first
               ^                                    ^
    
    drivers/usb/gadget/function/f_ncm.c
        ncm->netdev->netdev_ops->ndo_start_xmit(NULL, ncm->netdev);
                  ^                                   ^
    
    include/linux/netdevice.h
    static inline netdev_tx_t __netdev_start_xmit(...
    {
        return ops->ndo_start_xmit(skb, dev);
                                        ^
    }
    
        const struct net_device_ops *ops = dev->netdev_ops;
                                           ^
        rc = __netdev_start_xmit(ops, skb, dev, more);
                                           ^
    ```
    
    In each of the enumerated scenarios, it is impossible for the NULL-valued dev to
    reach the caif_xmit() without crashing the kernel earlier, therefore `BUG_ON(dev ==
    NULL)` is rather useless, hence the removal.
    
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Du Cheng <ducheng2@gmail.com>
    Link: https://lore.kernel.org/r/20210503115736.2104747-20-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e8dee217eca8d644d86817b0a9403b8c824ce488
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:56:43 2021 +0200

    Revert "net/smc: fix a NULL pointer dereference"
    
    [ Upstream commit 5369ead83f5aff223b6418c99cb1fe9a8f007363 ]
    
    This reverts commit e183d4e414b64711baf7a04e214b61969ca08dfa.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    The original commit causes a memory leak and does not properly fix the
    issue it claims to fix.  I will send a follow-on patch to resolve this
    properly.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Cc: Ursula Braun <ubraun@linux.ibm.com>
    Cc: David S. Miller <davem@davemloft.net>
    Link: https://lore.kernel.org/r/20210503115736.2104747-17-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22049c3d40f08facd1867548716a484dad6b3251
Author: Anirudh Rayabharam <mail@anirudhrb.com>
Date:   Mon May 3 13:56:42 2021 +0200

    net: fujitsu: fix potential null-ptr-deref
    
    [ Upstream commit 52202be1cd996cde6e8969a128dc27ee45a7cb5e ]
    
    In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer
    deref. To fix this, check the return value of ioremap and return -1
    to the caller in case of failure.
    
    Cc: "David S. Miller" <davem@davemloft.net>
    Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
    Link: https://lore.kernel.org/r/20210503115736.2104747-16-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ebb533ce35b5a259dad5e3dd40d84367c9959907
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:56:41 2021 +0200

    Revert "net: fujitsu: fix a potential NULL pointer dereference"
    
    [ Upstream commit 5f94eaa4ee23e80841fa359a372f84cfe25daee1 ]
    
    This reverts commit 9f4d6358e11bbc7b839f9419636188e4151fb6e4.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    The original change does not change any behavior as the caller of this
    function onlyu checks for "== -1" as an error condition so this error is
    not handled properly.  Remove this change and it will be fixed up
    properly in a later commit.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Cc: David S. Miller <davem@davemloft.net>
    Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Link: https://lore.kernel.org/r/20210503115736.2104747-15-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e50a9f2548a58a84d23457b69f948ba9c32a76e2
Author: Atul Gopinathan <atulgopinathan@gmail.com>
Date:   Mon May 3 13:56:38 2021 +0200

    serial: max310x: unregister uart driver in case of failure and abort
    
    [ Upstream commit 3890e3dea315f1a257d1b940a2a4e2fa16a7b095 ]
    
    The macro "spi_register_driver" invokes the function
    "__spi_register_driver()" which has a return type of int and can fail,
    returning a negative value in such a case. This is currently ignored and
    the init() function yields success even if the spi driver failed to
    register.
    
    Fix this by collecting the return value of "__spi_register_driver()" and
    also unregister the uart driver in case of failure.
    
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com>
    Link: https://lore.kernel.org/r/20210503115736.2104747-12-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5d3e4b6104c04bee41b5594bc419e367b06f063
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:56:37 2021 +0200

    Revert "serial: max310x: pass return value of spi_register_driver"
    
    [ Upstream commit b0a85abbe92e1a6f3e8580a4590fa7245de7090b ]
    
    This reverts commit 51f689cc11333944c7a457f25ec75fcb41e99410.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It will be fixed up "correctly" in a
    later kernel change.
    
    This change did not properly unwind from the error condition, so it was
    not correct.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Acked-by: Jiri Slaby <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-11-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 047aefd6222062022892376d60a027c6c191799d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:56:34 2021 +0200

    Revert "ALSA: sb: fix a missing check of snd_ctl_add"
    
    [ Upstream commit 4b059ce1f4b368208c2310925f49be77f15e527b ]
    
    This reverts commit beae77170c60aa786f3e4599c18ead2854d8694d.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to be incorrect for the reasons
    below, so it must be reverted.  It is safe to ignore this error as the
    mixer element is optional, and the driver is very legacy.
    
    Cc: Aditya Pakki <pakki001@umn.edu>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20210503115736.2104747-8-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bec840232fed63cedba11fccbe2c2fe1c8d704d6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 3 13:56:33 2021 +0200

    Revert "media: usb: gspca: add a missed check for goto_low_power"
    
    [ Upstream commit fd013265e5b5576a74a033920d6c571e08d7c423 ]
    
    This reverts commit 5b711870bec4dc9a6d705d41e127e73944fa3650.
    
    Because of recent interactions with developers from @umn.edu, all
    commits from them have been recently re-reviewed to ensure if they were
    correct or not.
    
    Upon review, this commit was found to do does nothing useful as a user
    can do nothing with this information and if an error did happen, the
    code would continue on as before.  Because of this, just revert it.
    
    Cc: Kangjie Lu <kjlu@umn.edu>
    Cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
    Link: https://lore.kernel.org/r/20210503115736.2104747-7-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e44a9941937d330220f7ef3e0e0aeed90dd924c4
Author: Zou Wei <zou_wei@huawei.com>
Date:   Wed May 12 11:17:47 2021 +0800

    gpio: cadence: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit 1e948b1752b58c9c570989ab29ceef5b38fdccda ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this driver when it is built
    as an external module.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0c7f6cce1cf4d4f8821c067b54e284126826c47
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Apr 30 14:07:35 2021 +0800

    platform/x86: hp_accel: Avoid invoking _INI to speed up resume
    
    [ Upstream commit 79d341e26ebcdbc622348aaaab6f8f89b6fdb25f ]
    
    hp_accel can take almost two seconds to resume on some HP laptops.
    
    The bottleneck is on evaluating _INI, which is only needed to run once.
    
    Resolve the issue by only invoking _INI when it's necessary. Namely, on
    probe and on hibernation restore.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Éric Piel <eric.piel@trempplin-utc.net>
    Link: https://lore.kernel.org/r/20210430060736.590321-1-kai.heng.feng@canonical.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd7a3b3ed9e35ba1057fd9f3a308cc56576d47a5
Author: Felix Fietkau <nbd@nbd.name>
Date:   Tue May 25 18:07:58 2021 +0200

    perf jevents: Fix getting maximum number of fds
    
    commit 75ea44e356b5de8c817f821c9dd68ae329e82add upstream.
    
    On some hosts, rlim.rlim_max can be returned as RLIM_INFINITY.
    By casting it to int, it is interpreted as -1, which will cause get_maxfds
    to return 0, causing "Invalid argument" errors in nftw() calls.
    Fix this by casting the second argument of min() to rlim_t instead.
    
    Fixes: 80eeb67fe577 ("perf jevents: Program to convert JSON file")
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
    Link: http://lore.kernel.org/lkml/20210525160758.97829-1-nbd@nbd.name
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77ac90814b4e31e60a3b58ae74694120d19ddab1
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu May 6 13:15:40 2021 +0200

    i2c: sh_mobile: Use new clock calculation formulas for RZ/G2E
    
    commit c4740e293c93c747e65d53d9aacc2ba8521d1489 upstream.
    
    When switching the Gen3 SoCs to the new clock calculation formulas, the
    match entry for RZ/G2E added in commit 51243b73455f2d12 ("i2c:
    sh_mobile: Add support for r8a774c0 (RZ/G2E)") was forgotten.
    
    Fixes: e8a27567509b2439 ("i2c: sh_mobile: use new clock calculation formulas for Gen3")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04cc05e3716ae31b17ecdab7bc55c8170def1b8b
Author: Jean Delvare <jdelvare@suse.de>
Date:   Tue May 25 17:03:36 2021 +0200

    i2c: i801: Don't generate an interrupt on bus reset
    
    commit e4d8716c3dcec47f1557024add24e1f3c09eb24b upstream.
    
    Now that the i2c-i801 driver supports interrupts, setting the KILL bit
    in a attempt to recover from a timed out transaction triggers an
    interrupt. Unfortunately, the interrupt handler (i801_isr) is not
    prepared for this situation and will try to process the interrupt as
    if it was signaling the end of a successful transaction. In the case
    of a block transaction, this can result in an out-of-range memory
    access.
    
    This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e
    https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e
    https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e
    https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb
    https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a
    https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79
    
    So disable interrupts while trying to reset the bus. Interrupts will
    be enabled again for the following transaction.
    
    Fixes: 636752bcb517 ("i2c-i801: Enable IRQ for SMBus transactions")
    Reported-by: syzbot+b4d3fd1dfd53e90afd79@syzkaller.appspotmail.com
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45488e77e0142ec8b17dddc6ba960c3a747075b6
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Wed May 26 08:39:37 2021 -0400

    i2c: s3c2410: fix possible NULL pointer deref on read message after write
    
    commit 24990423267ec283b9d86f07f362b753eb9b0ed5 upstream.
    
    Interrupt handler processes multiple message write requests one after
    another, till the driver message queue is drained.  However if driver
    encounters a read message without preceding START, it stops the I2C
    transfer as it is an invalid condition for the controller.  At least the
    comment describes a requirement "the controller forces us to send a new
    START when we change direction".  This stop results in clearing the
    message queue (i2c->msg = NULL).
    
    The code however immediately jumped back to label "retry_write" which
    dereferenced the "i2c->msg" making it a possible NULL pointer
    dereference.
    
    The Coverity analysis:
    1. Condition !is_msgend(i2c), taking false branch.
       if (!is_msgend(i2c)) {
    
    2. Condition !is_lastmsg(i2c), taking true branch.
       } else if (!is_lastmsg(i2c)) {
    
    3. Condition i2c->msg->flags & 1, taking true branch.
       if (i2c->msg->flags & I2C_M_RD) {
    
    4. write_zero_model: Passing i2c to s3c24xx_i2c_stop, which sets i2c->msg to NULL.
       s3c24xx_i2c_stop(i2c, -EINVAL);
    
    5. Jumping to label retry_write.
       goto retry_write;
    
    6. var_deref_model: Passing i2c to is_msgend, which dereferences null i2c->msg.
       if (!is_msgend(i2c)) {"
    
    All previous calls to s3c24xx_i2c_stop() in this interrupt service
    routine are followed by jumping to end of function (acknowledging
    the interrupt and returning).  This seems a reasonable choice also here
    since message buffer was entirely emptied.
    
    Addresses-Coverity: Explicit null dereferenced
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e00da6510b3bdf6129f0c38508e2d9e594feb730
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Mon May 24 12:25:25 2021 +0300

    net: dsa: sja1105: error out on unsupported PHY mode
    
    commit 6729188d2646709941903052e4b78e1d82c239b9 upstream.
    
    The driver continues probing when a port is configured for an
    unsupported PHY interface type, instead it should stop.
    
    Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce5355f140a7987011388c7e30c4f8fbe180d3e8
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat May 8 16:30:35 2021 +0300

    net: dsa: fix a crash if ->get_sset_count() fails
    
    commit a269333fa5c0c8e53c92b5a28a6076a28cde3e83 upstream.
    
    If ds->ops->get_sset_count() fails then it "count" is a negative error
    code such as -EOPNOTSUPP.  Because "i" is an unsigned int, the negative
    error code is type promoted to a very high value and the loop will
    corrupt memory until the system crashes.
    
    Fix this by checking for error codes and changing the type of "i" to
    just int.
    
    Fixes: badf3ada60ab ("net: dsa: Provide CPU port statistics to master netdev")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fe4e1f48ba119bdbc7c897c83b04ba0d08f5488
Author: DENG Qingfang <dqfext@gmail.com>
Date:   Sun May 23 22:51:54 2021 +0800

    net: dsa: mt7530: fix VLAN traffic leaks
    
    commit 474a2ddaa192777522a7499784f1d60691cd831a upstream.
    
    PCR_MATRIX field was set to all 1's when VLAN filtering is enabled, but
    was not reset when it is disabled, which may cause traffic leaks:
    
            ip link add br0 type bridge vlan_filtering 1
            ip link add br1 type bridge vlan_filtering 1
            ip link set swp0 master br0
            ip link set swp1 master br1
            ip link set br0 type bridge vlan_filtering 0
            ip link set br1 type bridge vlan_filtering 0
            # traffic in br0 and br1 will start leaking to each other
    
    As port_bridge_{add,del} have set up PCR_MATRIX properly, remove the
    PCR_MATRIX write from mt7530_port_set_vlan_aware.
    
    Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530")
    Signed-off-by: DENG Qingfang <dqfext@gmail.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15d1cc4b4b585f9a2ce72c52cca004d5d735bdf1
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun May 9 21:12:27 2021 +0200

    spi: spi-fsl-dspi: Fix a resource leak in an error handling path
    
    commit 680ec0549a055eb464dce6ffb4bfb736ef87236e upstream.
    
    'dspi_request_dma()' should be undone by a 'dspi_release_dma()' call in the
    error handling path of the probe function, as already done in the remove
    function
    
    Fixes: 90ba37033cb9 ("spi: spi-fsl-dspi: Add DMA support for Vybrid")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/d51caaac747277a1099ba8dea07acd85435b857e.1620587472.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64d17ec9f1ded042c4b188d15734f33486ed9966
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sat May 8 03:57:03 2021 +0800

    tipc: skb_linearize the head skb when reassembling msgs
    
    commit b7df21cf1b79ab7026f545e7bf837bd5750ac026 upstream.
    
    It's not a good idea to append the frag skb to a skb's frag_list if
    the frag_list already has skbs from elsewhere, such as this skb was
    created by pskb_copy() where the frag_list was cloned (all the skbs
    in it were skb_get'ed) and shared by multiple skbs.
    
    However, the new appended frag skb should have been only seen by the
    current skb. Otherwise, it will cause use after free crashes as this
    appended frag skb are seen by multiple skbs but it only got skb_get
    called once.
    
    The same thing happens with a skb updated by pskb_may_pull() with a
    skb_cloned skb. Li Shuang has reported quite a few crashes caused
    by this when doing testing over macvlan devices:
    
      [] kernel BUG at net/core/skbuff.c:1970!
      [] Call Trace:
      []  skb_clone+0x4d/0xb0
      []  macvlan_broadcast+0xd8/0x160 [macvlan]
      []  macvlan_process_broadcast+0x148/0x150 [macvlan]
      []  process_one_work+0x1a7/0x360
      []  worker_thread+0x30/0x390
    
      [] kernel BUG at mm/usercopy.c:102!
      [] Call Trace:
      []  __check_heap_object+0xd3/0x100
      []  __check_object_size+0xff/0x16b
      []  simple_copy_to_iter+0x1c/0x30
      []  __skb_datagram_iter+0x7d/0x310
      []  __skb_datagram_iter+0x2a5/0x310
      []  skb_copy_datagram_iter+0x3b/0x90
      []  tipc_recvmsg+0x14a/0x3a0 [tipc]
      []  ____sys_recvmsg+0x91/0x150
      []  ___sys_recvmsg+0x7b/0xc0
    
      [] kernel BUG at mm/slub.c:305!
      [] Call Trace:
      []  <IRQ>
      []  kmem_cache_free+0x3ff/0x400
      []  __netif_receive_skb_core+0x12c/0xc40
      []  ? kmem_cache_alloc+0x12e/0x270
      []  netif_receive_skb_internal+0x3d/0xb0
      []  ? get_rx_page_info+0x8e/0xa0 [be2net]
      []  be_poll+0x6ef/0xd00 [be2net]
      []  ? irq_exit+0x4f/0x100
      []  net_rx_action+0x149/0x3b0
    
      ...
    
    This patch is to fix it by linearizing the head skb if it has frag_list
    set in tipc_buf_append(). Note that we choose to do this before calling
    skb_unshare(), as __skb_linearize() will avoid skb_copy(). Also, we can
    not just drop the frag_list either as the early time.
    
    Fixes: 45c8b7b175ce ("tipc: allow non-linear first fragment buffer")
    Reported-by: Li Shuang <shuali@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1f76dfadaf8f47ed1753f97dbcbd41c16215ffa
Author: Xin Long <lucien.xin@gmail.com>
Date:   Mon May 17 02:28:58 2021 +0800

    tipc: wait and exit until all work queues are done
    
    commit 04c26faa51d1e2fe71cf13c45791f5174c37f986 upstream.
    
    On some host, a crash could be triggered simply by repeating these
    commands several times:
    
      # modprobe tipc
      # tipc bearer enable media udp name UDP1 localip 127.0.0.1
      # rmmod tipc
    
      [] BUG: unable to handle kernel paging request at ffffffffc096bb00
      [] Workqueue: events 0xffffffffc096bb00
      [] Call Trace:
      []  ? process_one_work+0x1a7/0x360
      []  ? worker_thread+0x30/0x390
      []  ? create_worker+0x1a0/0x1a0
      []  ? kthread+0x116/0x130
      []  ? kthread_flush_work_fn+0x10/0x10
      []  ? ret_from_fork+0x35/0x40
    
    When removing the TIPC module, the UDP tunnel sock will be delayed to
    release in a work queue as sock_release() can't be done in rtnl_lock().
    If the work queue is schedule to run after the TIPC module is removed,
    kernel will crash as the work queue function cleanup_beareri() code no
    longer exists when trying to invoke it.
    
    To fix it, this patch introduce a member wq_count in tipc_net to track
    the numbers of work queues in schedule, and  wait and exit until all
    work queues are done in tipc_exit_net().
    
    Fixes: d0f91938bede ("tipc: add ip/udp media type")
    Reported-by: Shuang Li <shuali@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdd37028a026a3cb93a0ff8486cbaad553109d8e
Author: Hoang Le <hoang.h.le@dektech.com.au>
Date:   Fri May 14 08:23:03 2021 +0700

    Revert "net:tipc: Fix a double free in tipc_sk_mcast_rcv"
    
    commit 75016891357a628d2b8acc09e2b9b2576c18d318 upstream.
    
    This reverts commit 6bf24dc0cc0cc43b29ba344b66d78590e687e046.
    Above fix is not correct and caused memory leak issue.
    
    Fixes: 6bf24dc0cc0c ("net:tipc: Fix a double free in tipc_sk_mcast_rcv")
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Acked-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
    Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e01d87b108c72fc97f7260676c4d5a7fc8a10e4
Author: Vladyslav Tarasiuk <vladyslavt@nvidia.com>
Date:   Sun May 9 09:43:18 2021 +0300

    net/mlx4: Fix EEPROM dump support
    
    commit db825feefc6868896fed5e361787ba3bee2fd906 upstream.
    
    Fix SFP and QSFP* EEPROM queries by setting i2c_address, offset and page
    number correctly. For SFP set the following params:
    - I2C address for offsets 0-255 is 0x50. For 256-511 - 0x51.
    - Page number is zero.
    - Offset is 0-255.
    
    At the same time, QSFP* parameters are different:
    - I2C address is always 0x50.
    - Page number is not limited to zero.
    - Offset is 0-255 for page zero and 128-255 for others.
    
    To set parameters accordingly to cable used, implement function to query
    module ID and implement respective helper functions to set parameters
    correctly.
    
    Fixes: 135dd9594f12 ("net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages query")
    Signed-off-by: Vladyslav Tarasiuk <vladyslavt@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fd3213e53547341d23374feba9bb7c3c4c76f9e
Author: Dima Chumak <dchumak@nvidia.com>
Date:   Mon Apr 26 15:16:26 2021 +0300

    net/mlx5e: Fix nullptr in add_vlan_push_action()
    
    commit dca59f4a791960ec73fa15803faa0abe0f92ece2 upstream.
    
    The result of dev_get_by_index_rcu() is not checked for NULL and then
    gets dereferenced immediately.
    
    Also, the RCU lock must be held by the caller of dev_get_by_index_rcu(),
    which isn't satisfied by the call stack.
    
    Fix by handling nullptr return value when iflink device is not found.
    Add RCU locking around dev_get_by_index_rcu() to avoid possible adverse
    effects while iterating over the net_device's hlist.
    
    It is safe not to increment reference count of the net_device pointer in
    case of a successful lookup, because it's already handled by VLAN code
    during VLAN device registration (see register_vlan_dev and
    netdev_upper_dev_link).
    
    Fixes: 278748a95aa3 ("net/mlx5e: Offload TC e-switch rules with egress VLAN device")
    Addresses-Coverity: ("Dereference null return value")
    Signed-off-by: Dima Chumak <dchumak@nvidia.com>
    Reviewed-by: Vlad Buslov <vladbu@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df61870c4b1d0042028edf7e8330be425e49ee52
Author: Dima Chumak <dchumak@nvidia.com>
Date:   Tue Apr 13 22:43:08 2021 +0300

    net/mlx5e: Fix multipath lag activation
    
    commit 97817fcc684ed01497bd19d0cd4dea699665b9cf upstream.
    
    When handling FIB_EVENT_ENTRY_REPLACE event for a new multipath route,
    lag activation can be missed if a stale (struct lag_mp)->mfi pointer
    exists, which was associated with an older multipath route that had been
    removed.
    
    Normally, when a route is removed, it triggers mlx5_lag_fib_event(),
    which handles FIB_EVENT_ENTRY_DEL and clears mfi pointer. But, if
    mlx5_lag_check_prereq() condition isn't met, for example when eswitch is
    in legacy mode, the fib event is skipped and mfi pointer becomes stale.
    
    Fix by resetting mfi pointer to NULL every time mlx5_lag_mp_init() is
    called.
    
    Fixes: 544fe7c2e654 ("net/mlx5e: Activate HW multipath and handle port affinity based on FIB events")
    Signed-off-by: Dima Chumak <dchumak@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ce2bf20b4a6e307e114847d60b2bf40a6a1fac0
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Fri Apr 30 10:27:44 2021 +0200

    drm/meson: fix shutdown crash when component not probed
    
    commit 7cfc4ea78fc103ea51ecbacd9236abb5b1c490d2 upstream.
    
    When main component is not probed, by example when the dw-hdmi module is
    not loaded yet or in probe defer, the following crash appears on shutdown:
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038
    ...
    pc : meson_drv_shutdown+0x24/0x50
    lr : platform_drv_shutdown+0x20/0x30
    ...
    Call trace:
    meson_drv_shutdown+0x24/0x50
    platform_drv_shutdown+0x20/0x30
    device_shutdown+0x158/0x360
    kernel_restart_prepare+0x38/0x48
    kernel_restart+0x18/0x68
    __do_sys_reboot+0x224/0x250
    __arm64_sys_reboot+0x24/0x30
    ...
    
    Simply check if the priv struct has been allocated before using it.
    
    Fixes: fa0c16caf3d7 ("drm: meson_drv add shutdown function")
    Reported-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210430082744.3638743-1-narmstrong@baylibre.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0787efc1a35980aca8caf9fa43527b152222fe64
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Tue May 25 23:32:35 2021 -0400

    NFSv4: Fix v4.0/v4.1 SEEK_DATA return -ENOTSUPP when set NFS_V4_2 config
    
    commit e67afa7ee4a59584d7253e45d7f63b9528819a13 upstream.
    
    Since commit bdcc2cd14e4e ("NFSv4.2: handle NFS-specific llseek errors"),
    nfs42_proc_llseek would return -EOPNOTSUPP rather than -ENOTSUPP when
    SEEK_DATA on NFSv4.0/v4.1.
    
    This will lead xfstests generic/285 not run on NFSv4.0/v4.1 when set the
    CONFIG_NFS_V4_2, rather than run failed.
    
    Fixes: bdcc2cd14e4e ("NFSv4.2: handle NFS-specific llseek errors")
    Cc: <stable.vger.kernel.org> # 4.2
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 785917316b25685c9b3a2a88f933139f2de75e33
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue May 25 10:40:12 2021 -0400

    NFS: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce()
    
    commit 0d0ea309357dea0d85a82815f02157eb7fcda39f upstream.
    
    The value of mirror->pg_bytes_written should only be updated after a
    successful attempt to flush out the requests on the list.
    
    Fixes: a7d42ddb3099 ("nfs: add mirroring support to pgio layer")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fc5f4eb9d31268ac3ce152d74ad5501ad24ca3e
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue May 25 10:23:05 2021 -0400

    NFS: Fix an Oopsable condition in __nfs_pageio_add_request()
    
    commit 56517ab958b7c11030e626250c00b9b1a24b41eb upstream.
    
    Ensure that nfs_pageio_error_cleanup() resets the mirror array contents,
    so that the structure reflects the fact that it is now empty.
    Also change the test in nfs_pageio_do_add_request() to be more robust by
    checking whether or not the list is empty rather than relying on the
    value of pg_count.
    
    Fixes: a7d42ddb3099 ("nfs: add mirroring support to pgio layer")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e411df81cd862ef3d5b878120b2a2fef0ca9cdb1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 11 11:49:42 2021 +0300

    NFS: fix an incorrect limit in filelayout_decode_layout()
    
    commit 769b01ea68b6c49dc3cde6adf7e53927dacbd3a8 upstream.
    
    The "sizeof(struct nfs_fh)" is two bytes too large and could lead to
    memory corruption.  It should be NFS_MAXFHSIZE because that's the size
    of the ->data[] buffer.
    
    I reversed the size of the arguments to put the variable on the left.
    
    Fixes: 16b374ca439f ("NFSv4.1: pnfs: filelayout: add driver's LAYOUTGET and GETDEVICEINFO infrastructure")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f76e76555682b300f35610711e8b51d446441020
Author: zhouchuangao <zhouchuangao@vivo.com>
Date:   Sun May 9 19:34:37 2021 -0700

    fs/nfs: Use fatal_signal_pending instead of signal_pending
    
    commit bb002388901151fe35b6697ab116f6ed0721a9ed upstream.
    
    We set the state of the current process to TASK_KILLABLE via
    prepare_to_wait(). Should we use fatal_signal_pending() to detect
    the signal here?
    
    Fixes: b4868b44c562 ("NFSv4: Wait for stateid updates after CLOSE/OPEN_DOWNGRADE")
    Signed-off-by: zhouchuangao <zhouchuangao@vivo.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe201316ac36c48fc3cb2891dfdc8ab68058734d
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Tue Apr 13 13:21:03 2021 -0300

    Bluetooth: cmtp: fix file refcount when cmtp_attach_device fails
    
    commit 8da3a0b87f4f1c3a3bbc4bfb78cf68476e97d183 upstream.
    
    When cmtp_attach_device fails, cmtp_add_connection returns the error value
    which leads to the caller to doing fput through sockfd_put. But
    cmtp_session kthread, which is stopped in this path will also call fput,
    leading to a potential refcount underflow or a use-after-free.
    
    Add a refcount before we signal the kthread to stop. The kthread will try
    to grab the cmtp_session_sem mutex before doing the fput, which is held
    when get_file is called, so there should be no races there.
    
    Reported-by: Ryota Shiga
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 977c34b50e6bb04e56e5006b085a56f895994483
Author: Lukas Wunner <lukas@wunner.de>
Date:   Mon Dec 7 09:17:02 2020 +0100

    spi: spi-geni-qcom: Fix use-after-free on unbind
    
    commit 8f96c434dfbc85ffa755d6634c8c1cb2233fcf24 upstream.
    
    spi_geni_remove() accesses the driver's private data after calling
    spi_unregister_master() even though that function releases the last
    reference on the spi_master and thereby frees the private data.
    
    Moreover, since commit 1a9e489e6128 ("spi: spi-geni-qcom: Use OPP API to
    set clk/perf state"), spi_geni_probe() leaks the spi_master allocation
    if the calls to dev_pm_opp_set_clkname() or dev_pm_opp_of_add_table()
    fail.
    
    Fix by switching over to the new devm_spi_alloc_master() helper which
    keeps the private data accessible until the driver has unbound and also
    avoids the spi_master leak on probe.
    
    Fixes: 561de45f72bd ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP")
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Cc: <stable@vger.kernel.org> # v4.20+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
    Cc: <stable@vger.kernel.org> # v4.20+
    Cc: Rajendra Nayak <rnayak@codeaurora.org>
    Cc: Girish Mahadevan <girishm@codeaurora.org>
    Link: https://lore.kernel.org/r/dfa1d8c41b8acdfad87ec8654cd124e6e3cb3f31.1607286887.git.lukas@wunner.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    [lukas: backport to v5.4.123]
    Signed-off-by: Lukas Wunner <lukas@wunner.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b95fb96e6339e34694dd578fb6bde3575b01af17
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Mon May 24 23:02:08 2021 +0300

    net: usb: fix memory leak in smsc75xx_bind
    
    commit 46a8b29c6306d8bbfd92b614ef65a47c900d8e70 upstream.
    
    Syzbot reported memory leak in smsc75xx_bind().
    The problem was is non-freed memory in case of
    errors after memory allocation.
    
    backtrace:
      [<ffffffff84245b62>] kmalloc include/linux/slab.h:556 [inline]
      [<ffffffff84245b62>] kzalloc include/linux/slab.h:686 [inline]
      [<ffffffff84245b62>] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460
      [<ffffffff82b5b2e6>] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728
    
    Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
    Cc: stable@kernel.vger.org
    Reported-and-tested-by: syzbot+b558506ba8165425fee2@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b94afae0fa7a9549751979b2ce615fd35798ce6c
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Mon May 24 15:01:55 2021 +0900

    usb: gadget: udc: renesas_usb3: Fix a race in usb3_start_pipen()
    
    commit e752dbc59e1241b13b8c4f7b6eb582862e7668fe upstream.
    
    The usb3_start_pipen() is called by renesas_usb3_ep_queue() and
    usb3_request_done_pipen() so that usb3_start_pipen() is possible
    to cause a race when getting usb3_first_req like below:
    
    renesas_usb3_ep_queue()
     spin_lock_irqsave()
     list_add_tail()
     spin_unlock_irqrestore()
     usb3_start_pipen()
      usb3_first_req = usb3_get_request() --- [1]
     --- interrupt ---
     usb3_irq_dma_int()
     usb3_request_done_pipen()
      usb3_get_request()
      usb3_start_pipen()
      usb3_first_req = usb3_get_request()
      ...
      (the req is possible to be finished in the interrupt)
    
    The usb3_first_req [1] above may have been finished after the interrupt
    ended so that this driver caused to start a transfer wrongly. To fix this
    issue, getting/checking the usb3_first_req are under spin_lock_irqsave()
    in the same section.
    
    Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://lore.kernel.org/r/20210524060155.1178724-1-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b5bfb8ce56d9664c353a7af6a73eec9766b4b00
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Wed May 12 20:17:09 2021 -0700

    usb: dwc3: gadget: Properly track pending and queued SG
    
    commit 25dda9fc56bd90d45f9a4516bcfa5211e61b4290 upstream.
    
    The driver incorrectly uses req->num_pending_sgs to track both the
    number of pending and queued SG entries. It only prepares the next
    request if the previous is done, and it doesn't update num_pending_sgs
    until there is TRB completion interrupt. This may starve the controller
    of more TRBs until the num_pending_sgs is decremented.
    
    Fix this by decrementing the num_pending_sgs after they are queued and
    properly track both num_mapped_sgs and num_queued_sgs.
    
    Fixes: c96e6725db9d ("usb: dwc3: gadget: Correct the logic for queuing sgs")
    Cc: <stable@vger.kernel.org>
    Reported-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Tested-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/ba24591dbcaad8f244a3e88bd449bb7205a5aec3.1620874069.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2cd572cc45b55b9220a1dbd0b9ef5539fa97b9fa
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Fri Apr 30 05:23:43 2021 -0700

    thermal/drivers/intel: Initialize RW trip to THERMAL_TEMP_INVALID
    
    commit eb8500b874cf295971a6a2a04e14eb0854197a3c upstream.
    
    After commit 81ad4276b505 ("Thermal: Ignore invalid trip points") all
    user_space governor notifications via RW trip point is broken in intel
    thermal drivers. This commits marks trip_points with value of 0 during
    call to thermal_zone_device_register() as invalid. RW trip points can be
    0 as user space will set the correct trip temperature later.
    
    During driver init, x86_package_temp and all int340x drivers sets RW trip
    temperature as 0. This results in all these trips marked as invalid by
    the thermal core.
    
    To fix this initialize RW trips to THERMAL_TEMP_INVALID instead of 0.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20210430122343.1789899-1-srinivas.pandruvada@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78e80f9c4e9675e7be8ebfdb815d7023329cd191
Author: Zolton Jheng <s6668c2t@gmail.com>
Date:   Mon May 10 10:32:00 2021 +0800

    USB: serial: pl2303: add device id for ADLINK ND-6530 GC
    
    commit f8e8c1b2f782e7391e8a1c25648ce756e2a7d481 upstream.
    
    This adds the device id for the ADLINK ND-6530 which is a PL2303GC based
    device.
    
    Signed-off-by: Zolton Jheng <s6668c2t@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f485e4dcbe44f4c8cb28c6f57cb4dc7b1946bd08
Author: Dominik Andreas Schorpp <dominik.a.schorpp@ids.de>
Date:   Thu Apr 22 09:58:52 2021 +0200

    USB: serial: ftdi_sio: add IDs for IDS GmbH Products
    
    commit c5a80540e425a5f9a82b0f3163e3b6a4331f33bc upstream.
    
    Add the IDS GmbH Vendor ID and the Product IDs for SI31A (2xRS232)
    and CM31A (LoRaWAN Modem).
    
    Signed-off-by: Dominik Andreas Schorpp <dominik.a.schorpp@ids.de>
    Signed-off-by: Juergen Borleis <jbe@pengutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8217f3c7f6cc66f34283db13eeebd25cd9f27772
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Wed Apr 28 09:26:34 2021 +0200

    USB: serial: option: add Telit LE910-S1 compositions 0x7010, 0x7011
    
    commit e467714f822b5d167a7fb03d34af91b5b6af1827 upstream.
    
    Add support for the following Telit LE910-S1 compositions:
    
    0x7010: rndis, tty, tty, tty
    0x7011: ecm, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Link: https://lore.kernel.org/r/20210428072634.5091-1-dnlplm@gmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eddf691bab0f716584bda5a5d33765b149a2e463
Author: Sean MacLennan <seanm@seanm.ca>
Date:   Sat May 1 20:40:45 2021 -0400

    USB: serial: ti_usb_3410_5052: add startech.com device id
    
    commit 89b1a3d811e6f8065d6ae8a25e7682329b4a31e2 upstream.
    
    This adds support for the Startech.com generic serial to USB converter.
    It seems to be a bone stock TI_3410. I have been using this patch for
    years.
    
    Signed-off-by: Sean MacLennan <seanm@seanm.ca>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 915452f40e2f495e187276c4407a4f567ec2307e
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Fri May 21 06:08:43 2021 +0000

    serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait'
    
    commit 016002848c82eeb5d460489ce392d91fe18c475c upstream.
    
    In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls
    'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the
    firmware don't exists, function just return without initializing ports
    of 'rp2_card'. But now the interrupt handler function has been
    registered, and when an interrupt comes, 'rp2_uart_interrupt' may access
    those ports then causing NULL pointer dereference or other bugs.
    
    Because the driver does some initialization work in 'rp2_fw_cb', in
    order to make the driver ready to handle interrupts, 'request_firmware'
    should be used instead of asynchronous 'request_firmware_nowait'.
    
    This report reveals it:
    
    INFO: trying to register non-static key.
    the code is fine but needs lockdep annotation.
    turning off the locking correctness validator.
    CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-
    gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    Call Trace:
     <IRQ>
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0xec/0x156 lib/dump_stack.c:118
     assign_lock_key kernel/locking/lockdep.c:727 [inline]
     register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753
     __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303
     lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907
     __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
     _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144
     spin_lock include/linux/spinlock.h:329 [inline]
     rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline]
     rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493
     rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504
     __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149
     handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189
     handle_irq_event+0xac/0x140 kernel/irq/handle.c:206
     handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725
     generic_handle_irq_desc include/linux/irqdesc.h:155 [inline]
     handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87
     do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247
     common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
     </IRQ>
    RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61
    Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8
    8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90
    90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
    RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
    RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285
    RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200
    RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840
    R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002
    R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000
     arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
     default_idle+0x6f/0x360 arch/x86/kernel/process.c:557
     arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548
     default_idle_call+0x3b/0x60 kernel/sched/idle.c:93
     cpuidle_idle_call kernel/sched/idle.c:153 [inline]
     do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263
     cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369
     start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271
     secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
    PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0
    Oops: 0000 [#1] PREEMPT SMP KASAN PTI
    CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-
    gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline]
    RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline]
    RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c:
    493
    Code: df e8 43 5d c2 05 48 8d 83 e8 01 00 00 48 89 85 60 ff ff ff 48 c1 e8
    03 42 80 3c 30 00 0f 85 aa 07 00 00 48 8b 83 e8 01 00 00 <8b> 40 10 89 c1
    89 85 68 ff ff ff 48 8b 83 e8 01 00 00 89 48 10 83
    RSP: 0018:ffff88806c287cd0 EFLAGS: 00010046
    RAX: 0000000000000000 RBX: ffff88806ade6820 RCX: ffffffff814300b1
    RDX: 1ffff1100d5bcd06 RSI: 0000000000000004 RDI: ffff88806ade6820
    RBP: ffff88806c287db8 R08: ffffed100d5bcd05 R09: ffffed100d5bcd05
    R10: 0000000000000001 R11: ffffed100d5bcd04 R12: ffffc90001e00000
    R13: ffff888069654e10 R14: dffffc0000000000 R15: ffff888069654df0
    FS:  0000000000000000(0000) GS:ffff88806c280000(0000) knlGS:
    0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000010 CR3: 000000006892c000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <IRQ>
     rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504
     __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149
     handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189
     handle_irq_event+0xac/0x140 kernel/irq/handle.c:206
     handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725
     generic_handle_irq_desc include/linux/irqdesc.h:155 [inline]
     handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87
     do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247
     common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
     </IRQ>
    RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61
    Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7
    f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90
    90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
    RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
    RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285
    RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200
    RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840
    R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002
    R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000
     arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
     default_idle+0x6f/0x360 arch/x86/kernel/process.c:557
     arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548
     default_idle_call+0x3b/0x60 kernel/sched/idle.c:93
     cpuidle_idle_call kernel/sched/idle.c:153 [inline]
     do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263
     cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369
     start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271
     secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
    Modules linked in:
    Dumping ftrace buffer:
       (ftrace buffer empty)
    CR2: 0000000000000010
    ---[ end trace 11804dbb55cb1a64 ]---
    RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline]
    RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline]
    RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c:
    493
    Code: df e8 43 5d c2 05 48 8d 83 e8 01 00 00 48 89 85 60 ff ff ff 48 c1
    e8 03 42 80 3c 30 00 0f 85 aa 07 00 00 48 8b 83 e8 01 00 00 <8b> 40 10 89
    c1 89 85 68 ff ff ff 48 8b 83 e8 01 00 00 89 48 10 83
    RSP: 0018:ffff88806c287cd0 EFLAGS: 00010046
    RAX: 0000000000000000 RBX: ffff88806ade6820 RCX: ffffffff814300b1
    RDX: 1ffff1100d5bcd06 RSI: 0000000000000004 RDI: ffff88806ade6820
    RBP: ffff88806c287db8 R08: ffffed100d5bcd05 R09: ffffed100d5bcd05
    R10: 0000000000000001 R11: ffffed100d5bcd04 R12: ffffc90001e00000
    R13: ffff888069654e10 R14: dffffc0000000000 R15: ffff888069654df0
    FS:  0000000000000000(0000) GS:ffff88806c280000(0000) knlGS:
    0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000010 CR3: 000000006892c000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Reported-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Link: https://lore.kernel.org/r/1621577323-1541-1-git-send-email-zheyuma97@gmail.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d8071879a2b090e37ed68afa68cc5c8c576424c
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon May 10 14:07:55 2021 +0200

    serial: sh-sci: Fix off-by-one error in FIFO threshold register setting
    
    commit 2ea2e019c190ee3973ef7bcaf829d8762e56e635 upstream.
    
    The Receive FIFO Data Count Trigger field (RTRG[6:0]) in the Receive
    FIFO Data Count Trigger Register (HSRTRGR) of HSCIF can only hold values
    ranging from 0-127.  As the FIFO size is equal to 128 on HSCIF, the user
    can write an out-of-range value, touching reserved bits.
    
    Fix this by limiting the trigger value to the FIFO size minus one.
    Reverse the order of the checks, to avoid rx_trig becoming zero if the
    FIFO size is one.
    
    Note that this change has no impact on other SCIF variants, as their
    maximum supported trigger value is lower than the FIFO size anyway, and
    the code below takes care of enforcing these limits.
    
    Fixes: a380ed461f66d1b8 ("serial: sh-sci: implement FIFO threshold register setting")
    Reported-by: Linh Phung <linh.phung.jy@renesas.com>
    Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/5eff320aef92ffb33d00e57979fd3603bbb4a70f.1620648218.git.geert+renesas@glider.be
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3986ba109dadda34bf74c7a2c201e226188773b4
Author: Colin Ian King <colin.king@canonical.com>
Date:   Mon Apr 26 11:55:14 2021 +0100

    serial: tegra: Fix a mask operation that is always true
    
    commit 3ddb4ce1e6e3bd112778ab93bbd9092f23a878ec upstream.
    
    Currently the expression lsr | UART_LSR_TEMT is always true and
    this seems suspect. I believe the intent was to mask lsr with UART_LSR_TEMT
    to check that bit, so the expression should be using the & operator
    instead. Fix this.
    
    Fixes: b9c2470fb150 ("serial: tegra: flush the RX fifo on frame error")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210426105514.23268-1-colin.king@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c835fede13e03f2743a333e4370b5ed2db91e83
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue May 18 16:18:35 2021 -0400

    USB: usbfs: Don't WARN about excessively large memory allocations
    
    commit 4f2629ea67e7225c3fd292c7fe4f5b3c9d6392de upstream.
    
    Syzbot found that the kernel generates a WARNing if the user tries to
    submit a bulk transfer through usbfs with a buffer that is way too
    large.  This isn't a bug in the kernel; it's merely an invalid request
    from the user and the usbfs code does handle it correctly.
    
    In theory the same thing can happen with async transfers, or with the
    packet descriptor table for isochronous transfers.
    
    To prevent the MM subsystem from complaining about these bad
    allocation requests, add the __GFP_NOWARN flag to the kmalloc calls
    for these buffers.
    
    CC: Andrew Morton <akpm@linux-foundation.org>
    CC: <stable@vger.kernel.org>
    Reported-and-tested-by: syzbot+882a85c0c8ec4a3e2281@syzkaller.appspotmail.com
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20210518201835.GA1140918@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84af0c28ed1b0b6156b36854716e68d6a99fab9e
Author: Johan Hovold <johan@kernel.org>
Date:   Fri May 21 15:31:09 2021 +0200

    USB: trancevibrator: fix control-request direction
    
    commit 746e4acf87bcacf1406e05ef24a0b7139147c63e upstream.
    
    The direction of the pipe argument must match the request-type direction
    bit or control requests may fail depending on the host-controller-driver
    implementation.
    
    Fix the set-speed request which erroneously used USB_DIR_IN and update
    the default timeout argument to match (same value).
    
    Fixes: 5638e4d92e77 ("USB: add PlayStation 2 Trance Vibrator driver")
    Cc: stable@vger.kernel.org      # 2.6.19
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20210521133109.17396-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc8b9d8c0465fc481282864b94a90abb6046c2d2
Author: Christian Gmeiner <christian.gmeiner@gmail.com>
Date:   Thu May 27 11:54:40 2021 +0200

    serial: 8250_pci: handle FL_NOIRQ board flag
    
    commit 9808f9be31c68af43f6e531f2c851ebb066513fe upstream.
    
    In commit 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support")
    the way the irq gets allocated was changed. With that change the
    handling FL_NOIRQ got lost. Restore the old behaviour.
    
    Fixes: 8428413b1d14 ("serial: 8250_pci: Implement MSI(-X) support")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Link: https://lore.kernel.org/r/20210527095529.26281-1-christian.gmeiner@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f75a5b9907e8890e64d0a1a86b11e7db6fbd978c
Author: Randy Wright <rwright@hpe.com>
Date:   Fri May 14 10:26:54 2021 -0600

    serial: 8250_pci: Add support for new HPE serial device
    
    commit e0e24208792080135248f23fdf6d51aa2e04df05 upstream.
    
    Add support for new HPE serial device.  It is MSI enabled,
    but otherwise similar to legacy HP server serial devices.
    
    Tested-by: Jerry Hoemann <jerry.hoemann@hpe.com>
    Signed-off-by: Randy Wright <rwright@hpe.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1621009614-28836-1-git-send-email-rwright@hpe.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72fa5c26936a9b69ba4ce576e048e2a35d465da9
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri May 14 16:02:54 2021 +0800

    iio: adc: ad7793: Add missing error code in ad7793_setup()
    
    commit 4ed243b1da169bcbc1ec5507867e56250c5f1ff9 upstream.
    
    Set error code while device ID query failed.
    
    Fixes: 88bc30548aae ("IIO: ADC: New driver for AD7792/AD7793 3 Channel SPI ADC")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f49149964d2423fb618fb6b755bb1eaa431cca2c
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Thu May 13 15:07:42 2021 +0300

    iio: adc: ad7124: Fix potential overflow due to non sequential channel numbers
    
    commit f2a772c51206b0c3f262e4f6a3812c89a650191b upstream.
    
    Channel numbering must start at 0 and then not have any holes, or
    it is possible to overflow the available storage.  Note this bug was
    introduced as part of a fix to ensure we didn't rely on the ordering
    of child nodes.  So we need to support arbitrary ordering but they all
    need to be there somewhere.
    
    Note I hit this when using qemu to test the rest of this series.
    Arguably this isn't the best fix, but it is probably the most minimal
    option for backporting etc.
    
    Alexandru's sign-off is here because he carried this patch in a larger
    set that Jonathan then applied.
    
    Fixes: d7857e4ee1ba6 ("iio: adc: ad7124: Fix DT channel configuration")
    Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e5cac90430c70af8b87b186e08fffd99ac6ef0f
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Thu May 13 15:07:41 2021 +0300

    iio: adc: ad7124: Fix missbalanced regulator enable / disable on error.
    
    commit 4573472315f0fa461330545ff2aa2f6da0b1ae76 upstream.
    
    If the devm_regulator_get() call succeeded but not the regulator_enable()
    then regulator_disable() would be called on a regulator that was not
    enabled.
    
    Fix this by moving regulator enabling / disabling over to
    devm_ management via devm_add_action_or_reset.
    
    Alexandru's sign-off here because he pulled Jonathan's patch into
    a larger set which Jonathan then applied.
    
    Fixes: b3af341bbd96 ("iio: adc: Add ad7124 support")
    Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c9085b0fa04d5d511bf3294f8bb5783b73efa1a
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 17:53:13 2021 +0100

    iio: adc: ad7768-1: Fix too small buffer passed to iio_push_to_buffers_with_timestamp()
    
    commit a1caeebab07e9d72eec534489f47964782b93ba9 upstream.
    
    Add space for the timestamp to be inserted.  Also ensure correct
    alignment for passing to iio_push_to_buffers_with_timestamp()
    
    Fixes: a5f8c7da3dbe ("iio: adc: Add AD7768-1 ADC basic support")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501165314.511954-2-jic23@kernel.org
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd877887e479059f9fd46386bf15025939e72dc1
Author: Rui Miguel Silva <rui.silva@linaro.org>
Date:   Wed May 12 23:39:29 2021 +0100

    iio: gyro: fxas21002c: balance runtime power in error path
    
    commit 2a54c8c9ebc2006bf72554afc84ffc67768979a0 upstream.
    
    If we fail to read temperature or axis we need to decrement the
    runtime pm reference count to trigger autosuspend.
    
    Add the call to pm_put to do that in case of error.
    
    Fixes: a0701b6263ae ("iio: gyro: add core driver for fxas21002c")
    Suggested-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
    Link: https://lore.kernel.org/linux-iio/CBBZA9T1OY9C.2611WSV49DV2G@arch-thunder/
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 657f6a33f8719d56d83e777919581f50dec4f1db
Author: Lucas Stankus <lucas.p.stankus@gmail.com>
Date:   Tue May 11 17:54:18 2021 -0300

    staging: iio: cdc: ad7746: avoid overwrite of num_channels
    
    commit 04f5b9f539ce314f758d919a14dc7a669f3b7838 upstream.
    
    AD7745 devices don't have the CIN2 pins and therefore can't handle related
    channels. Forcing the number of AD7746 channels may lead to enabling more
    channels than what the hardware actually supports.
    Avoid num_channels being overwritten after first assignment.
    
    Signed-off-by: Lucas Stankus <lucas.p.stankus@gmail.com>
    Fixes: 83e416f458d53 ("staging: iio: adc: Replace, rewrite ad7745 from scratch.")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12fb557863f8c098ac1c7a163f4bd930a419702b
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Wed May 26 22:33:34 2021 +0300

    mei: request autosuspend after sending rx flow control
    
    commit bbf0a94744edfeee298e4a9ab6fd694d639a5cdf upstream.
    
    A rx flow control waiting in the control queue may block autosuspend.
    Re-request autosuspend after flow control been sent to unblock
    the transition to the low power state.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20210526193334.445759-1-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb78fa5a3815a721e2508738ba4a442c9c037365
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Apr 27 15:48:29 2021 +0300

    thunderbolt: dma_port: Fix NVM read buffer bounds and offset issue
    
    commit b106776080a1cf953a1b2fd50cb2a995db4732be upstream.
    
    Up to 64 bytes of data can be read from NVM in one go. Read address
    must be dword aligned. Data is read into a local buffer.
    
    If caller asks to read data starting at an unaligned address then full
    dword is anyway read from NVM into a local buffer. Data is then copied
    from the local buffer starting at the unaligned offset to the caller
    buffer.
    
    In cases where asked data length + unaligned offset is over 64 bytes
    we need to make sure we don't read past the 64 bytes in the local
    buffer when copying to caller buffer, and make sure that we don't
    skip copying unaligned offset bytes from local buffer anymore after
    the first round of 64 byte NVM data read.
    
    Fixes: 3e13676862f9 ("thunderbolt: Add support for DMA configuration based mailbox")
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36b5ff1db1a4ef4fdbc2bae364344279f033ad88
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Fri May 14 20:43:48 2021 +0800

    misc/uss720: fix memory leak in uss720_probe
    
    commit dcb4b8ad6a448532d8b681b5d1a7036210b622de upstream.
    
    uss720_probe forgets to decrease the refcount of usbdev in uss720_probe.
    Fix this by decreasing the refcount of usbdev by usb_put_dev.
    
    BUG: memory leak
    unreferenced object 0xffff888101113800 (size 2048):
      comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s)
      hex dump (first 32 bytes):
        ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00  ....1...........
        00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00  ................
      backtrace:
        [<ffffffff82b8e822>] kmalloc include/linux/slab.h:554 [inline]
        [<ffffffff82b8e822>] kzalloc include/linux/slab.h:684 [inline]
        [<ffffffff82b8e822>] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582
        [<ffffffff82b98441>] hub_port_connect drivers/usb/core/hub.c:5129 [inline]
        [<ffffffff82b98441>] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline]
        [<ffffffff82b98441>] port_event drivers/usb/core/hub.c:5509 [inline]
        [<ffffffff82b98441>] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591
        [<ffffffff81259229>] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275
        [<ffffffff81259b19>] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421
        [<ffffffff81261228>] kthread+0x178/0x1b0 kernel/kthread.c:292
        [<ffffffff8100227f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
    
    Fixes: 0f36163d3abe ("[PATCH] usb: fix uss720 schedule with interrupts off")
    Cc: stable <stable@vger.kernel.org>
    Reported-by: syzbot+636c58f40a86b4a879e7@syzkaller.appspotmail.com
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Link: https://lore.kernel.org/r/20210514124348.6587-1-mudongliangabcd@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66a2a494ac482a7448aff3aa5dd468d8840ca0fe
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Fri May 7 13:57:19 2021 +0200

    serial: core: fix suspicious security_locked_down() call
    
    commit 5e722b217ad3cf41f5504db80a68062df82b5242 upstream.
    
    The commit that added this check did so in a very strange way - first
    security_locked_down() is called, its value stored into retval, and if
    it's nonzero, then an additional check is made for (change_irq ||
    change_port), and if this is true, the function returns. However, if
    the goto exit branch is not taken, the code keeps the retval value and
    continues executing the function. Then, depending on whether
    uport->ops->verify_port is set, the retval value may or may not be reset
    to zero and eventually the error value from security_locked_down() may
    abort the function a few lines below.
    
    I will go out on a limb and assume that this isn't the intended behavior
    and that an error value from security_locked_down() was supposed to
    abort the function only in case (change_irq || change_port) is true.
    
    Note that security_locked_down() should be called last in any series of
    checks, since the SELinux implementation of this hook will do a check
    against the policy and generate an audit record in case of denial. If
    the operation was to carry on after calling security_locked_down(), then
    the SELinux denial record would be bogus.
    
    See commit 59438b46471a ("security,lockdown,selinux: implement SELinux
    lockdown") for how SELinux implements this hook.
    
    Fixes: 794edf30ee6c ("lockdown: Lock down TIOCSSERIAL")
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210507115719.140799-1-omosnace@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48a9b7957bb26ec88c3607300bf55276e8056784
Author: Sargun Dhillon <sargun@sargun.me>
Date:   Mon May 17 12:39:05 2021 -0700

    Documentation: seccomp: Fix user notification documentation
    
    commit aac902925ea646e461c95edc98a8a57eb0def917 upstream.
    
    The documentation had some previously incorrect information about how
    userspace notifications (and responses) were handled due to a change
    from a previously proposed patchset.
    
    Signed-off-by: Sargun Dhillon <sargun@sargun.me>
    Acked-by: Tycho Andersen <tycho@tycho.pizza>
    Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210517193908.3113-2-sargun@sargun.me
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7c6a316a887907fea6db73c93d825b39bb6be64
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu May 20 15:08:39 2021 +0200

    kgdb: fix gcc-11 warnings harder
    
    commit bda7d3ab06f19c02dcef61fefcb9dd954dfd5e4f upstream.
    
    40cc3a80bb42 ("kgdb: fix gcc-11 warning on indentation") tried to fix up
    the gcc-11 complaints in this file by just reformatting the #defines.
    That worked for gcc 11.1.0, but in gcc 11.1.1 as shipped by Fedora 34,
    the warning came back for one of the #defines.
    
    Fix this up again by putting { } around the if statement, now it is
    quiet again.
    
    Fixes: 40cc3a80bb42 ("kgdb: fix gcc-11 warning on indentation")
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Daniel Thompson <daniel.thompson@linaro.org>
    Cc: Jason Wessel <jason.wessel@windriver.com>
    Link: https://lore.kernel.org/r/20210520130839.51987-1-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01c57232a1cbdf74a3408582f1148cbb9038ebce
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed Nov 4 21:08:42 2020 +1100

    selftests/gpio: Fix build when source tree is read only
    
    [ Upstream commit b68c1c65dec5fb5186ebd33ce52059b4c6db8500 ]
    
    Currently the gpio selftests fail to build if the source tree is read
    only:
    
      make -j 160 -C tools/testing/selftests TARGETS=gpio
      make[1]: Entering directory '/linux/tools/testing/selftests/gpio'
      make OUTPUT=/linux/tools/gpio/ -C /linux/tools/gpio
      make[2]: Entering directory '/linux/tools/gpio'
      mkdir -p /linux/tools/gpio/include/linux 2>&1 || true
      ln -sf /linux/tools/gpio/../../include/uapi/linux/gpio.h /linux/tools/gpio/include/linux/gpio.h
      ln: failed to create symbolic link '/linux/tools/gpio/include/linux/gpio.h': Read-only file system
    
    This happens because we ask make to build ../../../gpio (tools/gpio)
    without pointing OUTPUT away from the source directory.
    
    To fix it we create a subdirectory of the existing OUTPUT directory,
    called tools-gpio, and tell tools/gpio to build in there.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d93532a4873d7b409bd34c7709ea597816181345
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed Nov 4 21:08:41 2020 +1100

    selftests/gpio: Move include of lib.mk up
    
    [ Upstream commit 449539da2e237336bc750b41f1736a77f9aca25c ]
    
    Move the include of lib.mk up so that in a subsequent patch we can use
    OUTPUT, which is initialised by lib.mk, in the definition of the GPIO
    variables.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1e20cdb93889c02ac893f2c2ac934d3e18f1c32f
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed Nov 4 21:08:40 2020 +1100

    selftests/gpio: Use TEST_GEN_PROGS_EXTENDED
    
    [ Upstream commit ff2c395b9257f0e617f9cd212893f3c72c80ee6c ]
    
    Use TEST_GEN_PROGS_EXTENDED rather than TEST_PROGS_EXTENDED.
    
    That tells the lib.mk logic that the files it references are to be
    generated by the Makefile.
    
    Having done that we don't need to override the all rule.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 03aeefb46f0792fd4ded248f5837e5ab8a5b8773
Author: James Zhu <James.Zhu@amd.com>
Date:   Wed May 19 11:40:39 2021 -0400

    drm/amdgpu/vcn2.5: add cancel_delayed_work_sync before power gate
    
    commit 2fb536ea42d557f39f70c755f68e1aa1ad466c55 upstream.
    
    Add cancel_delayed_work_sync before set power gating state
    to avoid race condition issue when power gating.
    
    Signed-off-by: James Zhu <James.Zhu@amd.com>
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Acked-by: Christian König <christian.koenig@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 f0780e96a6e2897114feaa699b93a9b67906f567
Author: James Zhu <James.Zhu@amd.com>
Date:   Wed May 19 11:26:32 2021 -0400

    drm/amdgpu/vcn2.0: add cancel_delayed_work_sync before power gate
    
    commit 0c6013377b4027e69d8f3e63b6bf556b6cb87802 upstream.
    
    Add cancel_delayed_work_sync before set power gating state
    to avoid race condition issue when power gating.
    
    Signed-off-by: James Zhu <James.Zhu@amd.com>
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Acked-by: Christian König <christian.koenig@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 9351c5192b887659629bb21852c9fb377d1b9887
Author: James Zhu <James.Zhu@amd.com>
Date:   Tue May 18 10:58:22 2021 -0400

    drm/amdgpu/vcn1: add cancel_delayed_work_sync before power gate
    
    commit b95f045ea35673572ef46d6483ad8bd6d353d63c upstream.
    
    Add cancel_delayed_work_sync before set power gating state
    to avoid race condition issue when power gating.
    
    Signed-off-by: James Zhu <James.Zhu@amd.com>
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Acked-by: Christian König <christian.koenig@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 d65ec240b3e43e8637dac93dcd8d9134646d608c
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue May 25 13:17:19 2021 -0400

    dm snapshot: properly fix a crash when an origin has no snapshots
    
    commit 7e768532b2396bcb7fbf6f82384b85c0f1d2f197 upstream.
    
    If an origin target has no snapshots, o->split_boundary is set to 0.
    This causes BUG_ON(sectors <= 0) in block/bio.c:bio_split().
    
    Fix this by initializing chunk_size, and in turn split_boundary, to
    rounddown_pow_of_two(UINT_MAX) -- the largest power of two that fits
    into "unsigned" type.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b06fe1124369b394de89e934478eefec8d5a3f1d
Author: Sriram R <srirrama@codeaurora.org>
Date:   Tue May 11 20:02:57 2021 +0200

    ath10k: Validate first subframe of A-MSDU before processing the list
    
    commit 62a8ff67eba52dae9b107e1fb8827054ed00a265 upstream.
    
    In certain scenarios a normal MSDU can be received as an A-MSDU when
    the A-MSDU present bit of a QoS header gets flipped during reception.
    Since this bit is unauthenticated, the hardware crypto engine can pass
    the frame to the driver without any error indication.
    
    This could result in processing unintended subframes collected in the
    A-MSDU list. Hence, validate A-MSDU list by checking if the first frame
    has a valid subframe header.
    
    Comparing the non-aggregated MSDU and an A-MSDU, the fields of the first
    subframe DA matches the LLC/SNAP header fields of a normal MSDU.
    In order to avoid processing such frames, add a validation to
    filter such A-MSDU frames where the first subframe header DA matches
    with the LLC/SNAP header pattern.
    
    Tested-on: QCA9984 hw1.0 PCI 10.4-3.10-00047
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sriram R <srirrama@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Link: https://lore.kernel.org/r/20210511200110.e6f5eb7b9847.I38a77ae26096862527a5eab73caebd7346af8b66@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aee0121afee53cde39e49086317af5d029911857
Author: Wen Gong <wgong@codeaurora.org>
Date:   Tue May 11 20:02:56 2021 +0200

    ath10k: Fix TKIP Michael MIC verification for PCIe
    
    commit 0dc267b13f3a7e8424a898815dd357211b737330 upstream.
    
    TKIP Michael MIC was not verified properly for PCIe cases since the
    validation steps in ieee80211_rx_h_michael_mic_verify() in mac80211 did
    not get fully executed due to unexpected flag values in
    ieee80211_rx_status.
    
    Fix this by setting the flags property to meet mac80211 expectations for
    performing Michael MIC validation there. This fixes CVE-2020-26141. It
    does the same as ath10k_htt_rx_proc_rx_ind_hl() for SDIO which passed
    MIC verification case. This applies only to QCA6174/QCA9377 PCIe.
    
    Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Wen Gong <wgong@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Link: https://lore.kernel.org/r/20210511200110.c3f1d42c6746.I795593fcaae941c471425b8c7d5f7bb185d29142@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 124ce717f6b257ea3a8b6f6ef2cf26e672456a20
Author: Wen Gong <wgong@codeaurora.org>
Date:   Tue May 11 20:02:55 2021 +0200

    ath10k: drop MPDU which has discard flag set by firmware for SDIO
    
    commit 079a108feba474b4b32bd3471db03e11f2f83b81 upstream.
    
    When the discard flag is set by the firmware for an MPDU, it should be
    dropped. This allows a mitigation for CVE-2020-24588 to be implemented
    in the firmware.
    
    Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Wen Gong <wgong@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Link: https://lore.kernel.org/r/20210511200110.11968c725b5c.Idd166365ebea2771c0c0a38c78b5060750f90e17@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 405d08dda2f9f7e393e8be355d81461f7e235d49
Author: Wen Gong <wgong@codeaurora.org>
Date:   Tue May 11 20:02:54 2021 +0200

    ath10k: drop fragments with multicast DA for SDIO
    
    commit 40e7462dad6f3d06efdb17d26539e61ab6e34db1 upstream.
    
    Fragmentation is not used with multicast frames. Discard unexpected
    fragments with multicast DA. This fixes CVE-2020-26145.
    
    Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Wen Gong <wgong@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Link: https://lore.kernel.org/r/20210511200110.9ca6ca7945a9.I1e18b514590af17c155bda86699bc3a971a8dcf4@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96d4d82652fa013d8b452871305a0c1e5f805d9e
Author: Wen Gong <wgong@codeaurora.org>
Date:   Tue May 11 20:02:53 2021 +0200

    ath10k: drop fragments with multicast DA for PCIe
    
    commit 65c415a144ad8132b6a6d97d4a1919ffc728e2d1 upstream.
    
    Fragmentation is not used with multicast frames. Discard unexpected
    fragments with multicast DA. This fixes CVE-2020-26145.
    
    Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Wen Gong <wgong@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Link: https://lore.kernel.org/r/20210511200110.5a0bd289bda8.Idd6ebea20038fb1cfee6de924aa595e5647c9eae@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bf449a34c0de8becabc3d3a9f76b32cb287347e
Author: Wen Gong <wgong@codeaurora.org>
Date:   Tue May 11 20:02:52 2021 +0200

    ath10k: add CCMP PN replay protection for fragmented frames for PCIe
    
    commit a1166b2653db2f3de7338b9fb8a0f6e924b904ee upstream.
    
    PN replay check for not fragmented frames is finished in the firmware,
    but this was not done for fragmented frames when ath10k is used with
    QCA6174/QCA6377 PCIe. mac80211 has the function
    ieee80211_rx_h_defragment() for PN replay check for fragmented frames,
    but this does not get checked with QCA6174 due to the
    ieee80211_has_protected() condition not matching the cleared Protected
    bit case.
    
    Validate the PN of received fragmented frames within ath10k when CCMP is
    used and drop the fragment if the PN is not correct (incremented by
    exactly one from the previous fragment). This applies only for
    QCA6174/QCA6377 PCIe.
    
    Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Wen Gong <wgong@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Link: https://lore.kernel.org/r/20210511200110.9ba2664866a4.I756e47b67e210dba69966d989c4711ffc02dc6bc@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbc470aa3f93a92233a087cc9b34499ffd0b4c63
Author: Wen Gong <wgong@codeaurora.org>
Date:   Tue May 11 20:02:51 2021 +0200

    mac80211: extend protection against mixed key and fragment cache attacks
    
    commit 3edc6b0d6c061a70d8ca3c3c72eb1f58ce29bfb1 upstream.
    
    For some chips/drivers, e.g., QCA6174 with ath10k, the decryption is
    done by the hardware, and the Protected bit in the Frame Control field
    is cleared in the lower level driver before the frame is passed to
    mac80211. In such cases, the condition for ieee80211_has_protected() is
    not met in ieee80211_rx_h_defragment() of mac80211 and the new security
    validation steps are not executed.
    
    Extend mac80211 to cover the case where the Protected bit has been
    cleared, but the frame is indicated as having been decrypted by the
    hardware. This extends protection against mixed key and fragment cache
    attack for additional drivers/chips. This fixes CVE-2020-24586 and
    CVE-2020-24587 for such cases.
    
    Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Wen Gong <wgong@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Link: https://lore.kernel.org/r/20210511200110.037aa5ca0390.I7bb888e2965a0db02a67075fcb5deb50eb7408aa@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88664d5e5dc9eedddbea9cc8ebb3d57d933f9f8a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue May 11 20:02:50 2021 +0200

    mac80211: do not accept/forward invalid EAPOL frames
    
    commit a8c4d76a8dd4fb9666fc8919a703d85fb8f44ed8 upstream.
    
    EAPOL frames are used for authentication and key management between the
    AP and each individual STA associated in the BSS. Those frames are not
    supposed to be sent by one associated STA to another associated STA
    (either unicast for broadcast/multicast).
    
    Similarly, in 802.11 they're supposed to be sent to the authenticator
    (AP) address.
    
    Since it is possible for unexpected EAPOL frames to result in misbehavior
    in supplicant implementations, it is better for the AP to not allow such
    cases to be forwarded to other clients either directly, or indirectly if
    the AP interface is part of a bridge.
    
    Accept EAPOL (control port) frames only if they're transmitted to the
    own address, or, due to interoperability concerns, to the PAE group
    address.
    
    Disable forwarding of EAPOL (or well, the configured control port
    protocol) frames back to wireless medium in all cases. Previously, these
    frames were accepted from fully authenticated and authorized stations
    and also from unauthenticated stations for one of the cases.
    
    Additionally, to avoid forwarding by the bridge, rewrite the PAE group
    address case to the local MAC address.
    
    Cc: stable@vger.kernel.org
    Co-developed-by: Jouni Malinen <jouni@codeaurora.org>
    Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
    Link: https://lore.kernel.org/r/20210511200110.cb327ed0cabe.Ib7dcffa2a31f0913d660de65ba3c8aca75b1d10f@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bbc06191e36e041ceae76fbc6a36907e301817e6
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue May 11 20:02:49 2021 +0200

    mac80211: prevent attacks on TKIP/WEP as well
    
    commit 7e44a0b597f04e67eee8cdcbe7ee706c6f5de38b upstream.
    
    Similar to the issues fixed in previous patches, TKIP and WEP
    should be protected even if for TKIP we have the Michael MIC
    protecting it, and WEP is broken anyway.
    
    However, this also somewhat protects potential other algorithms
    that drivers might implement.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210511200110.430e8c202313.Ia37e4e5b6b3eaab1a5ae050e015f6c92859dbe27@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8b3a6150dc8ac78d5fdd5fbdfc4806249ef8b2c
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue May 11 20:02:48 2021 +0200

    mac80211: check defrag PN against current frame
    
    commit bf30ca922a0c0176007e074b0acc77ed345e9990 upstream.
    
    As pointed out by Mathy Vanhoef, we implement the RX PN check
    on fragmented frames incorrectly - we check against the last
    received PN prior to the new frame, rather than to the one in
    this frame itself.
    
    Prior patches addressed the security issue here, but in order
    to be able to reason better about the code, fix it to really
    compare against the current frame's PN, not the last stored
    one.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210511200110.bfbc340ff071.Id0b690e581da7d03d76df90bb0e3fd55930bc8a0@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b3774e58e470d0c9ccf156d76fd8a2836f44cef
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue May 11 20:02:47 2021 +0200

    mac80211: add fragment cache to sta_info
    
    commit 3a11ce08c45b50d69c891d71760b7c5b92074709 upstream.
    
    Prior patches protected against fragmentation cache attacks
    by coloring keys, but this shows that it can lead to issues
    when multiple stations use the same sequence number. Add a
    fragment cache to struct sta_info (in addition to the one in
    the interface) to separate fragments for different stations
    properly.
    
    This then automatically clear most of the fragment cache when a
    station disconnects (or reassociates) from an AP, or when client
    interfaces disconnect from the network, etc.
    
    On the way, also fix the comment there since this brings us in line
    with the recommendation in 802.11-2016 ("An AP should support ...").
    Additionally, remove a useless condition (since there's no problem
    purging an already empty list).
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210511200110.fc35046b0d52.I1ef101e3784d13e8f6600d83de7ec9a3a45bcd52@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb1b24f94d1c23512e7b70c91fbb41db1658ff05
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue May 11 20:02:46 2021 +0200

    mac80211: drop A-MSDUs on old ciphers
    
    commit 270032a2a9c4535799736142e1e7c413ca7b836e upstream.
    
    With old ciphers (WEP and TKIP) we shouldn't be using A-MSDUs
    since A-MSDUs are only supported if we know that they are, and
    the only practical way for that is HT support which doesn't
    support old ciphers.
    
    However, we would normally accept them anyway. Since we check
    the MMIC before deaggregating A-MSDUs, and the A-MSDU bit in
    the QoS header is not protected in TKIP (or WEP), this enables
    attacks similar to CVE-2020-24588. To prevent that, drop A-MSDUs
    completely with old ciphers.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210511200110.076543300172.I548e6e71f1ee9cad4b9a37bf212ae7db723587aa@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa00d4928eafe4fe8d854028f73f7af8fdbc9c3c
Author: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
Date:   Tue May 11 20:02:45 2021 +0200

    cfg80211: mitigate A-MSDU aggregation attacks
    
    commit 2b8a1fee3488c602aca8bea004a087e60806a5cf upstream.
    
    Mitigate A-MSDU injection attacks (CVE-2020-24588) by detecting if the
    destination address of a subframe equals an RFC1042 (i.e., LLC/SNAP)
    header, and if so dropping the complete A-MSDU frame. This mitigates
    known attacks, although new (unknown) aggregation-based attacks may
    remain possible.
    
    This defense works because in A-MSDU aggregation injection attacks, a
    normal encrypted Wi-Fi frame is turned into an A-MSDU frame. This means
    the first 6 bytes of the first A-MSDU subframe correspond to an RFC1042
    header. In other words, the destination MAC address of the first A-MSDU
    subframe contains the start of an RFC1042 header during an aggregation
    attack. We can detect this and thereby prevent this specific attack.
    For details, see Section 7.2 of "Fragment and Forge: Breaking Wi-Fi
    Through Frame Aggregation and Fragmentation".
    
    Note that for kernel 4.9 and above this patch depends on "mac80211:
    properly handle A-MSDUs that start with a rfc1042 header". Otherwise
    this patch has no impact and attacks will remain possible.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
    Link: https://lore.kernel.org/r/20210511200110.25d93176ddaf.I9e265b597f2cd23eb44573f35b625947b386a9de@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fe9fae1220e894dd4d1320c6253adebdb80721d
Author: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
Date:   Tue May 11 20:02:44 2021 +0200

    mac80211: properly handle A-MSDUs that start with an RFC 1042 header
    
    commit a1d5ff5651ea592c67054233b14b30bf4452999c upstream.
    
    Properly parse A-MSDUs whose first 6 bytes happen to equal a rfc1042
    header. This can occur in practice when the destination MAC address
    equals AA:AA:03:00:00:00. More importantly, this simplifies the next
    patch to mitigate A-MSDU injection attacks.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
    Link: https://lore.kernel.org/r/20210511200110.0b2b886492f0.I23dd5d685fe16d3b0ec8106e8f01b59f499dffed@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14f29a67f40496c832ca9fe8502e03b10cca6e59
Author: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
Date:   Tue May 11 20:02:43 2021 +0200

    mac80211: prevent mixed key and fragment cache attacks
    
    commit 94034c40ab4a3fcf581fbc7f8fdf4e29943c4a24 upstream.
    
    Simultaneously prevent mixed key attacks (CVE-2020-24587) and fragment
    cache attacks (CVE-2020-24586). This is accomplished by assigning a
    unique color to every key (per interface) and using this to track which
    key was used to decrypt a fragment. When reassembling frames, it is
    now checked whether all fragments were decrypted using the same key.
    
    To assure that fragment cache attacks are also prevented, the ID that is
    assigned to keys is unique even over (re)associations and (re)connects.
    This means fragments separated by a (re)association or (re)connect will
    not be reassembled. Because mac80211 now also prevents the reassembly of
    mixed encrypted and plaintext fragments, all cache attacks are prevented.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
    Link: https://lore.kernel.org/r/20210511200110.3f8290e59823.I622a67769ed39257327a362cfc09c812320eb979@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b90cf214e2bbb3f0a25d19937807238f646d1d72
Author: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
Date:   Tue May 11 20:02:42 2021 +0200

    mac80211: assure all fragments are encrypted
    
    commit 965a7d72e798eb7af0aa67210e37cf7ecd1c9cad upstream.
    
    Do not mix plaintext and encrypted fragments in protected Wi-Fi
    networks. This fixes CVE-2020-26147.
    
    Previously, an attacker was able to first forward a legitimate encrypted
    fragment towards a victim, followed by a plaintext fragment. The
    encrypted and plaintext fragment would then be reassembled. For further
    details see Section 6.3 and Appendix D in the paper "Fragment and Forge:
    Breaking Wi-Fi Through Frame Aggregation and Fragmentation".
    
    Because of this change there are now two equivalent conditions in the
    code to determine if a received fragment requires sequential PNs, so we
    also move this test to a separate function to make the code easier to
    maintain.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
    Link: https://lore.kernel.org/r/20210511200110.30c4394bb835.I5acfdb552cc1d20c339c262315950b3eac491397@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4302a6fdec60e12983974fdc2c858e503398bb7a
Author: Johan Hovold <johan@kernel.org>
Date:   Mon May 24 11:25:11 2021 +0200

    net: hso: fix control-request directions
    
    commit 1a6e9a9c68c1f183872e4bcc947382111c2e04eb upstream.
    
    The direction of the pipe argument must match the request-type direction
    bit or control requests may fail depending on the host-controller-driver
    implementation.
    
    Fix the tiocmset and rfkill requests which erroneously used
    usb_rcvctrlpipe().
    
    Fixes: 72dc1c096c70 ("HSO: add option hso driver")
    Cc: stable@vger.kernel.org      # 2.6.27
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60d171c477e9c8529ec5ade9d7fc9e1f857cad8c
Author: Kees Cook <keescook@chromium.org>
Date:   Tue May 25 12:37:35 2021 -0700

    proc: Check /proc/$pid/attr/ writes against file opener
    
    commit bfb819ea20ce8bbeeba17e1a6418bf8bda91fc28 upstream.
    
    Fix another "confused deputy" weakness[1]. Writes to /proc/$pid/attr/
    files need to check the opener credentials, since these fds do not
    transition state across execve(). Without this, it is possible to
    trick another process (which may have different credentials) to write
    to its own /proc/$pid/attr/ files, leading to unexpected and possibly
    exploitable behaviors.
    
    [1] https://www.kernel.org/doc/html/latest/security/credentials.html?highlight=confused#open-file-credentials
    
    Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f4d9d2f0be7fd60083e131bff6f3db2db83f153
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 21 12:20:53 2021 +0300

    perf scripts python: exported-sql-viewer.py: Fix warning display
    
    commit f56299a9c998e0bfbd4ab07cafe9eb8444512448 upstream.
    
    Deprecation warnings are useful only for the developer, not an end user.
    Display warnings only when requested using the python -W option. This
    stops the display of warnings like:
    
     tools/perf/scripts/python/exported-sql-viewer.py:5102: DeprecationWarning:
             an integer is required (got type PySide2.QtCore.Qt.AlignmentFlag).
             Implicit conversion to integers using __int__ is deprecated, and
             may be removed in a future version of Python.
        err = app.exec_()
    
    Since the warning can be fixed only in PySide2, we must wait for it to
    be finally fixed there.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@vger.kernel.org      # v5.3+
    Link: http://lore.kernel.org/lkml/20210521092053.25683-4-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb08c8d591cb57393cbfb5e2eccebb4c54f8b10a
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 21 12:20:52 2021 +0300

    perf scripts python: exported-sql-viewer.py: Fix Array TypeError
    
    commit fd931b2e234a7cc451a7bbb1965d6ce623189158 upstream.
    
    The 'Array' class is present in more than one python standard library.
    In some versions of Python 3, the following error occurs:
    
    Traceback (most recent call last):
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 4702, in <lambda>
        reports_menu.addAction(CreateAction(label, "Create a new window displaying branch events", lambda a=None,x=dbid: self.NewBranchView(x), self))
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 4727, in NewBranchView
        BranchWindow(self.glb, event_id, ReportVars(), self)
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 3208, in __init__
        self.model = LookupCreateModel(model_name, lambda: BranchModel(glb, event_id, report_vars.where_clause))
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 343, in LookupCreateModel
        model = create_fn()
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 3208, in <lambda>
        self.model = LookupCreateModel(model_name, lambda: BranchModel(glb, event_id, report_vars.where_clause))
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 3124, in __init__
        self.fetcher = SQLFetcher(glb, sql, prep, self.AddSample)
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 2658, in __init__
        self.buffer = Array(c_char, self.buffer_size, lock=False)
    TypeError: abstract class
    
    This apparently happens because Python can be inconsistent about which
    class of the name 'Array' gets imported. Fix by importing explicitly by
    name so that only the desired 'Array' gets imported.
    
    Fixes: 8392b74b575c3 ("perf scripts python: exported-sql-viewer.py: Add ability to display all the database tables")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@vger.kernel.org
    Link: http://lore.kernel.org/lkml/20210521092053.25683-3-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9044d06150d0bfc5586aba00c87b14f5e71fd561
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri May 21 12:20:51 2021 +0300

    perf scripts python: exported-sql-viewer.py: Fix copy to clipboard from Top Calls by elapsed Time report
    
    commit a6172059758ba1b496ae024cece7d5bdc8d017db upstream.
    
    Provide missing argument to prevent following error when copying a
    selection to the clipboard:
    
    Traceback (most recent call last):
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 4041, in <lambda>
        menu.addAction(CreateAction("&Copy selection", "Copy to clipboard", lambda: CopyCellsToClipboardHdr(self.view), self.view))
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 4021, in CopyCellsToClipboardHdr
        CopyCellsToClipboard(view, False, True)
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 4018, in CopyCellsToClipboard
        view.CopyCellsToClipboard(view, as_csv, with_hdr)
      File "tools/perf/scripts/python/exported-sql-viewer.py", line 3871, in CopyTableCellsToClipboard
        val = model.headerData(col, Qt.Horizontal)
    TypeError: headerData() missing 1 required positional argument: 'role'
    
    Fixes: 96c43b9a7ab3b ("perf scripts python: exported-sql-viewer.py: Add copy to clipboard")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@vger.kernel.org
    Link: http://lore.kernel.org/lkml/20210521092053.25683-2-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21e2eb6a950c060b49f257e0d29649a7959ded3d
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Wed May 19 10:45:13 2021 +0300

    perf intel-pt: Fix transaction abort handling
    
    commit cb7987837c31b217b28089bbc78922d5c9187869 upstream.
    
    When adding support for power events, some handling of FUP packets was
    unified. That resulted in breaking reporting of TSX aborts, by not
    considering the associated TIP packet. Fix that.
    
    Example:
    
    A machine that supports TSX is required. It will have flag "rtm". Kernel
    parameter tsx=on may be required.
    
     # for w in `cat /proc/cpuinfo | grep -m1 flags `;do echo $w | grep rtm ; done
     rtm
    
    Test program:
    
     #include <stdio.h>
     #include <immintrin.h>
    
     int main()
     {
            int x = 0;
    
            if (_xbegin() == _XBEGIN_STARTED) {
                    x = 1;
                    _xabort(1);
            } else {
                    printf("x = %d\n", x);
            }
            return 0;
     }
    
    Compile with -mrtm i.e.
    
     gcc -Wall -Wextra -mrtm xabort.c -o xabort
    
    Record:
    
     perf record -e intel_pt/cyc/u --filter 'filter main @ ./xabort' ./xabort
    
    Before:
    
     # perf script --itrace=be -F+flags,+addr,-period,-event --ns
              xabort  1478 [007] 92161.431348552:   tr strt                             0 [unknown] ([unknown]) =>           400b6d main+0x0 (/root/xabort)
              xabort  1478 [007] 92161.431348624:   jmp                            400b96 main+0x29 (/root/xabort) =>           400bae main+0x41 (/root/xabort)
              xabort  1478 [007] 92161.431348624:   return                         400bb4 main+0x47 (/root/xabort) =>           400b87 main+0x1a (/root/xabort)
              xabort  1478 [007] 92161.431348637:   jcc                            400b8a main+0x1d (/root/xabort) =>           400b98 main+0x2b (/root/xabort)
              xabort  1478 [007] 92161.431348644:   tr end  call                   400ba9 main+0x3c (/root/xabort) =>           40f690 printf+0x0 (/root/xabort)
              xabort  1478 [007] 92161.431360859:   tr strt                             0 [unknown] ([unknown]) =>           400bae main+0x41 (/root/xabort)
              xabort  1478 [007] 92161.431360882:   tr end  return                 400bb4 main+0x47 (/root/xabort) =>           401139 __libc_start_main+0x309 (/root/xabort)
    
    After:
    
     # perf script --itrace=be -F+flags,+addr,-period,-event --ns
              xabort  1478 [007] 92161.431348552:   tr strt                             0 [unknown] ([unknown]) =>           400b6d main+0x0 (/root/xabort)
              xabort  1478 [007] 92161.431348624:   tx abrt                        400b93 main+0x26 (/root/xabort) =>           400b87 main+0x1a (/root/xabort)
              xabort  1478 [007] 92161.431348637:   jcc                            400b8a main+0x1d (/root/xabort) =>           400b98 main+0x2b (/root/xabort)
              xabort  1478 [007] 92161.431348644:   tr end  call                   400ba9 main+0x3c (/root/xabort) =>           40f690 printf+0x0 (/root/xabort)
              xabort  1478 [007] 92161.431360859:   tr strt                             0 [unknown] ([unknown]) =>           400bae main+0x41 (/root/xabort)
              xabort  1478 [007] 92161.431360882:   tr end  return                 400bb4 main+0x47 (/root/xabort) =>           401139 __libc_start_main+0x309 (/root/xabort)
    
    Fixes: a472e65fc490a ("perf intel-pt: Add decoder support for ptwrite and power event packets")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@vger.kernel.org
    Link: http://lore.kernel.org/lkml/20210519074515.9262-2-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 854216d7ec1029c464f20cc4b08f7a73f4aefeef
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Wed May 19 10:45:14 2021 +0300

    perf intel-pt: Fix sample instruction bytes
    
    commit c954eb72b31a9dc56c99b450253ec5b121add320 upstream.
    
    The decoder reports the current instruction if it was decoded. In some
    cases the current instruction is not decoded, in which case the instruction
    bytes length must be set to zero. Ensure that is always done.
    
    Note perf script can anyway get the instruction bytes for any samples where
    they are not present.
    
    Also note, that there is a redundant "ptq->insn_len = 0" statement which is
    not removed until a subsequent patch in order to make this patch apply
    cleanly to stable branches.
    
    Example:
    
    A machne that supports TSX is required. It will have flag "rtm". Kernel
    parameter tsx=on may be required.
    
     # for w in `cat /proc/cpuinfo | grep -m1 flags `;do echo $w | grep rtm ; done
     rtm
    
    Test program:
    
     #include <stdio.h>
     #include <immintrin.h>
    
     int main()
     {
            int x = 0;
    
            if (_xbegin() == _XBEGIN_STARTED) {
                    x = 1;
                    _xabort(1);
            } else {
                    printf("x = %d\n", x);
            }
            return 0;
     }
    
    Compile with -mrtm i.e.
    
     gcc -Wall -Wextra -mrtm xabort.c -o xabort
    
    Record:
    
     perf record -e intel_pt/cyc/u --filter 'filter main @ ./xabort' ./xabort
    
    Before:
    
     # perf script --itrace=xe -F+flags,+insn,-period --xed --ns
              xabort  1478 [007] 92161.431348581:   transactions:   x                              400b81 main+0x14 (/root/xabort)          mov $0xffffffff, %eax
              xabort  1478 [007] 92161.431348624:   transactions:   tx abrt                        400b93 main+0x26 (/root/xabort)          mov $0xffffffff, %eax
    
    After:
    
     # perf script --itrace=xe -F+flags,+insn,-period --xed --ns
              xabort  1478 [007] 92161.431348581:   transactions:   x                              400b81 main+0x14 (/root/xabort)          xbegin 0x6
              xabort  1478 [007] 92161.431348624:   transactions:   tx abrt                        400b93 main+0x26 (/root/xabort)          xabort $0x1
    
    Fixes: faaa87680b25d ("perf intel-pt/bts: Report instruction bytes and length in sample")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: stable@vger.kernel.org
    Link: http://lore.kernel.org/lkml/20210519074515.9262-3-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 044bbe8b92ab4e542de7f6c93c88ea65cccd8e29
Author: Rolf Eike Beer <eb@emlix.com>
Date:   Tue May 25 15:08:02 2021 +0800

    iommu/vt-d: Fix sysfs leak in alloc_iommu()
    
    commit 0ee74d5a48635c848c20f152d0d488bf84641304 upstream.
    
    iommu_device_sysfs_add() is called before, so is has to be cleaned on subsequent
    errors.
    
    Fixes: 39ab9555c2411 ("iommu: Add sysfs bindings for struct iommu_device")
    Cc: stable@vger.kernel.org # 4.11.x
    Signed-off-by: Rolf Eike Beer <eb@emlix.com>
    Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
    Link: https://lore.kernel.org/r/17411490.HIIP88n32C@mobilepool36.emlix.com
    Link: https://lore.kernel.org/r/20210525070802.361755-2-baolu.lu@linux.intel.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aba3c7795f51717ae316f3566442dee7cc3eeccb
Author: Anna Schumaker <Anna.Schumaker@Netapp.com>
Date:   Wed May 19 12:54:51 2021 -0400

    NFSv4: Fix a NULL pointer dereference in pnfs_mark_matching_lsegs_return()
    
    commit a421d218603ffa822a0b8045055c03eae394a7eb upstream.
    
    Commit de144ff4234f changes _pnfs_return_layout() to call
    pnfs_mark_matching_lsegs_return() passing NULL as the struct
    pnfs_layout_range argument. Unfortunately,
    pnfs_mark_matching_lsegs_return() doesn't check if we have a value here
    before dereferencing it, causing an oops.
    
    I'm able to hit this crash consistently when running connectathon basic
    tests on NFS v4.1/v4.2 against Ontap.
    
    Fixes: de144ff4234f ("NFSv4: Don't discard segments marked for return in _pnfs_return_layout()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2a35ade2274abf6898f7b054370bae61e16ef43
Author: Aurelien Aptel <aaptel@suse.com>
Date:   Fri May 21 17:19:27 2021 +0200

    cifs: set server->cipher_type to AES-128-CCM for SMB3.0
    
    commit 6d2fcfe6b517fe7cbf2687adfb0a16cdcd5d9243 upstream.
    
    SMB3.0 doesn't have encryption negotiate context but simply uses
    the SMB2_GLOBAL_CAP_ENCRYPTION flag.
    
    When that flag is present in the neg response cifs.ko uses AES-128-CCM
    which is the only cipher available in this context.
    
    cipher_type was set to the server cipher only when parsing encryption
    negotiate context (SMB3.1.1).
    
    For SMB3.0 it was set to 0. This means cipher_type value can be 0 or 1
    for AES-128-CCM.
    
    Fix this by checking for SMB3.0 and encryption capability and setting
    cipher_type appropriately.
    
    Signed-off-by: Aurelien Aptel <aaptel@suse.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c81a4e24cf1481f7f81a9e25bd692941e961d62
Author: Geoffrey D. Bennett <g@b4.vu>
Date:   Fri May 21 17:50:13 2021 +0930

    ALSA: usb-audio: scarlett2: Improve driver startup messages
    
    commit 265d1a90e4fb6d3264d8122fbd10760e5e733be6 upstream.
    
    Add separate init function to call the existing controls_create
    function so a custom error can be displayed if initialisation fails.
    
    Use info level instead of error for notifications.
    
    Display the VID/PID so device_setup is targeted to the right device.
    
    Display "enabled" message to easily confirm that the driver is loaded.
    
    Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/b5d140c65f640faf2427e085fbbc0297b32e5fce.1621584566.git.g@b4.vu
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26314d2784237ffda6cf72bbb8e24a6836b71bbb
Author: Geoffrey D. Bennett <g@b4.vu>
Date:   Fri May 21 17:50:12 2021 +0930

    ALSA: usb-audio: scarlett2: Fix device hang with ehci-pci
    
    commit 764fa6e686e0107c0357a988d193de04cf047583 upstream.
    
    Use usb_rcvctrlpipe() not usb_sndctrlpipe() for USB control input in
    the Scarlett Gen 2 mixer driver. This fixes the device hang during
    initialisation when used with the ehci-pci host driver.
    
    Fixes: 9e4d5c1be21f ("ALSA: usb-audio: Scarlett Gen 2 mixer interface")
    Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/66a3d05dac325d5b53e4930578e143cef1f50dbe.1621584566.git.g@b4.vu
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fc2850259e6995a39e378d861eb79db4beb2ca3
Author: Hui Wang <hui.wang@canonical.com>
Date:   Sat May 22 11:47:41 2021 +0800

    ALSA: hda/realtek: Headphone volume is controlled by Front mixer
    
    commit 119b75c150773425a89033215eab4d15d4198f8b upstream.
    
    On some ASUS and MSI machines, the audio codec is alc1220 and the
    Headphone is connected to audio mixer 0xf and DAC 0x5, in theory
    the Headphone volume is controlled by DAC 0x5 (Heapdhone Playback
    Volume), but somehow it is controlled by DAC 0x2 (Front Playback
    Volume), maybe this is a defect on the codec alc1220.
    
    Because of this issue, the PA couldn't switch the headphone and
    Lineout correctly, If we apply the quirk CLEVO_P950 to those machines,
    the Lineout and Headphone will share the audio mixer 0xc and DAC 0x2,
    and generate Headphone+LO mixer, then PA could handle them when
    switching between them.
    
    BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1206
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Link: https://lore.kernel.org/r/20210522034741.13415-1-hui.wang@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>