commit 0b0649b1d27a768d37f23acf4d88e6e90cca7856
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Aug 25 11:45:54 2022 +0200

    Linux 5.19.4
    
    Link: https://lore.kernel.org/r/20220823080118.128342613@linuxfoundation.org
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Link: https://lore.kernel.org/r/20220824065936.861377531@linuxfoundation.org
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c19305ce5228d63473e4e82d6d0ca8da50a058d2
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jul 15 20:29:03 2022 +0200

    Revert "ALSA: hda: Fix page fault in snd_hda_codec_shutdown()"
    
    commit 53f07e9b010b966017e32be1ca1bbcbcc4cee73d upstream.
    
    This reverts commit 980b3a8790b402e959a6d773b38b771019682be1.
    
    The commit didn't consider the fact that ASoC hdac-hda driver
    initializes the HD-audio stuff without calling
    snd_hda_codec_device_init().  Hence this caused a regression leading
    to Oops.
    
    Revert the commit to restore the behavior.
    
    Fixes: 980b3a8790b4 ("ALSA: hda: Fix page fault in snd_hda_codec_shutdown()")
    Link: https://lore.kernel.org/r/3c40df55-3aee-1e08-493b-7b30cd84dc00@linux.intel.com
    Link: https://lore.kernel.org/r/20220715182903.19594-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 127e3bb0dae18d7c688b23bffd67248e787f37d9
Author: Ren Zhijie <renzhijie2@huawei.com>
Date:   Sun Jun 19 19:54:32 2022 +0800

    scsi: ufs: ufs-mediatek: Fix build error and type mismatch
    
    commit f54912b228a8df6c0133e31bc75628677bb8c6e5 upstream.
    
    If CONFIG_PM_SLEEP is not set.
    
    make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-, will fail:
    
    drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_vreg_fix_vcc’:
    drivers/ufs/host/ufs-mediatek.c:688:46: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long unsigned int’ [-Wformat=]
        snprintf(vcc_name, MAX_VCC_NAME, "vcc-opt%u", res.a1);
                                                 ~^   ~~~~~~
                                                 %lu
    drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_suspend’:
    drivers/ufs/host/ufs-mediatek.c:1371:8: error: implicit declaration of function ‘ufshcd_system_suspend’; did you mean ‘ufs_mtk_system_suspend’? [-Werror=implicit-function-declaration]
      ret = ufshcd_system_suspend(dev);
            ^~~~~~~~~~~~~~~~~~~~~
            ufs_mtk_system_suspend
    drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_resume’:
    drivers/ufs/host/ufs-mediatek.c:1386:9: error: implicit declaration of function ‘ufshcd_system_resume’; did you mean ‘ufs_mtk_system_resume’? [-Werror=implicit-function-declaration]
      return ufshcd_system_resume(dev);
             ^~~~~~~~~~~~~~~~~~~~
             ufs_mtk_system_resume
    cc1: some warnings being treated as errors
    
    The declaration of func "ufshcd_system_suspend()" depends on
    CONFIG_PM_SLEEP, so the function wrapper ufs_mtk_system_suspend() should
    wrapped by CONFIG_PM_SLEEP too.
    
    Link: https://lore.kernel.org/r/20220619115432.205504-1-renzhijie2@huawei.com
    Fixes: 3fd23b8dfb54 ("scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulators")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
    Signed-off-by: Ren Zhijie <renzhijie2@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    [only take the suspend/resume portion of the commit - gregkh]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7000ad53ec1b17bd2fac76984b7b0c663755cbb7
Author: Ye Bin <yebin10@huawei.com>
Date:   Mon Aug 1 19:26:04 2022 +0800

    f2fs: fix null-ptr-deref in f2fs_get_dnode_of_data
    
    [ Upstream commit 4a2c5b7994960fac29cf8a3f4e62855bae1b27d4 ]
    
    There is issue as follows when test f2fs atomic write:
    F2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock
    F2FS-fs (loop0): invalid crc_offset: 0
    F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=1, run fsck to fix.
    F2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=2, run fsck to fix.
    ==================================================================
    BUG: KASAN: null-ptr-deref in f2fs_get_dnode_of_data+0xac/0x16d0
    Read of size 8 at addr 0000000000000028 by task rep/1990
    
    CPU: 4 PID: 1990 Comm: rep Not tainted 5.19.0-rc6-next-20220715 #266
    Call Trace:
     <TASK>
     dump_stack_lvl+0x6e/0x91
     print_report.cold+0x49a/0x6bb
     kasan_report+0xa8/0x130
     f2fs_get_dnode_of_data+0xac/0x16d0
     f2fs_do_write_data_page+0x2a5/0x1030
     move_data_page+0x3c5/0xdf0
     do_garbage_collect+0x2015/0x36c0
     f2fs_gc+0x554/0x1d30
     f2fs_balance_fs+0x7f5/0xda0
     f2fs_write_single_data_page+0xb66/0xdc0
     f2fs_write_cache_pages+0x716/0x1420
     f2fs_write_data_pages+0x84f/0x9a0
     do_writepages+0x130/0x3a0
     filemap_fdatawrite_wbc+0x87/0xa0
     file_write_and_wait_range+0x157/0x1c0
     f2fs_do_sync_file+0x206/0x12d0
     f2fs_sync_file+0x99/0xc0
     vfs_fsync_range+0x75/0x140
     f2fs_file_write_iter+0xd7b/0x1850
     vfs_write+0x645/0x780
     ksys_write+0xf1/0x1e0
     do_syscall_64+0x3b/0x90
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    As 3db1de0e582c commit changed atomic write way which new a cow_inode for
    atomic write file, and also mark cow_inode as FI_ATOMIC_FILE.
    When f2fs_do_write_data_page write cow_inode will use cow_inode's cow_inode
    which is NULL. Then will trigger null-ptr-deref.
    To solve above issue, introduce FI_COW_FILE flag for COW inode.
    
    Fiexes: 3db1de0e582c("f2fs: change the current atomic write way")
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ceb6e2e0ef305b1d76e9241f12a7e105697b8e05
Author: Daeho Jeong <daehojeong@google.com>
Date:   Mon Aug 1 10:08:08 2022 -0700

    f2fs: revive F2FS_IOC_ABORT_VOLATILE_WRITE
    
    [ Upstream commit 23339e5752d01a4b5e122759b002cf896d26f6c1 ]
    
    F2FS_IOC_ABORT_VOLATILE_WRITE was used to abort a atomic write before.
    However it was removed accidentally. So revive it by changing the name,
    since volatile write had gone.
    
    Signed-off-by: Daeho Jeong <daehojeong@google.com>
    Fiexes: 7bc155fec5b3("f2fs: kill volatile write support")
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a050bbba5e115741f0cb960df1634121bb3d847a
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Aug 2 10:59:36 2022 -0700

    MIPS: tlbex: Explicitly compare _PAGE_NO_EXEC against 0
    
    [ Upstream commit 74de14fe05dd6b151d73cb0c73c8ec874cbdcde6 ]
    
    When CONFIG_XPA is enabled, Clang warns:
    
      arch/mips/mm/tlbex.c:629:24: error: converting the result of '<<' to a boolean; did you mean '(1 << _PAGE_NO_EXEC_SHIFT) != 0'? [-Werror,-Wint-in-bool-context]
              if (cpu_has_rixi && !!_PAGE_NO_EXEC) {
                                  ^
      arch/mips/include/asm/pgtable-bits.h:174:28: note: expanded from macro '_PAGE_NO_EXEC'
      # define _PAGE_NO_EXEC          (1 << _PAGE_NO_EXEC_SHIFT)
                                         ^
      arch/mips/mm/tlbex.c:2568:24: error: converting the result of '<<' to a boolean; did you mean '(1 << _PAGE_NO_EXEC_SHIFT) != 0'? [-Werror,-Wint-in-bool-context]
              if (!cpu_has_rixi || !_PAGE_NO_EXEC) {
                                    ^
      arch/mips/include/asm/pgtable-bits.h:174:28: note: expanded from macro '_PAGE_NO_EXEC'
      # define _PAGE_NO_EXEC          (1 << _PAGE_NO_EXEC_SHIFT)
                                         ^
      2 errors generated.
    
    _PAGE_NO_EXEC can be '0' or '1 << _PAGE_NO_EXEC_SHIFT' depending on the
    build and runtime configuration, which is what the negation operators
    are trying to convey. To silence the warning, explicitly compare against
    0 so the result of the '<<' operator is not implicitly converted to a
    boolean.
    
    According to its documentation, GCC enables -Wint-in-bool-context with
    -Wall but this warning is not visible when building the same
    configuration with GCC. It appears GCC only warns when compiling C++,
    not C, although the documentation makes no note of this:
    https://godbolt.org/z/x39q3brxf
    
    Reported-by: Sudip Mukherjee (Codethink) <sudipm.mukherjee@gmail.com>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f350812e2d15278f1d867eeb997407782234fb3c
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Wed Aug 3 17:24:19 2022 +0800

    video: fbdev: i740fb: Check the argument of i740_calc_vclk()
    
    [ Upstream commit 40bf722f8064f50200b8c4f8946cd625b441dda9 ]
    
    Since the user can control the arguments of the ioctl() from the user
    space, under special arguments that may result in a divide-by-zero bug.
    
    If the user provides an improper 'pixclock' value that makes the argumet
    of i740_calc_vclk() less than 'I740_RFREQ_FIX', it will cause a
    divide-by-zero bug in:
        drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX)));
    
    The following log can reveal it:
    
    divide error: 0000 [#1] PREEMPT SMP KASAN PTI
    RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [inline]
    RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [inline]
    RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742
    Call Trace:
     fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034
     do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
     fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189
    
    Fix this by checking the argument of i740_calc_vclk() first.
    
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d4eccd78461c3e3555bff67148432bb6c21d059
Author: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Date:   Mon Aug 1 18:16:41 2022 +0300

    venus: pm_helpers: Fix warning in OPP during probe
    
    [ Upstream commit 1d95af02f23031c2e1cca7607c514b86ce85bc6e ]
    
    Fix the following WARN triggered during Venus driver probe on
    5.19.0-rc8-next-20220728:
    
     WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610
     Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor
      qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+)
      videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched
      snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats
      drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5
      phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro
      lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers
      qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector
      drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6
     CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-20220728 #4
     Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
     pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : dev_pm_opp_set_config+0x49c/0x610
     lr : dev_pm_opp_set_config+0x58/0x610
     sp : ffff8000093c3710
     x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00
     x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810
     x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810
     x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000
     x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858
     x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000
     x11: 0000000000000002 x10: 0000000000000a60 x9 : ffff8000093c35c0
     x8 : ffff4396c4273700 x7 : ffff43983efca6c0 x6 : ffff43983efca640
     x5 : 00000000410fd0d0 x4 : ffff4396c4272c40 x3 : ffffbca3f5d1e008
     x2 : 0000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860
     Call trace:
      dev_pm_opp_set_config+0x49c/0x610
      devm_pm_opp_set_config+0x18/0x70
      vcodec_domains_get+0xb8/0x1638 [venus_core]
      core_get_v4+0x1d8/0x218 [venus_core]
      venus_probe+0xf4/0x468 [venus_core]
      platform_probe+0x68/0xd8
      really_probe+0xbc/0x2a8
      __driver_probe_device+0x78/0xe0
      driver_probe_device+0x3c/0xf0
      __driver_attach+0x70/0x120
      bus_for_each_dev+0x70/0xc0
      driver_attach+0x24/0x30
      bus_add_driver+0x150/0x200
      driver_register+0x64/0x120
      __platform_driver_register+0x28/0x38
      qcom_venus_driver_init+0x24/0x1000 [venus_core]
      do_one_initcall+0x54/0x1c8
      do_init_module+0x44/0x1d0
      load_module+0x16c8/0x1aa0
      __do_sys_finit_module+0xbc/0x110
      __arm64_sys_finit_module+0x20/0x30
      invoke_syscall+0x44/0x108
      el0_svc_common.constprop.0+0xcc/0xf0
      do_el0_svc+0x2c/0xb8
      el0_svc+0x2c/0x88
      el0t_64_sync_handler+0xb8/0xc0
      el0t_64_sync+0x18c/0x190
      qcom-venus: probe of aa00000.video-codec failed with error -16
    
    The fix is re-ordering the code related to OPP core. The OPP core
    expects all configuration options to be provided before the OPP
    table is added.
    
    Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f9357313cdcadb0a311b44c29d4eaccc7fa632f
Author: Zhouyi Zhou <zhouzhouyi@gmail.com>
Date:   Tue Jul 26 09:57:47 2022 +0800

    powerpc/64: Init jump labels before parse_early_param()
    
    [ Upstream commit ca829e05d3d4f728810cc5e4b468d9ebc7745eb3 ]
    
    On 64-bit, calling jump_label_init() in setup_feature_keys() is too
    late because static keys may be used in subroutines of
    parse_early_param() which is again subroutine of early_init_devtree().
    
    For example booting with "threadirqs":
    
      static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init()
      WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120
      ...
      NIP static_key_enable_cpuslocked+0xfc/0x120
      LR  static_key_enable_cpuslocked+0xf8/0x120
      Call Trace:
        static_key_enable_cpuslocked+0xf8/0x120 (unreliable)
        static_key_enable+0x30/0x50
        setup_forced_irqthreads+0x28/0x40
        do_early_param+0xa0/0x108
        parse_args+0x290/0x4e0
        parse_early_options+0x48/0x5c
        parse_early_param+0x58/0x84
        early_init_devtree+0xd4/0x518
        early_setup+0xb4/0x214
    
    So call jump_label_init() just before parse_early_param() in
    early_init_devtree().
    
    Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
    [mpe: Add call trace to change log and minor wording edits.]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220726015747.11754-1-zhouzhouyi@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a77b03098b1491cbaf23aba3f7e5c981755aef2
Author: Steve French <stfrench@microsoft.com>
Date:   Tue Jul 12 11:43:44 2022 -0500

    smb3: check xattr value length earlier
    
    [ Upstream commit 5fa2cffba0b82336a2244d941322eb1627ff787b ]
    
    Coverity complains about assigning a pointer based on
    value length before checking that value length goes
    beyond the end of the SMB.  Although this is even more
    unlikely as value length is a single byte, and the
    pointer is not dereferenced until laterm, it is clearer
    to check the lengths first.
    
    Addresses-Coverity: 1467704 ("Speculative execution data leak")
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14128541cf81047e60168cb6580604f365b04e60
Author: Chao Yu <chao.yu@oppo.com>
Date:   Wed Jul 27 22:51:05 2022 +0800

    f2fs: fix to do sanity check on segment type in build_sit_entries()
    
    [ Upstream commit 09beadf289d6e300553e60d6e76f13c0427ecab3 ]
    
    As Wenqing Liu <wenqingliu0120@gmail.com> reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=216285
    
    RIP: 0010:memcpy_erms+0x6/0x10
     f2fs_update_meta_page+0x84/0x570 [f2fs]
     change_curseg.constprop.0+0x159/0xbd0 [f2fs]
     f2fs_do_replace_block+0x5c7/0x18a0 [f2fs]
     f2fs_replace_block+0xeb/0x180 [f2fs]
     recover_data+0x1abd/0x6f50 [f2fs]
     f2fs_recover_fsync_data+0x12ce/0x3250 [f2fs]
     f2fs_fill_super+0x4459/0x6190 [f2fs]
     mount_bdev+0x2cf/0x3b0
     legacy_get_tree+0xed/0x1d0
     vfs_get_tree+0x81/0x2b0
     path_mount+0x47e/0x19d0
     do_mount+0xce/0xf0
     __x64_sys_mount+0x12c/0x1a0
     do_syscall_64+0x38/0x90
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    The root cause is segment type is invalid, so in f2fs_do_replace_block(),
    f2fs accesses f2fs_sm_info::curseg_array with out-of-range segment type,
    result in accessing invalid curseg->sum_blk during memcpy in
    f2fs_update_meta_page(). Fix this by adding sanity check on segment type
    in build_sit_entries().
    
    Reported-by: Wenqing Liu <wenqingliu0120@gmail.com>
    Signed-off-by: Chao Yu <chao.yu@oppo.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43ce0a0bda2c54dad91d5a1943554eed9e050f55
Author: Chao Yu <chao.yu@oppo.com>
Date:   Mon Jul 25 00:03:23 2022 +0800

    f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()
    
    [ Upstream commit 141170b759e03958f296033bb7001be62d1d363b ]
    
    As Dipanjan Das <mail.dipanjan.das@gmail.com> reported, syzkaller
    found a f2fs bug as below:
    
    RIP: 0010:f2fs_new_node_page+0x19ac/0x1fc0 fs/f2fs/node.c:1295
    Call Trace:
     write_all_xattrs fs/f2fs/xattr.c:487 [inline]
     __f2fs_setxattr+0xe76/0x2e10 fs/f2fs/xattr.c:743
     f2fs_setxattr+0x233/0xab0 fs/f2fs/xattr.c:790
     f2fs_xattr_generic_set+0x133/0x170 fs/f2fs/xattr.c:86
     __vfs_setxattr+0x115/0x180 fs/xattr.c:182
     __vfs_setxattr_noperm+0x125/0x5f0 fs/xattr.c:216
     __vfs_setxattr_locked+0x1cf/0x260 fs/xattr.c:277
     vfs_setxattr+0x13f/0x330 fs/xattr.c:303
     setxattr+0x146/0x160 fs/xattr.c:611
     path_setxattr+0x1a7/0x1d0 fs/xattr.c:630
     __do_sys_lsetxattr fs/xattr.c:653 [inline]
     __se_sys_lsetxattr fs/xattr.c:649 [inline]
     __x64_sys_lsetxattr+0xbd/0x150 fs/xattr.c:649
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    NAT entry and nat bitmap can be inconsistent, e.g. one nid is free
    in nat bitmap, and blkaddr in its NAT entry is not NULL_ADDR, it
    may trigger BUG_ON() in f2fs_new_node_page(), fix it.
    
    Reported-by: Dipanjan Das <mail.dipanjan.das@gmail.com>
    Signed-off-by: Chao Yu <chao.yu@oppo.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2555ea40e38822a71487d00cf1f9dbe1facf148
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 28 14:59:45 2022 +0200

    ALSA: control: Use deferred fasync helper
    
    [ Upstream commit 4a971e84a7ae10a38d875cd2d4e487c8d1682ca3 ]
    
    For avoiding the potential deadlock via kill_fasync() call, use the
    new fasync helpers to defer the invocation from the control API.  Note
    that it's merely a workaround.
    
    Another note: although we haven't received reports about the deadlock
    with the control API, the deadlock is still potentially possible, and
    it's better to align the behavior with other core APIs (PCM and
    timer); so let's move altogether.
    
    Link: https://lore.kernel.org/r/20220728125945.29533-5-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe87784ab3a81f5b98e19182388f19206289e05d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 28 14:59:44 2022 +0200

    ALSA: pcm: Use deferred fasync helper
    
    [ Upstream commit 96b097091c66df4f6fbf5cbff21df6cc02a2f055 ]
    
    For avoiding the potential deadlock via kill_fasync() call, use the
    new fasync helpers to defer the invocation from timer API.  Note that
    it's merely a workaround.
    
    Reported-by: syzbot+8285e973a41b5aa68902@syzkaller.appspotmail.com
    Reported-by: syzbot+669c9abf11a6a011dd09@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20220728125945.29533-4-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2dffd9478f76f843205443cabfe04875b9a05b34
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 28 14:59:43 2022 +0200

    ALSA: timer: Use deferred fasync helper
    
    [ Upstream commit 95cc637c1afd83fb7dd3d7c8a53710488f4caf9c ]
    
    For avoiding the potential deadlock via kill_fasync() call, use the
    new fasync helpers to defer the invocation from PCI API.  Note that
    it's merely a workaround.
    
    Reported-by: syzbot+1ee0910eca9c94f71f25@syzkaller.appspotmail.com
    Reported-by: syzbot+49b10793b867871ee26f@syzkaller.appspotmail.com
    Reported-by: syzbot+8285e973a41b5aa68902@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20220728125945.29533-3-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e1a19a391d016dc21cc57533fd2bec95ed49003
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jul 28 14:59:42 2022 +0200

    ALSA: core: Add async signal helpers
    
    [ Upstream commit ef34a0ae7a2654bc9e58675e36898217fb2799d8 ]
    
    Currently the call of kill_fasync() from an interrupt handler might
    lead to potential spin deadlocks, as spotted by syzkaller.
    Unfortunately, it's not so trivial to fix this lock chain as it's
    involved with the tasklist_lock that is touched in allover places.
    
    As a temporary workaround, this patch provides the way to defer the
    async signal notification in a work.  The new helper functions,
    snd_fasync_helper() and snd_kill_faync() are replacements for
    fasync_helper() and kill_fasync(), respectively.  In addition,
    snd_fasync_free() needs to be called at the destructor of the relevant
    file object.
    
    Link: https://lore.kernel.org/r/20220728125945.29533-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb952a7683ae2ebab5797fa35a60a68d33fdeecc
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Thu Jul 14 18:08:00 2022 +1000

    powerpc/ioda/iommu/debugfs: Generate unique debugfs entries
    
    [ Upstream commit d73b46c3c1449bf27f793b9d9ee86ed70c7a7163 ]
    
    The iommu_table::it_index is a LIOBN which is not initialized on PowerNV
    as it is not used except IOMMU debugfs where it is used for a node name.
    
    This initializes it_index witn a unique number to avoid warnings and
    have a node for every iommu_table.
    
    This should not cause any behavioral change without CONFIG_IOMMU_DEBUGFS.
    
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220714080800.3712998-1-aik@ozlabs.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea64c14beb0ff2a603ae55b7b0b9a4c2efdb3a42
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Wed Jul 27 16:31:30 2022 +0200

    ovl: warn if trusted xattr creation fails
    
    [ Upstream commit b10b85fe5149ee8b39fbbf86095b303632dde2cd ]
    
    When mounting overlayfs in an unprivileged user namespace, trusted xattr
    creation will fail.  This will lead to failures in some file operations,
    e.g. in the following situation:
    
      mkdir lower upper work merged
      mkdir lower/directory
      mount -toverlay -olowerdir=lower,upperdir=upper,workdir=work none merged
      rmdir merged/directory
      mkdir merged/directory
    
    The last mkdir will fail:
    
      mkdir: cannot create directory 'merged/directory': Input/output error
    
    The cause for these failures is currently extremely non-obvious and hard to
    debug.  Hence, warn the user and suggest using the userxattr mount option,
    if it is not already supplied and xattr creation fails during the
    self-check.
    
    Reported-by: Alois Wohlschlager <alois1@gmx-topmail.de>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c5be8157340edde440a9bb160b8789f01451ce2
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Wed Jul 27 13:47:49 2022 +0100

    ASoC: codecs: va-macro: use fsgen as clock
    
    [ Upstream commit 30097967e0566cac817273ef76add100f6b0f463 ]
    
    VA Macro fsgen clock is supplied to other LPASS Macros using proper
    clock apis, however the internal user uses the registers directly without
    clk apis. This approch has race condition where in external users of
    the clock might cut the clock while VA macro is actively using this.
    
    Moving the internal usage to clk apis would provide a proper refcounting
    and avoid such race conditions.
    
    This issue was noticed while headset was pulled out while recording is
    in progress and shifting record patch to DMIC.
    
    Reported-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Tested-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
    Link: https://lore.kernel.org/r/20220727124749.4604-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8044f035b0c7e3c5cc3af001e702288ca64af1ca
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Jul 11 16:19:30 2022 +0200

    powerpc/32: Don't always pass -mcpu=powerpc to the compiler
    
    [ Upstream commit 446cda1b21d9a6b3697fe399c6a3a00ff4a285f5 ]
    
    Since commit 4bf4f42a2feb ("powerpc/kbuild: Set default generic
    machine type for 32-bit compile"), when building a 32 bits kernel
    with a bi-arch version of GCC, or when building a book3s/32 kernel,
    the option -mcpu=powerpc is passed to GCC at all time, relying on it
    being eventually overriden by a subsequent -mcpu=xxxx.
    
    But when building the same kernel with a 32 bits only version of GCC,
    that is not done, relying on gcc being built with the expected default
    CPU.
    
    This logic has two problems. First, it is a bit fragile to rely on
    whether the GCC version is bi-arch or not, because today we can have
    bi-arch versions of GCC configured with a 32 bits default. Second,
    there are some versions of GCC which don't support -mcpu=powerpc,
    for instance for e500 SPE-only versions.
    
    So, stop relying on this approximative logic and allow the user to
    decide whether he/she wants to use the toolchain's default CPU or if
    he/she wants to set one, and allow only possible CPUs based on the
    selected target.
    
    Reported-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Tested-by: Pali Rohár <pali@kernel.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/d4df724691351531bf46d685d654689e5dfa0d74.1657549153.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0919caa1639167cce056c5fe7d302059ee5dc89
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Tue Jun 14 12:34:09 2022 +0200

    powerpc/32: Set an IBAT covering up to _einittext during init
    
    [ Upstream commit 2a0fb3c155c97c75176e557d61f8e66c1bd9b735 ]
    
    Always set an IBAT covering up to _einittext during init because when
    CONFIG_MODULES is not selected there is no reason to have an exception
    handler for kernel instruction TLB misses.
    
    It implies DBAT and IBAT are now totaly independent, IBATs are set
    by setibat() and DBAT by setbat().
    
    This allows to revert commit 9bb162fa26ed ("powerpc/603: Fix
    boot failure with DEBUG_PAGEALLOC and KFENCE")
    
    Reported-by: Maxime Bizon <mbizon@freebox.fr>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/ce7f04a39593934d9b1ee68c69144ccd3d4da4a1.1655202804.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2f242d958759dd153087b5729d49b8814e276aa
Author: Laurent Dufour <ldufour@linux.ibm.com>
Date:   Wed Jul 13 17:47:29 2022 +0200

    powerpc/pseries/mobility: set NMI watchdog factor during an LPM
    
    [ Upstream commit 118b1366930c8c833b8b36abef657f40d4e26610 ]
    
    During an LPM, while the memory transfer is in progress on the arrival
    side, some latencies are generated when accessing not yet transferred
    pages on the arrival side. Thus, the NMI watchdog may be triggered too
    frequently, which increases the risk to hit an NMI interrupt in a bad
    place in the kernel, leading to a kernel panic.
    
    Disabling the Hard Lockup Watchdog until the memory transfer could be a
    too strong work around, some users would want this timeout to be
    eventually triggered if the system is hanging even during an LPM.
    
    Introduce a new sysctl variable nmi_watchdog_factor. It allows to apply
    a factor to the NMI watchdog timeout during an LPM. Just before the CPUs
    are stopped for the switchover sequence, the NMI watchdog timer is set
    to watchdog_thresh + factor%
    
    A value of 0 has no effect. The default value is 200, meaning that the
    NMI watchdog is set to 30s during LPM (based on a 10s watchdog_thresh
    value). Once the memory transfer is achieved, the factor is reset to 0.
    
    Setting this value to a high number is like disabling the NMI watchdog
    during an LPM.
    
    Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220713154729.80789-5-ldufour@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1bac78a8c189cf57a7191726052e5c1ff6bb72d
Author: Laurent Dufour <ldufour@linux.ibm.com>
Date:   Wed Jul 13 17:47:28 2022 +0200

    powerpc/watchdog: introduce a NMI watchdog's factor
    
    [ Upstream commit f5e74e836097d1004077390717d4bd95d4a2c27a ]
    
    Introduce a factor which would apply to the NMI watchdog timeout.
    
    This factor is a percentage added to the watchdog_tresh value. The value is
    set under the watchdog_mutex protection and lockup_detector_reconfigure()
    is called to recompute wd_panic_timeout_tb.
    
    Once the factor is set, it remains until it is set back to 0, which means
    no impact.
    
    Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220713154729.80789-4-ldufour@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 409135fdaca62a6ab868886df164b404d34a3b10
Author: Laurent Dufour <ldufour@linux.ibm.com>
Date:   Wed Jul 13 17:47:27 2022 +0200

    watchdog: export lockup_detector_reconfigure
    
    [ Upstream commit 7c56a8733d0a2a4be2438a7512566e5ce552fccf ]
    
    In some circumstances it may be interesting to reconfigure the watchdog
    from inside the kernel.
    
    On PowerPC, this may helpful before and after a LPAR migration (LPM) is
    initiated, because it implies some latencies, watchdog, and especially NMI
    watchdog is expected to be triggered during this operation. Reconfiguring
    the watchdog with a factor, would prevent it to happen too frequently
    during LPM.
    
    Rename lockup_detector_reconfigure() as __lockup_detector_reconfigure() and
    create a new function lockup_detector_reconfigure() calling
    __lockup_detector_reconfigure() under the protection of watchdog_mutex.
    
    Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
    [mpe: Squash in build fix from Laurent, reported by Sachin]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220713154729.80789-3-ldufour@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce60aca6f7aaf82d9da6ca0fa2b5f8f670fae782
Author: Yong Zhi <yong.zhi@intel.com>
Date:   Mon Jul 25 14:49:09 2022 -0500

    ASoC: Intel: sof_nau8825: Move quirk check to the front in late probe
    
    [ Upstream commit 5b56db90bbaf9d8581e5e6268727d8ad706555e4 ]
    
    The sof_rt5682_quirk check was placed in the middle of
    hdmi handling code, move it to the front to be consistent
    with sof_rt5682.c/sof_card_late_probe().
    
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Signed-off-by: Yong Zhi <yong.zhi@intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20220725194909.145418-11-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit abed2fd437f07c8ed53688628800e8ed401aeb60
Author: Andrey Turkin <andrey.turkin@gmail.com>
Date:   Mon Jul 25 14:49:03 2022 -0500

    ASoC: Intel: sof_es8336: ignore GpioInt when looking for speaker/headset GPIO lines
    
    [ Upstream commit 751e77011f7a43a204bf2a5d02fbf5f8219bc531 ]
    
    This fixes speaker GPIO detection on machines those ACPI tables
    list their jack detection GpioInt before output GpioIo.
    GpioInt entry can never be the speaker/headphone amplifier control
    so it makes sense to only look for GpioIo entries when looking for them.
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Andrey Turkin <andrey.turkin@gmail.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20220725194909.145418-5-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 73626a23b37038e446ba4f0bed1cc1a724e25fc7
Author: Andrey Turkin <andrey.turkin@gmail.com>
Date:   Mon Jul 25 14:49:02 2022 -0500

    ASoC: Intel: sof_es8336: Fix GPIO quirks set via module option
    
    [ Upstream commit 5e60f1cfb830342304200437121f440b72b54f54 ]
    
    The two GPIO quirk bits only affected actual GPIO selection
    when set by the quirks table. They were reported as being
    in effect when set via module options but actually did nothing.
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Andrey Turkin <andrey.turkin@gmail.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20220725194909.145418-4-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 728ba1b70fb6d6eb78a0fa57330027da12cde847
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Jul 25 14:53:41 2022 -0500

    ASoC: SOF: Intel: hda: add sanity check on SSP index reported by NHLT
    
    [ Upstream commit e51699505042fb365df3a0ce68b850ccd9ad0108 ]
    
    We should have a limited trust in the BIOS and verify that the SSP
    index reported in NHLT is valid for each platform.
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Link: https://lore.kernel.org/r/20220725195343.145603-2-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b7d0c2a4fba2e3deb41460cfe20234890746bc6
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Tue Jul 19 22:20:14 2022 +0800

    ALSA: hda/realtek: Enable speaker and mute LEDs for HP laptops
    
    [ Upstream commit c578d5da10dc429c6676ab09f3fec0b79b31633a ]
    
    Two more HP laptops that use cs35l41 AMP for speaker and GPIO for mute
    LEDs.
    
    So use the existing quirk to enable them accordingly.
    
    [ Sort the entries at the SSID order by tiwai ]
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Reviewed-by: Lucas Tanure <tanureal@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20220719142015.244426-1-kai.heng.feng@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d79c34048804001e4e941a9696e1bbf42337c8e8
Author: Xianting Tian <xianting.tian@linux.alibaba.com>
Date:   Mon Jun 6 16:23:08 2022 +0800

    RISC-V: Add fast call path of crash_kexec()
    
    [ Upstream commit 3f1901110a89b0e2e13adb2ac8d1a7102879ea98 ]
    
    Currently, almost all archs (x86, arm64, mips...) support fast call
    of crash_kexec() when "regs && kexec_should_crash()" is true. But
    RISC-V not, it can only enter crash system via panic(). However panic()
    doesn't pass the regs of the real accident scene to crash_kexec(),
    it caused we can't get accurate backtrace via gdb,
            $ riscv64-linux-gnu-gdb vmlinux vmcore
            Reading symbols from vmlinux...
            [New LWP 95]
            #0  console_unlock () at kernel/printk/printk.c:2557
            2557                    if (do_cond_resched)
            (gdb) bt
            #0  console_unlock () at kernel/printk/printk.c:2557
            #1  0x0000000000000000 in ?? ()
    
    With the patch we can get the accurate backtrace,
            $ riscv64-linux-gnu-gdb vmlinux vmcore
            Reading symbols from vmlinux...
            [New LWP 95]
            #0  0xffffffe00063a4e0 in test_thread (data=<optimized out>) at drivers/test_crash.c:81
            81             *(int *)p = 0xdead;
            (gdb)
            (gdb) bt
            #0  0xffffffe00064d5c0 in test_thread (data=<optimized out>) at drivers/test_crash.c:81
            #1  0x0000000000000000 in ?? ()
    
    Test code to produce NULL address dereference in test_crash.c,
            void *p = NULL;
            *(int *)p = 0xdead;
    
    Reviewed-by: Guo Ren <guoren@kernel.org>
    Tested-by: Xianting Tian <xianting.tian@linux.alibaba.com>
    Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20220606082308.2883458-1-xianting.tian@linux.alibaba.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f41d0c601081890c8e61b694a4e603f4f580055a
Author: Celeste Liu <coelacanthus@outlook.com>
Date:   Tue May 31 15:56:52 2022 +0800

    riscv: mmap with PROT_WRITE but no PROT_READ is invalid
    
    [ Upstream commit 2139619bcad7ac44cc8f6f749089120594056613 ]
    
    As mentioned in Table 4.5 in RISC-V spec Volume 2 Section 4.3, write
    but not read is "Reserved for future use.". For now, they are not valid.
    In the current code, -wx is marked as invalid, but -w- is not marked
    as invalid.
    This patch refines that judgment.
    
    Reported-by: xctan <xc-tan@outlook.com>
    Co-developed-by: dram <dramforever@live.com>
    Signed-off-by: dram <dramforever@live.com>
    Co-developed-by: Ruizhe Pan <c141028@gmail.com>
    Signed-off-by: Ruizhe Pan <c141028@gmail.com>
    Signed-off-by: Celeste Liu <coelacanthus@outlook.com>
    Link: https://lore.kernel.org/r/PH7PR14MB559464DBDD310E755F5B21E8CEDC9@PH7PR14MB5594.namprd14.prod.outlook.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fef71da84f51c395c367f9e9a9ebb74a3f0a5a8
Author: Mark Brown <broonie@kernel.org>
Date:   Mon Jul 18 15:04:05 2022 +0100

    ASoC: nau8821: Don't unconditionally free interrupt
    
    [ Upstream commit 2d86cef353b8f3d20b16f8c5615742fd6938c801 ]
    
    The remove() operation unconditionally frees the interrupt for the device
    but we may not actually have an interrupt so there might be nothing to
    free. Since the interrupt is requested after all other resources we don't
    need the explicit free anyway, unwinding is guaranteed to be safe, so just
    delete the remove() function and let devm take care of things.
    
    Reported-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Tested-by: Zheyu Ma <zheyuma97@gmail.com>
    Link: https://lore.kernel.org/r/20220718140405.57233-1-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a57f15f876f3df3bb2db2d665a8d271ffa3f70a2
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Tue Jul 5 20:04:36 2022 +0100

    riscv: dts: canaan: Add k210 topology information
    
    [ Upstream commit d9d193dea8666bbf69fc21c5bdcdabaa34a466e3 ]
    
    The k210 has no cpu-map node, so tools like hwloc cannot correctly
    parse the topology. Add the node using the existing node labels.
    
    Reported-by: Brice Goglin <Brice.Goglin@inria.fr>
    Link: https://github.com/open-mpi/hwloc/issues/536
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Link: https://lore.kernel.org/r/20220705190435.1790466-6-mail@conchuod.ie
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit beb779e433981b81d4fcf82abd327d12b5605fff
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Tue Jul 5 20:04:34 2022 +0100

    riscv: dts: sifive: Add fu740 topology information
    
    [ Upstream commit bf6cd1c01c959a31002dfa6784c0d8caffed4cf1 ]
    
    The fu740 has no cpu-map node, so tools like hwloc cannot correctly
    parse the topology. Add the node using the existing node labels.
    
    Reported-by: Brice Goglin <Brice.Goglin@inria.fr>
    Link: https://github.com/open-mpi/hwloc/issues/536
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Link: https://lore.kernel.org/r/20220705190435.1790466-4-mail@conchuod.ie
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1ab94899083047776c2aa0b18007051afe9dce7
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Thu Jul 14 06:28:15 2022 +0000

    ASoC: rsnd: care default case on rsnd_ssiu_busif_err_irq_ctrl()
    
    [ Upstream commit ef30911d3c39fd57884c348c29b9cbff88def155 ]
    
    Before, ssiu.c didn't care SSI5-8, thus,
    commit b1384d4c95088d0 ("ASoC: rsnd: care default case on
    rsnd_ssiu_busif_err_status_clear()") cares it for status clear.
    
    But we should care it for error irq handling, too.
    This patch cares it.
    
    Reported-by: Nguyen Bao Nguyen <nguyen.nguyen.yj@renesas.com>
    Reported-by: Nishiyama Kunihiko <kunihiko.nishiyama.dn@renesas.com>
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Link: https://lore.kernel.org/r/871quocio1.wl-kuninori.morimoto.gx@renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7218511f0a3136c0637c524be7e1866aa8550b1e
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Tue Jul 12 16:10:22 2022 +0300

    ASoC: SOF: sof-client-probes: Only load the driver if IPC3 is used
    
    [ Upstream commit 9b93eda355089b36482f7a2f134bdd24be70f907 ]
    
    The current implementation of probes only supports IPC3 and should not be
    loaded for other IPC implementation.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Link: https://lore.kernel.org/r/20220712131022.1124-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48945246cf802b9866f3a821103f1a7a196baf68
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Tue Jul 12 15:23:56 2022 +0300

    ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware boot
    
    [ Upstream commit 499cc881b09c8283ab5e75b0d6d21cb427722161 ]
    
    It is not yet clear, but it is possible to create a firmware so broken
    that it will send a reply message before a FW_READY message (it is not
    yet clear if FW_READY will arrive later).
    Since the reply_data is allocated only after the FW_READY message, this
    will lead to a NULL pointer dereference if not filtered out.
    
    The issue was reported with IPC4 firmware but the same condition is present
    for IPC3.
    
    Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20220712122357.31282-3-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 230f646085d17a008b609eb8fe8befb8811868f0
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Tue Jul 12 15:23:55 2022 +0300

    ASoC: SOF: Intel: cnl: Do not process IPC reply before firmware boot
    
    [ Upstream commit acacd9eefd0def5a83244d88e5483b5f38ee7287 ]
    
    It is not yet clear, but it is possible to create a firmware so broken
    that it will send a reply message before a FW_READY message (it is not
    yet clear if FW_READY will arrive later).
    Since the reply_data is allocated only after the FW_READY message, this
    will lead to a NULL pointer dereference if not filtered out.
    
    The issue was reported with IPC4 firmware but the same condition is present
    for IPC3.
    
    Reported-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20220712122357.31282-2-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62c8639072ae6cd7bbc0a27ea4d1faf7091f0a07
Author: Helge Deller <deller@gmx.de>
Date:   Fri Jul 8 11:44:54 2022 +0200

    modules: Ensure natural alignment for .altinstructions and __bug_table sections
    
    [ Upstream commit 87c482bdfa79f378297d92af49cdf265be199df5 ]
    
    In the kernel image vmlinux.lds.S linker scripts the .altinstructions
    and __bug_table sections are 4- or 8-byte aligned because they hold 32-
    and/or 64-bit values.
    
    Most architectures use altinstructions and BUG() or WARN() in modules as
    well, but in the module linker script (module.lds.S) those sections are
    currently missing. As consequence the linker will store their content
    byte-aligned by default, which then can lead to unnecessary unaligned
    memory accesses by the CPU when those tables are processed at runtime.
    
    Usually unaligned memory accesses are unnoticed, because either the
    hardware (as on x86 CPUs) or in-kernel exception handlers (e.g. on
    parisc or sparc) emulate and fix them up at runtime. Nevertheless, such
    unaligned accesses introduce a performance penalty and can even crash
    the kernel if there is a bug in the unalignment exception handlers
    (which happened once to me on the parisc architecture and which is why I
    noticed that issue at all).
    
    This patch fixes a non-critical issue and might be backported at any time.
    It's trivial and shouldn't introduce any regression because it simply
    tells the linker to use a different (8-byte alignment) for those
    sections by default.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Link: https://lore.kernel.org/all/Yr8%2Fgr8e8I7tVX4d@p100/
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e02db5c2c2ee15bc9a9ec8a86a614fd091e584dc
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Wed Jul 6 14:02:27 2022 +0200

    ALSA: hda: Fix page fault in snd_hda_codec_shutdown()
    
    [ Upstream commit 980b3a8790b402e959a6d773b38b771019682be1 ]
    
    If early probe of HDAudio bus driver fails e.g.: due to missing
    firmware file, snd_hda_codec_shutdown() ends in manipulating
    uninitialized codec->pcm_list_head causing page fault.
    
    Iinitialization of HDAudio codec in ASoC is split in two:
    - snd_hda_codec_device_init()
    - snd_hda_codec_device_new()
    
    snd_hda_codec_device_init() is called during probe_codecs() by HDAudio
    bus driver while snd_hda_codec_device_new() is called by
    codec-component's ->probe(). The second call will not happen until all
    components required by related sound card are present within the ASoC
    framework. With firmware failing to load during the PCI's deferred
    initialization i.e.: probe_work(), no platform components are ever
    registered. HDAudio codec enumeration is done at that point though, so
    the codec components became registered to ASoC framework, calling
    snd_hda_codec_device_init() in the process.
    
    Now, during platform reboot snd_hda_codec_shutdown() is called for every
    codec found on the HDAudio bus causing oops if any of them has not
    completed both of their initialization steps. Relocating field
    initialization fixes the issue.
    
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://lore.kernel.org/r/20220706120230.427296-7-cezary.rojewski@intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a0105e779e3cf46cb930b984c7cae08146dd4fa
Author: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Date:   Thu Jul 7 14:41:48 2022 +0200

    ASoC: Intel: avs: Set max DMA segment size
    
    [ Upstream commit 8544eebc78c96f1834a46b26ade3e7ebe785d10c ]
    
    Apparently it is possible for code to allocate large buffers which may
    cause warnings as reported in [1]. This was fixed for HDA, SOF and
    skylake in patchset [2], fix it also for avs driver.
    
    [1] https://github.com/thesofproject/linux/issues/3430
    [2] https://lore.kernel.org/all/20220215132756.31236-1-tiwai@suse.de/
    
    Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://lore.kernel.org/r/20220707124153.1858249-8-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b4f50e13d7eab6f806b214c4168e797a3acbc34c
Author: Yunfei Wang <yf.wang@mediatek.com>
Date:   Thu Jun 30 17:29:25 2022 +0800

    iommu/io-pgtable-arm-v7s: Add a quirk to allow pgtable PA up to 35bit
    
    [ Upstream commit bfdd231374181254742c5e2faef0bef2d30c0ee4 ]
    
    Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA and
    cause pgtable PA size larger than 32bit.
    
    Since Mediatek IOMMU hardware support at most 35bit PA in pgtable,
    so add a quirk to allow the PA of pgtables support up to bit35.
    
    Signed-off-by: Ning Li <ning.li@mediatek.com>
    Signed-off-by: Yunfei Wang <yf.wang@mediatek.com>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Acked-by: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20220630092927.24925-2-yf.wang@mediatek.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a80016c40cc797c7f3e5a705b8e12ae447280335
Author: Liang He <windhl@126.com>
Date:   Fri Jul 1 20:41:12 2022 +0800

    mips: cavium-octeon: Fix missing of_node_put() in octeon2_usb_clocks_start
    
    [ Upstream commit 7a9f743ceead60ed454c46fbc3085ee9a79cbebb ]
    
    We should call of_node_put() for the reference 'uctl_node' returned by
    of_get_parent() which will increase the refcount. Otherwise, there will
    be a refcount leak bug.
    
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7a4866734deac0cb6a1214a1065ffc87f5b2e1d
Author: Schspa Shi <schspa@gmail.com>
Date:   Wed Jun 29 10:29:48 2022 +0800

    vfio: Clear the caps->buf to NULL after free
    
    [ Upstream commit 6641085e8d7b3f061911517f79a2a15a0a21b97b ]
    
    On buffer resize failure, vfio_info_cap_add() will free the buffer,
    report zero for the size, and return -ENOMEM.  As additional
    hardening, also clear the buffer pointer to prevent any chance of a
    double free.
    
    Signed-off-by: Schspa Shi <schspa@gmail.com>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Link: https://lore.kernel.org/r/20220629022948.55608-1-schspa@gmail.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f61c957050d674c3703f88a17d46faa217e9884
Author: Fabiano Rosas <farosas@linux.ibm.com>
Date:   Wed May 25 10:05:50 2022 -0300

    KVM: PPC: Book3S HV: Fix "rm_exit" entry in debugfs timings
    
    [ Upstream commit 9981bace85d816ed8724ac46e49285e8488d29e6 ]
    
    At debugfs/kvm/<pid>/vcpu0/timings we show how long each part of the
    code takes to run:
    
    $ cat /sys/kernel/debug/kvm/*-*/vcpu0/timings
    rm_entry: 123785 49398892 118 4898
    rm_intr: 123780 6075890 22 390
    rm_exit: 0 0 0 0                     <-- NOK
    guest: 123780 46732919988 402 9997638
    cede: 0 0 0 0                        <-- OK, no cede napping in P9
    
    The "rm_exit" is always showing zero because it is the last one and
    end_timing does not increment the counter of the previous entry.
    
    We can fix it by calling accumulate_time again instead of
    end_timing. That way the counter gets incremented. The rest of the
    arithmetic can be ignored because there are no timing points after
    this and the accumulators are reset before the next round.
    
    Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220525130554.2614394-2-farosas@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6ed634eedb1a8a6a8cb110a7695c7abb70ffcbf
Author: Liang He <windhl@126.com>
Date:   Sat Jun 18 14:08:50 2022 +0800

    tty: serial: Fix refcount leak bug in ucc_uart.c
    
    [ Upstream commit d24d7bb2cd947676f9b71fb944d045e09b8b282f ]
    
    In soc_info(), of_find_node_by_type() will return a node pointer
    with refcount incremented. We should use of_node_put() when it is
    not used anymore.
    
    Acked-by: Timur Tabi <timur@kernel.org>
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20220618060850.4058525-1-windhl@126.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f531f0c5c7fa43baef103067308b494f42e6bd0
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue May 31 15:29:51 2022 -0700

    lib/list_debug.c: Detect uninitialized lists
    
    [ Upstream commit 0cc011c576aaa4de505046f7a6c90933d7c749a9 ]
    
    In some circumstances, attempts are made to add entries to or to remove
    entries from an uninitialized list.  A prime example is
    amdgpu_bo_vm_destroy(): It is indirectly called from
    ttm_bo_init_reserved() if that function fails, and tries to remove an
    entry from a list.  However, that list is only initialized in
    amdgpu_bo_create_vm() after the call to ttm_bo_init_reserved() returned
    success.  This results in crashes such as
    
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: 0000 [#1] PREEMPT SMP NOPTI
     CPU: 1 PID: 1479 Comm: chrome Not tainted 5.10.110-15768-g29a72e65dae5
     Hardware name: Google Grunt/Grunt, BIOS Google_Grunt.11031.149.0 07/15/2020
     RIP: 0010:__list_del_entry_valid+0x26/0x7d
     ...
     Call Trace:
      amdgpu_bo_vm_destroy+0x48/0x8b
      ttm_bo_init_reserved+0x1d7/0x1e0
      amdgpu_bo_create+0x212/0x476
      ? amdgpu_bo_user_destroy+0x23/0x23
      ? kmem_cache_alloc+0x60/0x271
      amdgpu_bo_create_vm+0x40/0x7d
      amdgpu_vm_pt_create+0xe8/0x24b
     ...
    
    Check if the list's prev and next pointers are NULL to catch such problems.
    
    Link: https://lkml.kernel.org/r/20220531222951.92073-1-linux@roeck-us.net
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0082e99a9074ff88eff729c70c93454c8588d8e1
Author: Kiselev, Oleg <okiselev@amazon.com>
Date:   Wed Jul 20 04:27:48 2022 +0000

    ext4: avoid resizing to a partial cluster size
    
    [ Upstream commit 69cb8e9d8cd97cdf5e293b26d70a9dee3e35e6bd ]
    
    This patch avoids an attempt to resize the filesystem to an
    unaligned cluster boundary.  An online resize to a size that is not
    integral to cluster size results in the last iteration attempting to
    grow the fs by a negative amount, which trips a BUG_ON and leaves the fs
    with a corrupted in-memory superblock.
    
    Signed-off-by: Oleg Kiselev <okiselev@amazon.com>
    Link: https://lore.kernel.org/r/0E92A0AB-4F16-4F1A-94B7-702CC6504FDE@amazon.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2522041d248a8c969cbbc97e1fc2cd8b4de120d
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Thu Jul 14 18:59:03 2022 +0200

    ext4: block range must be validated before use in ext4_mb_clear_bb()
    
    [ Upstream commit 1e1c2b86ef86a8477fd9b9a4f48a6bfe235606f6 ]
    
    Block range to free is validated in ext4_free_blocks() using
    ext4_inode_block_valid() and then it's passed to ext4_mb_clear_bb().
    However in some situations on bigalloc file system the range might be
    adjusted after the validation in ext4_free_blocks() which can lead to
    troubles on corrupted file systems such as one found by syzkaller that
    resulted in the following BUG
    
    kernel BUG at fs/ext4/ext4.h:3319!
    PREEMPT SMP NOPTI
    CPU: 28 PID: 4243 Comm: repro Kdump: loaded Not tainted 5.19.0-rc6+ #1
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014
    RIP: 0010:ext4_free_blocks+0x95e/0xa90
    Call Trace:
     <TASK>
     ? lock_timer_base+0x61/0x80
     ? __es_remove_extent+0x5a/0x760
     ? __mod_timer+0x256/0x380
     ? ext4_ind_truncate_ensure_credits+0x90/0x220
     ext4_clear_blocks+0x107/0x1b0
     ext4_free_data+0x15b/0x170
     ext4_ind_truncate+0x214/0x2c0
     ? _raw_spin_unlock+0x15/0x30
     ? ext4_discard_preallocations+0x15a/0x410
     ? ext4_journal_check_start+0xe/0x90
     ? __ext4_journal_start_sb+0x2f/0x110
     ext4_truncate+0x1b5/0x460
     ? __ext4_journal_start_sb+0x2f/0x110
     ext4_evict_inode+0x2b4/0x6f0
     evict+0xd0/0x1d0
     ext4_enable_quotas+0x11f/0x1f0
     ext4_orphan_cleanup+0x3de/0x430
     ? proc_create_seq_private+0x43/0x50
     ext4_fill_super+0x295f/0x3ae0
     ? snprintf+0x39/0x40
     ? sget_fc+0x19c/0x330
     ? ext4_reconfigure+0x850/0x850
     get_tree_bdev+0x16d/0x260
     vfs_get_tree+0x25/0xb0
     path_mount+0x431/0xa70
     __x64_sys_mount+0xe2/0x120
     do_syscall_64+0x5b/0x80
     ? do_user_addr_fault+0x1e2/0x670
     ? exc_page_fault+0x70/0x170
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    RIP: 0033:0x7fdf4e512ace
    
    Fix it by making sure that the block range is properly validated before
    used every time it changes in ext4_free_blocks() or ext4_mb_clear_bb().
    
    Link: https://syzkaller.appspot.com/bug?id=5266d464285a03cee9dbfda7d2452a72c3c2ae7c
    Reported-by: syzbot+15cd994e273307bf5cfa@syzkaller.appspotmail.com
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Cc: Tadeusz Struk <tadeusz.struk@linaro.org>
    Tested-by: Tadeusz Struk <tadeusz.struk@linaro.org>
    Link: https://lore.kernel.org/r/20220714165903.58260-1-lczerner@redhat.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit baa9f14ff470b301b6980db4deb58eb0efe79c3c
Author: Ye Bin <yebin10@huawei.com>
Date:   Wed Jun 22 17:02:23 2022 +0800

    ext4: avoid remove directory when directory is corrupted
    
    [ Upstream commit b24e77ef1c6d4dbf42749ad4903c97539cc9755a ]
    
    Now if check directoy entry is corrupted, ext4_empty_dir may return true
    then directory will be removed when file system mounted with "errors=continue".
    In order not to make things worse just return false when directory is corrupted.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220622090223.682234-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb3a4f73f43f839df981dda5859e8e075067a360
Author: Wentao_Liang <Wentao_Liang_g@163.com>
Date:   Thu Jul 28 19:39:19 2022 +0800

    drivers:md:fix a potential use-after-free bug
    
    [ Upstream commit 104212471b1c1817b311771d817fb692af983173 ]
    
    In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and
    may cause sh to be released. However, sh is subsequently used in lines
    2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in an
    use-after-free bug.
    
    It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of
    the function.
    
    Signed-off-by: Wentao_Liang <Wentao_Liang_g@163.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22d908afbd769c484c28f28f2db23f4b99fc08fd
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Sun Jul 24 11:58:43 2022 +0300

    nvmet-tcp: fix lockdep complaint on nvmet_tcp_wq flush during queue teardown
    
    [ Upstream commit 533d2e8b4d5e4c89772a0adce913525fb86cbbee ]
    
    We probably need nvmet_tcp_wq to have MEM_RECLAIM as we are
    sending/receiving for the socket from works on this workqueue.
    Also this eliminates lockdep complaints:
    --
    [ 6174.010200] workqueue: WQ_MEM_RECLAIM
    nvmet-wq:nvmet_tcp_release_queue_work [nvmet_tcp] is flushing
    !WQ_MEM_RECLAIM nvmet_tcp_wq:nvmet_tcp_io_work [nvmet_tcp]
    [ 6174.010216] WARNING: CPU: 20 PID: 14456 at kernel/workqueue.c:2628
    check_flush_dependency+0x110/0x14c
    
    Reported-by: Yi Zhang <yi.zhang@redhat.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0fce640d81e2ba97b9a8bf4cbaaeb28855481a5e
Author: Logan Gunthorpe <logang@deltatee.com>
Date:   Thu Jun 16 13:19:31 2022 -0600

    md/raid5: Make logic blocking check consistent with logic that blocks
    
    [ Upstream commit 6e3f50d30af847bebce072182bd735e90a294c6a ]
    
    The check in raid5_make_request differs very slightly from the logic
    that causes it to block lower down. This likely does not cause a bug
    as the check is fuzzy anyway (as reshape may move on between the first
    check and the subsequent check). However, make it consistent so it can
    be cleaned up in a subsequent patch.
    
    The condition which causes the schedule is:
    
     !(mddev->reshape_backwards ? logical_sector < conf->reshape_progress :
       logical_sector >= conf->reshape_progress) &&
      (mddev->reshape_backwards ? logical_sector < conf->reshape_safe :
       logical_sector >= conf->reshape_safe)
    
    The condition that causes the early bailout is made to match this.
    
    Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a320a192cae8b7bdcbbf6a715e9dfb076b933a3
Author: Logan Gunthorpe <logang@deltatee.com>
Date:   Wed Jun 8 10:27:56 2022 -0600

    md: Notify sysfs sync_completed in md_reap_sync_thread()
    
    [ Upstream commit 9973f0fa7d20269fe6fefe6333997fb5914449c1 ]
    
    The mdadm test 07layouts randomly produces a kernel hung task deadlock.
    The deadlock is caused by the suspend_lo/suspend_hi files being set by
    the mdadm background process during reshape and not being cleared
    because the process hangs. (Leaving aside the issue of the fragility of
    freezing kernel tasks by buggy userspace processes...)
    
    When the background mdadm process hangs it, is waiting (without a
    timeout) on a change to the sync_completed file signalling that the
    reshape has completed. The process is woken up a couple times when
    the reshape finishes but it is woken up before MD_RECOVERY_RUNNING
    is cleared so sync_completed_show() reports 0 instead of "none".
    
    To fix this, notify the sysfs file in md_reap_sync_thread() after
    MD_RECOVERY_RUNNING has been cleared. This wakes up mdadm and causes
    it to continue and write to suspend_lo/suspend_hi to allow IO to
    continue.
    
    Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 51854ee9535cdbe1d38d6d9e0d642ccdbf88a28d
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Wed Jun 29 00:04:08 2022 +0200

    phy: samsung: phy-exynos-pcie: sanitize init/power_on callbacks
    
    [ Upstream commit f2812227bb07e2eaee74253f11cea1576945df31 ]
    
    The exynos-pcie driver called phy_power_on() before phy_init() for some
    historical reasons. However the generic PHY framework assumes that the
    proper sequence is to call phy_init() first, then phy_power_on(). The
    operations done by both functions should be considered as one action and as
    such they are called by the exynos-pcie driver (without doing anything
    between them). The initialization is just a sequence of register writes,
    which cannot be altered without breaking the hardware operation.
    
    To match the generic PHY framework requirement, simply move all register
    writes to the phy_init()/phy_exit() and drop power_on()/power_off()
    callbacks. This way the driver will also work with the old (incorrect)
    PHY initialization call sequence.
    
    Link: https://lore.kernel.org/r/20220628220409.26545-1-m.szyprowski@samsung.com
    Reported-by: Bjorn Helgaas <helgaas@kernel.org>
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Chanho Park <chanho61.park@samsung.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-By: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55faab828d23b5602e8408a0c3873c5185d6751a
Author: Stafford Horne <shorne@gmail.com>
Date:   Fri Jul 29 19:54:08 2022 +0900

    openrisc: io: Define iounmap argument as volatile
    
    [ Upstream commit 52e0ea900202d23843daee8f7089817e81dd3dd7 ]
    
    When OpenRISC enables PCI it allows for more drivers to be compiled
    resulting in exposing the following with -Werror.
    
        drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe':
        drivers/video/fbdev/riva/fbdev.c:2062:42: error:
                passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type
    
        drivers/video/fbdev/nvidia/nvidia.c: In function 'nvidiafb_probe':
        drivers/video/fbdev/nvidia/nvidia.c:1414:20: error:
                passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type
    
        drivers/scsi/aic7xxx/aic7xxx_osm.c: In function 'ahc_platform_free':
        drivers/scsi/aic7xxx/aic7xxx_osm.c:1231:41: error:
                passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type
    
    Most architectures define the iounmap argument to be volatile.  To fix this
    issue we do the same for OpenRISC.  This patch must go before PCI is enabled on
    OpenRISC to avoid any compile failures.
    
    Link: https://lore.kernel.org/lkml/20220729033728.GA2195022@roeck-us.net/
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Stafford Horne <shorne@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e004a35e8148ad9fc438b0479884641acf382896
Author: Li Zhijian <lizhijian@fujitsu.com>
Date:   Tue Jul 26 03:16:26 2022 +0000

    Revert "RDMA/rxe: Create duplicate mapping tables for FMRs"
    
    [ Upstream commit 1e75550648da1fa1cd1969e7597355de8fe8caf6 ]
    
    Below 2 commits will be reverted:
     commit 8ff5f5d9d8cf ("RDMA/rxe: Prevent double freeing rxe_map_set()")
     commit 647bf13ce944 ("RDMA/rxe: Create duplicate mapping tables for FMRs")
    
    The community has a few bug reports which pointed this commit at last.
    Some proposals are raised up in the meantime but all of them have no
    follow-up operation.
    
    The previous commit led the map_set of FMR to be not available any more if
    the MR is registered again after invalidating. Although the mentioned
    patch try to fix a potential race in building/accessing the same table
    for fast memory regions, it broke rtrs etc ULPs. Since the latter could
    be worse, revert this patch.
    
    With previous commit, it's observed that a same MR in rnbd server will
    trigger below code path:
     -> rxe_mr_init_fast()
     |-> alloc map_set() # map_set is uninitialized
     |...-> rxe_map_mr_sg() # build the map_set
         |-> rxe_mr_set_page()
     |...-> rxe_reg_fast_mr() # mr->state change to VALID from FREE that means
                              # we can access host memory(such rxe_mr_copy)
     |...-> rxe_invalidate_mr() # mr->state change to FREE from VALID
     |...-> rxe_reg_fast_mr() # mr->state change to VALID from FREE,
                              # but map_set was not built again
     |...-> rxe_mr_copy() # kernel crash due to access wild addresses
                          # that lookup from the map_set
    
    The backtraces are not always identical.
    [1st]----------
      RIP: 0010:lookup_iova+0x66/0xa0 [rdma_rxe]
      Code: 00 00 00 48 d3 ee 89 32 c3 4c 8b 18 49 8b 3b 48 8b 47 08 48 39 c6 72 38 48 29 c6 45 31 d2 b8 01 00 00 00 48 63 c8 48 c1 e1 04 <48> 8b 4c 0f 08 48 39 f1 77 21 83 c0 01 48 29 ce 3d 00 01 00 00 75
      RSP: 0018:ffffb7ff80063bf0 EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff9b9949d86800 RCX: 0000000000000000
      RDX: ffffb7ff80063c00 RSI: 0000000049f6b378 RDI: 002818da00000004
      RBP: 0000000000000120 R08: ffffb7ff80063c08 R09: ffffb7ff80063c04
      R10: 0000000000000002 R11: ffff9b9916f7eef8 R12: ffff9b99488a0038
      R13: ffff9b99488a0038 R14: ffff9b9914fb346a R15: ffff9b990ab27000
      FS:  0000000000000000(0000) GS:ffff9b997dc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007efc33a98ed0 CR3: 0000000014f32004 CR4: 00000000001706f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       rxe_mr_copy.part.0+0x6f/0x140 [rdma_rxe]
       rxe_responder+0x12ee/0x1b60 [rdma_rxe]
       ? rxe_icrc_check+0x7e/0x100 [rdma_rxe]
       ? rxe_rcv+0x1d0/0x780 [rdma_rxe]
       ? rxe_icrc_hdr.isra.0+0xf6/0x160 [rdma_rxe]
       rxe_do_task+0x67/0xb0 [rdma_rxe]
       rxe_xmit_packet+0xc7/0x210 [rdma_rxe]
       rxe_requester+0x680/0xee0 [rdma_rxe]
       ? update_load_avg+0x5f/0x690
       ? update_load_avg+0x5f/0x690
       ? rtrs_clt_recv_done+0x1b/0x30 [rtrs_client]
    
    [2nd]----------
      RIP: 0010:rxe_mr_copy.part.0+0xa8/0x140 [rdma_rxe]
      Code: 00 00 49 c1 e7 04 48 8b 00 4c 8d 2c d0 48 8b 44 24 10 4d 03 7d 00 85 ed 7f 10 eb 6c 89 54 24 0c 49 83 c7 10 31 c0 85 ed 7e 5e <49> 8b 3f 8b 14 24 4c 89 f6 48 01 c7 85 d2 74 06 48 89 fe 4c 89 f7
      RSP: 0018:ffffae3580063bf8 EFLAGS: 00010202
      RAX: 0000000000018978 RBX: ffff9d7ef7a03600 RCX: 0000000000000008
      RDX: 000000000000007c RSI: 000000000000007c RDI: ffff9d7ef7a03600
      RBP: 0000000000000120 R08: ffffae3580063c08 R09: ffffae3580063c04
      R10: ffff9d7efece0038 R11: ffff9d7ec4b1db00 R12: ffff9d7efece0038
      R13: ffff9d7ef4098260 R14: ffff9d7f11e23c6a R15: 4c79500065708144
      FS:  0000000000000000(0000) GS:ffff9d7f3dc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fce47276c60 CR3: 0000000003f66004 CR4: 00000000001706f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       rxe_responder+0x12ee/0x1b60 [rdma_rxe]
       ? rxe_icrc_check+0x7e/0x100 [rdma_rxe]
       ? rxe_rcv+0x1d0/0x780 [rdma_rxe]
       ? rxe_icrc_hdr.isra.0+0xf6/0x160 [rdma_rxe]
       rxe_do_task+0x67/0xb0 [rdma_rxe]
       rxe_xmit_packet+0xc7/0x210 [rdma_rxe]
       rxe_requester+0x680/0xee0 [rdma_rxe]
       ? update_load_avg+0x5f/0x690
       ? update_load_avg+0x5f/0x690
       ? rtrs_clt_recv_done+0x1b/0x30 [rtrs_client]
       rxe_do_task+0x67/0xb0 [rdma_rxe]
       tasklet_action_common.constprop.0+0x92/0xc0
       __do_softirq+0xe1/0x2d8
       run_ksoftirqd+0x21/0x30
       smpboot_thread_fn+0x183/0x220
       ? sort_range+0x20/0x20
       kthread+0xe2/0x110
       ? kthread_complete_and_exit+0x20/0x20
       ret_from_fork+0x22/0x30
    
    Link: https://lore.kernel.org/r/1658805386-2-1-git-send-email-lizhijian@fujitsu.com
    Link: https://lore.kernel.org/all/20220210073655.42281-1-guoqing.jiang@linux.dev/T/
    Link: https://www.spinics.net/lists/linux-rdma/msg110836.html
    Link: https://lore.kernel.org/lkml/94a5ea93-b8bb-3a01-9497-e2021f29598a@linux.dev/t/
    Tested-by: Md Haris Iqbal <haris.iqbal@ionos.com>
    Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa6e96cb21658496f21ea5db10ae49bbc79f5801
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Jul 21 22:40:54 2022 +0200

    dmaengine: sprd: Cleanup in .remove() after pm_runtime_get_sync() failed
    
    [ Upstream commit 1e42f82cbec7b2cc4873751e7791e6611901c5fc ]
    
    It's not allowed to quit remove early without cleaning up completely.
    Otherwise this results in resource leaks that probably yield graver
    problems later. Here for example some tasklets might survive the lifetime
    of the sprd-dma device and access sdev which is freed after .remove()
    returns.
    
    As none of the device freeing requires an active device, just ignore the
    return value of pm_runtime_get_sync().
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
    Link: https://lore.kernel.org/r/20220721204054.323602-1-u.kleine-koenig@pengutronix.de
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32a979841d790271afdca6f198b348dbdffc172a
Author: Akhil R <akhilrajeev@nvidia.com>
Date:   Wed Jul 20 16:10:44 2022 +0530

    dmaengine: tegra: Add terminate() for Tegra234
    
    [ Upstream commit 36834c67016794b8fa03d7672a5b7f2cc4529298 ]
    
    In certain cases where the DMA client bus gets corrupted or if the
    end device ceases to send/receive data, DMA can wait indefinitely
    for the data to be received/sent. Attempting to terminate the transfer
    will put the DMA in pause flush mode and it remains there.
    
    The channel is irrecoverable once this pause times out in Tegra194 and
    earlier chips. Whereas, from Tegra234, it can be recovered by disabling
    the channel and reprograming it.
    
    Hence add a new terminate() function that ignores the outcome of
    dma_pause() so that terminate_all() can proceed to disable the channel.
    
    Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20220720104045.16099-3-akhilrajeev@nvidia.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 59e659594420e9445be1478f99fe834793526758
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Jul 12 16:17:07 2022 -0400

    selftests/kprobe: Do not test for GRP/ without event failures
    
    [ Upstream commit f5eab65ff2b76449286d18efc7fee3e0b72f7d9b ]
    
    A new feature is added where kprobes (and other probes) do not need to
    explicitly state the event name when creating a probe. The event name will
    come from what is being attached.
    
    That is:
    
      # echo 'p:foo/ vfs_read' > kprobe_events
    
    Will no longer error, but instead create an event:
    
      # cat kprobe_events
     p:foo/p_vfs_read_0 vfs_read
    
    This should not be tested as an error case anymore. Remove it from the
    selftest as now this feature "breaks" the selftest as it no longer fails
    as expected.
    
    Link: https://lore.kernel.org/all/1656296348-16111-1-git-send-email-quic_linyyuan@quicinc.com/
    Link: https://lkml.kernel.org/r/20220712161707.6dc08a14@gandalf.local.home
    
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0cd4d17ce33eba20274c31836f411a57688287e
Author: Liao Chang <liaochang1@huawei.com>
Date:   Wed May 25 16:02:41 2022 +0800

    csky/kprobe: reclaim insn_slot on kprobe unregistration
    
    [ Upstream commit a2310c74d418deca0f1d749c45f1f43162510f51 ]
    
    On kprobe registration kernel allocate one insn_slot for new kprobe,
    but it forget to reclaim the insn_slot on unregistration, leading to a
    potential leakage.
    
    Reported-by: Chen Guokai <chenguokai17@mails.ucas.ac.cn>
    Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Liao Chang <liaochang1@huawei.com>
    Signed-off-by: Guo Ren <guoren@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0a5e36832ffd96f08fb6b39e7e61c835b3186c1b
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Thu Jun 30 14:04:25 2022 -0500

    RDMA/rxe: Limit the number of calls to each tasklet
    
    [ Upstream commit eff6d998ca297cb0b2e53b032a56cf8e04dd8b17 ]
    
    Limit the maximum number of calls to each tasklet from rxe_do_task()
    before yielding the cpu. When the limit is reached reschedule the tasklet
    and exit the calling loop. This patch prevents one tasklet from consuming
    100% of a cpu core and causing a deadlock or soft lockup.
    
    Link: https://lore.kernel.org/r/20220630190425.2251-9-rpearsonhpe@gmail.com
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f03d253ba71994b196f342a7acad448a56812a8c
Author: Sudeep Holla <sudeep.holla@arm.com>
Date:   Wed Jul 20 13:55:39 2022 +0100

    ACPI: PPTT: Leave the table mapped for the runtime usage
    
    [ Upstream commit 0c80f9e165f8f9cca743d7b6cbdb54362da297e0 ]
    
    Currently, everytime an information needs to be fetched from the PPTT,
    the table is mapped via acpi_get_table() and unmapped after the use via
    acpi_put_table() which is fine. However we do this at runtime especially
    when the CPU is hotplugged out and plugged in back since we re-populate
    the cache topology and other information.
    
    However, with the support to fetch LLC information from the PPTT in the
    cpuhotplug path which is executed in the atomic context, it is preferred
    to avoid mapping and unmapping of the PPTT for every single use as the
    acpi_get_table() might sleep waiting for a mutex.
    
    In order to avoid the same, the table is needs to just mapped once on
    the boot CPU and is never unmapped allowing it to be used at runtime
    with out the hassle of mapping and unmapping the table.
    
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Cc: Rafael J. Wysocki <rafael@kernel.org>
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    
    --
    
    Hi Rafael,
    
    Sorry to bother you again on this PPTT changes. Guenter reported an issue
    with lockdep enabled in -next that include my cacheinfo/arch_topology changes
    to utilise LLC from PPTT in the CPU hotplug path.
    
    Please ack the change once you are happy so that I can get it merged with
    other fixes via Greg's tree.
    
    Regards,
    Sudeep
    
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Link: https://lore.kernel.org/r/20220720-arch_topo_fixes-v3-2-43d696288e84@arm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a28c93fd39ad5f69c697d5ba459c701665674185
Author: Takeshi Saito <takeshi.saito.xv@renesas.com>
Date:   Wed Jul 20 09:29:01 2022 +0200

    mmc: renesas_sdhi: newer SoCs don't need manual tap correction
    
    [ Upstream commit 00e8c11c137b2e4b2bf54dc9881cf32e3441ddb4 ]
    
    The newest Gen3 SoCs and Gen4 SoCs do not need manual tap correction
    with HS400 anymore. So, instead of checking the SDHI version, add a
    quirk flag and set manual tap correction only for affected SoCs.
    
    Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com>
    [wsa: rebased, renamed the quirk variable, removed stale comment]
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://lore.kernel.org/r/20220720072901.1266-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d05aeebbde8c69593d8aa512b7c08b8f0ad25ba
Author: Ben Dooks <ben.dooks@sifive.com>
Date:   Fri Jul 8 18:01:53 2022 +0100

    dmaengine: dw-axi-dmac: ignore interrupt if no descriptor
    
    [ Upstream commit 820f5ce999d2f99961e88c16d65cd26764df0590 ]
    
    If the channel has no descriptor and the interrupt is raised then the
    kernel will OOPS. Check the result of vchan_next_desc() in the handler
    axi_chan_block_xfer_complete() to avoid the error happening.
    
    Signed-off-by: Ben Dooks <ben.dooks@sifive.com>
    Link: https://lore.kernel.org/r/20220708170153.269991-4-ben.dooks@sifive.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad764df73ae5eada265fffc0408404703cbb2b8d
Author: Ben Dooks <ben.dooks@sifive.com>
Date:   Fri Jul 8 18:01:52 2022 +0100

    dmaengine: dw-axi-dmac: do not print NULL LLI during error
    
    [ Upstream commit 86cb0defe0e275453bc39e856bb523eb425a6537 ]
    
    During debugging we have seen an issue where axi_chan_dump_lli()
    is passed a NULL LLI pointer which ends up causing an OOPS due
    to trying to get fields from it. Simply print NULL LLI and exit
    to avoid this.
    
    Signed-off-by: Ben Dooks <ben.dooks@sifive.com>
    Link: https://lore.kernel.org/r/20220708170153.269991-3-ben.dooks@sifive.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30b2f5fc6482b03efda0f27111a0df6ffb63e231
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Jul 15 16:03:14 2022 +0200

    of: overlay: Move devicetree_corrupt() check up
    
    [ Upstream commit e385b0ba6a137f34953e746d70d543660c2de1a0 ]
    
    There is no point in doing several preparatory steps in
    of_overlay_fdt_apply(), only to see of_overlay_apply() return early
    because of a corrupt device tree.
    
    Move the check for a corrupt device tree from of_overlay_apply() to
    of_overlay_fdt_apply(), to check for this as early as possible.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Frank Rowand <frank.rowand@sony.com>
    Tested-by: Frank Rowand <frank.rowand@sony.com>
    Signed-off-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/c91ce7112eb5167ea46a43d8a980e76b920010ba.1657893306.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 462f8d4cbc96aae4664fc1ff17a3aada8447d2f8
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Wed Jul 13 13:56:17 2022 +0200

    um: add "noreboot" command line option for PANIC_TIMEOUT=-1 setups
    
    [ Upstream commit dda520d07b95072a0b63f6c52a8eb566d08ea897 ]
    
    QEMU has a -no-reboot option, which halts instead of reboots when the
    guest asks to reboot. This is invaluable when used with
    CONFIG_PANIC_TIMEOUT=-1 (and panic_on_warn), because it allows panics
    and warnings to be caught immediately in CI. Implement this in UML too,
    by way of a basic setup param.
    
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5fecb67738e69c16e40f257d87b9ae6b94d47f40
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Thu Jul 14 20:42:10 2022 +0800

    PCI/ACPI: Guard ARM64-specific mcfg_quirks
    
    [ Upstream commit 40a6cc141b4b9580de140bcb3e893445708acc5d ]
    
    Guard ARM64-specific quirks with CONFIG_ARM64 to avoid build errors,
    since mcfg_quirks will be shared by more than one architectures.
    
    Link: https://lore.kernel.org/r/20220714124216.1489304-2-chenhuacai@loongson.cn
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2557780ee7818b701681c226fa4cb7c0b171665
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Jul 11 21:14:48 2022 +0200

    cxl: Fix a memory leak in an error handling path
    
    [ Upstream commit 3a15b45b5454da862376b5d69a4967f5c6fa1368 ]
    
    A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the
    error handling path of afu_allocate_irqs().
    
    Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/ce5869418f5838187946eb6b11a52715a93ece3d.1657566849.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 300ae4fd800bc0bedc3dfb3ecf59af3074f88201
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Jun 6 19:41:28 2022 +0300

    pinctrl: intel: Check against matching data instead of ACPI companion
    
    [ Upstream commit c551bd81d198bf1dcd4398d5454acdc0309dbe77 ]
    
    In some cases we may get a platform device that has ACPI companion
    which is different to the pin control described in the ACPI tables.
    This is primarily happens when device is instantiated by board file.
    
    In order to allow this device being enumerated, refactor
    intel_pinctrl_get_soc_data() to check the matching data instead of
    ACPI companion.
    
    Reported-by: Henning Schild <henning.schild@siemens.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Tested-by: Henning Schild <henning.schild@siemens.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Acked-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15670c28103dd810a21313cf872b416b0bbca1ac
Author: Chanho Park <chanho61.park@samsung.com>
Date:   Wed Jul 6 11:02:55 2022 +0900

    scsi: ufs: ufs-exynos: Change ufs phy control sequence
    
    [ Upstream commit 3d73b200f9893d8f5ba5d105e8b69c8d16744fa2 ]
    
    Since commit 1599069a62c6 ("phy: core: Warn when phy_power_on is called
    before phy_init"), the following warning has been reported:
    
            phy_power_on was called before phy_init
    
    To address this, we need to remove phy_power_on from exynos_ufs_phy_init()
    and move it after phy_init. phy_power_off and phy_exit are also necessary
    in exynos_ufs_remove().
    
    Link: https://lore.kernel.org/r/20220706020255.151177-4-chanho61.park@samsung.com
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Chanho Park <chanho61.park@samsung.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef577017cdcc938c0270caac7a17c5061a8499fc
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Sat Jun 25 15:17:22 2022 +0200

    mmc: tmio: avoid glitches when resetting
    
    [ Upstream commit 2e586f8a5b0ed4a525014a692923ac96f6647816 ]
    
    If we reset because of an error, we need to preserve values for the
    clock frequency. Otherwise, glitches may be seen on the bus.
    
    To achieve that, we introduce a 'preserve' parameter to the reset
    function and the IP core specific reset callbacks to handle everything
    accordingly.
    
    Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://lore.kernel.org/r/20220625131722.1397-1-wsa@kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 325da44d085e0584124ee67d2e9610f71aa5346f
Author: Oded Gabbay <ogabbay@kernel.org>
Date:   Fri Jun 24 16:45:02 2022 +0300

    habanalabs/gaudi: mask constant value before cast
    
    [ Upstream commit e3f49437a2e0221a387ecd192d742ae1434e1e3a ]
    
    This fixes a sparse warning of
    "cast truncates bits from constant value"
    
    Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19958bf4ef3124f6e93fd9e2de0b54d2a356a4db
Author: Ofir Bitton <obitton@habana.ai>
Date:   Wed Jun 15 16:11:31 2022 +0300

    habanalabs/gaudi: fix shift out of bounds
    
    [ Upstream commit 01622098aeb05a5efbb727199bbc2a4653393255 ]
    
    When validating NIC queues, queue offset calculation must be
    performed only for NIC queues.
    
    Signed-off-by: Ofir Bitton <obitton@habana.ai>
    Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
    Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a4aa11781f595800fc05b15d6ef152c0bab7ada
Author: Tal Cohen <talcohen@habana.ai>
Date:   Wed Jun 8 16:02:09 2022 +0300

    habanalabs/gaudi: invoke device reset from one code block
    
    [ Upstream commit be572e67dafbf8004d46a2c9d97338c107efb60e ]
    
    In order to prepare the driver code for device reset event
    notification, change the event handler function flow to call
    device reset from one code block.
    
    In addition, the commit fixes an issue that reset was performed
    w/o checking the 'hard_reset_on_fw_event' state and w/o setting
    the HL_DRV_RESET_DELAY flag.
    
    Signed-off-by: Tal Cohen <talcohen@habana.ai>
    Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
    Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb806b52acb047358a5b5a64ee39664de2448386
Author: Dafna Hirschfeld <dhirschfeld@habana.ai>
Date:   Thu May 19 10:54:30 2022 +0300

    habanalabs: add terminating NULL to attrs arrays
    
    [ Upstream commit 78d503087be190eab36290644ccec050135e7c70 ]
    
    Arrays of struct attribute are expected to be NULL terminated.
    This is required by API methods such as device_add_groups.
    This fixes a crash when loading the driver for Goya device.
    
    Signed-off-by: Dafna Hirschfeld <dhirschfeld@habana.ai>
    Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
    Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c209db797d6409e3b315cecc400c09d2696227eb
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Fri Jul 8 16:15:20 2022 -0700

    coresight: etm4x: avoid build failure with unrolled loops
    
    [ Upstream commit 4d45bc82df667ad9e9cb8361830e54fc1264e993 ]
    
    When the following configs are enabled:
    * CORESIGHT
    * CORESIGHT_SOURCE_ETM4X
    * UBSAN
    * UBSAN_TRAP
    
    Clang fails assemble the kernel with the error:
    <instantiation>:1:7: error: expected constant expression in '.inst' directive
    .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
          ^
    drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in
    macro instantiation
    etm4x_relaxed_read32(csa, TRCCNTVRn(i));
    ^
    drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from
    macro 'etm4x_relaxed_read32'
    read_etm4x_sysreg_offset((offset), false)))
    ^
    drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded
    from macro 'read_etm4x_sysreg_offset'
    __val = read_etm4x_sysreg_const_offset((offset));       \
            ^
    drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from
    macro 'read_etm4x_sysreg_const_offset'
    READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
    ^
    drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from
    macro 'READ_ETM4x_REG'
    read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
    ^
    arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro
    'read_sysreg_s'
    asm volatile(__mrs_s("%0", r) : "=r" (__val));                  \
                 ^
    arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
    "       mrs_s " v ", " __stringify(r) "\n"                      \
     ^
    
    Consider the definitions of TRCSSCSRn and TRCCNTVRn:
    drivers/hwtracing/coresight/coresight-etm4x.h:56
     #define TRCCNTVRn(n)      (0x160 + (n * 4))
    drivers/hwtracing/coresight/coresight-etm4x.h:81
     #define TRCSSCSRn(n)      (0x2A0 + (n * 4))
    
    Where the macro parameter is expanded to i; a loop induction variable
    from etm4_disable_hw.
    
    When any compiler can determine that loops may be unrolled, then the
    __builtin_constant_p check in read_etm4x_sysreg_offset() defined in
    drivers/hwtracing/coresight/coresight-etm4x.h may evaluate to true. This
    can lead to the expression `(0x160 + (i * 4))` being passed to
    read_etm4x_sysreg_const_offset. Via the trace above, this is passed
    through READ_ETM4x_REG, read_sysreg_s, and finally to __mrs_s where it
    is string-ified and used directly in inline asm.
    
    Regardless of which compiler or compiler options determine whether a
    loop can or can't be unrolled, which determines whether
    __builtin_constant_p evaluates to true when passed an expression using a
    loop induction variable, it is NEVER safe to allow the preprocessor to
    construct inline asm like:
      asm volatile (".inst (0x160 + (i * 4))" : "=r"(__val));
                                     ^ expected constant expression
    
    Instead of read_etm4x_sysreg_offset() using __builtin_constant_p(), use
    __is_constexpr from include/linux/const.h instead to ensure only
    expressions that are valid integer constant expressions get passed
    through to read_sysreg_s().
    
    This is not a bug in clang; it's a potentially unsafe use of the macro
    arguments in read_etm4x_sysreg_offset dependent on __builtin_constant_p.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1310
    Reported-by: Arnd Bergmann <arnd@kernel.org>
    Reported-by: Tao Zhang <quic_taozha@quicinc.com>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20220708231520.3958391-1-ndesaulniers@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b06d5d97c0e067108a122986767731d40742138
Author: Jozef Martiniak <jomajm@gmail.com>
Date:   Fri Jul 8 09:06:44 2022 +0200

    gadgetfs: ep_io - wait until IRQ finishes
    
    [ Upstream commit 04cb742d4d8f30dc2e83b46ac317eec09191c68e ]
    
    after usb_ep_queue() if wait_for_completion_interruptible() is
    interrupted we need to wait until IRQ gets finished.
    
    Otherwise complete() from epio_complete() can corrupt stack.
    
    Signed-off-by: Jozef Martiniak <jomajm@gmail.com>
    Link: https://lore.kernel.org/r/20220708070645.6130-1-jomajm@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4eb7a1beff03836d3df271cd23b790884e3facb9
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jul 1 14:14:18 2022 -0700

    scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE
    
    [ Upstream commit 2f67dc7970bce3529edce93a0a14234d88b3fcd5 ]
    
    There is no corresponding free routine if lpfc_sli4_issue_wqe fails to
    issue the CMF WQE in lpfc_issue_cmf_sync_wqe.
    
    If ret_val is non-zero, then free the iocbq request structure.
    
    Link: https://lore.kernel.org/r/20220701211425.2708-6-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d544e9d19c109dfe34b3dc1253a8b2971abe060
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri Jul 1 14:14:15 2022 -0700

    scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user input
    
    [ Upstream commit f8191d40aa612981ce897e66cda6a88db8df17bb ]
    
    Malformed user input to debugfs results in buffer overflow crashes.  Adapt
    input string lengths to fit within internal buffers, leaving space for NULL
    terminators.
    
    Link: https://lore.kernel.org/r/20220701211425.2708-3-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92f8378250539d2aad0c8ede54827f2be0549231
Author: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Date:   Fri Jul 1 09:27:11 2022 +0300

    clk: qcom: clk-alpha-pll: fix clk_trion_pll_configure description
    
    [ Upstream commit 94bed9bb05c7850ff5d80b87cc29004901f37956 ]
    
    After merging lucid and trion pll functions in commit 0b01489475c6
    ("clk: qcom: clk-alpha-pll: same regs and ops for trion and lucid")
    the function clk_trion_pll_configure() is left with an old description
    header, which results in a W=2 compile time warning, fix it.
    
    Acked-by: Stephen Boyd <sboyd@kernel.org>
    Reviewed-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220701062711.2757855-1-vladimir.zapolskiy@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8b7e95345502fbb6c461bb1cec40b3c08556ff8
Author: Sergey Senozhatsky <senozhatsky@chromium.org>
Date:   Wed Jun 22 11:35:01 2022 +0900

    zram: do not lookup algorithm in backends table
    
    [ Upstream commit dc89997264de565999a1cb55db3f295d3a8e457b ]
    
    Always use crypto_has_comp() so that crypto can lookup module, call
    usermodhelper to load the modules, wait for usermodhelper to finish and so
    on.  Otherwise crypto will do all of these steps under CPU hot-plug lock
    and this looks like too much stuff to handle under the CPU hot-plug lock.
    Besides this can end up in a deadlock when usermodhelper triggers a code
    path that attempts to lock the CPU hot-plug lock, that zram already holds.
    
    An example of such deadlock:
    
    - path A. zram grabs CPU hot-plug lock, execs /sbin/modprobe from crypto
      and waits for modprobe to finish
    
    disksize_store
     zcomp_create
      __cpuhp_state_add_instance
       __cpuhp_state_add_instance_cpuslocked
        zcomp_cpu_up_prepare
         crypto_alloc_base
          crypto_alg_mod_lookup
           call_usermodehelper_exec
            wait_for_completion_killable
             do_wait_for_common
              schedule
    
    - path B. async work kthread that brings in scsi device. It wants to
      register CPUHP states at some point, and it needs the CPU hot-plug
      lock for that, which is owned by zram.
    
    async_run_entry_fn
     scsi_probe_and_add_lun
      scsi_mq_alloc_queue
       blk_mq_init_queue
        blk_mq_init_allocated_queue
         blk_mq_realloc_hw_ctxs
          __cpuhp_state_add_instance
           __cpuhp_state_add_instance_cpuslocked
            mutex_lock
             schedule
    
    - path C. modprobe sleeps, waiting for all aync works to finish.
    
    load_module
     do_init_module
      async_synchronize_full
       async_synchronize_cookie_domain
        schedule
    
    [senozhatsky@chromium.org: add comment]
      Link: https://lkml.kernel.org/r/20220624060606.1014474-1-senozhatsky@chromium.org
    Link: https://lkml.kernel.org/r/20220622023501.517125-1-senozhatsky@chromium.org
    Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Nitin Gupta <ngupta@vflare.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 842a89d91a945d43bf49ebc5c6d4562b6a6ddef8
Author: Jean-Philippe Brucker <jean-philippe@linaro.org>
Date:   Fri Jul 1 11:48:43 2022 +0800

    uacce: Handle parent device removal or parent driver module rmmod
    
    [ Upstream commit 80fc671bcc0173836e9032b0c698ea74c13b9d7c ]
    
    The uacce driver must deal with a possible removal of the parent device
    or parent driver module rmmod at any time.
    
    Although uacce_remove(), called on device removal and on driver unbind,
    prevents future use of the uacce fops by removing the cdev, fops that
    were called before that point may still be running.
    
    Serialize uacce_fops_open() and uacce_remove() with uacce->mutex.
    Serialize other fops against uacce_remove() with q->mutex.
    Since we need to protect uacce_fops_poll() which gets called on the fast
    path, replace uacce->queues_lock with q->mutex to improve scalability.
    The other fops are only used during setup.
    
    uacce_queue_is_valid(), checked under q->mutex or uacce->mutex, denotes
    whether uacce_remove() has disabled all queues. If that is the case,
    don't go any further since the parent device is being removed and
    uacce->ops should not be called anymore.
    
    Reported-by: Yang Shen <shenyang39@huawei.com>
    Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
    Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
    Link: https://lore.kernel.org/r/20220701034843.7502-1-zhangfei.gao@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 459411b9f0180e3f382d7abfa3028dd3285984c3
Author: Robert Marko <robimarko@gmail.com>
Date:   Sun May 15 23:00:47 2022 +0200

    clk: qcom: ipq8074: dont disable gcc_sleep_clk_src
    
    [ Upstream commit 1bf7305e79aab095196131bdc87a97796e0e3fac ]
    
    Once the usb sleep clocks are disabled, clock framework is trying to
    disable the sleep clock source also.
    
    However, it seems that it cannot be disabled and trying to do so produces:
    [  245.436390] ------------[ cut here ]------------
    [  245.441233] gcc_sleep_clk_src status stuck at 'on'
    [  245.441254] WARNING: CPU: 2 PID: 223 at clk_branch_wait+0x130/0x140
    [  245.450435] Modules linked in: xhci_plat_hcd xhci_hcd dwc3 dwc3_qcom leds_gpio
    [  245.456601] CPU: 2 PID: 223 Comm: sh Not tainted 5.18.0-rc4 #215
    [  245.463889] Hardware name: Xiaomi AX9000 (DT)
    [  245.470050] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [  245.474307] pc : clk_branch_wait+0x130/0x140
    [  245.481073] lr : clk_branch_wait+0x130/0x140
    [  245.485588] sp : ffffffc009f2bad0
    [  245.489838] x29: ffffffc009f2bad0 x28: ffffff8003e6c800 x27: 0000000000000000
    [  245.493057] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800226ef20
    [  245.500175] x23: ffffffc0089ff550 x22: 0000000000000000 x21: ffffffc008476ad0
    [  245.507294] x20: 0000000000000000 x19: ffffffc00965ac70 x18: fffffffffffc51a7
    [  245.514413] x17: 68702e3030303837 x16: 3a6d726f6674616c x15: ffffffc089f2b777
    [  245.521531] x14: ffffffc0095c9d18 x13: 0000000000000129 x12: 0000000000000129
    [  245.528649] x11: 00000000ffffffea x10: ffffffc009621d18 x9 : 0000000000000001
    [  245.535767] x8 : 0000000000000001 x7 : 0000000000017fe8 x6 : 0000000000000001
    [  245.542885] x5 : ffffff803fdca6d8 x4 : 0000000000000000 x3 : 0000000000000027
    [  245.550002] x2 : 0000000000000027 x1 : 0000000000000023 x0 : 0000000000000026
    [  245.557122] Call trace:
    [  245.564229]  clk_branch_wait+0x130/0x140
    [  245.566490]  clk_branch2_disable+0x2c/0x40
    [  245.570656]  clk_core_disable+0x60/0xb0
    [  245.574561]  clk_core_disable+0x68/0xb0
    [  245.578293]  clk_disable+0x30/0x50
    [  245.582113]  dwc3_qcom_remove+0x60/0xc0 [dwc3_qcom]
    [  245.585588]  platform_remove+0x28/0x60
    [  245.590361]  device_remove+0x4c/0x80
    [  245.594179]  device_release_driver_internal+0x1dc/0x230
    [  245.597914]  device_driver_detach+0x18/0x30
    [  245.602861]  unbind_store+0xec/0x110
    [  245.607027]  drv_attr_store+0x24/0x40
    [  245.610847]  sysfs_kf_write+0x44/0x60
    [  245.614405]  kernfs_fop_write_iter+0x128/0x1c0
    [  245.618052]  new_sync_write+0xc0/0x130
    [  245.622391]  vfs_write+0x1d4/0x2a0
    [  245.626123]  ksys_write+0x58/0xe0
    [  245.629508]  __arm64_sys_write+0x1c/0x30
    [  245.632895]  invoke_syscall.constprop.0+0x5c/0x110
    [  245.636890]  do_el0_svc+0xa0/0x150
    [  245.641488]  el0_svc+0x18/0x60
    [  245.644872]  el0t_64_sync_handler+0xa4/0x130
    [  245.647914]  el0t_64_sync+0x174/0x178
    [  245.652340] ---[ end trace 0000000000000000 ]---
    
    So, add CLK_IS_CRITICAL flag to the clock so that the kernel won't try
    to disable the sleep clock.
    
    Signed-off-by: Robert Marko <robimarko@gmail.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220515210048.483898-10-robimarko@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5cd88146e7907f577d70dd0c64fd8cd78b2a3f9
Author: Pascal Terjan <pterjan@google.com>
Date:   Sun Jun 12 14:37:44 2022 +0100

    vboxguest: Do not use devm for irq
    
    [ Upstream commit 6169525b76764acb81918aa387ac168fb9a55575 ]
    
    When relying on devm it doesn't get freed early enough which causes the
    following warning when unloading the module:
    
    [249348.837181] remove_proc_entry: removing non-empty directory 'irq/20', leaking at least 'vboxguest'
    [249348.837219] WARNING: CPU: 0 PID: 6708 at fs/proc/generic.c:715 remove_proc_entry+0x119/0x140
    
    [249348.837379] Call Trace:
    [249348.837385]  unregister_irq_proc+0xbd/0xe0
    [249348.837392]  free_desc+0x23/0x60
    [249348.837396]  irq_free_descs+0x4a/0x70
    [249348.837401]  irq_domain_free_irqs+0x160/0x1a0
    [249348.837452]  mp_unmap_irq+0x5c/0x60
    [249348.837458]  acpi_unregister_gsi_ioapic+0x29/0x40
    [249348.837463]  acpi_unregister_gsi+0x17/0x30
    [249348.837467]  acpi_pci_irq_disable+0xbf/0xe0
    [249348.837473]  pcibios_disable_device+0x20/0x30
    [249348.837478]  pci_disable_device+0xef/0x120
    [249348.837482]  vbg_pci_remove+0x6c/0x70 [vboxguest]
    
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Pascal Terjan <pterjan@google.com>
    Link: https://lore.kernel.org/r/20220612133744.4030602-1-pterjan@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f69ec6766aa1d8e5e06ad338b293aeb59cf97a8
Author: Amelie Delaunay <amelie.delaunay@foss.st.com>
Date:   Wed Jun 22 18:07:17 2022 +0200

    usb: dwc2: gadget: remove D+ pull-up while no vbus with usb-role-switch
    
    [ Upstream commit db638c6500abaffb8f7770b2a69c40d003d54ae1 ]
    
    When using usb-role-switch, D+ pull-up is set as soon as DTCL_SFTDISCON is
    cleared, whatever the vbus valid signal state is. The pull-up should not
    be set when vbus isn't present (this is determined by the drd controller).
    
    This patch ensures that B-Session (so Peripheral role + vbus valid signal)
    is valid before clearing the DCTL_SFTDISCON bit when role switch is used.
    Keep original behavior when usb-role-switch isn't used.
    
    Acked-by: Minas Harutyunyan <hminas@synopsys.com>
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Link: https://lore.kernel.org/r/20220622160717.314580-1-fabrice.gasnier@foss.st.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0483ffc02ebb953124c592485a5c48ac4ffae5fe
Author: Mike Christie <michael.christie@oracle.com>
Date:   Thu Jun 16 17:27:33 2022 -0500

    scsi: iscsi: Fix HW conn removal use after free
    
    [ Upstream commit c577ab7ba5f3bf9062db8a58b6e89d4fe370447e ]
    
    If qla4xxx doesn't remove the connection before the session, the iSCSI
    class tries to remove the connection for it. We were doing a
    iscsi_put_conn() in the iter function which is not needed and will result
    in a use after free because iscsi_remove_conn() will free the connection.
    
    Link: https://lore.kernel.org/r/20220616222738.5722-2-michael.christie@oracle.com
    Tested-by: Nilesh Javali <njavali@marvell.com>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Reviewed-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5c4b699193eba51f1bbf462d758d66f545fddd35
Author: Liang He <windhl@126.com>
Date:   Sat Jun 18 10:32:05 2022 +0800

    usb: renesas: Fix refcount leak bug
    
    [ Upstream commit 9d6d5303c39b8bc182475b22f45504106a07f086 ]
    
    In usbhs_rza1_hardware_init(), of_find_node_by_name() will return
    a node pointer with refcount incremented. We should use of_node_put()
    when it is not used anymore.
    
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20220618023205.4056548-1-windhl@126.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 403132881e66db7aa98b55c6655daedd80d407fd
Author: Liang He <windhl@126.com>
Date:   Fri Jun 17 11:46:37 2022 +0800

    usb: host: ohci-ppc-of: Fix refcount leak bug
    
    [ Upstream commit 40a959d7042bb7711e404ad2318b30e9f92c6b9b ]
    
    In ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return
    a node pointer with refcount incremented. We should use of_node_put()
    when it is not used anymore.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20220617034637.4003115-1-windhl@126.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4bd8b3b68a7b2856b588ab3eaf319b8707912032
Author: Prashant Malani <pmalani@chromium.org>
Date:   Wed Jun 15 17:20:18 2022 +0000

    usb: typec: mux: Add CONFIG guards for functions
    
    [ Upstream commit a37599ebfb656c2af4ca119de556eba29b6926d6 ]
    
    There are some drivers that can use the Type C mux API, but don't have
    to. Introduce CONFIG guards for the mux functions so that drivers can
    include the header file and not run into compilation errors on systems
    which don't have CONFIG_TYPEC enabled. When CONFIG_TYPEC is not enabled,
    the Type C mux functions will be stub versions of the original calls.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Signed-off-by: Prashant Malani <pmalani@chromium.org>
    Link: https://lore.kernel.org/r/20220615172129.1314056-3-pmalani@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6a1adbf1f2bf154f052bd721d7438ff3fc4c235
Author: Po-Wen Kao <powen.kao@mediatek.com>
Date:   Thu Jun 16 13:37:18 2022 +0800

    scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulators
    
    [ Upstream commit 3fd23b8dfb54d9b74eba6dfdd3225db3ac116785 ]
    
    Currently the LPM configurations of device regulators may not work since
    VCC is not disabled yet while ufs_mtk_vreg_set_lpm() is executed.
    
    Fix this by changing the timing of invoking ufs_mtk_vreg_set_lpm().
    
    Link: https://lore.kernel.org/r/20220616053725.5681-5-stanley.chu@mediatek.com
    Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
    Signed-off-by: Po-Wen Kao <powen.kao@mediatek.com>
    Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67c830a6de835a36b4e19fe4d968dbaf8dc4e9c6
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Jun 15 09:43:06 2022 +0300

    clk: ti: Stop using legacy clkctrl names for omap4 and 5
    
    [ Upstream commit 255584b138343d4a28c6d25bd82d04b09460d672 ]
    
    With the addition of clock-output-names, we can now unify the internal
    clock naming for omap4 and 5 to follow the other TI SoCs.
    
    We are still using legacy clkctrl names for omap4 and 5 based on the clock
    manager name which is wrong. Instead, we want to use the clkctrl clock
    based naming.
    
    We must now also drop the legacy TI_CLK_CLKCTRL_COMPAT quirk for the
    clkctrl clock.
    
    This change will allow further devicetree warning cleanup as already
    done for am3/4 and dra7.
    
    Cc: linux-clk@vger.kernel.org
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: Tero Kristo <kristo@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20220615064306.22254-1-tony@atomide.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 588e52fbc36d46b63e95cb4f369e184b1572670f
Author: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
Date:   Wed May 18 22:14:13 2022 +0530

    drm/meson: Fix overflow implicit truncation warnings
    
    [ Upstream commit 98692f52c588225034cbff458622c2c06dfcb544 ]
    
    Fix -Woverflow warnings for drm/meson driver which is a result
    of moving arm64 custom MMIO accessor macros to asm-generic function
    implementations giving a bonus type-checking now and uncovering these
    overflow warnings.
    
    drivers/gpu/drm/meson/meson_viu.c: In function ‘meson_viu_init’:
    drivers/gpu/drm/meson/meson_registers.h:1826:48: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
     #define  VIU_OSD_BLEND_REORDER(dest, src)      ((src) << (dest * 4))
                                                    ^
    drivers/gpu/drm/meson/meson_viu.c:472:18: note: in expansion of macro ‘VIU_OSD_BLEND_REORDER’
       writel_relaxed(VIU_OSD_BLEND_REORDER(0, 1) |
                      ^~~~~~~~~~~~~~~~~~~~~
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 74edc1e11ef34fe4aa52fd163533e53eedcf59bf
Author: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
Date:   Wed May 18 22:14:12 2022 +0530

    irqchip/tegra: Fix overflow implicit truncation warnings
    
    [ Upstream commit 443685992bda9bb4f8b17fc02c9f6c60e62b1461 ]
    
    Fix -Woverflow warnings for tegra irqchip driver which is a result
    of moving arm64 custom MMIO accessor macros to asm-generic function
    implementations giving a bonus type-checking now and uncovering these
    overflow warnings.
    
    drivers/irqchip/irq-tegra.c: In function ‘tegra_ictlr_suspend’:
    drivers/irqchip/irq-tegra.c:151:18: warning: large integer implicitly truncated to unsigned type [-Woverflow]
       writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
                      ^
    
    Suggested-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6ad16176b705d116d9bd5d6b9a889eb50e72439
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Fri Jun 3 20:05:20 2022 +0900

    scsi: ufs: core: Add UFSHCD_QUIRK_HIBERN_FASTAUTO
    
    [ Upstream commit 2f11bbc2c7f37e3a6151ac548b1c0679cc90ea83 ]
    
    Add UFSHCD_QUIRK_HIBERN_FASTAUTO quirk for host controllers which supports
    auto-hibernate the capability but only FASTAUTO mode.
    
    Link: https://lore.kernel.org/r/20220603110524.1997825-4-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99c6d37aeffa30702980976bb5a1eb6243c0826b
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Fri Jun 3 20:05:19 2022 +0900

    scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS
    
    [ Upstream commit 6554400d6f66b9494a0c0f07712ab0a9d307eb01 ]
    
    Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS for host controllers which do not
    support 64-bit addressing.
    
    Link: https://lore.kernel.org/r/20220603110524.1997825-3-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db0c485f4ac288194fa5e4c6c43436a107acc2b0
Author: Pali Rohár <pali@kernel.org>
Date:   Tue May 24 15:28:27 2022 +0200

    PCI: aardvark: Fix reporting Slot capabilities on emulated bridge
    
    [ Upstream commit bcdb6fd4f3e9ac1097698c8d8f56b70853b49873 ]
    
    Slot capabilities are currently not reported because emulated bridge does
    not report the PCI_EXP_FLAGS_SLOT flag.
    
    Set PCI_EXP_FLAGS_SLOT to let the kernel know that PCI_EXP_SLT* registers
    are supported.
    
    Move setting of PCI_EXP_SLTCTL register from "dynamic" pcie_conf_read
    function to static buffer as it is only statically filled the
    PCI_EXP_SLTSTA_PDS flag and dynamic read callback is not needed for this
    register.
    
    Set Presence State Bit to 1 since there is no support for unplugging the
    card and there is currently no platform able to detect presence of a card -
    in such a case the bit needs to be set to 1.
    
    Finally correctly set Physical Slot Number to 1 since there is only one
    port and zero value is reserved for ports within the same silicon as Root
    Port which is not our case for Aardvark HW.
    
    Link: https://lore.kernel.org/r/20220524132827.8837-3-kabel@kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ec370e0a50f2b0de9304ddaad1c1dacb4680810
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Mon May 30 00:38:48 2022 +0200

    usb: gadget: uvc: call uvc uvcg_warn on completed status instead of uvcg_info
    
    [ Upstream commit a725d0f6dfc5d3739d6499f30ec865305ba3544d ]
    
    Likewise to the uvcvideo hostside driver, this patch is changing the
    usb_request message of an non zero completion handler call from dev_info
    to dev_warn.
    
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Link: https://lore.kernel.org/r/20220529223848.105914-4-m.grzeschik@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2d17078980a3814ba7c502eb29e1839b9b63e45
Author: Michael Grzeschik <m.grzeschik@pengutronix.de>
Date:   Mon May 30 00:38:46 2022 +0200

    usb: gadget: uvc: calculate the number of request depending on framesize
    
    [ Upstream commit 87d76b5f1d8eeb49efa16e2018e188864cbb9401 ]
    
    The current limitation of possible number of requests being handled is
    dependent on the gadget speed. It makes more sense to depend on the
    typical frame size when calculating the number of requests. This patch
    is changing this and is using the previous limits as boundaries for
    reasonable minimum and maximum number of requests.
    
    For a 1080p jpeg encoded video stream with a maximum imagesize of
    e.g. 800kB with a maxburst of 8 and an multiplier of 1 the resulting
    number of requests is calculated to 49.
    
            800768         1
    nreqs = ------ * -------------- ~= 49
              2      (1024 * 8 * 1)
    
    Tested-by: Dan Vacura <w36195@motorola.com>
    Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
    Link: https://lore.kernel.org/r/20220529223848.105914-2-m.grzeschik@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6fd50446e7c9a98b4bcf96815f5c9602a16ea472
Author: Frank Li <Frank.Li@nxp.com>
Date:   Wed Jun 8 14:04:30 2022 -0500

    usb: cdns3 fix use-after-free at workaround 2
    
    [ Upstream commit 7d602f30149a117eea260208b1661bc404c21dfd ]
    
    BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xac
    
    cdns3_wa2_remove_old_request()
    {
            ...
            kfree(priv_req->request.buf);
            cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request);
            list_del_init(&priv_req->list);
            ^^^ use after free
            ...
    }
    
    cdns3_gadget_ep_free_request() free the space pointed by priv_req,
    but priv_req is used in the following list_del_init().
    
    This patch move list_del_init() before cdns3_gadget_ep_free_request().
    
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Faqiang Zhu <faqiang.zhu@nxp.com>
    Link: https://lore.kernel.org/r/20220608190430.2814358-1-Frank.Li@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2700f6072f22a9820f2cb4059fff703955905913
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Tue Jun 7 22:26:21 2022 +0300

    staging: r8188eu: add error handling of rtw_read32
    
    [ Upstream commit b9c5e272062708680d47df433bfbfe5299ad1a63 ]
    
    rtw_read32() reads data from device via USB API which may fail. In case
    of any failure previous code returned stack data to callers, which is
    wrong.
    
    Fix it by changing rtw_read32() prototype and prevent caller from
    touching random stack data
    
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Link: https://lore.kernel.org/r/583c3d21c46066275e4fc8da5ba4fd0e3679335b.1654629778.git.paskripkin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93883ec2d6aa31543f951fc9f2064f5f1f628a77
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Tue Jun 7 22:26:12 2022 +0300

    staging: r8188eu: add error handling of rtw_read16
    
    [ Upstream commit fed9e604eeb6150847d9757f6b056c12912d468b ]
    
    rtw_read16() reads data from device via USB API which may fail. In case
    of any failure previous code returned stack data to callers, which is
    wrong.
    
    Fix it by changing rtw_read16() prototype and prevent caller from
    touching random stack data
    
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Link: https://lore.kernel.org/r/06b45afda048d0aeddeed983c2318680fe6265f5.1654629778.git.paskripkin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eac7d9f47ad40fd7530ade2428686bd2f374a849
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Tue Jun 7 22:26:05 2022 +0300

    staging: r8188eu: add error handling of rtw_read8
    
    [ Upstream commit 857fe9e5efc09833fe1110e99d8baba954a86abb ]
    
    rtw_read8() reads data from device via USB API which may fail. In case
    of any failure previous code returned stack data to callers, which is
    wrong.
    
    Fix it by changing rtw_read8() prototype and prevent caller from
    touching random stack data
    
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Link: https://lore.kernel.org/r/c8f8ef4f14db3ba2478a87d5be6eb768a093dfaf.1654629778.git.paskripkin@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 582b3175deeaa052809c95a270629571d8641f66
Author: Tzung-Bi Shih <tzungbi@kernel.org>
Date:   Thu Jun 9 08:49:49 2022 +0000

    platform/chrome: cros_ec_proto: don't show MKBP version if unsupported
    
    [ Upstream commit b36f0643ff14a2fb281b105418e4e73c9d7c11d0 ]
    
    It wrongly showed the following message when it doesn't support MKBP:
    "MKBP support version 4294967295".
    
    Fix it.
    
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
    Link: https://lore.kernel.org/r/20220609084957.3684698-14-tzungbi@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ba397e2c31dae55247dcbf32514e701bd3b2f443
Author: Pavan Chebbi <pavan.chebbi@broadcom.com>
Date:   Thu Jun 9 13:41:47 2022 -0400

    PCI: Add ACS quirk for Broadcom BCM5750x NICs
    
    [ Upstream commit afd306a65cedb9589564bdb23a0c368abc4215fd ]
    
    The Broadcom BCM5750x NICs may be multi-function devices.  They do not
    advertise ACS capability. Peer-to-peer transactions are not possible
    between the individual functions, so it is safe to treat them as fully
    isolated.
    
    Add an ACS quirk for these devices so the functions can be in independent
    IOMMU groups and attached individually to userspace applications using
    VFIO.
    
    Link: https://lore.kernel.org/r/1654796507-28610-1-git-send-email-michael.chan@broadcom.com
    Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccb19dba9ded8d0059cd4e4bdcc9e8c3462bfba1
Author: Tao Jin <tao-j@outlook.com>
Date:   Thu May 19 23:51:32 2022 -0400

    HID: multitouch: new device class fix Lenovo X12 trackpad sticky
    
    [ Upstream commit 54eed5c7b938dc4ef6b14d4ee048bbdafdbce352 ]
    
    The trackpad of the given device sends continuous report of pointers
    status as per wxn8 spec. However, the spec did not clarify when the
    fingers are lifted so fast that between the interval of two report
    frames fingers on pad reduced from >=2 to 0. The second last report
    contains >=2 fingers with tip state 1 and the last report contains only
    1 finger with tip state 0. Although this can happen unfrequently, a
      quick fix will be improve the consistency to 100%. A quick fix is to
    disable MT_QUIRK_ALWAYS_VALID and enable MT_QUIRK_NOT_SEEN_MEANS_UP.
    
    Test for hid-tools is added in [1]
    
    In addition to this, I2C device 04CA:00B1 may also need similar class
    but with MT_QUIRK_FORCE_MULTI_INPUT disabled (but it does not harm to
     enable it on non-multi-input device either). The respective owner has
    been notified and a patch may coming soon after test.
    
    [1]: https://gitlab.freedesktop.org/libevdev/hid-tools/-/merge_requests/130
    
    Signed-off-by: Tao Jin <tao-j@outlook.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d419ac1f3336fd2ee89a6472ef73cdb9339c0d4
Author: Gil Fine <gil.fine@intel.com>
Date:   Thu May 26 13:59:19 2022 +0300

    thunderbolt: Change downstream router's TMU rate in both TMU uni/bidir mode
    
    [ Upstream commit 5fd6b9a5cbe63fea4c490fee8af34144a139a266 ]
    
    In case of uni-directional time sync, TMU handshake is
    initiated by upstream router. In case of bi-directional
    time sync, TMU handshake is initiated by downstream router.
    In order to handle correctly the case of uni-directional mode,
    we avoid changing the upstream router's rate to off,
    because it might have another downstream router plugged that is set to
    uni-directional mode (and we don't want to change its mode).
    Instead, we always change downstream router's rate.
    
    Signed-off-by: Gil Fine <gil.fine@intel.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5b5faedc4981c1dec88751962dc4f575f520639
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Thu Aug 18 08:53:43 2022 -0700

    x86/kvm: Fix "missing ENDBR" BUG for fastop functions
    
    [ Upstream commit 3d9606b0e0f3aed4dfb61d0853ebf432fead7bba ]
    
    The following BUG was reported:
    
      traps: Missing ENDBR: andw_ax_dx+0x0/0x10 [kvm]
      ------------[ cut here ]------------
      kernel BUG at arch/x86/kernel/traps.c:253!
      invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
       <TASK>
       asm_exc_control_protection+0x2b/0x30
      RIP: 0010:andw_ax_dx+0x0/0x10 [kvm]
      Code: c3 cc cc cc cc 0f 1f 44 00 00 66 0f 1f 00 48 19 d0 c3 cc cc cc
            cc 0f 1f 40 00 f3 0f 1e fa 20 d0 c3 cc cc cc cc 0f 1f 44 00 00
            <66> 0f 1f 00 66 21 d0 c3 cc cc cc cc 0f 1f 40 00 66 0f 1f 00 21
            d0
    
       ? andb_al_dl+0x10/0x10 [kvm]
       ? fastop+0x5d/0xa0 [kvm]
       x86_emulate_insn+0x822/0x1060 [kvm]
       x86_emulate_instruction+0x46f/0x750 [kvm]
       complete_emulated_mmio+0x216/0x2c0 [kvm]
       kvm_arch_vcpu_ioctl_run+0x604/0x650 [kvm]
       kvm_vcpu_ioctl+0x2f4/0x6b0 [kvm]
       ? wake_up_q+0xa0/0xa0
    
    The BUG occurred because the ENDBR in the andw_ax_dx() fastop function
    had been incorrectly "sealed" (converted to a NOP) by apply_ibt_endbr().
    
    Objtool marked it to be sealed because KVM has no compile-time
    references to the function.  Instead KVM calculates its address at
    runtime.
    
    Prevent objtool from annotating fastop functions as sealable by creating
    throwaway dummy compile-time references to the functions.
    
    Fixes: 6649fa876da4 ("x86/ibt,kvm: Add ENDBR to fastops")
    Reported-by: Pengfei Xu <pengfei.xu@intel.com>
    Debugged-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Message-Id: <0d4116f90e9d0c1b754bb90c585e6f0415a1c508.1660837839.git.jpoimboe@kernel.org>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe5a22a2925a9cd6f2afe1ea0991333eb5d4491d
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Thu Aug 18 14:39:27 2022 -0700

    x86/ibt, objtool: Add IBT_NOSEAL()
    
    [ Upstream commit e27e5bea956ce4d3eb15112de5fa5a3b77c2f488 ]
    
    Add a macro which prevents a function from getting sealed if there are
    no compile-time references to it.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Message-Id: <20220818213927.e44fmxkoq4yj6ybn@treble>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e124bab08a51d80badd94fef78a8284fbe49799c
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Aug 16 16:53:52 2022 +0300

    net: mscc: ocelot: report ndo_get_stats64 from the wraparound-resistant ocelot->stats
    
    [ Upstream commit e780e3193e889fd8358b862f7cd18ec5a4901caf ]
    
    Rather than reading the stats64 counters directly from the 32-bit
    hardware, it's better to rely on the output produced by the periodic
    ocelot_port_update_stats().
    
    It would be even better to call ocelot_port_update_stats() right from
    ocelot_get_stats64() to make sure we report the current values rather
    than the ones from 2 seconds ago. But we need to export
    ocelot_port_update_stats() from the switch lib towards the switchdev
    driver for that, and future work will largely undo that.
    
    There are more ocelot-based drivers waiting to be introduced, an example
    of which is the SPI-controlled VSC7512. In that driver's case, it will
    be impossible to call ocelot_port_update_stats() from ndo_get_stats64
    context, since the latter is atomic, and reading the stats over SPI is
    sleepable. So the compromise taken here, which will also hold going
    forward, is to report 64-bit counters to stats64, which are not 100% up
    to date.
    
    Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e07a74dc0fed1570a4fbf3240cfb06a93b8f904e
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Aug 16 16:53:50 2022 +0300

    net: mscc: ocelot: make struct ocelot_stat_layout array indexable
    
    [ Upstream commit 9190460084ddd0e9235f55eab0fdd5456b5f2fd5 ]
    
    The ocelot counters are 32-bit and require periodic reading, every 2
    seconds, by ocelot_port_update_stats(), so that wraparounds are
    detected.
    
    Currently, the counters reported by ocelot_get_stats64() come from the
    32-bit hardware counters directly, rather than from the 64-bit
    accumulated ocelot->stats, and this is a problem for their integrity.
    
    The strategy is to make ocelot_get_stats64() able to cherry-pick
    individual stats from ocelot->stats the way in which it currently reads
    them out from SYS_COUNT_* registers. But currently it can't, because
    ocelot->stats is an opaque u64 array that's used only to feed data into
    ethtool -S.
    
    To solve that problem, we need to make ocelot->stats indexable, and
    associate each element with an element of struct ocelot_stat_layout used
    by ethtool -S.
    
    This makes ocelot_stat_layout a fat (and possibly sparse) array, so we
    need to change the way in which we access it. We no longer need
    OCELOT_STAT_END as a sentinel, because we know the array's size
    (OCELOT_NUM_STATS). We just need to skip the array elements that were
    left unpopulated for the switch revision (ocelot, felix, seville).
    
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3aa635bf2f8f7495135d5cba72aae6fc279df33e
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Aug 16 16:53:49 2022 +0300

    net: mscc: ocelot: fix race between ndo_get_stats64 and ocelot_check_stats_work
    
    [ Upstream commit 18d8e67df184081bc6ce6220a2dd965cfd3d7e6b ]
    
    The 2 methods can run concurrently, and one will change the window of
    counters (SYS_STAT_CFG_STAT_VIEW) that the other sees. The fix is
    similar to what commit 7fbf6795d127 ("net: mscc: ocelot: fix mutex lock
    error during ethtool stats read") has done for ethtool -S.
    
    Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d05a558033e18e2b92f1b086bd405a5fd4494ff
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Aug 16 16:53:48 2022 +0300

    net: mscc: ocelot: turn stats_lock into a spinlock
    
    [ Upstream commit 22d842e3efe56402c33b5e6e303bb71ce9bf9334 ]
    
    ocelot_get_stats64() currently runs unlocked and therefore may collide
    with ocelot_port_update_stats() which indirectly accesses the same
    counters. However, ocelot_get_stats64() runs in atomic context, and we
    cannot simply take the sleepable ocelot->stats_lock mutex. We need to
    convert it to an atomic spinlock first. Do that as a preparatory change.
    
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62ef55aa4381c8adbd2b8364bfd1f76e02dfa4d0
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Tue Aug 16 19:25:54 2022 +0000

    KVM: arm64: Reject 32bit user PSTATE on asymmetric systems
    
    [ Upstream commit b10d86fb8e46cc812171728bcd326df2f34e9ed5 ]
    
    KVM does not support AArch32 EL0 on asymmetric systems. To that end,
    prevent userspace from configuring a vCPU in such a state through
    setting PSTATE.
    
    It is already ABI that KVM rejects such a write on a system where
    AArch32 EL0 is unsupported. Though the kernel's definition of a 32bit
    system changed in commit 2122a833316f ("arm64: Allow mismatched
    32-bit EL0 support"), KVM's did not.
    
    Fixes: 2122a833316f ("arm64: Allow mismatched 32-bit EL0 support")
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220816192554.1455559-3-oliver.upton@linux.dev
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4a36b051ca714a38ff45628b10de0b0558f2845
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Tue Aug 16 19:25:53 2022 +0000

    KVM: arm64: Treat PMCR_EL1.LC as RES1 on asymmetric systems
    
    [ Upstream commit f3c6efc72f3b20ec23566e768979802f0a398f04 ]
    
    KVM does not support AArch32 on asymmetric systems. To that end, enforce
    AArch64-only behavior on PMCR_EL1.LC when on an asymmetric system.
    
    Fixes: 2122a833316f ("arm64: Allow mismatched 32-bit EL0 support")
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20220816192554.1455559-2-oliver.upton@linux.dev
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b38e3b423f0bb41ee6abae5ca9deec1546ba227
Author: Maíra Canal <mairacanal@riseup.net>
Date:   Mon Aug 15 08:39:31 2022 -0300

    drm/amdgpu: Fix use-after-free on amdgpu_bo_list mutex
    
    [ Upstream commit bbca24d0a3c11193bafb9e174f89f52a379006e3 ]
    
    If amdgpu_cs_vm_handling returns r != 0, then it will unlock the
    bo_list_mutex inside the function amdgpu_cs_vm_handling and again on
    amdgpu_cs_parser_fini. This problem results in the following
    use-after-free problem:
    
    [ 220.280990] ------------[ cut here ]------------
    [ 220.281000] refcount_t: underflow; use-after-free.
    [ 220.281019] WARNING: CPU: 1 PID: 3746 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
    [ 220.281029] ------------[ cut here ]------------
    [ 220.281415] CPU: 1 PID: 3746 Comm: chrome:cs0 Tainted: G W L ------- --- 5.20.0-0.rc0.20220812git7ebfc85e2cd7.10.fc38.x86_64 #1
    [ 220.281421] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022
    [ 220.281426] RIP: 0010:refcount_warn_saturate+0xba/0x110
    [ 220.281431] Code: 01 01 e8 79 4a 6f 00 0f 0b e9 42 47 a5 00 80 3d de
    7e be 01 00 75 85 48 c7 c7 f8 98 8e 98 c6 05 ce 7e be 01 01 e8 56 4a
    6f 00 <0f> 0b e9 1f 47 a5 00 80 3d b9 7e be 01 00 0f 85 5e ff ff ff 48
    c7
    [ 220.281437] RSP: 0018:ffffb4b0d18d7a80 EFLAGS: 00010282
    [ 220.281443] RAX: 0000000000000026 RBX: 0000000000000003 RCX: 0000000000000000
    [ 220.281448] RDX: 0000000000000001 RSI: ffffffff988d06dc RDI: 00000000ffffffff
    [ 220.281452] RBP: 00000000ffffffff R08: 0000000000000000 R09: ffffb4b0d18d7930
    [ 220.281457] R10: 0000000000000003 R11: ffffa0672e2fffe8 R12: ffffa058ca360400
    [ 220.281461] R13: ffffa05846c50a18 R14: 00000000fffffe00 R15: 0000000000000003
    [ 220.281465] FS: 00007f82683e06c0(0000) GS:ffffa066e2e00000(0000) knlGS:0000000000000000
    [ 220.281470] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 220.281475] CR2: 00003590005cc000 CR3: 00000001fca46000 CR4: 0000000000350ee0
    [ 220.281480] Call Trace:
    [ 220.281485] <TASK>
    [ 220.281490] amdgpu_cs_ioctl+0x4e2/0x2070 [amdgpu]
    [ 220.281806] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
    [ 220.282028] drm_ioctl_kernel+0xa4/0x150
    [ 220.282043] drm_ioctl+0x21f/0x420
    [ 220.282053] ? amdgpu_cs_find_mapping+0xe0/0xe0 [amdgpu]
    [ 220.282275] ? lock_release+0x14f/0x460
    [ 220.282282] ? _raw_spin_unlock_irqrestore+0x30/0x60
    [ 220.282290] ? _raw_spin_unlock_irqrestore+0x30/0x60
    [ 220.282297] ? lockdep_hardirqs_on+0x7d/0x100
    [ 220.282305] ? _raw_spin_unlock_irqrestore+0x40/0x60
    [ 220.282317] amdgpu_drm_ioctl+0x4a/0x80 [amdgpu]
    [ 220.282534] __x64_sys_ioctl+0x90/0xd0
    [ 220.282545] do_syscall_64+0x5b/0x80
    [ 220.282551] ? futex_wake+0x6c/0x150
    [ 220.282568] ? lock_is_held_type+0xe8/0x140
    [ 220.282580] ? do_syscall_64+0x67/0x80
    [ 220.282585] ? lockdep_hardirqs_on+0x7d/0x100
    [ 220.282592] ? do_syscall_64+0x67/0x80
    [ 220.282597] ? do_syscall_64+0x67/0x80
    [ 220.282602] ? lockdep_hardirqs_on+0x7d/0x100
    [ 220.282609] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    [ 220.282616] RIP: 0033:0x7f8282a4f8bf
    [ 220.282639] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10
    00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00
    0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00
    00
    [ 220.282644] RSP: 002b:00007f82683df410 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    [ 220.282651] RAX: ffffffffffffffda RBX: 00007f82683df588 RCX: 00007f8282a4f8bf
    [ 220.282655] RDX: 00007f82683df4d0 RSI: 00000000c0186444 RDI: 0000000000000018
    [ 220.282659] RBP: 00007f82683df4d0 R08: 00007f82683df5e0 R09: 00007f82683df4b0
    [ 220.282663] R10: 00001d04000a0600 R11: 0000000000000246 R12: 00000000c0186444
    [ 220.282667] R13: 0000000000000018 R14: 00007f82683df588 R15: 0000000000000003
    [ 220.282689] </TASK>
    [ 220.282693] irq event stamp: 6232311
    [ 220.282697] hardirqs last enabled at (6232319): [<ffffffff9718cd7e>] __up_console_sem+0x5e/0x70
    [ 220.282704] hardirqs last disabled at (6232326): [<ffffffff9718cd63>] __up_console_sem+0x43/0x70
    [ 220.282709] softirqs last enabled at (6232072): [<ffffffff970ff669>] __irq_exit_rcu+0xf9/0x170
    [ 220.282716] softirqs last disabled at (6232061): [<ffffffff970ff669>] __irq_exit_rcu+0xf9/0x170
    [ 220.282722] ---[ end trace 0000000000000000 ]---
    
    Therefore, remove the mutex_unlock from the amdgpu_cs_vm_handling
    function, so that amdgpu_cs_submit and amdgpu_cs_parser_fini can handle
    the unlock.
    
    Fixes: 90af0ca047f3 ("drm/amdgpu: Protect the amdgpu_bo_list list with a mutex v2")
    Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Melissa Wen <mwen@igalia.com>
    Signed-off-by: Maíra Canal <mairacanal@riseup.net>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb837f5b83461624e525727a8f4add14b201147e
Author: Samuel Holland <samuel@sholland.org>
Date:   Thu Aug 11 22:16:23 2022 -0500

    drm/sun4i: dsi: Prevent underflow when computing packet sizes
    
    [ Upstream commit 82a1356a933d8443139f8886f11b63c974a09a67 ]
    
    Currently, the packet overhead is subtracted using unsigned arithmetic.
    With a short sync pulse, this could underflow and wrap around to near
    the maximal u16 value. Fix this by using signed subtraction. The call to
    max() will correctly handle any negative numbers that are produced.
    
    Apply the same fix to the other timings, even though those subtractions
    are less likely to underflow.
    
    Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20220812031623.34057-1-samuel@sholland.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e53531c1813a4bec25bd6ed3c18156886d9979e
Author: Marek Vasut <marex@denx.de>
Date:   Mon Aug 1 14:54:19 2022 +0200

    drm/bridge: lvds-codec: Fix error checking of drm_of_lvds_get_data_mapping()
    
    [ Upstream commit 2bba782002c5dab6ca8d608b778b386fb912adff ]
    
    The drm_of_lvds_get_data_mapping() returns either negative value on
    error or MEDIA_BUS_FMT_* otherwise. The check for 'ret' would also
    catch the positive case of MEDIA_BUS_FMT_* and lead to probe failure
    every time 'data-mapping' DT property is specified.
    
    Fixes: 7c4dd0a266527 ("drm: of: Add drm_of_lvds_get_data_mapping")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    To: dri-devel@lists.freedesktop.org
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220801125419.167562-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit efd4b62d109fc970dc567ea756d42e675e030174
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Wed Aug 3 16:54:24 2022 +0530

    drm/amdgpu: Avoid another list of reset devices
    
    [ Upstream commit 0a83bb35d8a6ff3d18c2772afe616780c23293a6 ]
    
    A list of devices to be reset is already created in
    amdgpu_device_gpu_recover function. Creating another list with the
    same nodes is incorrect and not supported in list_head. Instead, pass
    the device list as part of reset context.
    
    Fixes: 9e08564727fc (drm/amdgpu: Refactor mode2 reset logic for v13.0.2)
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b431cffb4883b9e90d48f0c408674c50fef428a5
Author: Matthew Auld <matthew.auld@intel.com>
Date:   Wed Jul 27 17:43:46 2022 +0100

    drm/i915/ttm: don't leak the ccs state
    
    [ Upstream commit 232d150fa15606e96c0e01e5c7a2d4e03f621787 ]
    
    The kernel only manages the ccs state with lmem-only objects, however
    the kernel should still take care not to leak the CCS state from the
    previous user.
    
    Fixes: 48760ffe923a ("drm/i915/gt: Clear compress metadata for Flat-ccs objects")
    Signed-off-by: Matthew Auld <matthew.auld@intel.com>
    Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Cc: Ramalingam C <ramalingam.c@intel.com>
    Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220727164346.282407-1-matthew.auld@intel.com
    (cherry picked from commit 353819d85f87be46aeb9c1dd929d445a006fc6ec)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8dec38e19f6928235d4009ce55f7add8af34e5c7
Author: Liang He <windhl@126.com>
Date:   Tue Jul 26 09:07:22 2022 +0800

    drm/meson: Fix refcount bugs in meson_vpu_has_available_connectors()
    
    [ Upstream commit 91b3c8dbe898df158fd2a84675f3a284ff6666f7 ]
    
    In this function, there are two refcount leak bugs:
    (1) when breaking out of for_each_endpoint_of_node(), we need call
    the of_node_put() for the 'ep';
    (2) we should call of_node_put() for the reference returned by
    of_graph_get_remote_port() when it is not used anymore.
    
    Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
    Signed-off-by: Liang He <windhl@126.com>
    Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Acked-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220726010722.1319416-1-windhl@126.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 02a22d62051a1507cfc56785c6d917268f8cc48b
Author: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Date:   Thu Jul 21 15:09:12 2022 +0300

    drm/imx/dcss: get rid of HPD warning message
    
    [ Upstream commit 30bdc36b8c776cd4fce5de2a96ff28b37f96942f ]
    
    When DCSS + MIPI_DSI is used, and the last bridge in the chain supports
    HPD, we can see a "Hot plug detection already enabled" warning stack
    trace dump that's thrown when DCSS is initialized.
    
    The problem appeared when HPD was enabled by default in the
    bridge_connector initialization, which made the
    drm_bridge_connector_enable_hpd() call, in DCSS init path, redundant.
    So, let's remove that call.
    
    Fixes: 09077bc311658 ("drm/bridge_connector: enable HPD by default if supported")
    Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220721120912.6639-1-laurentiu.palcu@oss.nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5494b6ed31bcaeeb33881d1a3d65378a657838f
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Fri Jul 29 17:36:55 2022 +0300

    can: j1939: j1939_sk_queue_activate_next_locked(): replace WARN_ON_ONCE with netdev_warn_once()
    
    commit 8ef49f7f8244424adcf4a546dba4cbbeb0b09c09 upstream.
    
    We should warn user-space that it is doing something wrong when trying
    to activate sessions with identical parameters but WARN_ON_ONCE macro
    can not be used here as it serves a different purpose.
    
    So it would be good to replace it with netdev_warn_once() message.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/all/20220729143655.1108297-1-pchelkin@ispras.ru
    [mkl: fix indention]
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ba9bafa2ce0bfd626e35763a44631e3e528e92f
Author: Andrew Donnellan <ajd@linux.ibm.com>
Date:   Tue Aug 16 15:17:20 2022 +1000

    gcc-plugins: Undefine LATENT_ENTROPY_PLUGIN when plugin disabled for a file
    
    commit 012e8d2034f1bda8863435cd589636e618d6a659 upstream.
    
    Commit 36d4b36b6959 ("lib/nodemask: inline next_node_in() and
    node_random()") refactored some code by moving node_random() from
    lib/nodemask.c to include/linux/nodemask.h, thus requiring nodemask.h to
    include random.h, which conditionally defines add_latent_entropy()
    depending on whether the macro LATENT_ENTROPY_PLUGIN is defined.
    
    This broke the build on powerpc, where nodemask.h is indirectly included
    in arch/powerpc/kernel/prom_init.c, part of the early boot machinery that
    is excluded from the latent entropy plugin using
    DISABLE_LATENT_ENTROPY_PLUGIN. It turns out that while we add a gcc flag
    to disable the actual plugin, we don't undefine LATENT_ENTROPY_PLUGIN.
    
    This leads to the following:
    
        CC      arch/powerpc/kernel/prom_init.o
      In file included from ./include/linux/nodemask.h:97,
                       from ./include/linux/mmzone.h:17,
                       from ./include/linux/gfp.h:7,
                       from ./include/linux/xarray.h:15,
                       from ./include/linux/radix-tree.h:21,
                       from ./include/linux/idr.h:15,
                       from ./include/linux/kernfs.h:12,
                       from ./include/linux/sysfs.h:16,
                       from ./include/linux/kobject.h:20,
                       from ./include/linux/pci.h:35,
                       from arch/powerpc/kernel/prom_init.c:24:
      ./include/linux/random.h: In function 'add_latent_entropy':
      ./include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'?
         25 |         add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy));
            |                                              ^~~~~~~~~~~~~~
            |                                              add_latent_entropy
      ./include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in
      make[2]: *** [scripts/Makefile.build:249: arch/powerpc/kernel/prom_init.o] Fehler 1
      make[1]: *** [scripts/Makefile.build:465: arch/powerpc/kernel] Fehler 2
      make: *** [Makefile:1855: arch/powerpc] Error 2
    
    Change the DISABLE_LATENT_ENTROPY_PLUGIN flags to undefine
    LATENT_ENTROPY_PLUGIN for files where the plugin is disabled.
    
    Cc: Yury Norov <yury.norov@gmail.com>
    Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216367
    Link: https://lore.kernel.org/linuxppc-dev/alpine.DEB.2.22.394.2208152006320.289321@ramsan.of.borg/
    Reported-by: Erhard Furtner <erhard_f@mailbox.org>
    Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
    Reviewed-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20220816051720.44108-1-ajd@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c61b45ecee996a3c2ba48eb67f825e34037d45e
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun Aug 14 08:09:28 2022 +0900

    kbuild: fix the modules order between drivers and libs
    
    commit 113147510b48e764e624e3d0e6707a1e48bc05a9 upstream.
    
    Commit b2c885549122 ("kbuild: update modules.order only when contained
    modules are updated") accidentally changed the modules order.
    
    Prior to that commit, the modules order was determined based on
    vmlinux-dirs, which lists core-y/m, drivers-y/m, libs-y/m, in this order.
    
    Now, subdir-modorder lists them in a different order: core-y/m, libs-y/m,
    drivers-y/m.
    
    Presumably, there was no practical issue because the modules in drivers
    and libs are orthogonal, but there is no reason to have this distortion.
    
    Get back to the original order.
    
    Fixes: b2c885549122 ("kbuild: update modules.order only when contained modules are updated")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64c0c233a88591bb23569ae12eed7f74e5bd39ce
Author: Lin Ma <linma@zju.edu.cn>
Date:   Wed Aug 17 11:49:21 2022 -0700

    igb: Add lock to avoid data race
    
    commit 6faee3d4ee8be0f0367d0c3d826afb3571b7a5e0 upstream.
    
    The commit c23d92b80e0b ("igb: Teardown SR-IOV before
    unregister_netdev()") places the unregister_netdev() call after the
    igb_disable_sriov() call to avoid functionality issue.
    
    However, it introduces several race conditions when detaching a device.
    For example, when .remove() is called, the below interleaving leads to
    use-after-free.
    
     (FREE from device detaching)      |   (USE from netdev core)
    igb_remove                         |  igb_ndo_get_vf_config
     igb_disable_sriov                 |  vf >= adapter->vfs_allocated_count?
      kfree(adapter->vf_data)          |
      adapter->vfs_allocated_count = 0 |
                                       |    memcpy(... adapter->vf_data[vf]
    
    Moreover, the igb_disable_sriov() also suffers from data race with the
    requests from VF driver.
    
     (FREE from device detaching)      |   (USE from requests)
    igb_remove                         |  igb_msix_other
     igb_disable_sriov                 |   igb_msg_task
      kfree(adapter->vf_data)          |    vf < adapter->vfs_allocated_count
      adapter->vfs_allocated_count = 0 |
    
    To this end, this commit first eliminates the data races from netdev
    core by using rtnl_lock (similar to commit 719479230893 ("dpaa2-eth: add
    MAC/PHY support through phylink")). And then adds a spinlock to
    eliminate races from driver requests. (similar to commit 1e53834ce541
    ("ixgbe: Add locking to prevent panic when setting sriov_numvfs to zero")
    
    Fixes: c23d92b80e0b ("igb: Teardown SR-IOV before unregister_netdev()")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Link: https://lore.kernel.org/r/20220817184921.735244-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9400aeb419d35e718e90aa14a97c11229d0a40bc
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Aug 16 16:23:57 2022 +0200

    stmmac: intel: Add a missing clk_disable_unprepare() call in intel_eth_pci_remove()
    
    commit 5c23d6b717e4e956376f3852b90f58e262946b50 upstream.
    
    Commit 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove
    paths") removed this clk_disable_unprepare()
    
    This was partly revert by commit ac322f86b56c ("net: stmmac: Fix clock
    handling on remove path") which removed this clk_disable_unprepare()
    because:
    "
       While unloading the dwmac-intel driver, clk_disable_unprepare() is
       being called twice in stmmac_dvr_remove() and
       intel_eth_pci_remove(). This causes kernel panic on the second call.
    "
    
    However later on, commit 5ec55823438e8 ("net: stmmac: add clocks management
    for gmac driver") has updated stmmac_dvr_remove() which do not call
    clk_disable_unprepare() anymore.
    
    So this call should now be called from intel_eth_pci_remove().
    
    Fixes: 5ec55823438e8 ("net: stmmac: add clocks management for gmac driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/d7c8c1dadf40df3a7c9e643f76ffadd0ccc1ad1b.1660659689.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 994c8f12be24a8075935d322b0d8ea677def735d
Author: Samuel Holland <samuel@sholland.org>
Date:   Fri Aug 12 02:37:02 2022 -0500

    dt-bindings: display: sun4i: Add D1 TCONs to conditionals
    
    commit 2a29f80e155a9cf40ca8b6648bcdc8422db4c4e4 upstream.
    
    When adding the D1 TCON bindings, I missed the conditional blocks that
    restrict the binding for TCON LCD vs TCON TV hardware. Add the D1 TCON
    variants to the appropriate blocks for DE2 TCON LCDs and TCON TVs.
    
    Fixes: ae5a5d26c15c ("dt-bindings: display: Add D1 display engine compatibles")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20220812073702.57618-1-samuel@sholland.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 330eccd73fc0adae76f3cd59b9e2692e36061802
Author: Csókás Bence <csokas.bence@prolan.hu>
Date:   Thu Aug 11 12:13:49 2022 +0200

    fec: Fix timer capture timing in `fec_ptp_enable_pps()`
    
    commit 61d5e2a251fb20c2c5e998c3f1d52ed6d5360319 upstream.
    
    Code reimplements functionality already in `fec_ptp_read()`,
    but misses check for FEC_QUIRK_BUG_CAPTURE. Replace with function call.
    
    Fixes: 28b5f058cf1d ("net: fec: ptp: fix convergence issue to support LinuxPTP stack")
    Signed-off-by: Csókás Bence <csokas.bence@prolan.hu>
    Link: https://lore.kernel.org/r/20220811101348.13755-1-csokas.bence@prolan.hu
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b72e5b0457465bb66ac91980f3ddb45acff13ec1
Author: Ben Hutchings <benh@debian.org>
Date:   Sat Jul 16 15:47:08 2022 +0200

    tools/rtla: Fix command symlinks
    
    commit ff5a55dcdb343e3db9b9fb08795b78544b032773 upstream.
    
    "ln -s" stores the next argument directly as the symlink target, so
    it needs to be a relative path.  In this case, just "rtla".
    
    Link: https://lore.kernel.org/linux-trace-devel/YtLBXMI6Ui4HLIF1@decadent.org.uk
    
    Fixes: 0605bf009f18 ("rtla: Add osnoise tool")
    Fixes: a828cd18bc4a ("rtla: Add timerlat tool and timelart top mode")
    Signed-off-by: Ben Hutchings <benh@debian.org>
    Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d4dc30b4c96f047264fa60a34944a595ed1a62a
Author: Yufen Yu <yuyufen@huawei.com>
Date:   Wed Aug 3 10:33:55 2022 +0800

    blk-mq: run queue no matter whether the request is the last request
    
    commit d3b38596875dbc709b4e721a5873f4663d8a9ea2 upstream.
    
    We do test on a virtio scsi device (/dev/sda) and the default mq
    scheduler is 'none'. We found a IO hung as following:
    
    blk_finish_plug
      blk_mq_plug_issue_direct
          scsi_mq_get_budget
          //get budget_token fail and sdev->restarts=1
    
                                     scsi_end_request
                                       scsi_run_queue_async
                                       //sdev->restart=0 and run queue
    
         blk_mq_request_bypass_insert
            //add request to hctx->dispatch list
    
      //continue to dispath plug list
      blk_mq_dispatch_plug_list
          blk_mq_try_issue_list_directly
            //success issue all requests from plug list
    
    After .get_budget fail, scsi_mq_get_budget will increase 'restarts'.
    Normally, it will run hw queue when io complete and set 'restarts'
    as 0. But if we run queue before adding request to the dispatch list
    and blk_mq_dispatch_plug_list also success issue all requests, then
    on one will run queue, and the request will be stall in the dispatch
    list and cannot complete forever.
    
    It is wrong to use last request of plug list to decide if run queue is
    needed since all the remained requests in plug list may be from other
    hctxs. To fix the bug, pass run_queue as true always to
    blk_mq_request_bypass_insert().
    
    Fix-suggested-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Yufen Yu <yuyufen@huawei.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Fixes: dc5fc361d891 ("block: attempt direct issue of plug list")
    Link: https://lore.kernel.org/r/20220803023355.3687360-1-yuyufen@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c9ebb648cdecd24774e019d083dc5892476163a
Author: Alan Brady <alan.brady@intel.com>
Date:   Tue Aug 2 10:19:17 2022 +0200

    i40e: Fix to stop tx_timeout recovery if GLOBR fails
    
    commit 57c942bc3bef0970f0b21f8e0998e76a900ea80d upstream.
    
    When a tx_timeout fires, the PF attempts to recover by incrementally
    resetting.  First we try a PFR, then CORER and finally a GLOBR.  If the
    GLOBR fails, then we keep hitting the tx_timeout and incrementing the
    recovery level and issuing dmesgs, which is both annoying to the user
    and accomplishes nothing.
    
    If the GLOBR fails, then we're pretty much totally hosed, and there's
    not much else we can do to recover, so this makes it such that we just
    kill the VSI and stop hitting the tx_timeout in such a case.
    
    Fixes: 41c445ff0f48 ("i40e: main driver core")
    Signed-off-by: Alan Brady <alan.brady@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56ba4d6853ec5230a37889c8d8cb3a70cb4f982f
Author: Frieder Schrempf <frieder.schrempf@kontron.de>
Date:   Tue Aug 2 08:43:34 2022 +0200

    regulator: pca9450: Remove restrictions for regulator-name
    
    commit b0de7fa706506bf0591037908376351beda8c5d6 upstream.
    
    The device bindings shouldn't put any constraints on the regulator-name
    property specified in the generic bindings. This allows using arbitrary
    and descriptive names for the regulators.
    
    Suggested-by: Mark Brown <broonie@kernel.org>
    Fixes: 7ae9e3a6bf3f ("dt-bindings: regulator: add pca9450 regulator yaml")
    Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
    Link: https://lore.kernel.org/r/20220802064335.8481-1-frieder@fris.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15ccc6fa8153ff1ea9b44de0c7433fd82b0e5595
Author: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
Date:   Wed Jul 27 11:19:40 2022 +0200

    i40e: Fix tunnel checksum offload with fragmented traffic
    
    commit 2c6482091f01ba104cf8ee549aa5c717e80d43ea upstream.
    
    Fix checksum offload on VXLAN tunnels.
    In case, when mpls protocol is not used, set l4 header to transport
    header of skb. This fixes case, when user tries to offload checksums
    of VXLAN tunneled traffic.
    
    Steps for reproduction (requires link partner with tunnels):
    ip l s enp130s0f0 up
    ip a f enp130s0f0
    ip a a 10.10.110.2/24 dev enp130s0f0
    ip l s enp130s0f0 mtu 1600
    ip link add vxlan12_sut type vxlan id 12 group 238.168.100.100 dev \
    enp130s0f0 dstport 4789
    ip l s vxlan12_sut up
    ip a a 20.10.110.2/24 dev vxlan12_sut
    iperf3 -c 20.10.110.1 #should connect
    
    Without this patch, TX descriptor was using wrong data, due to
    l4 header pointing wrong address. NIC would then drop those packets
    internally, due to incorrect TX descriptor data, which increased
    GLV_TEPC register.
    
    Fixes: b4fb2d33514a ("i40e: Add support for MPLS + TSO")
    Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Tested-by: Marek Szlosek <marek.szlosek@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bce25a155b297c393b8cad24821d9cecffd04b4
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Jul 20 17:09:33 2022 +0200

    i2c: imx: Make sure to unregister adapter on remove()
    
    commit d98bdd3a5b50446d8e010be5b04ce81c4eabf728 upstream.
    
    If for whatever reasons pm_runtime_resume_and_get() fails and .remove() is
    exited early, the i2c adapter stays around and the irq still calls its
    handler, while the driver data and the register mapping go away. So if
    later the i2c adapter is accessed or the irq triggers this results in
    havoc accessing freed memory and unmapped registers.
    
    So unregister the software resources even if resume failed, and only skip
    the hardware access in that case.
    
    Fixes: 588eb93ea49f ("i2c: imx: add runtime pm support to improve the performance")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5fc790e349ade000f114c1c26fd6fa9915af4b9e
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Aug 9 23:11:17 2022 +0900

    modpost: fix module versioning when a symbol lacks valid CRC
    
    commit 5b8a9a8fd1f0c3d55d407cf759d54ca68798d9ad upstream.
    
    Since commit 7b4537199a4a ("kbuild: link symbol CRCs at final link,
    removing CONFIG_MODULE_REL_CRCS"), module versioning is broken on
    some architectures. Loading a module fails with "disagrees about
    version of symbol module_layout".
    
    On such architectures (e.g. ARCH=sparc build with sparc64_defconfig),
    modpost shows a warning, like follows:
    
      WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.
      Is "_mcount" prototyped in <asm/asm-prototypes.h>?
    
    Previously, it was a harmless warning (CRC check was just skipped),
    but now wrong CRCs are used for comparison because invalid CRCs are
    just skipped.
    
      $ sparc64-linux-gnu-nm -n vmlinux
        [snip]
      0000000000c2cea0 r __ksymtab__kstrtol
      0000000000c2ceb8 r __ksymtab__kstrtoul
      0000000000c2ced0 r __ksymtab__local_bh_enable
      0000000000c2cee8 r __ksymtab__mcount
      0000000000c2cf00 r __ksymtab__printk
      0000000000c2cf18 r __ksymtab__raw_read_lock
      0000000000c2cf30 r __ksymtab__raw_read_lock_bh
        [snip]
      0000000000c53b34 D __crc__kstrtol
      0000000000c53b38 D __crc__kstrtoul
      0000000000c53b3c D __crc__local_bh_enable
      0000000000c53b40 D __crc__printk
      0000000000c53b44 D __crc__raw_read_lock
      0000000000c53b48 D __crc__raw_read_lock_bh
    
    Please notice __crc__mcount is missing here.
    
    When the module subsystem looks up a CRC that comes after, it results
    in reading out a wrong address. For example, when __crc__printk is
    needed, the module subsystem reads 0xc53b44 instead of 0xc53b40.
    
    All CRC entries must be output for correct index accessing. Invalid
    CRCs will be unused, but are needed to keep the one-to-one mapping
    between __ksymtab_* and __crc_*.
    
    The best is to fix all modpost warnings, but several warnings are still
    remaining on less popular architectures.
    
    Fixes: 7b4537199a4a ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS")
    Reported-by: matoro <matoro_mailinglist_kernel@matoro.tk>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Tested-by: matoro <matoro_mailinglist_kernel@matoro.tk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e933ded5079a3b366593492689bcf28c1fdcf1d
Author: Benjamin Mikailenko <benjamin.mikailenko@intel.com>
Date:   Fri Aug 12 15:25:50 2022 +0200

    ice: Ignore error message when setting same promiscuous mode
    
    commit 79956b83ed4281c35561c39254558092d96a9ed1 upstream.
    
    Commit 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling")
    introduced new checks when setting/clearing promiscuous mode. But if the
    requested promiscuous mode setting already exists, an -EEXIST error
    message would be printed. This is incorrect because promiscuous mode is
    either on/off and shouldn't print an error when the requested
    configuration is already set.
    
    This can happen when removing a bridge with two bonded interfaces and
    promiscuous most isn't fully cleared from VLAN VSI in hardware.
    
    Fix this by ignoring cases where requested promiscuous mode exists.
    
    Fixes: 1273f89578f2 ("ice: Fix broken IFF_ALLMULTI handling")
    Signed-off-by: Benjamin Mikailenko <benjamin.mikailenko@intel.com>
    Signed-off-by: Grzegorz Siwik <grzegorz.siwik@intel.com>
    Link: https://lore.kernel.org/all/CAK8fFZ7m-KR57M_rYX6xZN39K89O=LGooYkKsu6HKt0Bs+x6xQ@mail.gmail.com/
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc6770eb90ff5021cf42ef931e40194d60eeb5f4
Author: Grzegorz Siwik <grzegorz.siwik@intel.com>
Date:   Fri Aug 12 15:25:49 2022 +0200

    ice: Fix clearing of promisc mode with bridge over bond
    
    commit abddafd4585cc825d454da3cf308ad1226f6c554 upstream.
    
    When at least two interfaces are bonded and a bridge is enabled on the
    bond, an error can occur when the bridge is removed and re-added. The
    reason for the error is because promiscuous mode was not fully cleared from
    the VLAN VSI in the hardware. With this change, promiscuous mode is
    properly removed when the bridge disconnects from bonding.
    
    [ 1033.676359] bond1: link status definitely down for interface enp95s0f0, disabling it
    [ 1033.676366] bond1: making interface enp175s0f0 the new active one
    [ 1033.676369] device enp95s0f0 left promiscuous mode
    [ 1033.676522] device enp175s0f0 entered promiscuous mode
    [ 1033.676901] ice 0000:af:00.0 enp175s0f0: Error setting Multicast promiscuous mode on VSI 6
    [ 1041.795662] ice 0000:af:00.0 enp175s0f0: Error setting Multicast promiscuous mode on VSI 6
    [ 1041.944826] bond1: link status definitely down for interface enp175s0f0, disabling it
    [ 1041.944874] device enp175s0f0 left promiscuous mode
    [ 1041.944918] bond1: now running without any active interface!
    
    Fixes: c31af68a1b94 ("ice: Add outer_vlan_ops and VSI specific VLAN ops implementations")
    Co-developed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: Grzegorz Siwik <grzegorz.siwik@intel.com>
    Link: https://lore.kernel.org/all/CAK8fFZ7m-KR57M_rYX6xZN39K89O=LGooYkKsu6HKt0Bs+x6xQ@mail.gmail.com/
    Tested-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com>
    Tested-by: Igor Raits <igor@gooddata.com>
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26fce11f927c805e80c28c7474d183f1f07b7284
Author: Grzegorz Siwik <grzegorz.siwik@intel.com>
Date:   Fri Aug 12 15:25:48 2022 +0200

    ice: Ignore EEXIST when setting promisc mode
    
    commit 11e551a2efa4481bd4f616ab75374a2710b480e9 upstream.
    
    Ignore EEXIST error when setting promiscuous mode.
    This fix is needed because the driver could set promiscuous mode
    when it still has not cleared properly.
    Promiscuous mode could be set only once, so setting it second
    time will be rejected.
    
    Fixes: 5eda8afd6bcc ("ice: Add support for PF/VF promiscuous mode")
    Signed-off-by: Grzegorz Siwik <grzegorz.siwik@intel.com>
    Link: https://lore.kernel.org/all/CAK8fFZ7m-KR57M_rYX6xZN39K89O=LGooYkKsu6HKt0Bs+x6xQ@mail.gmail.com/
    Tested-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com>
    Tested-by: Igor Raits <igor@gooddata.com>
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6db6964e33a3b8c9b92781eb59dbb2eb590f5da3
Author: Grzegorz Siwik <grzegorz.siwik@intel.com>
Date:   Fri Aug 12 15:25:47 2022 +0200

    ice: Fix double VLAN error when entering promisc mode
    
    commit ffa9ed86522f1c08d4face4e0a4ebf366037bf19 upstream.
    
    Avoid enabling or disabling VLAN 0 when trying to set promiscuous
    VLAN mode if double VLAN mode is enabled. This fix is needed
    because the driver tries to add the VLAN 0 filter twice (once for
    inner and once for outer) when double VLAN mode is enabled. The
    filter program is rejected by the firmware when double VLAN is
    enabled, because the promiscuous filter only needs to be set once.
    
    This issue was missed in the initial implementation of double VLAN
    mode.
    
    Fixes: 5eda8afd6bcc ("ice: Add support for PF/VF promiscuous mode")
    Signed-off-by: Grzegorz Siwik <grzegorz.siwik@intel.com>
    Link: https://lore.kernel.org/all/CAK8fFZ7m-KR57M_rYX6xZN39K89O=LGooYkKsu6HKt0Bs+x6xQ@mail.gmail.com/
    Tested-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com>
    Tested-by: Igor Raits <igor@gooddata.com>
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d46c877935e4b6651cc4a8154d20d0aabaa98c28
Author: Sylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
Date:   Wed Aug 3 10:42:46 2022 +0200

    ice: Fix VF not able to send tagged traffic with no VLAN filters
    
    commit 664d4646184ed986f8195df684cc4660563fb02a upstream.
    
    VF was not able to send tagged traffic when it didn't
    have any VLAN interfaces and VLAN anti-spoofing was enabled.
    Fix this by allowing VFs with no VLAN filters to send tagged
    traffic. After VF adds a VLAN interface it will be able to
    send tagged traffic matching VLAN filters only.
    
    Testing hints:
    1. Spawn VF
    2. Send tagged packet from a VF
    3. The packet should be sent out and not dropped
    4. Add a VLAN interface on VF
    5. Send tagged packet on that VLAN interface
    6. Packet should be sent out and not dropped
    7. Send tagged packet with id different than VLAN interface
    8. Packet should be dropped
    
    Fixes: daf4dd16438b ("ice: Refactor spoofcheck configuration functions")
    Signed-off-by: Sylwester Dziedziuch <sylwesterx.dziedziuch@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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af1b0d1547dd1686ae842cac7f3678649a5cbd89
Author: Michal Jaron <michalx.jaron@intel.com>
Date:   Mon Jul 25 10:32:43 2022 +0200

    ice: Fix call trace with null VSI during VF reset
    
    commit cf90b74341eecc32ceef0c136954a1668e43b1e7 upstream.
    
    During stress test with attaching and detaching VF from KVM and
    simultaneously changing VFs spoofcheck and trust there was a
    call trace in ice_reset_vf that VF's VSI is null.
    
    [145237.352797] WARNING: CPU: 46 PID: 840629 at drivers/net/ethernet/intel/ice/ice_vf_lib.c:508 ice_reset_vf+0x3d6/0x410 [ice]
    [145237.352851] Modules linked in: ice(E) vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio iavf dm_mod xt_CHECKSUM xt_MASQUERADE
    xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun
     bridge stp llc sunrpc intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm iTCO_wdt iTC
    O_vendor_support irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl ipmi_si intel_cstate ipmi_devintf joydev intel_uncore m
    ei_me ipmi_msghandler i2c_i801 pcspkr mei lpc_ich ioatdma i2c_smbus acpi_pad acpi_power_meter ip_tables xfs libcrc32c i2c_algo_bit drm_sh
    mem_helper drm_kms_helper sd_mod t10_pi crc64_rocksoft syscopyarea crc64 sysfillrect sg sysimgblt fb_sys_fops drm i40e ixgbe ahci libahci
     libata crc32c_intel mdio dca wmi fuse [last unloaded: ice]
    [145237.352917] CPU: 46 PID: 840629 Comm: kworker/46:2 Tainted: G S      W I E     5.19.0-rc6+ #24
    [145237.352921] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
    [145237.352923] Workqueue: ice ice_service_task [ice]
    [145237.352948] RIP: 0010:ice_reset_vf+0x3d6/0x410 [ice]
    [145237.352984] Code: 30 ec f3 cc e9 28 fd ff ff 0f b7 4b 50 48 c7 c2 48 19 9c c0 4c 89 ee 48 c7 c7 30 fe 9e c0 e8 d1 21 9d cc 31 c0 e9 a
    9 fe ff ff <0f> 0b b8 ea ff ff ff e9 c1 fc ff ff 0f 0b b8 fb ff ff ff e9 91 fe
    [145237.352987] RSP: 0018:ffffb453e257fdb8 EFLAGS: 00010246
    [145237.352990] RAX: ffff8bd0040181c0 RBX: ffff8be68db8f800 RCX: 0000000000000000
    [145237.352991] RDX: 000000000000ffff RSI: 0000000000000000 RDI: ffff8be68db8f800
    [145237.352993] RBP: ffff8bd0040181c0 R08: 0000000000001000 R09: ffff8bcfd520e000
    [145237.352995] R10: 0000000000000000 R11: 00008417b5ab0bc0 R12: 0000000000000005
    [145237.352996] R13: ffff8bcee061c0d0 R14: ffff8bd004019640 R15: 0000000000000000
    [145237.352998] FS:  0000000000000000(0000) GS:ffff8be5dfb00000(0000) knlGS:0000000000000000
    [145237.353000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [145237.353002] CR2: 00007fd81f651d68 CR3: 0000001a0fe10001 CR4: 00000000001726e0
    [145237.353003] Call Trace:
    [145237.353008]  <TASK>
    [145237.353011]  ice_process_vflr_event+0x8d/0xb0 [ice]
    [145237.353049]  ice_service_task+0x79f/0xef0 [ice]
    [145237.353074]  process_one_work+0x1c8/0x390
    [145237.353081]  ? process_one_work+0x390/0x390
    [145237.353084]  worker_thread+0x30/0x360
    [145237.353087]  ? process_one_work+0x390/0x390
    [145237.353090]  kthread+0xe8/0x110
    [145237.353094]  ? kthread_complete_and_exit+0x20/0x20
    [145237.353097]  ret_from_fork+0x22/0x30
    [145237.353103]  </TASK>
    
    Remove WARN_ON() from check if VSI is null in ice_reset_vf.
    Add "VF is already removed\n" in dev_dbg().
    
    This WARN_ON() is unnecessary and causes call trace, despite that
    call trace, driver still works. There is no need for this warn
    because this piece of code is responsible for disabling VF's Tx/Rx
    queues when VF is disabled, but when VF is already removed there
    is no need to do reset or disable queues.
    
    Fixes: efe41860008e ("ice: Fix memory corruption in VF driver")
    Signed-off-by: Michal Jaron <michalx.jaron@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Marek Szlosek <marek.szlosek@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18c800b1844d321df333d7a62bc4b67a9d4a971d
Author: Benjamin Mikailenko <benjamin.mikailenko@intel.com>
Date:   Fri Jul 15 18:27:07 2022 -0400

    ice: Fix VSI rebuild WARN_ON check for VF
    
    commit 7fe05e125d5f730bd2d0fc53985bee77b6c762f0 upstream.
    
    In commit b03d519d3460 ("ice: store VF pointer instead of VF ID")
    WARN_ON checks were added to validate the vsi->vf pointer and
    catch programming errors. However, one check to vsi->vf was missed.
    This caused a call trace when resetting VFs.
    
    Fix ice_vsi_rebuild by encompassing VF pointer in WARN_ON check.
    
    Fixes: b03d519d3460 ("ice: store VF pointer instead of VF ID")
    Signed-off-by: Benjamin Mikailenko <benjamin.mikailenko@intel.com>
    Tested-by: Marek Szlosek <marek.szlosek@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79f86b862416126a2e826cb74224180d6625a32f
Author: Rustam Subkhankulov <subkhankulov@ispras.ru>
Date:   Wed Aug 17 03:38:45 2022 +0300

    net: dsa: sja1105: fix buffer overflow in sja1105_setup_devlink_regions()
    
    commit fd8e899cdb5ecaf8e8ee73854a99e10807eef1de upstream.
    
    If an error occurs in dsa_devlink_region_create(), then 'priv->regions'
    array will be accessed by negative index '-1'.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Rustam Subkhankulov <subkhankulov@ispras.ru>
    Fixes: bf425b82059e ("net: dsa: sja1105: expose static config as devlink region")
    Link: https://lore.kernel.org/r/20220817003845.389644-1-subkhankulov@ispras.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e2bb2db0dd843a4f6ac0f82e0b93ede4ec13692
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Aug 16 23:14:45 2022 +0300

    net: dsa: don't warn in dsa_port_set_state_now() when driver doesn't support it
    
    commit 211987f3ac734000ea1548784b2a4539a974fbc8 upstream.
    
    ds->ops->port_stp_state_set() is, like most DSA methods, optional, and
    if absent, the port is supposed to remain in the forwarding state (as
    standalone). Such is the case with the mv88e6060 driver, which does not
    offload the bridge layer. DSA warns that the STP state can't be changed
    to FORWARDING as part of dsa_port_enable_rt(), when in fact it should not.
    
    The error message is also not up to modern standards, so take the
    opportunity to make it more descriptive.
    
    Fixes: fd3645413197 ("net: dsa: change scope of STP state setter")
    Reported-by: Sergei Antonov <saproj@gmail.com>
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Sergei Antonov <saproj@gmail.com>
    Link: https://lore.kernel.org/r/20220816201445.1809483-1-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26b6acd365823e99e46be3b27500f5dc235dda5e
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Tue Aug 16 09:19:39 2022 -0700

    net: genl: fix error path memory leak in policy dumping
    
    commit 249801360db3dec4f73768c502192020bfddeacc upstream.
    
    If construction of the array of policies fails when recording
    non-first policy we need to unwind.
    
    netlink_policy_dump_add_policy() itself also needs fixing as
    it currently gives up on error without recording the allocated
    pointer in the pstate pointer.
    
    Reported-by: syzbot+dc54d9ba8153b216cae0@syzkaller.appspotmail.com
    Fixes: 50a896cf2d6f ("genetlink: properly support per-op policy dumping")
    Link: https://lore.kernel.org/r/20220816161939.577583-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 636f5ac8cb272625a847e4b7aad85a3de0eba8b7
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Aug 16 16:53:47 2022 +0300

    net: mscc: ocelot: fix address of SYS_COUNT_TX_AGING counter
    
    commit 173ca86618d751bd183456c9cdbb69952ba283c8 upstream.
    
    This register, used as part of stats->tx_dropped in
    ocelot_get_stats64(), has a wrong address. At the address currently
    given, there is actually the c_tx_green_prio_6 counter.
    
    Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89caf1cf7a0152020f67faee358bd62bf97d9af3
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Aug 16 16:53:46 2022 +0300

    net: mscc: ocelot: fix incorrect ndo_get_stats64 packet counters
    
    commit 5152de7b79ab0be150f5966481b0c8f996192531 upstream.
    
    Reading stats using the SYS_COUNT_* register definitions is only used by
    ocelot_get_stats64() from the ocelot switchdev driver, however,
    currently the bucket definitions are incorrect.
    
    Separately, on both RX and TX, we have the following problems:
    - a 256-1023 bucket which actually tracks the 256-511 packets
    - the 1024-1526 bucket actually tracks the 512-1023 packets
    - the 1527-max bucket actually tracks the 1024-1526 packets
    
    => nobody tracks the packets from the real 1527-max bucket
    
    Additionally, the RX_PAUSE, RX_CONTROL, RX_LONGS and RX_CLASSIFIED_DROPS
    all track the wrong thing. However this doesn't seem to have any
    consequence, since ocelot_get_stats64() doesn't use these.
    
    Even though this problem only manifests itself for the switchdev driver,
    we cannot split the fix for ocelot and for DSA, since it requires fixing
    the bucket definitions from enum ocelot_reg, which makes us necessarily
    adapt the structures from felix and seville as well.
    
    Fixes: 84705fc16552 ("net: dsa: felix: introduce support for Seville VSC9953 switch")
    Fixes: 56051948773e ("net: dsa: ocelot: add driver for Felix switch family")
    Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d0faa1d50d3d78b93bd78993dabd9f8aca0eb3d9
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Tue Aug 16 16:53:45 2022 +0300

    net: dsa: felix: fix ethtool 256-511 and 512-1023 TX packet counters
    
    commit 40d21c4565bce064c73a03b79a157a3493c518b9 upstream.
    
    What the driver actually reports as 256-511 is in fact 512-1023, and the
    TX packets in the 256-511 bucket are not reported. Fix that.
    
    Fixes: 56051948773e ("net: dsa: ocelot: add driver for Felix switch family")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7d1edd299d9bd0c18acbfae28710404aedf8563
Author: Arun Ramadoss <arun.ramadoss@microchip.com>
Date:   Tue Aug 16 16:25:16 2022 +0530

    net: dsa: microchip: ksz9477: fix fdb_dump last invalid entry
    
    commit 36c0d935015766bf20d621c18313f17691bda5e3 upstream.
    
    In the ksz9477_fdb_dump function it reads the ALU control register and
    exit from the timeout loop if there is valid entry or search is
    complete. After exiting the loop, it reads the alu entry and report to
    the user space irrespective of entry is valid. It works till the valid
    entry. If the loop exited when search is complete, it reads the alu
    table. The table returns all ones and it is reported to user space. So
    bridge fdb show gives ff:ff:ff:ff:ff:ff as last entry for every port.
    To fix it, after exiting the loop the entry is reported only if it is
    valid one.
    
    Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
    Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20220816105516.18350-1-arun.ramadoss@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd3c02963b7e0ac782e38b1ab37ef965269655e4
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Mon Aug 15 11:08:48 2022 +0800

    net: sched: fix misuse of qcpu->backlog in gnet_stats_add_queue_cpu
    
    commit de64b6b6fb6f369840d171b7c5a9baf31b8b2630 upstream.
    
    In the gnet_stats_add_queue_cpu function, the qstats->qlen statistics
    are incorrectly set to qcpu->backlog.
    
    Fixes: 448e163f8b9b ("gen_stats: Add gnet_stats_add_queue()")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Link: https://lore.kernel.org/r/20220815030848.276746-1-shaozhengchao@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce12ce2e88646e221601f29a7dd8d7613f5cbf01
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Mon Aug 15 10:46:29 2022 +0800

    net: rtnetlink: fix module reference count leak issue in rtnetlink_rcv_msg
    
    commit 5b22f62724a0a09e00d301abf5b57b0c12be8a16 upstream.
    
    When bulk delete command is received in the rtnetlink_rcv_msg function,
    if bulk delete is not supported, module_put is not called to release
    the reference counting. As a result, module reference count is leaked.
    
    Fixes: a6cec0bcd342 ("net: rtnetlink: add bulk delete support flag")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://lore.kernel.org/r/20220815024629.240367-1-shaozhengchao@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7998043d31d000c3a93f46182e6569dd0eecda34
Author: Xin Xiong <xiongx18@fudan.edu.cn>
Date:   Sat Aug 13 20:49:08 2022 +0800

    net: fix potential refcount leak in ndisc_router_discovery()
    
    commit 7396ba87f1edf549284869451665c7c4e74ecd4f upstream.
    
    The issue happens on specific paths in the function. After both the
    object `rt` and `neigh` are grabbed successfully, when `lifetime` is
    nonzero but the metric needs change, the function just deletes the
    route and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh`
    again if above conditions hold. The function simply overwrite `neigh`
    if succeeds or returns if fails, without decreasing the reference
    count of previous `neigh`. This may result in memory leaks.
    
    Fix it by decrementing the reference count of `neigh` in place.
    
    Fixes: 6b2e04bc240f ("net: allow user to set metric on default route learned via Router Advertisement")
    Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec6612958fc8fb0e90259a43de7c4afb69bba7f8
Author: Sergei Antonov <saproj@gmail.com>
Date:   Fri Aug 12 20:13:39 2022 +0300

    net: moxa: pass pdev instead of ndev to DMA functions
    
    commit 3a12df22a8f68954a4ba48435c06b3d1791c87c4 upstream.
    
    dma_map_single() calls fail in moxart_mac_setup_desc_ring() and
    moxart_mac_start_xmit() which leads to an incessant output of this:
    
    [   16.043925] moxart-ethernet 92000000.mac eth0: DMA mapping error
    [   16.050957] moxart-ethernet 92000000.mac eth0: DMA mapping error
    [   16.058229] moxart-ethernet 92000000.mac eth0: DMA mapping error
    
    Passing pdev to DMA is a common approach among net drivers.
    
    Fixes: 6c821bd9edc9 ("net: Add MOXA ART SoCs ethernet driver")
    Signed-off-by: Sergei Antonov <saproj@gmail.com>
    Suggested-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20220812171339.2271788-1-saproj@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df5423131456848040cff307751ecafb6efb911d
Author: Amit Cohen <amcohen@nvidia.com>
Date:   Fri Aug 12 17:32:01 2022 +0200

    mlxsw: spectrum: Clear PTP configuration after unregistering the netdevice
    
    commit a159e986ad26d3f35c0157ac92760ba5e44e6785 upstream.
    
    Currently as part of removing port, PTP API is called to clear the
    existing configuration and set the 'rx_filter' and 'tx_type' to zero.
    The clearing is done before unregistering the netdevice, which means that
    there is a window of time in which the user can reconfigure PTP in the
    port, and this configuration will not be cleared.
    
    Reorder the operations, clear PTP configuration after unregistering the
    netdevice.
    
    Fixes: 8748642751ede ("mlxsw: spectrum: PTP: Support SIOCGHWTSTAMP, SIOCSHWTSTAMP ioctls")
    Signed-off-by: Amit Cohen <amcohen@nvidia.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb0422d00a2a7e5ab0c3db60fb80d15a6480fb30
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Thu Aug 11 08:51:58 2022 -0400

    virtio_net: fix endian-ness for RSS
    
    commit 95bb633048fab742230eb2cdf20b8e2676240a54 upstream.
    
    Using native endian-ness for device supplied fields is wrong
    on BE platforms. Sparse warns about this.
    
    Fixes: 91f41f01d219 ("drivers/net/virtio_net: Added RSS hash report.")
    Cc: "Andrew Melnychenko" <andrew@daynix.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1a75f78a2937567946b1b756f82462874b5ca20
Author: Maxim Kochetkov <fido_max@inbox.ru>
Date:   Thu Aug 11 12:48:40 2022 +0300

    net: qrtr: start MHI channel after endpoit creation
    
    commit 68a838b84effb7b57ba7d50b1863fc6ae35a54ce upstream.
    
    MHI channel may generates event/interrupt right after enabling.
    It may leads to 2 race conditions issues.
    
    1)
    Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check:
    
            if (!qdev || mhi_res->transaction_status)
                    return;
    
    Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed at
    this moment. In this situation qrtr-ns will be unable to enumerate
    services in device.
    ---------------------------------------------------------------
    
    2)
    Such event may come at the moment after dev_set_drvdata() and
    before qrtr_endpoint_register(). In this case kernel will panic with
    accessing wrong pointer at qcom_mhi_qrtr_dl_callback():
    
            rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr,
                                    mhi_res->bytes_xferd);
    
    Because endpoint is not created yet.
    --------------------------------------------------------------
    So move mhi_prepare_for_transfer_autoqueue after endpoint creation
    to fix it.
    
    Fixes: a2e2cc0dbb11 ("net: qrtr: Start MHI channels during init")
    Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
    Reviewed-by: Hemant Kumar <quic_hemantk@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
    Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3a4b55829617cad2d36fa6524367ef629566ba6
Author: Sergei Antonov <saproj@gmail.com>
Date:   Thu Aug 11 10:09:39 2022 +0300

    net: dsa: mv88e6060: prevent crash on an unused port
    
    commit 246bbf2f977ea36aaf41f5d24370fef433250728 upstream.
    
    If the port isn't a CPU port nor a user port, 'cpu_dp'
    is a null pointer and a crash happened on dereferencing
    it in mv88e6060_setup_port():
    
    [    9.575872] Unable to handle kernel NULL pointer dereference at virtual address 00000014
    ...
    [    9.942216]  mv88e6060_setup from dsa_register_switch+0x814/0xe84
    [    9.948616]  dsa_register_switch from mdio_probe+0x2c/0x54
    [    9.954433]  mdio_probe from really_probe.part.0+0x98/0x2a0
    [    9.960375]  really_probe.part.0 from driver_probe_device+0x30/0x10c
    [    9.967029]  driver_probe_device from __device_attach_driver+0xb8/0x13c
    [    9.973946]  __device_attach_driver from bus_for_each_drv+0x90/0xe0
    [    9.980509]  bus_for_each_drv from __device_attach+0x110/0x184
    [    9.986632]  __device_attach from bus_probe_device+0x8c/0x94
    [    9.992577]  bus_probe_device from deferred_probe_work_func+0x78/0xa8
    [    9.999311]  deferred_probe_work_func from process_one_work+0x290/0x73c
    [   10.006292]  process_one_work from worker_thread+0x30/0x4b8
    [   10.012155]  worker_thread from kthread+0xd4/0x10c
    [   10.017238]  kthread from ret_from_fork+0x14/0x3c
    
    Fixes: 0abfd494deef ("net: dsa: use dedicated CPU port")
    CC: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
    CC: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Sergei Antonov <saproj@gmail.com>
    Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20220811070939.1717146-1-saproj@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 76fbeb1662b1c56514325118a07fba74dc4c79fe
Author: Xin Xiong <xiongx18@fudan.edu.cn>
Date:   Wed Aug 10 23:29:13 2022 +0800

    net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change()
    
    commit bfc48f1b0505ffcb03a6d749139b7577d6b81ae0 upstream.
    
    The issue happens on some error handling paths. When the function
    fails to grab the object `xprt`, it simply returns 0, forgetting to
    decrease the reference count of another object `xps`, which is
    increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount
    leaks. Also, the function forgets to check whether `xps` is valid
    before using it, which may result in NULL-dereferencing issues.
    
    Fix it by adding proper error handling code when either `xprt` or
    `xps` is NULL.
    
    Fixes: 5b7eb78486cd ("SUNRPC: take a xprt offline using sysfs")
    Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 181c691581d04cda1b115aff70d0c2fe1e397068
Author: Neil Armstrong <narmstrong@baylibre.com>
Date:   Thu Aug 11 15:44:45 2022 +0200

    spi: meson-spicc: add local pow2 clock ops to preserve rate between messages
    
    commit 09992025dacd258c823f50e82db09d7ef06cdac4 upstream.
    
    At the end of a message, the HW gets a reset in meson_spicc_unprepare_transfer(),
    this resets the SPICC_CONREG register and notably the value set by the
    Common Clock Framework.
    
    This is problematic because:
    - the register value CCF can be different from the corresponding CCF cached rate
    - CCF is allowed to change the clock rate whenever the HW state
    
    This introduces:
    - local pow2 clock ops checking the HW state before allowing a clock operation
    - separation of legacy pow2 clock patch and new enhanced clock path
    - SPICC_CONREG datarate value is now value kepts across messages
    
    It has been checked that:
    - SPICC_CONREG datarate value is kept across messages
    - CCF is only allowed to change the SPICC_CONREG datarate value when busy
    - SPICC_CONREG datarate value is correct for each transfer
    
    This didn't appear before commit 3e0cf4d3fc29 ("spi: meson-spicc: add a linear clock divider support")
    because we recalculated and wrote the rate for each xfer.
    
    Fixes: 3e0cf4d3fc29 ("spi: meson-spicc: add a linear clock divider support")
    Reported-by: Da Xue <da@libre.computer>
    Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20220811134445.678446-1-narmstrong@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90f195c01a2e8d8da6281791617e21109719c981
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Mon Aug 15 16:55:23 2022 +1000

    powerpc/pci: Fix get_phb_number() locking
    
    commit 8d48562a2729742f767b0fdd994d6b2a56a49c63 upstream.
    
    The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP
    warning on some systems:
    
      BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
      in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper
      preempt_count: 1, expected: 0
      RCU nest depth: 0, expected: 0
      1 lock held by swapper/1:
       #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220
      Preemption disabled at:
      [<00000000>] 0x0
      CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1
      Call Trace:
      [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable)
      [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8
      [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec
      [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4
      [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220
      [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784
      [d101de50] [c140852c] discover_phbs+0x30/0x4c
      [d101de60] [c0007fd4] do_one_initcall+0x94/0x344
      [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c
      [d101df10] [c00086e0] kernel_init+0x34/0x160
      [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64
    
    This is because pcibios_alloc_controller() holds hose_spinlock but
    of_alias_get_id() takes of_mutex which can sleep.
    
    The hose_spinlock protects the phb_bitmap, and also the hose_list, but
    it doesn't need to be held while get_phb_number() calls the OF routines,
    because those are only looking up information in the device tree.
    
    So fix it by having get_phb_number() take the hose_spinlock itself, only
    where required, and then dropping the lock before returning.
    pcibios_alloc_controller() then needs to take the lock again before the
    list_add() but that's safe, the order of the list is not important.
    
    Fixes: 0fe1e96fef0a ("powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias")
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220815065550.1303620-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05414b8644e0842849fb0ceb35410c9d5b45b366
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Aug 15 17:55:07 2022 +0200

    netfilter: nf_tables: check NFT_SET_CONCAT flag if field_count is specified
    
    commit 1b6345d4160ecd3d04bd8cd75df90c67811e8cc9 upstream.
    
    Since f3a2181e16f1 ("netfilter: nf_tables: Support for sets with
    multiple ranged fields"), it possible to combine intervals and
    concatenations. Later on, ef516e8625dd ("netfilter: nf_tables:
    reintroduce the NFT_SET_CONCAT flag") provides the NFT_SET_CONCAT flag
    for userspace to report that the set stores a concatenation.
    
    Make sure NFT_SET_CONCAT is set on if field_count is specified for
    consistency. Otherwise, if NFT_SET_CONCAT is specified with no
    field_count, bail out with EINVAL.
    
    Fixes: ef516e8625dd ("netfilter: nf_tables: reintroduce the NFT_SET_CONCAT flag")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6232edba59e1437fee1af9508cd152d3778b782
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sat Aug 13 15:22:05 2022 +0200

    netfilter: nf_tables: disallow NFT_SET_ELEM_CATCHALL and NFT_SET_ELEM_INTERVAL_END
    
    commit fc0ae524b5fd2938c94d56da3f749f11eb3273d5 upstream.
    
    These flags are mutually exclusive, report EINVAL in this case.
    
    Fixes: aaa31047a6d2 ("netfilter: nftables: add catch-all set element support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad48276cd5b45c1d25875ac74b352da3049eb7a4
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Aug 12 16:21:28 2022 +0200

    netfilter: nf_tables: NFTA_SET_ELEM_KEY_END requires concat and interval flags
    
    commit 88cccd908d51397f9754f89a937cd13fa59dee37 upstream.
    
    If the NFT_SET_CONCAT|NFT_SET_INTERVAL flags are set on, then the
    netlink attribute NFTA_SET_ELEM_KEY_END must be specified. Otherwise,
    NFTA_SET_ELEM_KEY_END should not be present.
    
    For catch-all element, NFTA_SET_ELEM_KEY_END should not be present.
    The NFT_SET_ELEM_INTERVAL_END is never used with this set flags
    combination.
    
    Fixes: 7b225d0b5c6d ("netfilter: nf_tables: add NFTA_SET_ELEM_KEY_END attribute")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ccd3c8a038405ed206c988dc5a67fb3b3731951
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Aug 12 16:19:23 2022 +0200

    netfilter: nf_tables: validate NFTA_SET_ELEM_OBJREF based on NFT_SET_OBJECT flag
    
    commit 5a2f3dc31811e93be15522d9eb13ed61460b76c8 upstream.
    
    If the NFTA_SET_ELEM_OBJREF netlink attribute is present and
    NFT_SET_OBJECT flag is set on, report EINVAL.
    
    Move existing sanity check earlier to validate that NFT_SET_OBJECT
    requires NFTA_SET_ELEM_OBJREF.
    
    Fixes: 8aeff920dcc9 ("netfilter: nf_tables: add stateful object reference to set elements")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4fbfbccc0a957b78768f1925f28df81185d395e
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Aug 11 13:30:39 2022 +0200

    netfilter: nf_tables: fix scheduling-while-atomic splat
    
    commit 2024439bd5ceb145eeeb428b2a59e9b905153ac3 upstream.
    
    nf_tables_check_loops() can be called from rhashtable list
    walk so cond_resched() cannot be used here.
    
    Fixes: 81ea01066741 ("netfilter: nf_tables: add rescheduling points during loop detection walks")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 822943b48f0fa84aeb4a7a457f68031c5e6e533d
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Aug 9 17:23:53 2022 +0200

    netfilter: nf_tables: really skip inactive sets when allocating name
    
    commit 271c5ca826e0c3c53e0eb4032f8eaedea1ee391c upstream.
    
    While looping to build the bitmap of used anonymous set names, check the
    current set in the iteration, instead of the one that is being created.
    
    Fixes: 37a9cc525525 ("netfilter: nf_tables: add generation mask to sets")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e52e6cfec6342c3d0df47dc3a76724fb3dabf56
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Aug 9 17:23:52 2022 +0200

    netfilter: nf_tables: possible module reference underflow in error path
    
    commit c485c35ff6783ccd12c160fcac6a0e504e83e0bf upstream.
    
    dst->ops is set on when nft_expr_clone() fails, but module refcount has
    not been bumped yet, therefore nft_expr_destroy() leads to module
    reference underflow.
    
    Fixes: 8cfd9b0f8515 ("netfilter: nftables: generalize set expressions support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fe99df73467a3084ff8efee034e27dbe2639a31
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Aug 9 15:16:35 2022 +0200

    netfilter: nf_ct_irc: cap packet search space to 4k
    
    commit 976bf59c69cd2e2c17f0ab20a14c0e700cba0f15 upstream.
    
    This uses a pseudo-linearization scheme with a 64k global buffer,
    but BIG TCP arrival means IPv6 TCP stack can generate skbs
    that exceed this size.
    
    In practice, IRC commands are not expected to exceed 512 bytes, plus
    this is interactive protocol, so we should not see large packets
    in practice.
    
    Given most IRC connections nowadays use TLS so this helper could also be
    removed in the near future.
    
    Fixes: 7c4e983c4f3c ("net: allow gso_max_size to exceed 65536")
    Fixes: 0fe79f28bfaf ("net: allow gro_max_size to exceed 65536")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61705b872f3cbcc4f587183829143a719decee64
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Aug 9 15:16:34 2022 +0200

    netfilter: nf_ct_ftp: prefer skb_linearize
    
    commit c783a29c7e5934eabac2b760571489ad83bf4fd1 upstream.
    
    This uses a pseudo-linearization scheme with a 64k global buffer,
    but BIG TCP arrival means IPv6 TCP stack can generate skbs
    that exceed this size.
    
    Use skb_linearize.  It should be possible to rewrite this to properly
    deal with segmented skbs (i.e., only do small chunk-wise accesses),
    but this is going to be a lot more intrusive than this because every
    helper function needs to get the sk_buff instead of a pointer to a raw
    data buffer.
    
    In practice, provided we're really looking at FTP control channel packets,
    there should never be a case where we deal with huge packets.
    
    Fixes: 7c4e983c4f3c ("net: allow gso_max_size to exceed 65536")
    Fixes: 0fe79f28bfaf ("net: allow gro_max_size to exceed 65536")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08147d81e88bae351a6733c06a7532a43e7df3b7
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Aug 9 15:16:33 2022 +0200

    netfilter: nf_ct_h323: cap packet size at 64k
    
    commit f3e124c36f70d5ffcdd4e8bdbe7bb28a98a715c0 upstream.
    
    With BIG TCP, packets generated by tcp stack may exceed 64kb.
    Cap datalen at 64kb.  The internal message format uses 16bit fields,
    so no embedded message can exceed 64k size.
    
    Multiple h323 messages in a single superpacket may now result
    in a message to get treated as incomplete/truncated, but thats
    better than scribbling past h323_buffer.
    
    Another alternative suitable for net tree would be a switch to
    skb_linearize().
    
    Fixes: 7c4e983c4f3c ("net: allow gso_max_size to exceed 65536")
    Fixes: 0fe79f28bfaf ("net: allow gro_max_size to exceed 65536")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44cc2be58b871b9f023978b3d90d6c950b515f53
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Aug 9 15:16:32 2022 +0200

    netfilter: nf_ct_sane: remove pseudo skb linearization
    
    commit a664375da76c6da8f83dc7997e43c568e1eb9a6a upstream.
    
    For historical reason this code performs pseudo linearization of skbs
    via skb_header_pointer and a global 64k buffer.
    
    With arrival of BIG TCP, packets generated by TCP stack can exceed 64kb.
    
    Rewrite this to only extract the needed header data.  This also allows
    to get rid of the locking.
    
    Fixes: 7c4e983c4f3c ("net: allow gso_max_size to exceed 65536")
    Fixes: 0fe79f28bfaf ("net: allow gro_max_size to exceed 65536")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f4882fa0ed3a7bd69919d524ca86bf939f81d55
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Aug 9 13:39:18 2022 +0200

    netfilter: nf_tables: disallow NFTA_SET_ELEM_KEY_END with NFT_SET_ELEM_INTERVAL_END flag
    
    commit 4963674c2e71fc062f8f089f0f58ffbb5533060b upstream.
    
    These are mutually exclusive, actually NFTA_SET_ELEM_KEY_END replaces
    the flag notation.
    
    Fixes: 7b225d0b5c6d ("netfilter: nf_tables: add NFTA_SET_ELEM_KEY_END attribute")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78c5b279e1fc0dd09aa0932b2fe968d6885212f1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Aug 8 11:34:41 2022 +0300

    fs/ntfs3: uninitialized variable in ntfs_set_acl_ex()
    
    commit d4073595d0c61463ec3a87411b19e2a90f76d3f8 upstream.
    
    The goto out calls kfree(value) on an uninitialized pointer.  Just
    return directly as the other error paths do.
    
    Fixes: 460bbf2990b3 ("fs/ntfs3: Do not change mode if ntfs_set_ea failed")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5aff1b8cf9f2b1051de8b3ab076c1ddf3fa7989
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Aug 9 13:22:01 2022 +0200

    netfilter: nf_tables: use READ_ONCE and WRITE_ONCE for shared generation id access
    
    commit 3400278328285a8c2f121904496aff5e7b610a01 upstream.
    
    The generation ID is bumped from the commit path while holding the
    mutex, however, netlink dump operations rely on RCU.
    
    This patch also adds missing cb->base_eq initialization in
    nf_tables_dump_set().
    
    Fixes: 38e029f14a97 ("netfilter: nf_tables: set NLM_F_DUMP_INTR if netlink dumping is stale")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19c942f7d2afc251e4b91f68e9f162c931a840db
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Aug 5 10:59:57 2022 +0200

    netfilter: nfnetlink: re-enable conntrack expectation events
    
    commit 0b2f3212b551a87fe936701fa0813032861a3308 upstream.
    
    To avoid allocation of the conntrack extension area when possible,
    the default behaviour was changed to only allocate the event extension
    if a userspace program is subscribed to a notification group.
    
    Problem is that while 'conntrack -E' does enable the event allocation
    behind the scenes, 'conntrack -E expect' does not: no expectation events
    are delivered unless user sets
    "net.netfilter.nf_conntrack_events" back to 1 (always on).
    
    Fix the autodetection to also consider EXP type group.
    
    We need to track the 6 event groups (3+3, new/update/destroy for events and
    for expectations each) independently, else we'd disable events again
    if an expectation group becomes empty while there is still an active
    event group.
    
    Fixes: 2794cdb0b97b ("netfilter: nfnetlink: allow to detect if ctnetlink listeners exist")
    Reported-by: Yi Chen <yiche@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 211c7bb7ee464ee30ac9fa61c7c63b3fbb13a970
Author: Potnuri Bharat Teja <bharat@chelsio.com>
Date:   Wed Aug 10 00:11:18 2022 +0530

    RDMA/cxgb4: fix accept failure due to increased cpl_t5_pass_accept_rpl size
    
    commit ef0162298abf46b881e4a4d0c604d1a066228647 upstream.
    
    Commit 'c2ed5611afd7' has increased the cpl_t5_pass_accept_rpl{} structure
    size by 8B to avoid roundup. cpl_t5_pass_accept_rpl{} is a HW specific
    structure and increasing its size will lead to unwanted adapter errors.
    Current commit reverts the cpl_t5_pass_accept_rpl{} back to its original
    and allocates zeroed skb buffer there by avoiding the memset for iss field.
    Reorder code to minimize chip type checks.
    
    Fixes: c2ed5611afd7 ("iw_cxgb4: Use memset_startat() for cpl_t5_pass_accept_rpl")
    Link: https://lore.kernel.org/r/20220809184118.2029-1-rahul.lakkireddy@chelsio.com
    Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com>
    Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e88dc32f66b027cf58d9df6ffd05a6545e7569f
Author: Mark Bloch <mbloch@nvidia.com>
Date:   Mon Aug 8 10:48:06 2022 +0300

    RDMA/mlx5: Use the proper number of ports
    
    commit 4b83c3caf289b80acecc539c79f10a6937cc42dd upstream.
    
    The cited commit allowed the driver to operate over HCAs that have
    4 physical ports. Use the number of ports of the RDMA device in the for
    loop instead of using the struct size.
    
    Fixes: 4cd14d44b11d ("net/mlx5: Support devices with more than 2 ports")
    Link: https://lore.kernel.org/r/a54a56c2ede16044a29d119209b35189c662ac72.1659944855.git.leonro@nvidia.com
    Signed-off-by: Mark Bloch <mbloch@nvidia.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cc625c5632f6c7655897503d4cc46b0de2a9893
Author: Sergey Gorenko <sergeygo@nvidia.com>
Date:   Fri Aug 5 09:01:35 2022 +0300

    IB/iser: Fix login with authentication
    
    commit d6d142cb7f79bec6051c5ecf744b7a5309c5a0ee upstream.
    
    The iSER Initiator uses two types of receive buffers:
    
      - one big login buffer posted by iser_post_recvl();
      - several small message buffers posted by iser_post_recvm().
    
    The login buffer is used at the login phase and full feature phase in
    the discovery session. It may take a few requests and responses to
    complete the login phase. The message buffers are only used in the
    normal operational session at the full feature phase.
    
    After the commit referred in the fixes line, the login operation fails
    if the authentication is enabled. That happens because the Initiator
    posts a small receive buffer after the first response from Target. So,
    the next send operation fails because Target's second response does not
    fit into the small receive buffer.
    
    This commit adds additional checks to prevent posting small receive
    buffers until the full feature phase.
    
    Fixes: 39b169ea0d36 ("IB/iser: Fix RNR errors")
    Link: https://lore.kernel.org/r/20220805060135.18493-1-sergeygo@nvidia.com
    Signed-off-by: Sergey Gorenko <sergeygo@nvidia.com>
    Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 069b05cc3eecee1a73d4faa8db904f695323a6a6
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Wed Aug 10 12:41:56 2022 +0200

    ASoC: codec: tlv320aic32x4: fix mono playback via I2S
    
    commit b4b5f29a076e52181f63e45a2ad1bc88593072e3 upstream.
    
    The two commits referenced below break mono playback via I2S DAI because
    they set BCLK to half the required speed. For PCM transport over I2S, the
    number of transmitted channels is always 2, even for mono playback.
    
    Fixes: dcd79364bff3 ("ASoC: codec: tlv3204: Enable 24 bit audio support")
    Fixes: 40b37136287b ("ASoC: tlv320aic32x4: Fix bdiv clock rate derivation")
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Link: https://lore.kernel.org/r/20220810104156.665452-1-p.zabel@pengutronix.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8c579901388662d3c21680d130534a11ae4c01f
Author: Martin Povišer <povik+lin@cutebit.org>
Date:   Mon Aug 8 16:12:46 2022 +0200

    ASoC: tas2770: Fix handling of mute/unmute
    
    commit 1e5907bcb3a3b569be0a03ebe668bba2ed320a50 upstream.
    
    Because the PWR_CTRL field is modeled as the power state of the DAC
    widget, and at the same time it is used to implement mute/unmute, we
    need some additional book-keeping to have the right end result no matter
    the sequence of calls. Without this fix, one can mute an ongoing stream
    by toggling a speaker pin control.
    
    Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver")
    Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
    Link: https://lore.kernel.org/r/20220808141246.5749-5-povik+lin@cutebit.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c02a92a57733c45326d0aa7a5e3d205748a0fae0
Author: Martin Povišer <povik+lin@cutebit.org>
Date:   Mon Aug 8 16:12:45 2022 +0200

    ASoC: tas2770: Drop conflicting set_bias_level power setting
    
    commit 482c23fbc7e9bf5a7a74defd0735d5346215db58 upstream.
    
    The driver is setting the PWR_CTRL field in both the set_bias_level
    callback and on DAPM events of the DAC widget (and also in the
    mute_stream method). Drop the set_bias_level callback altogether as the
    power setting it does is in conflict with the other code paths.
    
    Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver")
    Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
    Link: https://lore.kernel.org/r/20220808141246.5749-4-povik+lin@cutebit.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9fc6cac273a25d0fa4e73dbb8d5894655b372319
Author: Martin Povišer <povik+lin@cutebit.org>
Date:   Mon Aug 8 16:12:44 2022 +0200

    ASoC: tas2770: Allow mono streams
    
    commit bf54d97a835dfe62d4d29e245e170c63d0089be7 upstream.
    
    The part is a mono speaker amp, but it can do downmix and switch between
    left and right channel, so the right channel range is 1 to 2.
    
    Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver")
    Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
    Link: https://lore.kernel.org/r/20220808141246.5749-3-povik+lin@cutebit.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e755dc032d11b3f7845429b88fb8a2dd13ee4c60
Author: Martin Povišer <povik+lin@cutebit.org>
Date:   Mon Aug 8 16:12:43 2022 +0200

    ASoC: tas2770: Set correct FSYNC polarity
    
    commit e9ac31f0a5d0e246b046c20348954519f91a297f upstream.
    
    Fix setting of FSYNC polarity for DAI formats other than I2S. Also
    add support for polarity inversion.
    
    Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver")
    Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
    Link: https://lore.kernel.org/r/20220808141246.5749-2-povik+lin@cutebit.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a840e8ef6b6c56d1b7e6a555adc31135e517875
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Aug 1 19:05:10 2022 +0200

    ASoC: DPCM: Don't pick up BE without substream
    
    commit 754590651ccbbcc74a7c20907be4bb15d642bde3 upstream.
    
    When DPCM tries to add valid BE connections at dpcm_add_paths(), it
    doesn't check whether the picked BE actually supports for the given
    stream direction.  Due to that, when an asymmetric BE stream is
    present, it picks up wrongly and this may result in a NULL dereference
    at a later point where the code assumes the existence of a
    corresponding BE substream.
    
    This patch adds the check for the presence of the substream for the
    target BE for avoiding the problem above.
    
    Note that we have already some fix for non-existing BE substream at
    commit 6246f283d5e0 ("ASoC: dpcm: skip missing substream while
    applying symmetry").  But the code path we've hit recently is rather
    happening before the previous fix.  So this patch tries to fix at
    picking up a BE instead of parsing BE lists.
    
    Fixes: bbf7d3b1c4f4 ("ASoC: soc-pcm: align BE 'atomicity' with that of the FE")
    Reported-by: Alex Natalsson <harmoniesworlds@gmail.com>
    Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Cc: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/CADs9LoPZH_D+eJ9qjTxSLE5jGyhKsjMN7g2NighZ16biVxsyKw@mail.gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20220801170510.26582-1-tiwai@suse.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7915c5614a7ece117ec390f21a410531eac48de
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Aug 1 18:54:20 2022 +0200

    ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()
    
    commit 94c1ceb043c1a002de9649bb630c8e8347645982 upstream.
    
    snprintf() returns the would-be-filled size when the string overflows
    the given buffer size, hence using this value may result in the buffer
    overflow (although it's unrealistic).
    
    This patch replaces with a safer version, scnprintf() for papering
    over such a potential issue.
    
    Fixes: 29c8e4398f02 ("ASoC: SOF: Intel: hda: add extended rom status dump to error log")
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20220801165420.25978-4-tiwai@suse.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a67971a17604ae7de278fb09243432459afc51e1
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Aug 1 18:54:19 2022 +0200

    ASoC: SOF: debug: Fix potential buffer overflow by snprintf()
    
    commit 1eb123ce985e6cf302ac6e3f19862d132d86fa8f upstream.
    
    snprintf() returns the would-be-filled size when the string overflows
    the given buffer size, hence using this value may result in the buffer
    overflow (although it's unrealistic).
    
    This patch replaces with a safer version, scnprintf() for papering
    over such a potential issue.
    
    Fixes: 5b10b6298921 ("ASoC: SOF: Add `memory_info` file to debugfs")
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20220801165420.25978-3-tiwai@suse.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 840311a09f75632b9d41fbc1cd5c7aea94ce5f7e
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Aug 1 18:54:18 2022 +0200

    ASoC: Intel: avs: Fix potential buffer overflow by snprintf()
    
    commit ca3b7b9dc9bc1fa552f4697b7cccfa0258a44d00 upstream.
    
    snprintf() returns the would-be-filled size when the string overflows
    the given buffer size, hence using this value may result in a buffer
    overflow (although it's unrealistic).
    
    This patch replaces it with a safer version, scnprintf() for papering
    over such a potential issue.
    
    Fixes: f1b3b320bd65 ("ASoC: Intel: avs: Generic soc component driver")
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://lore.kernel.org/r/20220801165420.25978-2-tiwai@suse.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94e45c0cd8fdb40461d86d5bfaf5be2f73c2409a
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Mon Aug 8 19:58:45 2022 +0200

    iavf: Fix deadlock in initialization
    
    commit cbe9e51126305832cf407ee6bb556ce831488ffe upstream.
    
    Fix deadlock that occurs when iavf interface is a part of failover
    configuration.
    
    1. Mutex crit_lock is taken at the beginning of iavf_watchdog_task()
    2. Function iavf_init_config_adapter() is called when adapter
       state is __IAVF_INIT_CONFIG_ADAPTER
    3. iavf_init_config_adapter() calls register_netdevice() that emits
       NETDEV_REGISTER event
    4. Notifier function failover_event() then calls
       net_failover_slave_register() that calls dev_open()
    5. dev_open() calls iavf_open() that tries to take crit_lock in
       end-less loop
    
    Stack trace:
    ...
    [  790.251876]  usleep_range_state+0x5b/0x80
    [  790.252547]  iavf_open+0x37/0x1d0 [iavf]
    [  790.253139]  __dev_open+0xcd/0x160
    [  790.253699]  dev_open+0x47/0x90
    [  790.254323]  net_failover_slave_register+0x122/0x220 [net_failover]
    [  790.255213]  failover_slave_register.part.7+0xd2/0x180 [failover]
    [  790.256050]  failover_event+0x122/0x1ab [failover]
    [  790.256821]  notifier_call_chain+0x47/0x70
    [  790.257510]  register_netdevice+0x20f/0x550
    [  790.258263]  iavf_watchdog_task+0x7c8/0xea0 [iavf]
    [  790.259009]  process_one_work+0x1a7/0x360
    [  790.259705]  worker_thread+0x30/0x390
    
    To fix the situation we should check the current adapter state after
    first unsuccessful mutex_trylock() and return with -EBUSY if it is
    __IAVF_INIT_CONFIG_ADAPTER.
    
    Fixes: 226d528512cf ("iavf: fix locking of critical sections")
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0828e27971f18ea317710acb228afe6e72606082
Author: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
Date:   Tue Jul 19 11:16:54 2022 +0200

    iavf: Fix reset error handling
    
    commit 31071173771e079f7bc08dacd61e0db913262fbf upstream.
    
    Do not call iavf_close in iavf_reset_task error handling. Doing so can
    lead to double call of napi_disable, which can lead to deadlock there.
    Removing VF would lead to iavf_remove task being stuck, because it
    requires crit_lock, which is held by iavf_close.
    Call iavf_disable_vf if reset fail, so that driver will clean up
    remaining invalid resources.
    During rapid VF resets, HW can fail to setup VF mailbox. Wrong
    error handling can lead to iavf_remove being stuck with:
    [ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53
    ...
    [ 5267.189211] INFO: task repro.sh:11219 blocked for more than 30 seconds.
    [ 5267.189520]       Tainted: G S          E     5.18.0-04958-ga54ce3703613-dirty #1
    [ 5267.189764] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 5267.190062] task:repro.sh        state:D stack:    0 pid:11219 ppid:  8162 flags:0x00000000
    [ 5267.190347] Call Trace:
    [ 5267.190647]  <TASK>
    [ 5267.190927]  __schedule+0x460/0x9f0
    [ 5267.191264]  schedule+0x44/0xb0
    [ 5267.191563]  schedule_preempt_disabled+0x14/0x20
    [ 5267.191890]  __mutex_lock.isra.12+0x6e3/0xac0
    [ 5267.192237]  ? iavf_remove+0xf9/0x6c0 [iavf]
    [ 5267.192565]  iavf_remove+0x12a/0x6c0 [iavf]
    [ 5267.192911]  ? _raw_spin_unlock_irqrestore+0x1e/0x40
    [ 5267.193285]  pci_device_remove+0x36/0xb0
    [ 5267.193619]  device_release_driver_internal+0xc1/0x150
    [ 5267.193974]  pci_stop_bus_device+0x69/0x90
    [ 5267.194361]  pci_stop_and_remove_bus_device+0xe/0x20
    [ 5267.194735]  pci_iov_remove_virtfn+0xba/0x120
    [ 5267.195130]  sriov_disable+0x2f/0xe0
    [ 5267.195506]  ice_free_vfs+0x7d/0x2f0 [ice]
    [ 5267.196056]  ? pci_get_device+0x4f/0x70
    [ 5267.196496]  ice_sriov_configure+0x78/0x1a0 [ice]
    [ 5267.196995]  sriov_numvfs_store+0xfe/0x140
    [ 5267.197466]  kernfs_fop_write_iter+0x12e/0x1c0
    [ 5267.197918]  new_sync_write+0x10c/0x190
    [ 5267.198404]  vfs_write+0x24e/0x2d0
    [ 5267.198886]  ksys_write+0x5c/0xd0
    [ 5267.199367]  do_syscall_64+0x3a/0x80
    [ 5267.199827]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [ 5267.200317] RIP: 0033:0x7f5b381205c8
    [ 5267.200814] RSP: 002b:00007fff8c7e8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [ 5267.201981] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f5b381205c8
    [ 5267.202620] RDX: 0000000000000002 RSI: 00005569420ee900 RDI: 0000000000000001
    [ 5267.203426] RBP: 00005569420ee900 R08: 000000000000000a R09: 00007f5b38180820
    [ 5267.204327] R10: 000000000000000a R11: 0000000000000246 R12: 00007f5b383c06e0
    [ 5267.205193] R13: 0000000000000002 R14: 00007f5b383bb880 R15: 0000000000000002
    [ 5267.206041]  </TASK>
    [ 5267.206970] Kernel panic - not syncing: hung_task: blocked tasks
    [ 5267.207809] CPU: 48 PID: 551 Comm: khungtaskd Kdump: loaded Tainted: G S          E     5.18.0-04958-ga54ce3703613-dirty #1
    [ 5267.208726] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019
    [ 5267.209623] Call Trace:
    [ 5267.210569]  <TASK>
    [ 5267.211480]  dump_stack_lvl+0x33/0x42
    [ 5267.212472]  panic+0x107/0x294
    [ 5267.213467]  watchdog.cold.8+0xc/0xbb
    [ 5267.214413]  ? proc_dohung_task_timeout_secs+0x30/0x30
    [ 5267.215511]  kthread+0xf4/0x120
    [ 5267.216459]  ? kthread_complete_and_exit+0x20/0x20
    [ 5267.217505]  ret_from_fork+0x22/0x30
    [ 5267.218459]  </TASK>
    
    Fixes: f0db78928783 ("i40evf: use netdev variable in reset task")
    Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Marek Szlosek <marek.szlosek@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b305c7e9363f5a174ee08ac5f056e4b209f0325b
Author: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
Date:   Tue Jul 19 11:16:53 2022 +0200

    iavf: Fix NULL pointer dereference in iavf_get_link_ksettings
    
    commit 541a1af451b0cb3779e915d48d08efb17915207b upstream.
    
    Fix possible NULL pointer dereference, due to freeing of adapter->vf_res
    in iavf_init_get_resources. Previous commit introduced a regression,
    where receiving IAVF_ERR_ADMIN_QUEUE_NO_WORK from iavf_get_vf_config
    would free adapter->vf_res. However, netdev is still registered, so
    ethtool_ops can be called. Calling iavf_get_link_ksettings with no vf_res,
    will result with:
    [ 9385.242676] BUG: kernel NULL pointer dereference, address: 0000000000000008
    [ 9385.242683] #PF: supervisor read access in kernel mode
    [ 9385.242686] #PF: error_code(0x0000) - not-present page
    [ 9385.242690] PGD 0 P4D 0
    [ 9385.242696] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
    [ 9385.242701] CPU: 6 PID: 3217 Comm: pmdalinux Kdump: loaded Tainted: G S          E     5.18.0-04958-ga54ce3703613-dirty #1
    [ 9385.242708] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019
    [ 9385.242710] RIP: 0010:iavf_get_link_ksettings+0x29/0xd0 [iavf]
    [ 9385.242745] Code: 00 0f 1f 44 00 00 b8 01 ef ff ff 48 c7 46 30 00 00 00 00 48 c7 46 38 00 00 00 00 c6 46 0b 00 66 89 46 08 48 8b 87 68 0e 00 00 <f6> 40 08 80 75 50 8b 87 5c 0e 00 00 83 f8 08 74 7a 76 1d 83 f8 20
    [ 9385.242749] RSP: 0018:ffffc0560ec7fbd0 EFLAGS: 00010246
    [ 9385.242755] RAX: 0000000000000000 RBX: ffffc0560ec7fc08 RCX: 0000000000000000
    [ 9385.242759] RDX: ffffffffc0ad4550 RSI: ffffc0560ec7fc08 RDI: ffffa0fc66674000
    [ 9385.242762] RBP: 00007ffd1fb2bf50 R08: b6a2d54b892363ee R09: ffffa101dc14fb00
    [ 9385.242765] R10: 0000000000000000 R11: 0000000000000004 R12: ffffa0fc66674000
    [ 9385.242768] R13: 0000000000000000 R14: ffffa0fc66674000 R15: 00000000ffffffa1
    [ 9385.242771] FS:  00007f93711a2980(0000) GS:ffffa0fad72c0000(0000) knlGS:0000000000000000
    [ 9385.242775] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 9385.242778] CR2: 0000000000000008 CR3: 0000000a8e61c003 CR4: 00000000003706e0
    [ 9385.242781] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 9385.242784] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 9385.242787] Call Trace:
    [ 9385.242791]  <TASK>
    [ 9385.242793]  ethtool_get_settings+0x71/0x1a0
    [ 9385.242814]  __dev_ethtool+0x426/0x2f40
    [ 9385.242823]  ? slab_post_alloc_hook+0x4f/0x280
    [ 9385.242836]  ? kmem_cache_alloc_trace+0x15d/0x2f0
    [ 9385.242841]  ? dev_ethtool+0x59/0x170
    [ 9385.242848]  dev_ethtool+0xa7/0x170
    [ 9385.242856]  dev_ioctl+0xc3/0x520
    [ 9385.242866]  sock_do_ioctl+0xa0/0xe0
    [ 9385.242877]  sock_ioctl+0x22f/0x320
    [ 9385.242885]  __x64_sys_ioctl+0x84/0xc0
    [ 9385.242896]  do_syscall_64+0x3a/0x80
    [ 9385.242904]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [ 9385.242918] RIP: 0033:0x7f93702396db
    [ 9385.242923] Code: 73 01 c3 48 8b 0d ad 57 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 57 38 00 f7 d8 64 89 01 48
    [ 9385.242927] RSP: 002b:00007ffd1fb2bf18 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    [ 9385.242932] RAX: ffffffffffffffda RBX: 000055671b1d2fe0 RCX: 00007f93702396db
    [ 9385.242935] RDX: 00007ffd1fb2bf20 RSI: 0000000000008946 RDI: 0000000000000007
    [ 9385.242937] RBP: 00007ffd1fb2bf20 R08: 0000000000000003 R09: 0030763066307330
    [ 9385.242940] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd1fb2bf80
    [ 9385.242942] R13: 0000000000000007 R14: 0000556719f6de90 R15: 00007ffd1fb2c1b0
    [ 9385.242948]  </TASK>
    [ 9385.242949] Modules linked in: iavf(E) xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nft_compat nf_nat_tftp nft_objref nf_conntrack_tftp bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink vfat fat irdma ib_uverbs ib_core intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm iTCO_wdt iTCO_vendor_support ice irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl i40e pcspkr intel_cstate joydev mei_me intel_uncore mxm_wmi mei ipmi_ssif lpc_ich ipmi_si acpi_power_meter xfs libcrc32c mgag200 i2c_algo_bit drm_shmem_helper drm_kms_helper sd_mod t10_pi crc64_rocksoft crc64 syscopyarea sg sysfillrect sysimgblt fb_sys_fops drm ixgbe ahci libahci libata crc32c_intel mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
    [ 9385.243065]  [last unloaded: iavf]
    
    Dereference happens in if (ADV_LINK_SUPPORT(adapter)) statement
    
    Fixes: 209f2f9c7181 ("iavf: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2 negotiation")
    Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Marek Szlosek <marek.szlosek@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35c63581fdefdcbaeae8cded18908523252353ad
Author: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
Date:   Tue Jul 19 11:16:52 2022 +0200

    iavf: Fix adminq error handling
    
    commit 419831617ed349992c84344dbd9e627f9e68f842 upstream.
    
    iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent
    memory for VF mailbox.
    Free DMA regions for both ASQ and ARQ in case error happens during
    configuration of ASQ/ARQ registers.
    Without this change it is possible to see when unloading interface:
    74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32]
    One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]
    
    Fixes: d358aa9a7a2d ("i40evf: init code and hardware support")
    Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Marek Szlosek <marek.szlosek@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65f8463017ec3d767fd9901da8956fffc8bdade0
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Aug 8 16:09:45 2022 +0100

    nios2: add force_successful_syscall_return()
    
    commit fd0c153daad135d0ec1a53c5dbe6936a724d6ae1 upstream.
    
    If we use the ancient SysV syscall ABI, we'd better have tell the
    kernel how to claim that a negative return value is a success.
    Use ->orig_r2 for that - it's inaccessible via ptrace, so it's
    a fair game for changes and it's normally[*] non-negative on return
    from syscall.  Set to -1; syscall is not going to be restart-worthy
    by definition, so we won't interfere with that use either.
    
    [*] the only exception is rt_sigreturn(), where we skip the entire
    messing with r1/r2 anyway.
    
    Fixes: 82ed08dd1b0e ("nios2: Exception handling")
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e79673500d7be7d7f579289f7ac45f832c8173f1
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Aug 8 16:09:16 2022 +0100

    nios2: restarts apply only to the first sigframe we build...
    
    commit 411a76b7219555c55867466c82d70ce928d6c9e1 upstream.
    
    Fixes: b53e906d255d ("nios2: Signal handling support")
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 857b2561aae884361298dc2a9c33f4446e6f13c2
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Aug 8 16:08:48 2022 +0100

    nios2: fix syscall restart checks
    
    commit 2d631bd58fe0ea3e3350212e23c9aba1fb606514 upstream.
    
    sys_foo() returns -512 (aka -ERESTARTSYS) => do_signal() sees
    512 in r2 and 1 in r1.
    
    sys_foo() returns 512 => do_signal() sees 512 in r2 and 0 in r1.
    
    The former is restart-worthy; the latter obviously isn't.
    
    Fixes: b53e906d255d ("nios2: Signal handling support")
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66a496c6d784be02d0cd62860b5253e41684ec5f
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Aug 8 16:07:21 2022 +0100

    nios2: traced syscall does need to check the syscall number
    
    commit 25ba820ef36bdbaf9884adeac69b6e1821a7df76 upstream.
    
    all checks done before letting the tracer modify the register
    state are worthless...
    
    Fixes: 82ed08dd1b0e ("nios2: Exception handling")
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e489481f5dbe7c6e440fe0febfa8c6f18d23255
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Aug 8 16:06:46 2022 +0100

    nios2: don't leave NULLs in sys_call_table[]
    
    commit 45ec746c65097c25e77d24eae8fee0def5b6cc5d upstream.
    
    fill the gaps in there with sys_ni_syscall, as everyone does...
    
    Fixes: 82ed08dd1b0e ("nios2: Exception handling")
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69f5278fba36555f776d5af9efc9d2e378d3bb81
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Aug 8 16:06:04 2022 +0100

    nios2: page fault et.al. are *not* restartable syscalls...
    
    commit 8535c239ac674f7ead0f2652932d35c52c4123b2 upstream.
    
    make sure that ->orig_r2 is negative for everything except
    the syscalls.
    
    Fixes: 82ed08dd1b0e ("nios2: Exception handling")
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8089a1bc27b41e6800590a92d17c119e9aa8ff53
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Thu May 26 12:51:03 2022 +0300

    fs/ntfs3: Fix missing i_op in ntfs_read_mft
    
    commit 37a530bfe56ca9a0d3129598803f2794c7428aae upstream.
    
    There is null pointer dereference because i_op == NULL.
    The bug happens because we don't initialize i_op for records in $Extend.
    Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block")
    
    Reported-by: Liangbin Lian <jjm2473@gmail.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 228be1f6986ecf222b328fb4f88ca52a48e5d261
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Thu May 12 19:08:40 2022 +0300

    fs/ntfs3: Do not change mode if ntfs_set_ea failed
    
    commit 460bbf2990b3fdc597601c2cf669a3371c069242 upstream.
    
    ntfs_set_ea can fail with NOSPC, so we don't need to
    change mode in this situation.
    Fixes xfstest generic/449
    Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations")
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0fd64f062c8d1793d8d6d39fa3a4468e39880f90
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Wed May 11 19:58:36 2022 +0300

    fs/ntfs3: Fix double free on remount
    
    commit cd39981fb92adf0cc736112f87e3e61602baa415 upstream.
    
    Pointer to options was freed twice on remount
    Fixes xfstest generic/361
    Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block")
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4209b285adb853299affa808d2af130895ecc171
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon May 9 12:03:00 2022 +0300

    fs/ntfs3: Don't clear upper bits accidentally in log_replay()
    
    commit 926034353d3c67db1ffeab47dcb7f6bdac02a263 upstream.
    
    The "vcn" variable is a 64 bit.  The "log->clst_per_page" variable is a
    u32.  This means that the mask accidentally clears out the high 32 bits
    when it was only supposed to clear some low bits.  Fix this by adding a
    cast to u64.
    
    Fixes: b46acd6a6a62 ("fs/ntfs3: Add NTFS journal")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf6089dc01ba3194ab962105d7b85690843c256f
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Apr 21 23:53:36 2022 +0300

    fs/ntfs3: Fix NULL deref in ntfs_update_mftmirr
    
    commit 321460ca3b55f48b3ba6008248264ab2bd6407d9 upstream.
    
    If ntfs_fill_super() wasn't called then sbi->sb will be equal to NULL.
    Code should check this ptr before dereferencing. Syzbot hit this issue
    via passing wrong mount param as can be seen from log below
    
    Fail log:
    ntfs3: Unknown parameter 'iochvrset'
    general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
    CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0
    ...
    Call Trace:
     <TASK>
     put_ntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463
     ntfs_fs_free+0x6a/0xe0 fs/ntfs3/super.c:1363
     put_fs_context+0x119/0x7a0 fs/fs_context.c:469
     do_new_mount+0x2b4/0xad0 fs/namespace.c:3044
     do_mount fs/namespace.c:3383 [inline]
     __do_sys_mount fs/namespace.c:3591 [inline]
    
    Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block")
    Reported-and-tested-by: syzbot+c95173762127ad76a824@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d6663d0de7bb4d6ec42d37fac42fdde4f0bfc7f
Author: Yan Lei <chinayanlei2002@163.com>
Date:   Sun Apr 10 09:09:00 2022 +0300

    fs/ntfs3: Fix using uninitialized value n when calling indx_read
    
    commit ae5a4e46916fc307288227b64c1d062352eb93b7 upstream.
    
    This value is checked in indx_read, so it must be initialized
    Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block")
    
    Signed-off-by: Yan Lei <chinayanlei2002@163.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 174e6c2d089857997b0b953ee46d272f66d67160
Author: Chen Lin <chen45464546@163.com>
Date:   Thu Aug 11 23:16:51 2022 +0800

    dpaa2-eth: trace the allocated address instead of page struct
    
    commit e34f49348f8b7a53205b6f77707a3a6a40cf420b upstream.
    
    We should trace the allocated address instead of page struct.
    
    Fixes: 27c874867c4e ("dpaa2-eth: Use a single page per Rx buffer")
    Signed-off-by: Chen Lin <chen.lin5@zte.com.cn>
    Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
    Link: https://lore.kernel.org/r/20220811151651.3327-1-chen45464546@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e8471a8848bb73f95de7c069fc44b0010d451c68
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Aug 9 11:07:01 2022 +0300

    perf tests: Fix Track with sched_switch test for hybrid case
    
    commit 1da1d60774014137d776d0400fdf2f1779d8d4d5 upstream.
    
    If cpu_core PMU event fails to parse, try also cpu_atom PMU event when
    parsing cycles event.
    
    Fixes: 43eb05d066795bdf ("perf tests: Support 'Track with sched_switch' test for hybrid")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jin Yao <yao.jin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20220809080702.6921-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 129fe9d509f8f2e2e039642cbe17605636127ac3
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Aug 9 11:07:00 2022 +0300

    perf parse-events: Fix segfault when event parser gets an error
    
    commit 2e828582b81f5bc76a4fe8e7812df259ab208302 upstream.
    
    parse_events() is often called with parse_events_error set to NULL.
    Make parse_events_error__handle() not segfault in that case.
    
    A subsequent patch changes to avoid passing NULL in the first place.
    
    Fixes: 43eb05d066795bdf ("perf tests: Support 'Track with sched_switch' test for hybrid")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jin Yao <yao.jin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20220809080702.6921-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 8f89e5c8daf844dfae5e6d086c181b04126489c9
Author: Robin Reckmann <robin.reckmann@googlemail.com>
Date:   Sun Aug 7 23:04:54 2022 +0900

    i2c: qcom-geni: Fix GPI DMA buffer sync-back
    
    commit 8689b80b22dbf1f5e993233370fe57f08731b14d upstream.
    
    Fix i2c transfers using GPI DMA mode for all message types that do not set
    the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte").
    
    In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(),
    and it has to synced back to the message after the transfer is done.
    
    Add missing assignment of dma buffer in geni_i2c_gpi().
    
    Set xferred in i2c_put_dma_safe_msg_buf() to true in case of no error to
    ensure the sync-back of this dma buffer to the message.
    
    Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA")
    Signed-off-by: Robin Reckmann <robin.reckmann@gmail.com>
    Tested-by: Luca Weiss <luca.weiss@fairphone.com>
    Tested-by: Caleb Connolly <caleb@connolly.tech>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7dfea65b004f4e42f7b61a0bc3bf30a95c16ae55
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Aug 6 16:51:26 2022 +0200

    perf probe: Fix an error handling path in 'parse_perf_probe_command()'
    
    commit 4bf6dcaa93bcd083a13c278a91418fe10e6d23a0 upstream.
    
    If a memory allocation fail, we should branch to the error handling path
    in order to free some resources allocated a few lines above.
    
    Fixes: 15354d54698648e2 ("perf probe: Generate event name with line number")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: kernel-janitors@vger.kernel.org
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/b71bcb01fa0c7b9778647235c3ab490f699ba278.1659797452.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec82f4a9bd3a77f1cd1ea56025cf5fc25ea391bf
Author: Christoph Hellwig <hch@lst.de>
Date:   Sat Aug 6 10:29:55 2022 +0200

    nvme-fc: fix the fc_appid_store return value
    
    commit 9317d0014499182c77a03cd095e83bcfb0f53750 upstream.
    
    "nvme-fc: fold t fc_update_appid into fc_appid_store" accidentally
    changed the userspace interface for the appid attribute, because the code
    that decrements "count" to remove a trailing '\n' in the parsing results
    in the decremented value being incorrectly be returned from the sysfs
    write.  Fix this by keeping an orig_count variable for the full length
    of the write.
    
    Fixes: c814153c83a8 ("nvme-fc: fold t fc_update_appid into fc_appid_store")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Reviewed-by: James Smart <jsmart2021@gmail.com>
    Tested-by:  Muneendra Kumar M <muneendra.kumar@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14e3795597477f6b7919657511e4e8d41029b0d5
Author: Matthias May <matthias.may@westermo.com>
Date:   Fri Aug 5 21:00:06 2022 +0200

    geneve: fix TOS inheriting for ipv4
    
    commit b4ab94d6adaa5cf842b68bd28f4b50bc774496bd upstream.
    
    The current code retrieves the TOS field after the lookup
    on the ipv4 routing table. The routing process currently
    only allows routing based on the original 3 TOS bits, and
    not on the full 6 DSCP bits.
    As a result the retrieved TOS is cut to the 3 bits.
    However for inheriting purposes the full 6 bits should be used.
    
    Extract the full 6 bits before the route lookup and use
    that instead of the cut off 3 TOS bits.
    
    Fixes: e305ac6cf5a1 ("geneve: Add support to collect tunnel metadata.")
    Signed-off-by: Matthias May <matthias.may@westermo.com>
    Acked-by: Guillaume Nault <gnault@redhat.com>
    Link: https://lore.kernel.org/r/20220805190006.8078-1-matthias.may@westermo.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a369dc87b66acc85d0cffcf39984344a203e20b
Author: Jeff Layton <jlayton@kernel.org>
Date:   Fri Aug 5 06:42:45 2022 -0400

    fscache: don't leak cookie access refs if invalidation is in progress or failed
    
    commit fb24771faf72a2fd62b3b6287af3c610c3ec9cf1 upstream.
    
    It's possible for a request to invalidate a fscache_cookie will come in
    while we're already processing an invalidation. If that happens we
    currently take an extra access reference that will leak. Only call
    __fscache_begin_cookie_access if the FSCACHE_COOKIE_DO_INVALIDATE bit
    was previously clear.
    
    Also, ensure that we attempt to clear the bit when the cookie is
    "FAILED" and put the reference to avoid an access leak.
    
    Fixes: 85e4ea1049c7 ("fscache: Fix invalidation/lookup race")
    Suggested-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af412b252550f9ac36d9add7b013c2a2c3463835
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Fri Aug 5 15:00:08 2022 +0800

    atm: idt77252: fix use-after-free bugs caused by tst_timer
    
    commit 3f4093e2bf4673f218c0bf17d8362337c400e77b upstream.
    
    There are use-after-free bugs caused by tst_timer. The root cause
    is that there are no functions to stop tst_timer in idt77252_exit().
    One of the possible race conditions is shown below:
    
        (thread 1)          |        (thread 2)
                            |  idt77252_init_one
                            |    init_card
                            |      fill_tst
                            |        mod_timer(&card->tst_timer, ...)
    idt77252_exit           |  (wait a time)
                            |  tst_timer
                            |
                            |    ...
      kfree(card) // FREE   |
                            |    card->soft_tst[e] // USE
    
    The idt77252_dev is deallocated in idt77252_exit() and used in
    timer handler.
    
    This patch adds del_timer_sync() in idt77252_exit() in order that
    the timer handler could be stopped before the idt77252_dev is
    deallocated.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220805070008.18007-1-duoming@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a32429e10a949923548c9c12cb491815d0e5d79f
Author: Gerhard Engleder <gerhard@engleder-embedded.com>
Date:   Thu Aug 4 20:39:35 2022 +0200

    tsnep: Fix tsnep_tx_unmap() error path usage
    
    commit b3bb8628bf64440065976c71e4ab09186c393597 upstream.
    
    If tsnep_tx_map() fails, then tsnep_tx_unmap() shall start at the write
    index like tsnep_tx_map(). This is different to the normal operation.
    Thus, add an additional parameter to tsnep_tx_unmap() to enable start at
    different positions for successful TX and failed TX.
    
    Fixes: 403f69bbdbad ("tsnep: Add TSN endpoint Ethernet MAC driver")
    Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 970999be4cf3dc1d067e3badd681ad07170fcee2
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 4 10:11:33 2022 +0300

    xen/xenbus: fix return type in xenbus_file_read()
    
    commit 32ad11127b95236dfc52375f3707853194a7f4b4 upstream.
    
    This code tries to store -EFAULT in an unsigned int.  The
    xenbus_file_read() function returns type ssize_t so the negative value
    is returned as a positive value to the user.
    
    This change forces another change to the min() macro.  Originally, the
    min() macro used "unsigned" type which checkpatch complains about.  Also
    unsigned type would break if "len" were not capped at MAX_RW_COUNT.  Use
    size_t for the min().  (No effect on runtime for the min_t() change).
    
    Fixes: 2fb3683e7b16 ("xen: Add xenbus device driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
    Link: https://lore.kernel.org/r/YutxJUaUYRG/VLVc@kili
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc2f4da09ba023a850a6ba3959766a3bfc09e33f
Author: Yu Xiao <yu.xiao@corigine.com>
Date:   Tue Aug 2 10:33:55 2022 +0100

    nfp: ethtool: fix the display error of `ethtool -m DEVNAME`
    
    commit 4ae97cae07e15d41e5c0ebabba64c6eefdeb0bbe upstream.
    
    The port flag isn't set to `NFP_PORT_CHANGED` when using
    `ethtool -m DEVNAME` before, so the port state (e.g. interface)
    cannot be updated. Therefore, it caused that `ethtool -m DEVNAME`
    sometimes cannot read the correct information.
    
    E.g. `ethtool -m DEVNAME` cannot work when load driver before plug
    in optical module, as the port interface is still NONE without port
    update.
    
    Now update the port state before sending info to NIC to ensure that
    port interface is correct (latest state).
    
    Fixes: 61f7c6f44870 ("nfp: implement ethtool get module EEPROM")
    Reviewed-by: Louis Peens <louis.peens@corigine.com>
    Signed-off-by: Yu Xiao <yu.xiao@corigine.com>
    Signed-off-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/20220802093355.69065-1-simon.horman@corigine.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 776efefcaf804386843d85dca2e048f25c31ae55
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Jul 20 21:28:18 2022 +0300

    NTB: ntb_tool: uninitialized heap data in tool_fn_write()
    
    commit 45e1058b77feade4e36402828bfe3e0d3363177b upstream.
    
    The call to:
    
            ret = simple_write_to_buffer(buf, size, offp, ubuf, size);
    
    will return success if it is able to write even one byte to "buf".
    The value of "*offp" controls which byte.  This could result in
    reading uninitialized data when we do the sscanf() on the next line.
    
    This code is not really desigined to handle partial writes where
    *offp is non-zero and the "buf" is preserved and re-used between writes.
    Just ban partial writes and replace the simple_write_to_buffer() with
    copy_from_user().
    
    Fixes: 578b881ba9c4 ("NTB: Add tool test client")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jon Mason <jdmason@kudzu.us>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f60a0e33d311b5aab042f8a799e2dc45881584b
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Tue Jul 19 19:05:55 2022 +0200

    tools build: Switch to new openssl API for test-libcrypto
    
    commit 5b245985a6de5ac18b5088c37068816d413fb8ed upstream.
    
    Switch to new EVP API for detecting libcrypto, as Fedora 36 returns an
    error when it encounters the deprecated function MD5_Init() and the others.
    
    The error would be interpreted as missing libcrypto, while in reality it is
    not.
    
    Fixes: 6e8ccb4f624a73c5 ("tools/bpf: properly account for libbfd variations")
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Andrii Nakryiko <andrii@kernel.org>
    Cc: bpf@vger.kernel.org
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: John Fastabend <john.fastabend@gmail.com>
    Cc: KP Singh <kpsingh@kernel.org>
    Cc: llvm@lists.linux.dev
    Cc: Martin KaFai Lau <martin.lau@linux.dev>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Nick Terrell <terrelln@fb.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Quentin Monnet <quentin@isovalent.com>
    Cc: Song Liu <song@kernel.org>
    Cc: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/r/20220719170555.2576993-4-roberto.sassu@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7e676b7dc6a1c80a433899363a6ea81665e5491
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Mon Jul 11 14:09:23 2022 +0200

    kbuild: dummy-tools: avoid tmpdir leak in dummy gcc
    
    commit aac289653fa5adf9e9985e4912c1d24a3e8cbab2 upstream.
    
    When passed -print-file-name=plugin, the dummy gcc script creates a
    temporary directory that is never cleaned up. To avoid cluttering
    $TMPDIR, instead use a static directory included in the source tree.
    
    Fixes: 76426e238834 ("kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig")
    Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1347e13865af216e91f574ac2388c27f3312554
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Jun 22 01:00:45 2022 -0700

    tools/testing/cxl: Fix cxl_hdm_decode_init() calling convention
    
    commit 863fdccdc5ed1e187a30a4a103340be4569904c8 upstream.
    
    This failing signature:
    
    [    8.392669] cxl_bus_probe: cxl_port endpoint2: probe: 970997760
    [    8.392670] cxl_port: probe of endpoint2 failed with error 970997760
    [    8.392719] create_endpoint: cxl_mem mem0: add: endpoint2
    [    8.392721] cxl_mem mem0: endpoint2 failed probe
    [    8.392725] cxl_bus_probe: cxl_mem mem0: probe: -6
    
    ...shows cxl_hdm_decode_init() resulting in a return code ("970997760")
    that looks like stack corruption. The problem goes away if
    cxl_hdm_decode_init() is not mocked via __wrap_cxl_hdm_decode_init().
    
    The corruption results from the mismatch that the calling convention for
    cxl_hdm_decode_init() is:
    
    int cxl_hdm_decode_init(struct cxl_dev_state *cxlds, struct cxl_hdm *cxlhdm)
    
    ...and __wrap_cxl_hdm_decode_init() is:
    
    bool __wrap_cxl_hdm_decode_init(struct cxl_dev_state *cxlds, struct cxl_hdm *cxlhdm)
    
    ...i.e. an int is expected but __wrap_hdm_decode_init() returns bool.
    
    Fix the convention and cleanup the organization to match
    __wrap_cxl_await_media_ready() as the difference was a red herring that
    distracted from finding the bug.
    
    Fixes: 92804edb11f0 ("cxl/pci: Drop @info argument to cxl_hdm_decode_init()")
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Adam Manzanares <a.manzanares@samsung.com>
    Link: https://lore.kernel.org/r/165603870776.551046.8709990108936497723.stgit@dwillia2-xfh
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a291c7d289fac2cb13fb2614a9a251afbbd86ce9
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Tue Jun 21 17:13:23 2022 +0200

    vdpa_sim_blk: set number of address spaces and virtqueue groups
    
    commit 19cd4a5471b8eaa4bd161b0fdb4567f2fc88d809 upstream.
    
    Commit bda324fd037a ("vdpasim: control virtqueue support") added two
    new fields (nas, ngroups) to vdpasim_dev_attr, but we forgot to
    initialize them for vdpa_sim_blk.
    
    When creating a new vdpa_sim_blk device this causes the kernel
    to panic in this way:
        $ vdpa dev add mgmtdev vdpasim_blk name blk0
        BUG: kernel NULL pointer dereference, address: 0000000000000030
        ...
        RIP: 0010:vhost_iotlb_add_range_ctx+0x41/0x220 [vhost_iotlb]
        ...
        Call Trace:
         <TASK>
         vhost_iotlb_add_range+0x11/0x800 [vhost_iotlb]
         vdpasim_map_range+0x91/0xd0 [vdpa_sim]
         vdpasim_alloc_coherent+0x56/0x90 [vdpa_sim]
         ...
    
    This happens because vdpasim->iommu[0] is not initialized when
    dev_attr.nas is 0.
    
    Let's fix this issue by initializing both (nas, ngroups) to 1 for
    vdpa_sim_blk.
    
    Fixes: bda324fd037a ("vdpasim: control virtqueue support")
    Cc: gautam.dawar@xilinx.com
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Message-Id: <20220621151323.190431-1-sgarzare@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Eugenio Pérez <eperezma@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d5428b2940dc5fbefb80e7b633bd28ea97d36da
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Tue Jun 21 17:12:08 2022 +0200

    vdpa_sim: use max_iotlb_entries as a limit in vhost_iotlb_init
    
    commit 67f8f10c0bd78c4a0f0e983e050ab90da015323b upstream.
    
    Commit bda324fd037a ("vdpasim: control virtqueue support") changed
    the allocation of iotlbs calling vhost_iotlb_init() for each address
    space, instead of vhost_iotlb_alloc().
    
    With this change we forgot to use the limit we had introduced with
    the `max_iotlb_entries` module parameter.
    
    Fixes: bda324fd037a ("vdpasim: control virtqueue support")
    Cc: gautam.dawar@xilinx.com
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Message-Id: <20220621151208.189959-1-sgarzare@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Eugenio Pérez <eperezma@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 358781831c109ded676a092afe4f085383d78030
Author: Jacky Bai <ping.bai@nxp.com>
Date:   Thu Jun 9 21:28:58 2022 +0800

    clk: imx93: Correct the edma1's parent clock
    
    commit ebb4f1eb9360036be5ea70de82c5703ca0e64d43 upstream.
    
    For EDMA1 in AONMIX, its parent clock should be from cm33_root,
    so Correct it.
    
    Fixes: 24defbe194b65("clk: imx: add i.MX93 clk")
    Signed-off-by: Jacky Bai <ping.bai@nxp.com>
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20220609132902.3504651-4-peng.fan@oss.nxp.com
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a090cc69699ec2d11b5e34cee8c61f0d4b0068cb
Author: Jeff Layton <jlayton@kernel.org>
Date:   Fri Jun 3 16:39:57 2022 -0400

    ceph: don't leak snap_rwsem in handle_cap_grant
    
    commit 58dd4385577ed7969b80cdc9e2a31575aba6c712 upstream.
    
    When handle_cap_grant is called on an IMPORT op, then the snap_rwsem is
    held and the function is expected to release it before returning. It
    currently fails to do that in all cases which could lead to a deadlock.
    
    Fixes: 6f05b30ea063 ("ceph: reset i_requested_max_size if file write is not wanted")
    Link: https://tracker.ceph.com/issues/55857
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Luís Henriques <lhenriques@suse.de>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 279b52d7541ce17bfc66542dd9cb988ad8d8ac4c
Author: Yuanzheng Song <songyuanzheng@huawei.com>
Date:   Sat May 28 06:31:17 2022 +0000

    tools/vm/slabinfo: use alphabetic order when two values are equal
    
    commit 4f5ceb8851f0081af54313abbf56de1615911faf upstream.
    
    When the number of partial slabs in each cache is the same (e.g., the
    value are 0), the results of the `slabinfo -X -N5` and `slabinfo -P -N5`
    are different.
    
    / # slabinfo -X -N5
    ...
    Slabs sorted by number of partial slabs
    ---------------------------------------
    Name                   Objects Objsize           Space Slabs/Part/Cpu  O/S O %Fr %Ef Flg
    inode_cache              15180     392         6217728        758/0/1   20 1   0  95 a
    kernfs_node_cache        22494      88         2002944        488/0/1   46 0   0  98
    shmem_inode_cache          663     464          319488         38/0/1   17 1   0  96
    biovec-max                  50    3072          163840          4/0/1   10 3   0  93 A
    dentry                   19050     136         2600960        633/0/2   30 0   0  99 a
    
    / # slabinfo -P -N5
    Name                   Objects Objsize           Space Slabs/Part/Cpu  O/S O %Fr %Ef Flg
    bdev_cache                  32     984           32.7K          1/0/1   16 2   0  96 Aa
    ext4_inode_cache            42     752           32.7K          1/0/1   21 2   0  96 a
    dentry                   19050     136            2.6M        633/0/2   30 0   0  99 a
    TCPv6                       17    1840           32.7K          0/0/1   17 3   0  95 A
    RAWv6                       18     856           16.3K          0/0/1   18 2   0  94 A
    
    This problem is caused by the sort_slabs().  So let's use alphabetic order
    when two values are equal in the sort_slabs().
    
    By the way, the content of the `slabinfo -h` is not aligned because the
    
    `-P|--partial Sort by number of partial slabs`
    
    uses tabs instead of spaces.  So let's use spaces instead of tabs to fix
    it.
    
    Link: https://lkml.kernel.org/r/20220528063117.935158-1-songyuanzheng@huawei.com
    Fixes: 1106b205a3fe ("tools/vm/slabinfo: add partial slab listing to -X")
    Signed-off-by: Yuanzheng Song <songyuanzheng@huawei.com>
    Cc: "Tobin C. Harding" <tobin@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14d9cf9852f881924f8790ae429b11b2f1d0a0a2
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue May 24 10:48:59 2022 -0700

    tools/testing/cxl: Fix decoder default state
    
    commit 08f8d040a11d539481b9aee7b482430561281a28 upstream.
    
    The 'enabled' state is reserved for committed decoders. By default,
    cxl_test decoders are uncommitted at init time.
    
    Fixes: 7c7d68db0254 ("tools/testing/cxl: Enumerate mock decoders")
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/165603888091.551046.6312322707378021172.stgit@dwillia2-xfh
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52f636e1904cda95cba094cf5e72f11ef4e96196
Author: Luís Henriques <lhenriques@suse.de>
Date:   Tue May 24 17:06:27 2022 +0100

    ceph: use correct index when encoding client supported features
    
    commit fea013e020e6ecc7be75bea0d61697b7e916b44d upstream.
    
    Feature bits have to be encoded into the correct locations.  This hasn't
    been an issue so far because the only hole in the feature bits was in bit
    10 (CEPHFS_FEATURE_RECLAIM_CLIENT), which is located in the 2nd byte.  When
    adding more bits that go beyond the this 2nd byte, the bug will show up.
    
    [xiubli: remove incorrect comment for CEPHFS_FEATURES_CLIENT_SUPPORTED]
    
    Fixes: 9ba1e224538a ("ceph: allocate the correct amount of extra bytes for the session features")
    Signed-off-by: Luís Henriques <lhenriques@suse.de>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c969b0537daca25f1e9a69b00caae6c3aca01a17
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Jul 20 18:38:41 2022 +0200

    spi: dt-bindings: qcom,spi-geni-qcom: allow three interconnects
    
    commit ee912312db5a5e877120b9f519a034fc34315c9b upstream.
    
    Recent Qualcomm Geni SPI nodes, e.g. on SM8450, come also with three
    interconnects.  This fixes dtbs_check warnings like:
    
      sm8450-qrd.dtb: spi@a98000: interconnects: [[46, 1, 0, 46, 4, 0], [47, 2, 0, 48, 12, 0], [49, 1, 0, 50, 1, 0]] is too long
      sm8450-qrd.dtb: spi@a98000: interconnect-names: ['qup-core', 'qup-config', 'qup-memory'] is too long
    
    Fixes: 5bdcae1fe1c5 ("spi: dt-bindings: qcom,spi-geni-qcom: convert to dtschema")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220720163841.7283-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3be10a1426b0f574c462d003f00ebbda06233bee
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Fri Jul 8 13:11:54 2022 +0100

    dt-bindings: opp: opp-v2-kryo-cpu: Fix example binding checks
    
    commit 3b4916a6e422394aa129fe9b204f4d489ae484a6 upstream.
    
    Adding missing compat entries to the cpufreq node
    Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml shows up
    a dt_binding_check in this file.
    
    opp-v2-kryo-cpu.example.dtb: /: cpus:cpu@0: 'power-domains' is a required property
    opp-v2-kryo-cpu.example.dtb: /: cpus:cpu@0: 'power-domain-names' is a required property
    opp-v2-kryo-cpu.example.dtb: /: opp-table-0:opp-307200000: 'required-opps' is a required property
    
    Fixes: ec24d1d55469 ("dt-bindings: opp: Convert qcom-nvmem-cpufreq to DT schema")
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f32e6d5c94adc215960bde36ae262a11ede0028a
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Jul 4 15:06:18 2022 +0200

    spi: dt-bindings: zynqmp-qspi: add missing 'required'
    
    commit acfc34f008c3e66bbcb7b9162c80c8327b6e800f upstream.
    
    During the conversion the bindings lost list of required properties.
    
    Fixes: c58db2abb19f ("spi: convert Xilinx Zynq UltraScale+ MPSoC GQSPI bindings to YAML")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Michal Simek <michal.simek@amd.com>
    Link: https://lore.kernel.org/r/20220704130618.199231-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ec9bbdd28b57b2b6b2a0c260b2b46753c888c27
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Jul 4 15:06:17 2022 +0200

    spi: dt-bindings: cadence: add missing 'required'
    
    commit 6eee27c598fde65988723b785a9c9192d5ffb93a upstream.
    
    During the conversion the bindings lost list of required properties.
    
    Fixes: aa7968682a2b ("spi: convert Cadence SPI bindings to YAML")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Michal Simek <michal.simek@amd.com>
    Link: https://lore.kernel.org/r/20220704130618.199231-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50416c20c243e0bfc9475c6c117c3c55b36fce17
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed Jun 29 16:09:51 2022 +0200

    dt-bindings: PCI: qcom: Fix reset conditional
    
    commit 839fbdee4c080eb95567cbcf6366072a56d3a3cc upstream.
    
    Fix the reset conditional which always evaluated to true due to a
    misspelled property name ("compatibles" in plural).
    
    Fixes: 6700a9b00f0a ("dt-bindings: PCI: qcom: Do not require resets on msm8996 platforms")
    Link: https://lore.kernel.org/r/20220629141000.18111-2-johan+linaro@kernel.org
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e0513e565f70c06bbd7e1ef427523e37960d2c7a
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Mon Jun 20 10:19:33 2022 +0300

    dt-bindings: clock: qcom,gcc-msm8996: add more GCC clock sources
    
    commit 2b4e75a7a7c8d3531a40ebb103b92f88ff693f79 upstream.
    
    Add additional GCC clock sources. This includes PCIe and USB PIPE and
    UFS symbol clocks.
    
    Fixes: 2a8aa18c1131 ("dt-bindings: clk: qcom: Fix self-validation, split, and clean cruft")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220620071936.1558906-2-dmitry.baryshkov@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5476edddbb50951b8b1ce4a82231089c003aa6c9
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri May 20 14:32:47 2022 +0200

    dt-bindings: arm: qcom: fix MSM8994 boards compatibles
    
    commit c704bd373f58a84193eebe40bd271d6b73c138b0 upstream.
    
    The compatibles for APQ8094/MSM8994 boards are different than specified
    in bindings.  None of them use fallback to other SoC variant.
    
    Fixes: 9ad3c08f6f1b ("dt-bindings: arm: qcom: Document sony boards for apq8094")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220520123252.365762-4-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23c3019a432cce452d21d7dbf44df43b80377c82
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri May 20 14:32:46 2022 +0200

    dt-bindings: arm: qcom: fix MSM8916 MTP compatibles
    
    commit bb35fe1efbae4114bd288fae0f56070f563adcfc upstream.
    
    The order of compatibles for MSM8916 MTP board is different:
    
      msm8916-mtp.dtb: /: compatible: 'oneOf' conditional failed, one must be fixed:
        ['qcom,msm8916-mtp', 'qcom,msm8916-mtp/1', 'qcom,msm8916'] is too long
    
    Fixes: 9d3ef77fe568 ("dt-bindings: arm: Convert QCom board/soc bindings to json-schema")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220520123252.365762-3-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a33e50a147830e9739e7cb00a5afe2da1c27027
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri May 20 14:32:45 2022 +0200

    dt-bindings: arm: qcom: fix Longcheer L8150 compatibles
    
    commit 25d203d0751ca191301bc578ba5d59fa401f1fbf upstream.
    
    The MSM8916 Longcheer L8150 uses a fallback in compatible:
    
      msm8916-longcheer-l8150.dtb: /: compatible: 'oneOf' conditional failed, one must be fixed:
        ['longcheer,l8150', 'qcom,msm8916-v1-qrd/9-v1', 'qcom,msm8916'] is too long
    
    Fixes: b72160fa886d ("dt-bindings: qcom: Document bindings for new MSM8916 devices")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
    Link: https://lore.kernel.org/r/20220520123252.365762-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7950545bbf1d79d42368d85169d8a74b5ed6e6ab
Author: Michal Simek <michal.simek@xilinx.com>
Date:   Thu Oct 14 12:14:18 2021 +0200

    dt-bindings: gpio: zynq: Add missing compatible strings
    
    commit 7668048e5c697a9493ffc0e6001c322b2efe90ae upstream.
    
    "xlnx,zynqmp-gpio-1.0", "xlnx,versal-gpio-1.0" and "xlnx,pmc-gpio-1.0"
    compatible strings were not moved to yaml format. But they were in origin
    text file.
    
    Fixes: 45ca16072b70 ("dt-bindings: gpio: zynq: convert bindings to YAML")
    Signed-off-by: Michal Simek <michal.simek@xilinx.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/72c973da5670b5ae81d050c582948894ee4174f8.1634206453.git.michal.simek@xilinx.com
    Signed-off-by: Michal Simek <michal.simek@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6401143e6800a7e4b8f9c14a81334f0dbaa37599
Author: Peilin Ye <peilin.ye@bytedance.com>
Date:   Mon Aug 8 11:05:25 2022 -0700

    vsock: Set socket state back to SS_UNCONNECTED in vsock_connect_timeout()
    
    commit a3e7b29e30854ed67be0d17687e744ad0c769c4b upstream.
    
    Imagine two non-blocking vsock_connect() requests on the same socket.
    The first request schedules @connect_work, and after it times out,
    vsock_connect_timeout() sets *sock* state back to TCP_CLOSE, but keeps
    *socket* state as SS_CONNECTING.
    
    Later, the second request returns -EALREADY, meaning the socket "already
    has a pending connection in progress", even though the first request has
    already timed out.
    
    As suggested by Stefano, fix it by setting *socket* state back to
    SS_UNCONNECTED, so that the second request will return -ETIMEDOUT.
    
    Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ff5db3c1b3d6797eda5cd326dcd31b9cd1c5f72
Author: Peilin Ye <peilin.ye@bytedance.com>
Date:   Mon Aug 8 11:04:47 2022 -0700

    vsock: Fix memory leak in vsock_connect()
    
    commit 7e97cfed9929eaabc41829c395eb0d1350fccb9d upstream.
    
    An O_NONBLOCK vsock_connect() request may try to reschedule
    @connect_work.  Imagine the following sequence of vsock_connect()
    requests:
    
      1. The 1st, non-blocking request schedules @connect_work, which will
         expire after 200 jiffies.  Socket state is now SS_CONNECTING;
    
      2. Later, the 2nd, blocking request gets interrupted by a signal after
         a few jiffies while waiting for the connection to be established.
         Socket state is back to SS_UNCONNECTED, but @connect_work is still
         pending, and will expire after 100 jiffies.
    
      3. Now, the 3rd, non-blocking request tries to schedule @connect_work
         again.  Since @connect_work is already scheduled,
         schedule_delayed_work() silently returns.  sock_hold() is called
         twice, but sock_put() will only be called once in
         vsock_connect_timeout(), causing a memory leak reported by syzbot:
    
      BUG: memory leak
      unreferenced object 0xffff88810ea56a40 (size 1232):
        comm "syz-executor756", pid 3604, jiffies 4294947681 (age 12.350s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          28 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  (..@............
        backtrace:
          [<ffffffff837c830e>] sk_prot_alloc+0x3e/0x1b0 net/core/sock.c:1930
          [<ffffffff837cbe22>] sk_alloc+0x32/0x2e0 net/core/sock.c:1989
          [<ffffffff842ccf68>] __vsock_create.constprop.0+0x38/0x320 net/vmw_vsock/af_vsock.c:734
          [<ffffffff842ce8f1>] vsock_create+0xc1/0x2d0 net/vmw_vsock/af_vsock.c:2203
          [<ffffffff837c0cbb>] __sock_create+0x1ab/0x2b0 net/socket.c:1468
          [<ffffffff837c3acf>] sock_create net/socket.c:1519 [inline]
          [<ffffffff837c3acf>] __sys_socket+0x6f/0x140 net/socket.c:1561
          [<ffffffff837c3bba>] __do_sys_socket net/socket.c:1570 [inline]
          [<ffffffff837c3bba>] __se_sys_socket net/socket.c:1568 [inline]
          [<ffffffff837c3bba>] __x64_sys_socket+0x1a/0x20 net/socket.c:1568
          [<ffffffff84512815>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
          [<ffffffff84512815>] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:80
          [<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
      <...>
    
    Use mod_delayed_work() instead: if @connect_work is already scheduled,
    reschedule it, and undo sock_hold() to keep the reference count
    balanced.
    
    Reported-and-tested-by: syzbot+b03f55bf128f9a38f064@syzkaller.appspotmail.com
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Co-developed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3ea09259eb27276db7d2f0d566598b6dba34593
Author: Florian Westphal <fw@strlen.de>
Date:   Sun Aug 7 13:53:04 2022 +0200

    plip: avoid rcu debug splat
    
    commit bc3c8fe3c79bcdae4d90e3726054fac5cca8ac32 upstream.
    
    WARNING: suspicious RCU usage
    5.2.0-rc2-00605-g2638eb8b50cfc #1 Not tainted
    drivers/net/plip/plip.c:1110 suspicious rcu_dereference_check() usage!
    
    plip_open is called with RTNL held, switch to the correct helper.
    
    Fixes: 2638eb8b50cf ("net: ipv4: provide __rcu annotation for ifa_list")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Link: https://lore.kernel.org/r/20220807115304.13257-1-fw@strlen.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f427e275cd5bc7410ce35e25307988f0ceba298
Author: Matthias May <matthias.may@westermo.com>
Date:   Fri Aug 5 21:19:06 2022 +0200

    ipv6: do not use RT_TOS for IPv6 flowlabel
    
    commit ab7e2e0dfa5d37540ab1dc5376e9a2cb9188925d upstream.
    
    According to Guillaume Nault RT_TOS should never be used for IPv6.
    
    Quote:
    RT_TOS() is an old macro used to interprete IPv4 TOS as described in
    the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4
    code, although, given the current state of the code, most of the
    existing calls have no consequence.
    
    But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS"
    field to be interpreted the RFC 1349 way. There's no historical
    compatibility to worry about.
    
    Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
    Acked-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: Matthias May <matthias.may@westermo.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 923c65b5adf9045914ecde273c2a3d6dc0d314e2
Author: Matthias May <matthias.may@westermo.com>
Date:   Fri Aug 5 21:19:05 2022 +0200

    mlx5: do not use RT_TOS for IPv6 flowlabel
    
    commit bcb0da7fffee9464073998b267ce5543da2356d2 upstream.
    
    According to Guillaume Nault RT_TOS should never be used for IPv6.
    
    Quote:
    RT_TOS() is an old macro used to interprete IPv4 TOS as described in
    the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4
    code, although, given the current state of the code, most of the
    existing calls have no consequence.
    
    But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS"
    field to be interpreted the RFC 1349 way. There's no historical
    compatibility to worry about.
    
    Fixes: ce99f6b97fcd ("net/mlx5e: Support SRIOV TC encapsulation offloads for IPv6 tunnels")
    Acked-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: Matthias May <matthias.may@westermo.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fa0d54bd693b8a903935db71affc76e1f9f6cbf
Author: Matthias May <matthias.may@westermo.com>
Date:   Fri Aug 5 21:19:04 2022 +0200

    vxlan: do not use RT_TOS for IPv6 flowlabel
    
    commit e488d4f5d6e4cd1e728ba4ddbdcd7ef5f4d13a21 upstream.
    
    According to Guillaume Nault RT_TOS should never be used for IPv6.
    
    Quote:
    RT_TOS() is an old macro used to interprete IPv4 TOS as described in
    the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4
    code, although, given the current state of the code, most of the
    existing calls have no consequence.
    
    But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS"
    field to be interpreted the RFC 1349 way. There's no historical
    compatibility to worry about.
    
    Fixes: 1400615d64cf ("vxlan: allow setting ipv6 traffic class")
    Acked-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: Matthias May <matthias.may@westermo.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13904ed832a912fa8b4f69ab9cbffcbb035a0bc3
Author: Matthias May <matthias.may@westermo.com>
Date:   Fri Aug 5 21:19:03 2022 +0200

    geneve: do not use RT_TOS for IPv6 flowlabel
    
    commit ca2bb69514a8bc7f83914122f0d596371352416c upstream.
    
    According to Guillaume Nault RT_TOS should never be used for IPv6.
    
    Quote:
    RT_TOS() is an old macro used to interprete IPv4 TOS as described in
    the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4
    code, although, given the current state of the code, most of the
    existing calls have no consequence.
    
    But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS"
    field to be interpreted the RFC 1349 way. There's no historical
    compatibility to worry about.
    
    Fixes: 3a56f86f1be6 ("geneve: handle ipv6 priority like ipv4 tos")
    Acked-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: Matthias May <matthias.may@westermo.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29fea5c51a5cf7d7babd7a81fd17f64359d6a06d
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Mon Jul 11 14:25:59 2022 +0300

    ACPI: property: Return type of acpi_add_nondev_subnodes() should be bool
    
    commit 85140ef275f577f64e8a2c5789447222dfc14fc4 upstream.
    
    The value acpi_add_nondev_subnodes() returns is bool so change the return
    type of the function to match that.
    
    Fixes: 445b0eb058f5 ("ACPI / property: Add support for data-only subnodes")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8af1ddc42a7191880b1b2af24089a73c7548918
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date:   Wed Aug 3 13:24:15 2022 +0530

    octeontx2-af: Fix key checking for source mac
    
    commit c3c290276927a3ae79342a4e17ec0500c138c63a upstream.
    
    Given a field with its location/offset in input packet,
    the key checking logic verifies whether extracting the
    field can be supported or not based on the mkex profile
    loaded in hardware. This logic is wrong wrt source mac
    and this patch fixes that.
    
    Fixes: 9b179a960a96 ("octeontx2-af: Generate key field bit mask from KEX profile")
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc32347f48111eea8d0165538c92aca92ede83f6
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date:   Wed Aug 3 13:24:14 2022 +0530

    octeontx2-af: Fix mcam entry resource leak
    
    commit 3f8fe40ab7730cf8eb6f8b8ff412012f7f6f8f48 upstream.
    
    The teardown sequence in FLR handler returns if no NIX LF
    is attached to PF/VF because it indicates that graceful
    shutdown of resources already happened. But there is a
    chance of all allocated MCAM entries not being freed by
    PF/VF. Hence free mcam entries even in case of detached LF.
    
    Fixes: c554f9c1574e ("octeontx2-af: Teardown NPA, NIX LF upon receiving FLR")
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df1c025e383495904e2e1457b112f918d095a3bb
Author: Harman Kalra <hkalra@marvell.com>
Date:   Wed Aug 3 13:24:13 2022 +0530

    octeontx2-af: suppress external profile loading warning
    
    commit cf2437626502b5271d19686b03dea306efe17ea0 upstream.
    
    The packet parser profile supplied as firmware may not
    be present all the time and default profile is used mostly.
    Hence suppress firmware loading warning from kernel due to
    absence of firmware in kernel image.
    
    Fixes: 3a7244152f9c ("octeontx2-af: add support for custom KPU entries")
    Signed-off-by: Harman Kalra <hkalra@marvell.com>
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c28ff6c1444965e8cc7e7466c4120d49b5550da5
Author: Stanislaw Kardach <skardach@marvell.com>
Date:   Wed Aug 3 13:24:12 2022 +0530

    octeontx2-af: Apply tx nibble fixup always
    
    commit dd1d1a8a6b29b6b472fd0d449b29eb806c411dd2 upstream.
    
    NPC_PARSE_NIBBLE for TX interface has to be equal to the RX one for some
    silicon revisions. Mistakenly this fixup was only applied to the default
    MKEX profile while it should also be applied to any loaded profile.
    
    Fixes: 1c1935c9945d ("octeontx2-af: Add NIX1 interfaces to NPC")
    Signed-off-by: Stanislaw Kardach <skardach@marvell.com>
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a7fdd85eef5565101a00dfbe1cbf069d2c149bde
Author: Naveen Mamindlapalli <naveenm@marvell.com>
Date:   Tue Aug 2 19:58:13 2022 +0530

    octeontx2-pf: Fix NIX_AF_TL3_TL2X_LINKX_CFG register configuration
    
    commit 13c9f4dc102f2856e80b92486c41841e25e23772 upstream.
    
    For packets scheduled to RPM and LBK, NIX_AF_PSE_CHANNEL_LEVEL[BP_LEVEL]
    selects the TL3 or TL2 scheduling level as the one used for link/channel
    selection and backpressure. For each scheduling queue at the selected
    level: Setting NIX_AF_TL3_TL2(0..255)_LINK(0..12)_CFG[ENA] = 1 allows
    the TL3/TL2 queue to schedule packets to a specified RPM or LBK link
    and channel.
    
    There is an issue in the code where NIX_AF_PSE_CHANNEL_LEVEL[BP_LEVEL]
    is set to TL3 where as the NIX_AF_TL3_TL2(0..255)_LINK(0..12)_CFG is
    configured for TL2 queue in some cases. As a result packets will not
    transmit on that link/channel. This patch fixes the issue by configuring
    the NIX_AF_TL3_TL2(0..255)_LINK(0..12)_CFG register depending on the
    NIX_AF_PSE_CHANNEL_LEVEL[BP_LEVEL] value.
    
    Fixes: caa2da34fd25a ("octeontx2-pf: Initialize and config queues")
    Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
    Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
    Link: https://lore.kernel.org/r/20220802142813.25031-1-naveenm@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 342682efc6904b0823af2de3f814f639adb8b9e2
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Mon Jun 27 15:16:15 2022 -0700

    dt-bindings: input: iqs7222: Extend slider-mapped GPIO to IQS7222C
    
    commit f0ea452715d72bc365d2b401ceb458f5ae82eeec upstream.
    
    Although the IQS7222C does not offer slider gesture support, the
    press/release event can still be mapped to any of the IQS7222C's
    three GPIO pins. Update the binding to reflect this relationship.
    
    Fixes: 44dc42d254bf ("dt-bindings: input: Add bindings for Azoteq IQS7222A/B/C")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Link: https://lore.kernel.org/r/20220626072412.475211-10-jeff@labundy.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94683976b16c4e1f3ff1d3a36ec6a8c7dec88446
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Mon Jun 27 15:16:00 2022 -0700

    dt-bindings: input: iqs7222: Correct bottom speed step size
    
    commit 6cfb357851bd3ef0a48e14bccfb5ca6b8104ea61 upstream.
    
    The bottom speed property is specified in steps of 1, not 4.
    
    Fixes: 44dc42d254bf ("dt-bindings: input: Add bindings for Azoteq IQS7222A/B/C")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Link: https://lore.kernel.org/r/20220626072412.475211-9-jeff@labundy.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90857411e91e443a9b4e6a81c64c108ceb259a8f
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Mon Jun 27 15:15:46 2022 -0700

    dt-bindings: input: iqs7222: Remove support for RF filter
    
    commit f5d2c1ed72c26152e6883ed67dc3004a39165098 upstream.
    
    The vendor has marked the RF filter enable control as reserved in
    the datasheet; remove it from the binding.
    
    Fixes: 44dc42d254bf ("dt-bindings: input: Add bindings for Azoteq IQS7222A/B/C")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Link: https://lore.kernel.org/r/20220626072412.475211-8-jeff@labundy.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 179331884af66c80db881eea41247b28884bcabb
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Mon Jun 27 15:15:25 2022 -0700

    Input: iqs7222 - remove support for RF filter
    
    commit 381932cf61d52bde656c8596c0cb8f46bed53dc0 upstream.
    
    The vendor has marked the RF filter enable control as reserved in
    the datasheet; remove it from the driver.
    
    Fixes: e505edaedcb9 ("Input: add support for Azoteq IQS7222A/B/C")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Link: https://lore.kernel.org/r/20220626072412.475211-7-jeff@labundy.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5384b932e259a621e880076a4e963bc683f03a77
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Mon Jun 27 15:15:09 2022 -0700

    Input: iqs7222 - handle reset during ATI
    
    commit 8635c68891c6d786d644747d599c41bdf512fbbf upstream.
    
    If the device suffers a spurious reset during ATI, there is no point
    in enduring any further retries. Instead, simply return successfully
    from the polling loop.
    
    In this case, the interrupt handler will intervene and recognize the
    device has been reset. It then proceeds to initialize the device and
    trigger ATI once more.
    
    As part of this change, swap the order of status field evaluation to
    match that of the interrupt handler, and correct a nearby off-by-one
    error that causes an error message to suggest the final attempt will
    be retried.
    
    Fixes: e505edaedcb9 ("Input: add support for Azoteq IQS7222A/B/C")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Link: https://lore.kernel.org/r/20220626072412.475211-6-jeff@labundy.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2aa156cbc4bdd824b5de411fb8df506226910f64
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Mon Jun 27 15:14:42 2022 -0700

    Input: iqs7222 - acknowledge reset before writing registers
    
    commit 2e70ef525b7309287b2d4dd24e7c9c038a006328 upstream.
    
    If the device suffers a spurious reset while reacting to a previous
    spurious reset, the second reset interrupt is preempted because the
    ACK_RESET bit is written last.
    
    To solve this problem, write the ACK_RESET bit prior to writing any
    other registers. This ensures that any registers written before the
    second spurious reset will be rewritten.
    
    Last but not least, the order in which the ACK_RESET bit is written
    relative to the second filter beta register is important for select
    variants of silicon. Enforce the correct order so as to not clobber
    the system status register.
    
    Fixes: e505edaedcb9 ("Input: add support for Azoteq IQS7222A/B/C")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Link: https://lore.kernel.org/r/20220626072412.475211-5-jeff@labundy.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d45f72dcb766fe239c4619fc50a2bbc379aafca
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Mon Jun 27 15:14:23 2022 -0700

    Input: iqs7222 - protect volatile registers
    
    commit 1e4189d8af2749e2db406f92bdc4abccbab63138 upstream.
    
    Select variants of silicon silently mirror part of the event mask
    register to the system setup register (0xD0), and vice versa. For
    the following sequence:
    
    1. Read registers 0xD0 onward and store their contents.
    2. Modify the contents, including event mask fields.
    3. Write registers 0xD0 onward with the modified contents.
    4. Write register 0xD0 on its own again later, using the contents
       from step 1 to populate any reserved fields.
    
    ...the event mask register (e.g. address 0xDA) has been corrupted
    by writing register 0xD0 with contents that were made stale after
    step 3.
    
    To solve this problem, read register 0xD0 once more between steps
    3 and 4. When register 0xD0 is written during step 4, the portion
    which is mirrored to the event mask register already matches what
    was written in step 3.
    
    Fixes: e505edaedcb9 ("Input: add support for Azoteq IQS7222A/B/C")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Link: https://lore.kernel.org/r/20220626072412.475211-4-jeff@labundy.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d5f2539375f8ab6fe066c5621935caaa9ea5340
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Mon Jun 27 15:14:04 2022 -0700

    Input: iqs7222 - fortify slider event reporting
    
    commit 95215d3d19c5b47b8ccef8cb61c9dcd17ac7a669 upstream.
    
    The release cycle of any key mapped to a slider gesture relies upon
    trailing interrupts generated by other unmasked sources, the timing
    and presence of which are inconsistent.
    
    To solve this problem, explicitly report a release cycle to emulate
    a full keystroke. Also, unmask touch interrupts if the slider press
    event is defined; this ensures the device reports a final interrupt
    with coordinate = 0xFFFF once the finger is lifted.
    
    As a result of how the logic has been refactored, the press/release
    event can now be mapped to a GPIO. This is more convenient than the
    previous solution, which required each channel within the slider to
    specify the same GPIO.
    
    As part of this change, use the device's resolution rather than its
    number of interrupt status registers to more safely determine if it
    is capable of reporting gestures.
    
    Last but not least, make the code a bit simpler by eliminating some
    unnecessarily complex conditional statements and a macro that could
    be derived using information that is already available.
    
    Fixes: e505edaedcb9 ("Input: add support for Azoteq IQS7222A/B/C")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Link: https://lore.kernel.org/r/20220626072412.475211-3-jeff@labundy.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa7ab02564ba23680991a0b751983a9097608829
Author: Jeff LaBundy <jeff@labundy.com>
Date:   Mon Jun 27 15:13:49 2022 -0700

    Input: iqs7222 - correct slider event disable logic
    
    commit 56a0c54c4c2bdb6c0952de90dd690020a703b50e upstream.
    
    If a positive swipe/flick gesture is defined but the corresponding
    negative gesture is not, the former is inadvertently disabled. Fix
    this by gently refactoring the logic responsible for disabling all
    gestures by default.
    
    As part of this change, make the code a bit simpler by eliminating
    a superfluous conditional check. If a slider event does not define
    an enable control, the second term of the bitwise AND operation is
    simply 0xFFFF.
    
    Fixes: e505edaedcb9 ("Input: add support for Azoteq IQS7222A/B/C")
    Signed-off-by: Jeff LaBundy <jeff@labundy.com>
    Link: https://lore.kernel.org/r/20220626072412.475211-2-jeff@labundy.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1e2d6c849c178f605e7e334ee4f45c24f3dfed2
Author: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Date:   Fri Jul 8 14:57:31 2022 -0700

    Input: mt6779-keypad - match hardware matrix organization
    
    commit d6ed52583034f9d2e39dead7c18e03380fd4edf2 upstream.
    
    The MediaTek keypad has a set of bits representing keys,
    from KEY0 to KEY77, arranged in 5 chunks of 15 bits split into 5 32-bit
    registers.
    
    In our implementation, we simply decided to use register number as row
    and offset in the register as column when encoding our "matrix".
    
    Because of this, we can have a 5x32 matrix which does not match the
    hardware at all, which is confusing.
    
    Change the row/column calculation to match the hardware.
    
    Fixes: f28af984e771 ("Input: mt6779-keypad - add MediaTek keypad driver")
    Co-developed-by: Fabien Parent <fparent@baylibre.com>
    Signed-off-by: Fabien Parent <fparent@baylibre.com>
    Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
    Link: https://lore.kernel.org/r/20220707075236.126631-2-mkorpershoek@baylibre.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 478b58ac0bb01318f155db5e02e39441e661131f
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Jun 28 22:42:35 2022 -0700

    Input: exc3000 - fix return value check of wait_for_completion_timeout
    
    commit 6bb7144c3fa16a5efb54a8e2aff1817b4168018e upstream.
    
    wait_for_completion_timeout() returns unsigned long not int.
    It returns 0 if timed out, and positive if completed.
    The check for <= 0 is ambiguous and should be == 0 here
    indicating timeout which is the only error case.
    
    Fixes: 102feb1ddfd0 ("Input: exc3000 - factor out vendor data request")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220411105828.22140-1-linmq006@gmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d35d9269dd0ec322ea274fef1888afcb123475c9
Author: Zeng Jingxiang <linuszeng@tencent.com>
Date:   Thu Jul 28 18:01:01 2022 +0800

    rtc: spear: set range max
    
    commit 03c4cd6f89e074a51e289eb9129ac646f0f2bd29 upstream.
    
    In the commit f395e1d3b28d7c2c67b73bd467c4fb79523e1c65
    ("rtc: spear: set range"), the value of
    RTC_TIMESTAMP_END_9999 was incorrectly set to range_min.
    390     config->rtc->range_min = RTC_TIMESTAMP_BEGIN_0000;
    391     config->rtc->range_max = RTC_TIMESTAMP_END_9999;
    
    Fixes: f395e1d3b28d ("rtc: spear: set range")
    Signed-off-by: Zeng Jingxiang <linuszeng@tencent.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20220728100101.1906801-1-zengjx95@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51f58c8042c717438154fc288e12db1da6d3774e
Author: Jianhua Lu <lujianhua000@gmail.com>
Date:   Wed Aug 3 09:56:45 2022 +0800

    pinctrl: qcom: sm8250: Fix PDC map
    
    commit 4b759ca15a4914f96ea204ea9200ceeb01d70666 upstream.
    
    Fix the PDC mapping for SM8250, gpio39 is mapped to irq73(not irq37).
    
    Fixes: b41efeed507a("pinctrl: qcom: sm8250: Specify PDC map.")
    Signed-off-by: Jianhua Lu <lujianhua000@gmail.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Link: https://lore.kernel.org/r/20220803015645.22388-1-lujianhua000@gmail.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80a98362e6c69f70d96aa798716d7ed3caac0aff
Author: Allen-KH Cheng <allen-kh.cheng@mediatek.com>
Date:   Mon Jul 25 19:07:02 2022 +0800

    dt-bindings: pinctrl: mt8186: Add and use drive-strength-microamp
    
    commit f4526ae80dbdef7078ab2aae30dfc70bbc0098c6 upstream.
    
    Commit e5fabbe43f3f ("pinctrl: mediatek: paris: Support generic
    PIN_CONFIG_DRIVE_STRENGTH_UA") added support for using
    drive-strength-microamp instead of mediatek,drive-strength-adv.
    
    Similarly to the mt8192 and mt8195, there's no user of property
    'mediatek,drive-strength-adv', hence removing it is safe.
    
    Fixes: 338e953f1bd1 ("dt-bindings: pinctrl: mt8186: add pinctrl file and binding document")
    Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220725110702.11362-3-allen-kh.cheng@mediatek.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c408081ff6824888b6b6a348cc599409d26e8dc
Author: Samuel Holland <samuel@sholland.org>
Date:   Tue Jul 12 21:52:29 2022 -0500

    pinctrl: sunxi: Add I/O bias setting for H6 R-PIO
    
    commit fc153c8f283bf5925615195fc9d4056414d7b168 upstream.
    
    H6 requires I/O bias configuration on both of its PIO devices.
    Previously it was only done for the main PIO.
    
    The setting for Port L is at bit 0, so the bank calculation needs to
    account for the pin base. Otherwise the wrong bit is used.
    
    Fixes: cc62383fcebe ("pinctrl: sunxi: Support I/O bias voltage setting on H6")
    Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Tested-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Link: https://lore.kernel.org/r/20220713025233.27248-3-samuel@sholland.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec63eefb7ca8dea8f11a16cb4fc79a52ebd03975
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Jun 30 15:15:43 2022 +0200

    dt-bindings: pinctrl: mt8195: Add and use drive-strength-microamp
    
    commit 1b3ab63e56f0c30193b6787b083be4f4071b7fc6 upstream.
    
    As was already done for MT8192 in commit b52e695324bb ("dt-bindings:
    pinctrl: mt8192: Add drive-strength-microamp"), replace the custom
    mediatek,drive-strength-adv property with the standardized pinconf
    'drive-strength-microamp' one.
    
    Similarly to the mt8192 counterpart, there's no user of property
    'mediatek,drive-strength-adv', hence removing it is safe.
    
    Fixes: 69c3d58dc187 ("dt-bindings: pinctrl: mt8195: Add mediatek,drive-strength-adv property")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220630131543.225554-1-angelogioacchino.delregno@collabora.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f87b8f577d47a5364f91c6ed0113871b0d34ff76
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Jun 30 14:23:34 2022 +0200

    dt-bindings: pinctrl: mt8195: Fix name for mediatek,rsel-resistance-in-si-unit
    
    commit 11bd0ffd165fce7aff1a2ed15c04c088239f3d42 upstream.
    
    When this property was introduced, it contained underscores, but
    the actual code wants dashes.
    
    Change it from mediatek,rsel_resistance_in_si_unit to
    mediatek,rsel-resistance-in-si-unit.
    
    Fixes: 91e7edceda96 ("dt-bindings: pinctrl: mt8195: change pull up/down description")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220630122334.216903-1-angelogioacchino.delregno@collabora.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d8e2fa66adb5514380f5b680796ab0586140447
Author: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Date:   Mon Jun 13 12:11:26 2022 +0530

    pinctrl: amd: Don't save/restore interrupt status and wake status bits
    
    commit b8c824a869f220c6b46df724f85794349bafbf23 upstream.
    
    Saving/restoring interrupt and wake status bits across suspend can
    cause the suspend to fail if an IRQ is serviced across the
    suspend cycle.
    
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
    Fixes: 79d2c8bede2c ("pinctrl/amd: save pin registers over suspend/resume")
    Link: https://lore.kernel.org/r/20220613064127.220416-3-Basavaraj.Natikar@amd.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72400a60f6d3bf6fd203d488d1ffc1868bff1cf5
Author: Nikita Travkin <nikita@trvn.ru>
Date:   Sun Jun 12 19:59:54 2022 +0500

    pinctrl: qcom: msm8916: Allow CAMSS GP clocks to be muxed
    
    commit 44339391c666e46cba522d19c65a6ad1071c68b7 upstream.
    
    GPIO 31, 32 can be muxed to GCC_CAMSS_GP(1,2)_CLK respectively but the
    function was never assigned to the pingroup (even though the function
    exists already).
    
    Add this mode to the related pins.
    
    Fixes: 5373a2c5abb6 ("pinctrl: qcom: Add msm8916 pinctrl driver")
    Signed-off-by: Nikita Travkin <nikita@trvn.ru>
    Link: https://lore.kernel.org/r/20220612145955.385787-4-nikita@trvn.ru
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 587ac8ac00a1a9f4572785229d9441870fd7b187
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Jun 7 15:16:01 2022 +0400

    pinctrl: nomadik: Fix refcount leak in nmk_pinctrl_dt_subnode_to_map
    
    commit 4b32e054335ea0ce50967f63a7bfd4db058b14b9 upstream.
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak."
    
    Fixes: c2f6d059abfc ("pinctrl: nomadik: refactor DT parser to take two paths")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220607111602.57355-1-linmq006@gmail.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc4ac4cc41d19b4fb36b2d7098e825ce2de5a5d5
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Wed May 25 11:57:14 2022 -0400

    dt-bindings: pinctrl: mt8192: Use generic bias instead of pull-*-adv
    
    commit 353d2ef77f2be4c1b9b3c70f1637a9986f07b997 upstream.
    
    Commit cafe19db7751 ("pinctrl: mediatek: Backward compatible to previous
    Mediatek's bias-pull usage") allowed the bias-pull-up and bias-pull-down
    properties to be used for setting PUPD/R1/R0 type bias on mtk-paris
    based SoC's, which was previously only supported by the custom
    mediatek,pull-up-adv and mediatek,pull-down-adv properties.
    
    Since the bias-pull-{up,down} properties already have defines associated
    thus being more descriptive and is more universal on MediaTek platforms,
    and given that there are no mediatek,pull-{up,down}-adv users on mt8192
    yet, remove the custom adv properties in favor of the generic ones.
    
    Note that only mediatek,pull-up-adv was merged in the binding, but not
    its down counterpart.
    
    Fixes: edbacb36ea50 ("dt-bindings: pinctrl: mt8192: Add mediatek,pull-up-adv property")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogiocchino.delregno@collabora.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220525155714.1837360-3-nfraprado@collabora.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ada8cbf7d50a9147be9af8bebc8e852658544f89
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Wed May 25 11:57:13 2022 -0400

    dt-bindings: pinctrl: mt8192: Add drive-strength-microamp
    
    commit b52e695324bb44728053a414f17d25a5959ecb9d upstream.
    
    Commit e5fabbe43f3f ("pinctrl: mediatek: paris: Support generic
    PIN_CONFIG_DRIVE_STRENGTH_UA") added support for using
    drive-strength-microamp instead of mediatek,drive-strength-adv.
    
    Since there aren't any users of mediatek,drive-strength-adv on mt8192
    yet, remove this property and add drive-strength-microamp in its place,
    which has a clearer meaning.
    
    Fixes: 4ac68333ff6d ("dt-bindings: pinctrl: mt8192: Add mediatek,drive-strength-adv property")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogiocchino.delregno@collabora.com>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20220525155714.1837360-2-nfraprado@collabora.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0869aab075e83deaaf9ba41bc7b150b516cb62db
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Wed May 11 10:40:57 2022 +0100

    pinctrl: renesas: rzg2l: Return -EINVAL for pins which have input disabled
    
    commit 5223c511eb4f919e6b423b2f66e02674e97e77e3 upstream.
    
    Pin status reported by pinconf-pins file always reported pin status as
    "input enabled" even for pins which had input disabled. Fix this by
    returning -EINVAL for the pins which have input disabled.
    
    Fixes: c4c4637eb57f2 ("pinctrl: renesas: Add RZ/G2L pin and gpio controller driver")
    Reported-by: Phil Edworthy <phil.edworthy@renesas.com>
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Reviewed-by: Phil Edworthy <phil.edworthy@renesas.com>
    Link: https://lore.kernel.org/r/20220511094057.3151-1-prabhakar.mahadev-lad.rj@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a202e4d71d1fd74b6d29eaa6dccfa74d61b560e
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri May 20 14:32:44 2022 +0200

    dt-bindings: arm: qcom: fix Alcatel OneTouch Idol 3 compatibles
    
    commit 944de5182f0269e72ffe0a8880c8dbeb30f473d8 upstream.
    
    The MSM8916 Alcatel OneTouch Idol 3 does not use MTP fallbacks in
    compatibles:
    
      msm8916-alcatel-idol347.dtb: /: compatible: 'oneOf' conditional failed, one must be fixed:
        ['alcatel,idol347', 'qcom,msm8916'] is too short
    
    Reported-by: Rob Herring <robh@kernel.org>
    Fixes: e9dd2f7204ed ("dt-bindings: arm: qcom: Document alcatel,idol347 board")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
    Link: https://lore.kernel.org/r/20220520123252.365762-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ec24eef932578015b8c0e4d98f315b2a7228c86
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Tue Aug 9 14:33:20 2022 +0300

    selftests: forwarding: Fix failing tests with old libnet
    
    commit 8bcfb4ae4d970b9a9724ddfbac26c387934e0e94 upstream.
    
    The custom multipath hash tests use mausezahn in order to test how
    changes in various packet fields affect the packet distribution across
    the available nexthops.
    
    The tool uses the libnet library for various low-level packet
    construction and injection. The library started using the
    "SO_BINDTODEVICE" socket option for IPv6 sockets in version 1.1.6 and
    for IPv4 sockets in version 1.2.
    
    When the option is not set, packets are not routed according to the
    table associated with the VRF master device and tests fail.
    
    Fix this by prefixing the command with "ip vrf exec", which will cause
    the route lookup to occur in the VRF routing table. This makes the tests
    pass regardless of the libnet library version.
    
    Fixes: 511e8db54036 ("selftests: forwarding: Add test for custom multipath hash")
    Fixes: 185b0c190bb6 ("selftests: forwarding: Add test for custom multipath hash with IPv4 GRE")
    Fixes: b7715acba4d3 ("selftests: forwarding: Add test for custom multipath hash with IPv6 GRE")
    Reported-by: Ivan Vecera <ivecera@redhat.com>
    Tested-by: Ivan Vecera <ivecera@redhat.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Amit Cohen <amcohen@nvidia.com>
    Link: https://lore.kernel.org/r/20220809113320.751413-1-idosch@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 054233aa9f057071f33213fa44ef38e2dabc7584
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Wed Aug 10 09:45:47 2022 -0700

    net: atm: bring back zatm uAPI
    
    commit c2e75634cbe368065f140dd30bf8b1a0355158fd upstream.
    
    Jiri reports that linux-atm does not build without this header.
    Bring it back. It's completely dead code but we can't break
    the build for user space :(
    
    Reported-by: Jiri Slaby <jirislaby@kernel.org>
    Fixes: 052e1f01bfae ("net: atm: remove support for ZeitNet ZN122x ATM devices")
    Link: https://lore.kernel.org/all/8576aef3-37e4-8bae-bab5-08f82a78efd3@kernel.org/
    Link: https://lore.kernel.org/r/20220810164547.484378-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da1421a29d3b8681ba6a7f686bd0b40dda5acaf3
Author: Sandor Bodo-Merle <sbodomerle@gmail.com>
Date:   Mon Aug 8 19:39:39 2022 +0200

    net: bgmac: Fix a BUG triggered by wrong bytes_compl
    
    commit 1b7680c6c1f6de9904f1d9b05c952f0c64a03350 upstream.
    
    On one of our machines we got:
    
    kernel BUG at lib/dynamic_queue_limits.c:27!
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
    CPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: G        W  O    4.14.275-rt132 #1
    Hardware name: BRCM XGS iProc
    task: ee3415c0 task.stack: ee32a000
    PC is at dql_completed+0x168/0x178
    LR is at bgmac_poll+0x18c/0x6d8
    pc : [<c03b9430>]    lr : [<c04b5a18>]    psr: 800a0313
    sp : ee32be14  ip : 000005ea  fp : 00000bd4
    r10: ee558500  r9 : c0116298  r8 : 00000002
    r7 : 00000000  r6 : ef128810  r5 : 01993267  r4 : 01993851
    r3 : ee558000  r2 : 000070e1  r1 : 00000bd4  r0 : ee52c180
    Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
    Control: 12c5387d  Table: 8e88c04a  DAC: 00000051
    Process irq/41-bgmac (pid: 1166, stack limit = 0xee32a210)
    Stack: (0xee32be14 to 0xee32c000)
    be00:                                              ee558520 ee52c100 ef128810
    be20: 00000000 00000002 c0116298 c04b5a18 00000000 c0a0c8c4 c0951780 00000040
    be40: c0701780 ee558500 ee55d520 ef05b340 ef6f9780 ee558520 00000001 00000040
    be60: ffffe000 c0a56878 ef6fa040 c0952040 0000012c c0528744 ef6f97b0 fffcfb6a
    be80: c0a04104 2eda8000 c0a0c4ec c0a0d368 ee32bf44 c0153534 ee32be98 ee32be98
    bea0: ee32bea0 ee32bea0 ee32bea8 ee32bea8 00000000 c01462e4 ffffe000 ef6f22a8
    bec0: ffffe000 00000008 ee32bee4 c0147430 ffffe000 c094a2a8 00000003 ffffe000
    bee0: c0a54528 00208040 0000000c c0a0c8c4 c0a65980 c0124d3c 00000008 ee558520
    bf00: c094a23c c0a02080 00000000 c07a9910 ef136970 ef136970 ee30a440 ef136900
    bf20: ee30a440 00000001 ef136900 ee30a440 c016d990 00000000 c0108db0 c012500c
    bf40: ef136900 c016da14 ee30a464 ffffe000 00000001 c016dd14 00000000 c016db28
    bf60: ffffe000 ee21a080 ee30a400 00000000 ee32a000 ee30a440 c016dbfc ee25fd70
    bf80: ee21a09c c013edcc ee32a000 ee30a400 c013ec7c 00000000 00000000 00000000
    bfa0: 00000000 00000000 00000000 c0108470 00000000 00000000 00000000 00000000
    bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
    [<c03b9430>] (dql_completed) from [<c04b5a18>] (bgmac_poll+0x18c/0x6d8)
    [<c04b5a18>] (bgmac_poll) from [<c0528744>] (net_rx_action+0x1c4/0x494)
    [<c0528744>] (net_rx_action) from [<c0124d3c>] (do_current_softirqs+0x1ec/0x43c)
    [<c0124d3c>] (do_current_softirqs) from [<c012500c>] (__local_bh_enable+0x80/0x98)
    [<c012500c>] (__local_bh_enable) from [<c016da14>] (irq_forced_thread_fn+0x84/0x98)
    [<c016da14>] (irq_forced_thread_fn) from [<c016dd14>] (irq_thread+0x118/0x1c0)
    [<c016dd14>] (irq_thread) from [<c013edcc>] (kthread+0x150/0x158)
    [<c013edcc>] (kthread) from [<c0108470>] (ret_from_fork+0x14/0x24)
    Code: a83f15e0 0200001a 0630a0e1 c3ffffea (f201f0e7)
    
    The issue seems similar to commit 90b3b339364c ("net: hisilicon: Fix a BUG
    trigered by wrong bytes_compl") and potentially introduced by commit
    b38c83dd0866 ("bgmac: simplify tx ring index handling").
    
    If there is an RX interrupt between setting ring->end
    and netdev_sent_queue() we can hit the BUG_ON as bgmac_dma_tx_free()
    can miscalculate the queue size while called from bgmac_poll().
    
    The machine which triggered the BUG runs a v4.14 RT kernel - but the issue
    seems present in mainline too.
    
    Fixes: b38c83dd0866 ("bgmac: simplify tx ring index handling")
    Signed-off-by: Sandor Bodo-Merle <sbodomerle@gmail.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20220808173939.193804-1-sbodomerle@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e432f157c3edc5a97a7244c666589a438f5e4d4
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Mon Aug 8 15:51:27 2022 +0300

    net: dsa: felix: suppress non-changes to the tagging protocol
    
    commit 4c46bb49460ee14c69629e813640d8b929e88941 upstream.
    
    The way in which dsa_tree_change_tag_proto() works is that when
    dsa_tree_notify() fails, it doesn't know whether the operation failed
    mid way in a multi-switch tree, or it failed for a single-switch tree.
    So even though drivers need to fail cleanly in
    ds->ops->change_tag_protocol(), DSA will still call dsa_tree_notify()
    again, to restore the old tag protocol for potential switches in the
    tree where the change did succeeed (before failing for others).
    
    This means for the felix driver that if we report an error in
    felix_change_tag_protocol(), we'll get another call where proto_ops ==
    old_proto_ops. If we proceed to act upon that, we may do unexpected
    things. For example, we will call dsa_tag_8021q_register() twice in a
    row, without any dsa_tag_8021q_unregister() in between. Then we will
    actually call dsa_tag_8021q_unregister() via old_proto_ops->teardown,
    which (if it manages to run at all, after walking through corrupted data
    structures) will leave the ports inoperational anyway.
    
    The bug can be readily reproduced if we force an error while in
    tag_8021q mode; this crashes the kernel.
    
    echo ocelot-8021q > /sys/class/net/eno2/dsa/tagging
    echo edsa > /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014
    Call trace:
     vcap_entry_get+0x24/0x124
     ocelot_vcap_filter_del+0x198/0x270
     felix_tag_8021q_vlan_del+0xd4/0x21c
     dsa_switch_tag_8021q_vlan_del+0x168/0x2cc
     dsa_switch_event+0x68/0x1170
     dsa_tree_notify+0x14/0x34
     dsa_port_tag_8021q_vlan_del+0x84/0x110
     dsa_tag_8021q_unregister+0x15c/0x1c0
     felix_tag_8021q_teardown+0x16c/0x180
     felix_change_tag_protocol+0x1bc/0x230
     dsa_switch_event+0x14c/0x1170
     dsa_tree_change_tag_proto+0x118/0x1c0
    
    Fixes: 7a29d220f4c0 ("net: dsa: felix: reimplement tagging protocol change with function pointers")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20220808125127.3344094-1-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0bae8f44d88e7b587394df8af3b760c9682ce634
Author: Oleksij Rempel <linux@rempel-privat.de>
Date:   Fri Aug 5 09:31:59 2022 +0200

    net: phy: c45 baset1: do not skip aneg configuration if clock role is not specified
    
    commit 3702e4041cfda50bc697363d29511ce8f6b24795 upstream.
    
    In case master/slave clock role is not specified (which is default), the
    aneg registers will not be written.
    
    The visible impact of this is missing pause advertisement.
    
    So, rework genphy_c45_baset1_an_config_aneg() to be able to write
    advertisement registers even if clock role is unknown.
    
    Fixes: 3da8ffd8545f ("net: phy: Add 10BASE-T1L support in phy-c45")
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20220805073159.908643-1-o.rempel@pengutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3837c9b318d0ac9e4de6354b41158bc662756978
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Thu Aug 4 10:36:04 2022 -0700

    net: bcmgenet: Indicate MAC is in charge of PHY PM
    
    commit bc3410f250219660a7be032c01c954a53b2c26ab upstream.
    
    Avoid the PHY library call unnecessarily into the suspend/resume functions by
    setting phydev->mac_managed_pm to true. The GENET driver essentially does
    exactly what mdio_bus_phy_resume() does by calling phy_init_hw() plus
    phy_resume().
    
    Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20220804173605.1266574-1-f.fainelli@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7dc0ed411de3450e75b2a9600b5742cbf0908167
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Mon Aug 1 16:34:03 2022 -0700

    net: phy: Warn about incorrect mdio_bus_phy_resume() state
    
    commit 744d23c71af39c7dc77ac7c3cac87ae86a181a85 upstream.
    
    Calling mdio_bus_phy_resume() with neither the PHY state machine set to
    PHY_HALTED nor phydev->mac_managed_pm set to true is a good indication
    that we can produce a race condition looking like this:
    
    CPU0                                            CPU1
    bcmgenet_resume
     -> phy_resume
       -> phy_init_hw
     -> phy_start
       -> phy_resume
                                                    phy_start_aneg()
    mdio_bus_phy_resume
     -> phy_resume
        -> phy_write(..., BMCR_RESET)
         -> usleep()                                  -> phy_read()
    
    with the phy_resume() function triggering a PHY behavior that might have
    to be worked around with (see bf8bfc4336f7 ("net: phy: broadcom: Fix
    brcm_fet_config_init()") for instance) that ultimately leads to an error
    reading from the PHY.
    
    Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20220801233403.258871-1-f.fainelli@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26bef5616255066268c0e40e1da10cc9b78b82e9
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Tue Aug 9 14:35:06 2022 +0300

    devlink: Fix use-after-free after a failed reload
    
    commit 6b4db2e528f650c7fb712961aac36455468d5902 upstream.
    
    After a failed devlink reload, devlink parameters are still registered,
    which means user space can set and get their values. In the case of the
    mlxsw "acl_region_rehash_interval" parameter, these operations will
    trigger a use-after-free [1].
    
    Fix this by rejecting set and get operations while in the failed state.
    Return the "-EOPNOTSUPP" error code which does not abort the parameters
    dump, but instead causes it to skip over the problematic parameter.
    
    Another possible fix is to perform these checks in the mlxsw parameter
    callbacks, but other drivers might be affected by the same problem and I
    am not aware of scenarios where these stricter checks will cause a
    regression.
    
    [1]
    mlxsw_spectrum3 0000:00:10.0: Port 125: Failed to register netdev
    mlxsw_spectrum3 0000:00:10.0: Failed to create ports
    
    ==================================================================
    BUG: KASAN: use-after-free in mlxsw_sp_acl_tcam_vregion_rehash_intrvl_get+0xbd/0xd0 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:904
    Read of size 4 at addr ffff8880099dcfd8 by task kworker/u4:4/777
    
    CPU: 1 PID: 777 Comm: kworker/u4:4 Not tainted 5.19.0-rc7-custom-126601-gfe26f28c586d #1
    Hardware name: QEMU MSN4700, BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    Workqueue: netns cleanup_net
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x92/0xbd lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:313 [inline]
     print_report.cold+0x5e/0x5cf mm/kasan/report.c:429
     kasan_report+0xb9/0xf0 mm/kasan/report.c:491
     __asan_report_load4_noabort+0x14/0x20 mm/kasan/report_generic.c:306
     mlxsw_sp_acl_tcam_vregion_rehash_intrvl_get+0xbd/0xd0 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:904
     mlxsw_sp_acl_region_rehash_intrvl_get+0x49/0x60 drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c:1106
     mlxsw_sp_params_acl_region_rehash_intrvl_get+0x33/0x80 drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3854
     devlink_param_get net/core/devlink.c:4981 [inline]
     devlink_nl_param_fill+0x238/0x12d0 net/core/devlink.c:5089
     devlink_param_notify+0xe5/0x230 net/core/devlink.c:5168
     devlink_ns_change_notify net/core/devlink.c:4417 [inline]
     devlink_ns_change_notify net/core/devlink.c:4396 [inline]
     devlink_reload+0x15f/0x700 net/core/devlink.c:4507
     devlink_pernet_pre_exit+0x112/0x1d0 net/core/devlink.c:12272
     ops_pre_exit_list net/core/net_namespace.c:152 [inline]
     cleanup_net+0x494/0xc00 net/core/net_namespace.c:582
     process_one_work+0x9fc/0x1710 kernel/workqueue.c:2289
     worker_thread+0x675/0x10b0 kernel/workqueue.c:2436
     kthread+0x30c/0x3d0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
     </TASK>
    
    The buggy address belongs to the physical page:
    page:ffffea0000267700 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99dc
    flags: 0x100000000000000(node=0|zone=1)
    raw: 0100000000000000 0000000000000000 dead000000000122 0000000000000000
    raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff8880099dce80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
     ffff8880099dcf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    >ffff8880099dcf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                                                        ^
     ffff8880099dd000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
     ffff8880099dd080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    ==================================================================
    
    Fixes: 98bbf70c1c41 ("mlxsw: spectrum: add "acl_region_rehash_interval" devlink param")
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b54e14535bc34bf649372060d518ec9f2b893b3
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Thu Aug 11 01:09:48 2022 +0900

    virtio-blk: Avoid use-after-free on suspend/resume
    
    commit 8d12ec10292877751ee4463b11a63bd850bc09b5 upstream.
    
    hctx->user_data is set to vq in virtblk_init_hctx().  However, vq is
    freed on suspend and reallocated on resume.  So, hctx->user_data is
    invalid after resume, and it will cause use-after-free accessing which
    will result in the kernel crash something like below:
    
    [   22.428391] Call Trace:
    [   22.428899]  <TASK>
    [   22.429339]  virtqueue_add_split+0x3eb/0x620
    [   22.430035]  ? __blk_mq_alloc_requests+0x17f/0x2d0
    [   22.430789]  ? kvm_clock_get_cycles+0x14/0x30
    [   22.431496]  virtqueue_add_sgs+0xad/0xd0
    [   22.432108]  virtblk_add_req+0xe8/0x150
    [   22.432692]  virtio_queue_rqs+0xeb/0x210
    [   22.433330]  blk_mq_flush_plug_list+0x1b8/0x280
    [   22.434059]  __blk_flush_plug+0xe1/0x140
    [   22.434853]  blk_finish_plug+0x20/0x40
    [   22.435512]  read_pages+0x20a/0x2e0
    [   22.436063]  ? folio_add_lru+0x62/0xa0
    [   22.436652]  page_cache_ra_unbounded+0x112/0x160
    [   22.437365]  filemap_get_pages+0xe1/0x5b0
    [   22.437964]  ? context_to_sid+0x70/0x100
    [   22.438580]  ? sidtab_context_to_sid+0x32/0x400
    [   22.439979]  filemap_read+0xcd/0x3d0
    [   22.440917]  xfs_file_buffered_read+0x4a/0xc0
    [   22.441984]  xfs_file_read_iter+0x65/0xd0
    [   22.442970]  __kernel_read+0x160/0x2e0
    [   22.443921]  bprm_execve+0x21b/0x640
    [   22.444809]  do_execveat_common.isra.0+0x1a8/0x220
    [   22.446008]  __x64_sys_execve+0x2d/0x40
    [   22.446920]  do_syscall_64+0x37/0x90
    [   22.447773]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    This patch fixes this issue by getting vq from vblk, and removes
    virtblk_init_hctx().
    
    Fixes: 4e0400525691 ("virtio-blk: support polling I/O")
    Cc: "Suwan Kim" <suwan.kim027@gmail.com>
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Message-Id: <20220810160948.959781-1-syoshida@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18e383afbd7047af7b055df6e25436e0ce28f8a5
Author: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Date:   Thu Aug 4 14:32:48 2022 +0800

    virtio_net: fix memory leak inside XPD_TX with mergeable
    
    commit 7a542bee27c6a57e45c33cbbdc963325fd6493af upstream.
    
    When we call xdp_convert_buff_to_frame() to get xdpf, if it returns
    NULL, we should check if xdp_page was allocated by xdp_linearize_page().
    If it is newly allocated, it should be freed here alone. Just like any
    other "goto err_xdp".
    
    Fixes: 44fa2dbd4759 ("xdp: transition into using xdp_frame for ndo_xdp_xmit")
    Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3718ea043945ff8d16ab7c16a12893e1edb04e99
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Thu Jun 30 15:10:57 2022 -0400

    virtio: VIRTIO_HARDEN_NOTIFICATION is broken
    
    commit ebe797f25f68f28581f46a9cb9c1997ac15c39a0 upstream.
    
    This option doesn't really work and breaks too many drivers.
    Not yet sure what's the right thing to do, for now
    let's make sure randconfig isn't broken by this.
    
    Fixes: c346dae4f3fb ("virtio: disable notification hardening by default")
    Cc: "Jason Wang" <jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a6221c441817b22fb6c45c65dd41b1e9abe3f6f
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Fri Jun 10 15:48:18 2022 +0100

    ASoC: qdsp6: q6apm-dai: unprepare stream if its already prepared
    
    commit 6548c884a595391fab172faeae39e2b329b848f3 upstream.
    
    prepare callback can be called multiple times, so unprepare the stream
    if its already prepared.
    
    Without this DSP is not happy to setting the params on a already
    prepared graph.
    
    Fixes: 9b4fe0f1cd79 ("ASoC: qdsp6: audioreach: add q6apm-dai support")
    Reported-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20220610144818.511797-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08c6c65891d8a2e12176229b9be7379861456880
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Jul 27 13:02:27 2022 -0400

    SUNRPC: Don't reuse bvec on retransmission of the request
    
    commit 72691a269f0baad6d5f4aa7af97c29081b86d70f upstream.
    
    If a request is re-encoded and then retransmitted, we need to make sure
    that we also re-encode the bvec, in case the page lists have changed.
    
    Fixes: ff053dbbaffe ("SUNRPC: Move the call to xprt_send_pagedata() out of xprt_sock_sendmsg()")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7116a23f3d754cfe40f5497551b0d476ca85258f
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Jul 27 12:27:54 2022 -0400

    SUNRPC: Reinitialise the backchannel request buffers before reuse
    
    commit 6622e3a73112fc336c1c2c582428fb5ef18e456a upstream.
    
    When we're reusing the backchannel requests instead of freeing them,
    then we should reinitialise any values of the send/receive xdr_bufs so
    that they reflect the available space.
    
    Fixes: 0d2a970d0ae5 ("SUNRPC: Fix a backchannel race")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed1e2e39f083eae8ceb91325b7a294eb4ac3336a
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 19 09:18:35 2022 -0400

    SUNRPC: Fix xdr_encode_bool()
    
    commit c770f31d8f580ed4b965c64f924ec1cc50e41734 upstream.
    
    I discovered that xdr_encode_bool() was returning the same address
    that was passed in the @p parameter. The documenting comment states
    that the intent is to return the address of the next buffer
    location, just like the other "xdr_encode_*" helpers.
    
    The result was the encoded results of NFSv3 PATHCONF operations were
    not formed correctly.
    
    Fixes: ded04a587f6c ("NFSD: Update the NFSv3 PATHCONF3res encoder to use struct xdr_stream")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99cdd380b8127943061202e91b2e712707cb6370
Author: Dan Aloni <dan.aloni@vastdata.com>
Date:   Mon Jul 4 15:56:57 2022 +0300

    sunrpc: fix expiry of auth creds
    
    commit f1bafa7375c01ff71fb7cb97c06caadfcfe815f3 upstream.
    
    Before this commit, with a large enough LRU of expired items (100), the
    loop skipped all the expired items and was entirely ineffectual in
    trimming the LRU list.
    
    Fixes: 95cd623250ad ('SUNRPC: Clean up the AUTH cache code')
    Signed-off-by: Dan Aloni <dan.aloni@vastdata.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9da937bbe7063f7bdaaa3efddbf354cd65c9a1f
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon May 30 19:17:12 2022 -0700

    m68k: coldfire/device.c: protect FLEXCAN blocks
    
    commit 3c2bf173501652fced1d058834e9c983d295b126 upstream.
    
    When CAN_FLEXCAN=y and M5441x is not set/enabled, there are build
    errors in coldfire/device.c:
    
    ../arch/m68k/coldfire/device.c:595:26: error: 'MCFFLEXCAN_BASE0' undeclared here (not in a function); did you mean 'MCFDMA_BASE0'?
      595 |                 .start = MCFFLEXCAN_BASE0,
    ../arch/m68k/coldfire/device.c:596:43: error: 'MCFFLEXCAN_SIZE' undeclared here (not in a function)
      596 |                 .end = MCFFLEXCAN_BASE0 + MCFFLEXCAN_SIZE,
    ../arch/m68k/coldfire/device.c:600:26: error: 'MCF_IRQ_IFL0' undeclared here (not in a function); did you mean 'MCF_IRQ_I2C0'?
      600 |                 .start = MCF_IRQ_IFL0,
    ../arch/m68k/coldfire/device.c:605:26: error: 'MCF_IRQ_BOFF0' undeclared here (not in a function); did you mean 'MCF_IRQ_I2C0'?
      605 |                 .start = MCF_IRQ_BOFF0,
    ../arch/m68k/coldfire/device.c:610:26: error: 'MCF_IRQ_ERR0' undeclared here (not in a function); did you mean 'MCF_IRQ_I2C0'?
      610 |                 .start = MCF_IRQ_ERR0,
    
    Protect the FLEXCAN code blocks by checking if MCFFLEXCAN_SIZE
    is defined.
    
    Fixes: 35a9f9363a89 ("m68k: m5441x: add flexcan support")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Greg Ungerer <gerg@linux-m68k.org>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: linux-m68k@lists.linux-m68k.org
    Cc: uclinux-dev@uclinux.org
    Cc: Angelo Dureghello <angelo@kernel-space.org>
    Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23bf155476539354ab5c8cc9bb460fd1209b39b5
Author: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Date:   Mon Aug 8 16:18:45 2022 +0800

    net: atlantic: fix aq_vec index out of range error
    
    commit 2ba5e47fb75fbb8fab45f5c1bc8d5c33d8834bd3 upstream.
    
    The final update statement of the for loop exceeds the array range, the
    dereference of self->aq_vec[i] is not checked and then leads to the
    index out of range error.
    Also fixed this kind of coding style in other for loop.
    
    [   97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48
    [   97.937607] index 8 is out of range for type 'aq_vec_s *[8]'
    [   97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2
    [   97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022
    [   97.937611] Workqueue: events_unbound async_run_entry_fn
    [   97.937616] Call Trace:
    [   97.937617]  <TASK>
    [   97.937619]  dump_stack_lvl+0x49/0x63
    [   97.937624]  dump_stack+0x10/0x16
    [   97.937626]  ubsan_epilogue+0x9/0x3f
    [   97.937627]  __ubsan_handle_out_of_bounds.cold+0x44/0x49
    [   97.937629]  ? __scm_send+0x348/0x440
    [   97.937632]  ? aq_vec_stop+0x72/0x80 [atlantic]
    [   97.937639]  aq_nic_stop+0x1b6/0x1c0 [atlantic]
    [   97.937644]  aq_suspend_common+0x88/0x90 [atlantic]
    [   97.937648]  aq_pm_suspend_poweroff+0xe/0x20 [atlantic]
    [   97.937653]  pci_pm_suspend+0x7e/0x1a0
    [   97.937655]  ? pci_pm_suspend_noirq+0x2b0/0x2b0
    [   97.937657]  dpm_run_callback+0x54/0x190
    [   97.937660]  __device_suspend+0x14c/0x4d0
    [   97.937661]  async_suspend+0x23/0x70
    [   97.937663]  async_run_entry_fn+0x33/0x120
    [   97.937664]  process_one_work+0x21f/0x3f0
    [   97.937666]  worker_thread+0x4a/0x3c0
    [   97.937668]  ? process_one_work+0x3f0/0x3f0
    [   97.937669]  kthread+0xf0/0x120
    [   97.937671]  ? kthread_complete_and_exit+0x20/0x20
    [   97.937672]  ret_from_fork+0x22/0x30
    [   97.937676]  </TASK>
    
    v2. fixed "warning: variable 'aq_vec' set but not used"
    
    v3. simplified a for loop
    
    Fixes: 97bde5c4f909 ("net: ethernet: aquantia: Support for NIC-specific code")
    Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
    Acked-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
    Link: https://lore.kernel.org/r/20220808081845.42005-1-acelan.kao@canonical.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a0278dbeaaf7ca60346c62a9add65ae7d62564de
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Fri Aug 5 18:02:16 2022 +0300

    can: j1939: j1939_session_destroy(): fix memory leak of skbs
    
    commit 8c21c54a53ab21842f5050fa090f26b03c0313d6 upstream.
    
    We need to drop skb references taken in j1939_session_skb_queue() when
    destroying a session in j1939_session_destroy(). Otherwise those skbs
    would be lost.
    
    Link to Syzkaller info and repro: https://forge.ispras.ru/issues/11743.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    V1: https://lore.kernel.org/all/20220708175949.539064-1-pchelkin@ispras.ru
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Suggested-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/all/20220805150216.66313-1-pchelkin@ispras.ru
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dad7f33c95e1598b9ff094213cdccf9ebacd5aa9
Author: Sebastian Würl <sebastian.wuerl@ororatech.com>
Date:   Thu Aug 4 10:14:11 2022 +0200

    can: mcp251x: Fix race condition on receive interrupt
    
    commit d80d60b0db6ff3dd2e29247cc2a5166d7e9ae37e upstream.
    
    The mcp251x driver uses both receiving mailboxes of the CAN controller
    chips. For retrieving the CAN frames from the controller via SPI, it checks
    once per interrupt which mailboxes have been filled and will retrieve the
    messages accordingly.
    
    This introduces a race condition, as another CAN frame can enter mailbox 1
    while mailbox 0 is emptied. If now another CAN frame enters mailbox 0 until
    the interrupt handler is called next, mailbox 0 is emptied before
    mailbox 1, leading to out-of-order CAN frames in the network device.
    
    This is fixed by checking the interrupt flags once again after freeing
    mailbox 0, to correctly also empty mailbox 1 before leaving the handler.
    
    For reproducing the bug I created the following setup:
     - Two CAN devices, one Raspberry Pi with MCP2515, the other can be any.
     - Setup CAN to 1 MHz
     - Spam bursts of 5 CAN-messages with increasing CAN-ids
     - Continue sending the bursts while sleeping a second between the bursts
     - Check on the RPi whether the received messages have increasing CAN-ids
     - Without this patch, every burst of messages will contain a flipped pair
    
    v3: https://lore.kernel.org/all/20220804075914.67569-1-sebastian.wuerl@ororatech.com
    v2: https://lore.kernel.org/all/20220804064803.63157-1-sebastian.wuerl@ororatech.com
    v1: https://lore.kernel.org/all/20220803153300.58732-1-sebastian.wuerl@ororatech.com
    
    Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.")
    Signed-off-by: Sebastian Würl <sebastian.wuerl@ororatech.com>
    Link: https://lore.kernel.org/all/20220804081411.68567-1-sebastian.wuerl@ororatech.com
    [mkl: reduce scope of intf1, eflag1]
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 595fce48524eaacbd5d36893755b18be371145d0
Author: Hou Tao <houtao1@huawei.com>
Date:   Wed Aug 10 16:05:34 2022 +0800

    bpf: Check the validity of max_rdwr_access for sock local storage map iterator
    
    commit 52bd05eb7c88e1ad8541a48873188ccebca9da26 upstream.
    
    The value of sock local storage map is writable in map iterator, so check
    max_rdwr_access instead of max_rdonly_access.
    
    Fixes: 5ce6e77c7edf ("bpf: Implement bpf iterator for sock local storage map")
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/r/20220810080538.1845898-6-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 153a74518c0d7e11cdd7b07f64ead7677f48031b
Author: Hou Tao <houtao1@huawei.com>
Date:   Wed Aug 10 16:05:33 2022 +0800

    bpf: Acquire map uref in .init_seq_private for sock{map,hash} iterator
    
    commit f0d2b2716d71778d0b0c8eaa433c073287d69d93 upstream.
    
    sock_map_iter_attach_target() acquires a map uref, and the uref may be
    released before or in the middle of iterating map elements. For example,
    the uref could be released in sock_map_iter_detach_target() as part of
    bpf_link_release(), or could be released in bpf_map_put_with_uref() as
    part of bpf_map_release().
    
    Fixing it by acquiring an extra map uref in .init_seq_private and
    releasing it in .fini_seq_private.
    
    Fixes: 0365351524d7 ("net: Allow iterating sockmap and sockhash")
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/r/20220810080538.1845898-5-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be66774a7767bf4101f852a367485b0bd76f1626
Author: Hou Tao <houtao1@huawei.com>
Date:   Wed Aug 10 16:05:32 2022 +0800

    bpf: Acquire map uref in .init_seq_private for sock local storage map iterator
    
    commit 3c5f6e698b5c538bbb23cd453b22e1e4922cffd8 upstream.
    
    bpf_iter_attach_map() acquires a map uref, and the uref may be released
    before or in the middle of iterating map elements. For example, the uref
    could be released in bpf_iter_detach_map() as part of
    bpf_link_release(), or could be released in bpf_map_put_with_uref() as
    part of bpf_map_release().
    
    So acquiring an extra map uref in bpf_iter_init_sk_storage_map() and
    releasing it in bpf_iter_fini_sk_storage_map().
    
    Fixes: 5ce6e77c7edf ("bpf: Implement bpf iterator for sock local storage map")
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/r/20220810080538.1845898-4-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6bd5ea6a3d418d9406869e63cf56652ea94dc94
Author: Hou Tao <houtao1@huawei.com>
Date:   Wed Aug 10 16:05:31 2022 +0800

    bpf: Acquire map uref in .init_seq_private for hash map iterator
    
    commit ef1e93d2eeb58a1f08c37b22a2314b94bc045f15 upstream.
    
    bpf_iter_attach_map() acquires a map uref, and the uref may be released
    before or in the middle of iterating map elements. For example, the uref
    could be released in bpf_iter_detach_map() as part of
    bpf_link_release(), or could be released in bpf_map_put_with_uref() as
    part of bpf_map_release().
    
    So acquiring an extra map uref in bpf_iter_init_hash_map() and
    releasing it in bpf_iter_fini_hash_map().
    
    Fixes: d6c4503cc296 ("bpf: Implement bpf iterator for hash maps")
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/r/20220810080538.1845898-3-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a80118919088a79aa18a88b422ab73a6ae6ca40e
Author: Hou Tao <houtao1@huawei.com>
Date:   Wed Aug 10 16:05:30 2022 +0800

    bpf: Acquire map uref in .init_seq_private for array map iterator
    
    commit f76fa6b338055054f80c72b29c97fb95c1becadc upstream.
    
    bpf_iter_attach_map() acquires a map uref, and the uref may be released
    before or in the middle of iterating map elements. For example, the uref
    could be released in bpf_iter_detach_map() as part of
    bpf_link_release(), or could be released in bpf_map_put_with_uref() as
    part of bpf_map_release().
    
    Alternative fix is acquiring an extra bpf_link reference just like
    a pinned map iterator does, but it introduces unnecessary dependency
    on bpf_link instead of bpf_map.
    
    So choose another fix: acquiring an extra map uref in .init_seq_private
    for array map iterator.
    
    Fixes: d3cc2ab546ad ("bpf: Implement bpf iterator for array maps")
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/r/20220810080538.1845898-2-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62ec78d96dcb520c21cf1d7df379fc196c9884bf
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Date:   Tue Aug 9 23:30:32 2022 +0200

    bpf: Don't reinit map value in prealloc_lru_pop
    
    commit 275c30bcee66a27d1aa97a215d607ad6d49804cb upstream.
    
    The LRU map that is preallocated may have its elements reused while
    another program holds a pointer to it from bpf_map_lookup_elem. Hence,
    only check_and_free_fields is appropriate when the element is being
    deleted, as it ensures proper synchronization against concurrent access
    of the map value. After that, we cannot call check_and_init_map_value
    again as it may rewrite bpf_spin_lock, bpf_timer, and kptr fields while
    they can be concurrently accessed from a BPF program.
    
    This is safe to do as when the map entry is deleted, concurrent access
    is protected against by check_and_free_fields, i.e. an existing timer
    would be freed, and any existing kptr will be released by it. The
    program can create further timers and kptrs after check_and_free_fields,
    but they will eventually be released once the preallocated items are
    freed on map destruction, even if the item is never reused again. Hence,
    the deleted item sitting in the free list can still have resources
    attached to it, and they would never leak.
    
    With spin_lock, we never touch the field at all on delete or update, as
    we may end up modifying the state of the lock. Since the verifier
    ensures that a bpf_spin_lock call is always paired with bpf_spin_unlock
    call, the program will eventually release the lock so that on reuse the
    new user of the value can take the lock.
    
    Essentially, for the preallocated case, we must assume that the map
    value may always be in use by the program, even when it is sitting in
    the freelist, and handle things accordingly, i.e. use proper
    synchronization inside check_and_free_fields, and never reinitialize the
    special fields when it is reused on update.
    
    Fixes: 68134668c17f ("bpf: Add map side support for bpf timers.")
    Acked-by: Yonghong Song <yhs@fb.com>
    Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/r/20220809213033.24147-3-memxor@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b429d0b9a7a0f3dddb1f782b72629e6353f292fd
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Mon Aug 8 20:58:09 2022 -0700

    bpf: Disallow bpf programs call prog_run command.
    
    commit 86f44fcec22ce2979507742bc53db8400e454f46 upstream.
    
    The verifier cannot perform sufficient validation of bpf_attr->test.ctx_in
    pointer, therefore bpf programs should not be allowed to call BPF_PROG_RUN
    command from within the program.
    To fix this issue split bpf_sys_bpf() bpf helper into normal kern_sys_bpf()
    kernel function that can only be used by the kernel light skeleton directly.
    
    Reported-by: YiFei Zhu <zhuyifei@google.com>
    Fixes: b1d18a7574d0 ("bpf: Extend sys_bpf commands for bpf_syscall programs.")
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f6db7148ed7382b336c5827af33b5d9e992630e
Author: Jinghao Jia <jinghao@linux.ibm.com>
Date:   Fri Jul 29 20:17:13 2022 +0000

    BPF: Fix potential bad pointer dereference in bpf_sys_bpf()
    
    commit e2dcac2f58f5a95ab092d1da237ffdc0da1832cf upstream.
    
    The bpf_sys_bpf() helper function allows an eBPF program to load another
    eBPF program from within the kernel. In this case the argument union
    bpf_attr pointer (as well as the insns and license pointers inside) is a
    kernel address instead of a userspace address (which is the case of a
    usual bpf() syscall). To make the memory copying process in the syscall
    work in both cases, bpfptr_t was introduced to wrap around the pointer
    and distinguish its origin. Specifically, when copying memory contents
    from a bpfptr_t, a copy_from_user() is performed in case of a userspace
    address and a memcpy() is performed for a kernel address.
    
    This can lead to problems because the in-kernel pointer is never checked
    for validity. The problem happens when an eBPF syscall program tries to
    call bpf_sys_bpf() to load a program but provides a bad insns pointer --
    say 0xdeadbeef -- in the bpf_attr union. The helper calls __sys_bpf()
    which would then call bpf_prog_load() to load the program.
    bpf_prog_load() is responsible for copying the eBPF instructions to the
    newly allocated memory for the program; it creates a kernel bpfptr_t for
    insns and invokes copy_from_bpfptr(). Internally, all bpfptr_t
    operations are backed by the corresponding sockptr_t operations, which
    performs direct memcpy() on kernel pointers for copy_from/strncpy_from
    operations. Therefore, the code is always happy to dereference the bad
    pointer to trigger a un-handle-able page fault and in turn an oops.
    However, this is not supposed to happen because at that point the eBPF
    program is already verified and should not cause a memory error.
    
    Sample KASAN trace:
    
    [   25.685056][  T228] ==================================================================
    [   25.685680][  T228] BUG: KASAN: user-memory-access in copy_from_bpfptr+0x21/0x30
    [   25.686210][  T228] Read of size 80 at addr 00000000deadbeef by task poc/228
    [   25.686732][  T228]
    [   25.686893][  T228] CPU: 3 PID: 228 Comm: poc Not tainted 5.19.0-rc7 #7
    [   25.687375][  T228] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014
    [   25.687991][  T228] Call Trace:
    [   25.688223][  T228]  <TASK>
    [   25.688429][  T228]  dump_stack_lvl+0x73/0x9e
    [   25.688747][  T228]  print_report+0xea/0x200
    [   25.689061][  T228]  ? copy_from_bpfptr+0x21/0x30
    [   25.689401][  T228]  ? _printk+0x54/0x6e
    [   25.689693][  T228]  ? _raw_spin_lock_irqsave+0x70/0xd0
    [   25.690071][  T228]  ? copy_from_bpfptr+0x21/0x30
    [   25.690412][  T228]  kasan_report+0xb5/0xe0
    [   25.690716][  T228]  ? copy_from_bpfptr+0x21/0x30
    [   25.691059][  T228]  kasan_check_range+0x2bd/0x2e0
    [   25.691405][  T228]  ? copy_from_bpfptr+0x21/0x30
    [   25.691734][  T228]  memcpy+0x25/0x60
    [   25.692000][  T228]  copy_from_bpfptr+0x21/0x30
    [   25.692328][  T228]  bpf_prog_load+0x604/0x9e0
    [   25.692653][  T228]  ? cap_capable+0xb4/0xe0
    [   25.692956][  T228]  ? security_capable+0x4f/0x70
    [   25.693324][  T228]  __sys_bpf+0x3af/0x580
    [   25.693635][  T228]  bpf_sys_bpf+0x45/0x240
    [   25.693937][  T228]  bpf_prog_f0ec79a5a3caca46_bpf_func1+0xa2/0xbd
    [   25.694394][  T228]  bpf_prog_run_pin_on_cpu+0x2f/0xb0
    [   25.694756][  T228]  bpf_prog_test_run_syscall+0x146/0x1c0
    [   25.695144][  T228]  bpf_prog_test_run+0x172/0x190
    [   25.695487][  T228]  __sys_bpf+0x2c5/0x580
    [   25.695776][  T228]  __x64_sys_bpf+0x3a/0x50
    [   25.696084][  T228]  do_syscall_64+0x60/0x90
    [   25.696393][  T228]  ? fpregs_assert_state_consistent+0x50/0x60
    [   25.696815][  T228]  ? exit_to_user_mode_prepare+0x36/0xa0
    [   25.697202][  T228]  ? syscall_exit_to_user_mode+0x20/0x40
    [   25.697586][  T228]  ? do_syscall_64+0x6e/0x90
    [   25.697899][  T228]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
    [   25.698312][  T228] RIP: 0033:0x7f6d543fb759
    [   25.698624][  T228] Code: 08 5b 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 a6 0e 00 f7 d8 64 89 01 48
    [   25.699946][  T228] RSP: 002b:00007ffc3df78468 EFLAGS: 00000287 ORIG_RAX: 0000000000000141
    [   25.700526][  T228] RAX: ffffffffffffffda RBX: 00007ffc3df78628 RCX: 00007f6d543fb759
    [   25.701071][  T228] RDX: 0000000000000090 RSI: 00007ffc3df78478 RDI: 000000000000000a
    [   25.701636][  T228] RBP: 00007ffc3df78510 R08: 0000000000000000 R09: 0000000000300000
    [   25.702191][  T228] R10: 0000000000000005 R11: 0000000000000287 R12: 0000000000000000
    [   25.702736][  T228] R13: 00007ffc3df78638 R14: 000055a1584aca68 R15: 00007f6d5456a000
    [   25.703282][  T228]  </TASK>
    [   25.703490][  T228] ==================================================================
    [   25.704050][  T228] Disabling lock debugging due to kernel taint
    
    Update copy_from_bpfptr() and strncpy_from_bpfptr() so that:
     - for a kernel pointer, it uses the safe copy_from_kernel_nofault() and
       strncpy_from_kernel_nofault() functions.
     - for a userspace pointer, it performs copy_from_user() and
       strncpy_from_user().
    
    Fixes: af2ac3e13e45 ("bpf: Prepare bpf syscall to be used from kernel and user space.")
    Link: https://lore.kernel.org/bpf/20220727132905.45166-1-jinghao@linux.ibm.com/
    Signed-off-by: Jinghao Jia <jinghao@linux.ibm.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/r/20220729201713.88688-1-jinghao@linux.ibm.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 401d71c9cfb09522cac80093a3c61ca04a9ff68c
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Aug 4 17:21:27 2022 -0700

    selftests: mptcp: make sendfile selftest work
    
    commit df9e03aec3b14970df05b72d54f8ac9da3ab29e1 upstream.
    
    When the selftest got added, sendfile() on mptcp sockets returned
    -EOPNOTSUPP, so running 'mptcp_connect.sh -m sendfile' failed
    immediately.
    
    This is no longer the case, but the script fails anyway due to timeout.
    Let the receiver know once the sender has sent all data, just like
    with '-m mmap' mode.
    
    v2: need to respect cfg_wait too, as pm_userspace.sh relied
    on -m sendfile to keep the connection open (Mat Martineau)
    
    Fixes: 048d19d444be ("mptcp: add basic kselftest for mptcp")
    Reported-by: Xiumei Mu <xmu@redhat.com>
    Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8caf5c15b5288d52d9c89374d6c10fa32ee84ec5
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Aug 4 17:21:26 2022 -0700

    mptcp: do not queue data on closed subflows
    
    commit c886d70286bf3ad411eb3d689328a67f7102c6ae upstream.
    
    Dipanjan reported a syzbot splat at close time:
    
    WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153
    inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153
    Modules linked in: uio_ivshmem(OE) uio(E)
    CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G           OE
    5.19.0-rc6-g2eae0556bb9d #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    1.13.0-1ubuntu1.1 04/01/2014
    Workqueue: events mptcp_worker
    RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153
    Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91
    f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0b
    e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d
    RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00
    RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002
    RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000
    R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400
    R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258
    FS:  0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0
    Call Trace:
     <TASK>
     __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067
     sk_destruct+0xbd/0xe0 net/core/sock.c:2112
     __sk_free+0xef/0x3d0 net/core/sock.c:2123
     sk_free+0x78/0xa0 net/core/sock.c:2134
     sock_put include/net/sock.h:1927 [inline]
     __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351
     __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828
     mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586
     process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289
     worker_thread+0x623/0x1070 kernel/workqueue.c:2436
     kthread+0x2e9/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
     </TASK>
    
    The root cause of the problem is that an mptcp-level (re)transmit can
    race with mptcp_close() and the packet scheduler checks the subflow
    state before acquiring the socket lock: we can try to (re)transmit on
    an already closed ssk.
    
    Fix the issue checking again the subflow socket status under the
    subflow socket lock protection. Additionally add the missing check
    for the fallback-to-tcp case.
    
    Fixes: d5f49190def6 ("mptcp: allow picking different xmit subflows")
    Reported-by: Dipanjan Das <mail.dipanjan.das@gmail.com>
    Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6139039c8fc5c9dbcdc3ad389b9a6d0cacb4d693
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Aug 4 17:21:25 2022 -0700

    mptcp: move subflow cleanup in mptcp_destroy_common()
    
    commit c0bf3c6aa444a5ef44acc57ef6cfa53fd4fc1c9b upstream.
    
    If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE
    eBPF program, the MPTCP protocol ends-up leaking all the subflows:
    the related cleanup happens in __mptcp_destroy_sock() that is not
    invoked in such code path.
    
    Address the issue moving the subflow sockets cleanup in the
    mptcp_destroy_common() helper, which is invoked in every msk cleanup
    path.
    
    Additionally get rid of the intermediate list_splice_init step, which
    is an unneeded relic from the past.
    
    The issue is present since before the reported root cause commit, but
    any attempt to backport the fix before that hash will require a complete
    rewrite.
    
    Fixes: e16163b6e2 ("mptcp: refactor shutdown and close")
    Reported-by: Nguyen Dinh Phi <phind.uet@gmail.com>
    Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Co-developed-by: Nguyen Dinh Phi <phind.uet@gmail.com>
    Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1738a3087605e9c88707bba96c8bce4ae99e747c
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Tue Aug 2 18:33:24 2022 +0200

    mptcp, btf: Add struct mptcp_sock definition when CONFIG_MPTCP is disabled
    
    commit f1d41f7720c89705c20e4335a807b1c518c2e7be upstream.
    
    The btf_sock_ids array needs struct mptcp_sock BTF ID for the
    bpf_skc_to_mptcp_sock helper.
    
    When CONFIG_MPTCP is disabled, the 'struct mptcp_sock' is not
    defined and resolve_btfids will complain with:
    
      [...]
      BTFIDS  vmlinux
      WARN: resolve_btfids: unresolved symbol mptcp_sock
      [...]
    
    Add an empty definition for struct mptcp_sock when CONFIG_MPTCP
    is disabled.
    
    Fixes: 3bc253c2e652 ("bpf: Add bpf_skc_to_mptcp_sock_proto")
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/bpf/20220802163324.1873044-1-jolsa@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b03d1117e9be7c7da60e466eaf9beed85c5916c8
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Aug 2 15:48:50 2022 -0400

    NFSv4/pnfs: Fix a use-after-free bug in open
    
    commit 2135e5d56278ffdb1c2e6d325dc6b87f669b9dac upstream.
    
    If someone cancels the open RPC call, then we must not try to free
    either the open slot or the layoutget operation arguments, since they
    are likely still in use by the hung RPC call.
    
    Fixes: 6949493884fe ("NFSv4: Don't hold the layoutget locks across multiple RPC calls")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d56bdbffbbbc2b82b5ab17e6bdcf532b014007c
Author: Zhang Xianwei <zhang.xianwei8@zte.com.cn>
Date:   Wed Jul 27 18:01:07 2022 +0800

    NFSv4.1: RECLAIM_COMPLETE must handle EACCES
    
    commit e35a5e782f67ed76a65ad0f23a484444a95f000f upstream.
    
    A client should be able to handle getting an EACCES error while doing
    a mount operation to reclaim state due to NFS4CLNT_RECLAIM_REBOOT
    being set. If the server returns RPC_AUTH_BADCRED because authentication
    failed when we execute "exportfs -au", then RECLAIM_COMPLETE will go a
    wrong way. After mount succeeds, all OPEN call will fail due to an
    NFS4ERR_GRACE error being returned. This patch is to fix it by resending
    a RPC request.
    
    Signed-off-by: Zhang Xianwei <zhang.xianwei8@zte.com.cn>
    Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
    Fixes: aa5190d0ed7d ("NFSv4: Kill nfs4_async_handle_error() abuses by NFSv4.1")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2d1cdbc8b5909c992dfcf690edecc6545640cca
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Jul 13 17:46:52 2022 -0400

    NFSv4: Fix races in the legacy idmapper upcall
    
    commit 51fd2eb52c0ca8275a906eed81878ef50ae94eb0 upstream.
    
    nfs_idmap_instantiate() will cause the process that is waiting in
    request_key_with_auxdata() to wake up and exit. If there is a second
    process waiting for the idmap->idmap_mutex, then it may wake up and
    start a new call to request_key_with_auxdata(). If the call to
    idmap_pipe_downcall() from the first process has not yet finished
    calling nfs_idmap_complete_pipe_upcall_locked(), then we may end up
    triggering the WARN_ON_ONCE() in nfs_idmap_prepare_pipe_upcall().
    
    The fix is to ensure that we clear idmap->idmap_upcall_data before
    calling nfs_idmap_instantiate().
    
    Fixes: e9ab41b620e4 ("NFSv4: Clean up the legacy idmapper upcall")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 776f95d6cfc1ea841f81cd8af4798c2125373f4c
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Jul 12 09:22:40 2022 -0400

    NFSv4.1: Handle NFS4ERR_DELAY replies to OP_SEQUENCE correctly
    
    commit 7ccafd4b2b9f34e6d8185f796f151c47424e273e upstream.
    
    Don't assume that the NFS4ERR_DELAY means that the server is processing
    this slot id.
    
    Fixes: 3453d5708b33 ("NFSv4.1: Avoid false retries when RPC calls are interrupted")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 25c4488ba447de3f841c2b200ed44a687b105f5f
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Jul 12 09:16:04 2022 -0400

    NFSv4.1: Don't decrease the value of seq_nr_highest_sent
    
    commit f07a5d2427fc113dc50c5c818eba8929bc27b8ca upstream.
    
    When we're trying to figure out what the server may or may not have seen
    in terms of request numbers, do not assume that requests with a larger
    number were missed, just because we saw a reply to a request with a
    smaller number.
    
    Fixes: 3453d5708b33 ("NFSv4.1: Avoid false retries when RPC calls are interrupted")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd29648fcf69339713f2d25f7014ae905dcdfc18
Author: Cezar Bulinaru <cbulinaru@gmail.com>
Date:   Wed Aug 3 02:27:59 2022 -0400

    net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null
    
    commit 4f61f133f354853bc394ec7d6028adb9b02dd701 upstream.
    
    Fixes a NULL pointer derefence bug triggered from tap driver.
    When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null
    (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb)
    virtio_net_hdr_to_skb calls dev_parse_header_protocol which
    needs skb->dev field to be valid.
    
    The line that trigers the bug is in dev_parse_header_protocol
    (dev is at offset 0x10 from skb and is stored in RAX register)
      if (!dev->header_ops || !dev->header_ops->parse_protocol)
      22e1:   mov    0x10(%rbx),%rax
      22e5:   mov    0x230(%rax),%rax
    
    Setting skb->dev before the call in tap.c fixes the issue.
    
    BUG: kernel NULL pointer dereference, address: 0000000000000230
    RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap]
    Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48
    RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010
    RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300
    RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8
    R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001
    R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6
    FS:  0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0
    Call Trace:
     tap_get_user+0x3f1/0x540 [tap]
     tap_sendmsg+0x56/0x362 [tap]
     ? get_tx_bufs+0xc2/0x1e0 [vhost_net]
     handle_tx_copy+0x114/0x670 [vhost_net]
     handle_tx+0xb0/0xe0 [vhost_net]
     handle_tx_kick+0x15/0x20 [vhost_net]
     vhost_worker+0x7b/0xc0 [vhost]
     ? vhost_vring_call_reset+0x40/0x40 [vhost]
     kthread+0xfa/0x120
     ? kthread_complete_and_exit+0x20/0x20
     ret_from_fork+0x1f/0x30
    
    Fixes: 924a9bc362a5 ("net: check if protocol extracted by virtio_net_hdr_set_proto is correct")
    Signed-off-by: Cezar Bulinaru <cbulinaru@gmail.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da5eec7c65853fb79f2591524ef7be1dda68cb9a
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Aug 4 19:26:27 2022 +0200

    netfilter: nf_tables: fix crash when nf_trace is enabled
    
    commit 399a14ec7993d605740de7b2cd5c0ce8407d12ed upstream.
    
    do not access info->pkt when info->trace is not 1.
    nft_traceinfo is not initialized, except when tracing is enabled.
    
    The 'nft_trace_enabled' static key cannot be used for this, we must
    always check info->trace first.
    
    Pass nft_pktinfo directly to avoid this.
    
    Fixes: e34b9ed96ce3 ("netfilter: nf_tables: avoid skb access on nf_stolen")
    Reported-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e74a1e2a4d83c79e49eaa9d61ff94548f01f0611
Author: Qifu Zhang <zhangqifu@bytedance.com>
Date:   Tue Jul 19 19:50:13 2022 +0800

    Documentation: ACPI: EINJ: Fix obsolete example
    
    commit 9066e151c37950af92c3be6a7270daa8e8063db9 upstream.
    
    Since commit 488dac0c9237 ("libfs: fix error cast of negative value in
    simple_attr_write()"), the EINJ debugfs interface no longer accepts
    negative values as input. Attempt to do so will result in EINVAL.
    
    Fixes: 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()")
    Signed-off-by: Qifu Zhang <zhangqifu@bytedance.com>
    Reviewed-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6583edbf459de2e06b9759f264c0ae27e452b97a
Author: Xiu Jianfeng <xiujianfeng@huawei.com>
Date:   Tue Jun 14 17:00:01 2022 +0800

    apparmor: Fix memleak in aa_simple_write_to_buffer()
    
    commit 417ea9fe972d2654a268ad66e89c8fcae67017c3 upstream.
    
    When copy_from_user failed, the memory is freed by kvfree. however the
    management struct and data blob are allocated independently, so only
    kvfree(data) cause a memleak issue here. Use aa_put_loaddata(data) to
    fix this issue.
    
    Fixes: a6a52579e52b5 ("apparmor: split load data into management struct and data blob")
    Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ca40ad7afae144169a43988ef1a3f16182faf0a
Author: Xin Xiong <xiongx18@fudan.edu.cn>
Date:   Thu Apr 28 11:39:08 2022 +0800

    apparmor: fix reference count leak in aa_pivotroot()
    
    commit 11c3627ec6b56c1525013f336f41b79a983b4d46 upstream.
    
    The aa_pivotroot() function has a reference counting bug in a specific
    path. When aa_replace_current_label() returns on success, the function
    forgets to decrement the reference count of “target”, which is
    increased earlier by build_pivotroot(), causing a reference leak.
    
    Fix it by decreasing the refcount of “target” in that path.
    
    Fixes: 2ea3ffb7782a ("apparmor: add mount mediation")
    Co-developed-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Co-developed-by: Xin Tan <tanxin.ctf@gmail.com>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a1fffe963555096d401719342c9a1a8c752e30a
Author: John Johansen <john.johansen@canonical.com>
Date:   Sat Mar 26 01:58:15 2022 -0700

    apparmor: fix overlapping attachment computation
    
    commit 2504db207146543736e877241f3b3de005cbe056 upstream.
    
    When finding the profile via patterned attachments, the longest left
    match is being set to the static compile time value and not using the
    runtime computed value.
    
    Fix this by setting the candidate value to the greater of the
    precomputed value or runtime computed value.
    
    Fixes: 21f606610502 ("apparmor: improve overlapping domain attachment resolution")
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f91f50b890b1981f114d35cf76d85cfe751bb55c
Author: John Johansen <john.johansen@canonical.com>
Date:   Sat Mar 26 01:52:06 2022 -0700

    apparmor: fix setting unconfined mode on a loaded profile
    
    commit 3bbb7b2e9bbcd22e539e23034da753898fe3b4dc upstream.
    
    When loading a profile that is set to unconfined mode, that label
    flag is not set when it should be. Ensure it is set so that when
    used in a label the unconfined check will be applied correctly.
    
    Fixes: 038165070aa5 ("apparmor: allow setting any profile into the unconfined state")
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 705bfe4b620e027cad4591f316bc0c3b7bd0f6ca
Author: Tom Rix <trix@redhat.com>
Date:   Sun Feb 13 13:32:28 2022 -0800

    apparmor: fix aa_label_asxprint return check
    
    commit 3e2a3a0830a2090e766d0d887d52c67de2a6f323 upstream.
    
    Clang static analysis reports this issue
    label.c:1802:3: warning: 2nd function call argument
      is an uninitialized value
      pr_info("%s", str);
      ^~~~~~~~~~~~~~~~~~
    
    str is set from a successful call to aa_label_asxprint(&str, ...)
    On failure a negative value is returned, not a -1.  So change
    the check.
    
    Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels")
    Signed-off-by: Tom Rix <trix@redhat.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78ae04ce32b8d60a2cd2df3109765014719d8c3e
Author: John Johansen <john.johansen@canonical.com>
Date:   Tue Jan 25 00:37:42 2022 -0800

    apparmor: Fix failed mount permission check error message
    
    commit ec240b5905bbb09a03dccffee03062cf39e38dc2 upstream.
    
    When the mount check fails due to a permission check failure instead
    of explicitly at one of the subcomponent checks, AppArmor is reporting
    a failure in the flags match. However this is not true and AppArmor
    can not attribute the error at this point to any particular component,
    and should only indicate the mount failed due to missing permissions.
    
    Fixes: 2ea3ffb7782a ("apparmor: add mount mediation")
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af665613132c86944ece311e87dbbb8fa3f40239
Author: John Johansen <john.johansen@canonical.com>
Date:   Tue Dec 14 02:59:28 2021 -0800

    apparmor: fix absroot causing audited secids to begin with =
    
    commit 511f7b5b835726e844a5fc7444c18e4b8672edfd upstream.
    
    AppArmor is prefixing secids that are converted to secctx with the =
    to indicate the secctx should only be parsed from an absolute root
    POV. This allows catching errors where secctx are reparsed back into
    internal labels.
    
    Unfortunately because audit is using secid to secctx conversion this
    means that subject and object labels can result in a very unfortunate
    == that can break audit parsing.
    
    eg. the subj==unconfined term in the below audit message
    
    type=USER_LOGIN msg=audit(1639443365.233:160): pid=1633 uid=0 auid=1000
    ses=3 subj==unconfined msg='op=login id=1000 exe="/usr/sbin/sshd"
    hostname=192.168.122.1 addr=192.168.122.1 terminal=/dev/pts/1 res=success'
    
    Fix this by switch the prepending of = to a _. This still works as a
    special character to flag this case without breaking audit. Also move
    this check behind debug as it should not be needed during normal
    operqation.
    
    Fixes: 26b7899510ae ("apparmor: add support for absolute root view based labels")
    Reported-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a84ad486f3d2eef48655d72cb4e5a296ac86f6a8
Author: John Johansen <john.johansen@canonical.com>
Date:   Thu Apr 29 01:48:28 2021 -0700

    apparmor: fix quiet_denied for file rules
    
    commit 68ff8540cc9e4ab557065b3f635c1ff4c96e1f1c upstream.
    
    Global quieting of denied AppArmor generated file events is not
    handled correctly. Unfortunately the is checking if quieting of all
    audit events is set instead of just denied events.
    
    Fixes: 67012e8209df ("AppArmor: basic auditing infrastructure.")
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eca83750658df6888e49c9b2cb217c97683e45c1
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Mon Aug 1 22:47:16 2022 +0200

    can: ems_usb: fix clang's -Wunaligned-access warning
    
    commit a4cb6e62ea4d36e53fb3c0f18ea4503d7b76674f upstream.
    
    clang emits a -Wunaligned-access warning on struct __packed
    ems_cpc_msg.
    
    The reason is that the anonymous union msg (not declared as packed) is
    being packed right after some non naturally aligned variables (3*8
    bits + 2*32) inside a packed struct:
    
    | struct __packed ems_cpc_msg {
    |       u8 type;        /* type of message */
    |       u8 length;      /* length of data within union 'msg' */
    |       u8 msgid;       /* confirmation handle */
    |       __le32 ts_sec;  /* timestamp in seconds */
    |       __le32 ts_nsec; /* timestamp in nano seconds */
    |       /* ^ not naturally aligned */
    |
    |       union {
    |       /* ^ not declared as packed */
    |               u8 generic[64];
    |               struct cpc_can_msg can_msg;
    |               struct cpc_can_params can_params;
    |               struct cpc_confirm confirmation;
    |               struct cpc_overrun overrun;
    |               struct cpc_can_error error;
    |               struct cpc_can_err_counter err_counter;
    |               u8 can_state;
    |       } msg;
    | };
    
    Starting from LLVM 14, having an unpacked struct nested in a packed
    struct triggers a warning. c.f. [1].
    
    Fix the warning by marking the anonymous union as packed.
    
    [1] https://github.com/llvm/llvm-project/issues/55520
    
    Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface")
    Link: https://lore.kernel.org/all/20220802094021.959858-1-mkl@pengutronix.de
    Cc: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com>
    Cc: Sebastian Haas <haas@ems-wuensche.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2301e24302853ad712e3672879bbd7013bcbe71
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Thu Jun 23 15:36:59 2022 -0400

    dt-bindings: usb: mtk-xhci: Allow wakeup interrupt-names to be optional
    
    commit b2c510ffe29f20a5f6ff31ae28d32ffa494b8cfb upstream.
    
    Add missing "minItems: 1" to the interrupt-names property to allow the
    second interrupt-names, "wakeup", to be optional.
    
    Fixes: fe8e488058c4 ("dt-bindings: usb: mtk-xhci: add wakeup interrupt")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
    Link: https://lore.kernel.org/r/20220623193702.817996-2-nfraprado@collabora.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6bf741058c47b3f4cf32543e62821a6d8b23983
Author: Mohan Kumar <mkumard@nvidia.com>
Date:   Thu Aug 11 10:57:04 2022 +0530

    ALSA: hda: Fix crash due to jack poll in suspend
    
    commit 636aa8807b5780b76609b40cd3d3e1b5a225471c upstream.
    
    With jackpoll_in_suspend flag set, there is a possibility that
    jack poll worker thread will run even after system suspend was
    completed. Any register access after system pm callback flow
    will result in kernel crash as still jack poll worker thread
    tries to access registers.
    
    To fix the crash issue during system flow, cancel the jack poll
    worker thread during system pm prepare callback and cancel the
    worker thread at start of runtime suspend callback and re-schedule
    at last to avoid any unwarranted access of register by worker thread
    during suspend flow.
    
    Signed-off-by: Mohan Kumar <mkumard@nvidia.com>
    Fixes: b33115bd05af ("ALSA: hda: Jack detection poll in suspend state")
    Link: https://lore.kernel.org/r/20220811052704.2944-1-mkumard@nvidia.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7f5b9dc9bbe610c0bb1a5e40d41af5829381720
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Aug 9 09:32:59 2022 +0200

    ALSA: usb-audio: More comprehensive mixer map for ASUS ROG Zenith II
    
    commit 6bc2906253e723d1ab1acc652b55b83e286bfec2 upstream.
    
    ASUS ROG Zenith II has two USB interfaces, one for the front headphone
    and another for the rest I/O.  Currently we provided the mixer mapping
    for the latter but with an incomplete form.
    
    This patch corrects and provides more comprehensive mixer mapping, as
    well as providing the proper device names for both the front headphone
    and main audio.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211005
    Fixes: 2a48218f8e23 ("ALSA: usb-audio: Add mixer workaround for TRX40 and co")
    Link: https://lore.kernel.org/r/20220809073259.18849-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fe47d647ba9734c46fa7c048e7ffc41899ab49c
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Sat Aug 20 09:43:22 2022 -0400

    tracing: Have filter accept "common_cpu" to be consistent
    
    commit b2380577d4fe1c0ef3fa50417f1e441c016e4cbe upstream.
    
    Make filtering consistent with histograms. As "cpu" can be a field of an
    event, allow for "common_cpu" to keep it from being confused with the
    "cpu" field of the event.
    
    Link: https://lkml.kernel.org/r/20220820134401.513062765@goodmis.org
    Link: https://lore.kernel.org/all/20220820220920.e42fa32b70505b1904f0a0ad@kernel.org/
    
    Cc: stable@vger.kernel.org
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
    Cc: Tom Zanussi <zanussi@kernel.org>
    Fixes: 1e3bac71c5053 ("tracing/histogram: Rename "cpu" to "common_cpu"")
    Suggested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 511c5968711e5915b470cb9bf1c4b96bf8ba3eb5
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Sat Aug 20 09:43:21 2022 -0400

    tracing/probes: Have kprobes and uprobes use $COMM too
    
    commit ab8384442ee512fc0fc72deeb036110843d0e7ff upstream.
    
    Both $comm and $COMM can be used to get current->comm in eprobes and the
    filtering and histogram logic. Make kprobes and uprobes consistent in this
    regard and allow both $comm and $COMM as well. Currently kprobes and
    uprobes only handle $comm, which is inconsistent with the other utilities,
    and can be confusing to users.
    
    Link: https://lkml.kernel.org/r/20220820134401.317014913@goodmis.org
    Link: https://lore.kernel.org/all/20220820220442.776e1ddaf8836e82edb34d01@kernel.org/
    
    Cc: stable@vger.kernel.org
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
    Cc: Tom Zanussi <zanussi@kernel.org>
    Fixes: 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code")
    Suggested-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47cc883f21fa3bcf24891b4b455f4cd461ce2d6e
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Sat Aug 20 09:43:20 2022 -0400

    tracing/eprobes: Have event probes be consistent with kprobes and uprobes
    
    commit 6a832ec3d680b3a4f4fad5752672827d71bae501 upstream.
    
    Currently, if a symbol "@" is attempted to be used with an event probe
    (eprobes), it will cause a NULL pointer dereference crash.
    
    Both kprobes and uprobes can reference data other than the main registers.
    Such as immediate address, symbols and the current task name. Have eprobes
    do the same thing.
    
    For "comm", if "comm" is used and the event being attached to does not
    have the "comm" field, then make it the "$comm" that kprobes has. This is
    consistent to the way histograms and filters work.
    
    Link: https://lkml.kernel.org/r/20220820134401.136924220@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
    Cc: Tom Zanussi <zanussi@kernel.org>
    Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df99a48b6b115923990707038ada529d6d45bebd
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Sat Aug 20 09:43:19 2022 -0400

    tracing/eprobes: Fix reading of string fields
    
    commit f04dec93466a0481763f3b56cdadf8076e28bfbf upstream.
    
    Currently when an event probe (eprobe) hooks to a string field, it does
    not display it as a string, but instead as a number. This makes the field
    rather useless. Handle the different kinds of strings, dynamic, static,
    relational/dynamic etc.
    
    Now when a string field is used, the ":string" type can be used to display
    it:
    
      echo "e:sw sched/sched_switch comm=$next_comm:string" > dynamic_events
    
    Link: https://lkml.kernel.org/r/20220820134400.959640191@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
    Cc: Tom Zanussi <zanussi@kernel.org>
    Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events")
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f1c65a325fa3a950fe9a05c562f9d9af17ff658
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Sat Aug 20 09:43:18 2022 -0400

    tracing/eprobes: Do not hardcode $comm as a string
    
    commit 02333de90e5945e2fe7fc75b15b4eb9aee187f0a upstream.
    
    The variable $comm is hard coded as a string, which is true for both
    kprobes and uprobes, but for event probes (eprobes) it is a field name. In
    most cases the "comm" field would be a string, but there's no guarantee of
    that fact.
    
    Do not assume that comm is a string. Not to mention, it currently forces
    comm fields to fault, as string processing for event probes is currently
    broken.
    
    Link: https://lkml.kernel.org/r/20220820134400.756152112@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
    Cc: Tom Zanussi <zanussi@kernel.org>
    Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c262114a576d94c0ced80e232bbb17391a55908
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Sat Aug 20 09:43:17 2022 -0400

    tracing/eprobes: Do not allow eprobes to use $stack, or % for regs
    
    commit 2673c60ee67e71f2ebe34386e62d348f71edee47 upstream.
    
    While playing with event probes (eprobes), I tried to see what would
    happen if I attempted to retrieve the instruction pointer (%rip) knowing
    that event probes do not use pt_regs. The result was:
    
     BUG: kernel NULL pointer dereference, address: 0000000000000024
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: 0000 [#1] PREEMPT SMP PTI
     CPU: 1 PID: 1847 Comm: trace-cmd Not tainted 5.19.0-rc5-test+ #309
     Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01
    v03.03 07/14/2016
     RIP: 0010:get_event_field.isra.0+0x0/0x50
     Code: ff 48 c7 c7 c0 8f 74 a1 e8 3d 8b f5 ff e8 88 09 f6 ff 4c 89 e7 e8
    50 6a 13 00 48 89 ef 5b 5d 41 5c 41 5d e9 42 6a 13 00 66 90 <48> 63 47 24
    8b 57 2c 48 01 c6 8b 47 28 83 f8 02 74 0e 83 f8 04 74
     RSP: 0018:ffff916c394bbaf0 EFLAGS: 00010086
     RAX: ffff916c854041d8 RBX: ffff916c8d9fbf50 RCX: ffff916c255d2000
     RDX: 0000000000000000 RSI: ffff916c255d2008 RDI: 0000000000000000
     RBP: 0000000000000000 R08: ffff916c3a2a0c08 R09: ffff916c394bbda8
     R10: 0000000000000000 R11: 0000000000000000 R12: ffff916c854041d8
     R13: ffff916c854041b0 R14: 0000000000000000 R15: 0000000000000000
     FS:  0000000000000000(0000) GS:ffff916c9ea40000(0000)
    knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000024 CR3: 000000011b60a002 CR4: 00000000001706e0
     Call Trace:
      <TASK>
      get_eprobe_size+0xb4/0x640
      ? __mod_node_page_state+0x72/0xc0
      __eprobe_trace_func+0x59/0x1a0
      ? __mod_lruvec_page_state+0xaa/0x1b0
      ? page_remove_file_rmap+0x14/0x230
      ? page_remove_rmap+0xda/0x170
      event_triggers_call+0x52/0xe0
      trace_event_buffer_commit+0x18f/0x240
      trace_event_raw_event_sched_wakeup_template+0x7a/0xb0
      try_to_wake_up+0x260/0x4c0
      __wake_up_common+0x80/0x180
      __wake_up_common_lock+0x7c/0xc0
      do_notify_parent+0x1c9/0x2a0
      exit_notify+0x1a9/0x220
      do_exit+0x2ba/0x450
      do_group_exit+0x2d/0x90
      __x64_sys_exit_group+0x14/0x20
      do_syscall_64+0x3b/0x90
      entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Obviously this is not the desired result.
    
    Move the testing for TPARG_FL_TPOINT which is only used for event probes
    to the top of the "$" variable check, as all the other variables are not
    used for event probes. Also add a check in the register parsing "%" to
    fail if an event probe is used.
    
    Link: https://lkml.kernel.org/r/20220820134400.564426983@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
    Cc: Tom Zanussi <zanussi@kernel.org>
    Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events")
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 543b4a1dc28fb6cd5f32358bb737c2eb7de4bc27
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Aug 16 19:28:17 2022 -0400

    tracing/perf: Fix double put of trace event when init fails
    
    commit 7249921d94ff64f67b733eca0b68853a62032b3d upstream.
    
    If in perf_trace_event_init(), the perf_trace_event_open() fails, then it
    will call perf_trace_event_unreg() which will not only unregister the perf
    trace event, but will also call the put() function of the tp_event.
    
    The problem here is that the trace_event_try_get_ref() is called by the
    caller of perf_trace_event_init() and if perf_trace_event_init() returns a
    failure, it will then call trace_event_put(). But since the
    perf_trace_event_unreg() already called the trace_event_put() function, it
    triggers a WARN_ON().
    
     WARNING: CPU: 1 PID: 30309 at kernel/trace/trace_dynevent.c:46 trace_event_dyn_put_ref+0x15/0x20
    
    If perf_trace_event_reg() does not call the trace_event_try_get_ref() then
    the perf_trace_event_unreg() should not be calling trace_event_put(). This
    breaks symmetry and causes bugs like these.
    
    Pull out the trace_event_put() from perf_trace_event_unreg() and call it
    in the locations that perf_trace_event_unreg() is called. This not only
    fixes this bug, but also brings back the proper symmetry of the reg/unreg
    vs get/put logic.
    
    Link: https://lore.kernel.org/all/cover.1660347763.git.kjlx@templeofstupid.com/
    Link: https://lkml.kernel.org/r/20220816192817.43d5e17f@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Fixes: 1d18538e6a092 ("tracing: Have dynamic events have a ref counter")
    Reported-by: Krister Johansen <kjlx@templeofstupid.com>
    Reviewed-by: Krister Johansen <kjlx@templeofstupid.com>
    Tested-by: Krister Johansen <kjlx@templeofstupid.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f624910db300f950b9c81ed28957db584cd06244
Author: Nadav Amit <namit@vmware.com>
Date:   Sat Aug 13 15:59:43 2022 -0700

    x86/kprobes: Fix JNG/JNLE emulation
    
    commit 8924779df820c53875abaeb10c648e9cb75b46d4 upstream.
    
    When kprobes emulates JNG/JNLE instructions on x86 it uses the wrong
    condition. For JNG (opcode: 0F 8E), according to Intel SDM, the jump is
    performed if (ZF == 1 or SF != OF). However the kernel emulation
    currently uses 'and' instead of 'or'.
    
    As a result, setting a kprobe on JNG/JNLE might cause the kernel to
    behave incorrectly whenever the kprobe is hit.
    
    Fix by changing the 'and' to 'or'.
    
    Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step")
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220813225943.143767-1-namit@vmware.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60b6d38add7b9c17d6e5d49ee8e930ea1a5650c5
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Thu Aug 18 21:50:44 2022 +0800

    cifs: Fix memory leak on the deferred close
    
    commit ca08d0eac020d48a3141dbec0a3cf64fbdb17cde upstream.
    
    xfstests on smb21 report kmemleak as below:
    
      unreferenced object 0xffff8881767d6200 (size 64):
        comm "xfs_io", pid 1284, jiffies 4294777434 (age 20.789s)
        hex dump (first 32 bytes):
          80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff  .Z......x..c....
          00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00  .q.v............
        backtrace:
          [<00000000ad04e6ea>] cifs_close+0x92/0x2c0
          [<0000000028b93c82>] __fput+0xff/0x3f0
          [<00000000d8116851>] task_work_run+0x85/0xc0
          [<0000000027e14f9e>] do_exit+0x5e5/0x1240
          [<00000000fb492b95>] do_group_exit+0x58/0xe0
          [<00000000129a32d9>] __x64_sys_exit_group+0x28/0x30
          [<00000000e3f7d8e9>] do_syscall_64+0x35/0x80
          [<00000000102e8a0b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    When cancel the deferred close work, we should also cleanup the struct
    cifs_deferred_close.
    
    Fixes: 9e992755be8f2 ("cifs: Call close synchronously during unlink/rename/lease break.")
    Fixes: e3fc065682ebb ("cifs: Deferred close performance improvements")
    Cc: stable@vger.kernel.org
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17c3edc70ff3eaf71a31072cc7e7fd8c9b6bf4e3
Author: Mauro Carvalho Chehab <mchehab@kernel.org>
Date:   Thu Aug 4 09:37:22 2022 +0200

    drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()
    
    commit 9d50bff40e3e366886ec37299fc317edf84be0c9 upstream.
    
    WRITE_ONCE() should happen at the original var, not on a local
    copy of it.
    
    Cc: stable@vger.kernel.org
    Fixes: 59eda6ce824e ("drm/i915/gt: Batch TLB invalidations")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    [added cc-stable while merging it]
    Link: https://patchwork.freedesktop.org/patch/msgid/f9550e6bacea10131ff40dd8981b69eb9251cdcd.1659598090.git.mchehab@kernel.org
    (cherry picked from commit 3d037d99e61a1e7a3ae3d214146d88db349dd19f)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26d7e3fcf0af9d507cd8d9b52820b8bb1dcafd24
Author: Chris Wilson <chris.p.wilson@intel.com>
Date:   Wed Jul 27 14:29:55 2022 +0200

    drm/i915/gt: Batch TLB invalidations
    
    commit 59eda6ce824e95b98c45628fe6c0adb9130c6df2 upstream.
    
    Invalidate TLB in batches, in order to reduce performance regressions.
    
    Currently, every caller performs a full barrier around a TLB
    invalidation, ignoring all other invalidations that may have already
    removed their PTEs from the cache. As this is a synchronous operation
    and can be quite slow, we cause multiple threads to contend on the TLB
    invalidate mutex blocking userspace.
    
    We only need to invalidate the TLB once after replacing our PTE to
    ensure that there is no possible continued access to the physical
    address before releasing our pages. By tracking a seqno for each full
    TLB invalidate we can quickly determine if one has been performed since
    rewriting the PTE, and only if necessary trigger one for ourselves.
    
    That helps to reduce the performance regression introduced by TLB
    invalidate logic.
    
    [mchehab: rebased to not require moving the code to a separate file]
    
    Cc: stable@vger.kernel.org
    Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
    Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
    Cc: Fei Yang <fei.yang@intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/4e97ef5deb6739cadaaf40aa45620547e9c4ec06.1658924372.git.mchehab@kernel.org
    (cherry picked from commit 5d36acb7198b0e5eb88e6b701f9ad7b9448f8df9)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99a4dbc0328d917e587014afa23c0b057232f95f
Author: Chris Wilson <chris.p.wilson@intel.com>
Date:   Wed Jul 27 14:29:54 2022 +0200

    drm/i915/gt: Skip TLB invalidations once wedged
    
    commit e5a95c83ed1492c0f442b448b20c90c8faaf702b upstream.
    
    Skip all further TLB invalidations once the device is wedged and
    had been reset, as, on such cases, it can no longer process instructions
    on the GPU and the user no longer has access to the TLB's in each engine.
    
    So, an attempt to do a TLB cache invalidation will produce a timeout.
    
    That helps to reduce the performance regression introduced by TLB
    invalidate logic.
    
    Cc: stable@vger.kernel.org
    Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
    Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
    Cc: Fei Yang <fei.yang@intel.com>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/5aa86564b9ec5fe7fe605c1dd7de76855401ed73.1658924372.git.mchehab@kernel.org
    (cherry picked from commit be0366f168033374a93e4c43fdaa1a90ab905184)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a965f1822eabb088891e8590524c0800bb1bee73
Author: Chris Wilson <chris.p.wilson@intel.com>
Date:   Wed Jul 27 14:29:53 2022 +0200

    drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations
    
    commit 180abeb2c5032704787151135b6a38c6b71295a6 upstream.
    
    Ensure that the TLB of the OA unit is also invalidated
    on gen12 HW, as just invalidating the TLB of an engine is not
    enough.
    
    Cc: stable@vger.kernel.org
    Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
    Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
    Cc: Fei Yang <fei.yang@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/59724d9f5cf1e93b1620d01b8332ac991555283d.1658924372.git.mchehab@kernel.org
    (cherry picked from commit dfc83de118ff7930acc9a4c8dfdba7c153aa44d6)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f121b71c263875da54c389fe0153024e658d04c
Author: Chris Wilson <chris.p.wilson@intel.com>
Date:   Wed Jul 27 14:29:51 2022 +0200

    drm/i915/gt: Ignore TLB invalidations on idle engines
    
    commit db100e28fdf026a1fc10657c5170bb1e65663805 upstream.
    
    Check if the device is powered down prior to any engine activity,
    as, on such cases, all the TLBs were already invalidated, so an
    explicit TLB invalidation is not needed, thus reducing the
    performance regression impact due to it.
    
    This becomes more significant with GuC, as it can only do so when
    the connection to the GuC is awake.
    
    Cc: stable@vger.kernel.org
    Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
    Signed-off-by: Chris Wilson <chris.p.wilson@intel.com>
    Cc: Fei Yang <fei.yang@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/278a57a672edac75683f0818b292e95da583a5fe.1658924372.git.mchehab@kernel.org
    (cherry picked from commit 4bedceaed1ae1172cfe72d3ff752b3a1d32fe4d9)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 119ac4818a22c8cd3a6d44705fc7b2e0aff85936
Author: Likun Gao <Likun.Gao@amd.com>
Date:   Wed Aug 3 12:16:35 2022 +0800

    drm/amdgpu: change vram width algorithm for vram_info v3_0
    
    commit 4a0a2cf4c03ba49a4c2596c49c7daa719917d509 upstream.
    
    Update the vram width algorithm for vram_info v3_0 to align with the
    changes of latest IFWI.
    
    Signed-off-by: Likun Gao <Likun.Gao@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 5.19.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01d0ea8d3db10662bda6eb641bd6ad6c13865b2d
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Aug 1 14:57:52 2022 +0100

    btrfs: fix warning during log replay when bumping inode link count
    
    commit 769030e11847c5412270c0726ff21d3a1f0a3131 upstream.
    
    During log replay, at add_link(), we may increment the link count of
    another inode that has a reference that conflicts with a new reference
    for the inode currently being processed.
    
    During log replay, at add_link(), we may drop (unlink) a reference from
    some inode in the subvolume tree if that reference conflicts with a new
    reference found in the log for the inode we are currently processing.
    
    After the unlink, If the link count has decreased from 1 to 0, then we
    increment the link count to prevent the inode from being deleted if it's
    evicted by an iput() call, because we may have references to add to that
    inode later on (and we will fixup its link count later during log replay).
    
    However incrementing the link count from 0 to 1 triggers a warning:
    
      $ cat fs/inode.c
      (...)
      void inc_nlink(struct inode *inode)
      {
            if (unlikely(inode->i_nlink == 0)) {
                     WARN_ON(!(inode->i_state & I_LINKABLE));
                     atomic_long_dec(&inode->i_sb->s_remove_count);
            }
      (...)
    
    The I_LINKABLE flag is only set when creating an O_TMPFILE file, so it's
    never set during log replay.
    
    Most of the time, the warning isn't triggered even if we dropped the last
    reference of the conflicting inode, and this is because:
    
    1) The conflicting inode was previously marked for fixup, through a call
       to link_to_fixup_dir(), which increments the inode's link count;
    
    2) And the last iput() on the inode has not triggered eviction of the
       inode, nor was eviction triggered after the iput(). So at add_link(),
       even if we unlink the last reference of the inode, its link count ends
       up being 1 and not 0.
    
    So this means that if eviction is triggered after link_to_fixup_dir() is
    called, at add_link() we will read the inode back from the subvolume tree
    and have it with a correct link count, matching the number of references
    it has on the subvolume tree. So if when we are at add_link() the inode
    has exactly one reference only, its link count is 1, and after the unlink
    its link count becomes 0.
    
    So fix this by using set_nlink() instead of inc_nlink(), as the former
    accepts a transition from 0 to 1 and it's what we use in other similar
    contexts (like at link_to_fixup_dir().
    
    Also make add_inode_ref() use set_nlink() instead of inc_nlink() to
    bump the link count from 0 to 1.
    
    The warning is actually harmless, but it may scare users. Josef also ran
    into it recently.
    
    CC: stable@vger.kernel.org # 5.1+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f7e9cfbfbdcafd34b067deadf2e5d57cd749635
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Aug 1 14:57:51 2022 +0100

    btrfs: fix lost error handling when looking up extended ref on log replay
    
    commit 7a6b75b79902e47f46328b57733f2604774fa2d9 upstream.
    
    During log replay, when processing inode references, if we get an error
    when looking up for an extended reference at __add_inode_ref(), we ignore
    it and proceed, returning success (0) if no other error happens after the
    lookup. This is obviously wrong because in case an extended reference
    exists and it encodes some name not in the log, we need to unlink it,
    otherwise the filesystem state will not match the state it had after the
    last fsync.
    
    So just make __add_inode_ref() return an error it gets from the extended
    reference lookup.
    
    Fixes: f186373fef005c ("btrfs: extended inode refs")
    CC: stable@vger.kernel.org # 4.9+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28546ac036822d6d198f42f53db7f2cd3a044fdc
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Mon Jul 25 13:05:05 2022 -0400

    btrfs: reset RO counter on block group if we fail to relocate
    
    commit 74944c873602a3ed8d16ff7af3f64af80c0f9dac upstream.
    
    With the automatic block group reclaim code we will preemptively try to
    mark the block group RO before we start the relocation.  We do this to
    make sure we should actually try to relocate the block group.
    
    However if we hit an error during the actual relocation we won't clean
    up our RO counter and the block group will remain RO.  This was observed
    internally with file systems reporting less space available from df when
    we had failed background relocations.
    
    Fix this by doing the dec_ro in the error case.
    
    Fixes: 18bb8bbf13c1 ("btrfs: zoned: automatically reclaim zones")
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Boris Burkov <boris@bur.io>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5d741afed0bac206640cc64d77b97853283cf719
Author: Zixuan Fu <r33s3n6@gmail.com>
Date:   Thu Jul 21 15:48:29 2022 +0800

    btrfs: unset reloc control if transaction commit fails in prepare_to_relocate()
    
    commit 85f02d6c856b9f3a0acf5219de6e32f58b9778eb upstream.
    
    In btrfs_relocate_block_group(), the rc is allocated.  Then
    btrfs_relocate_block_group() calls
    
    relocate_block_group()
      prepare_to_relocate()
        set_reloc_control()
    
    that assigns rc to the variable fs_info->reloc_ctl. When
    prepare_to_relocate() returns, it calls
    
    btrfs_commit_transaction()
      btrfs_start_dirty_block_groups()
        btrfs_alloc_path()
          kmem_cache_zalloc()
    
    which may fail for example (or other errors could happen). When the
    failure occurs, btrfs_relocate_block_group() detects the error and frees
    rc and doesn't set fs_info->reloc_ctl to NULL. After that, in
    btrfs_init_reloc_root(), rc is retrieved from fs_info->reloc_ctl and
    then used, which may cause a use-after-free bug.
    
    This possible bug can be triggered by calling btrfs_ioctl_balance()
    before calling btrfs_ioctl_defrag().
    
    To fix this possible bug, in prepare_to_relocate(), check if
    btrfs_commit_transaction() fails. If the failure occurs,
    unset_reloc_control() is called to set fs_info->reloc_ctl to NULL.
    
    The error log in our fault-injection testing is shown as follows:
    
      [   58.751070] BUG: KASAN: use-after-free in btrfs_init_reloc_root+0x7ca/0x920 [btrfs]
      ...
      [   58.753577] Call Trace:
      ...
      [   58.755800]  kasan_report+0x45/0x60
      [   58.756066]  btrfs_init_reloc_root+0x7ca/0x920 [btrfs]
      [   58.757304]  record_root_in_trans+0x792/0xa10 [btrfs]
      [   58.757748]  btrfs_record_root_in_trans+0x463/0x4f0 [btrfs]
      [   58.758231]  start_transaction+0x896/0x2950 [btrfs]
      [   58.758661]  btrfs_defrag_root+0x250/0xc00 [btrfs]
      [   58.759083]  btrfs_ioctl_defrag+0x467/0xa00 [btrfs]
      [   58.759513]  btrfs_ioctl+0x3c95/0x114e0 [btrfs]
      ...
      [   58.768510] Allocated by task 23683:
      [   58.768777]  ____kasan_kmalloc+0xb5/0xf0
      [   58.769069]  __kmalloc+0x227/0x3d0
      [   58.769325]  alloc_reloc_control+0x10a/0x3d0 [btrfs]
      [   58.769755]  btrfs_relocate_block_group+0x7aa/0x1e20 [btrfs]
      [   58.770228]  btrfs_relocate_chunk+0xf1/0x760 [btrfs]
      [   58.770655]  __btrfs_balance+0x1326/0x1f10 [btrfs]
      [   58.771071]  btrfs_balance+0x3150/0x3d30 [btrfs]
      [   58.771472]  btrfs_ioctl_balance+0xd84/0x1410 [btrfs]
      [   58.771902]  btrfs_ioctl+0x4caa/0x114e0 [btrfs]
      ...
      [   58.773337] Freed by task 23683:
      ...
      [   58.774815]  kfree+0xda/0x2b0
      [   58.775038]  free_reloc_control+0x1d6/0x220 [btrfs]
      [   58.775465]  btrfs_relocate_block_group+0x115c/0x1e20 [btrfs]
      [   58.775944]  btrfs_relocate_chunk+0xf1/0x760 [btrfs]
      [   58.776369]  __btrfs_balance+0x1326/0x1f10 [btrfs]
      [   58.776784]  btrfs_balance+0x3150/0x3d30 [btrfs]
      [   58.777185]  btrfs_ioctl_balance+0xd84/0x1410 [btrfs]
      [   58.777621]  btrfs_ioctl+0x4caa/0x114e0 [btrfs]
      ...
    
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: Zixuan Fu <r33s3n6@gmail.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d37c5f24d1c8693f25ed1934ed0ce429210aa3e2
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Aug 7 08:56:38 2022 +0200

    mmc: meson-gx: Fix an error handling path in meson_mmc_probe()
    
    commit b3e1cf31154136da855f3cb6117c17eb0b6bcfb4 upstream.
    
    The commit in Fixes has introduced a new error handling which should goto
    the existing error handling path.
    Otherwise some resources leak.
    
    Fixes: 19c6beaa064c ("mmc: meson-gx: add device reset")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/be4b863bacf323521ba3a02efdc4fca9cdedd1a6.1659855351.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2de2030f37d4bfc6505c766bce96aa3c336e4fc5
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Jul 26 21:15:43 2022 +0200

    mmc: pxamci: Fix an error handling path in pxamci_probe()
    
    commit 98d7c5e5792b8ce3e1352196dac7f404bb1b46ec upstream.
    
    The commit in Fixes: has moved some code around without updating gotos to
    the error handling path.
    
    Update it now and release some resources if pxamci_of_init() fails.
    
    Fixes: fa3a5115469c ("mmc: pxamci: call mmc_of_parse()")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/6d75855ad4e2470e9ed99e0df21bc30f0c925a29.1658862932.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21d4c35e8dc3bfedc8ee438b46d34e791697d5fe
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Jul 26 21:15:51 2022 +0200

    mmc: pxamci: Fix another error handling path in pxamci_probe()
    
    commit b886f54c300d31c109d2e4336b22922b64e7ba7d upstream.
    
    The commit in Fixes: has introduced an new error handling without branching
    to the existing error handling path.
    
    Update it now and release some resources if pxamci_init_ocr() fails.
    
    Fixes: 61951fd6cb49 ("mmc: pxamci: let mmc core handle regulators")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/07a2dcebf8ede69b484103de8f9df043f158cffd.1658862932.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97f0f52c4ea5a3bd8a00a950fcca5bf4de1f9473
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Fri Aug 12 02:29:53 2022 +0900

    ata: libata-eh: Add missing command name
    
    commit d3122bf9aa4c974f5e2c0112f799757b3a2779da upstream.
    
    Add the missing command name for ATA_CMD_NCQ_NON_DATA to
    ata_get_cmd_name().
    
    Fixes: 661ce1f0c4a6 ("libata/libsas: Define ATA_CMD_NCQ_NON_DATA")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae2e4f9d983ec40fbd53af98a2d7b343ca5df73a
Author: Harald Freudenberger <freude@linux.ibm.com>
Date:   Fri Jul 15 12:23:48 2022 +0200

    s390/ap: fix crash on older machines based on QCI info missing
    
    commit 0fef40be5d1f8e7af3d61e8827a63c5862cd99f7 upstream.
    
    On older z series machines (z12 and older) there is no QCI info
    available. The AP code took care of this and the AP bus scan then
    switched to simple probing via TAPQ.
    
    With commit
    283915850a44 ("s390/ap: notify drivers on config changed and scan complete callbacks")
    some code was introduced which silently assumed that the QCI info is
    always available. However, with KVM simulating an older machine (z12)
    the result was a kernel crash. Funnily the same crash does not happen
    on LPAR - maybe because NULL is a valid pointer and reading some data
    from address 0 also works fine.
    
    This fix now improves the code to be aware that the QCI instruction
    may not be available on older machines and thus the two pointers to
    QCI info structs may simple be NULL.
    
    However, on a machine not providing the QCI info the two callbacks to
    the zcrypt device drivers on_config_changed() and on_scan_complete()
    provide parameters which are pointers to a QCI info struct.
    These both callbacks are NOT served if there is no QCI info available.
    The only consumer of these callbacks is the vfio device driver. This
    driver only supports CEX4 and higher. All physical machines which are
    able to provide CEX4 cards have QCI support available. So there is
    no sense in for example fill the QCI info struct by hand with looping
    over cards and queues and TAPQ each APQN.
    
    Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
    Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
    Cc: stable@vger.kernel.org
    Fixes: 283915850a44 ("s390/ap: notify drivers on config changed and scan complete callbacks")
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c31dca1799612eb3b6413e3e574f90c3fb8f865
Author: Aurabindo Pillai <aurabindo.pillai@amd.com>
Date:   Tue Jul 26 13:13:27 2022 -0400

    drm/amd/display: Check correct bounds for stream encoder instances for DCN303
    
    commit 89b008222c2bf21e50219725caed31590edfd9d1 upstream.
    
    [Why & How]
    eng_id for DCN303 cannot be more than 1, since we have only two
    instances of stream encoders.
    
    Check the correct boundary condition for engine ID for DCN303 prevent
    the potential out of bounds access.
    
    Fixes: cd6d421e3d1a ("drm/amd/display: Initial DC support for Beige Goby")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Chris Park <Chris.Park@amd.com>
    Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2cb62b2f68c8a67cde93f5f9f59ac907692c966c
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Aug 9 11:44:05 2022 -0400

    drm/amdgpu: Only disable prefer_shadow on hawaii
    
    commit a6250bdb6c4677ee77d699b338e077b900f94c0c upstream.
    
    We changed it for all asics due to a hibernation regression
    on hawaii, but the workaround breaks suspend on a polaris12.
    Just disable it for hawaii.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216119
    Fixes: 3a4b1cc28fbd ("drm/amdgpu/display: disable prefer_shadow for generic fb helpers")
    Reviewed-and-tested-by: Mario Limonciello <mario.limonciello@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 9bd970d4097287778a4449452e70b35d0bfaa3aa
Author: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Date:   Tue Aug 9 02:56:23 2022 -0700

    drm/ttm: Fix dummy res NULL ptr deref bug
    
    commit cf4b7387c0a842d64bdd7c353e6d3298174a7740 upstream.
    
    Check the bo->resource value before accessing the resource
    mem_type.
    
    v2: Fix commit description unwrapped warning
    
    <log snip>
    [   40.191227][  T184] general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI
    [   40.192995][  T184] KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
    [   40.194411][  T184] CPU: 1 PID: 184 Comm: systemd-udevd Not tainted 5.19.0-rc4-00721-gb297c22b7070 #1
    [   40.196063][  T184] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
    [   40.199605][  T184] RIP: 0010:ttm_bo_validate+0x1b3/0x240 [ttm]
    [   40.200754][  T184] Code: e8 72 c5 ff ff 83 f8 b8 74 d4 85 c0 75 54 49 8b 9e 58 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 10 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 3c 03 7e 44 8b 53 10 31 c0 85 d2 0f 85 58
    [   40.203685][  T184] RSP: 0018:ffffc900006df0c8 EFLAGS: 00010202
    [   40.204630][  T184] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 1ffff1102f4bb71b
    [   40.205864][  T184] RDX: 0000000000000002 RSI: ffffc900006df208 RDI: 0000000000000010
    [   40.207102][  T184] RBP: 1ffff920000dbe1a R08: ffffc900006df208 R09: 0000000000000000
    [   40.208394][  T184] R10: ffff88817a5f0000 R11: 0000000000000001 R12: ffffc900006df110
    [   40.209692][  T184] R13: ffffc900006df0f0 R14: ffff88817a5db800 R15: ffffc900006df208
    [   40.210862][  T184] FS:  00007f6b1d16e8c0(0000) GS:ffff88839d700000(0000) knlGS:0000000000000000
    [   40.212250][  T184] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   40.213275][  T184] CR2: 000055a1001d4ff0 CR3: 00000001700f4000 CR4: 00000000000006e0
    [   40.214469][  T184] Call Trace:
    [   40.214974][  T184]  <TASK>
    [   40.215438][  T184]  ? ttm_bo_bounce_temp_buffer+0x140/0x140 [ttm]
    [   40.216572][  T184]  ? mutex_spin_on_owner+0x240/0x240
    [   40.217456][  T184]  ? drm_vma_offset_add+0xaa/0x100 [drm]
    [   40.218457][  T184]  ttm_bo_init_reserved+0x3d6/0x540 [ttm]
    [   40.219410][  T184]  ? shmem_get_inode+0x744/0x980
    [   40.220231][  T184]  ttm_bo_init_validate+0xb1/0x200 [ttm]
    [   40.221172][  T184]  ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper]
    [   40.222530][  T184]  ? ttm_bo_init_reserved+0x540/0x540 [ttm]
    [   40.223643][  T184]  ? __do_sys_finit_module+0x11a/0x1c0
    [   40.224654][  T184]  ? __shmem_file_setup+0x102/0x280
    [   40.234764][  T184]  drm_gem_vram_create+0x305/0x480 [drm_vram_helper]
    [   40.235766][  T184]  ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper]
    [   40.236846][  T184]  ? __kasan_slab_free+0x108/0x180
    [   40.237650][  T184]  drm_gem_vram_fill_create_dumb+0x134/0x340 [drm_vram_helper]
    [   40.238864][  T184]  ? local_pci_probe+0xdf/0x180
    [   40.239674][  T184]  ? drmm_vram_helper_init+0x400/0x400 [drm_vram_helper]
    [   40.240826][  T184]  drm_client_framebuffer_create+0x19c/0x400 [drm]
    [   40.241955][  T184]  ? drm_client_buffer_delete+0x200/0x200 [drm]
    [   40.243001][  T184]  ? drm_client_pick_crtcs+0x554/0xb80 [drm]
    [   40.244030][  T184]  drm_fb_helper_generic_probe+0x23f/0x940 [drm_kms_helper]
    [   40.245226][  T184]  ? __cond_resched+0x1c/0xc0
    [   40.245987][  T184]  ? drm_fb_helper_memory_range_to_clip+0x180/0x180 [drm_kms_helper]
    [   40.247316][  T184]  ? mutex_unlock+0x80/0x100
    [   40.248005][  T184]  ? __mutex_unlock_slowpath+0x2c0/0x2c0
    [   40.249083][  T184]  drm_fb_helper_single_fb_probe+0x907/0xf00 [drm_kms_helper]
    [   40.250314][  T184]  ? drm_fb_helper_check_var+0x1180/0x1180 [drm_kms_helper]
    [   40.251540][  T184]  ? __cond_resched+0x1c/0xc0
    [   40.252321][  T184]  ? mutex_lock+0x9f/0x100
    [   40.253062][  T184]  __drm_fb_helper_initial_config_and_unlock+0xb9/0x2c0 [drm_kms_helper]
    [   40.254394][  T184]  drm_fbdev_client_hotplug+0x56f/0x840 [drm_kms_helper]
    [   40.255477][  T184]  drm_fbdev_generic_setup+0x165/0x3c0 [drm_kms_helper]
    [   40.256607][  T184]  bochs_pci_probe+0x6b7/0x900 [bochs]
    [   40.257515][  T184]  ? _raw_spin_lock_irqsave+0x87/0x100
    [   40.258312][  T184]  ? bochs_hw_init+0x480/0x480 [bochs]
    [   40.259244][  T184]  ? bochs_hw_init+0x480/0x480 [bochs]
    [   40.260186][  T184]  local_pci_probe+0xdf/0x180
    [   40.260928][  T184]  pci_call_probe+0x15f/0x500
    [   40.265798][  T184]  ? _raw_spin_lock+0x81/0x100
    [   40.266508][  T184]  ? pci_pm_suspend_noirq+0x980/0x980
    [   40.267322][  T184]  ? pci_assign_irq+0x81/0x280
    [   40.268096][  T184]  ? pci_match_device+0x351/0x6c0
    [   40.268883][  T184]  ? kernfs_put+0x18/0x40
    [   40.269611][  T184]  pci_device_probe+0xee/0x240
    [   40.270352][  T184]  really_probe+0x435/0xa80
    [   40.271021][  T184]  __driver_probe_device+0x2ab/0x480
    [   40.271828][  T184]  driver_probe_device+0x49/0x140
    [   40.272627][  T184]  __driver_attach+0x1bd/0x4c0
    [   40.273372][  T184]  ? __device_attach_driver+0x240/0x240
    [   40.274273][  T184]  bus_for_each_dev+0x11e/0x1c0
    [   40.275080][  T184]  ? subsys_dev_iter_exit+0x40/0x40
    [   40.275951][  T184]  ? klist_add_tail+0x132/0x280
    [   40.276767][  T184]  bus_add_driver+0x39b/0x580
    [   40.277574][  T184]  driver_register+0x20f/0x3c0
    [   40.278281][  T184]  ? 0xffffffffc04a2000
    [   40.278894][  T184]  do_one_initcall+0x8a/0x300
    [   40.279642][  T184]  ? trace_event_raw_event_initcall_level+0x1c0/0x1c0
    [   40.280707][  T184]  ? kasan_unpoison+0x23/0x80
    [   40.281479][  T184]  ? kasan_unpoison+0x23/0x80
    [   40.282197][  T184]  do_init_module+0x190/0x640
    [   40.282926][  T184]  load_module+0x221b/0x2780
    [   40.283611][  T184]  ? layout_and_allocate+0x5c0/0x5c0
    [   40.284401][  T184]  ? kernel_read_file+0x286/0x6c0
    [   40.285216][  T184]  ? __x64_sys_fspick+0x2c0/0x2c0
    [   40.286043][  T184]  ? mmap_region+0x4e7/0x1300
    [   40.286832][  T184]  ? __do_sys_finit_module+0x11a/0x1c0
    [   40.287743][  T184]  __do_sys_finit_module+0x11a/0x1c0
    [   40.288636][  T184]  ? __ia32_sys_init_module+0xc0/0xc0
    [   40.289557][  T184]  ? __seccomp_filter+0x15e/0xc80
    [   40.290341][  T184]  ? vm_mmap_pgoff+0x185/0x240
    [   40.291060][  T184]  do_syscall_64+0x3b/0xc0
    [   40.291763][  T184]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [   40.292678][  T184] RIP: 0033:0x7f6b1d6279b9
    [   40.293438][  T184] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48
    [   40.296302][  T184] RSP: 002b:00007ffe7f51b798 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
    [   40.297633][  T184] RAX: ffffffffffffffda RBX: 00005642dcca2880 RCX: 00007f6b1d6279b9
    [   40.298890][  T184] RDX: 0000000000000000 RSI: 00007f6b1d7b2e2d RDI: 0000000000000016
    [   40.300199][  T184] RBP: 0000000000020000 R08: 0000000000000000 R09: 00005642dccd5530
    [   40.301547][  T184] R10: 0000000000000016 R11: 0000000000000246 R12: 00007f6b1d7b2e2d
    [   40.302698][  T184] R13: 0000000000000000 R14: 00005642dcca4230 R15: 00005642dcca2880
    
    Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220726162205.2778-1-Arunpravin.PaneerSelvam@amd.com
    Link: https://patchwork.freedesktop.org/patch/msgid/20220809095623.3569-1-Arunpravin.PaneerSelvam@amd.com
    Signed-off-by: Christian König <christian.koenig@amd.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ed00422d72b131f2a9fbc7ddb1c6aebba6413cf
Author: Karol Herbst <kherbst@redhat.com>
Date:   Wed Aug 3 16:27:45 2022 +0200

    drm/nouveau: recognise GA103
    
    commit c20ee5749a3f688d9bab83a3b09b75587153ff13 upstream.
    
    Appears to be ok with general GA10x code.
    
    Signed-off-by: Karol Herbst <kherbst@redhat.com>
    Cc: <stable@vger.kernel.org> # v5.15+
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220803142745.2679510-1-kherbst@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e60eaa88436c10f75623a10cefeb2be130ecf56
Author: Hector Martin <marcan@marcan.st>
Date:   Tue Aug 16 16:03:11 2022 +0900

    locking/atomic: Make test_and_*_bit() ordered on failure
    
    commit 415d832497098030241605c52ea83d4e2cfa7879 upstream.
    
    These operations are documented as always ordered in
    include/asm-generic/bitops/instrumented-atomic.h, and producer-consumer
    type use cases where one side needs to ensure a flag is left pending
    after some shared data was updated rely on this ordering, even in the
    failure case.
    
    This is the case with the workqueue code, which currently suffers from a
    reproducible ordering violation on Apple M1 platforms (which are
    notoriously out-of-order) that ends up causing the TTY layer to fail to
    deliver data to userspace properly under the right conditions.  This
    change fixes that bug.
    
    Change the documentation to restrict the "no order on failure" story to
    the _lock() variant (for which it makes sense), and remove the
    early-exit from the generic implementation, which is what causes the
    missing barrier semantics in that case.  Without this, the remaining
    atomic op is fully ordered (including on ARM64 LSE, as of recent
    versions of the architecture spec).
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Fixes: e986a0d6cb36 ("locking/atomics, asm-generic/bitops/atomic.h: Rewrite using atomic_*() APIs")
    Fixes: 61e02392d3c7 ("locking/atomic/bitops: Document and clarify ordering semantics for failed test_and_{}_bit()")
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Acked-by: Will Deacon <will@kernel.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05d197ff4935eb8dcfff9b0ec2d8448287897418
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jul 26 16:48:44 2022 +0200

    drm/i915/gem: Remove shared locking on freeing objects
    
    commit 2826d447fbd60e6a05e53d5f918bceb8c04e315c upstream.
    
    The obj->base.resv may be shared across many objects, some of which may
    still be live and locked, preventing objects from being freed
    indefintely. We could individualise the lock during the free, or rely on
    a freed object having no contention and being able to immediately free
    the pages it owns.
    
    References: https://gitlab.freedesktop.org/drm/intel/-/issues/6469
    Fixes: be7612fd6665 ("drm/i915: Require object lock when freeing pages during destruction")
    Fixes: 6cb12fbda1c2 ("drm/i915: Use trylock instead of blocking lock for __i915_gem_free_objects.")
    Cc: <stable@vger.kernel.org> # v5.17+
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Tested-by: Nirmoy Das <nirmoy.das@intel.com>
    Acked-by: Nirmoy Das <nirmoy.das@intel.com>
    Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
    Reviewed-by: Matthew Auld <matthew.auld@intel.com>
    Signed-off-by: Matthew Auld <matthew.auld@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220726144844.18429-1-nirmoy.das@intel.com
    (cherry picked from commit 7dd5c56531eb03696acdb17774721de5ef481c0b)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d04f5d855eb0708620a49c66fd2e7d535baa411
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Aug 10 09:00:42 2022 -0400

    rds: add missing barrier to release_refill
    
    commit 9f414eb409daf4f778f011cf8266d36896bb930b upstream.
    
    The functions clear_bit and set_bit do not imply a memory barrier, thus it
    may be possible that the waitqueue_active function (which does not take
    any locks) is moved before clear_bit and it could miss a wakeup event.
    
    Fix this bug by adding a memory barrier after clear_bit.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60bfd51fed8bff9eac95c22a04387ccd8caf5ea9
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Fri Aug 19 10:30:01 2022 +0800

    x86/mm: Use proper mask when setting PUD mapping
    
    commit 88e0a74902f894fbbc55ad3ad2cb23b4bfba555c upstream.
    
    Commit c164fbb40c43f("x86/mm: thread pgprot_t through
    init_memory_mapping()") mistakenly used __pgprot() which doesn't respect
    __default_kernel_pte_mask when setting PUD mapping.
    
    Fix it by only setting the one bit we actually need (PSE) and leaving
    the other bits (that have been properly masked) alone.
    
    Fixes: c164fbb40c43 ("x86/mm: thread pgprot_t through init_memory_mapping()")
    Signed-off-by: Aaron Lu <aaron.lu@intel.com>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 865e08b77c244eed0b80439320e7e8440f61ebce
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Aug 16 05:39:36 2022 +0000

    KVM: Unconditionally get a ref to /dev/kvm module when creating a VM
    
    commit 405294f29faee5de8c10cb9d4a90e229c2835279 upstream.
    
    Unconditionally get a reference to the /dev/kvm module when creating a VM
    instead of using try_get_module(), which will fail if the module is in
    the process of being forcefully unloaded.  The error handling when
    try_get_module() fails doesn't properly unwind all that has been done,
    e.g. doesn't call kvm_arch_pre_destroy_vm() and doesn't remove the VM
    from the global list.  Not removing VMs from the global list tends to be
    fatal, e.g. leads to use-after-free explosions.
    
    The obvious alternative would be to add proper unwinding, but the
    justification for using try_get_module(), "rmmod --wait", is completely
    bogus as support for "rmmod --wait", i.e. delete_module() without
    O_NONBLOCK, was removed by commit 3f2b9c9cdf38 ("module: remove rmmod
    --wait option.") nearly a decade ago.
    
    It's still possible for try_get_module() to fail due to the module dying
    (more like being killed), as the module will be tagged MODULE_STATE_GOING
    by "rmmod --force", i.e. delete_module(..., O_TRUNC), but playing nice
    with forced unloading is an exercise in futility and gives a falsea sense
    of security.  Using try_get_module() only prevents acquiring _new_
    references, it doesn't magically put the references held by other VMs,
    and forced unloading doesn't wait, i.e. "rmmod --force" on KVM is all but
    guaranteed to cause spectacular fireworks; the window where KVM will fail
    try_get_module() is tiny compared to the window where KVM is building and
    running the VM with an elevated module refcount.
    
    Addressing KVM's inability to play nice with "rmmod --force" is firmly
    out-of-scope.  Forcefully unloading any module taints kernel (for obvious
    reasons)  _and_ requires the kernel to be built with
    CONFIG_MODULE_FORCE_UNLOAD=y, which is off by default and comes with the
    amusing disclaimer that it's "mainly for kernel developers and desperate
    users".  In other words, KVM is free to scoff at bug reports due to using
    "rmmod --force" while VMs may be running.
    
    Fixes: 5f6de5cbebee ("KVM: Prevent module exit until all VMs are freed")
    Cc: stable@vger.kernel.org
    Cc: David Matlack <dmatlack@google.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20220816053937.2477106-3-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a1d6aa0de7a5bb28eed1c36832147d9c9a71681
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Tue Aug 16 11:03:20 2022 -0300

    RDMA: Handle the return code from dma_resv_wait_timeout() properly
    
    commit b16de8b9e7d1aae169d059c3a0dd9a881a3c0d1d upstream.
    
    ib_umem_dmabuf_map_pages() returns 0 on success and -ERRNO on failure.
    
    dma_resv_wait_timeout() uses a different scheme:
    
     * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
     * greater than zero on success.
    
    This results in ib_umem_dmabuf_map_pages() being non-functional as a
    positive return will be understood to be an error by drivers.
    
    Fixes: f30bceab16d1 ("RDMA: use dma_resv_wait() instead of extracting the fence")
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/0-v1-d8f4e1fa84c8+17-rdma_dmabuf_fix_jgg@nvidia.com
    Tested-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb986ecaea460983e426fb8eea82af314ea25095
Author: Christoffer Sandberg <cs@tuxedo.de>
Date:   Wed Aug 17 15:51:44 2022 +0200

    ALSA: hda/realtek: Add quirk for Clevo NS50PU, NS70PU
    
    commit 90d74fdbd8059bf041ac797092c9b1d461555280 upstream.
    
    Fixes headset microphone detection on Clevo NS50PU and NS70PU.
    
    Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
    Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220817135144.34103-1-wse@tuxedocomputers.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9c994320d66847aed5f6d2bc9a6afbcb82d5353
Author: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Date:   Wed Aug 17 14:49:24 2022 +0200

    ALSA: info: Fix llseek return value when using callback
    
    commit 9be080edcca330be4af06b19916c35227891e8bc upstream.
    
    When using callback there was a flow of
    
            ret = -EINVAL
            if (callback) {
                    offset = callback();
                    goto out;
            }
            ...
            offset = some other value in case of no callback;
            ret = offset;
    out:
            return ret;
    
    which causes the snd_info_entry_llseek() to return -EINVAL when there is
    callback handler. Fix this by setting "ret" directly to callback return
    value before jumping to "out".
    
    Fixes: 73029e0ff18d ("ALSA: info - Implement common llseek for binary mode")
    Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220817124924.3974577-1-amadeuszx.slawinski@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>