commit 3a0f7014932490407e3503cd80967d7aaf18b9fe
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jun 14 18:36:28 2022 +0200

    Linux 5.15.47
    
    Link: https://lore.kernel.org/r/20220613094922.843438024@linuxfoundation.org
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Link: https://lore.kernel.org/r/20220613181847.216528857@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Fox Chen <foxhlchen@gmail.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7019562f142bc041f9cde63af338d1886585923
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 90385f2b65d0cd2b3b1ac8909f0cc6dd31062cfc
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 cfe3dd8bd5262749b1b1b6e07169acaa82fba64a
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 fb5e51c0aa973df7d9995992f4ff48e5bb59a8ac
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 7f36e2e13e296929e02dad14bc2aa0708a8654d5
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 9e4810b4e1abd550183b93daf5fea79e85b4d5b7
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 42c0160d27f6158b8dc9c6059eac568a42883fc6
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 4c106eb8953456a2768d4e5f78888c3209f9a046
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 51e5572724826d433d74c40702fa762342a3406c
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 e59a120f2d435ee2cfa47035be903cc2d8cc6731
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 ce49b94ddb70e607c476a12d26002715d694b23a
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 32ca45300fd9cbb1857b29a4b6059c21473ef3f8
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 82a2059a11b450eecebc5eae1d3a66fbd87b7840
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
Date:   Tue Dec 21 16:59:03 2021 +1100

    powerpc/mm: Switch obsolete dssall to .long
    
    commit d51f86cfd8e378d4907958db77da3074f6dce3ba upstream.
    
    The dssall ("Data Stream Stop All") instruction is obsolete altogether
    with other Data Cache Instructions since ISA 2.03 (year 2006).
    
    LLVM IAS does not support it but PPC970 seems to be using it.
    This switches dssall to .long as there is no much point in fixing LLVM.
    
    Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20211221055904.555763-6-aik@ozlabs.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a0165d278973e30f2282c15c52d91788749d2d4
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 2b7d9fd0f3725135b40571d6a44bbbaeead132fe
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 cab7cd86f9e81834c407e043844779f21653ff3c
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 142bebf827b33eb162c5b02c9b90b2ff588261cd
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 84280ab2245c1b201659a44dfa846e64143dfc94
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 3a7a81f4835dfda11f39fdd27586da14331896eb
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 614ad9d24f9ca0992bc8863c0909bb16ecd2ec3c
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 3eb91b7bc252a9fbb14cb69226b3b394e74b2a6a
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 dc2673462e3da7824507da59d26253ab9cf0b272
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 a5989ae3c53be69b2658ce22fa11ec30281aead0
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 f444ecd3f57f4ba5090fe8b6756933e37de4226e
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 73b28763050f0f5356f9096a57c88e9fb1805e32
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 bafbc134f5b0948aa1ca015a0dff70b02c0152b7
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 cba7c76ea1e15fddb95706eb64659644a6a02b38
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 50ca4e7f91ff5eb24db9c7d46d9b0bbd6b3494ac
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 0efa89742fd8ba27cf775080867efacc264b2244
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 63af49e0881c354434be5beec534cf6193d60c5a
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 0dcc35c1c23a99a508f7c20aec924123658e71cf
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 0cd4a17667591089dc2621e3b959567a24ed396f
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 7aa4b31291f1d750f40b75b235c13ad89aaecf39
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 700484081ea769808f65bf94face75573c8a48e3
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 0179650a13f91170ea19df2144e2fee79668b2cc
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 7fea196ccb4e497960cb483cf8f5a612d0938fc2
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 04f79360c69abdddfa12eeefaab81bf039f24380
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 2ee0b454fda766bfb6a40cd52765aa5414eafe06
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 8fe1ee5818461652a8abef700cca60e6775dde44
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 d3e38fdf9e1016897c897ea0d22af34e915b1219
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 f293dfc18404a35679c62295ebf3d0f2d788f379
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 b2d359f095883d10b33e74a4a404363d2312830d
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 dc105d20122d20784d145216d0ed89929d5ceb0d
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 12eb4e7db22a5a3fc99a122b4b3a9f1b9723d7aa
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 c4ba982bd5084fa659ef518aaf159e4dab02ecda
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 71c142f910da44421213ade601bcbd23ceae19fa
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 cbeafa7a79d08ecdb55f8f1d41a11323d0f709db
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 38d432f4b391b734740d1493c8e64cb46fb6ca74
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 0853f905e48b92dcf27a8d931104c9aac10de191
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 4adc7d7ee640b0dcfffa0ee6d2aa24c1ffd74ff4
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 5877390da9115f865b274a1324cb41a06d990afe
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 e0199ce728fb98a96a20136a5edb11c160d3151f
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 7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9
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 10ef82d6e0af5536ec64770c07f6bbabfdd6977c
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 1daf72982efe833078c76bfa9bafad1a53569f63
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 cc983cf9ee395c6a944e415bbacf12a16be9c96c
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 729fea8aaf2c7d0e879b3599d056533c9beb0e10
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 2cd1adcb8c08fd1243c458ccdbb071fb442db39b
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 b5a0f17b03df93dd3587b1d0e733871ffa01843b
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 0b4a66eb96de8a16cb0295a23b03a479407ea666
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 e369420e1234e6e623daf6f8b03e30e34ed3e0d4
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 d21ffa548737822fe8c0a8b77bdb9ddbd71323eb
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 f36e754a1f0bafb9feeea63463de78080acb6de0
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 95b0f54f8a898072a2810c05fab34d971f23a612
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 55bfe858d0198379a0cfd6024dd4624b2c130a5a
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 368e68ad6da4317fc4170e8d92b51c13d1bfe7a7
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 4785574f0caf920ff0af587d4ab23f93cd243970
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 e7686d80fc3cfad24aad859c69069b00dd2e2875
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 89401b5e9cf3e9b416dd04a43dc9193264b388f1
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 547ebdc200b862dff761ff4890f66d8217c33316
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 98cf0cd959ef36eee86e84c00cedd40083073899
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 bc8fceda3b89006e8a7dda8a097d36045d044c25
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 feb0fb39695b9f627c3f15a39fea8ee090e2f8fc
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 d888753872190abd18f68a7d77b9c7c367f0a7ab
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 2cbfc38df580bff5b2fe19f21c1a7520efcc4b3b
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 3592cfd8b848bf0c4d7740d78a87a7b8f6e1fa9a
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 fef451f0fbbe85dbd2962b18379d02e2965610db
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 042915c1bfedd684c1d98a841794ee203200571a
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 04a8e39c8c9b4e3d5c3c4f14a629875cc79d232e
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 5f9b2e4ca88cab1a96b86ecd45544e488ca43faf
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 8a95696bdc0e13f8980f05b54a3b9081963d1256
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 ae60744d5fad840b9d056d35b4b652d95e755846
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 f89f6c3ebf69623b8ea48200bd690e9e210335a1
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 b10e1171341c61cad3004307ddf8ae8004fd207c
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 3692f17e703661058083c176284ca9bfb99236c9
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 8eb42d6d10f8fe509117859defddf9e72b4fa4d0
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 9f9ed31de4dd25cf11843d05388b12a49d7ca864
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 bd08704b8a4db95b181563ffaee59ffbbd2f1c9c
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 614d81bba75d3f63eed42ddf90188c1c64238457
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 f1fec5ccbe70ff8661ec7d16e523074ba81464e1
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 9c1fb2e93844f0425dc1228e82884c7589f0468a
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 9b18f01a5120785d9b07d8ea889920b7fd943784
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 e31d9ba169860687dba19bdc8fccbfd34077f655
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 e6b6f98fc7605c06c0a3baa70f62c534d7b4ce58
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 356f3d808e771a95556de6d037b5eb9ef5e2d30b
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 0e92af67f051560c8a446b7a76a7c72fd9fd998f
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 d2ebc436aab90b214b540024f843379330591fbc
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 65a5ea7cb9c7c79e38540a5c6e46675b49e04d92
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 1084716f76c8045eadf92a9d9a62641f3c8d8c90
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 85a055c03691e51499123194a14a0c249cf33227
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 59fa94cddf9eef8d8dae587373eed8b8f4eb11d7
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 6dda4426fa772672883c5f67f9e282b8a3e8a8df
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 71afd0ceb5b0b540f4475b2f1c0bdc5ced302d8f
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 761b4fa75205f563f177cdcb333abc1603932c0c
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 403659df77b633ade9eb14ab816ea18007eabdf5
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 54d6802c4d83fa8de7696cfec06f475d5fd92d27
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 3f4d5e727aeaa610688d46c9f101f78b7f712583
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 c926ae58f24f7bd55aa2ea4add9f952032507913
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 39475043ffbce37be8d904879a113f58b4312d1e
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 40e6078fcf186b4f452abcbffcb004e28d750395
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 23cb1fef93d2f77bad7e7b9d056ba3b9f8e101e3
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 e33d9bd563e71f6c6528b96008d65524a459c4dc
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 fb2962f9a1b4320c7548369609c81a9cd38d5178
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 888312dc297a8a103f6371ef668c7e04f57a7679
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 77b68c59f6c938424bf29ed0dc5d27732a635d30
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 ea26bf5eca1459b5a7824997d7823409ce38214e
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 7a60594efdd5dbe1b2ece5c38cdcadd0e25cd05e
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 f275989ad04159dbfc62cefb65ba9c5ba1d7c34f
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 73629859a99759c9ce88cdf19b5afbe185d5f4c8
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 bf65364cd74ce98aaa5a5e967a19cd9d0dc05278
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 291efcb6ff49d332e29e294abc7e558461b2ccae
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 fde5ff6ab6c745dc30e8aa8da5632b94ed1afca1
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Dec 29 09:58:44 2021 +0100

    drm/bridge: sn65dsi83: Fix an error handling path in sn65dsi83_probe()
    
    [ Upstream commit 6edf615618b8259f16eeb1df98f0ba0d2312c22e ]
    
    sn65dsi83_parse_dt() takes a reference on 'ctx->host_node' that must be
    released in the error handling path of this function and of the probe.
    This is only done in the remove function up to now.
    
    Fixes: ceb515ba29ba ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Robert Foss <robert.foss@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/4bc21aed4b60d3d5ac4b28d8b07a6fdd8da6a536.1640768126.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3fc8051ee061e31db13e2fe011e8e0b71a7f815
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 21c6ee673401048bbeebf31a74055446464914eb
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 b382115016c88a2356a6aace0091750a2bbb73ba
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 4211742f0f9e083188f4f0ada00d6eeeef31b7c7
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 ca02b9675532b464b4702af68cfda7ac13b91010
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 e4cf9982ff3e15570c237f48a68025b9888554e5
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 d4c2a041ed3ba114502d5ed6ace5b1a48d637a8e
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 7b5488f4721fed6e121e661e165bab06ae2f8675
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 ed9b34f616f93d56fbd253894a498278295d41eb
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 40426b4f08bc5a24ef7e95b52f637b23641d15d8
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 015e9831547e0c4ed167d194eb5da6cdccdc6792
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 99c09b298e47ebbe345a6da9f268b32a6b0f4582
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 fb0f1c5eb8d60b3e018ba7c87da249b52674ebe6
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 98dd53a92825747395649f54d23512a13c3ed471
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 6eb85cbd9ef8fd47c1044284cb132cd8e6fe8ea4
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 9b534640a2c6a8d88168febc82ec6d161184f2ec
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 c1c62c5fa9a345128f2f49cfb1abd5d9941747f3
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 e8864a3c9da9c3d4380f20a4c2d3de1afbbba6f8
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 1699ec1bfb59304a788901474f6bb003f7831b61
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 0a0539c524faf2c296040e55220931b7bd3f0183
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 340cf8272540dd275ad1e76b629a533c8d2ee768
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 29357883a89193863f3cc6a2c5e0b42ceb022761
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 92a930fcf4250fe961f6238b99af0bc405799f39
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 0fcb0b131cc90c8f523a293d84c58d0c7273c96f
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 73647a1f92d11af06ffd5c89f841a31efd6e48e8
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 0c6cd71caa7c2efbfc56a521495b435d93df4787
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 cedca5b2f08bc706ad426d45c022d50ab12d58d0
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 66e2bf4b2cefd0758bdcf47734e3471430c121db
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 a96cae49dcbb6fec141580f8ab8407918bce6c83
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 9983f49a994e82d7c6f30be3d8fa11cf7e6f932e
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 88cd232146207ff1d41dededed5e77c0d4438113
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 f7ca1989fd218c88c0d219c2ae8007d82750fbfb
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 4ddcfb7870cfbbb304f715c274e4e0f4072bb0c7
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 a6d0af6d329d73eefd270ca305dbae79af381b9c
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 e5a1557906da1592adfa577659dd76e411d4f989
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 4a333ec73dee15e860a56a0308b8b07f02e930e1
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 29e0872acbd176e30085cf1f16c77b9512611fb0
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 e3b9204c08a76ea687963f409f2d54dd8613ea7d
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 655aafaa80ca5527845eb3308d51706e6e129e24
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 4a45a7dcc55e358d7757e31bdf2d53891343737b
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 06cb7e134f8f4a11b66f1dbeb5f237412a0aeedc
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 5567d69b95b9c07e1c56f15cf0301251d12e5f97
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 7768d102b1431e449758777c39efb44fe1fdec98
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 3308676ec525901bf1656014003c443a60730a04
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 4d481469137d461c6b7479f51df9261f0f0522df
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 6005d36fbc82611a7a632265f75557d3063b8d4c
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 33a5c6009ab84b66c1839762b78bef89f2d7ad06
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 f95e24bf19e2733fa5d5b93cb6d06fd10ff5498b
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 d03edc02a7528da327156fdb3f6977f88bb5a2e4
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 8969c3b1051eadc9b016c0b2dcfc0eeadcfbf566
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 5ff2514e4fb55dcf3d88294686040ca73ea0c1a2
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 f61b9c8760af444a03640a5fb41b70fb178dafb4
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 ecc53e58596542791e82eff00702f8af7a313f70
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 a53131a69515dc170707df1ac17f3c4444169b87
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 c1df9cb756e5a9ba1841648c44ee5d92306b9c65
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 a4b7ef3b159805ba6be061d0cd2403d84b9b0063
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 b24ca1cf846273361d5bd73a35de95a486a54b6d
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 1e853f235a012c33b9e6f08db11639f82daa3b42
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 a67b46468ae923a9e61ee7d30486a3c759fa5475
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 8a04477f3be9c37e0427b62bec1e2b07b936b17d
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 f3274083975bba737c7e0458924018c7c5ebd436
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 460aa288c5cd0544dcf933a2f0ad0e8c6d2d35ff
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 7a4afd8a003d6abf1f5d159c2bb67e6b7cbde253
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 5487a135c903b6aca59ca3a6c0f26fd46edc7fcb
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 df6de52b80aa3b46f5ac804412355ffe2e1df93e
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 cdf1a683a01583bca4b618dd16223cbd6e462e21
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 40960520a94004a1ceca5470c2efbdc58b6197cc
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 fdffa4ad8f6bf1ece877edfb807f2b2c729d8578
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 002949a3aedbd6a9a41f4c438dbf308fa1ab34d7
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 8137c0e48bca041a7568e5f4d7baef951479f033
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 c11c1cdd4f0e2f02509e8f1c455956925567bf69
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 b1ca16ac17ad0f2838768e0d28e1105d2b41f2d6
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 da689ae549c5bee8a632586c58e044b98c302c55
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 954a7194b164ce45e5314f7797cb187a777db2f4
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 899c5aabd0a9cf4b1655b3dc91ba4c8c9472c6cd
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 899938f18093e9b8269c48b168d3e3024effa63a
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 8303f34e733f83661eece778aef35fb986117c52
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 4c96e6aeacf54d4c8c47beeb66c4a994cada0dc9
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 9a63ef418a4e44432b973cb49c4f4e6442393f1a
Author: Tony Lindgren <tony@atomide.com>
Date:   Thu May 12 16:15:06 2022 +0300

    tty: n_gsm: Fix packet data hex dump output
    
    [ Upstream commit 925ea0fa5277c1e6bb9e51955ef34eea9736c3d7 ]
    
    The module param debug for n_gsm uses KERN_INFO level, but the hexdump
    now uses KERN_DEBUG level. This started after commit 091cb0994edd
    ("lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds").
    We now use dynamic_hex_dump() unless DEBUG is set.
    
    This causes no packets to be seen with modprobe n_gsm debug=0x1f unlike
    earlier. Let's fix this by adding gsm_hex_dump_bytes() that calls
    print_hex_dump() with KERN_INFO to match what n_gsm is doing with the
    other debug related output.
    
    Fixes: 091cb0994edd ("lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds")
    Cc: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20220512131506.1216-1-tony@atomide.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80dfe1798aa01930afc4478ac602c93209717ed3
Author: Tony Lindgren <tony@atomide.com>
Date:   Thu Sep 30 09:06:24 2021 +0300

    tty: n_gsm: Don't ignore write return value in gsmld_output()
    
    [ Upstream commit 9136c68346d096697935b9840782f7051d5796c5 ]
    
    We currently have gsmld_output() ignore the return value from device
    write. This means we will lose packets if device write returns 0 or
    an error.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20210930060624.46523-1-tony@atomide.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 029983ea88e59f4c7dc0d56ade2b16d6b869bf94
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 e1928887219b09140c043eed13fbd30bf22bd68e
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 49f698e2205299224dbf4599e87ca1b1d78683c3
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Mon Dec 20 01:15:24 2021 +0000

    rtc: ftrtc010: Use platform_get_irq() to get the interrupt
    
    [ Upstream commit 05020a733b02cf7a474305e620fb306cd3abfe84 ]
    
    platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
    allocation of IRQ resources in DT core code, this causes an issue
    when using hierarchical interrupt domains using "interrupts" property
    in the node as this bypasses the hierarchical setup and messes up the
    irq chaining.
    
    In preparation for removal of static setup of IRQ resource from DT core
    code use platform_get_irq().
    
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/20211220011524.17206-1-prabhakar.mahadev-lad.rj@bp.renesas.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 865051de2d9eaa50630e055b73921ceaf3c4a7fc
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 fb60291c0fde137d0f6de5886a76da8b4c6fb272
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 604e35f704756842f7c3c392bf3771e9970a9a88
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 aab25b669cb9fd3698c2631be4435f4fe92d9e59
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 a6061695bb2be3535925279e20d59a0ce0718d64
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 cf824b95c12a1abacadbc2d069931963221a3414
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 fffde6d1c67920b5675402f1ce3eed3765c79e8e
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 fd18fb38d6a4c726390835d45aaef08e0ef6ccd9
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 b3983b1042e4ccbe46b958c793ff53cfcff49529
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 cbf9172eb657d36140188acf55238cd630cd0f3c
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 5157979d8c797f0732f89450d78cf19a003d2e61
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 90e2993c8d885e3e8e2580987873a1c83ff69b9a
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 ede2512937539b5f7042be8e6a5fd570c066f5e7
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 ee94d746867921a09af0b3412af46006eef63b63
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Sun Aug 29 15:43:53 2021 +0300

    pvpanic: Fix typos in the comments
    
    [ Upstream commit cc5b392d0f94f27743583140d819fa35a46899db ]
    
    Fix a few spelling typos in the comments.
    
    Reviewed-by: Mihai Carabas <mihai.carabas@oracle.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20210829124354.81653-2-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2ba56d55ceaed41912a85e1b9285a0f903731c2
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 276f7c6165bfd1a5e78cdb8afb5d7573b6fec8cd
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 31f3f2a598f6eb1917efc3b538af5b4813447188
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 7c7bc8b82fffb361e1ccb48517c44bf6e259e4b5
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 79f83f388ba302e13fb2c008e1deac7a748e9d33
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 4ff1449e8fd9e38d31d326c13d156c3f456ba72c
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 b94d40c792de7f0ceda6a2fd8a8dc0597eca6d22
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 eaf37bb6b4f7c48a5adaf1be4879107daf4d6024
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 12452c776090b448cd883ed3c2c6e99e18a136c1
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 3b687b407179bb96bad926ddfc49e095ae291c20
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 c25feda42f14ba14269916f6caee38d1d361de5c
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 c8eb1ea6e839adc7441c8000e51dabb794283cea
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 1c6e5dc3b639c96e6839a8d1b8e951923fdfd34a
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 603efacb71e31bfda94b05b3981c721d48cab204
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 c49c6a1bf02d3a2b5b72d151c3fee0f85a4f00eb
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 2c0079979df64912930c13c5ce1b909d2566f22a
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 52e848568aa37c649bce5e3b380362523825616e
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 10243224fd457dc5509dd929c162f8a1761bd18e
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 09ad026dac0e1a0eb228205bcd2610ff9362a25f
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 90ab34df66546c78209237086b6d7ed01d1ab2d7
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 51422046be504515eb5a591adf0f424b62f46804
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 433a689cadea30facdec69f22e4d2fe741eb1b41
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 b62bbf8a47534c60428f117ba73986e859a409e7
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 923d34ce069e8e51a4d003caa6b66a8cd6ecd0ed
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 c84fa729f8db9f86c0800515d6b72a56cceb15a7
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 f307bdb670187125ccdef0d7e95ab3a1e859cf87
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 da64f419d7f78272bfe40dde1262602d4ff6b32c
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 20e75f3c6e09cf345031a8b02c9b9bff0473b424
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 1aeeca2b8397e3805c16a4ff26bf3cc8485f9853
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 1deb5f87053ec4d5de080d4f6d3d6f5e6a9c8091
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 b34163bf9967a2794bda41fc651fd1e1c6688db4
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 9d919665a0895db7aa5f48741ed0d5f3ebfb8436
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>