commit eed68052d2016d9f96d6656435099762608120e3
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jun 14 18:41:54 2022 +0200

    Linux 5.17.15
    
    Link: https://lore.kernel.org/r/20220613094924.913340374@linuxfoundation.org
    Link: https://lore.kernel.org/r/20220613181529.324450680@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f0c8a9d4ef1b9ebee0e4ac2495fe790727044aa
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date:   Mon Apr 25 17:37:45 2022 +0200

    xsk: Fix possible crash when multiple sockets are created
    
    commit ba3beec2ec1d3b4fd8672ca6e781dac4b3267f6e upstream.
    
    Fix a crash that happens if an Rx only socket is created first, then a
    second socket is created that is Tx only and bound to the same umem as
    the first socket and also the same netdev and queue_id together with the
    XDP_SHARED_UMEM flag. In this specific case, the tx_descs array page
    pool was not created by the first socket as it was an Rx only socket.
    When the second socket is bound it needs this tx_descs array of this
    shared page pool as it has a Tx component, but unfortunately it was
    never allocated, leading to a crash. Note that this array is only used
    for zero-copy drivers using the batched Tx APIs, currently only ice and
    i40e.
    
    [ 5511.150360] BUG: kernel NULL pointer dereference, address: 0000000000000008
    [ 5511.158419] #PF: supervisor write access in kernel mode
    [ 5511.164472] #PF: error_code(0x0002) - not-present page
    [ 5511.170416] PGD 0 P4D 0
    [ 5511.173347] Oops: 0002 [#1] PREEMPT SMP PTI
    [ 5511.178186] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G            E     5.18.0-rc1+ #97
    [ 5511.187245] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016
    [ 5511.198418] RIP: 0010:xsk_tx_peek_release_desc_batch+0x198/0x310
    [ 5511.205375] Code: c0 83 c6 01 84 c2 74 6d 8d 46 ff 23 07 44 89 e1 48 83 c0 14 48 c1 e1 04 48 c1 e0 04 48 03 47 10 4c 01 c1 48 8b 50 08 48 8b 00 <48> 89 51 08 48 89 01 41 80 bd d7 00 00 00 00 75 82 48 8b 19 49 8b
    [ 5511.227091] RSP: 0018:ffffc90000003dd0 EFLAGS: 00010246
    [ 5511.233135] RAX: 0000000000000000 RBX: ffff88810c8da600 RCX: 0000000000000000
    [ 5511.241384] RDX: 000000000000003c RSI: 0000000000000001 RDI: ffff888115f555c0
    [ 5511.249634] RBP: ffffc90000003e08 R08: 0000000000000000 R09: ffff889092296b48
    [ 5511.257886] R10: 0000ffffffffffff R11: ffff889092296800 R12: 0000000000000000
    [ 5511.266138] R13: ffff88810c8db500 R14: 0000000000000040 R15: 0000000000000100
    [ 5511.274387] FS:  0000000000000000(0000) GS:ffff88903f800000(0000) knlGS:0000000000000000
    [ 5511.283746] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 5511.290389] CR2: 0000000000000008 CR3: 00000001046e2001 CR4: 00000000003706f0
    [ 5511.298640] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [ 5511.306892] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [ 5511.315142] Call Trace:
    [ 5511.317972]  <IRQ>
    [ 5511.320301]  ice_xmit_zc+0x68/0x2f0 [ice]
    [ 5511.324977]  ? ktime_get+0x38/0xa0
    [ 5511.328913]  ice_napi_poll+0x7a/0x6a0 [ice]
    [ 5511.333784]  __napi_poll+0x2c/0x160
    [ 5511.337821]  net_rx_action+0xdd/0x200
    [ 5511.342058]  __do_softirq+0xe6/0x2dd
    [ 5511.346198]  irq_exit_rcu+0xb5/0x100
    [ 5511.350339]  common_interrupt+0xa4/0xc0
    [ 5511.354777]  </IRQ>
    [ 5511.357201]  <TASK>
    [ 5511.359625]  asm_common_interrupt+0x1e/0x40
    [ 5511.364466] RIP: 0010:cpuidle_enter_state+0xd2/0x360
    [ 5511.370211] Code: 49 89 c5 0f 1f 44 00 00 31 ff e8 e9 00 7b ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 72 02 00 00 31 ff e8 02 0c 80 ff fb 45 85 f6 <0f> 88 11 01 00 00 49 63 c6 4c 2b 2c 24 48 8d 14 40 48 8d 14 90 49
    [ 5511.391921] RSP: 0018:ffffffff82a03e60 EFLAGS: 00000202
    [ 5511.397962] RAX: ffff88903f800000 RBX: 0000000000000001 RCX: 000000000000001f
    [ 5511.406214] RDX: 0000000000000000 RSI: ffffffff823400b9 RDI: ffffffff8234c046
    [ 5511.424646] RBP: ffff88810a384800 R08: 000005032a28c046 R09: 0000000000000008
    [ 5511.443233] R10: 000000000000000b R11: 0000000000000006 R12: ffffffff82bcf700
    [ 5511.461922] R13: 000005032a28c046 R14: 0000000000000001 R15: 0000000000000000
    [ 5511.480300]  cpuidle_enter+0x29/0x40
    [ 5511.494329]  do_idle+0x1c7/0x250
    [ 5511.507610]  cpu_startup_entry+0x19/0x20
    [ 5511.521394]  start_kernel+0x649/0x66e
    [ 5511.534626]  secondary_startup_64_no_verify+0xc3/0xcb
    [ 5511.549230]  </TASK>
    
    Detect such case during bind() and allocate this memory region via newly
    introduced xp_alloc_tx_descs(). Also, use kvcalloc instead of kcalloc as
    for other buffer pool allocations, so that it matches the kvfree() from
    xp_destroy().
    
    Fixes: d1bc532e99be ("i40e: xsk: Move tmp desc array from driver to pool")
    Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
    Link: https://lore.kernel.org/bpf/20220425153745.481322-1-maciej.fijalkowski@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0cef0b7eb044bb8cfdaff4c1db55a8fd442f6bc9
Author: Mark Bloch <mbloch@nvidia.com>
Date:   Thu May 26 08:15:28 2022 +0300

    net/mlx5: E-Switch, pair only capable devices
    
    commit 3008e6a0049361e731b803c60fe8f3ab44e1d73f upstream.
    
    OFFLOADS paring using devcom is possible only on devices
    that support LAG. Filter based on lag capabilities.
    
    This fixes an issue where mlx5_get_next_phys_dev() was
    called without holding the interface lock.
    
    This issue was found when commit
    bc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices")
    added an assert that verifies the interface lock is held.
    
    WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]
    Modules linked in: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [last unloaded: mlx5_core]
    CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]
    Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff
    RSP: 0018:ffff88811bf47458 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001
    RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78
    RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437
    R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000
    R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428
    FS:  00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core]
     mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core]
     esw_offloads_enable+0x1153/0x1500 [mlx5_core]
     ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core]
     ? wait_for_completion_io_timeout+0x20/0x20
     ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core]
     mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core]
     ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core]
     ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core]
     ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core]
     ? __debugfs_create_file+0x260/0x3e0
     mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core]
     ? mutex_lock_io_nested+0x12c0/0x12c0
     ? esw_offloads_disable+0x250/0x250 [mlx5_core]
     ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470
     ? rcu_read_lock_sched_held+0x3f/0x70
     devlink_nl_cmd_eswitch_set_doit+0x217/0x620
    
    Fixes: dd3fddb82780 ("net/mlx5: E-Switch, handle devcom events only for ports on the same device")
    Signed-off-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aa7f333efd1138a68517a6a6a69ae540dd59d800
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 27 14:28:29 2022 -0700

    tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd
    
    commit 11825765291a93d8e7f44230da67b9f607c777bf upstream.
    
    syzbot got a new report [1] finally pointing to a very old bug,
    added in initial support for MTU probing.
    
    tcp_mtu_probe() has checks about starting an MTU probe if
    tcp_snd_cwnd(tp) >= 11.
    
    But nothing prevents tcp_snd_cwnd(tp) to be reduced later
    and before the MTU probe succeeds.
    
    This bug would lead to potential zero-divides.
    
    Debugging added in commit 40570375356c ("tcp: add accessors
    to read/set tp->snd_cwnd") has paid off :)
    
    While we are at it, address potential overflows in this code.
    
    [1]
    WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
    Modules linked in:
    CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]
    RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
    Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff
    RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287
    RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000
    RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f
    RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520
    R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50
    R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000
    FS:  00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356
     tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861
     tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973
     tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476
     sk_backlog_rcv include/net/sock.h:1061 [inline]
     __release_sock+0x1d8/0x4c0 net/core/sock.c:2849
     release_sock+0x5d/0x1c0 net/core/sock.c:3404
     sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145
     tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410
     tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg net/socket.c:734 [inline]
     __sys_sendto+0x439/0x5c0 net/socket.c:2119
     __do_sys_sendto net/socket.c:2131 [inline]
     __se_sys_sendto net/socket.c:2127 [inline]
     __x64_sys_sendto+0xda/0xf0 net/socket.c:2127
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    RIP: 0033:0x7f6431289109
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109
    RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a
    RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000
    
    Fixes: 5d424d5a674f ("[TCP]: MTU probing")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eb6735a64bb8227f86382ba97b3ea7879daa61b1
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Tue Apr 26 15:32:06 2022 -0700

    dmaengine: idxd: add missing callback function to support DMA_INTERRUPT
    
    commit 2112b8f4fb5cc35d1c384324763765953186b81f upstream.
    
    When setting DMA_INTERRUPT capability, a callback function
    dma->device_prep_dma_interrupt() is needed to support this capability.
    Without setting the callback, dma_async_device_register() will fail dma
    capability check.
    
    Fixes: 4e5a4eb20393 ("dmaengine: idxd: set DMA_INTERRUPT cap bit")
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/165101232637.3951447.15765792791591763119.stgit@djiang5-desk3.ch.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b180e78f78fbd6c09a2ba0dd9eabc47a3885db3a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jun 11 10:30:20 2022 -0700

    iov_iter: fix build issue due to possible type mis-match
    
    commit 1c27f1fc1549f0e470429f5497a76ad28a37f21a upstream.
    
    Commit 6c77676645ad ("iov_iter: Fix iter_xarray_get_pages{,_alloc}()")
    introduced a problem on some 32-bit architectures (at least arm, xtensa,
    csky,sparc and mips), that have a 'size_t' that is 'unsigned int'.
    
    The reason is that we now do
    
        min(nr * PAGE_SIZE - offset, maxsize);
    
    where 'nr' and 'offset' and both 'unsigned int', and PAGE_SIZE is
    'unsigned long'.  As a result, the normal C type rules means that the
    first argument to 'min()' ends up being 'unsigned long'.
    
    In contrast, 'maxsize' is of type 'size_t'.
    
    Now, 'size_t' and 'unsigned long' are always the same physical type in
    the kernel, so you'd think this doesn't matter, and from an actual
    arithmetic standpoint it doesn't.
    
    But on 32-bit architectures 'size_t' is commonly 'unsigned int', even if
    it could also be 'unsigned long'.  In that situation, both are unsigned
    32-bit types, but they are not the *same* type.
    
    And as a result 'min()' will complain about the distinct types (ignore
    the "pointer types" part of the error message: that's an artifact of the
    way we have made 'min()' check types for being the same):
    
      lib/iov_iter.c: In function 'iter_xarray_get_pages':
      include/linux/minmax.h:20:35: error: comparison of distinct pointer types lacks a cast [-Werror]
         20 |         (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
            |                                   ^~
      lib/iov_iter.c:1464:16: note: in expansion of macro 'min'
       1464 |         return min(nr * PAGE_SIZE - offset, maxsize);
            |                ^~~
    
    This was not visible on 64-bit architectures (where we always define
    'size_t' to be 'unsigned long').
    
    Force these cases to use 'min_t(size_t, x, y)' to make the type explicit
    and avoid the issue.
    
    [ Nit-picky note: technically 'size_t' doesn't have to match 'unsigned
      long' arithmetically. We've certainly historically seen environments
      with 16-bit address spaces and 32-bit 'unsigned long'.
    
      Similarly, even in 64-bit modern environments, 'size_t' could be its
      own type distinct from 'unsigned long', even if it were arithmetically
      identical.
    
      So the above type commentary is only really descriptive of the kernel
      environment, not some kind of universal truth for the kinds of wild
      and crazy situations that are allowed by the C standard ]
    
    Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Link: https://lore.kernel.org/all/YqRyL2sIqQNDfky2@debian/
    Cc: Jeff Layton <jlayton@kernel.org>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d50efc8d11d2a241d9482ec784881015bfa2da51
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Thu Jun 2 23:16:57 2022 +0900

    zonefs: fix handling of explicit_open option on mount
    
    commit a2a513be7139b279f1b5b2cee59c6c4950c34346 upstream.
    
    Ignoring the explicit_open mount option on mount for devices that do not
    have a limit on the number of open zones must be done after the mount
    options are parsed and set in s_mount_opts. Move the check to ignore
    the explicit_open option after the call to zonefs_parse_options() in
    zonefs_fill_super().
    
    Fixes: b5c00e975779 ("zonefs: open/close zone on file open/close")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b50d3a1dc10e31a8b836d24ef92f13c3d88ee61c
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Apr 1 15:33:51 2022 +0200

    PCI: qcom: Fix pipe clock imbalance
    
    commit fdf6a2f533115ec5d4d9629178f8196331f1ac50 upstream.
    
    Fix a clock imbalance introduced by ed8cc3b1fc84 ("PCI: qcom: Add support
    for SDM845 PCIe controller"), which enables the pipe clock both in init()
    and in post_init() but only disables in post_deinit().
    
    Note that the pipe clock was also never disabled in the init() error
    paths and that enabling the clock before powering up the PHY looks
    questionable.
    
    Link: https://lore.kernel.org/r/20220401133351.10113-1-johan+linaro@kernel.org
    Fixes: ed8cc3b1fc84 ("PCI: qcom: Add support for SDM845 PCIe controller")
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Cc: stable@vger.kernel.org      # 5.6
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d31b82b7f0cf0c5da22c1a9abdab50d5d042c27f
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri May 27 07:58:06 2022 +0200

    block, loop: support partitions without scanning
    
    commit b9684a71fca793213378dd410cd11675d973eaa1 upstream.
    
    Historically we did distinguish between a flag that surpressed partition
    scanning, and a combinations of the minors variable and another flag if
    any partitions were supported.  This was generally confusing and doesn't
    make much sense, but some corner case uses of the loop driver actually
    do want to support manually added partitions on a device that does not
    actively scan for partitions.  To make things worsee the loop driver
    also wants to dynamically toggle the scanning for partitions on a live
    gendisk, which makes the disk->flags updates non-atomic.
    
    Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
    just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
    in the loop driver.
    
    Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT")
    Reported-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20220527055806.1972352-1-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cbcf67ca409726ab7e2db8aa626a6e91d6ccdd3
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Thu Feb 10 18:56:08 2022 +0100

    net/sched: act_police: more accurate MTU policing
    
    commit 4ddc844eb81da59bfb816d8d52089aba4e59e269 upstream.
    
    in current Linux, MTU policing does not take into account that packets at
    the TC ingress have the L2 header pulled. Thus, the same TC police action
    (with the same value of tcfp_mtu) behaves differently for ingress/egress.
    In addition, the full GSO size is compared to tcfp_mtu: as a consequence,
    the policer drops GSO packets even when individual segments have the L2 +
    L3 + L4 + payload length below the configured valued of tcfp_mtu.
    
    Improve the accuracy of MTU policing as follows:
     - account for mac_len for non-GSO packets at TC ingress.
     - compare MTU threshold with the segmented size for GSO packets.
    Also, add a kselftest that verifies the correct behavior.
    
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 569d53264207e7334253484c96b363f17b98fbd4
Author: Pascal Hambourg <pascal@plouf.fr.eu.org>
Date:   Wed Apr 13 08:53:56 2022 +0200

    md/raid0: Ignore RAID0 layout if the second zone has only one device
    
    commit ea23994edc4169bd90d7a9b5908c6ccefd82fa40 upstream.
    
    The RAID0 layout is irrelevant if all members have the same size so the
    array has only one zone. It is *also* irrelevant if the array has two
    zones and the second zone has only one device, for example if the array
    has two members of different sizes.
    
    So in that case it makes sense to allow assembly even when the layout is
    undefined, like what is done when the array has only one zone.
    
    Reviewed-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Pascal Hambourg <pascal@plouf.fr.eu.org>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c6c4fca640e96b20310a969e9a09ec9ac0eb84c
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Jun 13 10:07:49 2022 +0200

    random: account for arch randomness in bits
    
    commit 77fc95f8c0dc9e1f8e620ec14d2fb65028fb7adc upstream.
    
    Rather than accounting in bytes and multiplying (shifting), we can just
    account in bits and avoid the shift. The main motivation for this is
    there are other patches in flux that expand this code a bit, and
    avoiding the duplication of "* 8" everywhere makes things a bit clearer.
    
    Cc: stable@vger.kernel.org
    Fixes: 12e45a2a6308 ("random: credit architectural init the exact amount")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56023044b9b78ab995aa7e64faadad2fe85875e6
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Jun 13 10:07:48 2022 +0200

    random: mark bootloader randomness code as __init
    
    commit 39e0f991a62ed5efabd20711a7b6e7da92603170 upstream.
    
    add_bootloader_randomness() and the variables it touches are only used
    during __init and not after, so mark these as __init. At the same time,
    unexport this, since it's only called by other __init code that's
    built-in.
    
    Cc: stable@vger.kernel.org
    Fixes: 428826f5358c ("fdt: add support for rng-seed")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ccc3457dbe5b27b2de86d45f2e730f4f38cbce3
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Jun 13 10:07:47 2022 +0200

    random: avoid checking crng_ready() twice in random_init()
    
    commit 9b29b6b20376ab64e1b043df6301d8a92378e631 upstream.
    
    The current flow expands to:
    
        if (crng_ready())
           ...
        else if (...)
            if (!crng_ready())
                ...
    
    The second crng_ready() call is redundant, but can't so easily be
    optimized out by the compiler.
    
    This commit simplifies that to:
    
        if (crng_ready()
            ...
        else if (...)
            ...
    
    Fixes: 560181c27b58 ("random: move initialization functions out of hot pages")
    Cc: stable@vger.kernel.org
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9993a9c6dc1274831e81ef4ff63ccccf1aa61d5
Author: KuoHsiang Chou <kuohsiang_chou@aspeedtech.com>
Date:   Mon Jan 17 16:36:43 2022 +0800

    drm/ast: Create threshold values for AST2600
    
    commit bcc77411e8a65929655cef7b63a36000724cdc4b upstream.
    
    The threshold value is used for AST2600 only.
    
    Signed-off-by: KuoHsiang Chou <kuohsiang_chou@aspeedtech.com>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220117083643.41493-1-kuohsiang_chou@aspeedtech.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 638556430658eca42501271edb38154264767ff5
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Tue Jun 7 00:34:56 2022 +1000

    powerpc/32: Fix overread/overwrite of thread_struct via ptrace
    
    commit 8e1278444446fc97778a5e5c99bca1ce0bbc5ec9 upstream.
    
    The ptrace PEEKUSR/POKEUSR (aka PEEKUSER/POKEUSER) API allows a process
    to read/write registers of another process.
    
    To get/set a register, the API takes an index into an imaginary address
    space called the "USER area", where the registers of the process are
    laid out in some fashion.
    
    The kernel then maps that index to a particular register in its own data
    structures and gets/sets the value.
    
    The API only allows a single machine-word to be read/written at a time.
    So 4 bytes on 32-bit kernels and 8 bytes on 64-bit kernels.
    
    The way floating point registers (FPRs) are addressed is somewhat
    complicated, because double precision float values are 64-bit even on
    32-bit CPUs. That means on 32-bit kernels each FPR occupies two
    word-sized locations in the USER area. On 64-bit kernels each FPR
    occupies one word-sized location in the USER area.
    
    Internally the kernel stores the FPRs in an array of u64s, or if VSX is
    enabled, an array of pairs of u64s where one half of each pair stores
    the FPR. Which half of the pair stores the FPR depends on the kernel's
    endianness.
    
    To handle the different layouts of the FPRs depending on VSX/no-VSX and
    big/little endian, the TS_FPR() macro was introduced.
    
    Unfortunately the TS_FPR() macro does not take into account the fact
    that the addressing of each FPR differs between 32-bit and 64-bit
    kernels. It just takes the index into the "USER area" passed from
    userspace and indexes into the fp_state.fpr array.
    
    On 32-bit there are 64 indexes that address FPRs, but only 32 entries in
    the fp_state.fpr array, meaning the user can read/write 256 bytes past
    the end of the array. Because the fp_state sits in the middle of the
    thread_struct there are various fields than can be overwritten,
    including some pointers. As such it may be exploitable.
    
    It has also been observed to cause systems to hang or otherwise
    misbehave when using gdbserver, and is probably the root cause of this
    report which could not be easily reproduced:
      https://lore.kernel.org/linuxppc-dev/dc38afe9-6b78-f3f5-666b-986939e40fc6@keymile.com/
    
    Rather than trying to make the TS_FPR() macro even more complicated to
    fix the bug, or add more macros, instead add a special-case for 32-bit
    kernels. This is more obvious and hopefully avoids a similar bug
    happening again in future.
    
    Note that because 32-bit kernels never have VSX enabled the code doesn't
    need to consider TS_FPRWIDTH/OFFSET at all. Add a BUILD_BUG_ON() to
    ensure that 32-bit && VSX is never enabled.
    
    Fixes: 87fec0514f61 ("powerpc: PTRACE_PEEKUSR/PTRACE_POKEUSER of FPR registers in little endian builds")
    Cc: stable@vger.kernel.org # v3.13+
    Reported-by: Ariel Miculas <ariel.miculas@belden.com>
    Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220609133245.573565-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 808104294597fe75680e3341e4f0642a6e55329e
Author: Jason Wang <jasowang@redhat.com>
Date:   Wed Jun 8 14:14:22 2022 +0800

    virtio-rng: make device ready before making request
    
    commit 228432551bd8783211e494ab35f42a4344580502 upstream.
    
    Current virtio-rng does a entropy request before DRIVER_OK, this
    violates the spec:
    
    virtio spec requires that all drivers set DRIVER_OK
    before using devices.
    
    Further, kernel will ignore the interrupt after commit
    8b4ec69d7e09 ("virtio: harden vring IRQ").
    
    Fixing this by making device ready before the request.
    
    Cc: stable@vger.kernel.org
    Fixes: 8b4ec69d7e09 ("virtio: harden vring IRQ")
    Fixes: f7f510ec1957 ("virtio: An entropy device, as suggested by hpa.")
    Reported-and-tested-by: syzbot+5b59d6d459306a556f54@syzkaller.appspotmail.com
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Message-Id: <20220608061422.38437-1-jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Laurent Vivier <lvivier@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 12428889c07be8b32a0d65994a1469392cb14b76
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu May 26 16:34:55 2022 -0400

    drm/amdgpu: update VCN codec support for Yellow Carp
    
    commit 97e50305542f384741a5b45699aba349fe9fca73 upstream.
    
    Supports AV1.  Mesa already has support for this and
    doesn't rely on the kernel caps for yellow carp, so
    this was already working from an application perspective.
    
    Fixes: 554398174d98 ("amdgpu/nv.c - Added video codec support for Yellow Carp")
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2002
    Reviewed-by: Leo Liu <leo.liu@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 820a413b76621f94115f6ff2993dba167a5bb8cd
Author: Mohammad Zafar Ziya <Mohammadzafar.ziya@amd.com>
Date:   Tue Jun 7 11:38:16 2022 +0800

    drm/amdgpu/jpeg2: Add jpeg vmid update under IB submit
    
    commit 578eb31776df57c81307fb3f96ef0781332c3c7c upstream.
    
    Add jpeg vmid update under IB submit
    
    Signed-off-by: Mohammad Zafar Ziya <Mohammadzafar.ziya@amd.com>
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@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 59ef346016357b751f5aec2e3da0a73df6044bb0
Author: Brian Norris <briannorris@chromium.org>
Date:   Mon Feb 28 12:25:32 2022 -0800

    drm/atomic: Force bridge self-refresh-exit on CRTC switch
    
    commit e54a4424925a27ed94dff046db3ce5caf4b1e748 upstream.
    
    It's possible to change which CRTC is in use for a given
    connector/encoder/bridge while we're in self-refresh without fully
    disabling the connector/encoder/bridge along the way. This can confuse
    the bridge encoder/bridge, because
    (a) it needs to track the SR state (trying to perform "active"
        operations while the panel is still in SR can be Bad(TM)); and
    (b) it tracks the SR state via the CRTC state (and after the switch, the
        previous SR state is lost).
    
    Thus, we need to either somehow carry the self-refresh state over to the
    new CRTC, or else force an encoder/bridge self-refresh transition during
    such a switch.
    
    I choose the latter, so we disable the encoder (and exit PSR) before
    attaching it to the new CRTC (where we can continue to assume a clean
    (non-self-refresh) state).
    
    This fixes PSR issues seen on Rockchip RK3399 systems with
    drivers/gpu/drm/bridge/analogix/analogix_dp_core.c.
    
    Change in v2:
    
    - Drop "->enable" condition; this could possibly be "->active" to
      reflect the intended hardware state, but it also is a little
      over-specific. We want to make a transition through "disabled" any
      time we're exiting PSR at the same time as a CRTC switch.
      (Thanks Liu Ying)
    
    Cc: Liu Ying <victor.liu@oss.nxp.com>
    Cc: <stable@vger.kernel.org>
    Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in drivers")
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Reviewed-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220228122522.v2.2.Ic15a2ef69c540aee8732703103e2cff51fb9c399@changeid
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54baffcf203eb4eee6f3a1f7a89e230b97fd1665
Author: Brian Norris <briannorris@chromium.org>
Date:   Mon Feb 28 12:25:31 2022 -0800

    drm/bridge: analogix_dp: Support PSR-exit to disable transition
    
    commit ca871659ec1606d33b1e76de8d4cf924cf627e34 upstream.
    
    Most eDP panel functions only work correctly when the panel is not in
    self-refresh. In particular, analogix_dp_bridge_disable() tends to hit
    AUX channel errors if the panel is in self-refresh.
    
    Given the above, it appears that so far, this driver assumes that we are
    never in self-refresh when it comes time to fully disable the bridge.
    Prior to commit 846c7dfc1193 ("drm/atomic: Try to preserve the crtc
    enabled state in drm_atomic_remove_fb, v2."), this tended to be true,
    because we would automatically disable the pipe when framebuffers were
    removed, and so we'd typically disable the bridge shortly after the last
    display activity.
    
    However, that is not guaranteed: an idle (self-refresh) display pipe may
    be disabled, e.g., when switching CRTCs. We need to exit PSR first.
    
    Stable notes: this is definitely a bugfix, and the bug has likely
    existed in some form for quite a while. It may predate the "PSR helpers"
    refactor, but the code looked very different before that, and it's
    probably not worth rewriting the fix.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 6c836d965bad ("drm/rockchip: Use the helpers for PSR")
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Reviewed-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220228122522.v2.1.I161904be17ba14526f78536ccd78b85818449b51@changeid
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ede531605505550efd576e46f9ac1604168e5940
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed May 25 13:26:39 2022 +1000

    powerpc: Don't select HAVE_IRQ_EXIT_ON_IRQ_STACK
    
    commit 1346d00e1bdfd4067f92bc14e8a6131a01de4190 upstream.
    
    The HAVE_IRQ_EXIT_ON_IRQ_STACK option tells generic code that irq_exit()
    is called while still running on the hard irq stack (hardirq_ctx[] in
    the powerpc code).
    
    Selecting the option means the generic code will *not* switch to the
    softirq stack before running softirqs, because the code is already
    running on the (mostly empty) hard irq stack.
    
    But since commit 1b1b6a6f4cc0 ("powerpc: handle irq_enter/irq_exit in
    interrupt handler wrappers"), irq_exit() is now called on the regular task
    stack, not the hard irq stack.
    
    That's because previously irq_exit() was called in __do_irq() which is
    run on the hard irq stack, but now it is called in
    interrupt_async_exit_prepare() which is called from do_irq() constructed
    by the wrapper macro, which is after the switch back to the task stack.
    
    So drop HAVE_IRQ_EXIT_ON_IRQ_STACK from the Kconfig. This will mean an
    extra stack switch when processing some interrupts, but should
    significantly reduce the likelihood of stack overflow.
    
    It also means the softirq stack will be used for running softirqs from
    other interrupts that don't use the hard irq stack, eg. timer interrupts.
    
    Fixes: 1b1b6a6f4cc0 ("powerpc: handle irq_enter/irq_exit in interrupt handler wrappers")
    Cc: stable@vger.kernel.org # v5.12+
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220525032639.1947280-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0c84962e297927ba57fd6ddc2bb000c9d149655
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Wed Jun 8 15:18:34 2022 -0400

    mm/huge_memory: Fix xarray node memory leak
    
    commit 69a37a8ba1b408a1c7616494aa7018e4b3844cbe upstream.
    
    If xas_split_alloc() fails to allocate the necessary nodes to complete the
    xarray entry split, it sets the xa_state to -ENOMEM, which xas_nomem()
    then interprets as "Please allocate more memory", not as "Please free
    any unnecessary memory" (which was the intended outcome).  It's confusing
    to use xas_nomem() to free memory in this context, so call xas_destroy()
    instead.
    
    Reported-by: syzbot+9e27a75a8c24f3fe75c1@syzkaller.appspotmail.com
    Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache")
    Cc: stable@vger.kernel.org
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e9d662a0492e5ffbcbe6fb37d6601529cd0944c
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Jun 8 16:27:27 2022 +0200

    cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE
    
    commit 32d4fd5751eadbe1823a37eb38df85ec5c8e6207 upstream.
    
    Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
    Xeons") wrecked intel_idle in two ways:
    
     - must not have tracing in idle functions
     - must return with IRQs disabled
    
    Additionally, it added a branch for no good reason.
    
    Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    [ rjw: Moved the intel_idle() kerneldoc comment next to the function ]
    Cc: 5.16+ <stable@vger.kernel.org> # 5.16+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 30fd1b56621e187346f65d01fe34870634b15188
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Tue Apr 26 15:36:56 2022 +0800

    vduse: Fix NULL pointer dereference on sysfs access
    
    commit b27ee76c74dc831d6e092eaebc2dfc9c0beed1c9 upstream.
    
    The control device has no drvdata. So we will get a
    NULL pointer dereference when accessing control
    device's msg_timeout attribute via sysfs:
    
    [ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8
    [ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271)
    [ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094)
    [ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59)
    [ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088)
    [ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164)
    [ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230)
    [ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041)
    [ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238)
    [ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1))
    [ 132.876319][ T3644] kernel_read (fs/read_write.c:459)
    [ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94)
    [ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186)
    [ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207)
    [ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189)
    [ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132)
    [ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419)
    
    To fix it, don't create the unneeded attribute for
    control device anymore.
    
    Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace")
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Message-Id: <20220426073656.229-1-xieyongji@bytedance.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5ff742fbde3ceebb04a50f47e63b4912279fa17
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Jun 7 12:11:33 2022 -0700

    Input: bcm5974 - set missing URB_NO_TRANSFER_DMA_MAP urb flag
    
    commit c42e65664390be7c1ef3838cd84956d3a2739d60 upstream.
    
    The bcm5974 driver does the allocation and dma mapping of the usb urb
    data buffer, but driver does not set the URB_NO_TRANSFER_DMA_MAP flag
    to let usb core know the buffer is already mapped.
    
    usb core tries to map the already mapped buffer, causing a warning:
    "xhci_hcd 0000:00:14.0: rejecting DMA map of vmalloc memory"
    
    Fix this by setting the URB_NO_TRANSFER_DMA_MAP, letting usb core
    know buffer is already mapped by bcm5974 driver
    
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215890
    Link: https://lore.kernel.org/r/20220606113636.588955-1-mathias.nyman@linux.intel.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cd5029759aa36eb949489628901968ab54bcaa0
Author: Olivier Matz <olivier.matz@6wind.com>
Date:   Wed Apr 6 11:52:52 2022 +0200

    ixgbe: fix unexpected VLAN Rx in promisc mode on VF
    
    commit 7bb0fb7c63df95d6027dc50d6af3bc3bbbc25483 upstream.
    
    When the promiscuous mode is enabled on a VF, the IXGBE_VMOLR_VPE
    bit (VLAN Promiscuous Enable) is set. This means that the VF will
    receive packets whose VLAN is not the same than the VLAN of the VF.
    
    For instance, in this situation:
    
    ┌────────┐    ┌────────┐    ┌────────┐
    │        │    │        │    │        │
    │        │    │        │    │        │
    │     VF0├────┤VF1  VF2├────┤VF3     │
    │        │    │        │    │        │
    └────────┘    └────────┘    └────────┘
       VM1           VM2           VM3
    
    vf 0:  vlan 1000
    vf 1:  vlan 1000
    vf 2:  vlan 1001
    vf 3:  vlan 1001
    
    If we tcpdump on VF3, we see all the packets, even those transmitted
    on vlan 1000.
    
    This behavior prevents to bridge VF1 and VF2 in VM2, because it will
    create a loop: packets transmitted on VF1 will be received by VF2 and
    vice-versa, and bridged again through the software bridge.
    
    This patch remove the activation of VLAN Promiscuous when a VF enables
    the promiscuous mode. However, the IXGBE_VMOLR_UPE bit (Unicast
    Promiscuous) is kept, so that a VF receives all packets that has the
    same VLAN, whatever the destination MAC address.
    
    Fixes: 8443c1a4b192 ("ixgbe, ixgbevf: Add new mbox API xcast mode")
    Cc: stable@vger.kernel.org
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Olivier Matz <olivier.matz@6wind.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 5eafe31cbb5971bb2a7354fef467eb62afcfb1c5
Author: Olivier Matz <olivier.matz@6wind.com>
Date:   Wed Apr 6 11:52:51 2022 +0200

    ixgbe: fix bcast packets Rx on VF after promisc removal
    
    commit 803e9895ea2b0fe80bc85980ae2d7a7e44037914 upstream.
    
    After a VF requested to remove the promiscuous flag on an interface, the
    broadcast packets are not received anymore. This breaks some protocols
    like ARP.
    
    In ixgbe_update_vf_xcast_mode(), we should keep the IXGBE_VMOLR_BAM
    bit (Broadcast Accept) on promiscuous removal.
    
    This flag is already set by default in ixgbe_set_vmolr() on VF reset.
    
    Fixes: 8443c1a4b192 ("ixgbe, ixgbevf: Add new mbox API xcast mode")
    Cc: stable@vger.kernel.org
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Olivier Matz <olivier.matz@6wind.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 e80b413f44af0433006350d8195f4a3259a49587
Author: Martin Faltesek <mfaltesek@google.com>
Date:   Mon Jun 6 21:57:29 2022 -0500

    nfc: st21nfca: fix incorrect sizing calculations in EVT_TRANSACTION
    
    commit f2e19b36593caed4c977c2f55aeba7408aeb2132 upstream.
    
    The transaction buffer is allocated by using the size of the packet buf,
    and subtracting two which seem intended to remove the two tags which are
    not present in the target structure. This calculation leads to under
    counting memory because of differences between the packet contents and the
    target structure. The aid_len field is a u8 in the packet, but a u32 in
    the structure, resulting in at least 3 bytes always being under counted.
    Further, the aid data is a variable length field in the packet, but fixed
    in the structure, so if this field is less than the max, the difference is
    added to the under counting.
    
    The last validation check for transaction->params_len is also incorrect
    since it employs the same accounting error.
    
    To fix, perform validation checks progressively to safely reach the
    next field, to determine the size of both buffers and verify both tags.
    Once all validation checks pass, allocate the buffer and copy the data.
    This eliminates freeing memory on the error path, as those checks are
    moved ahead of memory allocation.
    
    Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
    Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Faltesek <mfaltesek@google.com>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db836b97464d44340b568e041fd24602858713f7
Author: Martin Faltesek <mfaltesek@google.com>
Date:   Mon Jun 6 21:57:28 2022 -0500

    nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling
    
    commit 996419e0594abb311fb958553809f24f38e7abbe upstream.
    
    Error paths do not free previously allocated memory. Add devm_kfree() to
    those failure paths.
    
    Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
    Fixes: 4fbcc1a4cb20 ("nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION")
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Faltesek <mfaltesek@google.com>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8433965a12141aa08215d7e5d2d909a6ed8c3186
Author: Martin Faltesek <mfaltesek@google.com>
Date:   Mon Jun 6 21:57:27 2022 -0500

    nfc: st21nfca: fix incorrect validating logic in EVT_TRANSACTION
    
    commit 77e5fe8f176a525523ae091d6fd0fbb8834c156d upstream.
    
    The first validation check for EVT_TRANSACTION has two different checks
    tied together with logical AND. One is a check for minimum packet length,
    and the other is for a valid aid_tag. If either condition is true (fails),
    then an error should be triggered.  The fix is to change && to ||.
    
    Fixes: 26fc6c7f02cb ("NFC: st21nfca: Add HCI transaction event support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Martin Faltesek <mfaltesek@google.com>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e8c954ae2c0e2d002bfc5faad7872c725613549
Author: Jchao Sun <sunjunchao2870@gmail.com>
Date:   Tue May 24 08:05:40 2022 -0700

    writeback: Fix inode->i_io_list not be protected by inode->i_lock error
    
    commit 10e14073107dd0b6d97d9516a02845a8e501c2c9 upstream.
    
    Commit b35250c0816c ("writeback: Protect inode->i_io_list with
    inode->i_lock") made inode->i_io_list not only protected by
    wb->list_lock but also inode->i_lock, but inode_io_list_move_locked()
    was missed. Add lock there and also update comment describing
    things protected by inode->i_lock. This also fixes a race where
    __mark_inode_dirty() could move inode under flush worker's hands
    and thus sync(2) could miss writing some inodes.
    
    Fixes: b35250c0816c ("writeback: Protect inode->i_io_list with inode->i_lock")
    Link: https://lore.kernel.org/r/20220524150540.12552-1-sunjunchao2870@gmail.com
    CC: stable@vger.kernel.org
    Signed-off-by: Jchao Sun <sunjunchao2870@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b574f8a111d3e9187b1d88ac50d9585b86709c63
Author: Ilya Maximets <i.maximets@ovn.org>
Date:   Tue Jun 7 00:11:40 2022 +0200

    net: openvswitch: fix misuse of the cached connection on tuple changes
    
    commit 2061ecfdf2350994e5b61c43e50e98a7a70e95ee upstream.
    
    If packet headers changed, the cached nfct is no longer relevant
    for the packet and attempt to re-use it leads to the incorrect packet
    classification.
    
    This issue is causing broken connectivity in OpenStack deployments
    with OVS/OVN due to hairpin traffic being unexpectedly dropped.
    
    The setup has datapath flows with several conntrack actions and tuple
    changes between them:
    
      actions:ct(commit,zone=8,mark=0/0x1,nat(src)),
              set(eth(src=00:00:00:00:00:01,dst=00:00:00:00:00:06)),
              set(ipv4(src=172.18.2.10,dst=192.168.100.6,ttl=62)),
              ct(zone=8),recirc(0x4)
    
    After the first ct() action the packet headers are almost fully
    re-written.  The next ct() tries to re-use the existing nfct entry
    and marks the packet as invalid, so it gets dropped later in the
    pipeline.
    
    Clearing the cached conntrack entry whenever packet tuple is changed
    to avoid the issue.
    
    The flow key should not be cleared though, because we should still
    be able to match on the ct_state if the recirculation happens after
    the tuple change but before the next ct() action.
    
    Cc: stable@vger.kernel.org
    Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
    Reported-by: Frode Nordahl <frode.nordahl@canonical.com>
    Link: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-May/051829.html
    Link: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/1967856
    Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
    Link: https://lore.kernel.org/r/20220606221140.488984-1-i.maximets@ovn.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64cdf9843b937dbc25982487820289c4fc99720b
Author: Tan Tee Min <tee.min.tan@linux.intel.com>
Date:   Thu May 26 17:03:47 2022 +0800

    net: phy: dp83867: retrigger SGMII AN when link change
    
    commit c76acfb7e19dcc3a0964e0563770b1d11b8d4540 upstream.
    
    There is a limitation in TI DP83867 PHY device where SGMII AN is only
    triggered once after the device is booted up. Even after the PHY TPI is
    down and up again, SGMII AN is not triggered and hence no new in-band
    message from PHY to MAC side SGMII.
    
    This could cause an issue during power up, when PHY is up prior to MAC.
    At this condition, once MAC side SGMII is up, MAC side SGMII wouldn`t
    receive new in-band message from TI PHY with correct link status, speed
    and duplex info.
    
    As suggested by TI, implemented a SW solution here to retrigger SGMII
    Auto-Neg whenever there is a link change.
    
    v2: Add Fixes tag in commit message.
    
    Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy")
    Cc: <stable@vger.kernel.org> # 5.4.x
    Signed-off-by: Sit, Michael Wei Hong <michael.wei.hong.sit@intel.com>
    Reviewed-by: Voon Weifeng <weifeng.voon@intel.com>
    Signed-off-by: Tan Tee Min <tee.min.tan@linux.intel.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20220526090347.128742-1-tee.min.tan@linux.intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f00f191d5c1bbdeeaca6fc4ada7157f422c0ceb
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue May 31 20:19:22 2022 +0300

    mmc: block: Fix CQE recovery reset success
    
    commit a051246b786af7e4a9d9219cc7038a6e8a411531 upstream.
    
    The intention of the use of mmc_blk_reset_success() in
    mmc_blk_cqe_recovery() was to prevent repeated resets when retrying and
    getting the same error. However, that may not be the case - any amount
    of time and I/O may pass before another recovery is needed, in which
    case there would be no reason to deny it the opportunity to recover via
    a reset if necessary. CQE recovery is expected seldom and failure to
    recover (if the clear tasks command fails), even more seldom, so it is
    better to allow the reset always, which can be done by calling
    mmc_blk_reset_success() always.
    
    Fixes: 1e8e55b67030c6 ("mmc: block: Add CQE support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20220531171922.76080-1-adrian.hunter@intel.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8063a9f0085bf1001cbfc8e5d96df4a4c1b2a54a
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Wed Jun 8 22:51:07 2022 +0300

    ata: libata-transport: fix {dma|pio|xfer}_mode sysfs files
    
    commit 72aad489f992871e908ff6d9055b26c6366fb864 upstream.
    
    The {dma|pio}_mode sysfs files are incorrectly documented as having a
    list of the supported DMA/PIO transfer modes, while the corresponding
    fields of the *struct* ata_device hold the transfer mode IDs, not masks.
    
    To match these docs, the {dma|pio}_mode (and even xfer_mode!) sysfs
    files are handled by the ata_bitfield_name_match() macro which leads to
    reading such kind of nonsense from them:
    
    $ cat /sys/class/ata_device/dev3.0/pio_mode
    XFER_UDMA_7, XFER_UDMA_6, XFER_UDMA_5, XFER_UDMA_4, XFER_MW_DMA_4,
    XFER_PIO_6, XFER_PIO_5, XFER_PIO_4, XFER_PIO_3, XFER_PIO_2, XFER_PIO_1,
    XFER_PIO_0
    
    Using the correct ata_bitfield_name_search() macro fixes that:
    
    $ cat /sys/class/ata_device/dev3.0/pio_mode
    XFER_PIO_4
    
    While fixing the file documentation, somewhat reword the {dma|pio}_mode
    file doc and add a note about being mostly useful for PATA devices to
    the xfer_mode file doc...
    
    Fixes: d9027470b886 ("[libata] Add ATA transport class")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b44b312a01af8eaf2c950e02b05e50e736b96eb1
Author: Tyler Erickson <tyler.erickson@seagate.com>
Date:   Thu Jun 2 16:51:12 2022 -0600

    libata: fix translation of concurrent positioning ranges
    
    commit 6d11acd452fd885ef6ace184c9c70bc863a8c72f upstream.
    
    Fixing the page length in the SCSI translation for the concurrent
    positioning ranges VPD page. It was writing starting in offset 3
    rather than offset 2 where the MSB is supposed to start for
    the VPD page length.
    
    Cc: stable@vger.kernel.org
    Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log")
    Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
    Reviewed-by: Muhammad Ahmad <muhammad.ahmad@seagate.com>
    Tested-by: Michael English <michael.english@seagate.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aff343103de97bb56265393415d1fa749fb551c4
Author: Tyler Erickson <tyler.erickson@seagate.com>
Date:   Thu Jun 2 16:51:11 2022 -0600

    libata: fix reading concurrent positioning ranges log
    
    commit c745dfc541e78428ba3986f1d17fe1dfdaca8184 upstream.
    
    The concurrent positioning ranges log is not a fixed size and may depend
    on how many ranges are supported by the device. This patch uses the size
    reported in the GPL directory to determine the number of pages supported
    by the device before attempting to read this log page.
    
    This resolves this error from the dmesg output:
        ata6.00: Read log 0x47 page 0x00 failed, Emask 0x1
    
    Cc: stable@vger.kernel.org
    Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log")
    Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
    Reviewed-by: Muhammad Ahmad <muhammad.ahmad@seagate.com>
    Tested-by: Michael English <michael.english@seagate.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 776d2c552396e827d8fbaf9affefcd4aba4ad94b
Author: David Safford <david.safford@gmail.com>
Date:   Tue Jun 7 14:07:57 2022 -0400

    KEYS: trusted: tpm2: Fix migratable logic
    
    commit dda5384313a40ecbaafd8a9a80f47483255e4c4d upstream.
    
    When creating (sealing) a new trusted key, migratable
    trusted keys have the FIXED_TPM and FIXED_PARENT attributes
    set, and non-migratable keys don't. This is backwards, and
    also causes creation to fail when creating a migratable key
    under a migratable parent. (The TPM thinks you are trying to
    seal a non-migratable blob under a migratable parent.)
    
    The following simple patch fixes the logic, and has been
    tested for all four combinations of migratable and non-migratable
    trusted keys and parent storage keys. With this logic, you will
    get a proper failure if you try to create a non-migratable
    trusted key under a migratable parent storage key, and all other
    combinations work correctly.
    
    Cc: stable@vger.kernel.org # v5.13+
    Fixes: e5fb5d2c5a03 ("security: keys: trusted: Make sealed key properly interoperable")
    Signed-off-by: David Safford <david.safford@gmail.com>
    Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ff11913938bc00685cc05afed0af97bebedf852
Author: Tyler Erickson <tyler.erickson@seagate.com>
Date:   Thu Jun 2 16:51:13 2022 -0600

    scsi: sd: Fix interpretation of VPD B9h length
    
    commit f92de9d110429e39929a49240d823251c2fe903e upstream.
    
    Fixing the interpretation of the length of the B9h VPD page (Concurrent
    Positioning Ranges). Adding 4 is necessary as the first 4 bytes of the page
    is the header with page number and length information.  Adding 3 was likely
    a misinterpretation of the SBC-5 specification which sets all offsets
    starting at zero.
    
    This fixes the error in dmesg:
    
    [ 9.014456] sd 1:0:0:0: [sda] Invalid Concurrent Positioning Ranges VPD page
    
    Link: https://lore.kernel.org/r/20220602225113.10218-4-tyler.erickson@seagate.com
    Fixes: e815d36548f0 ("scsi: sd: add concurrent positioning ranges support")
    Cc: stable@vger.kernel.org
    Tested-by: Michael English <michael.english@seagate.com>
    Reviewed-by: Muhammad Ahmad <muhammad.ahmad@seagate.com>
    Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46d520e6a30ef7f5242579fef31f1fd9fa55b95f
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Mon Jun 6 09:52:46 2022 +0000

    cifs: populate empty hostnames for extra channels
    
    commit 4c14d7043fede258957d7b01da0cad2d9fe3a205 upstream.
    
    Currently, the secondary channels of a multichannel session
    also get hostname populated based on the info in primary channel.
    However, this will end up with a wrong resolution of hostname to
    IP address during reconnect.
    
    This change fixes this by not populating hostname info for all
    secondary channels.
    
    Fixes: 5112d80c162f ("cifs: populate server_hostname for extra channels")
    Cc: stable@vger.kernel.org
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2194646e41848c4edc80464adbc77b84db3d0f0c
Author: Paulo Alcantara <pc@cjr.nz>
Date:   Sun Jun 5 19:54:26 2022 -0300

    cifs: fix reconnect on smb3 mount types
    
    commit c36ee7dab7749f7be21f7a72392744490b2a9a2b upstream.
    
    cifs.ko defines two file system types: cifs & smb3, and
    __cifs_get_super() was not including smb3 file system type when
    looking up superblocks, therefore failing to reconnect tcons in
    cifs_tree_connect().
    
    Fix this by calling iterate_supers_type() on both file system types.
    
    Link: https://lore.kernel.org/r/CAFrh3J9soC36+BVuwHB=g9z_KB5Og2+p2_W+BBoBOZveErz14w@mail.gmail.com
    Cc: stable@vger.kernel.org
    Tested-by: Satadru Pramanik <satadru@gmail.com>
    Reported-by: Satadru Pramanik <satadru@gmail.com>
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5a61ba459e128b2afdce21612b8cda8a80616954
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Tue May 31 12:31:05 2022 +0000

    cifs: return errors during session setup during reconnects
    
    commit 8ea21823aa584b55ba4b861307093b78054b0c1b upstream.
    
    During reconnects, we check the return value from
    cifs_negotiate_protocol, and have handlers for both success
    and failures. But if that passes, and cifs_setup_session
    returns any errors other than -EACCES, we do not handle
    that. This fix adds a handler for that, so that we don't
    go ahead and try a tree_connect on a failed session.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Reviewed-by: Enzo Matsumiya <ematsumiya@suse.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f22261adffc2f939004e27ba814bf60288c23eae
Author: Jeremy Soller <jeremy@system76.com>
Date:   Wed Jun 8 08:01:11 2022 -0600

    ALSA: hda/realtek: Add quirk for HP Dev One
    
    commit 5f3d696eea916693b2d4ed7e62794653fcdd6ec0 upstream.
    
    Enables the audio mute LEDs and limits the mic boost to avoid picking up
    noise.
    
    Signed-off-by: Jeremy Soller <jeremy@system76.com>
    Signed-off-by: Tim Crawford <tcrawford@system76.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220608140111.23170-1-tcrawford@system76.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5bf395e30e39bc9831efc9c7e362fd053dca4c4
Author: Cameron Berkenpas <cam@neo-zeon.de>
Date:   Sun Jun 5 17:23:30 2022 -0700

    ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo Yoga DuetITL 2021
    
    commit 85743a847caeab696dafc4ce1a7e1e2b7e29a0f6 upstream.
    
    Enables the ALC287_FIXUP_YOGA7_14ITL_SPEAKERS quirk for the Lenovo
    Yoga DuetITL 2021 laptop to fix speaker output.
    
    [ re-sorted in the SSID order by tiwai ]
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555
    Signed-off-by: Cameron Berkenpas <cam@neo-zeon.de>
    Co-authored-by: Songine <donglingluoying@gmail.com>
    Cc: stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220606002329.215330-1-cam@neo-zeon.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70db2abb791000ed35f9d8a1c1177ea50e6e94a0
Author: huangwenhui <huangwenhuia@uniontech.com>
Date:   Tue Jun 7 14:56:31 2022 +0800

    ALSA: hda/conexant - Fix loopback issue with CX20632
    
    commit d5ea7544c32ba27c2c5826248e4ff58bd50a2518 upstream.
    
    On a machine with CX20632, Alsamixer doesn't have 'Loopback
    Mixing' and 'Line'.
    
    Signed-off-by: huangwenhui <huangwenhuia@uniontech.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220607065631.10708-1-huangwenhuia@uniontech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9474b0c6fbf41e90b461ce2acd867de4320fc565
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 6 18:09:10 2022 +0200

    ALSA: usb-audio: Set up (implicit) sync for Saffire 6
    
    commit e0469d6581aecb0e34e2ec64f39f88e6985cc52f upstream.
    
    Focusrite Saffire 6 has fixed audioformat quirks with multiple
    endpoints assigned to a single altsetting.  Unfortunately the generic
    parser couldn't detect the sync endpoint correctly as the implicit
    sync due to the missing EP attribute bits.  In the former kernels, it
    used to work somehow casually, but it's been broken for a while after
    the large code change in 5.11.
    
    This patch cures the regression by the following:
    - Allow the static quirk table to provide the sync EP information;
      we just need to fill the fields and let the generic parser skipping
      parsing if sync_ep is already set.
    - Add the sync endpoint information to the entry for Saffire 6.
    
    Fixes: 7b0efea4baf0 ("ALSA: usb-audio: Add missing ep_idx in fixed EP quirks")
    Reported-and-tested-by: André Kapelrud <a.kapelrud@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220606160910.6926-3-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a08c4a92f2f87f9d00db18262f4332c63eeeb2c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jun 6 18:09:09 2022 +0200

    ALSA: usb-audio: Skip generic sync EP parse for secondary EP
    
    commit efb75df105e82f076a85b9f2d81410428bcb55fc upstream.
    
    When ep_idx is already non-zero, it means usually a capture stream
    that is set up explicity by a fixed-format quirk, and applying the
    check for generic (non-implicit-fb) sync EPs might hit incorrectly,
    resulting in a bogus sync endpoint for the capture stream.
    
    This patch adds a check for the ep_idx and skip if it's a secondary
    endpoint.  It's a part of the fixes for regressions on Saffire 6.
    
    Fixes: 7b0efea4baf0 ("ALSA: usb-audio: Add missing ep_idx in fixed EP quirks")
    Reported-and-tested-by: André Kapelrud <a.kapelrud@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220606160910.6926-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2f664d5db68a5c6fbee07ee5c00c2f26da26867
Author: Bedant Patnaik <bedant.patnaik@gmail.com>
Date:   Thu Jun 9 00:58:43 2022 +0530

    platform/x86: hp-wmi: Use zero insize parameter only when supported
    
    [ Upstream commit 65f936f3535950d2643eac5bf34a735a0e428cdd ]
    
    commit be9d73e64957 ("platform/x86: hp-wmi: Fix 0x05 error code reported by
    several WMI calls") and commit 12b19f14a21a ("platform/x86: hp-wmi: Fix
    hp_wmi_read_int() reporting error (0x05)") cause ACPI BIOS Error (bug):
    Attempt to CreateField of length zero (20211217/dsopcode-133) because of
    the ACPI method HWMC, which unconditionally creates a Field of
    size (insize*8) bits:
            CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN)
    In cases where args->insize = 0, the Field size is 0, resulting in
    an error.
    
    Fix this by using zero insize only if 0x5 error code is returned
    
    Tested on Omen 15 AMD (2020) board ID: 8786.
    
    Fixes: be9d73e64957 ("platform/x86: hp-wmi: Fix 0x05 error code reported by several WMI calls")
    Signed-off-by: Bedant Patnaik <bedant.patnaik@gmail.com>
    Tested-by: Jorge Lopez <jorge.lopez2@hp.com>
    Link: https://lore.kernel.org/r/41be46743d21c78741232a47bbb5f1cdbcc3d21e.camel@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d34896fd4ae2dfd119a880c2c120229202b9694b
Author: Jorge Lopez <jorge.lopez2@hp.com>
Date:   Thu Mar 10 15:08:50 2022 -0600

    platform/x86: hp-wmi: Fix hp_wmi_read_int() reporting error (0x05)
    
    [ Upstream commit 12b19f14a21a2ee6348825d95b642ef2cd16794f ]
    
    The purpose of this patch is to introduce a fix to hp_wmi_read_int()
    and eliminate failure error (0x05). Several WMI queries leverage
    hp_wmi_read_int() to read their data and were failing with error 0x05.
    
    HPWMI_DISPLAY_QUERY
    HPWMI_HDDTEMP_QUERY
    HPWMI_ALS_QUERY
    HPWMI_HARDWARE_QUERY
    HPWMI_WIRELESS_QUERY
    HPWMI_POSTCODEERROR_QUERY
    
    The failure occurs because hp_wmi_read_int() calls
    hp_wmi_perform_query() with input parameter of size greater than zero.
    Invoking those WMI commands with an input buffer size greater than
    zero causes the command to be rejected and error 0x05 be returned.
    
    All changes were validated on a HP ZBook Workstation notebook,
    HP EliteBook x360, and HP EliteBook 850 G8.
    
    Signed-off-by: Jorge Lopez <jorge.lopez2@hp.com>
    Link: https://lore.kernel.org/r/20220310210853.28367-2-jorge.lopez2@hp.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 669e8dd1265fef6a2bd495d63d83b1c21f928ba0
Author: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Date:   Fri Jun 10 15:14:57 2022 +0800

    scripts/gdb: change kernel config dumping method
    
    [ Upstream commit 1f7a6cf6b07c74a17343c2559cd5f5018a245961 ]
    
    MAGIC_START("IKCFG_ST") and MAGIC_END("IKCFG_ED") are moved out
    from the kernel_config_data variable.
    
    Thus, we parse kernel_config_data directly instead of considering
    offset of MAGIC_START and MAGIC_END.
    
    Fixes: 13610aa908dc ("kernel/configs: use .incbin directive to embed config_data.gz")
    Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 929f265c40feadfd57e3a8c650a007b541fde2b1
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Thu May 26 17:03:45 2022 +0800

    platform/x86: barco-p50-gpio: Add check for platform_driver_register
    
    [ Upstream commit 011881b80ebe773914b59905bce0f5e0ef93e7ba ]
    
    As platform_driver_register() could fail, it should be better
    to deal with the return value in order to maintain the code
    consisitency.
    
    Fixes: 86af1d02d458 ("platform/x86: Support for EC-connected GPIOs for identify LED/button on Barco P50 board")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Acked-by: Peter Korsgaard <peter.korsgaard@barco.com>
    Link: https://lore.kernel.org/r/20220526090345.1444172-1-jiasheng@iscas.ac.cn
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c30b0d14603ea0b00fad70fdc671534688e6629c
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Thu May 5 18:09:10 2022 +0800

    vringh: Fix loop descriptors check in the indirect cases
    
    [ Upstream commit dbd29e0752286af74243cf891accf472b2f3edd8 ]
    
    We should use size of descriptor chain to test loop condition
    in the indirect case. And another statistical count is also introduced
    for indirect descriptors to avoid conflict with the statistical count
    of direct descriptors.
    
    Fixes: f87d0fbb5798 ("vringh: host-side implementation of virtio rings.")
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Signed-off-by: Fam Zheng <fam.zheng@bytedance.com>
    Message-Id: <20220505100910.137-1-xieyongji@bytedance.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d212b5909d051442264c4b9627c74118990dd1cb
Author: Kees Cook <keescook@chromium.org>
Date:   Wed May 18 13:52:23 2022 -0700

    nodemask: Fix return values to be unsigned
    
    [ Upstream commit 0dfe54071d7c828a02917b595456bfde1afdddc9 ]
    
    The nodemask routines had mixed return values that provided potentially
    signed return values that could never happen. This was leading to the
    compiler getting confusing about the range of possible return values
    (it was thinking things could be negative where they could not be). Fix
    all the nodemask routines that should be returning unsigned
    (or bool) values. Silences:
    
     mm/swapfile.c: In function ‘setup_swap_info’:
     mm/swapfile.c:2291:47: error: array subscript -1 is below array bounds of ‘struct plist_node[]’ [-Werror=array-bounds]
      2291 |                                 p->avail_lists[i].prio = 1;
           |                                 ~~~~~~~~~~~~~~^~~
     In file included from mm/swapfile.c:16:
     ./include/linux/swap.h:292:27: note: while referencing ‘avail_lists’
       292 |         struct plist_node avail_lists[]; /*
           |                           ^~~~~~~~~~~
    
    Reported-by: Christophe de Dinechin <dinechin@redhat.com>
    Link: https://lore.kernel.org/lkml/20220414150855.2407137-3-dinechin@redhat.com/
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Yury Norov <yury.norov@gmail.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Zhen Lei <thunder.leizhen@huawei.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55d1b40e256b4958baf91ad7648f63e734e60e1a
Author: Yury Norov <yury.norov@gmail.com>
Date:   Thu Apr 28 13:51:16 2022 -0700

    drm/amd/pm: use bitmap_{from,to}_arr32 where appropriate
    
    [ Upstream commit 525d6515604eb1373ce5e6372a6b6640953b2d6a ]
    
    The smu_v1X_0_set_allowed_mask() uses bitmap_copy() to convert
    bitmap to 32-bit array. This may be wrong due to endiannes issues.
    Fix it by switching to bitmap_{from,to}_arr32.
    
    CC: Alexander Gordeev <agordeev@linux.ibm.com>
    CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    CC: Christian Borntraeger <borntraeger@linux.ibm.com>
    CC: Claudio Imbrenda <imbrenda@linux.ibm.com>
    CC: David Hildenbrand <david@redhat.com>
    CC: Heiko Carstens <hca@linux.ibm.com>
    CC: Janosch Frank <frankja@linux.ibm.com>
    CC: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    CC: Sven Schnelle <svens@linux.ibm.com>
    CC: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 278cd0d714d5fdbfc69364b3ec1c27d2d5e2d13f
Author: Steve French <stfrench@microsoft.com>
Date:   Wed Jun 1 22:08:46 2022 -0500

    cifs: version operations for smb20 unneeded when legacy support disabled
    
    [ Upstream commit 7ef93ffccd55fb0ba000ed16ef6a81cd7dee07b5 ]
    
    We should not be including unused smb20 specific code when legacy
    support is disabled (CONFIG_CIFS_ALLOW_INSECURE_LEGACY turned
    off).  For example smb2_operations and smb2_values aren't used
    in that case.  Over time we can move more and more SMB1/CIFS and SMB2.0
    code into the insecure legacy ifdefs
    
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eeb86807d19e75043dc069c7256499dc9fa57495
Author: Christian Borntraeger <borntraeger@linux.ibm.com>
Date:   Mon May 30 11:27:05 2022 +0200

    s390/gmap: voluntarily schedule during key setting
    
    [ Upstream commit 6d5946274df1fff539a7eece458a43be733d1db8 ]
    
    With large and many guest with storage keys it is possible to create
    large latencies or stalls during initial key setting:
    
    rcu: INFO: rcu_sched self-detected stall on CPU
    rcu:   18-....: (2099 ticks this GP) idle=54e/1/0x4000000000000002 softirq=35598716/35598716 fqs=998
           (t=2100 jiffies g=155867385 q=20879)
    Task dump for CPU 18:
    CPU 1/KVM       R  running task        0 1030947 256019 0x06000004
    Call Trace:
    sched_show_task
    rcu_dump_cpu_stacks
    rcu_sched_clock_irq
    update_process_times
    tick_sched_handle
    tick_sched_timer
    __hrtimer_run_queues
    hrtimer_interrupt
    do_IRQ
    ext_int_handler
    ptep_zap_key
    
    The mmap lock is held during the page walking but since this is a
    semaphore scheduling is still possible. Same for the kvm srcu.
    To minimize overhead do this on every segment table entry or large page.
    
    Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220530092706.11637-2-borntraeger@linux.ibm.com
    Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d8ca199de788e31f5bb32561a522da81fea62c0
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed May 11 15:18:56 2022 -0500

    Revert "PCI: brcmstb: Split brcm_pcie_setup() into two funcs"
    
    [ Upstream commit f4fd559de3434c44bed1d2912bd0c75cfa42898b ]
    
    This reverts commit 830aa6f29f07a4e2f1a947dfa72b3ccddb46dd21.
    
    This is part of a revert of the following commits:
    
      11ed8b8624b8 ("PCI: brcmstb: Do not turn off WOL regulators on suspend")
      93e41f3fca3d ("PCI: brcmstb: Add control of subdevice voltage regulators")
      67211aadcb4b ("PCI: brcmstb: Add mechanism to turn on subdev regulators")
      830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup() into two funcs")
    
    Cyril reported that 830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup()
    into two funcs"), which appeared in v5.17-rc1, broke booting on the
    Raspberry Pi Compute Module 4.  Apparently 830aa6f29f07 panics with an
    Asynchronous SError Interrupt, and after further commits here is a black
    screen on HDMI and no output on the serial console.
    
    This does not seem to affect the Raspberry Pi 4 B.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215925
    Link: https://lore.kernel.org/r/20220511201856.808690-5-helgaas@kernel.org
    Reported-by: Cyril Brulebois <kibi@debian.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f0b924647390ae2b498d15d6015f2cbb4f6ca02
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed May 11 15:18:55 2022 -0500

    Revert "PCI: brcmstb: Add mechanism to turn on subdev regulators"
    
    [ Upstream commit 420be2f7ebe60c9ba3e332f5290017cd168e2bf8 ]
    
    This reverts commit 67211aadcb4b968d0fdc57bc27240fa71500c2d4.
    
    This is part of a revert of the following commits:
    
      11ed8b8624b8 ("PCI: brcmstb: Do not turn off WOL regulators on suspend")
      93e41f3fca3d ("PCI: brcmstb: Add control of subdevice voltage regulators")
      67211aadcb4b ("PCI: brcmstb: Add mechanism to turn on subdev regulators")
      830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup() into two funcs")
    
    Cyril reported that 830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup()
    into two funcs"), which appeared in v5.17-rc1, broke booting on the
    Raspberry Pi Compute Module 4.  Apparently 830aa6f29f07 panics with an
    Asynchronous SError Interrupt, and after further commits here is a black
    screen on HDMI and no output on the serial console.
    
    This does not seem to affect the Raspberry Pi 4 B.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215925
    Link: https://lore.kernel.org/r/20220511201856.808690-4-helgaas@kernel.org
    Reported-by: Cyril Brulebois <kibi@debian.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 63b3ab2af7677637187f9b227dd72c2ffde81c21
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed May 11 15:18:54 2022 -0500

    Revert "PCI: brcmstb: Add control of subdevice voltage regulators"
    
    [ Upstream commit 212942609d83b591f5a2f2691df122d13aa3a87d ]
    
    This reverts commit 93e41f3fca3d4a0f927b784012338c37f80a8a80.
    
    This is part of a revert of the following commits:
    
      11ed8b8624b8 ("PCI: brcmstb: Do not turn off WOL regulators on suspend")
      93e41f3fca3d ("PCI: brcmstb: Add control of subdevice voltage regulators")
      67211aadcb4b ("PCI: brcmstb: Add mechanism to turn on subdev regulators")
      830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup() into two funcs")
    
    Cyril reported that 830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup()
    into two funcs"), which appeared in v5.17-rc1, broke booting on the
    Raspberry Pi Compute Module 4.  Apparently 830aa6f29f07 panics with an
    Asynchronous SError Interrupt, and after further commits here is a black
    screen on HDMI and no output on the serial console.
    
    This does not seem to affect the Raspberry Pi 4 B.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215925
    Link: https://lore.kernel.org/r/20220511201856.808690-3-helgaas@kernel.org
    Reported-by: Cyril Brulebois <kibi@debian.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c89161dad4f1cc7f00981fb9ec8ee3507e2ff1b
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed May 11 15:18:53 2022 -0500

    Revert "PCI: brcmstb: Do not turn off WOL regulators on suspend"
    
    [ Upstream commit 7894025c783ca36394d3afe49c8cfb4c830b82fe ]
    
    This reverts commit 11ed8b8624b8085f706864b4addcd304b1e4fc38.
    
    This is part of a revert of the following commits:
    
      11ed8b8624b8 ("PCI: brcmstb: Do not turn off WOL regulators on suspend")
      93e41f3fca3d ("PCI: brcmstb: Add control of subdevice voltage regulators")
      67211aadcb4b ("PCI: brcmstb: Add mechanism to turn on subdev regulators")
      830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup() into two funcs")
    
    Cyril reported that 830aa6f29f07 ("PCI: brcmstb: Split brcm_pcie_setup()
    into two funcs"), which appeared in v5.17-rc1, broke booting on the
    Raspberry Pi Compute Module 4.  Apparently 830aa6f29f07 panics with an
    Asynchronous SError Interrupt, and after further commits here is a black
    screen on HDMI and no output on the serial console.
    
    This does not seem to affect the Raspberry Pi 4 B.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215925
    Link: https://lore.kernel.org/r/20220511201856.808690-2-helgaas@kernel.org
    Reported-by: Cyril Brulebois <kibi@debian.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54b06dc2a206b4d67349bb56b92d4bd32700b7b1
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Sat May 21 15:37:47 2022 +0800

    nbd: fix io hung while disconnecting device
    
    [ Upstream commit 09dadb5985023e27d4740ebd17e6fea4640110e5 ]
    
    In our tests, "qemu-nbd" triggers a io hung:
    
    INFO: task qemu-nbd:11445 blocked for more than 368 seconds.
          Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    task:qemu-nbd        state:D stack:    0 pid:11445 ppid:     1 flags:0x00000000
    Call Trace:
     <TASK>
     __schedule+0x480/0x1050
     ? _raw_spin_lock_irqsave+0x3e/0xb0
     schedule+0x9c/0x1b0
     blk_mq_freeze_queue_wait+0x9d/0xf0
     ? ipi_rseq+0x70/0x70
     blk_mq_freeze_queue+0x2b/0x40
     nbd_add_socket+0x6b/0x270 [nbd]
     nbd_ioctl+0x383/0x510 [nbd]
     blkdev_ioctl+0x18e/0x3e0
     __x64_sys_ioctl+0xac/0x120
     do_syscall_64+0x35/0x80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7fd8ff706577
    RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577
    RDX: 000000000000000d RSI: 000000000000ab00 RDI: 000000000000000f
    RBP: 000000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0
    R10: 00000002aff20000 R11: 0000000000000246 R12: 000000000000006d
    R13: 0000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0
    
    "qemu-ndb -d" will call ioctl 'NBD_DISCONNECT' first, however, following
    message was found:
    
    block nbd0: Send disconnect failed -32
    
    Which indicate that something is wrong with the server. Then,
    "qemu-nbd -d" will call ioctl 'NBD_CLEAR_SOCK', however ioctl can't clear
    requests after commit 2516ab1543fd("nbd: only clear the queue on device
    teardown"). And in the meantime, request can't complete through timeout
    because nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', which
    means such request will never be completed in this situation.
    
    Now that the flag 'NBD_CMD_INFLIGHT' can make sure requests won't
    complete multiple times, switch back to call nbd_clear_sock() in
    nbd_clear_sock_ioctl(), so that inflight requests can be cleared.
    
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20220521073749.3146892-5-yukuai3@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2888fa41985f93ed0a6837cfbb06bcbfd7fa2314
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Sat May 21 15:37:45 2022 +0800

    nbd: fix race between nbd_alloc_config() and module removal
    
    [ Upstream commit c55b2b983b0fa012942c3eb16384b2b722caa810 ]
    
    When nbd module is being removing, nbd_alloc_config() may be
    called concurrently by nbd_genl_connect(), although try_module_get()
    will return false, but nbd_alloc_config() doesn't handle it.
    
    The race may lead to the leak of nbd_config and its related
    resources (e.g, recv_workq) and oops in nbd_read_stat() due
    to the unload of nbd module as shown below:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000040
      Oops: 0000 [#1] SMP PTI
      CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
      Workqueue: knbd16-recv recv_work [nbd]
      RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd]
      Call Trace:
       recv_work+0x3b/0xb0 [nbd]
       process_one_work+0x1ed/0x390
       worker_thread+0x4a/0x3d0
       kthread+0x12a/0x150
       ret_from_fork+0x22/0x30
    
    Fixing it by checking the return value of try_module_get()
    in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV),
    assign nbd->config only when nbd_alloc_config() succeeds to ensure
    the value of nbd->config is binary (valid or NULL).
    
    Also adding a debug message to check the reference counter
    of nbd_config during module removal.
    
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20220521073749.3146892-3-yukuai3@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f505bbb8063fd3a238a4239d2d8c165e5279f6f
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Sat May 21 15:37:44 2022 +0800

    nbd: call genl_unregister_family() first in nbd_cleanup()
    
    [ Upstream commit 06c4da89c24e7023ea448cadf8e9daf06a0aae6e ]
    
    Otherwise there may be race between module removal and the handling of
    netlink command, which can lead to the oops as shown below:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000098
      Oops: 0002 [#1] SMP PTI
      CPU: 1 PID: 31299 Comm: nbd-client Tainted: G            E     5.14.0-rc4
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
      RIP: 0010:down_write+0x1a/0x50
      Call Trace:
       start_creating+0x89/0x130
       debugfs_create_dir+0x1b/0x130
       nbd_start_device+0x13d/0x390 [nbd]
       nbd_genl_connect+0x42f/0x748 [nbd]
       genl_family_rcv_msg_doit.isra.0+0xec/0x150
       genl_rcv_msg+0xe5/0x1e0
       netlink_rcv_skb+0x55/0x100
       genl_rcv+0x29/0x40
       netlink_unicast+0x1a8/0x250
       netlink_sendmsg+0x21b/0x430
       ____sys_sendmsg+0x2a4/0x2d0
       ___sys_sendmsg+0x81/0xc0
       __sys_sendmsg+0x62/0xb0
       __x64_sys_sendmsg+0x1f/0x30
       do_syscall_64+0x3b/0xc0
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      Modules linked in: nbd(E-)
    
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20220521073749.3146892-2-yukuai3@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d05317ba12b128c4cce0549006f71819b18706e6
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon May 2 12:30:20 2022 +0200

    jump_label,noinstr: Avoid instrumentation for JUMP_LABEL=n builds
    
    [ Upstream commit 656d054e0a15ec327bd82801ccd58201e59f6896 ]
    
    When building x86_64 with JUMP_LABEL=n it's possible for
    instrumentation to sneak into noinstr:
    
    vmlinux.o: warning: objtool: exit_to_user_mode+0x14: call to static_key_count.constprop.0() leaves .noinstr.text section
    vmlinux.o: warning: objtool: syscall_exit_to_user_mode+0x2d: call to static_key_count.constprop.0() leaves .noinstr.text section
    vmlinux.o: warning: objtool: irqentry_exit_to_user_mode+0x1b: call to static_key_count.constprop.0() leaves .noinstr.text section
    
    Switch to arch_ prefixed atomic to avoid the explicit instrumentation.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdce3bf65391580b085826b1612da778f9726021
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon May 2 12:15:23 2022 +0200

    x86/cpu: Elide KCSAN for cpu_has() and friends
    
    [ Upstream commit a6a5eb269f6f3a2fe392f725a8d9052190c731e2 ]
    
    As x86 uses the <asm-generic/bitops/instrumented-*.h> headers, the
    regular forms of all bitops are instrumented with explicit calls to
    KASAN and KCSAN checks. As these are explicit calls, these are not
    suppressed by the noinstr function attribute.
    
    This can result in calls to those check functions in noinstr code, which
    objtool warns about:
    
    vmlinux.o: warning: objtool: enter_from_user_mode+0x24: call to __kcsan_check_access() leaves .noinstr.text section
    vmlinux.o: warning: objtool: syscall_enter_from_user_mode+0x28: call to __kcsan_check_access() leaves .noinstr.text section
    vmlinux.o: warning: objtool: syscall_enter_from_user_mode_prepare+0x24: call to __kcsan_check_access() leaves .noinstr.text section
    vmlinux.o: warning: objtool: irqentry_enter_from_user_mode+0x24: call to __kcsan_check_access() leaves .noinstr.text section
    
    Prevent this by using the arch_*() bitops, which are the underlying
    bitops without explciit instrumentation.
    
    [null: Changelog]
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20220502111216.290518605@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8583b47a0a07e4e96b6f8c3cd1e36f29e1e967c
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue May 24 01:46:22 2022 +0900

    modpost: fix undefined behavior of is_arm_mapping_symbol()
    
    [ Upstream commit d6b732666a1bae0df3c3ae06925043bba34502b1 ]
    
    The return value of is_arm_mapping_symbol() is unpredictable when "$"
    is passed in.
    
    strchr(3) says:
      The strchr() and strrchr() functions return a pointer to the matched
      character or NULL if the character is not found. The terminating null
      byte is considered part of the string, so that if c is specified as
      '\0', these functions return a pointer to the terminator.
    
    When str[1] is '\0', strchr("axtd", str[1]) is not NULL, and str[2] is
    referenced (i.e. buffer overrun).
    
    Test code
    ---------
    
      char str1[] = "abc";
      char str2[] = "ab";
    
      strcpy(str1, "$");
      strcpy(str2, "$");
    
      printf("test1: %d\n", is_arm_mapping_symbol(str1));
      printf("test2: %d\n", is_arm_mapping_symbol(str2));
    
    Result
    ------
    
      test1: 0
      test2: 1
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab11cd8bcf2db637058f2195b02d8ed5a0507317
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri May 6 15:46:12 2022 +0200

    um: line: Use separate IRQs per line
    
    [ Upstream commit d5a9597d6916a76663085db984cb8fe97f0a5c56 ]
    
    Today, all possible serial lines (ssl*=) as well as all
    possible consoles (con*=) each share a single interrupt
    (with a fixed number) with others of the same type.
    
    Now, if you have two lines, say ssl0 and ssl1, and one
    of them is connected to an fd you cannot read (e.g. a
    file), but the other gets a read interrupt, then both
    of them get the interrupt since it's shared. Then, the
    read() call will return EOF, since it's a file being
    written and there's nothing to read (at least not at
    the current offset, at the end).
    
    Unfortunately, this is treated as a read error, and we
    close this line, losing all the possible output.
    
    It might be possible to work around this and make the
    IRQ sharing work, however, now that we have dynamically
    allocated IRQs that are easy to use, simply use that to
    achieve separating between the events; then there's no
    interrupt for that line and we never attempt the read
    in the first place, thus not closing the line.
    
    This manifested itself in the wifi hostap/hwsim tests
    where the parallel script communicates via one serial
    console and the kernel messages go to another (a file)
    and sending data on the communication console caused
    the kernel messages to stop flowing into the file.
    
    Reported-by: Jouni Malinen <j@w1.fi>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Acked-By: anton ivanov <anton.ivanov@cambridgegreys.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6703e116557bd46413e43c2c93e2937bc8a97e88
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Thu May 19 10:50:25 2022 +0530

    drm/amd/pm: Fix missing thermal throttler status
    
    [ Upstream commit b0f4d663fce6a4232d3c20ce820f919111b1c60b ]
    
    On aldebaran, when thermal throttling happens due to excessive GPU
    temperature, the reason for throttling event is missed in warning
    message. This patch fixes it.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a3ab1f44def86f0de9439fd5308a288b621a40e
Author: Gong Yuanjun <ruc_gongyuanjun@163.com>
Date:   Tue May 17 17:57:46 2022 +0800

    drm/amd/pm: fix a potential gpu_metrics_table memory leak
    
    [ Upstream commit d2f4460a3d9502513419f06cc376c7ade49d5753 ]
    
    gpu_metrics_table is allocated in yellow_carp_init_smc_tables() but
    not freed in yellow_carp_fini_smc_tables().
    
    Signed-off-by: Gong Yuanjun <ruc_gongyuanjun@163.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e938d24f0b7392e142b8aa434f18590d99dbe479
Author: Gong Yuanjun <ruc_gongyuanjun@163.com>
Date:   Tue May 17 17:57:00 2022 +0800

    drm/radeon: fix a possible null pointer dereference
    
    [ Upstream commit a2b28708b645c5632dc93669ab06e97874c8244f ]
    
    In radeon_fp_native_mode(), the return value of drm_mode_duplicate()
    is assigned to mode, which will lead to a NULL pointer dereference
    on failure of drm_mode_duplicate(). Add a check to avoid npd.
    
    The failure status of drm_cvt_mode() on the other path is checked too.
    
    Signed-off-by: Gong Yuanjun <ruc_gongyuanjun@163.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96725758eff7b3805e4e94d1443a100757412720
Author: David Galiffi <David.Galiffi@amd.com>
Date:   Tue May 3 18:30:25 2022 -0400

    drm/amd/display: Check if modulo is 0 before dividing.
    
    [ Upstream commit 49947b906a6bd9668eaf4f9cf691973c25c26955 ]
    
    [How & Why]
    If a value of 0 is read, then this will cause a divide-by-0 panic.
    
    Reviewed-by: Martin Leung <Martin.Leung@amd.com>
    Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
    Signed-off-by: David Galiffi <David.Galiffi@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b4a0edb03f993fa9989cc6f4c07a2d6f6fbc36da
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Wed May 25 00:56:18 2022 +0200

    net, neigh: Set lower cap for neigh_managed_work rearming
    
    [ Upstream commit ed6cd6a17896561b9f51ab4c0d9bbb29e762b597 ]
    
    Yuwei reported that plain reuse of DELAY_PROBE_TIME to rearm work queue
    in neigh_managed_work is problematic if user explicitly configures the
    DELAY_PROBE_TIME to 0 for a neighbor table. Such misconfig can then hog
    CPU to 100% processing the system work queue. Instead, set lower interval
    bound to HZ which is totally sufficient. Yuwei is additionally looking
    into making the interval separately configurable from DELAY_PROBE_TIME.
    
    Reported-by: Yuwei Wang <wangyuweihx@gmail.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/netdev/797c3c53-ce1b-9f60-e253-cda615788f4a@iogearbox.net
    Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://lore.kernel.org/r/3b8c5aa906c52c3a8c995d1b2e8ccf650ea7c716.1653432794.git.daniel@iogearbox.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e25051763603c3d70f23472bb1ee51d7d26b7be
Author: Xiubo Li <xiubli@redhat.com>
Date:   Tue Apr 19 08:58:49 2022 +0800

    ceph: flush the mdlog for filesystem sync
    
    [ Upstream commit 1b2ba3c5616e17ff951359e25c658a1c3f146f1e ]
    
    Before waiting for a request's safe reply, we will send the mdlog flush
    request to the relevant MDS. And this will also flush the mdlog for all
    the other unsafe requests in the same session, so we can record the last
    session and no need to flush mdlog again in the next loop. But there
    still have cases that it may send the mdlog flush requst twice or more,
    but that should be not often.
    
    Rename wait_unsafe_requests() to
    flush_mdlog_and_wait_mdsc_unsafe_requests() to make it more
    descriptive.
    
    [xiubli: fold in MDS request refcount leak fix from Jeff]
    
    URL: https://tracker.ceph.com/issues/55284
    URL: https://tracker.ceph.com/issues/55411
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e195336c1080bf951070079a7ea9f93020d6465
Author: Venky Shankar <vshankar@redhat.com>
Date:   Thu Mar 10 09:34:19 2022 -0500

    ceph: allow ceph.dir.rctime xattr to be updatable
    
    [ Upstream commit d7a2dc523085f8b8c60548ceedc696934aefeb0e ]
    
    `rctime' has been a pain point in cephfs due to its buggy
    nature - inconsistent values reported and those sorts.
    Fixing rctime is non-trivial needing an overall redesign
    of the entire nested statistics infrastructure.
    
    As a workaround, PR
    
         http://github.com/ceph/ceph/pull/37938
    
    allows this extended attribute to be manually set. This allows
    users to "fixup" inconsistent rctime values. While this sounds
    messy, its probably the wisest approach allowing users/scripts
    to workaround buggy rctime values.
    
    The above PR enables Ceph MDS to allow manually setting
    rctime extended attribute with the corresponding user-land
    changes. We may as well allow the same to be done via kclient
    for parity.
    
    Signed-off-by: Venky Shankar <vshankar@redhat.com>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b645df014911d4f051d1a56038a694dc3e178a2
Author: Michal Kubecek <mkubecek@suse.cz>
Date:   Mon May 23 22:05:24 2022 +0200

    Revert "net: af_key: add check for pfkey_broadcast in function pfkey_process"
    
    [ Upstream commit 9c90c9b3e50e16d03c7f87d63e9db373974781e0 ]
    
    This reverts commit 4dc2a5a8f6754492180741facf2a8787f2c415d7.
    
    A non-zero return value from pfkey_broadcast() does not necessarily mean
    an error occurred as this function returns -ESRCH when no registered
    listener received the message. In particular, a call with
    BROADCAST_PROMISC_ONLY flag and null one_sk argument can never return
    zero so that this commit in fact prevents processing any PF_KEY message.
    One visible effect is that racoon daemon fails to find encryption
    algorithms like aes and refuses to start.
    
    Excluding -ESRCH return value would fix this but it's not obvious that
    we really want to bail out here and most other callers of
    pfkey_broadcast() also ignore the return value. Also, as pointed out by
    Steffen Klassert, PF_KEY is kind of deprecated and newer userspace code
    should use netlink instead so that we should only disturb the code for
    really important fixes.
    
    v2: add a comment explaining why is the return value ignored
    
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cde7ae477b68bd2f58bafc2606dcfd0a9aa5f262
Author: Oder Chiou <oder_chiou@realtek.com>
Date:   Mon May 16 18:30:55 2022 +0800

    ASoC: rt5640: Do not manipulate pin "Platform Clock" if the "Platform Clock" is not in the DAPM
    
    [ Upstream commit 832296804bc7171730884e78c761c29f6d258e13 ]
    
    The pin "Platform Clock" was only used by the Intel Byt CR platform. In the
    others, the error log will be informed. The patch will set the flag to
    avoid the pin "Platform Clock" manipulated by the other platforms.
    
    Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
    Reported-by: Sameer Pujar <spujar@nvidia.com>
    Link: https://lore.kernel.org/r/20220516103055.20003-1-oder_chiou@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3888928653020a3766f0fd0317c89c0caa518ef5
Author: Hannes Reinecke <hare@suse.de>
Date:   Mon May 23 14:02:44 2022 +0200

    scsi: myrb: Fix up null pointer access on myrb_cleanup()
    
    [ Upstream commit f9f0a46141e2e39bedb4779c88380d1b5f018c14 ]
    
    When myrb_probe() fails the callback might not be set, so we need to
    validate the 'disable_intr' callback in myrb_cleanup() to not cause a null
    pointer exception. And while at it do not call myrb_cleanup() if we cannot
    enable the PCI device at all.
    
    Link: https://lore.kernel.org/r/20220523120244.99515-1-hare@suse.de
    Reported-by: Zheyu Ma <zheyuma97@gmail.com>
    Tested-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fb2060268b92e109ed0ad6030b95a49068b0b24e
Author: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Date:   Fri Apr 29 16:49:09 2022 +0800

    md: protect md_unregister_thread from reentrancy
    
    [ Upstream commit 1e267742283a4b5a8ca65755c44166be27e9aa0f ]
    
    Generally, the md_unregister_thread is called with reconfig_mutex, but
    raid_message in dm-raid doesn't hold reconfig_mutex to unregister thread,
    so md_unregister_thread can be called simulitaneously from two call sites
    in theory.
    
    Then after previous commit which remove the protection of reconfig_mutex
    for md_unregister_thread completely, the potential issue could be worse
    than before.
    
    Let's take pers_lock at the beginning of function to ensure reentrancy.
    
    Reported-by: Donald Buczek <buczek@molgen.mpg.de>
    Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0945b0d34aac4571c96276641657d85eb9af4ec8
Author: Hyunchul Lee <hyc.lee@gmail.com>
Date:   Wed May 18 06:46:08 2022 +0900

    ksmbd: smbd: fix connection dropped issue
    
    [ Upstream commit 5366afc4065075a4456941fbd51c33604d631ee5 ]
    
    When there are bursty connection requests,
    RDMA connection event handler is deferred and
    Negotiation requests are received even if
    connection status is NEW.
    
    To handle it, set the status to CONNECTED
    if Negotiation requests are received.
    
    Reported-by: Yufan Chen <wiz.chen@gmail.com>
    Signed-off-by: Hyunchul Lee <hyc.lee@gmail.com>
    Tested-by: Yufan Chen <wiz.chen@gmail.com>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a16764259fcf3de3a26f99b435cd5be7c01d38a3
Author: Liu Xinpeng <liuxp11@chinatelecom.cn>
Date:   Tue Apr 26 22:53:29 2022 +0800

    watchdog: wdat_wdt: Stop watchdog when rebooting the system
    
    [ Upstream commit 27fdf84510a1374748904db43f6755f912736d92 ]
    
    Executing reboot command several times on the machine "Dell
    PowerEdge R740", UEFI security detection stopped machine
    with the following prompt:
    
    UEFI0082: The system was reset due to a timeout from the watchdog
    timer. Check the System Event Log (SEL) or crash dumps from
    Operating Sysstem to identify the source that triggered the
    watchdog timer reset. Update the firmware or driver for the
    identified device.
    
    iDRAC has warning event: "The watchdog timer reset the system".
    
    This patch fixes this issue by adding the reboot notifier.
    
    Signed-off-by: Liu Xinpeng <liuxp11@chinatelecom.cn>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/1650984810-6247-3-git-send-email-liuxp11@chinatelecom.cn
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 894a152eca743c17cd4ee72b67974d66cca280ba
Author: Hao Luo <haoluo@google.com>
Date:   Mon May 16 12:09:51 2022 -0700

    kernfs: Separate kernfs_pr_cont_buf and rename_lock.
    
    [ Upstream commit 1a702dc88e150487c9c173a249b3d236498b9183 ]
    
    Previously the protection of kernfs_pr_cont_buf was piggy backed by
    rename_lock, which means that pr_cont() needs to be protected under
    rename_lock. This can cause potential circular lock dependencies.
    
    If there is an OOM, we have the following call hierarchy:
    
     -> cpuset_print_current_mems_allowed()
       -> pr_cont_cgroup_name()
         -> pr_cont_kernfs_name()
    
    pr_cont_kernfs_name() will grab rename_lock and call printk. So we have
    the following lock dependencies:
    
     kernfs_rename_lock -> console_sem
    
    Sometimes, printk does a wakeup before releasing console_sem, which has
    the dependence chain:
    
     console_sem -> p->pi_lock -> rq->lock
    
    Now, imagine one wants to read cgroup_name under rq->lock, for example,
    printing cgroup_name in a tracepoint in the scheduler code. They will
    be holding rq->lock and take rename_lock:
    
     rq->lock -> kernfs_rename_lock
    
    Now they will deadlock.
    
    A prevention to this circular lock dependency is to separate the
    protection of pr_cont_buf from rename_lock. In principle, rename_lock
    is to protect the integrity of cgroup name when copying to buf. Once
    pr_cont_buf has got its content, rename_lock can be dropped. So it's
    safe to drop rename_lock after kernfs_name_locked (and
    kernfs_path_from_node_locked) and rely on a dedicated pr_cont_lock
    to protect pr_cont_buf.
    
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Hao Luo <haoluo@google.com>
    Link: https://lore.kernel.org/r/20220516190951.3144144-1-haoluo@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83d818128464aae06e300b044655105532db59ef
Author: John Ogness <john.ogness@linutronix.de>
Date:   Fri May 6 23:39:24 2022 +0206

    serial: msm_serial: disable interrupts in __msm_console_write()
    
    [ Upstream commit aabdbb1b7a5819e18c403334a31fb0cc2c06ad41 ]
    
    __msm_console_write() assumes that interrupts are disabled, but
    with threaded console printers it is possible that the write()
    callback of the console is called with interrupts enabled.
    
    Explicitly disable interrupts using local_irq_save() to preserve
    the assumed context.
    
    Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Link: https://lore.kernel.org/r/20220506213324.470461-1-john.ogness@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 76a964ad0ea8f2b10abd69a7532e174a28258283
Author: Wang Cheng <wanngchenng@gmail.com>
Date:   Mon May 16 17:22:41 2022 +0800

    staging: rtl8712: fix uninit-value in r871xu_drv_init()
    
    [ Upstream commit 0458e5428e5e959d201a40ffe71d762a79ecedc4 ]
    
    When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0,
    'mac[6]' will not be initialized.
    
    BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541
     r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541
     usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
     really_probe+0x653/0x14b0 drivers/base/dd.c:596
     __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
     driver_probe_device drivers/base/dd.c:782 [inline]
     __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
     bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
     __device_attach+0x593/0x8e0 drivers/base/dd.c:970
     device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
     bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
     device_add+0x1fff/0x26e0 drivers/base/core.c:3405
     usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
     usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
     usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
     really_probe+0x653/0x14b0 drivers/base/dd.c:596
     __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
     driver_probe_device drivers/base/dd.c:782 [inline]
     __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
     bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
     __device_attach+0x593/0x8e0 drivers/base/dd.c:970
     device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
     bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
     device_add+0x1fff/0x26e0 drivers/base/core.c:3405
     usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566
     hub_port_connect drivers/usb/core/hub.c:5358 [inline]
     hub_port_connect_change drivers/usb/core/hub.c:5502 [inline]
     port_event drivers/usb/core/hub.c:5660 [inline]
     hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742
     process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307
     worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454
     kthread+0x3c7/0x500 kernel/kthread.c:377
     ret_from_fork+0x1f/0x30
    
    Local variable mac created at:
     r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394
     usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
    
    KMSAN: uninit-value in r871xu_drv_init
    https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8
    
    Reported-by: <syzbot+6f5ecd144854c0d8580b@syzkaller.appspotmail.com>
    Tested-by: <syzbot+6f5ecd144854c0d8580b@syzkaller.appspotmail.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Wang Cheng <wanngchenng@gmail.com>
    Link: https://lore.kernel.org/r/14c3886173dfa4597f0704547c414cfdbcd11d16.1652618244.git.wanngchenng@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7ed3c85da0b230bcdf5329acfe012ed093f3daa
Author: Wang Cheng <wanngchenng@gmail.com>
Date:   Mon May 16 17:22:23 2022 +0800

    staging: rtl8712: fix uninit-value in usb_read8() and friends
    
    [ Upstream commit d1b57669732d09da7e13ef86d058dab0cd57f6e0 ]
    
    When r8712_usbctrl_vendorreq() returns negative, 'data' in
    usb_read{8,16,32} will not be initialized.
    
    BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:643 [inline]
    BUG: KMSAN: uninit-value in string+0x4ec/0x6f0 lib/vsprintf.c:725
     string_nocheck lib/vsprintf.c:643 [inline]
     string+0x4ec/0x6f0 lib/vsprintf.c:725
     vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806
     va_format lib/vsprintf.c:1704 [inline]
     pointer+0x18e6/0x1f70 lib/vsprintf.c:2443
     vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810
     vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158
     vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256
     dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604
     dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615
     __dev_printk+0x3be/0x440 drivers/base/core.c:4627
     _dev_info+0x1ea/0x22f drivers/base/core.c:4673
     r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401
     usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396
     really_probe+0x6c7/0x1350 drivers/base/dd.c:621
     __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
     driver_probe_device drivers/base/dd.c:782 [inline]
     __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
     bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
     __device_attach+0x593/0x8e0 drivers/base/dd.c:970
     device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
     bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
     device_add+0x1fff/0x26e0 drivers/base/core.c:3405
     usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170
     usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238
     usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293
     really_probe+0x6c7/0x1350 drivers/base/dd.c:621
     __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752
     driver_probe_device drivers/base/dd.c:782 [inline]
     __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899
     bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427
     __device_attach+0x593/0x8e0 drivers/base/dd.c:970
     device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017
     bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487
     device_add+0x1fff/0x26e0 drivers/base/core.c:3405
     usb_new_device+0x1b91/0x2950 drivers/usb/core/hub.c:2566
     hub_port_connect drivers/usb/core/hub.c:5363 [inline]
     hub_port_connect_change drivers/usb/core/hub.c:5507 [inline]
     port_event drivers/usb/core/hub.c:5665 [inline]
     hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747
     process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289
     worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436
     kthread+0x3c7/0x500 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30
    
    Local variable data created at:
     usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33
     r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29
    
    KMSAN: uninit-value in r871xu_drv_init
    https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8
    
    Reported-by: <syzbot+6f5ecd144854c0d8580b@syzkaller.appspotmail.com>
    Tested-by: <syzbot+6f5ecd144854c0d8580b@syzkaller.appspotmail.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Wang Cheng <wanngchenng@gmail.com>
    Link: https://lore.kernel.org/r/b9b7a6ee02c02aa28054f5cf16129977775f3cd9.1652618244.git.wanngchenng@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5c4ccfc3481a7e128435d37b702a423a4e716d20
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Fri May 6 17:25:22 2022 +0100

    clocksource/drivers/sp804: Avoid error on multiple instances
    
    [ Upstream commit a98399cbc1e05f7b977419f03905501d566cf54e ]
    
    When a machine sports more than one SP804 timer instance, we only bring
    up the first one, since multiple timers of the same kind are not useful
    to Linux. As this is intentional behaviour, we should not return an
    error message, as we do today:
    ===============
    [    0.000800] Failed to initialize '/bus@8000000/motherboard-bus@8000000/iofpga-bus@300000000/timer@120000': -22
    ===============
    
    Replace the -EINVAL return with a debug message and return 0 instead.
    
    Also we do not reach the init function anymore if the DT node is
    disabled (as this is now handled by OF_DECLARE), so remove the explicit
    check for that case.
    
    This fixes a long standing bogus error when booting ARM's fastmodels.
    
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/20220506162522.3675399-1-andre.przywara@arm.com
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35ff1ac55d301efb3f467cf5426faaeb3452994b
Author: bumwoo lee <bw365.lee@samsung.com>
Date:   Wed Apr 27 12:00:05 2022 +0900

    extcon: Modify extcon device to be created after driver data is set
    
    [ Upstream commit 5dcc2afe716d69f5112ce035cb14f007461ff189 ]
    
    Currently, someone can invoke the sysfs such as state_show()
    intermittently before dev_set_drvdata() is done.
    And it can be a cause of kernel Oops because of edev is Null at that time.
    So modified the driver registration to after setting drviver data.
    
    - Oops's backtrace.
    
    Backtrace:
    [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show)
    [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show)
    [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show)
    [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read)
    [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read)
    [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read)
    [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read)
    [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read)
    [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read)
    [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return)
    
    Signed-off-by: bumwoo lee <bw365.lee@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c33ca06578c147b63adaa1934cc8efedb9553a8e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Dec 17 09:28:46 2021 +0300

    extcon: Fix extcon_get_extcon_dev() error handling
    
    [ Upstream commit 58e4a2d27d3255e4e8c507fdc13734dccc9fc4c7 ]
    
    The extcon_get_extcon_dev() function returns error pointers on error,
    NULL when it's a -EPROBE_DEFER defer situation, and ERR_PTR(-ENODEV)
    when the CONFIG_EXTCON option is disabled.  This is very complicated for
    the callers to handle and a number of them had bugs that would lead to
    an Oops.
    
    In real life, there are two things which prevented crashes.  First,
    error pointers would only be returned if there was bug in the caller
    where they passed a NULL "extcon_name" and none of them do that.
    Second, only two out of the eight drivers will build when CONFIG_EXTCON
    is disabled.
    
    The normal way to write this would be to return -EPROBE_DEFER directly
    when appropriate and return NULL when CONFIG_EXTCON is disabled.  Then
    the error handling is simple and just looks like:
    
            dev->edev = extcon_get_extcon_dev(acpi_dev_name(adev));
            if (IS_ERR(dev->edev))
                    return PTR_ERR(dev->edev);
    
    For the two drivers which can build with CONFIG_EXTCON disabled, then
    extcon_get_extcon_dev() will now return NULL which is not treated as an
    error and the probe will continue successfully.  Those two drivers are
    "typec_fusb302" and "max8997-battery".  In the original code, the
    typec_fusb302 driver had an 800ms hang in tcpm_get_current_limit() but
    now that function is a no-op.  For the max8997-battery driver everything
    should continue working as is.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00f0aada52f7e847c2dc3858cef45efa4d38d4ea
Author: Shuah Khan <skhan@linuxfoundation.org>
Date:   Fri Apr 29 15:09:13 2022 -0600

    misc: rtsx: set NULL intfdata when probe fails
    
    [ Upstream commit f861d36e021e1ac4a0a2a1f6411d623809975d63 ]
    
    rtsx_usb_probe() doesn't call usb_set_intfdata() to null out the
    interface pointer when probe fails. This leaves a stale pointer.
    Noticed the missing usb_set_intfdata() while debugging an unrelated
    invalid DMA mapping problem.
    
    Fix it with a call to usb_set_intfdata(..., NULL).
    
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20220429210913.46804-1-skhan@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit caa1f0dfcefe0f2b2ed448a7a1a1bcef9d8e4964
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Fri May 6 09:47:05 2022 +0100

    soundwire: qcom: adjust autoenumeration timeout
    
    [ Upstream commit 74da272400b46f2e898f115d1b1cd60828766919 ]
    
    Currently timeout for autoenumeration during probe and bus reset is set to
    2 secs which is really a big value. This can have an adverse effect on
    boot time if the slave device is not ready/reset.
    This was the case with wcd938x which was not reset yet but we spent 2
    secs waiting in the soundwire controller probe. Reduce this time to
    1/10 of Hz which should be good enough time to finish autoenumeration
    if any slaves are available on the bus.
    
    Reported-by: Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20220506084705.18525-1-srinivas.kandagatla@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7f35934f7ab67bfd9adabc84207e59da9c19108
Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Date:   Thu Apr 28 14:10:56 2022 +0300

    usb: dwc3: host: Stop setting the ACPI companion
    
    [ Upstream commit 7fd069d65da2e20b1caec3b7bcf9dfbe28c04bb2 ]
    
    It is no longer needed. The sysdev pointer is now used when
    assigning the ACPI companions to the xHCI ports and USB
    devices.
    
    Assigning the ACPI companion here resulted in the
    fwnode->secondary pointer to be replaced also for the parent
    dwc3 device since the primary fwnode (the ACPI companion)
    was shared. That was unintentional and it created potential
    side effects like resource leaks.
    
    Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20220428111056.3558-3-heikki.krogerus@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 172cfc167c8ee6238f24f9c16efd598602af643c
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Thu May 5 12:46:18 2022 +0200

    usb: dwc2: gadget: don't reset gadget's driver->bus
    
    [ Upstream commit 3120aac6d0ecd9accf56894aeac0e265f74d3d5a ]
    
    UDC driver should not touch gadget's driver internals, especially it
    should not reset driver->bus. This wasn't harmful so far, but since
    commit fc274c1e9973 ("USB: gadget: Add a new bus for gadgets") gadget
    subsystem got it's own bus and messing with ->bus triggers the
    following NULL pointer dereference:
    
    dwc2 12480000.hsotg: bound driver g_ether
    8<--- cut here ---
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    [00000000] *pgd=00000000
    Internal error: Oops: 5 [#1] SMP ARM
    Modules linked in: ...
    CPU: 0 PID: 620 Comm: modprobe Not tainted 5.18.0-rc5-next-20220504 #11862
    Hardware name: Samsung Exynos (Flattened Device Tree)
    PC is at module_add_driver+0x44/0xe8
    LR is at sysfs_do_create_link_sd+0x84/0xe0
    ...
    Process modprobe (pid: 620, stack limit = 0x(ptrval))
    ...
     module_add_driver from bus_add_driver+0xf4/0x1e4
     bus_add_driver from driver_register+0x78/0x10c
     driver_register from usb_gadget_register_driver_owner+0x40/0xb4
     usb_gadget_register_driver_owner from do_one_initcall+0x44/0x1e0
     do_one_initcall from do_init_module+0x44/0x1c8
     do_init_module from load_module+0x19b8/0x1b9c
     load_module from sys_finit_module+0xdc/0xfc
     sys_finit_module from ret_fast_syscall+0x0/0x54
    Exception stack(0xf1771fa8 to 0xf1771ff0)
    ...
    dwc2 12480000.hsotg: new device is high-speed
    ---[ end trace 0000000000000000 ]---
    
    Fix this by removing driver->bus entry reset.
    
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20220505104618.22729-1-m.szyprowski@samsung.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5aee61b029b88c030f9415fde69b3805cda46944
Author: Changbin Du <changbin.du@intel.com>
Date:   Mon Jan 17 23:43:00 2022 +0800

    sysrq: do not omit current cpu when showing backtrace of all active CPUs
    
    [ Upstream commit 5390e7f46b9d5546d45a83e6463bc656678b1d0e ]
    
    The backtrace of current CPU also should be printed as it is active. This
    change add stack trace for current CPU and print a hint for idle CPU for
    the generic workqueue based printing. (x86 already does this)
    
    Now it looks like below:
    [  279.401567] sysrq: Show backtrace of all active CPUs
    [  279.407234] sysrq: CPU5:
    [  279.407505] Call Trace:
    [  279.408789] [<ffffffff8000606c>] dump_backtrace+0x2c/0x3a
    [  279.411698] [<ffffffff800060ac>] show_stack+0x32/0x3e
    [  279.411809] [<ffffffff80542258>] sysrq_handle_showallcpus+0x4c/0xc6
    [  279.411929] [<ffffffff80542f16>] __handle_sysrq+0x106/0x26c
    [  279.412034] [<ffffffff805436a8>] write_sysrq_trigger+0x64/0x74
    [  279.412139] [<ffffffff8029cd48>] proc_reg_write+0x8e/0xe2
    [  279.412252] [<ffffffff8021a8f8>] vfs_write+0x90/0x2be
    [  279.412362] [<ffffffff8021acd2>] ksys_write+0xa6/0xce
    [  279.412467] [<ffffffff8021ad24>] sys_write+0x2a/0x38
    [  279.412689] [<ffffffff80003ff8>] ret_from_syscall+0x0/0x2
    [  279.417173] sysrq: CPU6: backtrace skipped as idling
    [  279.417185] sysrq: CPU4: backtrace skipped as idling
    [  279.417187] sysrq: CPU0: backtrace skipped as idling
    [  279.417181] sysrq: CPU7: backtrace skipped as idling
    [  279.417190] sysrq: CPU1: backtrace skipped as idling
    [  279.417193] sysrq: CPU3: backtrace skipped as idling
    [  279.417219] sysrq: CPU2:
    [  279.419179] Call Trace:
    [  279.419440] [<ffffffff8000606c>] dump_backtrace+0x2c/0x3a
    [  279.419782] [<ffffffff800060ac>] show_stack+0x32/0x3e
    [  279.420015] [<ffffffff80542b30>] showacpu+0x5c/0x96
    [  279.420317] [<ffffffff800ba71c>] flush_smp_call_function_queue+0xd6/0x218
    [  279.420569] [<ffffffff800bb438>] generic_smp_call_function_single_interrupt+0x14/0x1c
    [  279.420798] [<ffffffff800079ae>] handle_IPI+0xaa/0x13a
    [  279.421024] [<ffffffff804dcb92>] riscv_intc_irq+0x56/0x70
    [  279.421274] [<ffffffff80a05b70>] generic_handle_arch_irq+0x6a/0xfa
    [  279.421518] [<ffffffff80004006>] ret_from_exception+0x0/0x10
    [  279.421750] [<ffffffff80096492>] rcu_idle_enter+0x16/0x1e
    
    Signed-off-by: Changbin Du <changbin.du@gmail.com>
    Link: https://lore.kernel.org/r/20220117154300.2808-1-changbin.du@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21f1f167d727f3f857e26d509ef5a6d47fd31bc3
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Wed Apr 6 15:57:03 2022 +0800

    char: xillybus: fix a refcount leak in cleanup_dev()
    
    [ Upstream commit b67d19662fdee275c479d21853bc1239600a798f ]
    
    usb_get_dev is called in xillyusb_probe. So it is better to call
    usb_put_dev before xdev is released.
    
    Acked-by: Eli Billauer <eli.billauer@gmail.com>
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Link: https://lore.kernel.org/r/20220406075703.23464-1-hbh25y@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 07b9c8fe923e26cc803238b9231e33a0ab87fb6c
Author: Evan Green <evgreen@chromium.org>
Date:   Thu Apr 21 10:39:27 2022 -0700

    USB: hcd-pci: Fully suspend across freeze/thaw cycle
    
    [ Upstream commit 63acaa8e9c65dc34dc249440216f8e977f5d2748 ]
    
    The documentation for the freeze() method says that it "should quiesce
    the device so that it doesn't generate IRQs or DMA". The unspoken
    consequence of not doing this is that MSIs aimed at non-boot CPUs may
    get fully lost if they're sent during the period where the target CPU is
    offline.
    
    The current callbacks for USB HCD do not fully quiesce interrupts,
    specifically on XHCI. Change to use the full suspend/resume flow for
    freeze/thaw to ensure interrupts are fully quiesced. This fixes issues
    where USB devices fail to thaw during hibernation because XHCI misses
    its interrupt and cannot recover.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Evan Green <evgreen@chromium.org>
    Link: https://lore.kernel.org/r/20220421103751.v3.2.I8226c7fdae88329ef70957b96a39b346c69a914e@changeid
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4187b291a76664a3c03d3f0d9bfadc8322881868
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sun Apr 17 20:03:05 2022 +0800

    drivers: usb: host: Fix deadlock in oxu_bus_suspend()
    
    [ Upstream commit 4d378f2ae58138d4c55684e1d274e7dd94aa6524 ]
    
    There is a deadlock in oxu_bus_suspend(), which is shown below:
    
       (Thread 1)              |      (Thread 2)
                               | timer_action()
    oxu_bus_suspend()          |  mod_timer()
     spin_lock_irq() //(1)     |  (wait a time)
     ...                       | oxu_watchdog()
     del_timer_sync()          |  spin_lock_irq() //(2)
     (wait timer to stop)      |  ...
    
    We hold oxu->lock in position (1) of thread 1, and use
    del_timer_sync() to wait timer to stop, but timer handler
    also need oxu->lock in position (2) of thread 2. As a result,
    oxu_bus_suspend() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_irq(), which could let timer handler to obtain
    the needed lock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220417120305.64577-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 553213432ef0c295becdc08c0207d2094468f673
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sun Apr 17 19:16:26 2022 +0800

    drivers: tty: serial: Fix deadlock in sa1100_set_termios()
    
    [ Upstream commit 62b2caef400c1738b6d22f636c628d9f85cd4c4c ]
    
    There is a deadlock in sa1100_set_termios(), which is shown
    below:
    
       (Thread 1)              |      (Thread 2)
                               | sa1100_enable_ms()
    sa1100_set_termios()       |  mod_timer()
     spin_lock_irqsave() //(1) |  (wait a time)
     ...                       | sa1100_timeout()
     del_timer_sync()          |  spin_lock_irqsave() //(2)
     (wait timer to stop)      |  ...
    
    We hold sport->port.lock in position (1) of thread 1 and
    use del_timer_sync() to wait timer to stop, but timer handler
    also need sport->port.lock in position (2) of thread 2. As a result,
    sa1100_set_termios() will block forever.
    
    This patch moves del_timer_sync() before spin_lock_irqsave()
    in order to prevent the deadlock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220417111626.7802-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aca0cab0e9ed33b6371aafb519a6c38f2850ffc3
Author: Zhen Ni <nizhen@uniontech.com>
Date:   Wed Mar 2 11:37:16 2022 +0800

    USB: host: isp116x: check return value after calling platform_get_resource()
    
    [ Upstream commit 134a3408c2d3f7e23eb0e4556e0a2d9f36c2614e ]
    
    It will cause null-ptr-deref if platform_get_resource() returns NULL,
    we need check the return value.
    
    Signed-off-by: Zhen Ni <nizhen@uniontech.com>
    Link: https://lore.kernel.org/r/20220302033716.31272-1-nizhen@uniontech.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 46c861009bf437a18417df24cea0d181741b7d72
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sun Apr 17 22:16:41 2022 +0800

    drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()
    
    [ Upstream commit 9b6bdbd9337de3917945847bde262a34a87a6303 ]
    
    There is a deadlock in rtllib_beacons_stop(), which is shown
    below:
    
       (Thread 1)              |      (Thread 2)
                               | rtllib_send_beacon()
    rtllib_beacons_stop()      |  mod_timer()
     spin_lock_irqsave() //(1) |  (wait a time)
     ...                       | rtllib_send_beacon_cb()
     del_timer_sync()          |  spin_lock_irqsave() //(2)
     (wait timer to stop)      |  ...
    
    We hold ieee->beacon_lock in position (1) of thread 1 and
    use del_timer_sync() to wait timer to stop, but timer handler
    also need ieee->beacon_lock in position (2) of thread 2.
    As a result, rtllib_beacons_stop() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_irqsave(), which could let timer handler to obtain
    the needed lock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220417141641.124388-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffc9cab7243f8151be37966301307bfd3cda2db3
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sun Apr 17 21:54:07 2022 +0800

    drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()
    
    [ Upstream commit 806c7b53414934ba2a39449b31fd1a038e500273 ]
    
    There is a deadlock in ieee80211_beacons_stop(), which is shown below:
    
       (Thread 1)              |      (Thread 2)
                               | ieee80211_send_beacon()
    ieee80211_beacons_stop()   |  mod_timer()
     spin_lock_irqsave() //(1) |  (wait a time)
     ...                       | ieee80211_send_beacon_cb()
     del_timer_sync()          |  spin_lock_irqsave() //(2)
     (wait timer to stop)      |  ...
    
    We hold ieee->beacon_lock in position (1) of thread 1 and use
    del_timer_sync() to wait timer to stop, but timer handler
    also need ieee->beacon_lock in position (2) of thread 2.
    As a result, ieee80211_beacons_stop() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_irqsave(), which could let timer handler to obtain
    the needed lock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220417135407.109536-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3de490f254719bd20f0b2a266087e83e7bbaa99
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Fri Apr 1 17:24:28 2022 +0300

    thunderbolt: Use different lane for second DisplayPort tunnel
    
    [ Upstream commit 9d2d0a5cf0ca063f417681cc33e767ce52615286 ]
    
    Brad reported that on Apple hardware with Light Ridge or Falcon Ridge
    controller, plugging in a chain of Thunderbolt displays (Light Ridge
    based controllers) causes all kinds of tearing and flickering. The
    reason for this is that on Thunderbolt 1 hardware there is no lane
    bonding so we have two independent 10 Gb/s lanes, and currently Linux
    tunnels both displays through the lane 1. This makes the displays to
    share the 10 Gb/s bandwidth which may not be enough for higher
    resolutions.
    
    For this reason make the second tunnel go through the lane 0 instead.
    This seems to match what the macOS connection manager is also doing.
    
    Reported-by: Brad Campbell <lists2009@fnarfbargle.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Tested-by: Brad Campbell <lists2009@fnarfbargle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23e155b51d403c0ccedc60c0d6c3c452afed07fe
Author: Huang Guobin <huangguobin4@huawei.com>
Date:   Thu Mar 31 17:10:05 2022 +0800

    tty: Fix a possible resource leak in icom_probe
    
    [ Upstream commit ee157a79e7c82b01ae4c25de0ac75899801f322c ]
    
    When pci_read_config_dword failed, call pci_release_regions() and
    pci_disable_device() to recycle the resource previously allocated.
    
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Huang Guobin <huangguobin4@huawei.com>
    Link: https://lore.kernel.org/r/20220331091005.3290753-1-huangguobin4@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddd67751ab86c6a65f95c35293c42f85a42ac05d
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Sun Apr 10 19:48:14 2022 +0800

    tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()
    
    [ Upstream commit 689ca31c542687709ba21ec2195c1fbce34fd029 ]
    
    When the driver fails at alloc_hdlcdev(), and then we remove the driver
    module, we will get the following splat:
    
    [   25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI
    [   25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]
    [   25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0
    [   25.077709] Call Trace:
    [   25.077924]  <TASK>
    [   25.078108]  unregister_hdlc_device+0x16/0x30
    [   25.078481]  slgt_cleanup+0x157/0x9f0 [synclink_gt]
    
    Fix this by checking whether the 'info->netdev' is a null pointer first.
    
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Link: https://lore.kernel.org/r/20220410114814.3920474-1-zheyuma97@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f6c99b94ca3caad346876b3e22e3ca3d25bc8ee
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sat Apr 9 14:49:53 2022 +0800

    drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()
    
    [ Upstream commit 041879b12ddb0c6c83ed9c0bdd10dc82a056f2fc ]
    
    There is a deadlock in rtw_joinbss_event_prehandle(), which is shown
    below:
    
       (Thread 1)                |      (Thread 2)
                                 | _set_timer()
    rtw_joinbss_event_prehandle()|  mod_timer()
     spin_lock_bh() //(1)        |  (wait a time)
     ...                         | _rtw_join_timeout_handler()
     del_timer_sync()            |  spin_lock_bh() //(2)
     (wait timer to stop)        |  ...
    
    We hold pmlmepriv->lock in position (1) of thread 1 and
    use del_timer_sync() to wait timer to stop, but timer handler
    also need pmlmepriv->lock in position (2) of thread 2.
    As a result, rtw_joinbss_event_prehandle() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_bh(), which could let timer handler to obtain
    the needed lock. What`s more, we change spin_lock_bh() to
    spin_lock_irq() in _rtw_join_timeout_handler() in order to
    prevent deadlock.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220409064953.67420-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ce129d3efd181da5fd56f4360cc8827122afa67e
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sat Apr 9 14:18:35 2022 +0800

    drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()
    
    [ Upstream commit cc7ad0d77b51c872d629bcd98aea463a3c4109e7 ]
    
    There is a deadlock in rtw_surveydone_event_callback(),
    which is shown below:
    
       (Thread 1)                  |      (Thread 2)
                                   | _set_timer()
    rtw_surveydone_event_callback()|  mod_timer()
     spin_lock_bh() //(1)          |  (wait a time)
     ...                           | rtw_scan_timeout_handler()
     del_timer_sync()              |  spin_lock_bh() //(2)
     (wait timer to stop)          |  ...
    
    We hold pmlmepriv->lock in position (1) of thread 1 and use
    del_timer_sync() to wait timer to stop, but timer handler
    also need pmlmepriv->lock in position (2) of thread 2.
    As a result, rtw_surveydone_event_callback() will block forever.
    
    This patch extracts del_timer_sync() from the protection of
    spin_lock_bh(), which could let timer handler to obtain
    the needed lock. What`s more, we change spin_lock_bh() in
    rtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,
    spin_lock_bh() will also cause deadlock() in timer handler.
    
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220409061836.60529-1-duoming@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c4c73319b5c85a5fe34aeffb86b8224b1615494
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Feb 16 12:15:03 2022 -0800

    lkdtm/usercopy: Expand size of "out of frame" object
    
    [ Upstream commit f387e86d3a74407bdd9c5815820ac9d060962840 ]
    
    To be sufficiently out of range for the usercopy test to see the lifetime
    mismatch, expand the size of the "bad" buffer, which will let it be
    beyond current_stack_pointer regardless of stack growth direction.
    Paired with the recent addition of stack depth checking under
    CONFIG_HARDENED_USERCOPY=y, this will correctly start tripping again.
    
    Reported-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Link: https://lore.kernel.org/lkml/762faf1b-0443-5ddf-4430-44a20cf2ec4d@collabora.com/
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 29f09f35297df73f503ddad7c813cdd39452f2f0
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Mon Feb 7 15:38:33 2022 +0100

    iio: st_sensors: Add a local lock for protecting odr
    
    [ Upstream commit 474010127e2505fc463236470908e1ff5ddb3578 ]
    
    Right now the (framework) mlock lock is (ab)used for multiple purposes:
    1- protecting concurrent accesses over the odr local cache
    2- avoid changing samplig frequency whilst buffer is running
    
    Let's start by handling situation #1 with a local lock.
    
    Suggested-by: Jonathan Cameron <jic23@kernel.org>
    Cc: Denis Ciocca <denis.ciocca@st.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20220207143840.707510-7-miquel.raynal@bootlin.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 205e039fead72e87ad2838f5e649a4c4834f648b
Author: Xiaoke Wang <xkernel.wang@foxmail.com>
Date:   Tue Apr 5 12:43:07 2022 +0800

    staging: rtl8712: fix a potential memory leak in r871xu_drv_init()
    
    [ Upstream commit 7288ff561de650d4139fab80e9cb0da9b5b32434 ]
    
    In r871xu_drv_init(), if r8712_init_drv_sw() fails, then the memory
    allocated by r8712_alloc_io_queue() in r8712_usb_dvobj_init() is not
    properly released as there is no action will be performed by
    r8712_usb_dvobj_deinit().
    To properly release it, we should call r8712_free_io_queue() in
    r8712_usb_dvobj_deinit().
    
    Besides, in r871xu_dev_remove(), r8712_usb_dvobj_deinit() will be called
    by r871x_dev_unload() under condition `padapter->bup` and
    r8712_free_io_queue() is called by r8712_free_drv_sw().
    However, r8712_usb_dvobj_deinit() does not rely on `padapter->bup` and
    calling r8712_free_io_queue() in r8712_free_drv_sw() is negative for
    better understading the code.
    So I move r8712_usb_dvobj_deinit() into r871xu_dev_remove(), and remove
    r8712_free_io_queue() from r8712_free_drv_sw().
    
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.com>
    Link: https://lore.kernel.org/r/tencent_B8048C592777830380A23A7C4409F9DF1305@qq.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87eea4319b2cc92ad9a6ff16c6f668a7e1f9b451
Author: Xiaoke Wang <xkernel.wang@foxmail.com>
Date:   Sat Mar 5 11:14:05 2022 +0800

    iio: dummy: iio_simple_dummy: check the return value of kstrdup()
    
    [ Upstream commit ba93642188a6fed754bf7447f638bc410e05a929 ]
    
    kstrdup() is also a memory allocation-related function, it returns NULL
    when some memory errors happen. So it is better to check the return
    value of it so to catch the memory error in time. Besides, there should
    have a kfree() to clear up the allocation if we get a failure later in
    this function to prevent memory leak.
    
    Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.com>
    Link: https://lore.kernel.org/r/tencent_C920CFCC33B9CC1C63141FE1334A39FF8508@qq.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66f3a245bb5c93d710b2ce2e09b18ab176e99e8e
Author: David Howells <dhowells@redhat.com>
Date:   Thu Jun 9 09:07:01 2022 +0100

    iov_iter: Fix iter_xarray_get_pages{,_alloc}()
    
    [ Upstream commit 6c77676645ad42993e0a8bdb8dafa517851a352a ]
    
    The maths at the end of iter_xarray_get_pages() to calculate the actual
    size doesn't work under some circumstances, such as when it's been asked to
    extract a partial single page.  Various terms of the equation cancel out
    and you end up with actual == offset.  The same issue exists in
    iter_xarray_get_pages_alloc().
    
    Fix these to just use min() to select the lesser amount from between the
    amount of page content transcribed into the buffer, minus the offset, and
    the size limit specified.
    
    This doesn't appear to have caused a problem yet upstream because network
    filesystems aren't getting the pages from an xarray iterator, but rather
    passing it directly to the socket, which just iterates over it.  Cachefiles
    *does* do DIO from one to/from ext4/xfs/btrfs/etc. but it always asks for
    whole pages to be written or read.
    
    Fixes: 7ff5062079ef ("iov_iter: Add ITER_XARRAY")
    Reported-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Alexander Viro <viro@zeniv.linux.org.uk>
    cc: Dominique Martinet <asmadeus@codewreck.org>
    cc: Mike Marshall <hubcap@omnibond.com>
    cc: Gao Xiang <xiang@kernel.org>
    cc: linux-afs@lists.infradead.org
    cc: v9fs-developer@lists.sourceforge.net
    cc: devel@lists.orangefs.org
    cc: linux-erofs@lists.ozlabs.org
    cc: linux-cachefs@redhat.com
    cc: linux-fsdevel@vger.kernel.org
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 685fc7b8280102fa68dff10992b70cc2c2f9d8d8
Author: Etienne van der Linde <etienne.vanderlinde@corigine.com>
Date:   Wed Jun 8 11:29:01 2022 +0200

    nfp: flower: restructure flow-key for gre+vlan combination
    
    [ Upstream commit a0b843340dae704e17c1ddfad0f85c583c36757f ]
    
    Swap around the GRE and VLAN parts in the flow-key offloaded by
    the driver to fit in with other tunnel types and the firmware.
    Without this change used cases with GRE+VLAN on the outer header
    does not get offloaded as the flow-key mismatches what the
    firmware expect.
    
    Fixes: 0d630f58989a ("nfp: flower: add support to offload QinQ match")
    Fixes: 5a2b93041646 ("nfp: flower-ct: compile match sections of flow_payload")
    Signed-off-by: Etienne van der Linde <etienne.vanderlinde@corigine.com>
    Signed-off-by: Louis Peens <louis.peens@corigine.com>
    Signed-off-by: Yinjun Zhang <yinjun.zhang@corigine.com>
    Signed-off-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f2a9ecd71f59bd7a106cea4689db4352edae417e
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Jun 8 16:59:29 2022 -0700

    drm: imx: fix compiler warning with gcc-12
    
    [ Upstream commit 7aefd8b53815274f3ef398d370a3c9b27dd9f00c ]
    
    Gcc-12 correctly warned about this code using a non-NULL pointer as a
    truth value:
    
      drivers/gpu/drm/imx/ipuv3-crtc.c: In function ‘ipu_crtc_disable_planes’:
      drivers/gpu/drm/imx/ipuv3-crtc.c:72:21: error: the comparison will always evaluate as ‘true’ for the address of ‘plane’ will never be NULL [-Werror=address]
         72 |                 if (&ipu_crtc->plane[1] && plane == &ipu_crtc->plane[1]->base)
            |                     ^
    
    due to the extraneous '&' address-of operator.
    
    Philipp Zabel points out that The mistake had no adverse effect since
    the following condition doesn't actually dereference the NULL pointer,
    but the intent of the code was obviously to check for it, not to take
    the address of the member.
    
    Fixes: eb8c88808c83 ("drm/imx: add deferred plane disabling")
    Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef142d6f39da851e1297292e2c9b226d5384beea
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Tue Jun 7 15:02:14 2022 +0800

    tcp: use alloc_large_system_hash() to allocate table_perturb
    
    [ Upstream commit e67b72b90b7e19a4be4d9c29f3feea6f58ab43f8 ]
    
    In our server, there may be no high order (>= 6) memory since we reserve
    lots of HugeTLB pages when booting.  Then the system panic.  So use
    alloc_large_system_hash() to allocate table_perturb.
    
    Fixes: e9261476184b ("tcp: dynamically allocate the perturb table used by source ports")
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20220607070214.94443-1-songmuchun@bytedance.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a94cf9f9b5f64ee172e8ff3fcb18957961d20880
Author: Marek Behún <kabel@kernel.org>
Date:   Tue Jun 7 12:28:42 2022 +0100

    net: dsa: mv88e6xxx: use BMSR_ANEGCOMPLETE bit for filling an_complete
    
    [ Upstream commit 47e96930d6e6106d5252e85b868d3c7e29296de0 ]
    
    Commit ede359d8843a ("net: dsa: mv88e6xxx: Link in pcs_get_state() if AN
    is bypassed") added the ability to link if AN was bypassed, and added
    filling of state->an_complete field, but set it to true if AN was
    enabled in BMCR, not when AN was reported complete in BMSR.
    
    This was done because for some reason, when I wanted to use BMSR value
    to infer an_complete, I was looking at BMSR_ANEGCAPABLE bit (which was
    always 1), instead of BMSR_ANEGCOMPLETE bit.
    
    Use BMSR_ANEGCOMPLETE for filling state->an_complete.
    
    Fixes: ede359d8843a ("net: dsa: mv88e6xxx: Link in pcs_get_state() if AN is bypassed")
    Signed-off-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 803b217f1fb49a2dbb2123acdb45111b9c48b8be
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Jun 7 08:11:43 2022 +0400

    net: altera: Fix refcount leak in altera_tse_mdio_create
    
    [ Upstream commit 11ec18b1d8d92b9df307d31950dcba0b3dd7283c ]
    
    Every iteration of for_each_child_of_node() decrements
    the reference count of the previous node.
    When break from a for_each_child_of_node() loop,
    we need to explicitly call of_node_put() on the child node when
    not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: bbd2190ce96d ("Altera TSE: Add main and header file for Altera Ethernet Driver")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220607041144.7553-1-linmq006@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c92d813c7c9ca2212ecd879232e7d87362fce98
Author: Willem de Bruijn <willemb@google.com>
Date:   Mon Jun 6 09:21:07 2022 -0400

    ip_gre: test csum_start instead of transport header
    
    [ Upstream commit 8d21e9963bec1aad2280cdd034c8993033ef2948 ]
    
    GRE with TUNNEL_CSUM will apply local checksum offload on
    CHECKSUM_PARTIAL packets.
    
    ipgre_xmit must validate csum_start after an optional skb_pull,
    else lco_csum may trigger an overflow. The original check was
    
            if (csum && skb_checksum_start(skb) < skb->data)
                    return -EINVAL;
    
    This had false positives when skb_checksum_start is undefined:
    when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement
    was straightforward
    
            if (csum && skb->ip_summed == CHECKSUM_PARTIAL &&
                skb_checksum_start(skb) < skb->data)
                    return -EINVAL;
    
    But was eventually revised more thoroughly:
    - restrict the check to the only branch where needed, in an
      uncommon GRE path that uses header_ops and calls skb_pull.
    - test skb_transport_header, which is set along with csum_start
      in skb_partial_csum_set in the normal header_ops datapath.
    
    Turns out skbs can arrive in this branch without the transport
    header set, e.g., through BPF redirection.
    
    Revise the check back to check csum_start directly, and only if
    CHECKSUM_PARTIAL. Do leave the check in the updated location.
    Check field regardless of whether TUNNEL_CSUM is configured.
    
    Link: https://lore.kernel.org/netdev/YS+h%2FtqCJJiQei+W@shredder/
    Link: https://lore.kernel.org/all/20210902193447.94039-2-willemdebruijn.kernel@gmail.com/T/#u
    Fixes: 8a0ed250f911 ("ip_gre: validate csum_start only on pull")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Link: https://lore.kernel.org/r/20220606132107.3582565-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 69ced342223b969931e857f92c511692b8e32e73
Author: Mark Bloch <mbloch@nvidia.com>
Date:   Mon May 30 10:46:59 2022 +0300

    net/mlx5: fs, fail conflicting actions
    
    [ Upstream commit 8fa5e7b20e01042b14f8cd684d2da9b638460c74 ]
    
    When combining two steering rules into one check
    not only do they share the same actions but those
    actions are also the same. This resolves an issue where
    when creating two different rules with the same match
    the actions are overwritten and one of the rules is deleted
    a FW syndrome can be seen in dmesg.
    
    mlx5_core 0000:03:00.0: mlx5_cmd_check:819:(pid 2105): DEALLOC_MODIFY_HEADER_CONTEXT(0x941) op_mod(0x0) failed, status bad resource state(0x9), syndrome (0x1ab444)
    
    Fixes: 0d235c3fabb7 ("net/mlx5: Add hash table to search FTEs in a flow-group")
    Signed-off-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2d0cfb96fa6586c9f84a22be2acd1060bedafff
Author: Feras Daoud <ferasda@nvidia.com>
Date:   Sat Mar 19 21:47:48 2022 +0200

    net/mlx5: Rearm the FW tracer after each tracer event
    
    [ Upstream commit 8bf94e6414c9481bfa28269022688ab445d0081d ]
    
    The current design does not arm the tracer if traces are available before
    the tracer string database is fully loaded, leading to an unfunctional tracer.
    This fix will rearm the tracer every time the FW triggers tracer event
    regardless of the tracer strings database status.
    
    Fixes: c71ad41ccb0c ("net/mlx5: FW tracer, events handling")
    Signed-off-by: Feras Daoud <ferasda@nvidia.com>
    Signed-off-by: Roy Novich <royno@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7abbd2bc89ca830d98de2c138cd74e66f6b2c9b4
Author: Saeed Mahameed <saeedm@nvidia.com>
Date:   Fri Feb 19 23:10:47 2021 -0800

    net/mlx5: Fix mlx5_get_next_dev() peer device matching
    
    [ Upstream commit 1c5de097bea31760c3f0467ac0c84ba0dc3525d5 ]
    
    In some use-cases, mlx5 instances will need to search for their peer
    device (the other port on the same HCA). For that, mlx5 device matching
    mechanism relied on auxiliary_find_device() to search, and used a bad matching
    callback function.
    
    This approach has two issues:
    
    1) next_phys_dev() the matching function, assumed all devices are
       of the type mlx5_adev (mlx5 auxiliary device) which is wrong and
       could lead to crashes, this worked for a while, since only lately
       other drivers started registering auxiliary devices.
    
    2) using the auxiliary class bus (auxiliary_find_device) to search for
       mlx5_core_dev devices, who are actually PCIe device instances, is wrong.
       This works since mlx5_core always has at least one mlx5_adev instance
       hanging around in the aux bus.
    
    As suggested by others we can fix 1. by comparing device names prefixes
    if they have the string "mlx5_core" in them, which is not a best practice !
    but even with that fixed, still 2. needs fixing, we are trying to
    match pcie device peers so we should look in the right bus (pci bus),
    hence this fix.
    
    The fix:
    1) search the pci bus for mlx5 peer devices, instead of the aux bus
    2) to validated devices are the same type "mlx5_core_dev" compare if
       they have the same driver, which is bulletproof.
    
       This wouldn't have worked with the aux bus since the various mlx5 aux
       device types don't share the same driver, even if they share the same device
       wrapper struct (mlx5_adev) "which helped to find the parent device"
    
    Fixes: a925b5e309c9 ("net/mlx5: Register mlx5 devices to auxiliary virtual bus")
    Reported-by: Alexander Lobakin <alexandr.lobakin@intel.com>
    Reported-by: Maher Sanalla <msanalla@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Reviewed-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66753a0d42ac58a0432a90b5e7aa7234ff5ce00c
Author: Mark Bloch <mbloch@nvidia.com>
Date:   Sun Feb 27 12:40:39 2022 +0000

    net/mlx5: Lag, filter non compatible devices
    
    [ Upstream commit bc4c2f2e017949646b43fdcad005a03462d437c6 ]
    
    When search for a peer lag device we can filter based on that
    device's capabilities.
    
    Downstream patch will be less strict when filtering compatible devices
    and remove the limitation where we require exact MLX5_MAX_PORTS and
    change it to a range.
    
    Signed-off-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e6de5037148c5a93a436b1e8d2edad3dac11755
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jun 6 13:53:55 2022 +0900

    net: ipv6: unexport __init-annotated seg6_hmac_init()
    
    [ Upstream commit 5801f064e35181c71857a80ff18af4dbec3c5f5c ]
    
    EXPORT_SYMBOL and __init is a bad combination because the .init.text
    section is freed up after the initialization. Hence, modules cannot
    use symbols annotated __init. The access to a freed symbol may end up
    with kernel panic.
    
    modpost used to detect it, but it has been broken for a decade.
    
    Recently, I fixed modpost so it started to warn it again, then this
    showed up in linux-next builds.
    
    There are two ways to fix it:
    
      - Remove __init
      - Remove EXPORT_SYMBOL
    
    I chose the latter for this case because the caller (net/ipv6/seg6.c)
    and the callee (net/ipv6/seg6_hmac.c) belong to the same module.
    It seems an internal function call in ipv6.ko.
    
    Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e04d59cfe0c0129df7aba7ef7bb17b96be2a64f2
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jun 6 13:53:54 2022 +0900

    net: xfrm: unexport __init-annotated xfrm4_protocol_init()
    
    [ Upstream commit 4a388f08d8784af48f352193d2b72aaf167a57a1 ]
    
    EXPORT_SYMBOL and __init is a bad combination because the .init.text
    section is freed up after the initialization. Hence, modules cannot
    use symbols annotated __init. The access to a freed symbol may end up
    with kernel panic.
    
    modpost used to detect it, but it has been broken for a decade.
    
    Recently, I fixed modpost so it started to warn it again, then this
    showed up in linux-next builds.
    
    There are two ways to fix it:
    
      - Remove __init
      - Remove EXPORT_SYMBOL
    
    I chose the latter for this case because the only in-tree call-site,
    net/ipv4/xfrm4_policy.c is never compiled as modular.
    (CONFIG_XFRM is boolean)
    
    Fixes: 2f32b51b609f ("xfrm: Introduce xfrm_input_afinfo to access the the callbacks properly")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5c68137f1191ba3fcf6260ec71b30be2e2bf4c3
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jun 6 13:53:53 2022 +0900

    net: mdio: unexport __init-annotated mdio_bus_init()
    
    [ Upstream commit 35b42dce619701f1300fb8498dae82c9bb1f0263 ]
    
    EXPORT_SYMBOL and __init is a bad combination because the .init.text
    section is freed up after the initialization. Hence, modules cannot
    use symbols annotated __init. The access to a freed symbol may end up
    with kernel panic.
    
    modpost used to detect it, but it has been broken for a decade.
    
    Recently, I fixed modpost so it started to warn it again, then this
    showed up in linux-next builds.
    
    There are two ways to fix it:
    
      - Remove __init
      - Remove EXPORT_SYMBOL
    
    I chose the latter for this case because the only in-tree call-site,
    drivers/net/phy/phy_device.c is never compiled as modular.
    (CONFIG_PHYLIB is boolean)
    
    Fixes: 90eff9096c01 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58e1a7f907feec6c6cc06cc9f6c0a1c9f2b9d22d
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jun 7 16:47:52 2022 -0400

    SUNRPC: Fix the calculation of xdr->end in xdr_get_next_encode_buffer()
    
    [ Upstream commit 6c254bf3b637dd4ef4f78eb78c7447419c0161d7 ]
    
    I found that NFSD's new NFSv3 READDIRPLUS XDR encoder was screwing up
    right at the end of the page array. xdr_get_next_encode_buffer() does
    not compute the value of xdr->end correctly:
    
     * The check to see if we're on the final available page in xdr->buf
       needs to account for the space consumed by @nbytes.
    
     * The new xdr->end value needs to account for the portion of @nbytes
       that is to be encoded into the previous buffer.
    
    Fixes: 2825a7f90753 ("nfsd4: allow encoding across page boundaries")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Reviewed-by: NeilBrown <neilb@suse.de>
    Reviewed-by: J. Bruce Fields <bfields@fieldses.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a3a5581a19f2acb6f14626dc01583aa4b31cb9a
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date:   Tue Jun 7 16:22:00 2022 +0200

    xsk: Fix handling of invalid descriptors in XSK TX batching API
    
    [ Upstream commit d678cbd2f867a564a3c5b276c454e873f43f02f8 ]
    
    xdpxceiver run on a AF_XDP ZC enabled driver revealed a problem with XSK
    Tx batching API. There is a test that checks how invalid Tx descriptors
    are handled by AF_XDP. Each valid descriptor is followed by invalid one
    on Tx side whereas the Rx side expects only to receive a set of valid
    descriptors.
    
    In current xsk_tx_peek_release_desc_batch() function, the amount of
    available descriptors is hidden inside xskq_cons_peek_desc_batch(). This
    can be problematic in cases where invalid descriptors are present due to
    the fact that xskq_cons_peek_desc_batch() returns only a count of valid
    descriptors. This means that it is impossible to properly update XSK
    ring state when calling xskq_cons_release_n().
    
    To address this issue, pull out the contents of
    xskq_cons_peek_desc_batch() so that callers (currently only
    xsk_tx_peek_release_desc_batch()) will always be able to update the
    state of ring properly, as total count of entries is now available and
    use this value as an argument in xskq_cons_release_n(). By
    doing so, xskq_cons_peek_desc_batch() can be dropped altogether.
    
    Fixes: 9349eb3a9d2a ("xsk: Introduce batched Tx descriptor interfaces")
    Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
    Link: https://lore.kernel.org/bpf/20220607142200.576735-1-maciej.fijalkowski@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 297a53f67d26e39e593ae4fb6d6906b729c5aec2
Author: Magnus Karlsson <magnus.karlsson@intel.com>
Date:   Tue Jan 25 17:04:43 2022 +0100

    i40e: xsk: Move tmp desc array from driver to pool
    
    [ Upstream commit d1bc532e99becf104635ed4da6fefa306f452321 ]
    
    Move desc_array from the driver to the pool. The reason behind this is
    that we can then reuse this array as a temporary storage for descriptors
    in all zero-copy drivers that use the batched interface. This will make
    it easier to add batching to more drivers.
    
    i40e is the only driver that has a batched Tx zero-copy
    implementation, so no need to touch any other driver.
    
    Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
    Link: https://lore.kernel.org/bpf/20220125160446.78976-6-maciej.fijalkowski@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b10c28c63b0ed0a56bd12decd326654b0b751c9b
Author: Gal Pressman <gal@nvidia.com>
Date:   Mon Jun 6 14:57:18 2022 +0300

    net/mlx4_en: Fix wrong return value on ioctl EEPROM query failure
    
    [ Upstream commit f5826c8c9d57210a17031af5527056eefdc2b7eb ]
    
    The ioctl EEPROM query wrongly returns success on read failures, fix
    that by returning the appropriate error code.
    
    Fixes: 7202da8b7f71 ("ethtool, net/mlx4_en: Cable info, get_module_info/eeprom ethtool support")
    Signed-off-by: Gal Pressman <gal@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20220606115718.14233-1-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32cd78c5610f02a929f63cac985e73692d05f33e
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 11:23:34 2022 +0400

    net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list
    
    [ Upstream commit 0737e018a05e2aa352828c52bdeed3b02cff2930 ]
    
    Every iteration of for_each_available_child_of_node() decrements
    the reference count of the previous node.
    when breaking early from a for_each_available_child_of_node() loop,
    we need to explicitly call of_node_put() on the gphy_fw_np.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220605072335.11257-1-linmq006@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5c25a3040bc0486c41a7b63a1fb0de7cdb846ad7
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue May 31 14:51:13 2022 -0700

    bpf, arm64: Clear prog->jited_len along prog->jited
    
    [ Upstream commit 10f3b29c65bb2fe0d47c2945cd0b4087be1c5218 ]
    
    syzbot reported an illegal copy_to_user() attempt
    from bpf_prog_get_info_by_fd() [1]
    
    There was no repro yet on this bug, but I think
    that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns")
    is exposing a prior bug in bpf arm64.
    
    bpf_prog_get_info_by_fd() looks at prog->jited_len
    to determine if the JIT image can be copied out to user space.
    
    My theory is that syzbot managed to get a prog where prog->jited_len
    has been set to 43, while prog->bpf_func has ben cleared.
    
    It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering
    this particular warning.
    
    I thought find_vma_area(NULL) would not find a vm_struct.
    As we do not hold vmap_area_lock spinlock, it might be possible
    that the found vm_struct was garbage.
    
    [1]
    usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)!
    kernel BUG at mm/usercopy.c:101!
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0
    Hardware name: linux,dummy-virt (DT)
    pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101
    lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89
    sp : ffff80000b773a20
    x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48
    x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000
    x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001
    x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd
    x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420
    x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031
    x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865
    x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830
    x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000
    x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064
    Call trace:
     usercopy_abort+0x90/0x94 mm/usercopy.c:89
     check_heap_object mm/usercopy.c:186 [inline]
     __check_object_size mm/usercopy.c:252 [inline]
     __check_object_size+0x198/0x36c mm/usercopy.c:214
     check_object_size include/linux/thread_info.h:199 [inline]
     check_copy_size include/linux/thread_info.h:235 [inline]
     copy_to_user include/linux/uaccess.h:159 [inline]
     bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993
     bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253
     __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956
     __do_sys_bpf kernel/bpf/syscall.c:5021 [inline]
     __se_sys_bpf kernel/bpf/syscall.c:5019 [inline]
     __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019
     __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
     invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52
     el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142
     do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206
     el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624
     el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642
     el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581
    Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)
    
    Fixes: db496944fdaa ("bpf: arm64: add JIT support for multi-function programs")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Song Liu <songliubraving@fb.com>
    Link: https://lore.kernel.org/bpf/20220531215113.1100754-1-eric.dumazet@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9cfd29428941dab4daf44ecac02ad13c6edc8375
Author: Jan Beulich <jbeulich@suse.com>
Date:   Tue Jun 7 17:00:53 2022 +0200

    x86: drop bogus "cc" clobber from __try_cmpxchg_user_asm()
    
    [ Upstream commit 1df931d95f4dc1c11db1123e85d4e08156e46ef9 ]
    
    As noted (and fixed) a couple of times in the past, "=@cc<cond>" outputs
    and clobbering of "cc" don't work well together. The compiler appears to
    mean to reject such, but doesn't - in its upstream form - quite manage
    to yet for "cc". Furthermore two similar macros don't clobber "cc", and
    clobbering "cc" is pointless in asm()-s for x86 anyway - the compiler
    always assumes status flags to be clobbered there.
    
    Fixes: 989b5db215a2 ("x86/uaccess: Implement macros for CMPXCHG on user addresses")
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Message-Id: <485c0c0b-a3a7-0b7c-5264-7d00c01de032@suse.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 71e8bfc7f838cabc60cba24e09ca84c4f8321ab2
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Sun Jun 5 16:23:25 2022 -0700

    af_unix: Fix a data-race in unix_dgram_peer_wake_me().
    
    [ Upstream commit 662a80946ce13633ae90a55379f1346c10f0c432 ]
    
    unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s
    lock held and check if its receive queue is full.  Here we need to
    use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise
    KCSAN will report a data-race.
    
    Fixes: 7d267278a9ec ("unix: avoid use-after-free in ep_remove_wait_queue")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20220605232325.11804-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 72fe647a344819a54fa46699dbe8f6267cc1f4f3
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jun 5 22:50:48 2022 +0200

    stmmac: intel: Fix an error handling path in intel_eth_pci_probe()
    
    [ Upstream commit 5e74a4b3ec1816e3bbfd715d46ae29d2508079cb ]
    
    When the managed API is used, there is no need to explicitly call
    pci_free_irq_vectors().
    
    This looks to be a left-over from the commit in the Fixes tag. Only the
    .remove() function had been updated.
    
    So remove this unused function call and update goto label accordingly.
    
    Fixes: 8accc467758e ("stmmac: intel: use managed PCI function on probe and resume")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Wong Vee Khee <vee.khee.wong@linux.intel.com>
    Link: https://lore.kernel.org/r/1ac9b6787b0db83b0095711882c55c77c8ea8da0.1654462241.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b43387364d8291190fd4ea1322b65c337802baa2
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jun 6 13:59:20 2022 +0900

    xen: unexport __init-annotated xen_xlate_map_ballooned_pages()
    
    [ Upstream commit dbac14a5a05ff8e1ce7c0da0e1f520ce39ec62ea ]
    
    EXPORT_SYMBOL and __init is a bad combination because the .init.text
    section is freed up after the initialization. Hence, modules cannot
    use symbols annotated __init. The access to a freed symbol may end up
    with kernel panic.
    
    modpost used to detect it, but it has been broken for a decade.
    
    Recently, I fixed modpost so it started to warn it again, then this
    showed up in linux-next builds.
    
    There are two ways to fix it:
    
      - Remove __init
      - Remove EXPORT_SYMBOL
    
    I chose the latter for this case because none of the in-tree call-sites
    (arch/arm/xen/enlighten.c, arch/x86/xen/grant-table.c) is compiled as
    modular.
    
    Fixes: 243848fc018c ("xen/grant-table: Move xlated_setup_gnttab_pages to common place")
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
    Acked-by: Stefano Stabellini <sstabellini@kernel.org>
    Link: https://lore.kernel.org/r/20220606045920.4161881-1-masahiroy@kernel.org
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b51996e35bbfcc7a27d94dfeed5cc2429b2c0df4
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Jun 3 17:32:38 2022 +0400

    net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register
    
    [ Upstream commit b8d91399775c55162073bb2aca061ec42e3d4bc1 ]
    
    of_get_child_by_name() 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: 55954f3bfdac ("net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20220603133238.44114-1-linmq006@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5822be04734d5d66d27ae698d83ed3bcc4b4c82
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Thu Jun 2 14:01:08 2022 +0000

    amt: fix wrong type string definition
    
    [ Upstream commit d7970039d87c926bb648982e920cb9851c19f3e1 ]
    
    amt message type definition starts from 1, not 0.
    But type_str[] starts from 0.
    So, it prints wrong type information.
    
    Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 42c6af92666a6f4a600a0f03fabce98a361dc824
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Thu Jun 2 14:01:07 2022 +0000

    amt: fix possible null-ptr-deref in amt_rcv()
    
    [ Upstream commit d16207f92a4a823c48b4ea953ad51f4483456768 ]
    
    When amt interface receives amt message, it tries to obtain amt private
    data from sock.
    If there is no amt private data, it frees an skb immediately.
    After kfree_skb(), it increases the rx_dropped stats.
    But in order to use rx_dropped, amt private data is needed.
    So, it makes amt_rcv() to do not increase rx_dropped stats when it can
    not obtain amt private data.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Fixes: 1a1a0e80e005 ("amt: fix possible memory leak in amt_rcv()")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e1e025f16f5568afba5b9e65605549f17b978f9
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Thu Jun 2 14:01:06 2022 +0000

    amt: fix wrong usage of pskb_may_pull()
    
    [ Upstream commit f55a07074fdd38cab8c097ac5bd397d68eff733c ]
    
    It adds missing pskb_may_pull() in amt_update_handler() and
    amt_multicast_data_handler().
    And it fixes wrong parameter of pskb_may_pull() in
    amt_advertisement_handler() and amt_membership_query_handler().
    
    Reported-by: Jakub Kicinski <kuba@kernel.org>
    Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d625f31815018af343f1c657225d6df67094f92f
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Jun 6 17:31:29 2022 +0200

    netfilter: nf_tables: bail out early if hardware offload is not supported
    
    [ Upstream commit 3a41c64d9c1185a2f3a184015e2a9b78bfc99c71 ]
    
    If user requests for NFT_CHAIN_HW_OFFLOAD, then check if either device
    provides the .ndo_setup_tc interface or there is an indirect flow block
    that has been registered. Otherwise, bail out early from the preparation
    phase. Moreover, validate that family == NFPROTO_NETDEV and hook is
    NF_NETDEV_INGRESS.
    
    Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80de9ea1f5b808a6601e91111fae601df2b26369
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Jun 6 17:15:57 2022 +0200

    netfilter: nf_tables: memleak flow rule from commit path
    
    [ Upstream commit 9dd732e0bdf538b1b76dc7c157e2b5e560ff30d3 ]
    
    Abort path release flow rule object, however, commit path does not.
    Update code to destroy these objects before releasing the transaction.
    
    Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45ccd2689a6d3af1a05fc2bbfe3d0f6d5d1f8ef9
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sun Jun 5 13:40:06 2022 +0200

    netfilter: nf_tables: release new hooks on unsupported flowtable flags
    
    [ Upstream commit c271cc9febaaa1bcbc0842d1ee30466aa6148ea8 ]
    
    Release the list of new hooks that are pending to be registered in case
    that unsupported flowtable flags are provided.
    
    Fixes: 78d9f48f7f44 ("netfilter: nf_tables: add devices to existing flowtable")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9782e1b21bee4b783a64b2a91e7e71406c21a21
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 12:59:26 2022 +0400

    ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe
    
    [ Upstream commit 10d6bdf532902be1d8aa5900b3c03c5671612aa2 ]
    
    of_find_device_by_node() takes reference, we should use put_device()
    to release it when not need anymore.
    Add missing put_device() to avoid refcount leak.
    
    Fixes: 43f01da0f279 ("MIPS/OCTEON/ata: Convert pata_octeon_cf.c to use device tree.")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d9749a757a24c333d94a9b31f797bd42f9cbcf87
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Jun 1 17:49:36 2022 +0200

    netfilter: nf_tables: always initialize flowtable hook list in transaction
    
    [ Upstream commit 2c9e4559773c261900c674a86b8e455911675d71 ]
    
    The hook list is used if nft_trans_flowtable_update(trans) == true. However,
    initialize this list for other cases for safety reasons.
    
    Fixes: 78d9f48f7f44 ("netfilter: nf_tables: add devices to existing flowtable")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 812c13521d4a72469c78ce06d8cdc8dc5b5557b5
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Jun 1 12:46:52 2022 -0400

    SUNRPC: Trap RDMA segment overflows
    
    [ Upstream commit f012e95b377c73c0283f009823c633104dedb337 ]
    
    Prevent svc_rdma_build_writes() from walking off the end of a Write
    chunk's segment array. Caught with KASAN.
    
    The test that this fix replaces is invalid, and might have been left
    over from an earlier prototype of the PCL work.
    
    Fixes: 7a1cbfa18059 ("svcrdma: Use parsed chunk lists to construct RDMA Writes")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fee1194e42625b0461fc0548f630671a2ac3f98
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Jun 2 00:31:14 2022 +1000

    powerpc/kasan: Force thread size increase with KASAN
    
    [ Upstream commit 3e8635fb2e072672cbc650989ffedf8300ad67fb ]
    
    KASAN causes increased stack usage, which can lead to stack overflows.
    
    The logic in Kconfig to suggest a larger default doesn't work if a user
    has CONFIG_EXPERT enabled and has an existing .config with a smaller
    value.
    
    Follow the lead of x86 and arm64, and force the thread size to be
    increased when KASAN is enabled.
    
    That also has the effect of enlarging the stack for 64-bit KASAN builds,
    which is also desirable.
    
    Fixes: edbadaf06710 ("powerpc/kasan: Fix stack overflow by increasing THREAD_SHIFT")
    Reported-by: Erhard Furtner <erhard_f@mailbox.org>
    Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    [mpe: Use MIN_THREAD_SHIFT as suggested by Christophe]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220601143114.133524-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62d91062058b42bf70b2c3446aec397bb0ce15ee
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon May 30 18:40:06 2022 +0200

    netfilter: nf_tables: delete flowtable hooks via transaction list
    
    [ Upstream commit b6d9014a3335194590abdd2a2471ef5147a67645 ]
    
    Remove inactive bool field in nft_hook object that was introduced in
    abadb2f865d7 ("netfilter: nf_tables: delete devices from flowtable").
    Move stale flowtable hooks to transaction list instead.
    
    Deleting twice the same device does not result in ENOENT.
    
    Fixes: abadb2f865d7 ("netfilter: nf_tables: delete devices from flowtable")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ebaf04638bd3a991bcf24b58e4ca5ab53791b1f
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Jun 1 16:00:00 2022 +0200

    netfilter: nf_tables: use kfree_rcu(ptr, rcu) to release hooks in clean_net path
    
    [ Upstream commit ab5e5c062f67c5ae8cd07f0632ffa62dc0e7d169 ]
    
    Use kfree_rcu(ptr, rcu) variant instead as described by ae089831ff28
    ("netfilter: nf_tables: prefer kfree_rcu(ptr, rcu) variant").
    
    Fixes: f9a43007d3f7 ("netfilter: nf_tables: double hook unregistration in netns path")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7e599914669507ed22936e410b924b239e735d4
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Jun 1 10:47:35 2022 +0200

    netfilter: nat: really support inet nat without l3 address
    
    [ Upstream commit 282e5f8fe907dc3f2fbf9f2103b0e62ffc3a68a5 ]
    
    When no l3 address is given, priv->family is set to NFPROTO_INET and
    the evaluation function isn't called.
    
    Call it too so l4-only rewrite can work.
    Also add a test case for this.
    
    Fixes: a33f387ecd5aa ("netfilter: nft_nat: allow to specify layer 4 protocol NAT only")
    Reported-by: Yi Chen <yiche@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c8e8cc91a6ffc79865108279a74fd57d9070a17
Author: Steven Price <steven.price@arm.com>
Date:   Thu May 19 16:20:03 2022 +0100

    drm/panfrost: Job should reference MMU not file_priv
    
    [ Upstream commit 6e516faf04317db2c46cbec4e3b78b4653a5b109 ]
    
    For a while now it's been allowed for a MMU context to outlive it's
    corresponding panfrost_priv, however the job structure still references
    panfrost_priv to get hold of the MMU context. If panfrost_priv has been
    freed this is a use-after-free which I've been able to trigger resulting
    in a splat.
    
    To fix this, drop the reference to panfrost_priv in the job structure
    and add a direct reference to the MMU structure which is what's actually
    needed.
    
    Fixes: 7fdc48cc63a3 ("drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv")
    Signed-off-by: Steven Price <steven.price@arm.com>
    Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220519152003.81081-1-steven.price@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f768a8095d2b3518e2375dd8aeb452f987b6dda8
Author: Marek Vasut <marex@denx.de>
Date:   Thu May 19 01:38:44 2022 +0200

    drm/bridge: ti-sn65dsi83: Handle dsi_lanes == 0 as invalid
    
    [ Upstream commit edbc7960bef7fd71ef1e44d0df15b864784b14c8 ]
    
    Handle empty data-lanes = < >; property, which translates to
    dsi_lanes = 0 as invalid.
    
    Fixes: ceb515ba29ba6 ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Jonas Karlman <jonas@kwiboo.se>
    Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Marek Vasut <marex@denx.de>
    Cc: Maxime Ripard <maxime@cerno.tech>
    Cc: Neil Armstrong <narmstrong@baylibre.com>
    Cc: Robert Foss <robert.foss@linaro.org>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220518233844.248504-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 90c4f73104016748533a5707ecd15930fbeff402
Author: Kinglong Mee <kinglongmee@gmail.com>
Date:   Sun May 22 20:36:48 2022 +0800

    xprtrdma: treat all calls not a bcall when bc_serv is NULL
    
    [ Upstream commit 11270e7ca268e8d61b5d9e5c3a54bd1550642c9c ]
    
    When a rdma server returns a fault format reply, nfs v3 client may
    treats it as a bcall when bc service is not exist.
    
    The debug message at rpcrdma_bc_receive_call are,
    
    [56579.837169] RPC:       rpcrdma_bc_receive_call: callback XID
    00000001, length=20
    [56579.837174] RPC:       rpcrdma_bc_receive_call: 00 00 00 01 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 04
    
    After that, rpcrdma_bc_receive_call will meets NULL pointer as,
    
    [  226.057890] BUG: unable to handle kernel NULL pointer dereference at
    00000000000000c8
    ...
    [  226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20
    ...
    [  226.059732] Call Trace:
    [  226.059878]  rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma]
    [  226.060011]  __ib_process_cq+0x89/0x170 [ib_core]
    [  226.060092]  ib_cq_poll_work+0x26/0x80 [ib_core]
    [  226.060257]  process_one_work+0x1a7/0x360
    [  226.060367]  ? create_worker+0x1a0/0x1a0
    [  226.060440]  worker_thread+0x30/0x390
    [  226.060500]  ? create_worker+0x1a0/0x1a0
    [  226.060574]  kthread+0x116/0x130
    [  226.060661]  ? kthread_flush_work_fn+0x10/0x10
    [  226.060724]  ret_from_fork+0x35/0x40
    ...
    
    Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f5f8f850fbf75c563436fe924a139a8da5ac063
Author: Chao Yu <chao@kernel.org>
Date:   Fri May 27 12:13:30 2022 +0800

    f2fs: fix to tag gcing flag on page during file defragment
    
    [ Upstream commit 2d1fe8a86bf5e0663866fd0da83c2af1e1b0e362 ]
    
    In order to garantee migrated data be persisted during checkpoint,
    otherwise out-of-order persistency between data and node may cause
    data corruption after SPOR.
    
    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 10cdbc54a86b6a059f10be383b046f1d11c05f51
Author: Daniel Bristot de Oliveira <bristot@kernel.org>
Date:   Fri Apr 29 16:54:58 2022 +0200

    rtla/Makefile: Properly handle dependencies
    
    [ Upstream commit fe4d0d5dde457bb5832b866418b5036f4f0c8d13 ]
    
    Linus had a problem compiling RTLA, saying:
    
    "[...] I wish the tracing tools would do a bit more package
    checking and helpful error messages too, rather than just
    fail with:
    
        fatal error: tracefs.h: No such file or directory"
    
    Which is indeed not a helpful message. Update the Makefile, adding
    proper checks for the dependencies, with useful information about
    how to resolve possible problems.
    
    For example, the previous error is now reported as:
    
        $ make
        ********************************************
        ** NOTICE: libtracefs version 1.3 or higher not found
        **
        ** Consider installing the latest libtracefs from your
        ** distribution, e.g., 'dnf install libtracefs' on Fedora,
        ** or from source:
        **
        **  https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/
        **
        ********************************************
    
    These messages are inspired by the ones used on trace-cmd, as suggested
    by Stevel Rostedt.
    
    Link: https://lore.kernel.org/r/CAHk-=whxmA86E=csNv76DuxX_wYsg8mW15oUs3XTabu2Yc80yw@mail.gmail.com/
    
    Changes from V1:
     - Moved the rst2man check to the install phase (when it is used).
     - Removed the procps-ng lib check [1] as it is being removed.
    
    [1] a0f9f8c1030c66305c9b921057c3d483064d5529.1651220820.git.bristot@kernel.org
    
    Link: https://lkml.kernel.org/r/3f1fac776c37e4b67c876a94e5a0e45ed022ff3d.1651238057.git.bristot@kernel.org
    
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
    Suggested-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3eb629fae7d3e6b124c465242fdc87c03a7e512
Author: Greg Ungerer <gerg@linux-m68k.org>
Date:   Mon May 16 16:36:07 2022 +1000

    m68knommu: fix undefined reference to `mach_get_rtc_pll'
    
    [ Upstream commit 1300eec9e51f23c34c4487d2b06f58ca22e1ad3d ]
    
    Configuring for a nommu classic m68k target and enabling the generic rtc
    driver (CONFIG_RTC_DRV_GENERIC) will result in the following compile
    error:
    
       m68k-linux-ld: arch/m68k/kernel/time.o: in function `rtc_ioctl':
       time.c:(.text+0x82): undefined reference to `mach_get_rtc_pll'
       m68k-linux-ld: time.c:(.text+0xbc): undefined reference to `mach_set_rtc_pll'
       m68k-linux-ld: time.c:(.text+0xf4): undefined reference to `mach_set_rtc_pll'
    
    There are no definitions of "mach_set_rtc_pll" and "mach_get_rtc_pll" in the
    nommu code paths. Move these definitions and the associated "mach_hwclk",
    so that they are around their use case in time.c. This means they will
    always be defined on the builds that require them, and not on those that
    cannot use them - such as ColdFire (both with and without MMU enabled).
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ca8a07f141fd8eec347a82bdfa4b94164f2bb97
Author: Liao Chang <liaochang1@huawei.com>
Date:   Fri Apr 8 18:09:10 2022 +0800

    RISC-V: use memcpy for kexec_file mode
    
    [ Upstream commit b7fb4d78a6ade6026d9e5cf438c2a46ab962e032 ]
    
    The pointer to buffer loading kernel binaries is in kernel space for
    kexec_fil mode, When copy_from_user copies data from pointer to a block
    of memory, it checkes that the pointer is in the user space range, on
    RISCV-V that is:
    
    static inline bool __access_ok(unsigned long addr, unsigned long size)
    {
            return size <= TASK_SIZE && addr <= TASK_SIZE - size;
    }
    
    and TASK_SIZE is 0x4000000000 for 64-bits, which now causes
    copy_from_user to reject the access of the field 'buf' of struct
    kexec_segment that is in range [CONFIG_PAGE_OFFSET - VMALLOC_SIZE,
    CONFIG_PAGE_OFFSET), is invalid user space pointer.
    
    This patch fixes this issue by skipping access_ok(), use mempcy() instead.
    
    Signed-off-by: Liao Chang <liaochang1@huawei.com>
    Link: https://lore.kernel.org/r/20220408100914.150110-3-lizhengyu3@huawei.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b26fd8ea5a0639acaf7c670ae69c903a08fb101
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri May 13 18:05:41 2022 +0800

    video: fbdev: pxa3xx-gcu: release the resources correctly in pxa3xx_gcu_probe/remove()
    
    [ Upstream commit d87ad457f7e1b8d2492ca5b1531eb35030a1cc8f ]
    
    In pxa3xx_gcu_probe(), the sequence of error lable is wrong, it will
    leads some resource leaked, so adjust the sequence to handle the error
    correctly, and if pxa3xx_gcu_add_buffer() fails, pxa3xx_gcu_free_buffers()
    need be called.
    In pxa3xx_gcu_remove(), add missing clk_disable_unpreprare().
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 728f831b5edda3c04ddb464f6586f632733d0fe3
Author: Saurabh Sengar <ssengar@linux.microsoft.com>
Date:   Wed Apr 27 06:47:53 2022 -0700

    video: fbdev: hyperv_fb: Allow resolutions with size > 64 MB for Gen1
    
    [ Upstream commit c4b4d7047f16a8d138ce76da65faefb7165736f2 ]
    
    This patch fixes a bug where GEN1 VMs doesn't allow resolutions greater
    than 64 MB size (eg 7680x4320). Unnecessary PCI check limits Gen1 VRAM
    to legacy PCI BAR size only (ie 64MB). Thus any, resolution requesting
    greater then 64MB (eg 7680x4320) would fail. MMIO region assigning this
    memory shouldn't be limited by PCI bar size.
    
    Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08d7a26d115cc7892668baa9750f64bd8baca29b
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sat May 14 10:08:14 2022 -0400

    NFSv4: Don't hold the layoutget locks across multiple RPC calls
    
    [ Upstream commit 6949493884fe88500de4af182588e071cf1544ee ]
    
    When doing layoutget as part of the open() compound, we have to be
    careful to release the layout locks before we can call any further RPC
    calls, such as setattr(). The reason is that those calls could trigger
    a recall, which could deadlock.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4838969e4d95d2bd2995d1605b20d3144fcb3e74
Author: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Date:   Tue May 10 12:42:40 2022 +0530

    dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data type
    
    [ Upstream commit f9a9f43a62a04ec3183fb0da9226c7706eed0115 ]
    
    In zynqmp_dma_alloc/free_chan_resources functions there is a
    potential overflow in the below expressions.
    
    dma_alloc_coherent(chan->dev, (2 * chan->desc_size *
                       ZYNQMP_DMA_NUM_DESCS),
                       &chan->desc_pool_p, GFP_KERNEL);
    
    dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) *
                     ZYNQMP_DMA_NUM_DESCS),
                    chan->desc_pool_v, chan->desc_pool_p);
    
    The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Though
    this overflow condition is not observed but it is a potential problem
    in the case of 32-bit multiplication. Hence fix it by changing the
    desc_size data type to size_t.
    
    In addition to coverity fix it also reuse ZYNQMP_DMA_DESC_SIZE macro in
    dma_alloc_coherent API argument.
    
    Addresses-Coverity: Event overflow_before_widen.
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
    Link: https://lore.kernel.org/r/1652166762-18317-2-git-send-email-radhey.shyam.pandey@xilinx.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4342cdf6652bf82ec069c10deb58e4c12c9d14c6
Author: Greg Ungerer <gerg@linux-m68k.org>
Date:   Fri May 13 17:27:39 2022 +1000

    m68knommu: fix undefined reference to `_init_sp'
    
    [ Upstream commit a71b9e66fee47c59b3ec34e652b5c23bc6550794 ]
    
    When configuring a nommu classic m68k system enabling the uboot parameter
    passing support (CONFIG_UBOOT) will produce the following compile error:
    
       m68k-linux-ld: arch/m68k/kernel/uboot.o: in function `process_uboot_commandline':
       uboot.c:(.init.text+0x32): undefined reference to `_init_sp'
    
    The logic to support this option is only used on ColdFire based platforms
    (in its head.S startup code). So make the selection of this option
    depend on building for a ColdFire based platform.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1af404ebe0fca935cb8eba2a4f8b852700c2266
Author: Greg Ungerer <gerg@linux-m68k.org>
Date:   Wed Apr 20 23:27:47 2022 +1000

    m68knommu: set ZERO_PAGE() to the allocated zeroed page
    
    [ Upstream commit dc068f46217970d9516f16cd37972a01d50dc055 ]
    
    The non-MMU m68k pagetable ZERO_PAGE() macro is being set to the
    somewhat non-sensical value of "virt_to_page(0)". The zeroth page
    is not in any way guaranteed to be a page full of "0". So the result
    is that ZERO_PAGE() will almost certainly contain random values.
    
    We already allocate a real "empty_zero_page" in the mm setup code shared
    between MMU m68k and non-MMU m68k. It is just not hooked up to the
    ZERO_PAGE() macro for the non-MMU m68k case.
    
    Fix ZERO_PAGE() to use the allocated "empty_zero_page" pointer.
    
    I am not aware of any specific issues caused by the old code.
    
    Link: https://lore.kernel.org/linux-m68k/2a462b23-5b8e-bbf4-ec7d-778434a3b9d7@google.com/T/#t
    Reported-by: Hugh Dickens <hughd@google.com>
    Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d8741f70fe7d1bf67aced76e2376742d1e6eb043
Author: Lucas Tanure <tanureal@opensource.cirrus.com>
Date:   Wed Apr 13 10:14:10 2022 +0100

    i2c: cadence: Increase timeout per message if necessary
    
    [ Upstream commit 96789dce043f5bff8b7d62aa28d52a7c59403a84 ]
    
    Timeout as 1 second sets an upper limit on the length
    of the transfer executed, but there is no maximum length
    of a write or read message set in i2c_adapter_quirks for
    this controller.
    
    This upper limit affects devices that require sending
    large firmware blobs over I2C.
    
    To remove that limitation, calculate the minimal time
    necessary, plus some wiggle room, for every message and
    use it instead of the default one second, if more than
    one second.
    
    Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>
    Acked-by: Michal Simek <michal.simek@xilinx.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd6374af36cc548464d8c47a93fdba7303bb82a4
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Fri Apr 15 21:19:02 2022 +0800

    f2fs: remove WARN_ON in f2fs_is_valid_blkaddr
    
    [ Upstream commit dc2f78e2d4cc844a1458653d57ce1b54d4a29f21 ]
    
    Syzbot triggers two WARNs in f2fs_is_valid_blkaddr and
    __is_bitmap_valid. For example, in f2fs_is_valid_blkaddr,
    if type is DATA_GENERIC_ENHANCE or DATA_GENERIC_ENHANCE_READ,
    it invokes WARN_ON if blkaddr is not in the right range.
    The call trace is as follows:
    
     f2fs_get_node_info+0x45f/0x1070
     read_node_page+0x577/0x1190
     __get_node_page.part.0+0x9e/0x10e0
     __get_node_page
     f2fs_get_node_page+0x109/0x180
     do_read_inode
     f2fs_iget+0x2a5/0x58b0
     f2fs_fill_super+0x3b39/0x7ca0
    
    Fix these two WARNs by replacing WARN_ON with dump_stack.
    
    Reported-by: syzbot+763ae12a2ede1d99d4dc@syzkaller.appspotmail.com
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.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 db728a891f9177b044aaca89b678f6b5e24d5cc3
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Apr 25 19:45:25 2022 +0800

    iommu/arm-smmu-v3: check return value after calling platform_get_resource()
    
    [ Upstream commit b131fa8c1d2afd05d0b7598621114674289c2fbb ]
    
    It will cause null-ptr-deref if platform_get_resource() returns NULL,
    we need check the return value.
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20220425114525.2651143-1-yangyingliang@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80776a71340f57d6a4952635fc89f0342072f3ca
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Apr 25 19:41:36 2022 +0800

    iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()
    
    [ Upstream commit d9ed8af1dee37f181096631fb03729ece98ba816 ]
    
    It will cause null-ptr-deref when using 'res', if platform_get_resource()
    returns NULL, so move using 'res' after devm_ioremap_resource() that
    will check it to avoid null-ptr-deref.
    And use devm_platform_get_and_ioremap_resource() to simplify code.
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20220425114136.2649310-1-yangyingliang@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8b5c425ad82c462bca8e7f4e8c6b83f03f7a33d
Author: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Date:   Tue Apr 26 20:24:06 2022 +0800

    tracing: Avoid adding tracer option before update_tracer_options
    
    [ Upstream commit ef9188bcc6ca1d8a2ad83e826b548e6820721061 ]
    
    To prepare for support asynchronous tracer_init_tracefs initcall,
    avoid calling create_trace_option_files before __update_tracer_options.
    Otherwise, create_trace_option_files will show warning because
    some tracers in trace_types list are already in tr->topts.
    
    For example, hwlat_tracer call register_tracer in late_initcall,
    and global_trace.dir is already created in tracing_init_dentry,
    hwlat_tracer will be put into tr->topts.
    Then if the __update_tracer_options is executed after hwlat_tracer
    registered, create_trace_option_files find that hwlat_tracer is
    already in tr->topts.
    
    Link: https://lkml.kernel.org/r/20220426122407.17042-2-mark-pk.tsai@mediatek.com
    
    Link: https://lore.kernel.org/lkml/20220322133339.GA32582@xsang-OptiPlex-9020/
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43bfc4dccc416c964b53cbdc430e814f8b6f770b
Author: Jun Miao <jun.miao@intel.com>
Date:   Tue Apr 19 09:39:10 2022 +0800

    tracing: Fix sleeping function called from invalid context on RT kernel
    
    [ Upstream commit 12025abdc8539ed9d5014e2d647a3fd1bd3de5cd ]
    
    When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the
    cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the
    atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,
    these locks are replaced with sleepable rt-spinlock, so the stack calltrace will
    be triggered.
    Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start
    tp_printk=1" enabled.
    
     BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
     in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
     preempt_count: 2, expected: 0
     RCU nest depth: 0, expected: 0
     Preemption disabled at:
     [<ffffffff8992303e>] try_to_wake_up+0x7e/0xba0
     CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
     Call Trace:
      <TASK>
      dump_stack_lvl+0x60/0x8c
      dump_stack+0x10/0x12
      __might_resched.cold+0x11d/0x155
      rt_spin_lock+0x40/0x70
      trace_event_buffer_commit+0x2fa/0x4c0
      ? map_vsyscall+0x93/0x93
      trace_event_raw_event_initcall_start+0xbe/0x110
      ? perf_trace_initcall_finish+0x210/0x210
      ? probe_sched_wakeup+0x34/0x40
      ? ttwu_do_wakeup+0xda/0x310
      ? trace_hardirqs_on+0x35/0x170
      ? map_vsyscall+0x93/0x93
      do_one_initcall+0x217/0x3c0
      ? trace_event_raw_event_initcall_level+0x170/0x170
      ? push_cpu_stop+0x400/0x400
      ? cblist_init_generic+0x241/0x290
      kernel_init_freeable+0x1ac/0x347
      ? _raw_spin_unlock_irq+0x65/0x80
      ? rest_init+0xf0/0xf0
      kernel_init+0x1e/0x150
      ret_from_fork+0x22/0x30
      </TASK>
    
    Link: https://lkml.kernel.org/r/20220419013910.894370-1-jun.miao@intel.com
    
    Signed-off-by: Jun Miao <jun.miao@intel.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67093fb9b17cd8b11c53826bcf58fe9d2dcfaded
Author: Jeff Xie <xiehuan09@gmail.com>
Date:   Sun Apr 10 22:50:25 2022 +0800

    tracing: Make tp_printk work on syscall tracepoints
    
    [ Upstream commit cb1c45fb68b8a4285ccf750842b1136f26cfe267 ]
    
    Currently the tp_printk option has no effect on syscall tracepoint.
    When adding the kernel option parameter tp_printk, then:
    
    echo 1 > /sys/kernel/debug/tracing/events/syscalls/enable
    
    When running any application, no trace information is printed on the
    terminal.
    
    Now added printk for syscall tracepoints.
    
    Link: https://lkml.kernel.org/r/20220410145025.681144-1-xiehuan09@gmail.com
    
    Signed-off-by: Jeff Xie <xiehuan09@gmail.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7a72ac2f24726ba9dfbd2af1ac2c76863b198a0
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed Apr 6 11:30:59 2022 +0900

    bootconfig: Make the bootconfig.o as a normal object file
    
    [ Upstream commit 6014a23638cdee63a71ef13c51d7c563eb5829ee ]
    
    Since the APIs defined in the bootconfig.o are not individually used,
    it is meaningless to build it as library by lib-y. Use obj-y for that.
    
    Link: https://lkml.kernel.org/r/164921225875.1090670.15565363126983098971.stgit@devnote2
    
    Cc: Padmanabha Srinivasaiah <treasure4paddy@gmail.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Sami Tolvanen <samitolvanen@google.com>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
    Reported-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f843cdfc202caaa5d67db3395d893e56362e43a
Author: Gong Yuanjun <ruc_gongyuanjun@163.com>
Date:   Thu Apr 7 12:26:57 2022 +0800

    mips: cpc: Fix refcount leak in mips_cpc_default_phys_base
    
    [ Upstream commit 4107fa700f314592850e2c64608f6ede4c077476 ]
    
    Add the missing of_node_put() to release the refcount incremented
    by of_find_compatible_node().
    
    Signed-off-by: Gong Yuanjun <ruc_gongyuanjun@163.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e9a90ead68a4a23efc9a39c1da121efb8f983a6
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Mon Apr 11 15:09:38 2022 -0700

    dmaengine: idxd: set DMA_INTERRUPT cap bit
    
    [ Upstream commit 4e5a4eb20393b851590b4465f1197a8041c2076b ]
    
    Even though idxd driver has always supported interrupt, it never actually
    set the DMA_INTERRUPT cap bit. Rectify this mistake so the interrupt
    capability is advertised.
    
    Reported-by: Ben Walker <benjamin.walker@intel.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/164971497859.2201379.17925303210723708961.stgit@djiang5-desk3.ch.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8926dd7e9053d57cdcf581348e68d825459553b3
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jun 5 11:51:48 2022 -0700

    bluetooth: don't use bitmaps for random flag accesses
    
    [ Upstream commit e1cff7002b716bd0b5f5f4afd4273c99aa8644be ]
    
    The bluetooth code uses our bitmap infrastructure for the two bits (!)
    of connection setup flags, and in the process causes odd problems when
    it converts between a bitmap and just the regular values of said bits.
    
    It's completely pointless to do things like bitmap_to_arr32() to convert
    a bitmap into a u32.  It shoudln't have been a bitmap in the first
    place.  The reason to use bitmaps is if you have arbitrary number of
    bits you want to manage (not two!), or if you rely on the atomicity
    guarantees of the bitmap setting and clearing.
    
    The code could use an "atomic_t" and use "atomic_or/andnot()" to set and
    clear the bit values, but considering that it then copies the bitmaps
    around with "bitmap_to_arr32()" and friends, there clearly cannot be a
    lot of atomicity requirements.
    
    So just use a regular integer.
    
    In the process, this avoids the warnings about erroneous use of
    bitmap_from_u64() which were triggered on 32-bit architectures when
    conversion from a u64 would access two words (and, surprise, surprise,
    only one word is needed - and indeed overkill - for a 2-bit bitmap).
    
    That was always problematic, but the compiler seems to notice it and
    warn about the invalid pattern only after commit 0a97953fd221 ("lib: add
    bitmap_{from,to}_arr64") changed the exact implementation details of
    'bitmap_from_u64()', as reported by Sudip Mukherjee and Stephen Rothwell.
    
    Fixes: fe92ee6425a2 ("Bluetooth: hci_core: Rework hci_conn_params flags")
    Link: https://lore.kernel.org/all/YpyJ9qTNHJzz0FHY@debian/
    Link: https://lore.kernel.org/all/20220606080631.0c3014f2@canb.auug.org.au/
    Link: https://lore.kernel.org/all/20220605162537.1604762-1-yury.norov@gmail.com/
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Reviewed-by: Yury Norov <yury.norov@gmail.com>
    Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Cc: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ebc130ba142dd312a2997a2114fd389b79ee3e9
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu May 12 15:31:34 2022 -0700

    Bluetooth: hci_sync: Fix attempting to suspend with unfiltered passive scan
    
    [ Upstream commit 3b42055388c30f2761a2d9cd9af2c99611dfe457 ]
    
    When suspending the passive scanning _must_ have its filter_policy set
    to 0x01 to use the accept list otherwise _any_ advertise report would
    end up waking up the system.
    
    In order to fix the filter_policy the code now checks for
    hdev->suspended && HCI_CONN_FLAG_REMOTE_WAKEUP
    first, since the MGMT_OP_SET_DEVICE_FLAGS will reject any attempt to
    set HCI_CONN_FLAG_REMOTE_WAKEUP when it cannot be programmed in the
    acceptlist, so it can return success causing the proper filter_policy
    to be used.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215768
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60c465cdf128bb1d0d56979003e9b6cbfe6b5278
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu May 12 15:31:33 2022 -0700

    Bluetooth: MGMT: Add conditions for setting HCI_CONN_FLAG_REMOTE_WAKEUP
    
    [ Upstream commit a9a347655d224fa2841877957b34fc9d491fc2d7 ]
    
    HCI_CONN_FLAG_REMOTE_WAKEUP can only be set if device can be programmed
    in the allowlist which in case of device using RPA requires LL Privacy
    support to be enabled.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215768
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3267c0e64e43d88b3f936598cb5c77d8105dd049
Author: Leo Yan <leo.yan@linaro.org>
Date:   Mon May 30 16:42:53 2022 +0800

    perf c2c: Fix sorting in percent_rmt_hitm_cmp()
    
    [ Upstream commit b24192a17337abbf3f44aaa75e15df14a2d0016e ]
    
    The function percent_rmt_hitm_cmp() wrongly uses local HITMs for
    sorting remote HITMs.
    
    Since this function is to sort cache lines for remote HITMs, this patch
    changes to use 'rmt_hitm' field for correct sorting.
    
    Fixes: 9cb3500afc0980c5 ("perf c2c report: Add hitm/store percent related sort keys")
    Signed-off-by: Leo Yan <leo.yan@linaro.org>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Joe Mario <jmario@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20220530084253.750190-1-leo.yan@linaro.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93fc86ec2db18899f2f9a94fd34e680375fa52d7
Author: Zhengjun Xing <zhengjun.xing@linux.intel.com>
Date:   Thu Jun 2 23:36:03 2022 +0800

    perf record: Support sample-read topdown metric group for hybrid platforms
    
    [ Upstream commit 151e7d75036b4e2ac0f33730bc1a5b3ff424d9a7 ]
    
    With the hardware TopDown metrics feature, the sample-read feature should
    be supported for a TopDown group, e.g., sample a non-topdown event and read
    a Topdown metric group. But the current perf record code errors are out.
    
    For a TopDown metric group,the slots event must be the leader of the group,
    but the leader slots event doesn't support sampling. To support sample-read
    the TopDown metric group, uses the 2nd event of the group as the "leader"
    for the purposes of sampling.
    
    Only the platform with the TopDown metric feature supports sample-read the
    topdown group. In commit acb65150a47c ("perf record: Support sample-read
    topdown metric group"), it adds arch_topdown_sample_read() to indicate
    whether the TopDown group supports sample-read, it should only work on the
    non-hybrid systems, this patch extends the support for hybrid platforms.
    
    Before:
    
      # ./perf record -e "{cpu_core/slots/,cpu_core/cycles/,cpu_core/topdown-retiring/}:S" -a sleep 1
      Error:
      The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (cpu_core/topdown-retiring/).
      /bin/dmesg | grep -i perf may provide additional information.
    
    After:
    
      # ./perf record -e "{cpu_core/slots/,cpu_core/cycles/,cpu_core/topdown-retiring/}:S" -a sleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.238 MB perf.data (369 samples) ]
    
    Fixes: acb65150a47c2bae ("perf record: Support sample-read topdown metric group")
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Zhengjun Xing <zhengjun.xing@linux.intel.com>
    Acked-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20220602153603.1884710-1-zhengjun.xing@linux.intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6384acec542c810b5dac44711ff241c528cf0433
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Wed May 18 07:39:00 2022 -0700

    perf parse-events: Move slots event for the hybrid platform too
    
    [ Upstream commit e0e14cdff31d326f81e0edbd5140f788c870756c ]
    
    The commit 94dbfd6781a0e87b ("perf parse-events: Architecture specific
    leader override") introduced a feature to reorder the slots event to
    fulfill the restriction of the perf metrics topdown group. But the
    feature doesn't work on the hybrid machine.
    
      $ perf stat -e "{cpu_core/instructions/,cpu_core/slots/,cpu_core/topdown-retiring/}" -a sleep 1
    
       Performance counter stats for 'system wide':
    
           <not counted>      cpu_core/instructions/
           <not counted>      cpu_core/slots/
         <not supported>      cpu_core/topdown-retiring/
    
             1.002871801 seconds time elapsed
    
    A hybrid platform has a different PMU name for the core PMUs, while
    current perf hard code the PMU name "cpu".
    
    Introduce a new function to check whether the system supports the perf
    metrics feature. The result is cached for the future usage.
    
    For X86, the core PMU name always has "cpu" prefix.
    
    With the patch:
    
      $ perf stat -e "{cpu_core/instructions/,cpu_core/slots/,cpu_core/topdown-retiring/}" -a sleep 1
    
       Performance counter stats for 'system wide':
    
              76,337,010      cpu_core/slots/
              10,416,809      cpu_core/instructions/
              11,692,372      cpu_core/topdown-retiring/
    
             1.002805453 seconds time elapsed
    
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Xing Zhengjun <zhengjun.xing@linux.intel.com>
    Link: https://lore.kernel.org/r/20220518143900.1493980-5-kan.liang@linux.intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bde1c93570930dde5f90a5bc5509efde3c192ba9
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Wed May 18 07:38:57 2022 -0700

    perf evsel: Fixes topdown events in a weak group for the hybrid platform
    
    [ Upstream commit 39d5f412da84784bcc7f39ed49e55376be526fc7 ]
    
    The patch ("perf evlist: Keep topdown counters in weak group") fixes the
    perf metrics topdown event issue when the topdown events are in a weak
    group on a non-hybrid platform. However, it doesn't work for the hybrid
    platform.
    
      $./perf stat -e '{cpu_core/slots/,cpu_core/topdown-bad-spec/,
      cpu_core/topdown-be-bound/,cpu_core/topdown-fe-bound/,
      cpu_core/topdown-retiring/,cpu_core/branch-instructions/,
      cpu_core/branch-misses/,cpu_core/bus-cycles/,cpu_core/cache-misses/,
      cpu_core/cache-references/,cpu_core/cpu-cycles/,cpu_core/instructions/,
      cpu_core/mem-loads/,cpu_core/mem-stores/,cpu_core/ref-cycles/,
      cpu_core/cache-misses/,cpu_core/cache-references/}:W' -a sleep 1
    
      Performance counter stats for 'system wide':
    
           751,765,068      cpu_core/slots/                        (84.07%)
       <not supported>      cpu_core/topdown-bad-spec/
       <not supported>      cpu_core/topdown-be-bound/
       <not supported>      cpu_core/topdown-fe-bound/
       <not supported>      cpu_core/topdown-retiring/
            12,398,197      cpu_core/branch-instructions/          (84.07%)
             1,054,218      cpu_core/branch-misses/                (84.24%)
           539,764,637      cpu_core/bus-cycles/                   (84.64%)
                14,683      cpu_core/cache-misses/                 (84.87%)
             7,277,809      cpu_core/cache-references/             (77.30%)
           222,299,439      cpu_core/cpu-cycles/                   (77.28%)
            63,661,714      cpu_core/instructions/                 (84.85%)
                     0      cpu_core/mem-loads/                    (77.29%)
            12,271,725      cpu_core/mem-stores/                   (77.30%)
           542,241,102      cpu_core/ref-cycles/                   (84.85%)
                 8,854      cpu_core/cache-misses/                 (76.71%)
             7,179,013      cpu_core/cache-references/             (76.31%)
    
             1.003245250 seconds time elapsed
    
    A hybrid platform has a different PMU name for the core PMUs, while
    the current perf hard code the PMU name "cpu".
    
    The evsel->pmu_name can be used to replace the "cpu" to fix the issue.
    For a hybrid platform, the pmu_name must be non-NULL. Because there are
    at least two core PMUs. The PMU has to be specified.
    For a non-hybrid platform, the pmu_name may be NULL. Because there is
    only one core PMU, "cpu". For a NULL pmu_name, we can safely assume that
    it is a "cpu" PMU.
    
    In case other PMUs also define the "slots" event, checking the PMU type
    as well.
    
    With the patch,
    
      $ perf stat -e '{cpu_core/slots/,cpu_core/topdown-bad-spec/,
      cpu_core/topdown-be-bound/,cpu_core/topdown-fe-bound/,
      cpu_core/topdown-retiring/,cpu_core/branch-instructions/,
      cpu_core/branch-misses/,cpu_core/bus-cycles/,cpu_core/cache-misses/,
      cpu_core/cache-references/,cpu_core/cpu-cycles/,cpu_core/instructions/,
      cpu_core/mem-loads/,cpu_core/mem-stores/,cpu_core/ref-cycles/,
      cpu_core/cache-misses/,cpu_core/cache-references/}:W' -a sleep 1
    
      Performance counter stats for 'system wide':
    
         766,620,266   cpu_core/slots/                                        (84.06%)
          73,172,129   cpu_core/topdown-bad-spec/ #    9.5% bad speculation   (84.06%)
         193,443,341   cpu_core/topdown-be-bound/ #    25.0% backend bound    (84.06%)
         403,940,929   cpu_core/topdown-fe-bound/ #    52.3% frontend bound   (84.06%)
         102,070,237   cpu_core/topdown-retiring/ #    13.2% retiring         (84.06%)
          12,364,429   cpu_core/branch-instructions/                          (84.03%)
           1,080,124   cpu_core/branch-misses/                                (84.24%)
         564,120,383   cpu_core/bus-cycles/                                   (84.65%)
              36,979   cpu_core/cache-misses/                                 (84.86%)
           7,298,094   cpu_core/cache-references/                             (77.30%)
         227,174,372   cpu_core/cpu-cycles/                                   (77.31%)
          63,886,523   cpu_core/instructions/                                 (84.87%)
                   0   cpu_core/mem-loads/                                    (77.31%)
          12,208,782   cpu_core/mem-stores/                                   (77.31%)
         566,409,738   cpu_core/ref-cycles/                                   (84.87%)
              23,118   cpu_core/cache-misses/                                 (76.71%)
           7,212,602   cpu_core/cache-references/                             (76.29%)
    
           1.003228667 seconds time elapsed
    
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Acked-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Xing Zhengjun <zhengjun.xing@linux.intel.com>
    Link: https://lore.kernel.org/r/20220518143900.1493980-2-kan.liang@linux.intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 528229474e1cbb1b3451cb713d94aecb5f6ee264
Author: Saravana Kannan <saravanak@google.com>
Date:   Fri Jun 3 13:31:37 2022 +0200

    driver core: Fix wait_for_device_probe() & deferred_probe_timeout interaction
    
    [ Upstream commit 5ee76c256e928455212ab759c51d198fedbe7523 ]
    
    Mounting NFS rootfs was timing out when deferred_probe_timeout was
    non-zero [1].  This was because ip_auto_config() initcall times out
    waiting for the network interfaces to show up when
    deferred_probe_timeout was non-zero. While ip_auto_config() calls
    wait_for_device_probe() to make sure any currently running deferred
    probe work or asynchronous probe finishes, that wasn't sufficient to
    account for devices being deferred until deferred_probe_timeout.
    
    Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits
    until the deferred_probe_timeout fires") tried to fix that by making
    sure wait_for_device_probe() waits for deferred_probe_timeout to expire
    before returning.
    
    However, if wait_for_device_probe() is called from the kernel_init()
    context:
    
    - Before deferred_probe_initcall() [2], it causes the boot process to
      hang due to a deadlock.
    
    - After deferred_probe_initcall() [3], it blocks kernel_init() from
      continuing till deferred_probe_timeout expires and beats the point of
      deferred_probe_timeout that's trying to wait for userspace to load
      modules.
    
    Neither of this is good. So revert the changes to
    wait_for_device_probe().
    
    [1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/
    [2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/
    [3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/
    
    Fixes: 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires")
    Cc: John Stultz <jstultz@google.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
    Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Rob Herring <robh@kernel.org>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: Sudeep Holla <sudeep.holla@arm.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
    Cc: Basil Eljuse <Basil.Eljuse@arm.com>
    Cc: Ferry Toth <fntoth@gmail.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Anders Roxell <anders.roxell@linaro.org>
    Cc: linux-pm@vger.kernel.org
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: John Stultz <jstultz@google.com>
    Signed-off-by: Saravana Kannan <saravanak@google.com>
    Link: https://lore.kernel.org/r/20220526034609.480766-2-saravanak@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 292be63c382ce20673ee61dff1ee9ed4a3dcaae7
Author: Hoang Le <hoang.h.le@dektech.com.au>
Date:   Thu Jun 2 13:30:53 2022 +0700

    tipc: check attribute length for bearer name
    
    [ Upstream commit 7f36f798f89bf32c0164049cb0e3fd1af613d0bb ]
    
    syzbot reported uninit-value:
    =====================================================
    BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]
    BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725
     string_nocheck lib/vsprintf.c:644 [inline]
     string+0x4f9/0x6f0 lib/vsprintf.c:725
     vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806
     vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158
     vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256
     vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283
     vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50
     _printk+0x18d/0x1cf kernel/printk/printk.c:2293
     tipc_enable_bearer net/tipc/bearer.c:371 [inline]
     __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033
     tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042
     genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
    
    - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.
    - Do not use 'illegal name' in printing message.
    
    Reported-by: syzbot+e820fdc8ce362f2dea51@syzkaller.appspotmail.com
    Fixes: cb30a63384bc ("tipc: refactor function tipc_enable_bearer()")
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
    Link: https://lore.kernel.org/r/20220602063053.5892-1-hoang.h.le@dektech.com.au
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6b3e4d3336028269aeec7dc6d3a140a7faa28db
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Mon May 30 23:21:58 2022 +0800

    ax25: Fix ax25 session cleanup problems
    
    [ Upstream commit 7d8a3a477b3e25ada8dc71d22048c2ea417209a0 ]
    
    There are session cleanup problems in ax25_release() and
    ax25_disconnect(). If we setup a session and then disconnect,
    the disconnected session is still in "LISTENING" state that
    is shown below.
    
    Active AX.25 sockets
    Dest       Source     Device  State        Vr/Vs    Send-Q  Recv-Q
    DL9SAU-4   DL9SAU-3   ???     LISTENING    000/000  0       0
    DL9SAU-3   DL9SAU-4   ???     LISTENING    000/000  0       0
    
    The first reason is caused by del_timer_sync() in ax25_release().
    The timers of ax25 are used for correct session cleanup. If we use
    ax25_release() to close ax25 sessions and ax25_dev is not null,
    the del_timer_sync() functions in ax25_release() will execute.
    As a result, the sessions could not be cleaned up correctly,
    because the timers have stopped.
    
    In order to solve this problem, this patch adds a device_up flag
    in ax25_dev in order to judge whether the device is up. If there
    are sessions to be cleaned up, the del_timer_sync() in
    ax25_release() will not execute. What's more, we add ax25_cb_del()
    in ax25_kill_by_device(), because the timers have been stopped
    and there are no functions that could delete ax25_cb if we do not
    call ax25_release(). Finally, we reorder the position of
    ax25_list_lock in ax25_cb_del() in order to synchronize among
    different functions that call ax25_cb_del().
    
    The second reason is caused by improper check in ax25_disconnect().
    The incoming ax25 sessions which ax25->sk is null will close
    heartbeat timer, because the check "if(!ax25->sk || ..)" is
    satisfied. As a result, the session could not be cleaned up properly.
    
    In order to solve this problem, this patch changes the improper
    check to "if(ax25->sk && ..)" in ax25_disconnect().
    
    What`s more, the ax25_disconnect() may be called twice, which is
    not necessary. For example, ax25_kill_by_device() calls
    ax25_disconnect() and sets ax25->state to AX25_STATE_0, but
    ax25_release() calls ax25_disconnect() again.
    
    In order to solve this problem, this patch add a check in
    ax25_release(). If the flag of ax25->sk equals to SOCK_DEAD,
    the ax25_disconnect() in ax25_release() should not be executed.
    
    Fixes: 82e31755e55f ("ax25: Fix UAF bugs in ax25 timers")
    Fixes: 8a367e74c012 ("ax25: Fix segfault after sock connection timeout")
    Reported-and-tested-by: Thomas Osterried <thomas@osterried.de>
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220530152158.108619-1-duoming@zju.edu.cn
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78f8e96df06e2d04d82d4071c299b59d28744f47
Author: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Date:   Wed Jun 1 15:25:43 2022 +0900

    scsi: sd: Fix potential NULL pointer dereference
    
    [ Upstream commit 05fbde3a77a4f1d62e4c4428f384288c1f1a0be5 ]
    
    If sd_probe() sees an early error before sdkp->device is initialized,
    sd_zbc_release_disk() is called. This causes a NULL pointer dereference
    when sd_is_zoned() is called inside that function. Avoid this by removing
    the call to sd_zbc_release_disk() in sd_probe() error path.
    
    This change is safe and does not result in zone information memory leakage
    because the zone information for a zoned disk is allocated only when
    sd_revalidate_disk() is called, at which point sdkp->disk_dev is fully set,
    resulting in sd_disk_release() being called when needed to cleanup a disk
    zone information using sd_zbc_release_disk().
    
    Link: https://lore.kernel.org/r/20220601062544.905141-2-damien.lemoal@opensource.wdc.com
    Fixes: 89d947561077 ("sd: Implement support for ZBC devices")
    Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Suggested-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ebcece2fd19c9a4e93596c6dc884e61b0837c4c
Author: Kuogee Hsieh <quic_khsieh@quicinc.com>
Date:   Tue May 17 09:21:34 2022 -0700

    drm/msm/dp: Always clear mask bits to disable interrupts at dp_ctrl_reset_irq_ctrl()
    
    [ Upstream commit 993a2adc6e2e94a0a7b5bfc054eda90ac95f62c3 ]
    
    dp_catalog_ctrl_reset() will software reset DP controller. But it will
    not reset programmable registers to default value. DP driver still have
    to clear mask bits to interrupt status registers to disable interrupts
    after software reset of controller.
    
    At current implementation, dp_ctrl_reset_irq_ctrl() will software reset dp
    controller but did not call dp_catalog_ctrl_enable_irq(false) to clear hpd
    related interrupt mask bits to disable hpd related interrupts due to it
    mistakenly think hpd related interrupt mask bits will be cleared by software
    reset of dp controller automatically. This mistake may cause system to crash
    during suspending procedure due to unexpected irq fired and trigger event
    thread to access dp controller registers with controller clocks are disabled.
    
    This patch fixes system crash during suspending problem by removing "enable"
    flag condition checking at dp_ctrl_reset_irq_ctrl() so that hpd related
    interrupt mask bits are cleared to prevent unexpected from happening.
    
    Changes in v2:
    -- add more details commit text
    
    Changes in v3:
    -- add synchrons_irq()
    -- add atomic_t suspended
    
    Changes in v4:
    -- correct Fixes's commit ID
    -- remove synchrons_irq()
    
    Changes in v5:
    -- revise commit text
    
    Changes in v6:
    -- add event_lock to protect "suspended"
    
    Changes in v7:
    -- delete "suspended" flag
    
    Fixes: 989ebe7bc446 ("drm/msm/dp: do not initialize phy until plugin interrupt received")
    Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Patchwork: https://patchwork.freedesktop.org/patch/486591/
    Link: https://lore.kernel.org/r/1652804494-19650-1-git-send-email-quic_khsieh@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c46fa568926406ac11aad5e2439d35f27815763
Author: David Howells <dhowells@redhat.com>
Date:   Tue May 31 09:30:40 2022 +0100

    afs: Fix infinite loop found by xfstest generic/676
    
    [ Upstream commit 17eabd42560f4636648ad65ba5b20228071e2363 ]
    
    In AFS, a directory is handled as a file that the client downloads and
    parses locally for the purposes of performing lookup and getdents
    operations.  The in-kernel afs filesystem has a number of functions that
    do this.
    
    A directory file is arranged as a series of 2K blocks divided into
    32-byte slots, where a directory entry occupies one or more slots, plus
    each block starts with one or more metadata blocks.
    
    When parsing a block, if the last slots are occupied by a dirent that
    occupies more than a single slot and the file position points at a slot
    that's not the initial one, the logic in afs_dir_iterate_block() that
    skips over it won't advance the file pointer to the end of it.  This
    will cause an infinite loop in getdents() as it will keep retrying that
    block and failing to advance beyond the final entry.
    
    Fix this by advancing the file pointer if the next entry will be beyond
    it when we skip a block.
    
    This was found by the generic/676 xfstest but can also be triggered with
    something like:
    
            ~/xfstests-dev/src/t_readdir_3 /xfstest.test/z 4000 1
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Marc Dionne <marc.dionne@auristor.com>
    Tested-by: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: http://lore.kernel.org/r/165391973497.110268.2939296942213894166.stgit@warthog.procyon.org.uk/
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d7c3b484123ad172707441320aaf0fa5daf46abb
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Mon May 30 18:48:48 2022 +0800

    gpio: pca953x: use the correct register address to do regcache sync
    
    [ Upstream commit 43624eda86c98b0de726d0b6f2516ccc3ef7313f ]
    
    For regcache_sync_region, need to use pca953x_recalc_addr() to get
    the real register address.
    
    Fixes: b76574300504 ("gpio: pca953x: Restore registers after suspend/resume cycle")
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3a88fe1da7628a1c2c535369a52f9e7c256e730
Author: Fabien Parent <fparent@baylibre.com>
Date:   Sun May 29 17:46:13 2022 +0200

    regulator: mt6315-regulator: fix invalid allowed mode
    
    [ Upstream commit 28cbc2d4c54c09a427b18a1604740efb6b2cc2d6 ]
    
    In the binding example, the regulator mode 4 is shown as a valid mode,
    but the driver actually only support mode 0 to 2:
    
    This generates an error in dmesg when copy/pasting the binding example:
    [    0.306080] vbuck1: invalid regulator-allowed-modes element 4
    [    0.307290] vbuck2: invalid regulator-allowed-modes element 4
    
    This commit fixes this error by removing the invalid mode from the
    examples.
    
    Fixes: 977fb5b58469 ("regulator: document binding for MT6315 regulator")
    Signed-off-by: Fabien Parent <fparent@baylibre.com>
    Link: https://lore.kernel.org/r/20220529154613.337559-1-fparent@baylibre.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d14c1eb470347d9449970e0c6955471ae6cd8d8c
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Mon May 23 12:38:14 2022 +0200

    s390/mcck: isolate SIE instruction when setting CIF_MCCK_GUEST flag
    
    [ Upstream commit 29ccaa4b35ea874ddd50518e5c2c746b9238a792 ]
    
    Commit d768bd892fc8 ("s390: add options to change branch prediction
    behaviour for the kernel") introduced .Lsie_exit label - supposedly
    to fence off SIE instruction. However, the corresponding address
    range length .Lsie_crit_mcck_length was not updated, which led to
    BPON code potentionally marked with CIF_MCCK_GUEST flag.
    
    Both .Lsie_exit and .Lsie_crit_mcck_length were removed with commit
    0b0ed657fe00 ("s390: remove critical section cleanup from entry.S"),
    but the issue persisted - currently BPOFF and BPENTER macros might
    get wrongly considered by the machine check handler as a guest.
    
    Fixes: d768bd892fc8 ("s390: add options to change branch prediction behaviour for the kernel")
    Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
    Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78933cbc143b82d02330e00900d2fd08f2682f4e
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Tue May 31 15:45:00 2022 +0800

    macsec: fix UAF bug for real_dev
    
    [ Upstream commit 196a888ca6571deb344468e1d7138e3273206335 ]
    
    Create a new macsec device but not get reference to real_dev. That can
    not ensure that real_dev is freed after macsec. That will trigger the
    UAF bug for real_dev as following:
    
    ==================================================================
    BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662
    Call Trace:
     ...
     macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662
     dev_get_iflink+0x73/0xe0 net/core/dev.c:637
     default_operstate net/core/link_watch.c:42 [inline]
     rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54
     linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161
    
    Allocated by task 22209:
     ...
     alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549
     rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235
     veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748
    
    Freed by task 8:
     ...
     kfree+0xd6/0x4d0 mm/slub.c:4552
     kvfree+0x42/0x50 mm/util.c:615
     device_release+0x9f/0x240 drivers/base/core.c:2229
     kobject_cleanup lib/kobject.c:673 [inline]
     kobject_release lib/kobject.c:704 [inline]
     kref_put include/linux/kref.h:65 [inline]
     kobject_put+0x1c8/0x540 lib/kobject.c:721
     netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327
    
    After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")
    and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we
    can add dev_hold_track() in macsec_dev_init() and dev_put_track() in
    macsec_free_netdev() to fix the problem.
    
    Fixes: 2bce1ebed17d ("macsec: fix refcnt leak in module exit routine")
    Reported-by: syzbot+d0e94b65ac259c29ce7a@syzkaller.appspotmail.com
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Link: https://lore.kernel.org/r/20220531074500.1272846-1-william.xuanziyang@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96edf985abdece3717969082b13173b3307c774e
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 31 10:28:45 2022 +0300

    octeontx2-af: fix error code in is_valid_offset()
    
    [ Upstream commit f3d671c711097a133bc36bd2bde52f1fcca783a6 ]
    
    The is_valid_offset() function returns success/true if the call to
    validate_and_get_cpt_blkaddr() fails.
    
    Fixes: ecad2ce8c48f ("octeontx2-af: cn10k: Add mailbox to configure reassembly timeout")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YpXDrTPb8qV01JSP@kili
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9901e67572c7a19a268c6899532d4344d666efdc
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue May 24 13:55:57 2022 +0800

    vdpa: ifcvf: set pci driver data in probe
    
    [ Upstream commit bd8bb9aed56b1814784a975e2dfea12a9adcee92 ]
    
    We should set the pci driver data in probe instead of the vdpa device
    adding callback. Otherwise if no vDPA device is created we will lose
    the pointer to the management device.
    
    Fixes: 6b5df347c6482 ("vDPA/ifcvf: implement management netlink framework for ifcvf")
    Tested-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Message-Id: <20220524055557.1938-1-jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bdc28a8fb43cc476e33b11519235adb816ce00e8
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 30 14:37:13 2022 -0700

    tcp: tcp_rtx_synack() can be called from process context
    
    [ Upstream commit 0a375c822497ed6ad6b5da0792a12a6f1af10c0b ]
    
    Laurent reported the enclosed report [1]
    
    This bug triggers with following coditions:
    
    0) Kernel built with CONFIG_DEBUG_PREEMPT=y
    
    1) A new passive FastOpen TCP socket is created.
       This FO socket waits for an ACK coming from client to be a complete
       ESTABLISHED one.
    2) A socket operation on this socket goes through lock_sock()
       release_sock() dance.
    3) While the socket is owned by the user in step 2),
       a retransmit of the SYN is received and stored in socket backlog.
    4) At release_sock() time, the socket backlog is processed while
       in process context.
    5) A SYNACK packet is cooked in response of the SYN retransmit.
    6) -> tcp_rtx_synack() is called in process context.
    
    Before blamed commit, tcp_rtx_synack() was always called from BH handler,
    from a timer handler.
    
    Fix this by using TCP_INC_STATS() & NET_INC_STATS()
    which do not assume caller is in non preemptible context.
    
    [1]
    BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180
    caller is tcp_rtx_synack.part.0+0x36/0xc0
    CPU: 10 PID: 2180 Comm: epollpep Tainted: G           OE     5.16.0-0.bpo.4-amd64 #1  Debian 5.16.12-1~bpo11+1
    Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021
    Call Trace:
     <TASK>
     dump_stack_lvl+0x48/0x5e
     check_preemption_disabled+0xde/0xe0
     tcp_rtx_synack.part.0+0x36/0xc0
     tcp_rtx_synack+0x8d/0xa0
     ? kmem_cache_alloc+0x2e0/0x3e0
     ? apparmor_file_alloc_security+0x3b/0x1f0
     inet_rtx_syn_ack+0x16/0x30
     tcp_check_req+0x367/0x610
     tcp_rcv_state_process+0x91/0xf60
     ? get_nohz_timer_target+0x18/0x1a0
     ? lock_timer_base+0x61/0x80
     ? preempt_count_add+0x68/0xa0
     tcp_v4_do_rcv+0xbd/0x270
     __release_sock+0x6d/0xb0
     release_sock+0x2b/0x90
     sock_setsockopt+0x138/0x1140
     ? __sys_getsockname+0x7e/0xc0
     ? aa_sk_perm+0x3e/0x1a0
     __sys_setsockopt+0x198/0x1e0
     __x64_sys_setsockopt+0x21/0x30
     do_syscall_64+0x38/0xc0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Laurent Fasnacht <laurent.fasnacht@proton.ch>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Link: https://lore.kernel.org/r/20220530213713.601888-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3119910a6b3c154e2f87f9e174e08ec8b1ba774
Author: Guoju Fang <gjfang@linux.alibaba.com>
Date:   Sat May 28 18:16:28 2022 +0800

    net: sched: add barrier to fix packet stuck problem for lockless qdisc
    
    [ Upstream commit 2e8728c955ce0624b958eee6e030a37aca3a5d86 ]
    
    In qdisc_run_end(), the spin_unlock() only has store-release semantic,
    which guarantees all earlier memory access are visible before it. But
    the subsequent test_bit() has no barrier semantics so may be reordered
    ahead of the spin_unlock(). The store-load reordering may cause a packet
    stuck problem.
    
    The concurrent operations can be described as below,
             CPU 0                      |          CPU 1
       qdisc_run_end()                  |     qdisc_run_begin()
              .                         |           .
     ----> /* may be reorderd here */   |           .
    |         .                         |           .
    |     spin_unlock()                 |         set_bit()
    |         .                         |         smp_mb__after_atomic()
     ---- test_bit()                    |         spin_trylock()
              .                         |          .
    
    Consider the following sequence of events:
        CPU 0 reorder test_bit() ahead and see MISSED = 0
        CPU 1 calls set_bit()
        CPU 1 calls spin_trylock() and return fail
        CPU 0 executes spin_unlock()
    
    At the end of the sequence, CPU 0 calls spin_unlock() and does nothing
    because it see MISSED = 0. The skb on CPU 1 has beed enqueued but no one
    take it, until the next cpu pushing to the qdisc (if ever ...) will
    notice and dequeue it.
    
    This patch fix this by adding one explicit barrier. As spin_unlock() and
    test_bit() ordering is a store-load ordering, a full memory barrier
    smp_mb() is needed here.
    
    Fixes: a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc")
    Signed-off-by: Guoju Fang <gjfang@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20220528101628.120193-1-gjfang@linux.alibaba.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bcf5e89e19b6c595531e2039884535fdd588d919
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date:   Mon May 23 15:39:13 2022 +0300

    net/mlx5e: Update netdev features after changing XDP state
    
    [ Upstream commit f6279f113ad593971999c877eb69dc3d36a75894 ]
    
    Some features (LRO, HW GRO) conflict with XDP. If there is an attempt to
    enable such features while XDP is active, they will be set to `off
    [requested on]`. In order to activate these features after XDP is turned
    off, the driver needs to call netdev_update_features(). This commit adds
    this missing call after XDP state changes.
    
    Fixes: cf6e34c8c22f ("net/mlx5e: Properly block LRO when XDP is enabled")
    Fixes: b0617e7b3500 ("net/mlx5e: Properly block HW GRO when XDP is enabled")
    Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68f16c84a6cae1be6d990c96493f9cad76967579
Author: Changcheng Liu <jerrliu@nvidia.com>
Date:   Tue Apr 26 21:28:14 2022 +0800

    net/mlx5: correct ECE offset in query qp output
    
    [ Upstream commit 3fc2a9e89b3508a5cc0c324f26d7b4740ba8c456 ]
    
    ECE field should be after opt_param_mask in query qp output.
    
    Fixes: 6b646a7e4af6 ("net/mlx5: Add ability to read and write ECE options")
    Signed-off-by: Changcheng Liu <jerrliu@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bea6bd8dadb7803a15414539d412cb0cb66f90cd
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date:   Fri Apr 15 16:19:15 2022 +0300

    net/mlx5e: Disable softirq in mlx5e_activate_rq to avoid race condition
    
    [ Upstream commit 2e642afb61b24401a7ec819d27ddcd69c7c29784 ]
    
    When the driver activates the channels, it assumes NAPI isn't running
    yet. mlx5e_activate_rq posts a NOP WQE to ICOSQ to trigger a hardware
    interrupt and start NAPI, which will run mlx5e_alloc_rx_mpwqe and post
    UMR WQEs to ICOSQ to be able to receive packets with striding RQ.
    
    Unfortunately, a race condition is possible if NAPI is triggered by
    something else (for example, TX) at a bad timing, before
    mlx5e_activate_rq finishes. In this case, mlx5e_alloc_rx_mpwqe may post
    UMR WQEs to ICOSQ, and with the bad timing, the wqe_info of the first
    UMR may be overwritten by the wqe_info of the NOP posted by
    mlx5e_activate_rq.
    
    The consequence is that icosq->db.wqe_info[0].num_wqebbs will be changed
    from MLX5E_UMR_WQEBBS to 1, disrupting the integrity of the array-based
    linked list in wqe_info[]. mlx5e_poll_ico_cq will hang in an infinite
    loop after processing wqe_info[0], because after the corruption, the
    next item to be processed will be wqe_info[1], which is filled with
    zeros, and `sqcc += wi->num_wqebbs` will never move further.
    
    This commit fixes this race condition by using async_icosq to post the
    NOP and trigger the interrupt. async_icosq is always protected with a
    spinlock, eliminating the race condition.
    
    Fixes: bc77b240b3c5 ("net/mlx5e: Add fragmented memory support for RX multi packet WQE")
    Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
    Reported-by: Karsten Nielsen <karsten@foo-bar.dk>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Gal Pressman <gal@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdd1d5c5e970435dd5573eef25a8f2a614247ce3
Author: Paul Blakey <paulb@nvidia.com>
Date:   Mon May 23 19:12:21 2022 +0300

    net/mlx5: CT: Fix header-rewrite re-use for tupels
    
    [ Upstream commit 1f2856cde64baa78475e6d3c601fb7b7f693a161 ]
    
    Tuple entries that don't have nat configured for them
    which are added to the ct nat table will always create
    a new modify header, as we don't check for possible
    re-use on them. The same for tuples that have nat configured
    for them but are added to ct table.
    
    Fix the above by only avoiding wasteful re-use lookup
    for actually natted entries in ct nat table.
    
    Fixes: 7fac5c2eced3 ("net/mlx5: CT: Avoid reusing modify header context for natted entries")
    Signed-off-by: Paul Blakey <paulb@nvidia.com>
    Reviewed-by: Ariel Levkovich <lariel@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18d1864ffff2919648293d11c8403148241f9875
Author: Maor Dickman <maord@nvidia.com>
Date:   Mon May 2 10:51:30 2022 +0300

    net/mlx5e: TC NIC mode, fix tc chains miss table
    
    [ Upstream commit 66cb64e292d21588bdb831f08a7ec0ff04d6380d ]
    
    The cited commit changed promisc table to be created on demand with the
    highest priority in the NIC table replacing the vlan table, this caused
    tc NIC tables miss flow to skip the prmoisc table because it use vlan
    table as miss table.
    
    OVS offload in NIC mode use promisc by default so any unicast packet
    which will be handled by tc NIC tables miss flow will skip the promisc
    rule and will be dropped.
    
    Fix this by adding new empty table in new tc level with low priority and
    point the nic tc chain miss to it, the new table is managed so it will
    point to vlan table if promisc is disabled and to promisc table if enabled.
    
    Fixes: 1c46d7409f30 ("net/mlx5e: Optimize promiscuous mode")
    Signed-off-by: Maor Dickman <maord@nvidia.com>
    Reviewed-by: Paul Blakey <paulb@nvidia.com>
    Reviewed-by: Ariel Levkovich <lariel@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3c8a86e4205ee217f9a31d9ca837d408d7e67bd
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue May 24 15:59:27 2022 +0300

    net/mlx5: Don't use already freed action pointer
    
    [ Upstream commit 80b2bd737d0e833e6a2b77e482e5a714a79c86a4 ]
    
    The call to mlx5dr_action_destroy() releases "action" memory. That
    pointer is set to miss_action later and generates the following smatch
    error:
    
     drivers/net/ethernet/mellanox/mlx5/core/steering/fs_dr.c:53 set_miss_action()
     warn: 'action' was already freed.
    
    Make sure that the pointer is always valid by setting NULL after destroy.
    
    Fixes: 6a48faeeca10 ("net/mlx5: Add direct rule fs_cmd implementation")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6efb5526a5f3ad94743e5f7ec933e1908e9303eb
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Apr 3 11:11:14 2022 +0200

    virtio: pci: Fix an error handling path in vp_modern_probe()
    
    [ Upstream commit 7a836a2aba09479c8e71fa43249eecc4af945f61 ]
    
    If an error occurs after a successful pci_request_selected_regions() call,
    it should be undone by a corresponding pci_release_selected_regions() call,
    as already done in vp_modern_remove().
    
    Fixes: fd502729fbbf ("virtio-pci: introduce modern device module")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Message-Id: <237109725aad2c3c03d14549f777b1927c84b045.1648977064.git.christophe.jaillet@wanadoo.fr>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bfc70acd49037118084fd50b47953e20b1336c4a
Author: Eli Cohen <elic@nvidia.com>
Date:   Wed May 18 16:37:59 2022 +0300

    vdpa: Fix error logic in vdpa_nl_cmd_dev_get_doit
    
    [ Upstream commit 7a6691f1f89784f775fa0c54be57533445726068 ]
    
    In vdpa_nl_cmd_dev_get_doit(), if the call to genlmsg_reply() fails we
    must not call nlmsg_free() since this is done inside genlmsg_reply().
    
    Fix it.
    
    Fixes: bc0d90ee021f ("vdpa: Enable user to query vdpa device info")
    Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Eli Cohen <elic@nvidia.com>
    Message-Id: <20220518133804.1075129-2-elic@nvidia.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 601c9086845822a6e67fcbcd4b5e659003cb6a06
Author: Haisu Wang <haisuwang@tencent.com>
Date:   Mon May 30 14:40:59 2022 +0800

    blk-mq: do not update io_ticks with passthrough requests
    
    [ Upstream commit b81c14ca14b631aa1abae32fb5ae75b5e9251012 ]
    
    Flush or passthrough requests are not accounted as normal IO in completion.
    To reflect iostat for slow IO, io_ticks is updated when stat show called
    based on inflight numbers.
    It may cause inconsistent io_ticks calculation result.
    
    So do not account non-passthrough request when check inflight.
    
    Fixes: 86d7331299fd ("block: update io_ticks when io hang")
    Signed-off-by: Haisu Wang <haisuwang@tencent.com>
    Reviewed-by: samuelliao <samuelliao@tencent.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220530064059.1120058-1-haisuwang@tencent.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2094fe0ddc5bb66aed0b0d8f1324906f6f14fcdb
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun May 29 07:13:09 2022 -0600

    block: make bioset_exit() fully resilient against being called twice
    
    [ Upstream commit 605f7415ecfb426610195dd6c7577b30592b3369 ]
    
    Most of bioset_exit() is fine being called twice, as it clears the
    various allocations etc when they are freed. The exception is
    bio_alloc_cache_destroy(), which does not clear ->cache when it has
    freed it.
    
    This isn't necessarily a bug, but can be if buggy users does call the
    exit path more then once, or with just a memset() bioset which has
    never been initialized. dm appears to be one such user.
    
    Fixes: be4d234d7aeb ("bio: add allocation cache abstraction")
    Link: https://lore.kernel.org/linux-block/YpK7m+14A+pZKs5k@casper.infradead.org/
    Reported-by: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a7c0b3ef93d1d1dae7b0a85dab3ac6e3ad0ef61
Author: Íñigo Huguet <ihuguet@redhat.com>
Date:   Fri May 27 10:05:29 2022 +0200

    sfc: fix wrong tx channel offset with efx_separate_tx_channels
    
    [ Upstream commit c308dfd1b43ef0d4c3e57b741bb3462eb7a7f4a2 ]
    
    tx_channel_offset is calculated in efx_allocate_msix_channels, but it is
    also calculated again in efx_set_channels because it was originally done
    there, and when efx_allocate_msix_channels was introduced it was
    forgotten to be removed from efx_set_channels.
    
    Moreover, the old calculation is wrong when using
    efx_separate_tx_channels because now we can have XDP channels after the
    TX channels, so n_channels - n_tx_channels doesn't point to the first TX
    channel.
    
    Remove the old calculation from efx_set_channels, and add the
    initialization of this variable if MSI or legacy interrupts are used,
    next to the initialization of the rest of the related variables, where
    it was missing.
    
    Fixes: 3990a8fffbda ("sfc: allocate channels for XDP tx queues")
    Reported-by: Tianhao Zhao <tizhao@redhat.com>
    Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e7e8d5e25dc762b70f9c88ec6b7d451d0816eead
Author: Martin Habets <habetsm.xilinx@gmail.com>
Date:   Fri May 27 10:05:28 2022 +0200

    sfc: fix considering that all channels have TX queues
    
    [ Upstream commit 2e102b53f8a778f872dc137f4c7ac548705817aa ]
    
    Normally, all channels have RX and TX queues, but this is not true if
    modparam efx_separate_tx_channels=1 is used. In that cases, some
    channels only have RX queues and others only TX queues (or more
    preciselly, they have them allocated, but not initialized).
    
    Fix efx_channel_has_tx_queues to return the correct value for this case
    too.
    
    Messages shown at probe time before the fix:
     sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0
     ------------[ cut here ]------------
     netdevice: ens6f0np0: failed to initialise TXQ -1
     WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc]
     [...] stripped
     RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc]
     [...] stripped
     Call Trace:
      efx_init_tx_queue+0xaa/0xf0 [sfc]
      efx_start_channels+0x49/0x120 [sfc]
      efx_start_all+0x1f8/0x430 [sfc]
      efx_net_open+0x5a/0xe0 [sfc]
      __dev_open+0xd0/0x190
      __dev_change_flags+0x1b3/0x220
      dev_change_flags+0x21/0x60
     [...] stripped
    
    Messages shown at remove time before the fix:
     sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues
     sfc 0000:03:00.0 ens6f0np0: failed to flush queues
    
    Fixes: 8700aff08984 ("sfc: fix channel allocation with brute force")
    Reported-by: Tianhao Zhao <tizhao@redhat.com>
    Signed-off-by: Martin Habets <habetsm.xilinx@gmail.com>
    Tested-by: Íñigo Huguet <ihuguet@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e848ffa5d93062758a8c85ef7f715ab8023f1b7
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon May 23 14:43:02 2022 +0200

    block: use bio_queue_enter instead of blk_queue_enter in bio_poll
    
    [ Upstream commit ebd076bf7d5deef488ec7ebc3fdbf781eafae269 ]
    
    We want to have a valid live gendisk to call ->poll and not just a
    request_queue, so call the right helper.
    
    Fixes: 3e08773c3841 ("block: switch polling to be bio based")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220523124302.526186-1-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ad1c25d127d7a9a4873663067ef59d50f29e829
Author: Yu Xiao <yu.xiao@corigine.com>
Date:   Fri May 27 20:24:24 2022 +0200

    nfp: only report pause frame configuration for physical device
    
    [ Upstream commit 0649e4d63420ebc8cbebef3e9d39e12ffc5eb9fa ]
    
    Only report pause frame configuration for physical device. Logical
    port of both PCI PF and PCI VF do not support it.
    
    Fixes: 9fdc5d85a8fe ("nfp: update ethtool reporting of pauseframe control")
    Signed-off-by: Yu Xiao <yu.xiao@corigine.com>
    Signed-off-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5aba0ad44fb4a7fb78c5076c313456de199a3c29
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Apr 5 16:35:38 2022 -0700

    tcp: add accessors to read/set tp->snd_cwnd
    
    [ Upstream commit 40570375356c874b1578e05c1dcc3ff7c1322dbe ]
    
    We had various bugs over the years with code
    breaking the assumption that tp->snd_cwnd is greater
    than zero.
    
    Lately, syzbot reported the WARN_ON_ONCE(!tp->prior_cwnd) added
    in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")
    can trigger, and without a repro we would have to spend
    considerable time finding the bug.
    
    Instead of complaining too late, we want to catch where
    and when tp->snd_cwnd is set to an illegal value.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Suggested-by: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Link: https://lore.kernel.org/r/20220405233538.947344-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d9cc7813420ea52b68714b7f4e250c136c00575
Author: Guangguan Wang <guangguan.wang@linux.alibaba.com>
Date:   Sat May 28 14:54:57 2022 +0800

    net/smc: fixes for converting from "struct smc_cdc_tx_pend **" to "struct smc_wr_tx_pend_priv *"
    
    [ Upstream commit e225c9a5a74b12e9ef8516f30a3db2c7eb866ee1 ]
    
    "struct smc_cdc_tx_pend **" can not directly convert
    to "struct smc_wr_tx_pend_priv *".
    
    Fixes: 2bced6aefa3d ("net/smc: put slot when connection is killed")
    Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e58636e224b40f9603c4330081a6a44a54e9b6c
Author: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Date:   Sat May 28 03:41:32 2022 +0200

    riscv: read-only pages should not be writable
    
    [ Upstream commit 630f972d76d6460235e84e1aa034ee06f9c8c3a9 ]
    
    If EFI pages are marked as read-only,
    we should remove the _PAGE_WRITE flag.
    
    The current code overwrites an unused value.
    
    Fixes: b91540d52a08b ("RISC-V: Add EFI runtime services")
    Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
    Link: https://lore.kernel.org/r/20220528014132.91052-1-heinrich.schuchardt@canonical.com
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdf62c535a9bfd5ff0eef4b91669da39d8abc0c3
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Sat May 21 15:37:46 2022 +0800

    nbd: don't clear 'NBD_CMD_INFLIGHT' flag if request is not completed
    
    [ Upstream commit 2895f1831e911ca87d4efdf43e35eb72a0c7e66e ]
    
    Otherwise io will hung because request will only be completed if the
    cmd has the flag 'NBD_CMD_INFLIGHT'.
    
    Fixes: 07175cb1baf4 ("nbd: make sure request completion won't concurrent")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20220521073749.3146892-4-yukuai3@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 42451da154872d72ae88755d52c15c431e67cb42
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue May 24 16:39:19 2022 +0200

    block: take destination bvec offsets into account in bio_copy_data_iter
    
    [ Upstream commit 403d50341cce6b5481a92eb481e6df60b1f49b55 ]
    
    Appartly bcache can copy into bios that do not just contain fresh
    pages but can have offsets into the bio_vecs.  Restore support for tht
    in bio_copy_data_iter.
    
    Fixes: f8b679a070c5 ("block: rewrite bio_copy_data_iter to use bvec_kmap_local and memcpy_to_bvec")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220524143919.1155501-1-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f53d4b7bcc1a0ee67f42538214d96a49acd5b57
Author: Menglong Dong <imagedong@tencent.com>
Date:   Tue May 24 10:12:27 2022 +0800

    bpf: Fix probe read error in ___bpf_prog_run()
    
    [ Upstream commit caff1fa4118cec4dfd4336521ebd22a6408a1e3e ]
    
    I think there is something wrong with BPF_PROBE_MEM in ___bpf_prog_run()
    in big-endian machine. Let's make a test and see what will happen if we
    want to load a 'u16' with BPF_PROBE_MEM.
    
    Let's make the src value '0x0001', the value of dest register will become
    0x0001000000000000, as the value will be loaded to the first 2 byte of
    DST with following code:
    
      bpf_probe_read_kernel(&DST, SIZE, (const void *)(long) (SRC + insn->off));
    
    Obviously, the value in DST is not correct. In fact, we can compare
    BPF_PROBE_MEM with LDX_MEM_H:
    
      DST = *(SIZE *)(unsigned long) (SRC + insn->off);
    
    If the memory load is done by LDX_MEM_H, the value in DST will be 0x1 now.
    
    And I think this error results in the test case 'test_bpf_sk_storage_map'
    failing:
    
      test_bpf_sk_storage_map:PASS:bpf_iter_bpf_sk_storage_map__open_and_load 0 nsec
      test_bpf_sk_storage_map:PASS:socket 0 nsec
      test_bpf_sk_storage_map:PASS:map_update 0 nsec
      test_bpf_sk_storage_map:PASS:socket 0 nsec
      test_bpf_sk_storage_map:PASS:map_update 0 nsec
      test_bpf_sk_storage_map:PASS:socket 0 nsec
      test_bpf_sk_storage_map:PASS:map_update 0 nsec
      test_bpf_sk_storage_map:PASS:attach_iter 0 nsec
      test_bpf_sk_storage_map:PASS:create_iter 0 nsec
      test_bpf_sk_storage_map:PASS:read 0 nsec
      test_bpf_sk_storage_map:FAIL:ipv6_sk_count got 0 expected 3
      $10/26 bpf_iter/bpf_sk_storage_map:FAIL
    
    The code of the test case is simply, it will load sk->sk_family to the
    register with BPF_PROBE_MEM and check if it is AF_INET6. With this patch,
    now the test case 'bpf_iter' can pass:
    
      $10  bpf_iter:OK
    
    Fixes: 2a02759ef5f8 ("bpf: Add support for BTF pointers to interpreter")
    Signed-off-by: Menglong Dong <imagedong@tencent.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Jiang Biao <benbjiang@tencent.com>
    Reviewed-by: Hao Peng <flyingpeng@tencent.com>
    Cc: Ilya Leoshkevich <iii@linux.ibm.com>
    Link: https://lore.kernel.org/bpf/20220524021228.533216-1-imagedong@tencent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6307ce68cafe88f08f3f91faae93141c7c869593
Author: Song Liu <song@kernel.org>
Date:   Thu May 26 12:16:08 2022 -0700

    selftests/bpf: fix stacktrace_build_id with missing kprobe/urandom_read
    
    [ Upstream commit 59ed76fe2f981bccde37bdddb465f260a96a2404 ]
    
    Kernel function urandom_read is replaced with urandom_read_iter.
    Therefore, kprobe on urandom_read is not working any more:
    
    [root@eth50-1 bpf]# ./test_progs -n 161
    test_stacktrace_build_id:PASS:skel_open_and_load 0 nsec
    libbpf: kprobe perf_event_open() failed: No such file or directory
    libbpf: prog 'oncpu': failed to create kprobe 'urandom_read+0x0' \
            perf event: No such file or directory
    libbpf: prog 'oncpu': failed to auto-attach: -2
    test_stacktrace_build_id:FAIL:attach_tp err -2
    161     stacktrace_build_id:FAIL
    
    Fix this by replacing urandom_read with urandom_read_iter in the test.
    
    Fixes: 1b388e7765f2 ("random: convert to using fops->read_iter()")
    Reported-by: Mykola Lysenko <mykolal@fb.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Acked-by: David Vernet <void@manifault.com>
    Link: https://lore.kernel.org/r/20220526191608.2364049-1-song@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44b9a9b72e6f0e21501f2ecc2c7282a044def4d8
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Fri Mar 25 15:56:43 2022 -0700

    selftests/bpf: fix selftest after random: Urandom_read tracepoint removal
    
    [ Upstream commit 99dea2c664d7bc7e4f6f6947182d0d365165a998 ]
    
    14c174633f34 ("random: remove unused tracepoints") removed all the
    tracepoints from drivers/char/random.c, one of which,
    random:urandom_read, was used by stacktrace_build_id selftest to trigger
    stack trace capture.
    
    Fix breakage by switching to kprobing urandom_read() function.
    
    Suggested-by: Yonghong Song <yhs@fb.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20220325225643.2606-1-andrii@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e27ecf325e51abd06aaefba57a6322a46fa4178b
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Tue May 10 20:31:26 2022 +0800

    ubi: ubi_create_volume: Fix use-after-free when volume creation failed
    
    [ Upstream commit 8c03a1c21d72210f81cb369cc528e3fde4b45411 ]
    
    There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s
    error handling path:
    
      ubi_eba_replace_table(vol, eba_tbl)
        vol->eba_tbl = tbl
    out_mapping:
      ubi_eba_destroy_table(eba_tbl)   // Free 'eba_tbl'
    out_unlock:
      put_device(&vol->dev)
        vol_release
          kfree(tbl->entries)         // UAF
    
    Fix it by removing redundant 'eba_tbl' releasing.
    Fetch a reproducer in [Link].
    
    Fixes: 493cfaeaa0c9b ("mtd: utilize new cdev_device_add helper function")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215965
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 794c698e38d8510ec4ff3e265af32a4350bd6301
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Tue May 10 20:31:24 2022 +0800

    ubi: fastmap: Fix high cpu usage of ubi_bgt by making sure wl_pool not empty
    
    [ Upstream commit d09e9a2bddba6c48e0fddb16c4383172ac593251 ]
    
    There at least 6 PEBs reserved on UBI device:
    1. EBA_RESERVED_PEBS[1]
    2. WL_RESERVED_PEBS[1]
    3. UBI_LAYOUT_VOLUME_EBS[2]
    4. MIN_FASTMAP_RESERVED_PEBS[2]
    
    When all ubi volumes take all their PEBs, there are 3 (EBA_RESERVED_PEBS +
    WL_RESERVED_PEBS + MIN_FASTMAP_RESERVED_PEBS - MIN_FASTMAP_TAKEN_PEBS[1])
    free PEBs. Since commit f9c34bb529975fe ("ubi: Fix producing anchor PEBs")
    and commit 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs considering
    wear level rules") applied, there is only 1 (3 - FASTMAP_ANCHOR_PEBS[1] -
    FASTMAP_NEXT_ANCHOR_PEBS[1]) free PEB to fill pool and wl_pool, after
    filling pool, wl_pool is always empty. So, UBI could be stuck in an
    infinite loop:
    
            ubi_thread         system_wq
    wear_leveling_worker <--------------------------------------------------
      get_peb_for_wl                                                        |
        // fm_wl_pool, used = size = 0                                      |
        schedule_work(&ubi->fm_work)                                        |
                                                                            |
                        update_fastmap_work_fn                              |
                          ubi_update_fastmap                                |
                            ubi_refill_pools                                |
                            // ubi->free_count - ubi->beb_rsvd_pebs < 5     |
                            // wl_pool is not filled with any PEBs          |
                            schedule_erase(old_fm_anchor)                   |
                            ubi_ensure_anchor_pebs                          |
                              __schedule_ubi_work(wear_leveling_worker)     |
                                                                            |
    __erase_worker                                                          |
      ensure_wear_leveling                                                  |
        __schedule_ubi_work(wear_leveling_worker) --------------------------
    
    , which cause high cpu usage of ubi_bgt:
    top - 12:10:42 up 5 min,  2 users,  load average: 1.76, 0.68, 0.27
    Tasks: 123 total,   3 running,  54 sleeping,   0 stopped,   0 zombie
    
      PID USER PR   NI VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
     1589 root 20   0   0      0      0 R  45.0  0.0   0:38.86 ubi_bgt0d
      319 root 20   0   0      0      0 I  15.2  0.0   0:15.29 kworker/0:3-eve
      371 root 20   0   0      0      0 I  14.9  0.0   0:12.85 kworker/3:3-eve
       20 root 20   0   0      0      0 I  11.3  0.0   0:05.33 kworker/1:0-eve
      202 root 20   0   0      0      0 I  11.3  0.0   0:04.93 kworker/2:3-eve
    
    In commit 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs considering
    wear level rules"), there are three key changes:
      1) Choose the fastmap anchor when the most free PEBs are available.
      2) Enable anchor move within the anchor area again as it is useful
         for distributing wear.
      3) Import a candidate fm anchor and check this PEB's erase count during
         wear leveling. If the wear leveling limit is exceeded, use the used
         anchor area PEB with the lowest erase count to replace it.
    
    The anchor candidate can be removed, we can check fm_anchor PEB's erase
    count during wear leveling. Fix it by:
      1) Removing 'fm_next_anchor' and check 'fm_anchor' during wear leveling.
      2) Preferentially filling one free peb into fm_wl_pool in condition of
         ubi->free_count > ubi->beb_rsvd_pebs, then try to reserve enough
         free count for fastmap non anchor pebs after the above prerequisites
         are met.
    Then, there are at least 1 PEB in pool and 1 PEB in wl_pool after calling
    ubi_refill_pools() with all erase works done.
    
    Fetch a reproducer in [Link].
    
    Fixes: 4b68bf9a69d22dd ("ubi: Select fastmap anchor PEBs ... rules")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215407
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf9db013e167bc8fc2ecd7a13ed97a37df0c9dab
Author: Baokun Li <libaokun1@huawei.com>
Date:   Tue Apr 12 17:38:16 2022 +0800

    jffs2: fix memory leak in jffs2_do_fill_super
    
    [ Upstream commit c14adb1cf70a984ed081c67e9d27bc3caad9537c ]
    
    If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns
    an error, we can observe the following kmemleak report:
    
    --------------------------------------------
    unreferenced object 0xffff888105a65340 (size 64):
      comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff859c45e5>] kmem_cache_alloc_trace+0x475/0x8a0
        [<ffffffff86160146>] jffs2_sum_init+0x96/0x1a0
        [<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120
        [<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810
        [<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0
        [...]
    unreferenced object 0xffff8881bd7f0000 (size 65536):
      comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
      hex dump (first 32 bytes):
        bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
        bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
      backtrace:
        [<ffffffff858579ba>] kmalloc_order+0xda/0x110
        [<ffffffff85857a11>] kmalloc_order_trace+0x21/0x130
        [<ffffffff859c2ed1>] __kmalloc+0x711/0x8a0
        [<ffffffff86160189>] jffs2_sum_init+0xd9/0x1a0
        [<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120
        [<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810
        [<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0
        [...]
    --------------------------------------------
    
    This is because the resources allocated in jffs2_sum_init() are not
    released. Call jffs2_sum_exit() to release these resources to solve
    the problem.
    
    Fixes: e631ddba5887 ("[JFFS2] Add erase block summary support (mount time improvement)")
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 044118d329134111a6cd6a09d5c02ba59c05eccb
Author: Genjian Zhang <zhanggenjian123@gmail.com>
Date:   Tue May 17 15:39:46 2022 +0800

    ep93xx: clock: Do not return the address of the freed memory
    
    [ Upstream commit 8a7322a3a05f75e8a4902bdf8129aecd37d54fe9 ]
    
    Avoid return freed memory addresses,Modified to the actual error
    return value of clk_register().
    
    Fixes: 9645ccc7bd7a ("ep93xx: clock: convert in-place to COMMON_CLK")
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a00a6c738190e94a3d49139c2f805306d886a27a
Author: Alexander Lobakin <alexandr.lobakin@intel.com>
Date:   Tue May 24 17:27:18 2022 +0200

    modpost: fix removing numeric suffixes
    
    [ Upstream commit b5beffa20d83c4e15306c991ffd00de0d8628338 ]
    
    With the `-z unique-symbol` linker flag or any similar mechanism,
    it is possible to trigger the following:
    
    ERROR: modpost: "param_set_uint.0" [vmlinux] is a static EXPORT_SYMBOL
    
    The reason is that for now the condition from remove_dot():
    
    if (m && (s[n + m] == '.' || s[n + m] == 0))
    
    which was designed to test if it's a dot or a '\0' after the suffix
    is never satisfied.
    This is due to that `s[n + m]` always points to the last digit of a
    numeric suffix, not on the symbol next to it (from a custom debug
    print added to modpost):
    
    param_set_uint.0, s[n + m] is '0', s[n + m + 1] is '\0'
    
    So it's off-by-one and was like that since 2014.
    
    Fix this for the sake of any potential upcoming features, but don't
    bother stable-backporting, as it's well hidden -- apart from that
    LD flag, it can be triggered only with GCC LTO which never landed
    upstream.
    
    Fixes: fcd38ed0ff26 ("scripts: modpost: fix compilation warning")
    Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e0d763d0c7665c7897e4f5a0847ab0c82543345f
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu May 26 18:52:08 2022 +0400

    net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register
    
    [ Upstream commit 02ded5a173619b11728b8bf75a3fd995a2c1ff28 ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when done.
    
    mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().
    We don't need the device node after it.
    
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78aca10a16f001c9f49f1cc4dadfee8d444bb173
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu May 26 12:52:08 2022 +0400

    net: ethernet: ti: am65-cpsw-nuss: Fix some refcount leaks
    
    [ Upstream commit 5dd89d2fc438457811cbbec07999ce0d80051ff5 ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    am65_cpsw_init_cpts() and am65_cpsw_nuss_probe() don't release
    the refcount in error case.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: b1f66a5bee07 ("net: ethernet: ti: am65-cpsw-nuss: enable packet timestamping support")
    Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4cde554c70d7397cfa2e4116bacb4accdfb6fd48
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu May 26 11:02:42 2022 +0300

    net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry()
    
    [ Upstream commit e7e7104e2d5ddf3806a28695670f21bef471f1e1 ]
    
    The "fsp->location" variable comes from user via ethtool_get_rxnfc().
    Check that it is valid to prevent an out of bounds read.
    
    Fixes: 7aab747e5563 ("net: ethernet: mediatek: add ethtool functions to configure RX flows of HW LRO")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0db2dcc639cff0955ad64330c86752b8efb3bc72
Author: Vincent Ray <vray@kalrayinc.com>
Date:   Wed May 25 17:17:46 2022 -0700

    net: sched: fixed barrier to prevent skbuff sticking in qdisc backlog
    
    [ Upstream commit a54ce3703613e41fe1d98060b62ec09a3984dc28 ]
    
    In qdisc_run_begin(), smp_mb__before_atomic() used before test_bit()
    does not provide any ordering guarantee as test_bit() is not an atomic
    operation. This, added to the fact that the spin_trylock() call at
    the beginning of qdisc_run_begin() does not guarantee acquire
    semantics if it does not grab the lock, makes it possible for the
    following statement :
    
    if (test_bit(__QDISC_STATE_MISSED, &qdisc->state))
    
    to be executed before an enqueue operation called before
    qdisc_run_begin().
    
    As a result the following race can happen :
    
               CPU 1                             CPU 2
    
          qdisc_run_begin()               qdisc_run_begin() /* true */
            set(MISSED)                            .
          /* returns false */                      .
              .                            /* sees MISSED = 1 */
              .                            /* so qdisc not empty */
              .                            __qdisc_run()
              .                                    .
              .                              pfifo_fast_dequeue()
     ----> /* may be done here */                  .
    |         .                                clear(MISSED)
    |         .                                    .
    |         .                                smp_mb __after_atomic();
    |         .                                    .
    |         .                                /* recheck the queue */
    |         .                                /* nothing => exit   */
    |   enqueue(skb1)
    |         .
    |   qdisc_run_begin()
    |         .
    |     spin_trylock() /* fail */
    |         .
    |     smp_mb__before_atomic() /* not enough */
    |         .
     ---- if (test_bit(MISSED))
            return false;   /* exit */
    
    In the above scenario, CPU 1 and CPU 2 both try to grab the
    qdisc->seqlock at the same time. Only CPU 2 succeeds and enters the
    bypass code path, where it emits its skb then calls __qdisc_run().
    
    CPU1 fails, sets MISSED and goes down the traditionnal enqueue() +
    dequeue() code path. But when executing qdisc_run_begin() for the
    second time, after enqueuing its skbuff, it sees the MISSED bit still
    set (by itself) and consequently chooses to exit early without setting
    it again nor trying to grab the spinlock again.
    
    Meanwhile CPU2 has seen MISSED = 1, cleared it, checked the queue
    and found it empty, so it returned.
    
    At the end of the sequence, we end up with skb1 enqueued in the
    backlog, both CPUs out of __dev_xmit_skb(), the MISSED bit not set,
    and no __netif_schedule() called made. skb1 will now linger in the
    qdisc until somebody later performs a full __qdisc_run(). Associated
    to the bypass capacity of the qdisc, and the ability of the TCP layer
    to avoid resending packets which it knows are still in the qdisc, this
    can lead to serious traffic "holes" in a TCP connection.
    
    We fix this by replacing the smp_mb__before_atomic() / test_bit() /
    set_bit() / smp_mb__after_atomic() sequence inside qdisc_run_begin()
    by a single test_and_set_bit() call, which is more concise and
    enforces the needed memory barriers.
    
    Fixes: 89837eb4b246 ("net: sched: add barrier to ensure correct ordering for lockless qdisc")
    Signed-off-by: Vincent Ray <vray@kalrayinc.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20220526001746.2437669-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 73337dd9fbf33c84c9180e90498fa1d89fab1292
Author: Michael Walle <michael@walle.cc>
Date:   Thu May 26 01:12:39 2022 +0200

    net: lan966x: check devm_of_phy_get() for -EDEFER_PROBE
    
    [ Upstream commit b58cdd4388b1d8f5bee9f5a3897a7e780d1eaa48 ]
    
    At the moment, if devm_of_phy_get() returns an error the serdes
    simply isn't set. While it is bad to ignore an error in general, there
    is a particular bug that network isn't working if the serdes driver is
    compiled as a module. In that case, devm_of_phy_get() returns
    -EDEFER_PROBE and the error is silently ignored.
    
    The serdes is optional, it is not there if the port is using RGMII, in
    which case devm_of_phy_get() returns -ENODEV. Rearrange the error
    handling so that -ENODEV will be handled but other error codes will
    abort the probing.
    
    Fixes: d28d6d2e37d1 ("net: lan966x: add port module support")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Link: https://lore.kernel.org/r/20220525231239.1307298-1-michael@walle.cc
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0808b7a04157b3f56e919f27023fec37a075fad
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon May 16 10:05:48 2022 +0300

    drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq()
    
    [ Upstream commit a35faec3db0e13aac8ea720bc1a3503081dd5a3d ]
    
    The > ARRAY_SIZE() should be >= ARRAY_SIZE() to prevent an out of bounds
    access.
    
    Fixes: e27c41d5b068 ("drm/amd/display: Support for DMUB HPD interrupt handling")
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7dbe01147417ef46d6c8db34e22e754ebf627ba8
Author: Eddie James <eajames@linux.ibm.com>
Date:   Wed May 25 11:58:51 2022 -0500

    spi: fsi: Fix spurious timeout
    
    [ Upstream commit 61bf40ef51aa73f6216b33563271b6acf7ea8d70 ]
    
    The driver may return a timeout error even if the status register
    indicates that the transfer may proceed. Fix this by restructuring
    the polling loop.
    
    Fixes: 89b35e3f2851 ("spi: fsi: Implement a timeout for polling status")
    Signed-off-by: Eddie James <eajames@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220525165852.33167-2-eajames@linux.ibm.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4057803a84112ffd17535fa535d74bf69c3b969
Author: liuyacan <liuyacan@corp.netease.com>
Date:   Wed May 25 16:54:08 2022 +0800

    net/smc: set ini->smcrv2.ib_dev_v2 to NULL if SMC-Rv2 is unavailable
    
    [ Upstream commit b3b1a17538d3ef6a9667b2271216fd16d7678ab5 ]
    
    In the process of checking whether RDMAv2 is available, the current
    implementation first sets ini->smcrv2.ib_dev_v2, and then allocates
    smc buf desc and register rmb, but the latter may fail. In this case,
    the pointer should be reset.
    
    Fixes: e49300a6bf62 ("net/smc: add listen processing for SMC-Rv2")
    Signed-off-by: liuyacan <liuyacan@corp.netease.com>
    Reviewed-by: Karsten Graul <kgraul@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220525085408.812273-1-liuyacan@corp.netease.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60d9c020c69977e138727b3577bc6a0458325e9c
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon May 23 16:17:08 2022 +0000

    amt: fix possible memory leak in amt_rcv()
    
    [ Upstream commit 1a1a0e80e005cbdc2c250fc858e1d8570f4e4acb ]
    
    If an amt receives packets and it finds socket.
    If it can't find a socket, it should free a received skb.
    But it doesn't.
    So, a memory leak would possibly occur.
    
    Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec6feb113abe511bbe054e8c47e2c94b6b961f94
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Mon May 23 16:17:07 2022 +0000

    amt: fix return value of amt_update_handler()
    
    [ Upstream commit ac1dbf55981b88d64312858ea06e3e63001f085d ]
    
    If a relay receives an update message, it lookup a tunnel.
    and if there is no tunnel for that message, it should be treated
    as an error, not a success.
    But amt_update_handler() returns false, which means success.
    
    Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 61f26d00c08da139b03e686452c43fdf838370ef
Author: Jann Horn <jannh@google.com>
Date:   Tue May 17 16:30:47 2022 +0200

    s390/crypto: fix scatterwalk_unmap() callers in AES-GCM
    
    [ Upstream commit bd52cd5e23f134019b23f0c389db0f9a436e4576 ]
    
    The argument of scatterwalk_unmap() is supposed to be the void* that was
    returned by the previous scatterwalk_map() call.
    The s390 AES-GCM implementation was instead passing the pointer to the
    struct scatter_walk.
    
    This doesn't actually break anything because scatterwalk_unmap() only uses
    its argument under CONFIG_HIGHMEM and ARCH_HAS_FLUSH_ON_KUNMAP.
    
    Fixes: bf7fa038707c ("s390/crypto: add s390 platform specific aes gcm support.")
    Signed-off-by: Jann Horn <jannh@google.com>
    Acked-by: Harald Freudenberger <freude@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220517143047.3054498-1-jannh@google.com
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a95d03cdb2de8540cbf49608457378e7d1db29a1
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Apr 22 12:41:01 2022 +0200

    clocksource/drivers/oxnas-rps: Fix irq_of_parse_and_map() return value
    
    [ Upstream commit 9c04a8ff03def4df3f81219ffbe1ec9b44ff5348 ]
    
    The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO.
    
    Fixes: 89355274e1f7 ("clocksource/drivers/oxnas-rps: Add Oxford Semiconductor RPS Dual Timer")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
    Link: https://lore.kernel.org/r/20220422104101.55754-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5be67427bcc1f942275a04291fb9de1b07d329c
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date:   Mon May 23 13:44:21 2022 +0800

    ASoC: fsl_sai: Fix FSL_SAI_xDR/xFR definition
    
    [ Upstream commit e4dd748dc87cf431af7b3954963be0d9f6150217 ]
    
    There are multiple xDR and xFR registers, the index is
    from 0 to 7. FSL_SAI_xDR and FSL_SAI_xFR is abandoned,
    replace them with FSL_SAI_xDR0 and FSL_SAI_xFR0.
    
    Fixes: 4f7a0728b530 ("ASoC: fsl_sai: Add support for SAI new version")
    Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
    Link: https://lore.kernel.org/r/1653284661-18964-1-git-send-email-shengjiu.wang@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b140bac470b4f707cda59c7266214246238661df
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sun May 22 20:23:50 2022 +0800

    blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx
    
    [ Upstream commit 5d05426e2d5fd7df8afc866b78c36b37b00188b7 ]
    
    blk_mq_run_hw_queues() could be run when there isn't queued request and
    after queue is cleaned up, at that time tagset is freed, because tagset
    lifetime is covered by driver, and often freed after blk_cleanup_queue()
    returns.
    
    So don't touch ->tagset for figuring out current default hctx by the mapping
    built in request queue, so use-after-free on tagset can be avoided. Meantime
    this way should be fast than retrieving mapping from tagset.
    
    Cc: "yukuai (C)" <yukuai3@huawei.com>
    Cc: Jan Kara <jack@suse.cz>
    Fixes: b6e68ee82585 ("blk-mq: Improve performance of non-mq IO schedulers with multiple HW queues")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220522122350.743103-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91fa5aa53f68b85e779164b3127c7e23cad5c457
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed May 11 15:42:03 2022 +0400

    watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe
    
    [ Upstream commit 5d24df3d690809952528e7a19a43d84bc5b99d44 ]
    
    of_parse_phandle() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when done.
    Add  missing of_node_put() in some error paths.
    
    Fixes: bf9006399939 ("watchdog: ts4800: add driver for TS-4800 watchdog")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220511114203.47420-1-linmq006@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 62bcab8ca85b089dd454803e5b005461cd5745ec
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Apr 12 07:08:23 2022 +0000

    watchdog: rti-wdt: Fix pm_runtime_get_sync() error checking
    
    [ Upstream commit b3ac0c58fa8934926360268f3d89ec7680644d7b ]
    
    If the device is already in a runtime PM enabled state
    pm_runtime_get_sync() will return 1, so a test for negative
    value should be used to check for errors.
    
    Fixes: 2d63908bdbfb ("watchdog: Add K3 RTI watchdog support")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220412070824.23708-1-linmq006@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d53a227bfcd5160ce1b61d9954901968a20651e7
Author: Zhang Wensheng <zhangwensheng5@huawei.com>
Date:   Wed May 18 15:45:16 2022 +0800

    driver core: fix deadlock in __device_attach
    
    [ Upstream commit b232b02bf3c205b13a26dcec08e53baddd8e59ed ]
    
    In __device_attach function, The lock holding logic is as follows:
    ...
    __device_attach
    device_lock(dev)      // get lock dev
      async_schedule_dev(__device_attach_async_helper, dev); // func
        async_schedule_node
          async_schedule_node_domain(func)
            entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
            /* when fail or work limit, sync to execute func, but
               __device_attach_async_helper will get lock dev as
               well, which will lead to A-A deadlock.  */
            if (!entry || atomic_read(&entry_count) > MAX_WORK) {
              func;
            else
              queue_work_node(node, system_unbound_wq, &entry->work)
      device_unlock(dev)
    
    As shown above, when it is allowed to do async probes, because of
    out of memory or work limit, async work is not allowed, to do
    sync execute instead. it will lead to A-A deadlock because of
    __device_attach_async_helper getting lock dev.
    
    To fix the deadlock, move the async_schedule_dev outside device_lock,
    as we can see, in async_schedule_node_domain, the parameter of
    queue_work_node is system_unbound_wq, so it can accept concurrent
    operations. which will also not change the code logic, and will
    not lead to deadlock.
    
    Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers")
    Signed-off-by: Zhang Wensheng <zhangwensheng5@huawei.com>
    Link: https://lore.kernel.org/r/20220518074516.1225580-1-zhangwensheng5@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5389101257828d1913d713d9a40acbe14f5961df
Author: Schspa Shi <schspa@gmail.com>
Date:   Fri May 13 19:24:44 2022 +0800

    driver: base: fix UAF when driver_attach failed
    
    [ Upstream commit 310862e574001a97ad02272bac0fd13f75f42a27 ]
    
    When driver_attach(drv); failed, the driver_private will be freed.
    But it has been added to the bus, which caused a UAF.
    
    To fix it, we need to delete it from the bus when failed.
    
    Fixes: 190888ac01d0 ("driver core: fix possible missing of device probe")
    Signed-off-by: Schspa Shi <schspa@gmail.com>
    Link: https://lore.kernel.org/r/20220513112444.45112-1-schspa@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0efa0391b72230a2877de6deca98f38eddadc5a1
Author: Tony Lindgren <tony@atomide.com>
Date:   Thu May 12 08:30:21 2022 +0300

    bus: ti-sysc: Fix warnings for unbind for serial
    
    [ Upstream commit c337125b8834f9719dfda0e40b25eaa266f1b8cf ]
    
    We can get "failed to disable" clock_unprepare warnings on unbind at least
    for the serial console device if the unbind is done before the device has
    been idled.
    
    As some devices are using deferred idle, we must check the status for
    pending idle work to idle the device.
    
    Fixes: 76f0f772e469 ("bus: ti-sysc: Improve handling for no-reset-on-init and no-idle-on-init")
    Cc: Romain Naour <romain.naour@smile.fr>
    Reviewed-by: Romain Naour <romain.naour@smile.fr>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20220512053021.61650-1-tony@atomide.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ba359ebe914ac3f8c6c832b28007c14c39d3766
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed May 11 11:14:19 2022 +0400

    firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle
    
    [ Upstream commit 660ba678f9998aca6db74f2dd912fa5124f0fa31 ]
    
    kobject_init_and_add() takes reference even when it fails.
    According to the doc of kobject_init_and_add()
    
       If this function returns an error, kobject_put() must be called to
       properly clean up the memory associated with the object.
    
    Fix this issue by calling kobject_put().
    
    Fixes: 948af1f0bbc8 ("firmware: Basic dmi-sysfs support")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220511071421.9769-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27edfc4a970cc6c5750d21c3703c48b3d28c0eef
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:07 2022 +0300

    serial: stm32-usart: Correct CSIZE, bits, and parity
    
    [ Upstream commit 1deeda8d2877c18bc2b9eeee10dd6d2628852848 ]
    
    Add CSIZE sanitization for unsupported CSIZE configurations. In
    addition, if parity is asked for but CSx was unsupported, the sensible
    result is CS8+parity which requires setting USART_CR1_M0 like with 9
    bits.
    
    Incorrect CSIZE results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: c8a9d043947b (serial: stm32: fix word length configuration)
    Cc: Erwan Le Ray <erwan.leray@st.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-9-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b5a7b222d7560773a304469ee774e3515863229
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:06 2022 +0300

    serial: st-asc: Sanitize CSIZE and correct PARENB for CS7
    
    [ Upstream commit 52bb1cb7118564166b04d52387bd8403632f5190 ]
    
    Only CS7 and CS8 seem supported but CSIZE is not sanitized from CS5 or
    CS6 to CS8. In addition, ASC_CTL_MODE_7BIT_PAR suggests that CS7 has
    to have parity, thus add PARENB.
    
    Incorrect CSIZE results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: c4b058560762 (serial:st-asc: Add ST ASC driver.)
    Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-8-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df6c3ce4efd1f7d3782499ea8e304e22e4089a8c
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:05 2022 +0300

    serial: sifive: Sanitize CSIZE and c_iflag
    
    [ Upstream commit c069d2756c01ed36121fae6a42c14fdf1325c71d ]
    
    Only CS8 is supported but CSIZE was not sanitized to CS8.
    
    Set CSIZE correctly so that userspace knows the effective value.
    Incorrect CSIZE also results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Similarly, INPCK, PARMRK, and BRKINT are reported textually unsupported
    but were not cleared in termios c_iflag which is the machine-readable
    format.
    
    Fixes: 45c054d0815b (tty: serial: add driver for the SiFive UART)
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-7-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 28639d20ef553335b1aa8047989c7035bab13ab5
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:04 2022 +0300

    serial: sh-sci: Don't allow CS5-6
    
    [ Upstream commit 9b87162de8be26bf3156460b37deee6399fd0fcb ]
    
    Only CS7 and CS8 seem supported but CSIZE is not sanitized from
    CS5 or CS6 to CS8.
    
    Set CSIZE correctly so that userspace knows the effective value.
    Incorrect CSIZE also results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: 1da177e4c3f4 (Linux-2.6.12-rc2)
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-6-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 520a10a7806869b3abf2be55265f01ba8add395d
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:03 2022 +0300

    serial: txx9: Don't allow CS5-6
    
    [ Upstream commit 79ac88655dc0551e3571ad16bdabdbe65d61553e ]
    
    Only CS7 and CS8 are supported but CSIZE is not sanitized with
    CS5 or CS6 to CS8.
    
    Set CSIZE correctly so that userspace knows the effective value.
    Incorrect CSIZE also results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: 1da177e4c3f4 (Linux-2.6.12-rc2)
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-5-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cbc1c95a8d4966e28b73fa62f6fd9e8cb4647379
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:02 2022 +0300

    serial: rda-uart: Don't allow CS5-6
    
    [ Upstream commit 098333a9c7d12bb3ce44c82f08b4d810c44d31b0 ]
    
    Only CS7 and CS8 are supported but CSIZE is not sanitized after
    fallthrough from CS5 or CS6 to CS7.
    
    Set CSIZE correctly so that userspace knows the effective value.
    Incorrect CSIZE also results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: c10b13325ced (tty: serial: Add RDA8810PL UART driver)
    Cc: Manivannan Sadhasivam <mani@kernel.org>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-4-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58c1b6be7a28aafe80a62ef744382de901ea4940
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:01 2022 +0300

    serial: digicolor-usart: Don't allow CS5-6
    
    [ Upstream commit fd63031b8c0763addcecdefe0e0c59d49646204e ]
    
    Only CS7 and CS8 seem supported but CSIZE is not sanitized to CS8 in
    the default: block.
    
    Set CSIZE correctly so that userspace knows the effective value.
    Incorrect CSIZE also results in miscalculation of the frame bits in
    tty_get_char_size() or in its predecessor where the roughly the same
    code is directly within uart_update_timeout().
    
    Fixes: 5930cb3511df (serial: driver for Conexant Digicolor USART)
    Acked-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-3-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c44d9583dc7ee0a2612b17d0c8407b2c513d359
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Thu May 19 11:18:00 2022 +0300

    serial: uartlite: Fix BRKINT clearing
    
    [ Upstream commit 3f7fed405c118607d4d42255f2572072db728399 ]
    
    BRKINT is within c_iflag rather than c_cflag.
    
    Fixes: ea017f5853e9 (tty: serial: uartlite: Prevent changing fixed parameters)
    Reviewed-by: Sean Anderson <sean.anderson@seco.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220519081808.3776-2-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd107e3dbf18e9071f3748c37cfc1f9dc9130ddc
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed May 18 21:54:52 2022 +0800

    serial: cpm_uart: Fix build error without CONFIG_SERIAL_CPM_CONSOLE
    
    [ Upstream commit 0258502f11a4f6036b5f8b34b09027c8a92def3a ]
    
    drivers/tty/serial/cpm_uart/cpm_uart_core.c: In function ‘cpm_uart_init_port’:
    drivers/tty/serial/cpm_uart/cpm_uart_core.c:1251:7: error: ‘udbg_port’ undeclared (first use in this function); did you mean ‘uart_port’?
      if (!udbg_port)
           ^~~~~~~~~
           uart_port
    
    commit d142585bceb3 leave this corner, wrap it with #ifdef block
    
    Fixes: d142585bceb3 ("serial: cpm_uart: Protect udbg definitions by CONFIG_SERIAL_CPM_CONSOLE")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Link: https://lore.kernel.org/r/20220518135452.39480-1-yuehaibing@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68310abcd028aca30815dee25202a84723d40a6a
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Fri May 13 16:46:43 2022 +0300

    serial: 8250_fintek: Check SER_RS485_RTS_* only with RS485
    
    [ Upstream commit af0179270977508df6986b51242825d7edd59caf ]
    
    SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND relate to behavior
    within RS485 operation. The driver checks if they have the same value
    which is not possible to realize with the hardware. The check is taken
    regardless of SER_RS485_ENABLED flag and -EINVAL is returned when the
    check fails, which creates problems.
    
    This check makes it unnecessarily complicated to turn RS485 mode off as
    simple zeroed serial_rs485 struct will trigger that equal values check.
    In addition, the driver itself memsets its rs485 structure to zero when
    RS485 is disabled but if userspace would try to make an TIOCSRS485
    ioctl() call with the very same struct, it would end up failing with
    -EINVAL which doesn't make much sense.
    
    Resolve the problem by moving the check inside SER_RS485_ENABLED block.
    
    Fixes: 7ecc77011c6f ("serial: 8250_fintek: Return -EINVAL on invalid configuration")
    Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/035c738-8ea5-8b17-b1d7-84a7b3aeaa51@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0153e67305d4ffde922ba01b2814940e18d52543
Author: John Ogness <john.ogness@linutronix.de>
Date:   Sun May 8 12:41:47 2022 +0206

    serial: meson: acquire port->lock in startup()
    
    [ Upstream commit 589f892ac8ef244e47c5a00ffd8605daa1eaef8e ]
    
    The uart_ops startup() callback is called without interrupts
    disabled and without port->lock locked, relatively late during the
    boot process (from the call path of console_on_rootfs()). If the
    device is a console, it was already previously registered and could
    be actively printing messages.
    
    Since the startup() callback is reading/writing registers used by
    the console write() callback (AML_UART_CONTROL), its access must
    be synchronized using the port->lock. Currently it is not.
    
    The startup() callback is the only function that explicitly enables
    interrupts. Without the synchronization, it is possible that
    interrupts become accidentally permanently disabled.
    
    CPU0                           CPU1
    meson_serial_console_write     meson_uart_startup
    --------------------------     ------------------
    spin_lock(port->lock)
    val = readl(AML_UART_CONTROL)
    uart_console_write()
                                   writel(INT_EN, AML_UART_CONTROL)
    writel(val, AML_UART_CONTROL)
    spin_unlock(port->lock)
    
    Add port->lock synchronization to meson_uart_startup() to avoid
    racing with meson_serial_console_write().
    
    Also add detailed comments to meson_uart_reset() explaining why it
    is *not* using port->lock synchronization.
    
    Link: https://lore.kernel.org/lkml/2a82eae7-a256-f70c-fd82-4e510750906e@samsung.com
    Fixes: ff7693d079e5 ("ARM: meson: serial: add MesonX SoC on-chip uart driver")
    Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Acked-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Link: https://lore.kernel.org/r/20220508103547.626355-1-john.ogness@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ae7bf782eacad803f752c83a183393b0a67127b
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Wed May 18 15:59:57 2022 +0800

    staging: r8188eu: add check for kzalloc
    
    [ Upstream commit f94b47c6bde624d6c07f43054087607c52054a95 ]
    
    As kzalloc() may return null pointer, it should be better to
    check the return value and return error if fails in order
    to avoid dereference of null pointer.
    Moreover, the return value of rtw_alloc_hwxmits() should also
    be dealt with.
    
    Fixes: 15865124feed ("staging: r8188eu: introduce new core dir for RTL8188eu driver")
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20220518075957.514603-1-jiasheng@iscas.ac.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7e22687ec8a6217c40d317eb41a16769fd727be7
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Apr 3 05:49:12 2022 +0000

    rtc: ftrtc010: Fix error handling in ftrtc010_rtc_probe
    
    [ Upstream commit b520cbe5be37b1b9b401c0b6ecbdae32575273db ]
    
    In the error handling path, the clk_prepare_enable() function
    call should be balanced by a corresponding 'clk_disable_unprepare()'
    call , as already done in the remove function.
    
    clk_disable_unprepare calls clk_disable() and clk_unprepare().
    They will use IS_ERR_OR_NULL to check the argument.
    
    Fixes: ac05fba39cc5 ("rtc: gemini: Add optional clock handling")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20220403054912.31739-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58a729c55ce3a432eb827fdaa24c7909cd3b0a6b
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu May 5 20:50:43 2022 +0800

    rtc: mt6397: check return value after calling platform_get_resource()
    
    [ Upstream commit d3b43eb505bffb8e4cdf6800c15660c001553fe6 ]
    
    It will cause null-ptr-deref if platform_get_resource() returns NULL,
    we need check the return value.
    
    Fixes: fc2979118f3f ("rtc: mediatek: Add MT6397 RTC driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20220505125043.1594771-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3208c7447154a3ca744eedfff596eb2926e2e952
Author: Howard Chiu <howard_chiu@aspeedtech.com>
Date:   Fri Apr 1 06:59:06 2022 +0000

    ARM: dts: aspeed: ast2600-evb: Enable RX delay for MAC0/MAC1
    
    [ Upstream commit 4d338ee40ba89e508c5d3e1b4af956af7cb5e12e ]
    
    Since mac0/1 and mac2/3 are physically located on different die,
    they have different properties by nature, which is mac0/1 has smaller delay step.
    
    The property 'phy-mode' on ast2600 mac0 and mac1 is recommended to set to 'rgmii-rxid'
    which enables the RX interface delay from the PHY chip.
    Refer page 45 of SDK User Guide v08.00
    https://github.com/AspeedTech-BMC/openbmc/releases/download/v08.00/SDK_User_Guide_v08.00.pdf
    
    Fixes: 2ca5646b5c2f ("ARM: dts: aspeed: Add AST2600 and EVB")
    Signed-off-by: Howard Chiu <howard_chiu@aspeedtech.com>
    Link: https://lore.kernel.org/r/SG2PR06MB23152A548AAE81140B57DD69E6E09@SG2PR06MB2315.apcprd06.prod.outlook.com
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a54fb777ff3bf47889afca8a35d9fde05414ecc
Author: Samuel Holland <samuel@sholland.org>
Date:   Sun May 8 20:21:21 2022 -0500

    clocksource/drivers/riscv: Events are stopped during CPU suspend
    
    [ Upstream commit 232ccac1bd9b5bfe73895f527c08623e7fa0752d ]
    
    Some implementations of the SBI time extension depend on hart-local
    state (for example, CSRs) that are lost or hardware that is powered
    down when a CPU is suspended. To be safe, the clockevents driver
    cannot assume that timer IRQs will be received during CPU suspend.
    
    Fixes: 62b019436814 ("clocksource: new RISC-V SBI timer driver")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Reviewed-by: Anup Patel <anup@brainfault.org>
    Link: https://lore.kernel.org/r/20220509012121.40031-1-samuel@sholland.org
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 042571fe1d171773655ad706715ecc865913d9a4
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon May 16 11:20:10 2022 +0400

    soc: rockchip: Fix refcount leak in rockchip_grf_init
    
    [ Upstream commit 9b59588d8be91c96bfb0371e912ceb4f16315dbf ]
    
    of_find_matching_node_and_match returns a node pointer with refcount
    incremented, we should use of_node_put() on it when done.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 4c58063d4258 ("soc: rockchip: add driver handling grf setup")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220516072013.19731-1-linmq006@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1530186c83196876e44535192120f5ce6541f6cf
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Wed May 11 15:54:51 2022 -0400

    dt-bindings: remoteproc: mediatek: Make l1tcm reg exclusive to mt819x
    
    [ Upstream commit 6bbe1065121b8cd3b3e734ef8cd99f142bdab241 ]
    
    Commit ca23ecfdbd44 ("remoteproc/mediatek: support L1TCM") added support
    for the l1tcm memory region on the MT8192 SCP, adding a new da_to_va
    callback that handles l1tcm while keeping the old one for
    back-compatibility with MT8183. However, since the mt8192 compatible was
    missing from the dt-binding, the accompanying dt-binding commit
    503c64cc42f1 ("dt-bindings: remoteproc: mediatek: add L1TCM memory region")
    mistakenly added this reg as if it were for mt8183. And later
    it became common to all platforms as their compatibles were added.
    
    Fix the dt-binding so that the l1tcm reg can be present only on the
    supported platforms: mt8192 and mt8195.
    
    Fixes: 503c64cc42f1 ("dt-bindings: remoteproc: mediatek: add L1TCM memory region")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220511195452.871897-2-nfraprado@collabora.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b96e96ead6e74b2e87ebfc461957fc899599a558
Author: Li Jun <jun.li@nxp.com>
Date:   Tue Apr 19 20:44:08 2022 +0800

    extcon: ptn5150: Add queue work sync before driver release
    
    [ Upstream commit 782cd939cbe0f569197cd1c9b0477ee213167f04 ]
    
    Add device managed action to sync pending queue work, otherwise
    the queued work may run after the work is destroyed.
    
    Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver")
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 248d71b440aef829f5cc5f6545ca113ef5062900
Author: Xin Xiong <xiongx18@fudan.edu.cn>
Date:   Fri Apr 29 16:11:22 2022 +0800

    ksmbd: fix reference count leak in smb_check_perm_dacl()
    
    [ Upstream commit d21a580dafc69aa04f46e6099616146a536b0724 ]
    
    The issue happens in a specific path in smb_check_perm_dacl(). When
    "id" and "uid" have the same value, the function simply jumps out of
    the loop without decrementing the reference count of the object
    "posix_acls", which is increased by get_acl() earlier. This may
    result in memory leaks.
    
    Fix it by decreasing the reference count of "posix_acls" before
    jumping to label "check_access_bits".
    
    Fixes: 777cad1604d6 ("ksmbd: remove select FS_POSIX_ACL in Kconfig")
    Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 53cc04f4ca9934291a09c5835f83bcc5b5b43b1f
Author: Guilherme G. Piccoli <gpiccoli@igalia.com>
Date:   Wed Apr 27 19:49:03 2022 -0300

    coresight: cpu-debug: Replace mutex with mutex_trylock on panic notifier
    
    [ Upstream commit 1adff542d67a2ed1120955cb219bfff8a9c53f59 ]
    
    The panic notifier infrastructure executes registered callbacks when
    a panic event happens - such callbacks are executed in atomic context,
    with interrupts and preemption disabled in the running CPU and all other
    CPUs disabled. That said, mutexes in such context are not a good idea.
    
    This patch replaces a regular mutex with a mutex_trylock safer approach;
    given the nature of the mutex used in the driver, it should be pretty
    uncommon being unable to acquire such mutex in the panic path, hence
    no functional change should be observed (and if it is, that would be
    likely a deadlock with the regular mutex).
    
    Fixes: 2227b7c74634 ("coresight: add support for CPU debug module")
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20220427224924.592546-10-gpiccoli@igalia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96b5d2b8138961c9c8ac0ed345b16c1e07ee236f
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Wed Apr 20 10:32:39 2022 +0800

    soundwire: intel: prevent pm_runtime resume prior to system suspend
    
    [ Upstream commit 6d9f2dadba698114fed97b224578c5338a36b0d9 ]
    
    commit e38f9ff63e6d ("ACPI: scan: Do not add device IDs from _CID if _HID is not valid")
    exposes a race condition on a TGL RVP device leading to a timeout.
    
    The detailed analysis shows the RT711 codec driver scheduling a jack
    detection workqueue while attaching during a spurious pm_runtime
    resume, and the work function happens to be scheduled after the
    manager device is suspended.
    
    The direct link between this ACPI patch and a spurious pm_runtime
    resume is not obvious; the most likely explanation is that a change in
    the ACPI device linked list management modifies the order in which the
    pm_runtime device status is checked and exposes a race condition that
    was probably present for a very long time, but was not identified.
    
    We already have a check in the .prepare stage, where we will resume to
    full power from specific clock-stop modes. In all other cases, we
    don't need to resume to full power by default. Adding the
    SMART_SUSPEND flag prevents the spurious resume from happening.
    
    BugLink: https://github.com/thesofproject/linux/issues/3459
    Fixes: 029bfd1cd53cd ("soundwire: intel: conditionally exit clock stop mode on system suspend")
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Link: https://lore.kernel.org/r/20220420023241.14335-2-yung-chuan.liao@linux.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31db539abd4c5ec992a06cf39512688bc044b490
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Fri Feb 25 17:53:17 2022 +0000

    watchdog: rzg2l_wdt: Fix reset control imbalance
    
    [ Upstream commit 33d04d0fdba9fae18c7d58364643d2c606a43dba ]
    
    Both rzg2l_wdt_probe() and rzg2l_wdt_start() calls reset_control_
    deassert() which results in a reset control imbalance.
    
    This patch fixes reset control imbalance by removing reset_control_
    deassert() from rzg2l_wdt_start() and replaces reset_control_assert with
    reset_control_reset in rzg2l_wdt_stop() as watchdog module can be stopped
    only by a module reset. This change will allow us to restart WDT after
    stop() by configuring WDT timeout and enable registers.
    
    Fixes: 2cbc5cd0b55fa2 ("watchdog: Add Watchdog Timer driver for RZ/G2L")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220225175320.11041-5-biju.das.jz@bp.renesas.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6505541e5298cea2b79da68ee626f583f8e18784
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Fri Feb 25 17:53:16 2022 +0000

    watchdog: rzg2l_wdt: Fix 'BUG: Invalid wait context'
    
    [ Upstream commit e4cf89596c1f1e33309556699f910ced4abbaf44 ]
    
    This patch fixes the issue 'BUG: Invalid wait context' during restart()
    callback by using clk_prepare_enable() instead of pm_runtime_get_sync()
    for turning on the clocks during restart.
    
    This issue is noticed when testing with renesas_defconfig.
    
    [   42.213802] reboot: Restarting system
    [   42.217860]
    [   42.219364] =============================
    [   42.223368] [ BUG: Invalid wait context ]
    [   42.227372] 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522 Not tainted
    [   42.234153] -----------------------------
    [   42.238155] systemd-shutdow/1 is trying to lock:
    [   42.242766] ffff00000a650828 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x14/0x20
    [   42.250709] other info that might help us debug this:
    [   42.255753] context-{4:4}
    [   42.258368] 2 locks held by systemd-shutdow/1:
    [   42.262806]  #0: ffff80000944e1c8 (system_transition_mutex#2){+.+.}-{3:3}, at: __do_sys_reboot+0xd0/0x250
    [   42.272388]  #1: ffff8000094c4e40 (rcu_read_lock){....}-{1:2}, at: atomic_notifier_call_chain+0x0/0x150
    [   42.281795] stack backtrace:
    [   42.284672] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522
    [   42.294577] Hardware name: Renesas SMARC EVK based on r9a07g044c2 (DT)
    [   42.301096] Call trace:
    [   42.303538]  dump_backtrace+0xcc/0xd8
    [   42.307203]  show_stack+0x14/0x30
    [   42.310517]  dump_stack_lvl+0x88/0xb0
    [   42.314180]  dump_stack+0x14/0x2c
    [   42.317492]  __lock_acquire+0x1b24/0x1b50
    [   42.321502]  lock_acquire+0x120/0x3a8
    [   42.325162]  __mutex_lock+0x84/0x8f8
    [   42.328737]  mutex_lock_nested+0x30/0x58
    [   42.332658]  genpd_lock_mtx+0x14/0x20
    [   42.336319]  genpd_runtime_resume+0xc4/0x228
    [   42.340587]  __rpm_callback+0x44/0x170
    [   42.344337]  rpm_callback+0x64/0x70
    [   42.347824]  rpm_resume+0x4e0/0x6b8
    [   42.351310]  __pm_runtime_resume+0x50/0x78
    [   42.355404]  rzg2l_wdt_restart+0x28/0x68
    [   42.359329]  watchdog_restart_notifier+0x1c/0x30
    [   42.363943]  atomic_notifier_call_chain+0x94/0x150
    [   42.368732]  do_kernel_restart+0x24/0x30
    [   42.372652]  machine_restart+0x44/0x70
    [   42.376399]  kernel_restart+0x3c/0x60
    [   42.380058]  __do_sys_reboot+0x228/0x250
    [   42.383977]  __arm64_sys_reboot+0x20/0x28
    [   42.387983]  invoke_syscall+0x40/0xf8
    
    Fixes: 2cbc5cd0b55fa2 ("watchdog: Add Watchdog Timer driver for RZ/G2L")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220225175320.11041-4-biju.das.jz@bp.renesas.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d120d125425f9765047c6bb1056d00c5a43dd641
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Fri Feb 25 17:53:15 2022 +0000

    watchdog: rzg2l_wdt: Fix Runtime PM usage
    
    [ Upstream commit 95abafe76297fa057de6c3486ef844bd446bdf18 ]
    
    Both rzg2l_wdt_probe() and rzg2l_wdt_start() calls pm_runtime_get() which
    results in a usage counter imbalance. This patch fixes this issue by
    removing pm_runtime_get() call from probe.
    
    Fixes: 2cbc5cd0b55fa2 ("watchdog: Add Watchdog Timer driver for RZ/G2L")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20220225175320.11041-3-biju.das.jz@bp.renesas.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e07b9fa0dc32b492de85528caaf9f0c605d8424f
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Fri Feb 25 17:53:14 2022 +0000

    watchdog: rzg2l_wdt: Fix 32bit overflow issue
    
    [ Upstream commit ea2949df22a533cdf75e4583c00b1ce94cd5a83b ]
    
    The value of timer_cycle_us can be 0 due to 32bit overflow.
    For eg:- If we assign the counter value "0xfff" for computing
    maxval.
    
    This patch fixes this issue by appending ULL to 1024, so that
    it is promoted to 64bit.
    
    This patch also fixes the warning message, 'watchdog: Invalid min and
    max timeout values, resetting to 0!'.
    
    Fixes: 2cbc5cd0b55fa2 ("watchdog: Add Watchdog Timer driver for RZ/G2L")
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20220225175320.11041-2-biju.das.jz@bp.renesas.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 66b04734cd6ddd654530c12665c57de49c8cd8e2
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 27 11:04:42 2022 +0200

    export: fix string handling of namespace in EXPORT_SYMBOL_NS
    
    [ Upstream commit d143b9db8069f0e2a0fa34484e806a55a0dd4855 ]
    
    Commit c3a6cf19e695 ("export: avoid code duplication in
    include/linux/export.h") broke the ability for a defined string to be
    used as a namespace value.  Fix this up by using stringify to properly
    encode the namespace name.
    
    Fixes: c3a6cf19e695 ("export: avoid code duplication in include/linux/export.h")
    Cc: Miroslav Benes <mbenes@suse.cz>
    Cc: Emil Velikov <emil.l.velikov@gmail.com>
    Cc: Jessica Yu <jeyu@kernel.org>
    Cc: Quentin Perret <qperret@google.com>
    Cc: Matthias Maennich <maennich@google.com>
    Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
    Link: https://lore.kernel.org/r/20220427090442.2105905-1-gregkh@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 43f3369c5d1750c50e311818e64eda412b88cef9
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Fri Apr 29 21:40:18 2022 +0100

    serial: sifive: Report actual baud base rather than fixed 115200
    
    [ Upstream commit 0a7ff843d507ce2cca2c3b7e169ee56e28133530 ]
    
    The base baud value reported is supposed to be the highest baud rate
    that can be set for a serial port.  The SiFive FU740-C000 SOC's on-chip
    UART supports baud rates of up to 1/16 of the input clock rate, which is
    the bus clock `tlclk'[1], often at 130MHz in the case of the HiFive
    Unmatched board.
    
    However the sifive UART driver reports a fixed value of 115200 instead:
    
    10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 1, base_baud = 115200) is a SiFive UART v0
    10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 2, base_baud = 115200) is a SiFive UART v0
    
    even though we already support setting higher baud rates, e.g.:
    
    $ tty
    /dev/ttySIF1
    $ stty speed
    230400
    
    The baud base value is computed by the serial core by dividing the UART
    clock recorded in `struct uart_port' by 16, which is also the minimum
    value of the clock divider supported, so correct the baud base value
    reported by setting the UART clock recorded to the input clock rate
    rather than 115200:
    
    10010000.serial: ttySIF0 at MMIO 0x10010000 (irq = 1, base_baud = 8125000) is a SiFive UART v0
    10011000.serial: ttySIF1 at MMIO 0x10011000 (irq = 2, base_baud = 8125000) is a SiFive UART v0
    
    References:
    
    [1] "SiFive FU740-C000 Manual", v1p3, SiFive, Inc., August 13, 2021,
        Section 16.9 "Baud Rate Divisor Register (div)", pp.143-144
    
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Fixes: 1f1496a923b6 ("riscv: Fix sifive serial driver")
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204291656280.9383@angie.orcam.me.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9ce9b98a8f6b81827347690fbf80de0fedfdf78
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Sat Apr 23 19:27:27 2022 +0200

    power: supply: ab8500_fg: Allocate wq in probe
    
    [ Upstream commit 010ddb813f3554cbbf8bd13b731452236a2c8017 ]
    
    The workqueue is allocated in bind() but all interrupts are
    registered in probe().
    
    Some interrupts put work on the workqueue, which can have
    bad side effects.
    
    Allocate the workqueue in probe() instead, destroy it in
    .remove() and make unbind() simply flush the workqueue.
    
    Fixes: 1c1f13a006ed ("power: supply: ab8500: Move to componentized binding")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6bf660d4b66a1115e59cb863b49389ef6298a95b
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon May 2 13:12:35 2022 +0200

    power: supply: axp288_fuel_gauge: Drop BIOS version check from "T3 MRD" DMI quirk
    
    [ Upstream commit f61509a6f0b70f5bedea34efaf8065621689bd7a ]
    
    Some "T3 MRD" mini-PCs / HDMI-sticks without a battery use a different
    value then "5.11" for their DMI BIOS version field.
    
    Drop the BIOS version check so that the no-battery "T3 MRD" DMI quirk
    applies to these too.
    
    Fixes: 3a06b912a5ce ("power: supply: axp288_fuel_gauge: Make "T3 MRD" no_battery_list DMI entry more generic")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d4ee7d4f4de81a600b760984bee96c1d8dc7fabf
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon May 2 15:31:29 2022 +0200

    phy: qcom-qmp: fix pipe-clock imbalance on power-on failure
    
    [ Upstream commit 5e73b2d9867998278479ccc065a8a8227a5513ef ]
    
    Make sure to disable the pipe clock also if ufs-reset deassertion fails
    during power on.
    
    Note that the ufs-reset is asserted in qcom_qmp_phy_com_exit().
    
    Fixes: c9b589791fc1 ("phy: qcom: Utilize UFS reset controller")
    Cc: Evan Green <evgreen@chromium.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20220502133130.4125-2-johan+linaro@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 054d5cdeb09ac5790b43577084209de3aa5cf729
Author: Guilherme G. Piccoli <gpiccoli@igalia.com>
Date:   Wed Apr 27 19:48:59 2022 -0300

    misc/pvpanic: Convert regular spinlock into trylock on panic path
    
    [ Upstream commit e918c10265ef2bc82ce8a6fed6d8123d09ec1db3 ]
    
    The pvpanic driver relies on panic notifiers to execute a callback
    on panic event. Such function is executed in atomic context - the
    panic function disables local IRQs, preemption and all other CPUs
    that aren't running the panic code.
    
    With that said, it's dangerous to use regular spinlocks in such path,
    as introduced by commit b3c0f8774668 ("misc/pvpanic: probe multiple instances").
    This patch fixes that by replacing regular spinlocks with the trylock
    safer approach.
    
    It also fixes an old comment (about a long gone framebuffer code) and
    the notifier priority - we should execute hypervisor notifiers early,
    deferring this way the panic action to the hypervisor, as expected by
    the users that are setting up pvpanic.
    
    Fixes: b3c0f8774668 ("misc/pvpanic: probe multiple instances")
    Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Cc: Mihai Carabas <mihai.carabas@oracle.com>
    Cc: Shile Zhang <shile.zhang@linux.alibaba.com>
    Cc: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Cc: zhenwei pi <pizhenwei@bytedance.com>
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Link: https://lore.kernel.org/r/20220427224924.592546-6-gpiccoli@igalia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 19fc743bb2dbb4a8c47bdafb83db9d8ac82c7eb4
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sat Apr 23 11:39:32 2022 +0200

    rpmsg: qcom_smd: Fix returning 0 if irq_of_parse_and_map() fails
    
    [ Upstream commit 59d6f72f6f9c92fec8757d9e29527da828e9281f ]
    
    irq_of_parse_and_map() returns 0 on failure, so this should not be
    passed further as error return code.
    
    Fixes: 1a358d350664 ("rpmsg: qcom_smd: Fix irq_of_parse_and_map() return value")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220423093932.32136-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 217708ec2613f3eb7c74f5f0999e15734f2be8fd
Author: Cixi Geng <cixi.geng1@unisoc.com>
Date:   Tue Apr 19 22:24:54 2022 +0800

    iio: adc: sc27xx: Fine tune the scale calibration values
    
    [ Upstream commit 5a7a184b11c6910f47600ff5cbbee34168f701a8 ]
    
    Small adjustment the scale calibration value for the sc2731,
    use new name sc2731_[big|small]_scale_graph_calib, and remove
    the origin [big|small]_scale_graph_calib struct for unused.
    
    Fixes: 8ba0dbfd07a35 (iio: adc: sc27xx: Add ADC scale calibration)
    Signed-off-by: Cixi Geng <cixi.geng1@unisoc.com>
    Link: https://lore.kernel.org/r/20220419142458.884933-4-gengcixi@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b600e02bd7f63afa9f846348a36f87506d8bcc40
Author: Cixi Geng <cixi.geng1@unisoc.com>
Date:   Tue Apr 19 22:24:53 2022 +0800

    iio: adc: sc27xx: fix read big scale voltage not right
    
    [ Upstream commit ad930a75613282400179361e220e58b87386b8c7 ]
    
    Fix wrong configuration value of SC27XX_ADC_SCALE_MASK and
    SC27XX_ADC_SCALE_SHIFT by spec documetation.
    
    Fixes: 5df362a6cf49c (iio: adc: Add Spreadtrum SC27XX PMICs ADC support)
    Signed-off-by: Cixi Geng <cixi.geng1@unisoc.com>
    Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
    Link: https://lore.kernel.org/r/20220419142458.884933-3-gengcixi@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 505abf54a372136d9c91b94a0f82f46f1625f262
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Apr 12 06:42:09 2022 +0000

    iio: proximity: vl53l0x: Fix return value check of wait_for_completion_timeout
    
    [ Upstream commit 50f2959113cb6756ffd73c4fedc712cf2661f711 ]
    
    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: 3cef2e31b54b ("iio: proximity: vl53l0x: Add IRQ support")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220412064210.10734-1-linmq006@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a5ee3a03647c83c7c948c1a321e923bc82f28fc
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Tue Apr 12 06:51:45 2022 +0000

    iio: adc: stmpe-adc: Fix wait_for_completion_timeout return value check
    
    [ Upstream commit d345b23200bcdbd2bd3582213d738c258b77718f ]
    
    wait_for_completion_timeout() returns unsigned long not long.
    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: e813dde6f833 ("iio: stmpe-adc: Use wait_for_completion_timeout")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Reviewed-by: Philippe Schenker <philippe.schenker@toradex.com>
    Link: https://lore.kernel.org/r/20220412065150.14486-1-linmq006@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30da7b67fa9176fe19758bb959cb27e437ffbff3
Author: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Date:   Tue Apr 26 14:05:36 2022 +0800

    rpmsg: virtio: Fix the unregistration of the device rpmsg_ctrl
    
    [ Upstream commit df191796985922488e4e6b64f7bd79c3934412f2 ]
    
    Unregister the rpmsg_ctrl device instead of just freeing the
    the virtio_rpmsg_channel structure.
    This will properly unregister the device and call
    virtio_rpmsg_release_device() that frees the structure.
    
    Fixes: c486682ae1e2 ("rpmsg: virtio: Register the rpmsg_char device")
    Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Reviewed-by: Hangyu Hua <hbh25y@gmail.com>
    Link: https://lore.kernel.org/r/20220426060536.15594-4-hbh25y@gmail.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 900373f8f7ee128cbbd3968722182b8d26c1e54e
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Tue Apr 26 14:05:35 2022 +0800

    rpmsg: virtio: Fix possible double free in rpmsg_virtio_add_ctrl_dev()
    
    [ Upstream commit 1680939e9ecf7764fba8689cfb3429c2fe2bb23c ]
    
    vch will be free in virtio_rpmsg_release_device() when
    rpmsg_ctrldev_register_device() fails. There is no need to call
    kfree() again.
    
    Fixes: c486682ae1e2 ("rpmsg: virtio: Register the rpmsg_char device")
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Tested-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Link: https://lore.kernel.org/r/20220426060536.15594-3-hbh25y@gmail.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c49fb74e050d01ea09703b7c0d5fe8b9c3855b60
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Tue Apr 26 14:05:34 2022 +0800

    rpmsg: virtio: Fix possible double free in rpmsg_probe()
    
    [ Upstream commit c2eecefec5df1306eafce28ccdf1ca159a552ecc ]
    
    vch will be free in virtio_rpmsg_release_device() when
    rpmsg_ns_register_device() fails. There is no need to call kfree() again.
    
    Fix this by changing error path from free_vch to free_ctrldev.
    
    Fixes: c486682ae1e2 ("rpmsg: virtio: Register the rpmsg_char device")
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Tested-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
    Link: https://lore.kernel.org/r/20220426060536.15594-2-hbh25y@gmail.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2295b9e0440e728f6590fc3f2e4e7ee2cbd6805
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date:   Fri Apr 22 15:23:47 2022 -0700

    usb: typec: mux: Check dev_set_name() return value
    
    [ Upstream commit b9fa0292490db39d6542f514117333d366ec0011 ]
    
    It's possible that dev_set_name() returns -ENOMEM, catch and handle this.
    
    Fixes: 3370db35193b ("usb: typec: Registering real device entries for the muxes")
    Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220422222351.1297276-4-bjorn.andersson@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b94ef14a13da589f01c0d456d04bcd54d456d23
Author: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Date:   Thu Apr 14 11:56:09 2022 +0800

    firmware: stratix10-svc: fix a missing check on list iterator
    
    [ Upstream commit 5a0793ac66ac0e254d292f129a4d6c526f9f2aff ]
    
    The bug is here:
            pmem->vaddr = NULL;
    
    The list iterator 'pmem' will point to a bogus position containing
    HEAD if the list is empty or no element is found. This case must
    be checked before any use of the iterator, otherwise it will
    lead to a invalid memory access.
    
    To fix this bug, just gen_pool_free/set NULL/list_del() and return
    when found, otherwise list_del HEAD and return;
    
    Fixes: 7ca5ce896524f ("firmware: add Intel Stratix10 service layer driver")
    Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
    Link: https://lore.kernel.org/r/20220414035609.2239-1-xiam0nd.tong@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f965297acdfe2c99bf2e65c347b9feed89f0eae
Author: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Date:   Sun Mar 27 14:22:02 2022 +0800

    misc: fastrpc: fix an incorrect NULL check on list iterator
    
    [ Upstream commit 5ac11fe03a0a83042d1a040dbce4fa2fb5521e23 ]
    
    The bug is here:
            if (!buf) {
    
    The list iterator value 'buf' will *always* be set and non-NULL
    by list_for_each_entry(), so it is incorrect to assume that the
    iterator value will be NULL if the list is empty (in this case, the
    check 'if (!buf) {' will always be false and never exit expectly).
    
    To fix the bug, use a new variable 'iter' as the list iterator,
    while use the original variable 'buf' as a dedicated pointer to
    point to the found element.
    
    Fixes: 2419e55e532de ("misc: fastrpc: add mmap/unmap support")
    Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
    Link: https://lore.kernel.org/r/20220327062202.5720-1-xiam0nd.tong@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f819ba624252c26320f184b511ee72c252ff862
Author: SeongJae Park <sj@kernel.org>
Date:   Tue Apr 19 12:16:36 2022 +0000

    scripts/get_abi: Fix wrong script file name in the help message
    
    [ Upstream commit 5b5bfecaa333fb6a0cce1bfc4852a622dacfed1d ]
    
    The help message of 'get_abi.pl' is mistakenly saying it's
    'abi_book.pl'.  This commit fixes the wrong name in the help message.
    
    Fixes: bbc249f2b859 ("scripts: add an script to parse the ABI files")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Link: https://lore.kernel.org/r/20220419121636.290407-1-sj@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 24ce123abe7a789fe8b25696d858f2c6bea34718
Author: Zheng Yongjun <zhengyongjun3@huawei.com>
Date:   Fri Apr 22 06:26:52 2022 +0000

    usb: dwc3: pci: Fix pm_runtime_get_sync() error checking
    
    [ Upstream commit a03e2ddab8e735e2cc315609b297b300e9cc60d2 ]
    
    If the device is already in a runtime PM enabled state
    pm_runtime_get_sync() will return 1, so a test for negative
    value should be used to check for errors.
    
    Fixes: 8eed00b237a28 ("usb: dwc3: pci: Runtime resume child device from wq")
    Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
    Link: https://lore.kernel.org/r/20220422062652.10575-1-zhengyongjun3@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2424307cdf421ac72075a1384eae4e4199ab6457
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Thu Apr 14 11:35:21 2022 -0700

    usb: dwc3: gadget: Replace list_for_each_entry_safe() if using giveback
    
    [ Upstream commit bf594d1d0c1d7b895954018043536ffd327844f9 ]
    
    The list_for_each_entry_safe() macro saves the current item (n) and
    the item after (n+1), so that n can be safely removed without
    corrupting the list.  However, when traversing the list and removing
    items using gadget giveback, the DWC3 lock is briefly released,
    allowing other routines to execute.  There is a situation where, while
    items are being removed from the cancelled_list using
    dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable
    routine is running in parallel (due to UDC unbind).  As the cleanup
    routine removes n, and the pullup disable removes n+1, once the
    cleanup retakes the DWC3 lock, it references a request who was already
    removed/handled.  With list debug enabled, this leads to a panic.
    Ensure all instances of the macro are replaced where gadget giveback
    is used.
    
    Example call stack:
    
    Thread#1:
    __dwc3_gadget_ep_set_halt() - CLEAR HALT
      -> dwc3_gadget_ep_cleanup_cancelled_requests()
        ->list_for_each_entry_safe()
        ->dwc3_gadget_giveback(n)
          ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list]
          ->spin_unlock
          ->Thread#2 executes
          ...
        ->dwc3_gadget_giveback(n+1)
          ->Already removed!
    
    Thread#2:
    dwc3_gadget_pullup()
      ->waiting for dwc3 spin_lock
      ...
      ->Thread#1 released lock
      ->dwc3_stop_active_transfers()
        ->dwc3_remove_requests()
          ->fetches n+1 item from cancelled_list (n removed by Thread#1)
          ->dwc3_gadget_giveback()
            ->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list]
            ->spin_unlock
    
    Fixes: d4f1afe5e896 ("usb: dwc3: gadget: move requests to cancelled_list")
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20220414183521.23451-1-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9590cd1dec80d76a57318935a3c9949f072cfab2
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Apr 22 12:53:26 2022 +0200

    rpmsg: qcom_smd: Fix irq_of_parse_and_map() return value
    
    [ Upstream commit 1a358d35066487d228a68303d808bc4721c6b1b9 ]
    
    The irq_of_parse_and_map() returns 0 on failure, not a negative ERRNO.
    
    Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220422105326.78713-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ede19a5caa2ad5892053641644ef1edc8cd7767d
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Apr 8 17:38:46 2022 +0200

    pwm: raspberrypi-poe: Fix endianness in firmware struct
    
    [ Upstream commit 09f688f0718f57f9cf68ee1aa94490f641e759ba ]
    
    The reg member of struct raspberrypi_pwm_prop is a little endian 32 bit
    quantity. Explicitly convert the (native endian) value to little endian
    on assignment as is already done in raspberrypi_pwm_set_property().
    
    This fixes the following sparse warning:
    
            drivers/pwm/pwm-raspberrypi-poe.c:69:24: warning: incorrect type in initializer (different base types)
            drivers/pwm/pwm-raspberrypi-poe.c:69:24:    expected restricted __le32 [usertype] reg
            drivers/pwm/pwm-raspberrypi-poe.c:69:24:    got unsigned int [usertype] reg
    
    Fixes: 79caa362eab6 ("pwm: Add Raspberry Pi Firmware based PWM bus")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 202eff15b5e7ec4c01f919085b10403065493c45
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Apr 8 17:22:38 2022 +0200

    pwm: lp3943: Fix duty calculation in case period was clamped
    
    [ Upstream commit 5e3b07ca5cc78cd4a987e78446849e41288d87cb ]
    
    The hardware only supports periods <= 1.6 ms and if a bigger period is
    requested it is clamped to 1.6 ms. In this case duty_cycle might be bigger
    than 1.6 ms and then the duty cycle register is written with a value
    bigger than LP3943_MAX_DUTY. So clamp duty_cycle accordingly.
    
    Fixes: af66b3c0934e ("pwm: Add LP3943 PWM driver")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0fe4e9dbcd9f67e991525e28ff3f152907f70a00
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri Apr 22 08:48:18 2022 +0200

    staging: fieldbus: Fix the error handling path in anybuss_host_common_probe()
    
    [ Upstream commit 7079b3483a17be2cfba64cbd4feb1b7ae07f1ea7 ]
    
    If device_register() fails, device_unregister() should not be called
    because it will free some resources that are not allocated.
    put_device() should be used instead.
    
    Fixes: 308ee87a2f1e ("staging: fieldbus: anybus-s: support HMS Anybus-S bus")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/5401a519608d6e1a4e7435c20f4f20b0c5c36c23.1650610082.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84779dd3dd5ae3a8052dbc620106676eafcb4f6d
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Mar 9 11:10:33 2022 +0000

    usb: musb: Fix missing of_node_put() in omap2430_probe
    
    [ Upstream commit 424bef51fa530389b0b9008c9e144e40c10e8458 ]
    
    The device_node pointer is returned by of_parse_phandle() with refcount
    incremented. We should use of_node_put() on it when done.
    
    Fixes: 8934d3e4d0e7 ("usb: musb: omap2430: Don't use omap_get_control_dev()")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220309111033.24487-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57ca42f4dd35a6a41565153a4b563976e5e43b23
Author: Lin Ma <linma@zju.edu.cn>
Date:   Tue Apr 12 22:43:59 2022 +0800

    USB: storage: karma: fix rio_karma_init return
    
    [ Upstream commit b92ffb1eddd9a66a90defc556dcbf65a43c196c7 ]
    
    The function rio_karam_init() should return -ENOMEM instead of
    value 0 (USB_STOR_TRANSPORT_GOOD) when allocation fails.
    
    Similarly, it should return -EIO when rio_karma_send_command() fails.
    
    Fixes: dfe0d3ba20e8 ("USB Storage: add rio karma eject support")
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Link: https://lore.kernel.org/r/20220412144359.28447-1-linma@zju.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c78d7b7ce0c5eef27be9d15ad366f1e11922235
Author: Niels Dossche <dossche.niels@gmail.com>
Date:   Tue Apr 12 18:50:55 2022 +0200

    usb: usbip: add missing device lock on tweak configuration cmd
    
    [ Upstream commit d088fabace2ca337b275d1d4b36db4fe7771e44f ]
    
    The function documentation of usb_set_configuration says that its
    callers should hold the device lock. This lock is held for all
    callsites except tweak_set_configuration_cmd. The code path can be
    executed for example when attaching a remote USB device.
    The solution is to surround the call by the device lock.
    
    This bug was found using my experimental own-developed static analysis
    tool, which reported the missing lock on v5.17.2. I manually verified
    this bug report by doing code review as well. I runtime checked that
    the required lock is not held. I compiled and runtime tested this on
    x86_64 with a USB mouse. After applying this patch, my analyser no
    longer reports this potential bug.
    
    Fixes: 2c8c98158946 ("staging: usbip: let client choose device configuration")
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Niels Dossche <dossche.niels@gmail.com>
    Link: https://lore.kernel.org/r/20220412165055.257113-1-dossche.niels@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8afb048800919d0ab10c57983940eba956339f21
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Tue Apr 12 10:02:57 2022 +0800

    usb: usbip: fix a refcount leak in stub_probe()
    
    [ Upstream commit 9ec4cbf1cc55d126759051acfe328d489c5d6e60 ]
    
    usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails
    after that, usb_put_dev() needs to be called to release the reference.
    
    Fix this by moving usb_put_dev() to sdev_free error path handling.
    
    Find this by code review.
    
    Fixes: 3ff67445750a ("usbip: fix error handling in stub_probe()")
    Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Link: https://lore.kernel.org/r/20220412020257.9767-1-hbh25y@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a02704720ea77b330fe520d2cd5bb011b093587
Author: Samuel Holland <samuel@sholland.org>
Date:   Wed Apr 13 22:22:52 2022 -0500

    phy: rockchip-inno-usb2: Fix muxed interrupt support
    
    [ Upstream commit 6a98df08ccd55e87947d253b19925691763e755c ]
    
    This commit fixes two issues with the muxed interrupt handler. First,
    the OTG port has the "bvalid" interrupt enabled, not "linestate". Since
    only the linestate interrupt was handled, and not the bvalid interrupt,
    plugging in a cable to the OTG port caused an interrupt storm.
    
    Second, the return values from the individual port IRQ handlers need to
    be OR-ed together. Otherwise, the lack of an interrupt from the last
    port would cause the handler to erroneously return IRQ_NONE.
    
    Fixes: ed2b5a8e6b98 ("phy: phy-rockchip-inno-usb2: support muxed interrupts")
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Tested-by: Michael Riesch <michael.riesch@wolfvision.net>
    Link: https://lore.kernel.org/r/20220414032258.40984-2-samuel@sholland.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 968dd3086f3521627015ede91c0cfa896595c796
Author: Peng Fan <peng.fan@nxp.com>
Date:   Fri Apr 15 10:57:37 2022 +0800

    remoteproc: imx_rproc: Ignore create mem entry for resource table
    
    [ Upstream commit 58b7c856519fe946620ee68dd0c37bd3c695484a ]
    
    Resource table is used by Linux to get information published by
    remote processor. It should be not be used for memory allocation, so
    not create rproc mem entry.
    
    Fixes: b29b4249f8f0 ("remoteproc: imx_rproc: add i.MX specific parse fw hook")
    Signed-off-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/r/20220415025737.1561976-1-peng.fan@oss.nxp.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f453622a76d4e9eb5f32d294f75a5571e7dd1ef
Author: Sherry Sun <sherry.sun@nxp.com>
Date:   Mon Mar 21 19:22:11 2022 +0800

    tty: serial: fsl_lpuart: fix potential bug when using both of_alias_get_id and ida_simple_get
    
    [ Upstream commit f398e0aa325c61fa20903833a5b534ecb8e6e418 ]
    
    Now fsl_lpuart driver use both of_alias_get_id() and ida_simple_get() in
    .probe(), which has the potential bug. For example, when remove the
    lpuart7 alias in dts, of_alias_get_id() will return error, then call
    ida_simple_get() to allocate the id 0 for lpuart7, this may confilct
    with the lpuart4 which has alias 0.
    
        aliases {
            ...
            serial0 = &lpuart4;
            serial1 = &lpuart5;
            serial2 = &lpuart6;
            serial3 = &lpuart7;
        }
    
    So remove the ida_simple_get() in .probe(), return an error directly
    when calling of_alias_get_id() fails, which is consistent with other
    uart drivers behavior.
    
    Fixes: 3bc3206e1c0f ("serial: fsl_lpuart: Remove the alias node dependence")
    Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
    Link: https://lore.kernel.org/r/20220321112211.8895-1-sherry.sun@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 90a6b6fc52bfdcfe9698454bf5bea26112abbcd1
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Apr 4 14:38:40 2022 +0000

    serial: 8250_aspeed_vuart: Fix potential NULL dereference in aspeed_vuart_probe
    
    [ Upstream commit 0e0fd55719fa081de6f9e5d9e6cef48efb04d34a ]
    
    platform_get_resource() may fail and return NULL, so we should
    better check it's return value to avoid a NULL pointer dereference.
    
    Fixes: 54da3e381c2b ("serial: 8250_aspeed_vuart: use UPF_IOREMAP to set up register mapping")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220404143842.16960-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 817b7cd7c3765d9d774ab28a8e25963c68424aa7
Author: Daniel Gibson <daniel@gibson.sh>
Date:   Wed Mar 30 01:58:10 2022 +0200

    tty: n_tty: Restore EOF push handling behavior
    
    [ Upstream commit 65a8b287023da68c4550deab5c764e6891cf1caf ]
    
    TTYs in ICANON mode have a special case that allows "pushing" a line
    without a regular EOL character (like newline), by using EOF (the EOT
    character - ASCII 0x4) as a pseudo-EOL. It is silently discarded, so
    the reader of the PTS will receive the line *without* EOF or any other
    terminating character.
    
    This special case has an edge case: What happens if the readers buffer
    is the same size as the line (without EOF)? Will they be able to tell
    if the whole line is received, i.e. if the next read() will return more
    of the same line or the next line?
    
    There are two possibilities,  that both have (dis)advantages:
    
    1. The next read() returns 0. FreeBSD (13.0) and OSX (10.11) do this.
       Advantage: The reader can interpret this as "the line is over".
       Disadvantage: read() returning 0 means EOF, the reader could also
       interpret it as "there's no more data" and stop reading or even
       close the PT.
    
    2. The next read() returns the next line, the EOF is silently discarded.
       Solaris (or at least OpenIndiana 2021.10) does this, Linux has done
       do this since commit 40d5e0905a03 ("n_tty: Fix EOF push handling");
       this behavior was recently broken by commit 359303076163 ("tty:
       n_tty: do not look ahead for EOL character past the end of the buffer").
       Advantage: read() won't return 0 (EOF), reader less likely to be
       confused (and things like `while(read(..)>0)` don't break)
       Disadvantage: The reader can't really know if the read() continues
       the last line (that filled the whole read buffer) or starts a
       new line.
    
    As both options are defensible (and are used by other Unix-likes), it's
    best to stick to the "old" behavior since "n_tty: Fix EOF push handling"
    of 2013, i.e. silently discard that EOF.
    
    This patch - that I actually got from Linus for testing and only
    modified slightly - restores that behavior by skipping an EOF
    character if it's the next character after reading is done.
    
    Based on a patch from Linus Torvalds.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215611
    Fixes: 359303076163 ("tty: n_tty: do not look ahead for EOL character past the end of the buffer")
    Cc: Peter Hurley <peter@hurleysoftware.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Reviewed-and-tested-by: Daniel Gibson <daniel@gibson.sh>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Daniel Gibson <daniel@gibson.sh>
    Link: https://lore.kernel.org/r/20220329235810.452513-2-daniel@gibson.sh
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48840d18f3c98787654675b09a4a3ca4d4a58c6c
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Mar 7 10:51:35 2022 +0000

    tty: serial: owl: Fix missing clk_disable_unprepare() in owl_uart_probe
    
    [ Upstream commit bcea0f547ec1a2ee44d429aaf0334633e386e67c ]
    
    Fix the missing clk_disable_unprepare() before return
    from owl_uart_probe() in the error handling case.
    
    Fixes: abf42d2f333b ("tty: serial: owl: add "much needed" clk_prepare_enable()")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220307105135.11698-1-linmq006@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45f6ce70abfb7ccf9d787781cbc4c03294a775a1
Author: Wang Weiyang <wangweiyang2@huawei.com>
Date:   Mon Mar 28 19:58:44 2022 +0800

    tty: goldfish: Use tty_port_destroy() to destroy port
    
    [ Upstream commit 507b05063d1b7a1fcb9f7d7c47586fc4f3508f98 ]
    
    In goldfish_tty_probe(), the port initialized through tty_port_init()
    should be destroyed in error paths.In goldfish_tty_remove(), qtty->port
    also should be destroyed or else might leak resources.
    
    Fix the above by calling tty_port_destroy().
    
    Fixes: 666b7793d4bf ("goldfish: tty driver")
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Wang Weiyang <wangweiyang2@huawei.com>
    Link: https://lore.kernel.org/r/20220328115844.86032-1-wangweiyang2@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8fc5104764c1f44b58ce7281de8fe923a11acc67
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Apr 11 21:13:39 2022 +0200

    lkdtm/bugs: Don't expect thread termination without CONFIG_UBSAN_TRAP
    
    [ Upstream commit 8bfdbddd68249e0d8598777cca8249619ee51df0 ]
    
    When you don't select CONFIG_UBSAN_TRAP, you get:
    
      # echo ARRAY_BOUNDS > /sys/kernel/debug/provoke-crash/DIRECT
    [  102.265827] ================================================================================
    [  102.278433] UBSAN: array-index-out-of-bounds in drivers/misc/lkdtm/bugs.c:342:16
    [  102.287207] index 8 is out of range for type 'char [8]'
    [  102.298722] ================================================================================
    [  102.313712] lkdtm: FAIL: survived array bounds overflow!
    [  102.318770] lkdtm: Unexpected! This kernel (5.16.0-rc1-s3k-dev-01884-g720dcf79314a ppc) was built with CONFIG_UBSAN_BOUNDS=y
    
    It is not correct because when CONFIG_UBSAN_TRAP is not selected
    you can't expect array bounds overflow to kill the thread.
    
    Modify the logic so that when the kernel is built with
    CONFIG_UBSAN_BOUNDS but without CONFIG_UBSAN_TRAP, you get a warning
    about CONFIG_UBSAN_TRAP not been selected instead.
    
    This also require a fix of pr_expected_config(), otherwise the
    following error is encountered.
    
      CC      drivers/misc/lkdtm/bugs.o
    drivers/misc/lkdtm/bugs.c: In function 'lkdtm_ARRAY_BOUNDS':
    drivers/misc/lkdtm/bugs.c:351:2: error: 'else' without a previous 'if'
      351 |  else
          |  ^~~~
    
    Fixes: c75be56e35b2 ("lkdtm/bugs: Add ARRAY_BOUNDS to selftests")
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/363b58690e907c677252467a94fe49444c80ea76.1649704381.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec89c6200f8d94a86d57b2bb881fb079417f4901
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Thu Jan 20 17:29:36 2022 +0800

    lkdtm/bugs: Check for the NULL pointer after calling kmalloc
    
    [ Upstream commit 4a9800c81d2f34afb66b4b42e0330ae8298019a2 ]
    
    As the possible failure of the kmalloc(), the not_checked and checked
    could be NULL pointer.
    Therefore, it should be better to check it in order to avoid the
    dereference of the NULL pointer.
    Also, we need to kfree the 'not_checked' and 'checked' to avoid
    the memory leak if fails.
    And since it is just a test, it may directly return without error
    number.
    
    Fixes: ae2e1aad3e48 ("drivers/misc/lkdtm/bugs.c: add arithmetic overflow and array bounds checks")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20220120092936.1874264-1-jiasheng@iscas.ac.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 196efcfed302d790def6512692a25f19f385bc30
Author: Alexandru Tachici <alexandru.tachici@analog.com>
Date:   Tue Mar 22 12:50:24 2022 +0200

    iio: adc: ad7124: Remove shift from scan_type
    
    [ Upstream commit fe78ccf79b0e29fd6d8dc2e2c3b0dbeda4ce3ad8 ]
    
    The 24 bits data is stored in 32 bits in BE. There
    is no need to shift it. This confuses user-space apps.
    
    Fixes: b3af341bbd966 ("iio: adc: Add ad7124 support")
    Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
    Link: https://lore.kernel.org/r/20220322105029.86389-2-alexandru.tachici@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit becc34e66b97550ee4a2bf97775cd17518547db7
Author: Jakob Koschel <jakobkoschel@gmail.com>
Date:   Mon Mar 21 13:36:26 2022 +0100

    staging: greybus: codecs: fix type confusion of list iterator variable
    
    [ Upstream commit 84ef256550196bc06e6849a34224c998b45bd557 ]
    
    If the list does not exit early then data == NULL and 'module' does not
    point to a valid list element.
    Using 'module' in such a case is not valid and was therefore removed.
    
    Fixes: 6dd67645f22c ("greybus: audio: Use single codec driver registration")
    Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Vaibhav Agarwal <vaibhav.sr@gmail.com>
    Reviewed-by: Mark Greer <mgreer@animalcreek.com>
    Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
    Link: https://lore.kernel.org/r/20220321123626.3068639-1-jakobkoschel@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f64d8b0ab5182c433e165126b0bcbc450da0db4
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Jan 23 09:40:31 2022 -0800

    pcmcia: db1xxx_ss: restrict to MIPS_DB1XXX boards
    
    [ Upstream commit 3928cf08334ed895a31458cbebd8d4ec6d84c080 ]
    
    When the MIPS_ALCHEMY board selection is MIPS_XXS1500 instead of
    MIPS_DB1XXX, the PCMCIA driver 'db1xxx_ss' has build errors due
    to missing DB1XXX symbols. The PCMCIA driver should be restricted
    to MIPS_DB1XXX instead of MIPS_ALCHEMY to fix this build error.
    
    ERROR: modpost: "bcsr_read" [drivers/pcmcia/db1xxx_ss.ko] undefined!
    ERROR: modpost: "bcsr_mod" [drivers/pcmcia/db1xxx_ss.ko] undefined!
    
    Fixes: 42a4f17dc356 ("MIPS: Alchemy: remove SOC_AU1X00 in favor of MIPS_ALCHEMY")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: linux-mips@vger.kernel.org
    Acked-by: Manuel Lauss <manuel.lauss@gmail.com>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>