commit bdc8a139fb2492af5ea7ad6ecce6f64645d0aa8d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Oct 26 13:15:49 2022 +0200

    Linux 4.9.331
    
    Link: https://lore.kernel.org/r/20221024112949.358278806@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02eb44028e8c05dc86b6d9d597a54db705e0b9d0
Author: Martin Liska <mliska@suse.cz>
Date:   Thu Oct 13 09:40:59 2022 +0200

    gcov: support GCC 12.1 and newer compilers
    
    commit 977ef30a7d888eeb52fb6908f99080f33e5309a8 upstream.
    
    Starting with GCC 12.1, the created .gcda format can't be read by gcov
    tool.  There are 2 significant changes to the .gcda file format that
    need to be supported:
    
    a) [gcov: Use system IO buffering]
       (23eb66d1d46a34cb28c4acbdf8a1deb80a7c5a05) changed that all sizes in
       the format are in bytes and not in words (4B)
    
    b) [gcov: make profile merging smarter]
       (72e0c742bd01f8e7e6dcca64042b9ad7e75979de) add a new checksum to the
       file header.
    
    Tested with GCC 7.5, 10.4, 12.2 and the current master.
    
    Link: https://lkml.kernel.org/r/624bda92-f307-30e9-9aaa-8cc678b2dfb2@suse.cz
    Signed-off-by: Martin Liska <mliska@suse.cz>
    Tested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a83ed01f2f5baa68d403bc7fdfe3d8463a25796d
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Thu Oct 13 14:50:28 2022 +0200

    thermal: intel_powerclamp: Use first online CPU as control_cpu
    
    commit 4bb7f6c2781e46fc5bd00475a66df2ea30ef330d upstream.
    
    Commit 68b99e94a4a2 ("thermal: intel_powerclamp: Use get_cpu() instead
    of smp_processor_id() to avoid crash") fixed an issue related to using
    smp_processor_id() in preemptible context by replacing it with a pair
    of get_cpu()/put_cpu(), but what is needed there really is any online
    CPU and not necessarily the one currently running the code.  Arguably,
    getting the one that's running the code in there is confusing.
    
    For this reason, simply give the control CPU role to the first online
    one which automatically will be CPU0 if it is online, so one check
    can be dropped from the code for an added benefit.
    
    Link: https://lore.kernel.org/linux-pm/20221011113646.GA12080@duo.ucw.cz/
    Fixes: 68b99e94a4a2 ("thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Chen Yu <yu.c.chen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68c34ce11ef23328692aa35fa6aaafdd75913100
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Dec 20 06:33:30 2021 -0800

    inet: fully convert sk->sk_rx_dst to RCU rules
    
    commit 8f905c0e7354ef261360fb7535ea079b1082c105 upstream.
    
    syzbot reported various issues around early demux,
    one being included in this changelog [1]
    
    sk->sk_rx_dst is using RCU protection without clearly
    documenting it.
    
    And following sequences in tcp_v4_do_rcv()/tcp_v6_do_rcv()
    are not following standard RCU rules.
    
    [a]    dst_release(dst);
    [b]    sk->sk_rx_dst = NULL;
    
    They look wrong because a delete operation of RCU protected
    pointer is supposed to clear the pointer before
    the call_rcu()/synchronize_rcu() guarding actual memory freeing.
    
    In some cases indeed, dst could be freed before [b] is done.
    
    We could cheat by clearing sk_rx_dst before calling
    dst_release(), but this seems the right time to stick
    to standard RCU annotations and debugging facilities.
    
    [1]
    BUG: KASAN: use-after-free in dst_check include/net/dst.h:470 [inline]
    BUG: KASAN: use-after-free in tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792
    Read of size 2 at addr ffff88807f1cb73a by task syz-executor.5/9204
    
    CPU: 0 PID: 9204 Comm: syz-executor.5 Not tainted 5.16.0-rc5-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
     print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247
     __kasan_report mm/kasan/report.c:433 [inline]
     kasan_report.cold+0x83/0xdf mm/kasan/report.c:450
     dst_check include/net/dst.h:470 [inline]
     tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792
     ip_rcv_finish_core.constprop.0+0x15de/0x1e80 net/ipv4/ip_input.c:340
     ip_list_rcv_finish.constprop.0+0x1b2/0x6e0 net/ipv4/ip_input.c:583
     ip_sublist_rcv net/ipv4/ip_input.c:609 [inline]
     ip_list_rcv+0x34e/0x490 net/ipv4/ip_input.c:644
     __netif_receive_skb_list_ptype net/core/dev.c:5508 [inline]
     __netif_receive_skb_list_core+0x549/0x8e0 net/core/dev.c:5556
     __netif_receive_skb_list net/core/dev.c:5608 [inline]
     netif_receive_skb_list_internal+0x75e/0xd80 net/core/dev.c:5699
     gro_normal_list net/core/dev.c:5853 [inline]
     gro_normal_list net/core/dev.c:5849 [inline]
     napi_complete_done+0x1f1/0x880 net/core/dev.c:6590
     virtqueue_napi_complete drivers/net/virtio_net.c:339 [inline]
     virtnet_poll+0xca2/0x11b0 drivers/net/virtio_net.c:1557
     __napi_poll+0xaf/0x440 net/core/dev.c:7023
     napi_poll net/core/dev.c:7090 [inline]
     net_rx_action+0x801/0xb40 net/core/dev.c:7177
     __do_softirq+0x29b/0x9c2 kernel/softirq.c:558
     invoke_softirq kernel/softirq.c:432 [inline]
     __irq_exit_rcu+0x123/0x180 kernel/softirq.c:637
     irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
     common_interrupt+0x52/0xc0 arch/x86/kernel/irq.c:240
     asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:629
    RIP: 0033:0x7f5e972bfd57
    Code: 39 d1 73 14 0f 1f 80 00 00 00 00 48 8b 50 f8 48 83 e8 08 48 39 ca 77 f3 48 39 c3 73 3e 48 89 13 48 8b 50 f8 48 89 38 49 8b 0e <48> 8b 3e 48 83 c3 08 48 83 c6 08 eb bc 48 39 d1 72 9e 48 39 d0 73
    RSP: 002b:00007fff8a413210 EFLAGS: 00000283
    RAX: 00007f5e97108990 RBX: 00007f5e97108338 RCX: ffffffff81d3aa45
    RDX: ffffffff81d3aa45 RSI: 00007f5e97108340 RDI: ffffffff81d3aa45
    RBP: 00007f5e97107eb8 R08: 00007f5e97108d88 R09: 0000000093c2e8d9
    R10: 0000000000000000 R11: 0000000000000000 R12: 00007f5e97107eb0
    R13: 00007f5e97108338 R14: 00007f5e97107ea8 R15: 0000000000000019
     </TASK>
    
    Allocated by task 13:
     kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38
     kasan_set_track mm/kasan/common.c:46 [inline]
     set_alloc_info mm/kasan/common.c:434 [inline]
     __kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:467
     kasan_slab_alloc include/linux/kasan.h:259 [inline]
     slab_post_alloc_hook mm/slab.h:519 [inline]
     slab_alloc_node mm/slub.c:3234 [inline]
     slab_alloc mm/slub.c:3242 [inline]
     kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3247
     dst_alloc+0x146/0x1f0 net/core/dst.c:92
     rt_dst_alloc+0x73/0x430 net/ipv4/route.c:1613
     ip_route_input_slow+0x1817/0x3a20 net/ipv4/route.c:2340
     ip_route_input_rcu net/ipv4/route.c:2470 [inline]
     ip_route_input_noref+0x116/0x2a0 net/ipv4/route.c:2415
     ip_rcv_finish_core.constprop.0+0x288/0x1e80 net/ipv4/ip_input.c:354
     ip_list_rcv_finish.constprop.0+0x1b2/0x6e0 net/ipv4/ip_input.c:583
     ip_sublist_rcv net/ipv4/ip_input.c:609 [inline]
     ip_list_rcv+0x34e/0x490 net/ipv4/ip_input.c:644
     __netif_receive_skb_list_ptype net/core/dev.c:5508 [inline]
     __netif_receive_skb_list_core+0x549/0x8e0 net/core/dev.c:5556
     __netif_receive_skb_list net/core/dev.c:5608 [inline]
     netif_receive_skb_list_internal+0x75e/0xd80 net/core/dev.c:5699
     gro_normal_list net/core/dev.c:5853 [inline]
     gro_normal_list net/core/dev.c:5849 [inline]
     napi_complete_done+0x1f1/0x880 net/core/dev.c:6590
     virtqueue_napi_complete drivers/net/virtio_net.c:339 [inline]
     virtnet_poll+0xca2/0x11b0 drivers/net/virtio_net.c:1557
     __napi_poll+0xaf/0x440 net/core/dev.c:7023
     napi_poll net/core/dev.c:7090 [inline]
     net_rx_action+0x801/0xb40 net/core/dev.c:7177
     __do_softirq+0x29b/0x9c2 kernel/softirq.c:558
    
    Freed by task 13:
     kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38
     kasan_set_track+0x21/0x30 mm/kasan/common.c:46
     kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
     ____kasan_slab_free mm/kasan/common.c:366 [inline]
     ____kasan_slab_free mm/kasan/common.c:328 [inline]
     __kasan_slab_free+0xff/0x130 mm/kasan/common.c:374
     kasan_slab_free include/linux/kasan.h:235 [inline]
     slab_free_hook mm/slub.c:1723 [inline]
     slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1749
     slab_free mm/slub.c:3513 [inline]
     kmem_cache_free+0xbd/0x5d0 mm/slub.c:3530
     dst_destroy+0x2d6/0x3f0 net/core/dst.c:127
     rcu_do_batch kernel/rcu/tree.c:2506 [inline]
     rcu_core+0x7ab/0x1470 kernel/rcu/tree.c:2741
     __do_softirq+0x29b/0x9c2 kernel/softirq.c:558
    
    Last potentially related work creation:
     kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38
     __kasan_record_aux_stack+0xf5/0x120 mm/kasan/generic.c:348
     __call_rcu kernel/rcu/tree.c:2985 [inline]
     call_rcu+0xb1/0x740 kernel/rcu/tree.c:3065
     dst_release net/core/dst.c:177 [inline]
     dst_release+0x79/0xe0 net/core/dst.c:167
     tcp_v4_do_rcv+0x612/0x8d0 net/ipv4/tcp_ipv4.c:1712
     sk_backlog_rcv include/net/sock.h:1030 [inline]
     __release_sock+0x134/0x3b0 net/core/sock.c:2768
     release_sock+0x54/0x1b0 net/core/sock.c:3300
     tcp_sendmsg+0x36/0x40 net/ipv4/tcp.c:1441
     inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819
     sock_sendmsg_nosec net/socket.c:704 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:724
     sock_write_iter+0x289/0x3c0 net/socket.c:1057
     call_write_iter include/linux/fs.h:2162 [inline]
     new_sync_write+0x429/0x660 fs/read_write.c:503
     vfs_write+0x7cd/0xae0 fs/read_write.c:590
     ksys_write+0x1ee/0x250 fs/read_write.c:643
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    The buggy address belongs to the object at ffff88807f1cb700
     which belongs to the cache ip_dst_cache of size 176
    The buggy address is located 58 bytes inside of
     176-byte region [ffff88807f1cb700, ffff88807f1cb7b0)
    The buggy address belongs to the page:
    page:ffffea0001fc72c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7f1cb
    flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)
    raw: 00fff00000000200 dead000000000100 dead000000000122 ffff8881413bb780
    raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_HARDWALL), pid 5, ts 108466983062, free_ts 108048976062
     prep_new_page mm/page_alloc.c:2418 [inline]
     get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4149
     __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5369
     alloc_pages+0x1a7/0x300 mm/mempolicy.c:2191
     alloc_slab_page mm/slub.c:1793 [inline]
     allocate_slab mm/slub.c:1930 [inline]
     new_slab+0x32d/0x4a0 mm/slub.c:1993
     ___slab_alloc+0x918/0xfe0 mm/slub.c:3022
     __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3109
     slab_alloc_node mm/slub.c:3200 [inline]
     slab_alloc mm/slub.c:3242 [inline]
     kmem_cache_alloc+0x35c/0x3a0 mm/slub.c:3247
     dst_alloc+0x146/0x1f0 net/core/dst.c:92
     rt_dst_alloc+0x73/0x430 net/ipv4/route.c:1613
     __mkroute_output net/ipv4/route.c:2564 [inline]
     ip_route_output_key_hash_rcu+0x921/0x2d00 net/ipv4/route.c:2791
     ip_route_output_key_hash+0x18b/0x300 net/ipv4/route.c:2619
     __ip_route_output_key include/net/route.h:126 [inline]
     ip_route_output_flow+0x23/0x150 net/ipv4/route.c:2850
     ip_route_output_key include/net/route.h:142 [inline]
     geneve_get_v4_rt+0x3a6/0x830 drivers/net/geneve.c:809
     geneve_xmit_skb drivers/net/geneve.c:899 [inline]
     geneve_xmit+0xc4a/0x3540 drivers/net/geneve.c:1082
     __netdev_start_xmit include/linux/netdevice.h:4994 [inline]
     netdev_start_xmit include/linux/netdevice.h:5008 [inline]
     xmit_one net/core/dev.c:3590 [inline]
     dev_hard_start_xmit+0x1eb/0x920 net/core/dev.c:3606
     __dev_queue_xmit+0x299a/0x3650 net/core/dev.c:4229
    page last free stack trace:
     reset_page_owner include/linux/page_owner.h:24 [inline]
     free_pages_prepare mm/page_alloc.c:1338 [inline]
     free_pcp_prepare+0x374/0x870 mm/page_alloc.c:1389
     free_unref_page_prepare mm/page_alloc.c:3309 [inline]
     free_unref_page+0x19/0x690 mm/page_alloc.c:3388
     qlink_free mm/kasan/quarantine.c:146 [inline]
     qlist_free_all+0x5a/0xc0 mm/kasan/quarantine.c:165
     kasan_quarantine_reduce+0x180/0x200 mm/kasan/quarantine.c:272
     __kasan_slab_alloc+0xa2/0xc0 mm/kasan/common.c:444
     kasan_slab_alloc include/linux/kasan.h:259 [inline]
     slab_post_alloc_hook mm/slab.h:519 [inline]
     slab_alloc_node mm/slub.c:3234 [inline]
     kmem_cache_alloc_node+0x255/0x3f0 mm/slub.c:3270
     __alloc_skb+0x215/0x340 net/core/skbuff.c:414
     alloc_skb include/linux/skbuff.h:1126 [inline]
     alloc_skb_with_frags+0x93/0x620 net/core/skbuff.c:6078
     sock_alloc_send_pskb+0x783/0x910 net/core/sock.c:2575
     mld_newpack+0x1df/0x770 net/ipv6/mcast.c:1754
     add_grhead+0x265/0x330 net/ipv6/mcast.c:1857
     add_grec+0x1053/0x14e0 net/ipv6/mcast.c:1995
     mld_send_initial_cr.part.0+0xf6/0x230 net/ipv6/mcast.c:2242
     mld_send_initial_cr net/ipv6/mcast.c:1232 [inline]
     mld_dad_work+0x1d3/0x690 net/ipv6/mcast.c:2268
     process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298
     worker_thread+0x658/0x11f0 kernel/workqueue.c:2445
    
    Memory state around the buggy address:
     ffff88807f1cb600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88807f1cb680: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
    >ffff88807f1cb700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                            ^
     ffff88807f1cb780: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
     ffff88807f1cb800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    Fixes: 41063e9dd119 ("ipv4: Early TCP socket demux.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20211220143330.680945-1-eric.dumazet@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [cmllamas: backported to 4.9; dropped irrelevant hunks in ipv6/udp.c;
     added rcu_access_pointer(sk->sk_rx_dst) in tcp_prequeue().]
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b6f5ec5e2a83feb33efa2af47d8e2c504e929d21
Author: Jerry Lee 李修賢 <jerrylee@qnap.com>
Date:   Mon Jul 18 10:25:19 2022 +0000

    ext4: continue to expand file system when the target size doesn't reach
    
    commit df3cb754d13d2cd5490db9b8d536311f8413a92e upstream.
    
    When expanding a file system from (16TiB-2MiB) to 18TiB, the operation
    exits early which leads to result inconsistency between resize2fs and
    Ext4 kernel driver.
    
    === before ===
    ○ → resize2fs /dev/mapper/thin
    resize2fs 1.45.5 (07-Jan-2020)
    Filesystem at /dev/mapper/thin is mounted on /mnt/test; on-line resizing required
    old_desc_blocks = 2048, new_desc_blocks = 2304
    The filesystem on /dev/mapper/thin is now 4831837696 (4k) blocks long.
    
    [  865.186308] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
    [  912.091502] dm-4: detected capacity change from 34359738368 to 38654705664
    [  970.030550] dm-5: detected capacity change from 34359734272 to 38654701568
    [ 1000.012751] EXT4-fs (dm-5): resizing filesystem from 4294966784 to 4831837696 blocks
    [ 1000.012878] EXT4-fs (dm-5): resized filesystem to 4294967296
    
    === after ===
    [  129.104898] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
    [  143.773630] dm-4: detected capacity change from 34359738368 to 38654705664
    [  198.203246] dm-5: detected capacity change from 34359734272 to 38654701568
    [  207.918603] EXT4-fs (dm-5): resizing filesystem from 4294966784 to 4831837696 blocks
    [  207.918754] EXT4-fs (dm-5): resizing filesystem from 4294967296 to 4831837696 blocks
    [  207.918758] EXT4-fs (dm-5): Converting file system to meta_bg
    [  207.918790] EXT4-fs (dm-5): resizing filesystem from 4294967296 to 4831837696 blocks
    [  221.454050] EXT4-fs (dm-5): resized to 4658298880 blocks
    [  227.634613] EXT4-fs (dm-5): resized filesystem to 4831837696
    
    Signed-off-by: Jerry Lee <jerrylee@qnap.com>
    Link: https://lore.kernel.org/r/PU1PR04MB22635E739BD21150DC182AC6A18C9@PU1PR04MB2263.apcprd04.prod.outlook.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b22801fe33666ffb9b64982d40d7d0ee85f8cd1f
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Tue Oct 4 21:47:50 2022 -0400

    net/ieee802154: don't warn zero-sized raw_sendmsg()
    
    [ Upstream commit b12e924a2f5b960373459c8f8a514f887adf5cac ]
    
    syzbot is hitting skb_assert_len() warning at __dev_queue_xmit() [1],
    for PF_IEEE802154 socket's zero-sized raw_sendmsg() request is hitting
    __dev_queue_xmit() with skb->len == 0.
    
    Since PF_IEEE802154 socket's zero-sized raw_sendmsg() request was
    able to return 0, don't call __dev_queue_xmit() if packet length is 0.
    
      ----------
      #include <sys/socket.h>
      #include <netinet/in.h>
    
      int main(int argc, char *argv[])
      {
        struct sockaddr_in addr = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
        struct iovec iov = { };
        struct msghdr hdr = { .msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = &iov, .msg_iovlen = 1 };
        sendmsg(socket(PF_IEEE802154, SOCK_RAW, 0), &hdr, 0);
        return 0;
      }
      ----------
    
    Note that this might be a sign that commit fd1894224407c484 ("bpf: Don't
    redirect packets with invalid pkt_len") should be reverted, for
    skb->len == 0 was acceptable for at least PF_IEEE802154 socket.
    
    Link: https://syzkaller.appspot.com/bug?extid=5ea725c25d06fb9114c4 [1]
    Reported-by: syzbot <syzbot+5ea725c25d06fb9114c4@syzkaller.appspotmail.com>
    Fixes: fd1894224407c484 ("bpf: Don't redirect packets with invalid pkt_len")
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20221005014750.3685555-2-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33908a3cadd4e511ae61fe09b6ec0be4998131af
Author: Alexander Aring <aahringo@redhat.com>
Date:   Wed Oct 5 22:02:37 2022 -0400

    net: ieee802154: return -EINVAL for unknown addr type
    
    commit 30393181fdbc1608cc683b4ee99dcce05ffcc8c7 upstream.
    
    This patch adds handling to return -EINVAL for an unknown addr type. The
    current behaviour is to return 0 as successful but the size of an
    unknown addr type is not defined and should return an error like -EINVAL.
    
    Fixes: 94160108a70c ("net/ieee802154: fix uninit value bug in dgram_sendmsg")
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 41aeefb7e51a95a5348ee609750a7e83e1dce1e0
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Wed Oct 12 11:22:58 2022 +0300

    perf intel-pt: Fix segfault in intel_pt_print_info() with uClibc
    
    commit 5a3d47071f0ced0431ef82a5fb6bd077ed9493db upstream.
    
    uClibc segfaulted because NULL was passed as the format to fprintf().
    
    That happened because one of the format strings was missing and
    intel_pt_print_info() didn't check that before calling fprintf().
    
    Add the missing format string, and check format is not NULL before calling
    fprintf().
    
    Fixes: 11fa7cb86b56d361 ("perf tools: Pass Intel PT information for decoding MTC and CYC")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20221012082259.22394-2-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3304a6df957cc89a0590cb505388d659bf3db4c
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Thu Sep 22 21:48:44 2022 +0800

    usb: idmouse: fix an uninit-value in idmouse_open
    
    [ Upstream commit bce2b0539933e485d22d6f6f076c0fcd6f185c4c ]
    
    In idmouse_create_image, if any ftip_command fails, it will
    go to the reset label. However, this leads to the data in
    bulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the check
    for valid image incurs an uninitialized dereference.
    
    Fix this by moving the check before reset label since this
    check only be valid if the data after bulk_in_buffer[HEADER]
    has concrete data.
    
    Note that this is found by KMSAN, so only kernel compilation
    is tested.
    
    Reported-by: syzbot+79832d33eb89fb3cd092@syzkaller.appspotmail.com
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Link: https://lore.kernel.org/r/20220922134847.1101921-1-dzm91@hust.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f214204d240634583a2ad9c7d6d79bfa54a8f9d
Author: sunghwan jung <onenowy@gmail.com>
Date:   Tue Sep 13 20:49:13 2022 +0900

    Revert "usb: storage: Add quirk for Samsung Fit flash"
    
    [ Upstream commit ad5dbfc123e6ffbbde194e2a4603323e09f741ee ]
    
    This reverts commit 86d92f5465958752481269348d474414dccb1552,
    which fix the timeout issue for "Samsung Fit Flash".
    
    But the commit affects not only "Samsung Fit Flash" but also other usb
    storages that use the same controller and causes severe performance
    regression.
    
     # hdparm -t /dev/sda (without the quirk)
     Timing buffered disk reads: 622 MB in  3.01 seconds = 206.66 MB/sec
    
     # hdparm -t /dev/sda (with the quirk)
     Timing buffered disk reads: 220 MB in  3.00 seconds =  73.32 MB/sec
    
    The commit author mentioned that "Issue was reproduced after device has
    bad block", so this quirk should be applied when we have the timeout
    issue with a device that has bad blocks.
    
    We revert the commit so that we apply this quirk by adding kernel
    paramters using a bootloader or other ways when we really need it,
    without the performance regression with devices that don't have the
    issue.
    
    Signed-off-by: sunghwan jung <onenowy@gmail.com>
    Link: https://lore.kernel.org/r/20220913114913.3073-1-onenowy@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 826f84ab04a5cafe484ea9c2c85a3930068e5cb7
Author: Robin Guo <guoweibin@inspur.com>
Date:   Tue Sep 6 10:21:19 2022 +0800

    usb: musb: Fix musb_gadget.c rxstate overflow bug
    
    [ Upstream commit eea4c860c3b366369eff0489d94ee4f0571d467d ]
    
    The usb function device call musb_gadget_queue() adds the passed
    request to musb_ep::req_list,If the (request->length > musb_ep->packet_sz)
    and (is_buffer_mapped(req) return false),the rxstate() will copy all data
    in fifo to request->buf which may cause request->buf out of bounds.
    
    Fix it by add the length check :
    fifocnt = min_t(unsigned, request->length - request->actual, fifocnt);
    
    Signed-off-by: Robin Guo <guoweibin@inspur.com>
    Link: https://lore.kernel.org/r/20220906102119.1b071d07a8391ff115e6d1ef@inspur.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7fc6bab3413e6a42bb1264ff7c9149808c93a4c7
Author: Jianglei Nie <niejianglei2021@163.com>
Date:   Wed Sep 21 15:34:45 2022 +0300

    usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()
    
    [ Upstream commit 7e271f42a5cc3768cd2622b929ba66859ae21f97 ]
    
    xhci_alloc_stream_info() allocates stream context array for stream_info
    ->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,
    stream_info->stream_ctx_array is not released, which will lead to a
    memory leak.
    
    We can fix it by releasing the stream_info->stream_ctx_array with
    xhci_free_stream_ctx() on the error path to avoid the potential memory
    leak.
    
    Signed-off-by: Jianglei Nie <niejianglei2021@163.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20220921123450.671459-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84607bd3a8542b84b450d19a3579172f96c2bb47
Author: Hyunwoo Kim <imv4bel@gmail.com>
Date:   Sun Sep 4 12:31:15 2022 -0700

    HID: roccat: Fix use-after-free in roccat_read()
    
    [ Upstream commit cacdb14b1c8d3804a3a7d31773bc7569837b71a4 ]
    
    roccat_report_event() is responsible for registering
    roccat-related reports in struct roccat_device.
    
    int roccat_report_event(int minor, u8 const *data)
    {
            struct roccat_device *device;
            struct roccat_reader *reader;
            struct roccat_report *report;
            uint8_t *new_value;
    
            device = devices[minor];
    
            new_value = kmemdup(data, device->report_size, GFP_ATOMIC);
            if (!new_value)
                    return -ENOMEM;
    
            report = &device->cbuf[device->cbuf_end];
    
            /* passing NULL is safe */
            kfree(report->value);
            ...
    
    The registered report is stored in the struct roccat_device member
    "struct roccat_report cbuf[ROCCAT_CBUF_SIZE];".
    If more reports are received than the "ROCCAT_CBUF_SIZE" value,
    kfree() the saved report from cbuf[0] and allocates a new reprot.
    Since there is no lock when this kfree() is performed,
    kfree() can be performed even while reading the saved report.
    
    static ssize_t roccat_read(struct file *file, char __user *buffer,
                    size_t count, loff_t *ppos)
    {
            struct roccat_reader *reader = file->private_data;
            struct roccat_device *device = reader->device;
            struct roccat_report *report;
            ssize_t retval = 0, len;
            DECLARE_WAITQUEUE(wait, current);
    
            mutex_lock(&device->cbuf_lock);
    
            ...
    
            report = &device->cbuf[reader->cbuf_start];
            /*
             * If report is larger than requested amount of data, rest of report
             * is lost!
             */
            len = device->report_size > count ? count : device->report_size;
    
            if (copy_to_user(buffer, report->value, len)) {
                    retval = -EFAULT;
                    goto exit_unlock;
            }
            ...
    
    The roccat_read() function receives the device->cbuf report and
    delivers it to the user through copy_to_user().
    If the N+ROCCAT_CBUF_SIZE th report is received while copying of
    the Nth report->value is in progress, the pointer that copy_to_user()
    is working on is kfree()ed and UAF read may occur. (race condition)
    
    Since the device node of this driver does not set separate permissions,
    this is not a security vulnerability, but because it is used for
    requesting screen display of profile or dpi settings,
    a user using the roccat device can apply udev to this device node or
    There is a possibility to use it by giving.
    
    Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ddb6b1906f92a2511775faf9b67cd555c9e0763e
Author: Letu Ren <fantasquex@gmail.com>
Date:   Mon Aug 29 19:01:15 2022 +0800

    scsi: 3w-9xxx: Avoid disabling device if failing to enable it
    
    [ Upstream commit 7eff437b5ee1309b34667844361c6bbb5c97df05 ]
    
    The original code will "goto out_disable_device" and call
    pci_disable_device() if pci_enable_device() fails. The kernel will generate
    a warning message like "3w-9xxx 0000:00:05.0: disabling already-disabled
    device".
    
    We shouldn't disable a device that failed to be enabled. A simple return is
    fine.
    
    Link: https://lore.kernel.org/r/20220829110115.38789-1-fantasquex@gmail.com
    Reported-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Letu Ren <fantasquex@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c76d04d2079a4b7369ce9a0e859c0f3f2250bcc1
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Thu Jul 28 04:23:38 2022 +0200

    media: cx88: Fix a null-ptr-deref bug in buffer_prepare()
    
    [ Upstream commit 2b064d91440b33fba5b452f2d1b31f13ae911d71 ]
    
    When the driver calls cx88_risc_buffer() to prepare the buffer, the
    function call may fail, resulting in a empty buffer and null-ptr-deref
    later in buffer_queue().
    
    The following log can reveal it:
    
    [   41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
    [   41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    [   41.828027] RIP: 0010:buffer_queue+0xc2/0x500
    [   41.836311] Call Trace:
    [   41.836945]  __enqueue_in_driver+0x141/0x360
    [   41.837262]  vb2_start_streaming+0x62/0x4a0
    [   41.838216]  vb2_core_streamon+0x1da/0x2c0
    [   41.838516]  __vb2_init_fileio+0x981/0xbc0
    [   41.839141]  __vb2_perform_fileio+0xbf9/0x1120
    [   41.840072]  vb2_fop_read+0x20e/0x400
    [   41.840346]  v4l2_read+0x215/0x290
    [   41.840603]  vfs_read+0x162/0x4c0
    
    Fix this by checking the return value of cx88_risc_buffer()
    
    [hverkuil: fix coding style issues]
    
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec3738db5af0f716c2c61ee9b707d83ef76b4855
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Fri Aug 26 07:53:34 2022 +0200

    ARM: dts: imx6sl: add missing properties for sram
    
    [ Upstream commit 60c9213a1d9941a8b33db570796c3f9be8984974 ]
    
    All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
    sram@900000: '#address-cells' is a required property
    sram@900000: '#size-cells' is a required property
    sram@900000: 'ranges' is a required property
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a50659ef0e5cae890ce5fe08d9e97eafd6ce5976
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Fri Aug 26 07:53:33 2022 +0200

    ARM: dts: imx6qp: add missing properties for sram
    
    [ Upstream commit 088fe5237435ee2f7ed4450519b2ef58b94c832f ]
    
    All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
    sram@940000: '#address-cells' is a required property
    sram@940000: '#size-cells' is a required property
    sram@940000: 'ranges' is a required property
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b60b11b984e849216f507327b831d77b412254d
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Fri Aug 26 07:53:32 2022 +0200

    ARM: dts: imx6dl: add missing properties for sram
    
    [ Upstream commit f5848b95633d598bacf0500e0108dc5961af88c0 ]
    
    All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
    sram@900000: '#address-cells' is a required property
    sram@900000: '#size-cells' is a required property
    sram@900000: 'ranges' is a required property
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 699c156139a4945f13d0d8adfbb0691e4d22a28c
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Fri Aug 26 07:53:31 2022 +0200

    ARM: dts: imx6q: add missing properties for sram
    
    [ Upstream commit b11d083c5dcec7c42fe982c854706d404ddd3a5f ]
    
    All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
    sram@900000: '#address-cells' is a required property
    sram@900000: '#size-cells' is a required property
    sram@900000: 'ranges' is a required property
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e6fd866dfd474c44dfcdc140408a19189cb3787
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Mon Jul 25 18:16:22 2022 +0800

    ARM: dts: imx7d-sdb: config the max pressure for tsc2046
    
    [ Upstream commit e7c4ebe2f9cd68588eb24ba4ed122e696e2d5272 ]
    
    Use the general touchscreen method to config the max pressure for
    touch tsc2046(data sheet suggest 8 bit pressure), otherwise, for
    ABS_PRESSURE, when config the same max and min value, weston will
    meet the following issue,
    
    [17:19:39.183] event1  - ADS7846 Touchscreen: is tagged by udev as: Touchscreen
    [17:19:39.183] event1  - ADS7846 Touchscreen: kernel bug: device has min == max on ABS_PRESSURE
    [17:19:39.183] event1  - ADS7846 Touchscreen: was rejected
    [17:19:39.183] event1  - not using input device '/dev/input/event1'
    
    This will then cause the APP weston-touch-calibrator can't list touch devices.
    
    root@imx6ul7d:~# weston-touch-calibrator
    could not load cursor 'dnd-move'
    could not load cursor 'dnd-copy'
    could not load cursor 'dnd-none'
    No devices listed.
    
    And accroding to binding Doc, "ti,x-max", "ti,y-max", "ti,pressure-max"
    belong to the deprecated properties, so remove them. Also for "ti,x-min",
    "ti,y-min", "ti,x-plate-ohms", the value set in dts equal to the default
    value in driver, so are redundant, also remove here.
    
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a3474e7368e983ee0017c016d434529b83612f1
Author: hongao <hongao@uniontech.com>
Date:   Tue Sep 20 17:24:53 2022 +0800

    drm/amdgpu: fix initial connector audio value
    
    [ Upstream commit 4bb71fce58f30df3f251118291d6b0187ce531e6 ]
    
    This got lost somewhere along the way, This fixes
    audio not working until set_property was called.
    
    Signed-off-by: hongao <hongao@uniontech.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f38ad4587b0a10c176a02baeb7d3a97a96aef154
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Sep 17 23:04:07 2022 +0200

    platform/x86: msi-laptop: Change DMI match / alias strings to fix module autoloading
    
    [ Upstream commit 2a2565272a3628e45d61625e36ef17af7af4e3de ]
    
    On a MSI S270 with Fedora 37 x86_64 / systemd-251.4 the module does not
    properly autoload.
    
    This is likely caused by issues with how systemd-udevd handles the single
    quote char (') which is part of the sys_vendor / chassis_vendor strings
    on this laptop. As a workaround remove the single quote char + everything
    behind it from the sys_vendor + chassis_vendor matches. This fixes
    the module not autoloading.
    
    Link: https://github.com/systemd/systemd/issues/24715
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20220917210407.647432-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d213914386a0ede76a4549b41de30192fb92c595
Author: Javier Martinez Canillas <javierm@redhat.com>
Date:   Tue Jul 5 12:02:14 2022 +0200

    drm: Prevent drm_copy_field() to attempt copying a NULL pointer
    
    [ Upstream commit f6ee30407e883042482ad4ad30da5eaba47872ee ]
    
    There are some struct drm_driver fields that are required by drivers since
    drm_copy_field() attempts to copy them to user-space via DRM_IOCTL_VERSION.
    
    But it can be possible that a driver has a bug and did not set some of the
    fields, which leads to drm_copy_field() attempting to copy a NULL pointer:
    
    [ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000
    [  +0.010955] Mem abort info:
    [  +0.002835]   ESR = 0x0000000096000004
    [  +0.003872]   EC = 0x25: DABT (current EL), IL = 32 bits
    [  +0.005395]   SET = 0, FnV = 0
    [  +0.003113]   EA = 0, S1PTW = 0
    [  +0.003182]   FSC = 0x04: level 0 translation fault
    [  +0.004964] Data abort info:
    [  +0.002919]   ISV = 0, ISS = 0x00000004
    [  +0.003886]   CM = 0, WnR = 0
    [  +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000
    [  +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
    [  +0.006925] Internal error: Oops: 96000004 [#1] SMP
    ...
    [  +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [  +0.007061] pc : __pi_strlen+0x14/0x150
    [  +0.003895] lr : drm_copy_field+0x30/0x1a4
    [  +0.004156] sp : ffff8000094b3a50
    [  +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040
    [  +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040
    [  +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000
    [  +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000
    [  +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40
    [  +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
    [  +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8
    [  +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141
    [  +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
    [  +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000
    [  +0.007240] Call trace:
    [  +0.002475]  __pi_strlen+0x14/0x150
    [  +0.003537]  drm_version+0x84/0xac
    [  +0.003448]  drm_ioctl_kernel+0xa8/0x16c
    [  +0.003975]  drm_ioctl+0x270/0x580
    [  +0.003448]  __arm64_sys_ioctl+0xb8/0xfc
    [  +0.003978]  invoke_syscall+0x78/0x100
    [  +0.003799]  el0_svc_common.constprop.0+0x4c/0xf4
    [  +0.004767]  do_el0_svc+0x38/0x4c
    [  +0.003357]  el0_svc+0x34/0x100
    [  +0.003185]  el0t_64_sync_handler+0x11c/0x150
    [  +0.004418]  el0t_64_sync+0x190/0x194
    [  +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02)
    [  +0.006180] ---[ end trace 0000000000000000 ]---
    
    Reported-by: Peter Robinson <pbrobinson@gmail.com>
    Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
    Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220705100215.572498-3-javierm@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 12753d7a2cebca5affd9298ae17cfab950e64f5d
Author: Javier Martinez Canillas <javierm@redhat.com>
Date:   Tue Jul 5 12:02:13 2022 +0200

    drm: Use size_t type for len variable in drm_copy_field()
    
    [ Upstream commit 94dc3471d1b2b58b3728558d0e3f264e9ce6ff59 ]
    
    The strlen() function returns a size_t which is an unsigned int on 32-bit
    arches and an unsigned long on 64-bit arches. But in the drm_copy_field()
    function, the strlen() return value is assigned to an 'int len' variable.
    
    Later, the len variable is passed as copy_from_user() third argument that
    is an unsigned long parameter as well.
    
    In theory, this can lead to an integer overflow via type conversion. Since
    the assignment happens to a signed int lvalue instead of a size_t lvalue.
    
    In practice though, that's unlikely since the values copied are set by DRM
    drivers and not controlled by userspace. But using a size_t for len is the
    correct thing to do anyways.
    
    Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
    Tested-by: Peter Robinson <pbrobinson@gmail.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220705100215.572498-2-javierm@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3723658c287a98875f43cffc3245d0bf1d3ee076
Author: Andrew Gaul <gaul@gaul.org>
Date:   Sun Oct 2 12:41:28 2022 +0900

    r8152: Rate limit overflow messages
    
    [ Upstream commit 93e2be344a7db169b7119de21ac1bf253b8c6907 ]
    
    My system shows almost 10 million of these messages over a 24-hour
    period which pollutes my logs.
    
    Signed-off-by: Andrew Gaul <gaul@google.com>
    Link: https://lore.kernel.org/r/20221002034128.2026653-1-gaul@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11e40d6c0823f699d8ad501e48d1c3ae4be386cd
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Sep 29 13:27:13 2022 -0700

    Bluetooth: L2CAP: Fix user-after-free
    
    [ Upstream commit 35fcbc4243aad7e7d020b7c1dfb14bb888b20a4f ]
    
    This uses l2cap_chan_hold_unless_zero() after calling
    __l2cap_get_chan_blah() to prevent the following trace:
    
    Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref
    *kref)
    Bluetooth: chan 0000000023c4974d
    Bluetooth: parent 00000000ae861c08
    ==================================================================
    BUG: KASAN: use-after-free in __mutex_waiter_is_first
    kernel/locking/mutex.c:191 [inline]
    BUG: KASAN: use-after-free in __mutex_lock_common
    kernel/locking/mutex.c:671 [inline]
    BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400
    kernel/locking/mutex.c:729
    Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389
    
    Link: https://lore.kernel.org/lkml/20220622082716.478486-1-lee.jones@linaro.org
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da0d3649eac4402249759928cea99033ca31deeb
Author: Daniel Golle <daniel@makrotopia.org>
Date:   Sat Sep 17 21:28:29 2022 +0100

    wifi: rt2x00: don't run Rt5592 IQ calibration on MT7620
    
    [ Upstream commit d3aad83d05aec0cfd7670cf0028f2ad4b81de92e ]
    
    The function rt2800_iq_calibrate is intended for Rt5592 only.
    Don't call it for MT7620 which has it's own calibration functions.
    
    Reported-by: Serge Vasilugin <vasilugin@yandex.ru>
    Signed-off-by: Daniel Golle <daniel@makrotopia.org>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/31a1c34ddbd296b82f38c18c9ae7339059215fdc.1663445157.git.daniel@makrotopia.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 56761647ebba71bffc40e2b89c48b3ff37b1be93
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Thu Sep 15 09:55:56 2022 +0800

    can: bcm: check the result of can_send() in bcm_can_tx()
    
    [ Upstream commit 3fd7bfd28cfd68ae80a2fe92ea1615722cc2ee6e ]
    
    If can_send() fail, it should not update frames_abs counter
    in bcm_can_tx(). Add the result check for can_send() in bcm_can_tx().
    
    Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Link: https://lore.kernel.org/all/9851878e74d6d37aee2f1ee76d68361a46f89458.1663206163.git.william.xuanziyang@huawei.com
    Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4bcefec3636208b4c97536b26014d5935d5c10a0
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Sep 19 10:56:59 2022 -0700

    Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times
    
    [ Upstream commit 448a496f760664d3e2e79466aa1787e6abc922b5 ]
    
    device_add shall not be called multiple times as stated in its
    documentation:
    
     'Do not call this routine or device_register() more than once for
     any device structure'
    
    Syzkaller reports a bug as follows [1]:
    ------------[ cut here ]------------
    kernel BUG at lib/list_debug.c:33!
    invalid opcode: 0000 [#1] PREEMPT SMP KASAN
    [...]
    Call Trace:
     <TASK>
     __list_add include/linux/list.h:69 [inline]
     list_add_tail include/linux/list.h:102 [inline]
     kobj_kset_join lib/kobject.c:164 [inline]
     kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214
     kobject_add_varg lib/kobject.c:358 [inline]
     kobject_add+0x150/0x1c0 lib/kobject.c:410
     device_add+0x368/0x1e90 drivers/base/core.c:3452
     hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53
     hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799
     hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110
     hci_event_func net/bluetooth/hci_event.c:7440 [inline]
     hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495
     hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007
     process_one_work+0x991/0x1610 kernel/workqueue.c:2289
     worker_thread+0x665/0x1080 kernel/workqueue.c:2436
     kthread+0x2e4/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
     </TASK>
    
    Link: https://syzkaller.appspot.com/bug?id=da3246e2d33afdb92d66bc166a0934c5b146404a
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Tested-by: Hawkins Jiawei <yin31149@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09b5325966298dd56cc04cb0ae6241009a568a40
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Sun Sep 4 00:32:56 2022 +0900

    Bluetooth: L2CAP: initialize delayed works at l2cap_chan_create()
    
    [ Upstream commit 2d2cb3066f2c90cd8ca540b36ba7a55e7f2406e0 ]
    
    syzbot is reporting cancel_delayed_work() without INIT_DELAYED_WORK() at
    l2cap_chan_del() [1], for CONF_NOT_COMPLETE flag (which meant to prevent
    l2cap_chan_del() from calling cancel_delayed_work()) is cleared by timer
    which fires before l2cap_chan_del() is called by closing file descriptor
    created by socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_L2CAP).
    
    l2cap_bredr_sig_cmd(L2CAP_CONF_REQ) and l2cap_bredr_sig_cmd(L2CAP_CONF_RSP)
    are calling l2cap_ertm_init(chan), and they call l2cap_chan_ready() (which
    clears CONF_NOT_COMPLETE flag) only when l2cap_ertm_init(chan) succeeded.
    
    l2cap_sock_init() does not call l2cap_ertm_init(chan), and it instead sets
    CONF_NOT_COMPLETE flag by calling l2cap_chan_set_defaults(). However, when
    connect() is requested, "command 0x0409 tx timeout" happens after 2 seconds
     from connect() request, and CONF_NOT_COMPLETE flag is cleared after 4
    seconds from connect() request, for l2cap_conn_start() from
    l2cap_info_timeout() callback scheduled by
    
      schedule_delayed_work(&conn->info_timer, L2CAP_INFO_TIMEOUT);
    
    in l2cap_connect() is calling l2cap_chan_ready().
    
    Fix this problem by initializing delayed works used by L2CAP_MODE_ERTM
    mode as soon as l2cap_chan_create() allocates a channel, like I did in
    commit be8597239379f0f5 ("Bluetooth: initialize skb_queue_head at
    l2cap_chan_create()").
    
    Link: https://syzkaller.appspot.com/bug?extid=83672956c7aa6af698b3 [1]
    Reported-by: syzbot <syzbot+83672956c7aa6af698b3@syzkaller.appspotmail.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit debca61df6bc2f65e020656c9c5b878d6b38d30f
Author: Khalid Masum <khalid.masum.92@gmail.com>
Date:   Thu Sep 1 13:12:10 2022 +0600

    xfrm: Update ipcomp_scratches with NULL when freed
    
    [ Upstream commit 8a04d2fc700f717104bfb95b0f6694e448a4537f ]
    
    Currently if ipcomp_alloc_scratches() fails to allocate memory
    ipcomp_scratches holds obsolete address. So when we try to free the
    percpu scratches using ipcomp_free_scratches() it tries to vfree non
    existent vm area. Described below:
    
    static void * __percpu *ipcomp_alloc_scratches(void)
    {
            ...
            scratches = alloc_percpu(void *);
            if (!scratches)
                    return NULL;
    ipcomp_scratches does not know about this allocation failure.
    Therefore holding the old obsolete address.
            ...
    }
    
    So when we free,
    
    static void ipcomp_free_scratches(void)
    {
            ...
            scratches = ipcomp_scratches;
    Assigning obsolete address from ipcomp_scratches
    
            if (!scratches)
                    return;
    
            for_each_possible_cpu(i)
                   vfree(*per_cpu_ptr(scratches, i));
    Trying to free non existent page, causing warning: trying to vfree
    existent vm area.
            ...
    }
    
    Fix this breakage by updating ipcomp_scrtches with NULL when scratches
    is freed
    
    Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
    Reported-by: syzbot+5ec9bb042ddfe9644773@syzkaller.appspotmail.com
    Tested-by: syzbot+5ec9bb042ddfe9644773@syzkaller.appspotmail.com
    Signed-off-by: Khalid Masum <khalid.masum.92@gmail.com>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df778ecd470c812811cceb2d07305390a9a54f67
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 22 21:15:28 2022 +0000

    tcp: annotate data-race around tcp_md5sig_pool_populated
    
    [ Upstream commit aacd467c0a576e5e44d2de4205855dc0fe43f6fb ]
    
    tcp_md5sig_pool_populated can be read while another thread
    changes its value.
    
    The race has no consequence because allocations
    are protected with tcp_md5sig_mutex.
    
    This patch adds READ_ONCE() and WRITE_ONCE() to document
    the race and silence KCSAN.
    
    Reported-by: Abhishek Shah <abhishek.shah@columbia.edu>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c973b81482854e3f5e6329c9dbfff22b36f6404
Author: Mike Pattrick <mkp@redhat.com>
Date:   Wed Aug 17 11:06:35 2022 -0400

    openvswitch: Fix overreporting of drops in dropwatch
    
    [ Upstream commit c21ab2afa2c64896a7f0e3cbc6845ec63dcfad2e ]
    
    Currently queue_userspace_packet will call kfree_skb for all frames,
    whether or not an error occurred. This can result in a single dropped
    frame being reported as multiple drops in dropwatch. This functions
    caller may also call kfree_skb in case of an error. This patch will
    consume the skbs instead and allow caller's to use kfree_skb.
    
    Signed-off-by: Mike Pattrick <mkp@redhat.com>
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2109957
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 508a9b8a8cca99aa67c9edc097f567763bfc0971
Author: Mike Pattrick <mkp@redhat.com>
Date:   Wed Aug 17 11:06:34 2022 -0400

    openvswitch: Fix double reporting of drops in dropwatch
    
    [ Upstream commit 1100248a5c5ccd57059eb8d02ec077e839a23826 ]
    
    Frames sent to userspace can be reported as dropped in
    ovs_dp_process_packet, however, if they are dropped in the netlink code
    then netlink_attachskb will report the same frame as dropped.
    
    This patch checks for error codes which indicate that the frame has
    already been freed.
    
    Signed-off-by: Mike Pattrick <mkp@redhat.com>
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2109946
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e799e815097febbcb81b472285be824f5d089f9
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Tue Sep 20 04:06:57 2022 -0700

    thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash
    
    [ Upstream commit 68b99e94a4a2db6ba9b31fe0485e057b9354a640 ]
    
    When CPU 0 is offline and intel_powerclamp is used to inject
    idle, it generates kernel BUG:
    
    BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687
    caller is debug_smp_processor_id+0x17/0x20
    CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57
    Call Trace:
    <TASK>
    dump_stack_lvl+0x49/0x63
    dump_stack+0x10/0x16
    check_preemption_disabled+0xdd/0xe0
    debug_smp_processor_id+0x17/0x20
    powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]
    ...
    ...
    
    Here CPU 0 is the control CPU by default and changed to the current CPU,
    if CPU 0 offlined. This check has to be performed under cpus_read_lock(),
    hence the above warning.
    
    Use get_cpu() instead of smp_processor_id() to avoid this BUG.
    
    Suggested-by: Chen Yu <yu.c.chen@intel.com>
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    [ rjw: Subject edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 42f79dbb9514f726ff21df25f09cb0693b0b2445
Author: Chao Qin <chao.qin@intel.com>
Date:   Tue Sep 20 14:08:26 2022 +0800

    powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue
    
    [ Upstream commit 2d93540014387d1c73b9ccc4d7895320df66d01b ]
    
    When value < time_unit, the parameter of ilog2() will be zero and
    the return value is -1. u64(-1) is too large for shift exponent
    and then will trigger shift-out-of-bounds:
    
    shift exponent 18446744073709551615 is too large for 32-bit type 'int'
    Call Trace:
     rapl_compute_time_window_core
     rapl_write_data_raw
     set_time_window
     store_constraint_time_window_us
    
    Signed-off-by: Chao Qin <chao.qin@intel.com>
    Acked-by: Zhang Rui <rui.zhang@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52e607efd87e015f1eb4b4476323734e501c70d1
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Sep 7 16:05:56 2022 -0700

    MIPS: BCM47XX: Cast memcmp() of function to (void *)
    
    [ Upstream commit 0dedcf6e3301836eb70cfa649052e7ce4fcd13ba ]
    
    Clang is especially sensitive about argument type matching when using
    __overloaded functions (like memcmp(), etc). Help it see that function
    pointers are just "void *". Avoids this error:
    
    arch/mips/bcm47xx/prom.c:89:8: error: no matching function for call to 'memcmp'
                       if (!memcmp(prom_init, prom_init + mem, 32))
                            ^~~~~~
    include/linux/string.h:156:12: note: candidate function not viable: no known conversion from 'void (void)' to 'const void *' for 1st argument extern int memcmp(const void *,const void *,__kernel_size_t);
    
    Cc: Hauke Mehrtens <hauke@hauke-m.de>
    Cc: "Rafał Miłecki" <zajec5@gmail.com>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: linux-mips@vger.kernel.org
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: llvm@lists.linux.dev
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/lkml/202209080652.sz2d68e5-lkp@intel.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f4e3ffff800397b57aae273f3006a3e4011c45b
Author: Arvid Norlander <lkml@vorpal.se>
Date:   Wed Aug 24 20:49:50 2022 +0200

    ACPI: video: Add Toshiba Satellite/Portege Z830 quirk
    
    [ Upstream commit 574160b8548deff8b80b174f03201e94ab8431e2 ]
    
    Toshiba Satellite Z830 needs the quirk video_disable_backlight_sysfs_if
    for proper backlight control after suspend/resume cycles.
    
    Toshiba Portege Z830 is simply the same laptop rebranded for certain
    markets (I looked through the manual to other language sections to confirm
    this) and thus also needs this quirk.
    
    Thanks to Hans de Goede for suggesting this fix.
    
    Link: https://www.spinics.net/lists/platform-driver-x86/msg34394.html
    Suggested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Arvid Norlander <lkml@vorpal.se>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Arvid Norlander <lkml@vorpal.se>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7534a90f679c68e9e229be109f13abece019e840
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Mon Sep 5 12:59:17 2022 +0800

    f2fs: fix race condition on setting FI_NO_EXTENT flag
    
    [ Upstream commit 07725adc55c0a414c10acb5c8c86cea34b95ddef ]
    
    The following scenarios exist.
    process A:               process B:
    ->f2fs_drop_extent_tree  ->f2fs_update_extent_cache_range
                              ->f2fs_update_extent_tree_range
                               ->write_lock
     ->set_inode_flag
                               ->is_inode_flag_set
                               ->__free_extent_tree // Shouldn't
                                                    // have been
                                                    // cleaned up
                                                    // here
      ->write_lock
    
    In this case, the "FI_NO_EXTENT" flag is set between
    f2fs_update_extent_tree_range and is_inode_flag_set
    by other process. it leads to clearing the whole exten
    tree which should not have happened. And we fix it by
    move the setting it to the range of write_lock.
    
    Fixes:5f281fab9b9a3 ("f2fs: disable extent_cache for fcollapse/finsert inodes")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 706e359cf046c142db290244c3f4938b20fbe805
Author: Dan Carpenter <error27@gmail.com>
Date:   Thu Aug 4 17:32:39 2022 +0300

    iommu/omap: Fix buffer overflow in debugfs
    
    [ Upstream commit 184233a5202786b20220acd2d04ddf909ef18f29 ]
    
    There are two issues here:
    
    1) The "len" variable needs to be checked before the very first write.
       Otherwise if omap2_iommu_dump_ctx() with "bytes" less than 32 it is a
       buffer overflow.
    2) The snprintf() function returns the number of bytes that *would* have
       been copied if there were enough space.  But we want to know the
       number of bytes which were *actually* copied so use scnprintf()
       instead.
    
    Fixes: bd4396f09a4a ("iommu/omap: Consolidate OMAP IOMMU modules")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Link: https://lore.kernel.org/r/YuvYh1JbE3v+abd5@kili
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6de5f0e3e85e66e33baeefac23e5d5907d0a942d
Author: Pali Rohár <pali@kernel.org>
Date:   Fri Sep 2 23:21:02 2022 +0200

    powerpc: Fix SPE Power ISA properties for e500v1 platforms
    
    [ Upstream commit 37b9345ce7f4ab17538ea62def6f6d430f091355 ]
    
    Commit 2eb28006431c ("powerpc/e500v2: Add Power ISA properties to comply
    with ePAPR 1.1") introduced new include file e500v2_power_isa.dtsi and
    should have used it for all e500v2 platforms. But apparently it was used
    also for e500v1 platforms mpc8540, mpc8541, mpc8555 and mpc8560.
    
    e500v1 cores compared to e500v2 do not support double precision floating
    point SPE instructions. Hence power-isa-sp.fd should not be set on e500v1
    platforms, which is in e500v2_power_isa.dtsi include file.
    
    Fix this issue by introducing a new e500v1_power_isa.dtsi include file and
    use it in all e500v1 device tree files.
    
    Fixes: 2eb28006431c ("powerpc/e500v2: Add Power ISA properties to comply with ePAPR 1.1")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220902212103.22534-1-pali@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75dc8e7a9edcfc175ab5fde97a7f6fa614a0749c
Author: Liang He <windhl@126.com>
Date:   Fri Jul 1 21:17:50 2022 +0800

    powerpc/pci_dn: Add missing of_node_put()
    
    [ Upstream commit 110a1fcb6c4d55144d8179983a475f17a1d6f832 ]
    
    In pci_add_device_node_info(), use of_node_put() to drop the reference
    to 'parent' returned by of_get_parent() to keep refcount balance.
    
    Fixes: cca87d303c85 ("powerpc/pci: Refactor pci_dn")
    Co-authored-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Link: https://lore.kernel.org/r/20220701131750.240170-1-windhl@126.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 57bbf634eb36be07dd612b2ca670ef3197e1a893
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Fri Sep 2 18:00:08 2022 +0200

    powerpc/math_emu/efp: Include module.h
    
    [ Upstream commit cfe0d370e0788625ce0df3239aad07a2506c1796 ]
    
    When building with a recent version of clang, there are a couple of
    errors around the call to module_init():
    
      arch/powerpc/math-emu/math_efp.c:927:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
      module_init(spe_mathemu_init);
      ^
      int
      arch/powerpc/math-emu/math_efp.c:927:13: error: a parameter list without types is only allowed in a function definition
      module_init(spe_mathemu_init);
                  ^
      2 errors generated.
    
    module_init() is a macro, which is not getting expanded because module.h
    is not included in this file. Add the include so that the macro can
    expand properly, clearing up the build failure.
    
    Fixes: ac6f120369ff ("powerpc/85xx: Workaroudn e500 CPU erratum A005")
    [chleroy: added fixes tag]
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Link: https://lore.kernel.org/r/8403854a4c187459b2f4da3537f51227b70b9223.1662134272.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27abe45df1dc394c184688d816cbbf2f194d4c6a
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu Jun 2 07:08:36 2022 +0400

    clk: ti: dra7-atl: Fix reference leak in of_dra7_atl_clk_probe
    
    [ Upstream commit 9c59a01caba26ec06fefd6ca1f22d5fd1de57d63 ]
    
    pm_runtime_get_sync() will increment pm usage counter.
    Forgetting to putting operation will result in reference leak.
    Add missing pm_runtime_put_sync in some error paths.
    
    Fixes: 9ac33b0ce81f ("CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220602030838.52057-1-linmq006@gmail.com
    Reviewed-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f33a415a57ccd1b385d09bdb7f09e85e6030cb47
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date:   Sun Sep 4 16:10:37 2022 +0200

    clk: bcm2835: fix bcm2835_clock_rate_from_divisor declaration
    
    [ Upstream commit 0b919a3728691c172312dee99ba654055ccd8c84 ]
    
    The return value of bcm2835_clock_rate_from_divisor is always unsigned
    and also all caller expect this. So fix the declaration accordingly.
    
    Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
    Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
    Link: https://lore.kernel.org/r/20220904141037.38816-1-stefan.wahren@i2se.com
    Reviewed-by: Ivan T. Ivanov <iivanov@suse.de>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d967328312111870abe00283faa8c7cca11e8db1
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Mon Sep 19 09:58:42 2022 -0700

    dmaengine: ioat: stop mod_timer from resurrecting deleted timer in __cleanup()
    
    [ Upstream commit 898ec89dbb55b8294695ad71694a0684e62b2a73 ]
    
    User reports observing timer event report channel halted but no error
    observed in CHANERR register. The driver finished self-test and released
    channel resources. Debug shows that __cleanup() can call
    mod_timer() after the timer has been deleted and thus resurrect the
    timer. While harmless, it causes suprious error message to be emitted.
    Use mod_timer_pending() call to prevent deleted timer from being
    resurrected.
    
    Fixes: 3372de5813e4 ("dmaengine: ioatdma: removal of dma_v3.c and relevant ioat3 references")
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/166360672197.3851724.17040290563764838369.stgit@djiang5-desk3.ch.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88f497bb85ed856037f5ddb4ba0f4a9a3b1939d3
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Sep 13 17:11:12 2022 +0800

    mfd: sm501: Add check for platform_driver_register()
    
    [ Upstream commit 8325a6c24ad78b8c1acc3c42b098ee24105d68e5 ]
    
    As platform_driver_register() can return error numbers,
    it should be better to check platform_driver_register()
    and deal with the exception.
    
    Fixes: b6d6454fdb66 ("[PATCH] mfd: SM501 core driver")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: Lee Jones <lee@kernel.org>
    Link: https://lore.kernel.org/r/20220913091112.1739138-1-jiasheng@iscas.ac.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2c2ee4de66f84841a0ac1a44f8553351a043c8d
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jul 31 11:55:38 2022 +0200

    mfd: lp8788: Fix an error handling path in lp8788_irq_init() and lp8788_irq_init()
    
    [ Upstream commit 557244f6284f30613f2d61f14b579303165876c3 ]
    
    In lp8788_irq_init(), if an error occurs after a successful
    irq_domain_add_linear() call, it must be undone by a corresponding
    irq_domain_remove() call.
    
    irq_domain_remove() should also be called in lp8788_irq_exit() for the same
    reason.
    
    Fixes: eea6b7cc53aa ("mfd: Add lp8788 mfd driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Lee Jones <lee@kernel.org>
    Link: https://lore.kernel.org/r/bcd5a72c9c1c383dd6324680116426e32737655a.1659261275.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b38cf89456bbdeb30aeac240a96311c0763cde8d
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jul 31 11:55:27 2022 +0200

    mfd: lp8788: Fix an error handling path in lp8788_probe()
    
    [ Upstream commit becfdcd75126b20b8ec10066c5e85b34f8994ad5 ]
    
    Should an error occurs in mfd_add_devices(), some resources need to be
    released, as already done in the .remove() function.
    
    Add an error handling path and a lp8788_irq_exit() call to undo a previous
    lp8788_irq_init().
    
    Fixes: eea6b7cc53aa ("mfd: Add lp8788 mfd driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Lee Jones <lee@kernel.org>
    Link: https://lore.kernel.org/r/18398722da9df9490722d853e4797350189ae79b.1659261275.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 557f04c3fb032e56e7d262780478ec72d164bfde
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Aug 1 14:42:02 2022 +0300

    mfd: intel_soc_pmic: Fix an error handling path in intel_soc_pmic_i2c_probe()
    
    [ Upstream commit 48749cabba109397b4e7dd556e85718ec0ec114d ]
    
    The commit in Fixes: has added a pwm_add_table() call in the probe() and
    a pwm_remove_table() call in the remove(), but forget to update the error
    handling path of the probe.
    
    Add the missing pwm_remove_table() call.
    
    Fixes: a3aa9a93df9f ("mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Lee Jones <lee@kernel.org>
    Link: https://lore.kernel.org/r/20220801114211.36267-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f6d611a213e3a2fc17adad223317dd31370b5eee
Author: Pali Rohár <pali@kernel.org>
Date:   Sat Sep 24 12:43:24 2022 +0200

    serial: 8250: Fix restoring termios speed after suspend
    
    [ Upstream commit 379a33786d489ab81885ff0b3935cfeb36137fea ]
    
    Since commit edc6afc54968 ("tty: switch to ktermios and new framework")
    termios speed is no longer stored only in c_cflag member but also in new
    additional c_ispeed and c_ospeed members. If BOTHER flag is set in c_cflag
    then termios speed is stored only in these new members.
    
    Since commit 027b57170bf8 ("serial: core: Fix initializing and restoring
    termios speed") termios speed is available also in struct console.
    
    So properly restore also c_ispeed and c_ospeed members after suspend to fix
    restoring termios speed which is not represented by Bnnn constant.
    
    Fixes: 4516d50aabed ("serial: 8250: Use canary to restart console after suspend")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Link: https://lore.kernel.org/r/20220924104324.4035-1-pali@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 55ced28cac85e2fda63f25d45641c95acbbd07b0
Author: Guilherme G. Piccoli <gpiccoli@igalia.com>
Date:   Fri Sep 9 17:07:55 2022 -0300

    firmware: google: Test spinlock on panic path to avoid lockups
    
    [ Upstream commit 3e081438b8e639cc76ef1a5ce0c1bd8a154082c7 ]
    
    Currently the gsmi driver registers a panic notifier as well as
    reboot and die notifiers. The callbacks registered are called in
    atomic and very limited context - for instance, panic disables
    preemption and local IRQs, also all secondary CPUs (not executing
    the panic path) are shutdown.
    
    With that said, taking a spinlock in this scenario is a dangerous
    invitation for lockup scenarios. So, fix that by checking if the
    spinlock is free to acquire in the panic notifier callback - if not,
    bail-out and avoid a potential hang.
    
    Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: David Gow <davidgow@google.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Julius Werner <jwerner@chromium.org>
    Cc: Petr Mladek <pmladek@suse.com>
    Reviewed-by: Evan Green <evgreen@chromium.org>
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Link: https://lore.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff9a5e50fb1910be33e62925bc7ee3bef474879e
Author: Dan Carpenter <error27@gmail.com>
Date:   Thu Sep 22 14:22:47 2022 +0300

    drivers: serial: jsm: fix some leaks in probe
    
    [ Upstream commit 1d5859ef229e381f4db38dce8ed58e4bf862006b ]
    
    This error path needs to unwind instead of just returning directly.
    
    Fixes: 03a8482c17dd ("drivers: serial: jsm: Enable support for Digi Classic adapters")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YyxFh1+lOeZ9WfKO@kili
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e01f64a346a6d3aaf595c48e6f4987da84915e04
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date:   Fri Sep 16 14:28:35 2022 +0200

    ata: fix ata_id_has_dipm()
    
    [ Upstream commit 630624cb1b5826d753ac8e01a0e42de43d66dedf ]
    
    ACS-5 section
    7.13.6.36 Word 78: Serial ATA features supported
    states that:
    
    If word 76 is not 0000h or FFFFh, word 78 reports the features supported
    by the device. If this word is not supported, the word shall be cleared
    to zero.
    
    (This text also exists in really old ACS standards, e.g. ACS-3.)
    
    The problem with ata_id_has_dipm() is that the while it performs a
    check against 0 and 0xffff, it performs the check against
    ATA_ID_FEATURE_SUPP (word 78), the same word where the feature bit
    is stored.
    
    Fix this by performing the check against ATA_ID_SATA_CAPABILITY
    (word 76), like required by the spec. The feature bit check itself
    is of course still performed against ATA_ID_FEATURE_SUPP (word 78).
    
    Additionally, move the macro to the other ATA_ID_FEATURE_SUPP macros
    (which already have this check), thus making it more likely that the
    next ATA_ID_FEATURE_SUPP macro that is added will include this check.
    
    Fixes: ca77329fb713 ("[libata] Link power management infrastructure")
    Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e7d970ebf08fb1270436f47fbb90098b9a9dfcd
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date:   Fri Sep 16 14:28:34 2022 +0200

    ata: fix ata_id_has_ncq_autosense()
    
    [ Upstream commit a5fb6bf853148974dbde092ec1bde553bea5e49f ]
    
    ACS-5 section
    7.13.6.36 Word 78: Serial ATA features supported
    states that:
    
    If word 76 is not 0000h or FFFFh, word 78 reports the features supported
    by the device. If this word is not supported, the word shall be cleared
    to zero.
    
    (This text also exists in really old ACS standards, e.g. ACS-3.)
    
    Additionally, move the macro to the other ATA_ID_FEATURE_SUPP macros
    (which already have this check), thus making it more likely that the
    next ATA_ID_FEATURE_SUPP macro that is added will include this check.
    
    Fixes: 5b01e4b9efa0 ("libata: Implement NCQ autosense")
    Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2319e8f80b1e072a80081fcb3b7a8749403704c3
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date:   Fri Sep 16 14:28:33 2022 +0200

    ata: fix ata_id_has_devslp()
    
    [ Upstream commit 9c6e09a434e1317e09b78b3b69cd384022ec9a03 ]
    
    ACS-5 section
    7.13.6.36 Word 78: Serial ATA features supported
    states that:
    
    If word 76 is not 0000h or FFFFh, word 78 reports the features supported
    by the device. If this word is not supported, the word shall be cleared
    to zero.
    
    (This text also exists in really old ACS standards, e.g. ACS-3.)
    
    Additionally, move the macro to the other ATA_ID_FEATURE_SUPP macros
    (which already have this check), thus making it more likely that the
    next ATA_ID_FEATURE_SUPP macro that is added will include this check.
    
    Fixes: 65fe1f0f66a5 ("ahci: implement aggressive SATA device sleep support")
    Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8477ebe4bf48e1db5a2d8f2308489f85c021b667
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date:   Fri Sep 16 14:28:32 2022 +0200

    ata: fix ata_id_sense_reporting_enabled() and ata_id_has_sense_reporting()
    
    [ Upstream commit 690aa8c3ae308bc696ec8b1b357b995193927083 ]
    
    ACS-5 section
    7.13.6.41 Words 85..87, 120: Commands and feature sets supported or enabled
    states that:
    
    If bit 15 of word 86 is set to one, bit 14 of word 119 is set to one,
    and bit 15 of word 119 is cleared to zero, then word 119 is valid.
    
    If bit 15 of word 86 is set to one, bit 14 of word 120 is set to one,
    and bit 15 of word 120 is cleared to zero, then word 120 is valid.
    
    (This text also exists in really old ACS standards, e.g. ACS-3.)
    
    Currently, ata_id_sense_reporting_enabled() and
    ata_id_has_sense_reporting() both check bit 15 of word 86,
    but neither of them check that bit 14 of word 119 is set to one,
    or that bit 15 of word 119 is cleared to zero.
    
    Additionally, make ata_id_sense_reporting_enabled() return false
    if !ata_id_has_sense_reporting(), similar to how e.g.
    ata_id_flush_ext_enabled() returns false if !ata_id_has_flush_ext().
    
    Fixes: e87fd28cf9a2 ("libata: Implement support for sense data reporting")
    Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a1bea404ee3c82b49507d63178a5cf2b73d34b9e
Author: Jim Cromie <jim.cromie@gmail.com>
Date:   Sun Sep 4 15:40:44 2022 -0600

    dyndbg: let query-modname override actual module name
    
    [ Upstream commit e75ef56f74965f426dd819a41336b640ffdd8fbc ]
    
    dyndbg's control-parser: ddebug_parse_query(), requires that search
    terms: module, func, file, lineno, are used only once in a query; a
    thing cannot be named both foo and bar.
    
    The cited commit added an overriding module modname, taken from the
    module loader, which is authoritative.  So it set query.module 1st,
    which disallowed its use in the query-string.
    
    But now, its useful to allow a module-load to enable classes across a
    whole (or part of) a subsystem at once.
    
      # enable (dynamic-debug in) drm only
      modprobe drm dyndbg="class DRM_UT_CORE +p"
    
      # get drm_helper too
      modprobe drm dyndbg="class DRM_UT_CORE module drm* +p"
    
      # get everything that knows DRM_UT_CORE
      modprobe drm dyndbg="class DRM_UT_CORE module * +p"
    
      # also for boot-args:
      drm.dyndbg="class DRM_UT_CORE module * +p"
    
    So convert the override into a default, by filling it only when/after
    the query-string omitted the module.
    
    NB: the query class FOO handling is forthcoming.
    
    Fixes: 8e59b5cfb9a6 dynamic_debug: add modname arg to exec_query callchain
    Acked-by: Jason Baron <jbaron@akamai.com>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
    Link: https://lore.kernel.org/r/20220904214134.408619-8-jim.cromie@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d149377485e6e5548ab2e1d3d1fa6403d4ee7e9
Author: Jim Cromie <jim.cromie@gmail.com>
Date:   Sun Sep 4 15:40:39 2022 -0600

    dyndbg: fix module.dyndbg handling
    
    [ Upstream commit 85d6b66d31c35158364058ee98fb69ab5bb6a6b1 ]
    
    For CONFIG_DYNAMIC_DEBUG=N, the ddebug_dyndbg_module_param_cb()
    stub-fn is too permissive:
    
    bash-5.1# modprobe drm JUNKdyndbg
    bash-5.1# modprobe drm dyndbgJUNK
    [   42.933220] dyndbg param is supported only in CONFIG_DYNAMIC_DEBUG builds
    [   42.937484] ACPI: bus type drm_connector registered
    
    This caused no ill effects, because unknown parameters are either
    ignored by default with an "unknown parameter" warning, or ignored
    because dyndbg allows its no-effect use on non-dyndbg builds.
    
    But since the code has an explicit feedback message, it should be
    issued accurately.  Fix with strcmp for exact param-name match.
    
    Fixes: b48420c1d301 dynamic_debug: make dynamic-debug work for module initialization
    Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Acked-by: Jason Baron <jbaron@akamai.com>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
    Link: https://lore.kernel.org/r/20220904214134.408619-3-jim.cromie@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7cd46f98cece72a10b39b1aa0f276f359df48e91
Author: Zhu Yanjun <yanjun.zhu@linux.dev>
Date:   Sun Aug 21 21:16:14 2022 -0400

    RDMA/rxe: Fix the error caused by qp->sk
    
    [ Upstream commit 548ce2e66725dcba4e27d1e8ac468d5dd17fd509 ]
    
    When sock_create_kern in the function rxe_qp_init_req fails,
    qp->sk is set to NULL.
    
    Then the function rxe_create_qp will call rxe_qp_do_cleanup
    to handle allocated resource.
    
    Before handling qp->sk, this variable should be checked.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Link: https://lore.kernel.org/r/20220822011615.805603-3-yanjun.zhu@linux.dev
    Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
    Reviewed-by: Li Zhijian <lizhijian@fujitsu.com>
    Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48cd7098e71735ccafa0b3cf27c53924f9cb5b2f
Author: Zhu Yanjun <yanjun.zhu@linux.dev>
Date:   Sun Aug 21 21:16:13 2022 -0400

    RDMA/rxe: Fix "kernel NULL pointer dereference" error
    
    [ Upstream commit a625ca30eff806395175ebad3ac1399014bdb280 ]
    
    When rxe_queue_init in the function rxe_qp_init_req fails,
    both qp->req.task.func and qp->req.task.arg are not initialized.
    
    Because of creation of qp fails, the function rxe_create_qp will
    call rxe_qp_do_cleanup to handle allocated resource.
    
    Before calling __rxe_do_task, both qp->req.task.func and
    qp->req.task.arg should be checked.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Link: https://lore.kernel.org/r/20220822011615.805603-2-yanjun.zhu@linux.dev
    Reported-by: syzbot+ab99dc4c6e961eed8b8e@syzkaller.appspotmail.com
    Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
    Reviewed-by: Li Zhijian <lizhijian@fujitsu.com>
    Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b0efe7534071e0153708886355d80db69525d50
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Wed Jun 1 06:25:14 2022 +0200

    media: xilinx: vipp: Fix refcount leak in xvip_graph_dma_init
    
    [ Upstream commit 1c78f19c3a0ea312a8178a6bfd8934eb93e9b10a ]
    
    of_get_child_by_name() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: df3305156f98 ("[media] v4l: xilinx: Add Xilinx Video IP core")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93733128f64abd7ee18098f78dc7ea38cfc888be
Author: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Date:   Fri Jul 29 17:17:45 2022 +0530

    tty: xilinx_uartps: Fix the ignore_status
    
    [ Upstream commit b8a6c3b3d4654fba19881cc77da61eac29f57cae ]
    
    Currently the ignore_status is not considered in the isr.
    Add a check to add the ignore_status.
    
    Fixes: 61ec9016988f ("tty/serial: add support for Xilinx PS UART")
    Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
    Link: https://lore.kernel.org/r/20220729114748.18332-5-shubhrajyoti.datta@xilinx.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 319b8d737333f54605baf9d7c68962acb5327dd9
Author: Liang He <windhl@126.com>
Date:   Wed Jul 20 16:30:03 2022 +0200

    media: exynos4-is: fimc-is: Add of_node_put() when breaking out of loop
    
    [ Upstream commit 211f8304fa21aaedc2c247f0c9d6c7f1aaa61ad7 ]
    
    In fimc_is_register_subdevs(), we need to call of_node_put() for
    the reference 'i2c_bus' when breaking out of the
    for_each_compatible_node() which has increased the refcount.
    
    Fixes: 9a761e436843 ("[media] exynos4-is: Add Exynos4x12 FIMC-IS driver")
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9183a37d3e6190cc34291ababb789c2cdec995d3
Author: Jack Wang <jinpu.wang@ionos.com>
Date:   Fri Aug 26 12:12:27 2022 +0200

    HSI: omap_ssi_port: Fix dma_map_sg error check
    
    [ Upstream commit 551e325bbd3fb8b5a686ac1e6cf76e5641461cf2 ]
    
    dma_map_sg return 0 on error, in case of error return -EIO
    to caller.
    
    Cc: Sebastian Reichel <sre@kernel.org>
    Cc: linux-kernel@vger.kernel.org (open list)
    Fixes: b209e047bc74 ("HSI: Introduce OMAP SSI driver")
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20fbaff6699ea5553c67550e867d6f90b7085447
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Apr 4 08:52:32 2022 +0000

    HSI: omap_ssi: Fix refcount leak in ssi_probe
    
    [ Upstream commit 9a2ea132df860177b33c9fd421b26c4e9a0a9396 ]
    
    When returning or breaking early from a
    for_each_available_child_of_node() loop, we need to explicitly call
    of_node_put() on the child node to possibly release the node.
    
    Fixes: b209e047bc74 ("HSI: Introduce OMAP SSI driver")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f9bdef9bb60814514a787b84184ecaa269a7c951
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon May 23 19:28:11 2022 +0400

    clk: tegra20: Fix refcount leak in tegra20_clock_init
    
    [ Upstream commit 4e343bafe03ff68a62f48f8235cf98f2c685468b ]
    
    of_find_matching_node() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 37c26a906527 ("clk: tegra: add clock support for Tegra20")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220523152811.19692-1-linmq006@gmail.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f0e1cbbaffd729560716e9592aa5e609ea93bb6
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon May 23 18:38:34 2022 +0400

    clk: tegra: Fix refcount leak in tegra114_clock_init
    
    [ Upstream commit db16a80c76ea395766913082b1e3f939dde29b2c ]
    
    of_find_matching_node() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 2cb5efefd6f7 ("clk: tegra: Implement clocks for Tegra114")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220523143834.7587-1-linmq006@gmail.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a19360db83d29bd6b0de4ffad2c815d79246ba99
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon May 23 18:26:08 2022 +0400

    clk: tegra: Fix refcount leak in tegra210_clock_init
    
    [ Upstream commit 56c78cb1f00a9dde8cd762131ce8f4c5eb046fbb ]
    
    of_find_matching_node() returns a node pointer with refcount
    incremented, we should use of_node_put() on it when not need anymore.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: 6b301a059eb2 ("clk: tegra: Add support for Tegra210 clocks")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Link: https://lore.kernel.org/r/20220523142608.65074-1-linmq006@gmail.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c969ada8a2fa5fdd98775a23ad8db8d674246734
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Jun 26 13:29:23 2022 +0100

    iio: ABI: Fix wrong format of differential capacitance channel ABI.
    
    [ Upstream commit 1efc41035f1841acf0af2bab153158e27ce94f10 ]
    
    in_ only occurs once in these attributes.
    
    Fixes: 0baf29d658c7 ("staging:iio:documentation Add abi docs for capacitance adcs.")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20220626122938.582107-3-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64ead55b5d167128b0b314dc0dfb98123eb2d897
Author: Nuno Sá <nuno.sa@analog.com>
Date:   Fri Jul 15 14:28:49 2022 +0200

    iio: inkern: only release the device node when done with it
    
    [ Upstream commit 79c3e84874c7d14f04ad58313b64955a0d2e9437 ]
    
    'of_node_put()' can potentially release the memory pointed to by
    'iiospec.np' which would leave us with an invalid pointer (and we would
    still pass it in 'of_xlate()'). Note that it is not guaranteed for the
    of_node lifespan to be attached to the device (to which is attached)
    lifespan so that there is (even though very unlikely) the possibility
    for the node to be freed while the device is still around. Thus, as there
    are indeed some of_xlate users which do access the node, a race is indeed
    possible.
    
    As such, we can only release the node after we are done with it.
    
    Fixes: 17d82b47a215d ("iio: Add OF support")
    Signed-off-by: Nuno Sá <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20220715122903.332535-2-nuno.sa@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 27400d7219eb0dbf4c7c95cbb74cf0ca2dba6da7
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Wed Aug 3 13:28:37 2022 +0300

    iio: adc: at91-sama5d2_adc: fix AT91_SAMA5D2_MR_TRACKTIM_MAX
    
    [ Upstream commit bb73d5d9164c57c4bb916739a98e5cd8e0a5ed8c ]
    
    All ADC HW versions handled by this driver (SAMA5D2, SAM9X60, SAMA7G5)
    have MR.TRACKTIM on 4 bits. Fix AT91_SAMA5D2_MR_TRACKTIM_MAX to reflect
    this.
    
    Fixes: 27e177190891 ("iio:adc:at91_adc8xx: introduce new atmel adc driver")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Link: https://lore.kernel.org/r/20220803102855.2191070-2-claudiu.beznea@microchip.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 455c3226aef722e4f74af5406d8d305ebfd73851
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Tue Sep 27 15:05:03 2022 -0700

    ARM: dts: exynos: fix polarity of VBUS GPIO of Origen
    
    [ Upstream commit a08137bd1e0a7ce951dce9ce4a83e39d379b6e1b ]
    
    EHCI Oxynos (drivers/usb/host/ehci-exynos.c) drives VBUS GPIO high when
    trying to power up the bus, therefore the GPIO in DTS must be marked as
    "active high". This will be important when EHCI driver is converted to
    gpiod API that respects declared polarities.
    
    Fixes: 4e8991def565 ("ARM: dts: exynos: Enable AX88760 USB hub on Origen board")
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Link: https://lore.kernel.org/r/20220927220504.3744878-1-dmitry.torokhov@gmail.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 281934bdc5bfb0940f9d5e1b50f42ee99f917169
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Tue Sep 27 15:28:26 2022 +0200

    ARM: Drop CMDLINE_* dependency on ATAGS
    
    [ Upstream commit 136f4b1ec7c962ee37a787e095fd37b058d72bd3 ]
    
    On arm32, the configuration options to specify the kernel command line
    type depend on ATAGS.  However, the actual CMDLINE cofiguration option
    does not depend on ATAGS, and the code that handles this is not specific
    to ATAGS (see drivers/of/fdt.c:early_init_dt_scan_chosen()).
    
    Hence users who desire to override the kernel command line on arm32 must
    enable support for ATAGS, even on a pure-DT system.  Other architectures
    (arm64, loongarch, microblaze, nios2, powerpc, and riscv) do not impose
    such a restriction.
    
    Hence drop the dependency on ATAGS.
    
    Fixes: bd51e2f595580fb6 ("ARM: 7506/1: allow for ATAGS to be configured out when DT support is selected")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a3fbc5d360f578ea3ce7f3c1272d2787d35fe29
Author: Michael Walle <michael@walle.cc>
Date:   Tue Aug 16 02:10:25 2022 +0200

    ARM: dts: kirkwood: lsxl: remove first ethernet port
    
    [ Upstream commit 2d528eda7c96ce5c70f895854ecd5684bd5d80b9 ]
    
    Both the Linkstation LS-CHLv2 and the LS-XHL have only one ethernet
    port. This has always been wrong, i.e. the board code used to set up
    both ports, but the driver will play nice and return -ENODEV if the
    assiciated PHY is not found. Nevertheless, it is wrong. Remove it.
    
    Fixes: 876e23333511 ("ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 405130e06c5fce346d817b963eb5afaef69279d0
Author: Michael Walle <michael@walle.cc>
Date:   Tue Aug 16 02:10:24 2022 +0200

    ARM: dts: kirkwood: lsxl: fix serial line
    
    [ Upstream commit 04eabc6ac10fda9424606d9a7ab6ab9a5d95350a ]
    
    Commit 327e15428977 ("ARM: dts: kirkwood: consolidate common pinctrl
    settings") unknowingly broke the serial output on this board. Before
    this commit, the pinmux was still configured by the bootloader and the
    kernel didn't reconfigured it again. This was an oversight by the
    initial board support where the pinmux for the serial line was never
    configured by the kernel. But with this commit, the serial line will be
    reconfigured to the wrong pins. This is especially confusing, because
    the output still works, but the input doesn't. Presumingly, the input is
    reconfigured to MPP10, but the output is connected to both MPP11 and
    MPP5.
    
    Override the pinmux in the board device tree.
    
    Fixes: 327e15428977 ("ARM: dts: kirkwood: consolidate common pinctrl settings")
    Signed-off-by: Michael Walle <michael@walle.cc>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be76b8c1a812cd0ef78be491bf64619725254830
Author: Liang He <windhl@126.com>
Date:   Thu Jul 21 21:52:17 2022 +0800

    soc: qcom: smem_state: Add refcounting for the 'state->of_node'
    
    [ Upstream commit 90681f53b9381c23ff7762a3b13826d620c272de ]
    
    In qcom_smem_state_register() and qcom_smem_state_release(), we
    should better use of_node_get() and of_node_put() for the reference
    creation and destruction of 'device_node'.
    
    Fixes: 9460ae2ff308 ("soc: qcom: Introduce common SMEM state machine code")
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220721135217.1301039-2-windhl@126.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1bbe75d466e5118b7d49ef4a346c3ce5742da4e8
Author: Liang He <windhl@126.com>
Date:   Thu Jul 21 21:52:16 2022 +0800

    soc: qcom: smsm: Fix refcount leak bugs in qcom_smsm_probe()
    
    [ Upstream commit af8f6f39b8afd772fda4f8e61823ef8c021bf382 ]
    
    There are two refcount leak bugs in qcom_smsm_probe():
    
    (1) The 'local_node' is escaped out from for_each_child_of_node() as
    the break of iteration, we should call of_node_put() for it in error
    path or when it is not used anymore.
    (2) The 'node' is escaped out from for_each_available_child_of_node()
    as the 'goto', we should call of_node_put() for it in goto target.
    
    Fixes: c97c4090ff72 ("soc: qcom: smsm: Add driver for Qualcomm SMSM")
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Link: https://lore.kernel.org/r/20220721135217.1301039-1-windhl@126.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a4d0bd4388e1a39df47e8aaa044ef6a7ee626e48
Author: Liang He <windhl@126.com>
Date:   Tue Jul 19 16:56:39 2022 +0800

    memory: of: Fix refcount leak bug in of_get_ddr_timings()
    
    [ Upstream commit 05215fb32010d4afb68fbdbb4d237df6e2d4567b ]
    
    We should add the of_node_put() when breaking out of
    for_each_child_of_node() as it will automatically increase
    and decrease the refcount.
    
    Fixes: e6b42eb6a66c ("memory: emif: add device tree support to emif driver")
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20220719085640.1210583-1-windhl@126.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 026c35821584eaa615c06a4f551e8e3648873fb0
Author: Andreas Pape <apape@de.adit-jv.com>
Date:   Mon Sep 26 18:58:13 2022 +0200

    ALSA: dmaengine: increment buffer pointer atomically
    
    [ Upstream commit d1c442019594692c64a70a86ad88eb5b6db92216 ]
    
    Setting pointer and afterwards checking for wraparound leads
    to the possibility of returning the inconsistent pointer position.
    
    This patch increments buffer pointer atomically to avoid this issue.
    
    Fixes: e7f73a1613567a ("ASoC: Add dmaengine PCM helper functions")
    Signed-off-by: Andreas Pape <apape@de.adit-jv.com>
    Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
    Link: https://lore.kernel.org/r/1664211493-11789-1-git-send-email-erosca@de.adit-jv.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d76be949581b2a68ce8c38727153f3c50fd294a
Author: Liang He <windhl@126.com>
Date:   Wed Sep 14 21:43:54 2022 +0800

    ASoC: eureka-tlv320: Hold reference returned from of_find_xxx API
    
    [ Upstream commit bfb735a3ceff0bab6473bac275da96f9b2a06dec ]
    
    In eukrea_tlv320_probe(), we need to hold the reference returned
    from of_find_compatible_node() which has increased the refcount
    and then call of_node_put() with it when done.
    
    Fixes: 66f232908de2 ("ASoC: eukrea-tlv320: Add DT support.")
    Co-authored-by: Kelin Wang <wangkelin2023@163.com>
    Signed-off-by: Liang He <windhl@126.com>
    Link: https://lore.kernel.org/r/20220914134354.3995587-1-windhl@126.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6820a5a90c5e77a08a0ac2d258080449d950b780
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu Aug 25 09:33:57 2022 +0200

    mmc: au1xmmc: Fix an error handling path in au1xmmc_probe()
    
    [ Upstream commit 5cbedf52608cc3cbc1c2a9a861fb671620427a20 ]
    
    If clk_prepare_enable() fails, there is no point in calling
    clk_disable_unprepare() in the error handling path.
    
    Move the out_clk label at the right place.
    
    Fixes: b6507596dfd6 ("MIPS: Alchemy: au1xmmc: use clk framework")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/21d99886d07fa7fcbec74992657dabad98c935c4.1661412818.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2fa562af779e7113f77242b6118d30067b0ff09
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Aug 25 16:13:34 2022 +0200

    platform/x86: msi-laptop: Fix old-ec check for backlight registering
    
    [ Upstream commit 83ac7a1c2ed5f17caa07cbbc84bad3c05dc3bf22 ]
    
    Commit 2cc6c717799f ("msi-laptop: Port to new backlight interface
    selection API") replaced this check:
    
            if (!quirks->old_ec_model || acpi_video_backlight_support())
                    pr_info("Brightness ignored, ...");
            else
                    do_register();
    
    With:
    
            if (quirks->old_ec_model ||
                acpi_video_get_backlight_type() == acpi_backlight_vendor)
                    do_register();
    
    But since the do_register() part was part of the else branch, the entire
    condition should be inverted.  So not only the 2 statements on either
    side of the || should be inverted, but the || itself should be replaced
    with a &&.
    
    In practice this has likely not been an issue because the new-ec models
    (old_ec_model==false) likely all support ACPI video backlight control,
    making acpi_video_get_backlight_type() return acpi_backlight_video
    turning the second part of the || also false when old_ec_model == false.
    
    Fixes: 2cc6c717799f ("msi-laptop: Port to new backlight interface selection API")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20220825141336.208597-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c202cda08cd5693645d4990ad1eb2e8068a884ec
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Mon Jul 11 19:38:31 2022 +0200

    drm/mipi-dsi: Detach devices when removing the host
    
    [ Upstream commit 668a8f17b5290d04ef7343636a5588a0692731a1 ]
    
    Whenever the MIPI-DSI host is unregistered, the code of
    mipi_dsi_host_unregister() loops over every device currently found on that
    bus and will unregister it.
    
    However, it doesn't detach it from the bus first, which leads to all kind
    of resource leaks if the host wants to perform some clean up whenever a
    device is detached.
    
    Fixes: 068a00233969 ("drm: Add MIPI DSI bus support")
    Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20220711173939.1132294-2-maxime@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ec3f783f08b57a861700fdf4d3d8f3cfb68f471
Author: Jianglei Nie <niejianglei2021@163.com>
Date:   Fri Sep 30 14:28:43 2022 +0800

    bnx2x: fix potential memory leak in bnx2x_tpa_stop()
    
    [ Upstream commit b43f9acbb8942b05252be83ac25a81cec70cc192 ]
    
    bnx2x_tpa_stop() allocates a memory chunk from new_data with
    bnx2x_frag_alloc(). The new_data should be freed when gets some error.
    But when "pad + len > fp->rx_buf_size" is true, bnx2x_tpa_stop() returns
    without releasing the new_data, which will lead to a memory leak.
    
    We should free the new_data with bnx2x_frag_free() when "pad + len >
    fp->rx_buf_size" is true.
    
    Fixes: 07b0f00964def8af9321cfd6c4a7e84f6362f728 ("bnx2x: fix possible panic under memory stress")
    Signed-off-by: Jianglei Nie <niejianglei2021@163.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d2ba255e93211e541373469dffbda7c99dfa0e5
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Thu Sep 29 00:25:37 2022 +0900

    net: rds: don't hold sock lock when cancelling work from rds_tcp_reset_callbacks()
    
    [ Upstream commit a91b750fd6629354460282bbf5146c01b05c4859 ]
    
    syzbot is reporting lockdep warning at rds_tcp_reset_callbacks() [1], for
    commit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication in
    rds_tcp_reset_callbacks()") added cancel_delayed_work_sync() into a section
    protected by lock_sock() without realizing that rds_send_xmit() might call
    lock_sock().
    
    We don't need to protect cancel_delayed_work_sync() using lock_sock(), for
    even if rds_{send,recv}_worker() re-queued this work while __flush_work()
     from cancel_delayed_work_sync() was waiting for this work to complete,
    retried rds_{send,recv}_worker() is no-op due to the absence of RDS_CONN_UP
    bit.
    
    Link: https://syzkaller.appspot.com/bug?extid=78c55c7bc6f66e53dce2 [1]
    Reported-by: syzbot <syzbot+78c55c7bc6f66e53dce2@syzkaller.appspotmail.com>
    Co-developed-by: Hillf Danton <hdanton@sina.com>
    Signed-off-by: Hillf Danton <hdanton@sina.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Tested-by: syzbot <syzbot+78c55c7bc6f66e53dce2@syzkaller.appspotmail.com>
    Fixes: ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication in rds_tcp_reset_callbacks()")
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f6e420d0c7cf964b01b52d2d249fce45bcc3d41
Author: Neal Cardwell <ncardwell@google.com>
Date:   Wed Sep 28 16:03:31 2022 -0400

    tcp: fix tcp_cwnd_validate() to not forget is_cwnd_limited
    
    [ Upstream commit f4ce91ce12a7c6ead19b128ffa8cff6e3ded2a14 ]
    
    This commit fixes a bug in the tracking of max_packets_out and
    is_cwnd_limited. This bug can cause the connection to fail to remember
    that is_cwnd_limited is true, causing the connection to fail to grow
    cwnd when it should, causing throughput to be lower than it should be.
    
    The following event sequence is an example that triggers the bug:
    
     (a) The connection is cwnd_limited, but packets_out is not at its
         peak due to TSO deferral deciding not to send another skb yet.
         In such cases the connection can advance max_packets_seq and set
         tp->is_cwnd_limited to true and max_packets_out to a small
         number.
    
    (b) Then later in the round trip the connection is pacing-limited (not
         cwnd-limited), and packets_out is larger. In such cases the
         connection would raise max_packets_out to a bigger number but
         (unexpectedly) flip tp->is_cwnd_limited from true to false.
    
    This commit fixes that bug.
    
    One straightforward fix would be to separately track (a) the next
    window after max_packets_out reaches a maximum, and (b) the next
    window after tp->is_cwnd_limited is set to true. But this would
    require consuming an extra u32 sequence number.
    
    Instead, to save space we track only the most important
    information. Specifically, we track the strongest available signal of
    the degree to which the cwnd is fully utilized:
    
    (1) If the connection is cwnd-limited then we remember that fact for
    the current window.
    
    (2) If the connection not cwnd-limited then we track the maximum
    number of outstanding packets in the current window.
    
    In particular, note that the new logic cannot trigger the buggy
    (a)/(b) sequence above because with the new logic a condition where
    tp->packets_out > tp->max_packets_out can only trigger an update of
    tp->is_cwnd_limited if tp->is_cwnd_limited is false.
    
    This first showed up in a testing of a BBRv2 dev branch, but this
    buggy behavior highlighted a general issue with the
    tcp_cwnd_validate() logic that can cause cwnd to fail to increase at
    the proper rate for any TCP congestion control, including Reno or
    CUBIC.
    
    Fixes: ca8a22634381 ("tcp: make cwnd-limited checks measurement-based, and gentler")
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Kevin(Yudong) Yang <yyd@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1ba21168faf881c23c270605834d01af260cbb72
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Wed Sep 28 21:39:38 2022 +0800

    mISDN: fix use-after-free bugs in l1oip timer handlers
    
    [ Upstream commit 2568a7e0832ee30b0a351016d03062ab4e0e0a3f ]
    
    The l1oip_cleanup() traverses the l1oip_ilist and calls
    release_card() to cleanup module and stack. However,
    release_card() calls del_timer() to delete the timers
    such as keep_tl and timeout_tl. If the timer handler is
    running, the del_timer() will not stop it and result in
    UAF bugs. One of the processes is shown below:
    
        (cleanup routine)          |        (timer handler)
    release_card()                 | l1oip_timeout()
     ...                           |
     del_timer()                   | ...
     ...                           |
     kfree(hc) //FREE              |
                                   | hc->timeout_on = 0 //USE
    
    Fix by calling del_timer_sync() in release_card(), which
    makes sure the timer handlers have finished before the
    resources, such as l1oip and so on, have been deallocated.
    
    What's more, the hc->workq and hc->socket_thread can kick
    those timers right back in. We add a bool flag to show
    if card is released. Then, check this flag in hc->workq
    and hc->socket_thread.
    
    Fixes: 3712b42d4b1b ("Add layer1 over IP support")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c707fd13fc8d7ce7c4f9f8c63dfdf9845d9aa88
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Sat Sep 24 20:13:09 2022 +0800

    spi/omap100k:Fix PM disable depth imbalance in omap1_spi100k_probe
    
    [ Upstream commit 29f65f2171c85a9633daa380df14009a365f42f2 ]
    
    The pm_runtime_enable will increase power disable depth. Thus
    a pairing decrement is needed on the error handling path to
    keep it balanced according to context.
    
    Fixes:db91841b58f9a ("spi/omap100k: Convert to runtime PM")
    
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20220924121310.78331-4-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4b64328ae687afc821fca2461b9544b1edda564
Author: Zheng Yongjun <zhengyongjun3@huawei.com>
Date:   Thu Sep 8 13:55:13 2022 +0000

    net: fs_enet: Fix wrong check in do_pd_setup
    
    [ Upstream commit ec3f06b542a960806a81345042e4eee3f8c5dec4 ]
    
    Should check of_iomap return value 'fep->fec.fecp' instead of 'fep->fcc.fccp'
    
    Fixes: 976de6a8c304 ("fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.")
    Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44587a2304c447b0e4953070f9cff13404b1f57a
Author: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Date:   Fri Sep 2 14:48:32 2022 +0300

    wifi: rtl8xxxu: gen2: Fix mistake in path B IQ calibration
    
    [ Upstream commit e963a19c64ac0d2f8785d36a27391abd91ac77aa ]
    
    Found by comparing with the vendor driver. Currently this affects
    only the RTL8192EU, which is the only gen2 chip with 2 TX paths
    supported by this driver. It's unclear what kind of effect the
    mistake had in practice, since I don't have any RTL8192EU devices
    to test it.
    
    Fixes: e1547c535ede ("rtl8xxxu: First stab at adding IQK calibration for 8723bu parts")
    Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/30a59f3a-cfa9-8379-7af0-78a8f4c77cfd@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit beb236b2391609867b57015b9bc92dcd7f21df1e
Author: Xu Qiang <xuqiang36@huawei.com>
Date:   Thu Aug 25 06:53:24 2022 +0000

    spi: qup: add missing clk_disable_unprepare on error in spi_qup_pm_resume_runtime()
    
    [ Upstream commit 494a22765ce479c9f8ad181c5d24cffda9f534bb ]
    
    Add the missing clk_disable_unprepare() before return
    from spi_qup_pm_resume_runtime() in the error handling case.
    
    Fixes: dae1a7700b34 (“spi: qup: Handle clocks in pm_runtime suspend and resume”)
    Signed-off-by: Xu Qiang <xuqiang36@huawei.com>
    Link: https://lore.kernel.org/r/20220825065324.68446-2-xuqiang36@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b7d0628ef8645ea43155f907924bb8da1324198
Author: Xu Qiang <xuqiang36@huawei.com>
Date:   Thu Aug 25 06:53:23 2022 +0000

    spi: qup: add missing clk_disable_unprepare on error in spi_qup_resume()
    
    [ Upstream commit 70034320fdc597b8f58b4a43bb547f17c4c5557a ]
    
    Add the missing clk_disable_unprepare() before return
    from spi_qup_resume() in the error handling case.
    
    Fixes: 64ff247a978f (“spi: Add Qualcomm QUP SPI controller support”)
    Signed-off-by: Xu Qiang <xuqiang36@huawei.com>
    Link: https://lore.kernel.org/r/20220825065324.68446-1-xuqiang36@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cf31666912cc4c2904780c0b70ec66a490c13229
Author: Dan Carpenter <error27@gmail.com>
Date:   Fri Aug 19 08:22:32 2022 +0300

    wifi: rtl8xxxu: tighten bounds checking in rtl8xxxu_read_efuse()
    
    [ Upstream commit 620d5eaeb9059636864bda83ca1c68c20ede34a5 ]
    
    There some bounds checking to ensure that "map_addr" is not out of
    bounds before the start of the loop.  But the checking needs to be
    done as we iterate through the loop because "map_addr" gets larger as
    we iterate.
    
    Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/Yv8eGLdBslLAk3Ct@kili
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b0af38df1276cd7028838d5df0796b439cc93df
Author: Hari Chandrakanthan <quic_haric@quicinc.com>
Date:   Wed Jul 27 12:02:29 2022 +0530

    wifi: mac80211: allow bw change during channel switch in mesh
    
    [ Upstream commit 6b75f133fe05c36c52d691ff21545d5757fff721 ]
    
    From 'IEEE Std 802.11-2020 section 11.8.8.4.1':
      The mesh channel switch may be triggered by the need to avoid
      interference to a detected radar signal, or to reassign mesh STA
      channels to ensure the MBSS connectivity.
    
      A 20/40 MHz MBSS may be changed to a 20 MHz MBSS and a 20 MHz
      MBSS may be changed to a 20/40 MHz MBSS.
    
    Since the standard allows the change of bandwidth during
    the channel switch in mesh, remove the bandwidth check present in
    ieee80211_set_csa_beacon.
    
    Fixes: c6da674aff94 ("{nl,cfg,mac}80211: enable the triggering of CSA frame in mesh")
    Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com>
    Link: https://lore.kernel.org/r/1658903549-21218-1-git-send-email-quic_haric@quicinc.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15604ab67179ae27ea3c7fb24b6df32b143257c4
Author: Wen Gong <quic_wgong@quicinc.com>
Date:   Mon Aug 1 10:19:30 2022 -0400

    wifi: ath10k: add peer map clean up for peer delete in ath10k_sta_state()
    
    [ Upstream commit f020d9570a04df0762a2ac5c50cf1d8c511c9164 ]
    
    When peer delete failed in a disconnect operation, use-after-free
    detected by KFENCE in below log. It is because for each vdev_id and
    address, it has only one struct ath10k_peer, it is allocated in
    ath10k_peer_map_event(). When connected to an AP, it has more than
    one HTT_T2H_MSG_TYPE_PEER_MAP reported from firmware, then the
    array peer_map of struct ath10k will be set muti-elements to the
    same ath10k_peer in ath10k_peer_map_event(). When peer delete failed
    in ath10k_sta_state(), the ath10k_peer will be free for the 1st peer
    id in array peer_map of struct ath10k, and then use-after-free happened
    for the 2nd peer id because they map to the same ath10k_peer.
    
    And clean up all peers in array peer_map for the ath10k_peer, then
    user-after-free disappeared
    
    peer map event log:
    [  306.911021] wlan0: authenticate with b0:2a:43:e6:75:0e
    [  306.957187] ath10k_pci 0000:01:00.0: mac vdev 0 peer create b0:2a:43:e6:75:0e (new sta) sta 1 / 32 peer 1 / 33
    [  306.957395] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 246
    [  306.957404] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 198
    [  306.986924] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 166
    
    peer unmap event log:
    [  435.715691] wlan0: deauthenticating from b0:2a:43:e6:75:0e by local choice (Reason: 3=DEAUTH_LEAVING)
    [  435.716802] ath10k_pci 0000:01:00.0: mac vdev 0 peer delete b0:2a:43:e6:75:0e sta ffff990e0e9c2b50 (sta gone)
    [  435.717177] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 246
    [  435.717186] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 198
    [  435.717193] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 166
    
    use-after-free log:
    [21705.888627] wlan0: deauthenticating from d0:76:8f:82:be:75 by local choice (Reason: 3=DEAUTH_LEAVING)
    [21713.799910] ath10k_pci 0000:01:00.0: failed to delete peer d0:76:8f:82:be:75 for vdev 0: -110
    [21713.799925] ath10k_pci 0000:01:00.0: found sta peer d0:76:8f:82:be:75 (ptr 0000000000000000 id 102) entry on vdev 0 after it was supposedly removed
    [21713.799968] ==================================================================
    [21713.799991] BUG: KFENCE: use-after-free read in ath10k_sta_state+0x265/0xb8a [ath10k_core]
    [21713.799991]
    [21713.799997] Use-after-free read at 0x00000000abe1c75e (in kfence-#69):
    [21713.800010]  ath10k_sta_state+0x265/0xb8a [ath10k_core]
    [21713.800041]  drv_sta_state+0x115/0x677 [mac80211]
    [21713.800059]  __sta_info_destroy_part2+0xb1/0x133 [mac80211]
    [21713.800076]  __sta_info_flush+0x11d/0x162 [mac80211]
    [21713.800093]  ieee80211_set_disassoc+0x12d/0x2f4 [mac80211]
    [21713.800110]  ieee80211_mgd_deauth+0x26c/0x29b [mac80211]
    [21713.800137]  cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211]
    [21713.800153]  nl80211_deauthenticate+0xf8/0x121 [cfg80211]
    [21713.800161]  genl_rcv_msg+0x38e/0x3be
    [21713.800166]  netlink_rcv_skb+0x89/0xf7
    [21713.800171]  genl_rcv+0x28/0x36
    [21713.800176]  netlink_unicast+0x179/0x24b
    [21713.800181]  netlink_sendmsg+0x3a0/0x40e
    [21713.800187]  sock_sendmsg+0x72/0x76
    [21713.800192]  ____sys_sendmsg+0x16d/0x1e3
    [21713.800196]  ___sys_sendmsg+0x95/0xd1
    [21713.800200]  __sys_sendmsg+0x85/0xbf
    [21713.800205]  do_syscall_64+0x43/0x55
    [21713.800210]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [21713.800213]
    [21713.800219] kfence-#69: 0x000000009149b0d5-0x000000004c0697fb, size=1064, cache=kmalloc-2k
    [21713.800219]
    [21713.800224] allocated by task 13 on cpu 0 at 21705.501373s:
    [21713.800241]  ath10k_peer_map_event+0x7e/0x154 [ath10k_core]
    [21713.800254]  ath10k_htt_t2h_msg_handler+0x586/0x1039 [ath10k_core]
    [21713.800265]  ath10k_htt_htc_t2h_msg_handler+0x12/0x28 [ath10k_core]
    [21713.800277]  ath10k_htc_rx_completion_handler+0x14c/0x1b5 [ath10k_core]
    [21713.800283]  ath10k_pci_process_rx_cb+0x195/0x1df [ath10k_pci]
    [21713.800294]  ath10k_ce_per_engine_service+0x55/0x74 [ath10k_core]
    [21713.800305]  ath10k_ce_per_engine_service_any+0x76/0x84 [ath10k_core]
    [21713.800310]  ath10k_pci_napi_poll+0x49/0x144 [ath10k_pci]
    [21713.800316]  net_rx_action+0xdc/0x361
    [21713.800320]  __do_softirq+0x163/0x29a
    [21713.800325]  asm_call_irq_on_stack+0x12/0x20
    [21713.800331]  do_softirq_own_stack+0x3c/0x48
    [21713.800337]  __irq_exit_rcu+0x9b/0x9d
    [21713.800342]  common_interrupt+0xc9/0x14d
    [21713.800346]  asm_common_interrupt+0x1e/0x40
    [21713.800351]  ksoftirqd_should_run+0x5/0x16
    [21713.800357]  smpboot_thread_fn+0x148/0x211
    [21713.800362]  kthread+0x150/0x15f
    [21713.800367]  ret_from_fork+0x22/0x30
    [21713.800370]
    [21713.800374] freed by task 708 on cpu 1 at 21713.799953s:
    [21713.800498]  ath10k_sta_state+0x2c6/0xb8a [ath10k_core]
    [21713.800515]  drv_sta_state+0x115/0x677 [mac80211]
    [21713.800532]  __sta_info_destroy_part2+0xb1/0x133 [mac80211]
    [21713.800548]  __sta_info_flush+0x11d/0x162 [mac80211]
    [21713.800565]  ieee80211_set_disassoc+0x12d/0x2f4 [mac80211]
    [21713.800581]  ieee80211_mgd_deauth+0x26c/0x29b [mac80211]
    [21713.800598]  cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211]
    [21713.800614]  nl80211_deauthenticate+0xf8/0x121 [cfg80211]
    [21713.800619]  genl_rcv_msg+0x38e/0x3be
    [21713.800623]  netlink_rcv_skb+0x89/0xf7
    [21713.800628]  genl_rcv+0x28/0x36
    [21713.800632]  netlink_unicast+0x179/0x24b
    [21713.800637]  netlink_sendmsg+0x3a0/0x40e
    [21713.800642]  sock_sendmsg+0x72/0x76
    [21713.800646]  ____sys_sendmsg+0x16d/0x1e3
    [21713.800651]  ___sys_sendmsg+0x95/0xd1
    [21713.800655]  __sys_sendmsg+0x85/0xbf
    [21713.800659]  do_syscall_64+0x43/0x55
    [21713.800663]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
    
    Fixes: d0eeafad1189 ("ath10k: Clean up peer when sta goes away.")
    Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20220801141930.16794-1-quic_wgong@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b436d2e98509f04d72fa79da23b2505c52116cd
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Sep 7 16:40:44 2022 -0700

    sh: machvec: Use char[] for section boundaries
    
    [ Upstream commit c5783af354688b24abd359f7086c282ec74de993 ]
    
    As done for other sections, define the extern as a character array,
    which relaxes many of the compiler-time object size checks, which would
    otherwise assume it's a single long. Solves the following build error:
    
    arch/sh/kernel/machvec.c: error: array subscript 'struct sh_machine_vector[0]' is partly outside array bounds of 'long int[1]' [-Werror=array-bounds]:  => 105:33
    
    Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
    Cc: Rich Felker <dalias@libc.org>
    Cc: linux-sh@vger.kernel.org
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Link: https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2209050944290.964530@ramsan.of.borg/
    Fixes: 9655ad03af2d ("sh: Fixup machvec support.")
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Acked-by: Rich Felker <dalias@libc.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ab3fda4d989adff5726d454c34bb5c5bcb6a9f34
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Sep 20 19:12:52 2022 +0200

    selinux: use "grep -E" instead of "egrep"
    
    commit c969bb8dbaf2f3628927eae73e7c579a74cf1b6e upstream.
    
    The latest version of grep claims that egrep is now obsolete so the build
    now contains warnings that look like:
            egrep: warning: egrep is obsolescent; using grep -E
    fix this by using "grep -E" instead.
    
    Cc: Paul Moore <paul@paul-moore.com>
    Cc: Stephen Smalley <stephen.smalley.work@gmail.com>
    Cc: Eric Paris <eparis@parisplace.org>
    Cc: selinux@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [PM: tweak to remove vdso reference, cleanup subj line]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3eac1e56ebbeed69e3070add240320d54157520
Author: Michal Luczaj <mhal@rbox.co>
Date:   Mon Aug 22 00:06:47 2022 +0200

    KVM: x86/emulator: Fix handing of POP SS to correctly set interruptibility
    
    commit 6aa5c47c351b22c21205c87977c84809cd015fcf upstream.
    
    The emulator checks the wrong variable while setting the CPU
    interruptibility state, the target segment is embedded in the instruction
    opcode, not the ModR/M register.  Fix the condition.
    
    Signed-off-by: Michal Luczaj <mhal@rbox.co>
    Fixes: a5457e7bcf9a ("KVM: emulate: POP SS triggers a MOV SS shadow too")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20220821215900.1419215-1-mhal@rbox.co
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d7dd5658ce192d7e56e77448f8568428734cc30c
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Thu Sep 29 10:49:09 2022 -0400

    ring-buffer: Fix race between reset page and reading page
    
    commit a0fcaaed0c46cf9399d3a2d6e0c87ddb3df0e044 upstream.
    
    The ring buffer is broken up into sub buffers (currently of page size).
    Each sub buffer has a pointer to its "tail" (the last event written to the
    sub buffer). When a new event is requested, the tail is locally
    incremented to cover the size of the new event. This is done in a way that
    there is no need for locking.
    
    If the tail goes past the end of the sub buffer, the process of moving to
    the next sub buffer takes place. After setting the current sub buffer to
    the next one, the previous one that had the tail go passed the end of the
    sub buffer needs to be reset back to the original tail location (before
    the new event was requested) and the rest of the sub buffer needs to be
    "padded".
    
    The race happens when a reader takes control of the sub buffer. As readers
    do a "swap" of sub buffers from the ring buffer to get exclusive access to
    the sub buffer, it replaces the "head" sub buffer with an empty sub buffer
    that goes back into the writable portion of the ring buffer. This swap can
    happen as soon as the writer moves to the next sub buffer and before it
    updates the last sub buffer with padding.
    
    Because the sub buffer can be released to the reader while the writer is
    still updating the padding, it is possible for the reader to see the event
    that goes past the end of the sub buffer. This can cause obvious issues.
    
    To fix this, add a few memory barriers so that the reader definitely sees
    the updates to the sub buffer, and also waits until the writer has put
    back the "tail" of the sub buffer back to the last event that was written
    on it.
    
    To be paranoid, it will only spin for 1 second, otherwise it will
    warn and shutdown the ring buffer code. 1 second should be enough as
    the writer does have preemption disabled. If the writer doesn't move
    within 1 second (with preemption disabled) something is horribly
    wrong. No interrupt should last 1 second!
    
    Link: https://lore.kernel.org/all/20220830120854.7545-1-jiazi.li@transsion.com/
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216369
    Link: https://lkml.kernel.org/r/20220929104909.0650a36c@gandalf.local.home
    
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Fixes: c7b0930857e22 ("ring-buffer: prevent adding write in discarded area")
    Reported-by: Jiazi.Li <jiazi.li@transsion.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13b5e513c9cbbe835e3b2a99f65c1cd78570d995
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Sep 27 19:15:25 2022 -0400

    ring-buffer: Check pending waiters when doing wake ups as well
    
    commit ec0bbc5ec5664dcee344f79373852117dc672c86 upstream.
    
    The wake up waiters only checks the "wakeup_full" variable and not the
    "full_waiters_pending". The full_waiters_pending is set when a waiter is
    added to the wait queue. The wakeup_full is only set when an event is
    triggered, and it clears the full_waiters_pending to avoid multiple calls
    to irq_work_queue().
    
    The irq_work callback really needs to check both wakeup_full as well as
    full_waiters_pending such that this code can be used to wake up waiters
    when a file is closed that represents the ring buffer and the waiters need
    to be woken up.
    
    Link: https://lkml.kernel.org/r/20220927231824.209460321@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Fixes: 15693458c4bc0 ("tracing/ring-buffer: Move poll wake ups into ring buffer code")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4548d9f5f9d9816c55422d5c9e7d2eed40668c5f
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Sep 27 14:43:17 2022 -0400

    ring-buffer: Allow splice to read previous partially read pages
    
    commit fa8f4a89736b654125fb254b0db753ac68a5fced upstream.
    
    If a page is partially read, and then the splice system call is run
    against the ring buffer, it will always fail to read, no matter how much
    is in the ring buffer. That's because the code path for a partial read of
    the page does will fail if the "full" flag is set.
    
    The splice system call wants full pages, so if the read of the ring buffer
    is not yet full, it should return zero, and the splice will block. But if
    a previous read was done, where the beginning has been consumed, it should
    still be given to the splice caller if the rest of the page has been
    written to.
    
    This caused the splice command to never consume data in this scenario, and
    let the ring buffer just fill up and lose events.
    
    Link: https://lkml.kernel.org/r/20220927144317.46be6b80@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Fixes: 8789a9e7df6bf ("ring-buffer: read page interface")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b22c5a9a3733f91ea18dc2db62c131a2b7d6bd7
Author: Jinke Han <hanjinke.666@bytedance.com>
Date:   Sat Sep 3 09:24:29 2022 +0800

    ext4: place buffer head allocation before handle start
    
    commit d1052d236eddf6aa851434db1897b942e8db9921 upstream.
    
    In our product environment, we encounter some jbd hung waiting handles to
    stop while several writters were doing memory reclaim for buffer head
    allocation in delay alloc write path. Ext4 do buffer head allocation with
    holding transaction handle which may be blocked too long if the reclaim
    works not so smooth. According to our bcc trace, the reclaim time in
    buffer head allocation can reach 258s and the jbd transaction commit also
    take almost the same time meanwhile. Except for these extreme cases,
    we often see several seconds delays for cgroup memory reclaim on our
    servers. This is more likely to happen considering docker environment.
    
    One thing to note, the allocation of buffer heads is as often as page
    allocation or more often when blocksize less than page size. Just like
    page cache allocation, we should also place the buffer head allocation
    before startting the handle.
    
    Cc: stable@kernel.org
    Signed-off-by: Jinke Han <hanjinke.666@bytedance.com>
    Link: https://lore.kernel.org/r/20220903012429.22555-1-hanjinke.666@bytedance.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c5875ea6efcb81e0419f9edbac4f4412d5867221
Author: Lalith Rajendran <lalithkraj@google.com>
Date:   Thu Aug 18 21:40:49 2022 +0000

    ext4: make ext4_lazyinit_thread freezable
    
    commit 3b575495ab8dbb4dbe85b4ac7f991693c3668ff5 upstream.
    
    ext4_lazyinit_thread is not set freezable. Hence when the thread calls
    try_to_freeze it doesn't freeze during suspend and continues to send
    requests to the storage during suspend, resulting in suspend failures.
    
    Cc: stable@kernel.org
    Signed-off-by: Lalith Rajendran <lalithkraj@google.com>
    Link: https://lore.kernel.org/r/20220818214049.1519544-1-lalithkraj@google.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dc451578446afd03c0c21913993c08898a691435
Author: Baokun Li <libaokun1@huawei.com>
Date:   Fri Aug 5 20:39:47 2022 +0800

    ext4: fix null-ptr-deref in ext4_write_info
    
    commit f9c1f248607d5546075d3f731e7607d5571f2b60 upstream.
    
    I caught a null-ptr-deref bug as follows:
    ==================================================================
    KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
    CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339
    RIP: 0010:ext4_write_info+0x53/0x1b0
    [...]
    Call Trace:
     dquot_writeback_dquots+0x341/0x9a0
     ext4_sync_fs+0x19e/0x800
     __sync_filesystem+0x83/0x100
     sync_filesystem+0x89/0xf0
     generic_shutdown_super+0x79/0x3e0
     kill_block_super+0xa1/0x110
     deactivate_locked_super+0xac/0x130
     deactivate_super+0xb6/0xd0
     cleanup_mnt+0x289/0x400
     __cleanup_mnt+0x16/0x20
     task_work_run+0x11c/0x1c0
     exit_to_user_mode_prepare+0x203/0x210
     syscall_exit_to_user_mode+0x5b/0x3a0
     do_syscall_64+0x59/0x70
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
     ==================================================================
    
    Above issue may happen as follows:
    -------------------------------------
    exit_to_user_mode_prepare
     task_work_run
      __cleanup_mnt
       cleanup_mnt
        deactivate_super
         deactivate_locked_super
          kill_block_super
           generic_shutdown_super
            shrink_dcache_for_umount
             dentry = sb->s_root
             sb->s_root = NULL              <--- Here set NULL
            sync_filesystem
             __sync_filesystem
              sb->s_op->sync_fs > ext4_sync_fs
               dquot_writeback_dquots
                sb->dq_op->write_info > ext4_write_info
                 ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2)
                  d_inode(sb->s_root)
                   s_root->d_inode          <--- Null pointer dereference
    
    To solve this problem, we use ext4_journal_start_sb directly
    to avoid s_root being used.
    
    Cc: stable@kernel.org
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220805123947.565152-1-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b31cc533665899965e351aae6cc3c3f3b9cc076
Author: Jan Kara <jack@suse.cz>
Date:   Wed Jul 27 17:57:53 2022 +0200

    ext4: avoid crash when inline data creation follows DIO write
    
    commit 4bb26f2885ac6930984ee451b952c5a6042f2c0e upstream.
    
    When inode is created and written to using direct IO, there is nothing
    to clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets
    truncated later to say 1 byte and written using normal write, we will
    try to store the data as inline data. This confuses the code later
    because the inode now has both normal block and inline data allocated
    and the confusion manifests for example as:
    
    kernel BUG at fs/ext4/inode.c:2721!
    invalid opcode: 0000 [#1] PREEMPT SMP KASAN
    CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
    RIP: 0010:ext4_writepages+0x363d/0x3660
    RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293
    RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180
    RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000
    RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b
    R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128
    R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001
    FS:  00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0
    Call Trace:
     <TASK>
     do_writepages+0x397/0x640
     filemap_fdatawrite_wbc+0x151/0x1b0
     file_write_and_wait_range+0x1c9/0x2b0
     ext4_sync_file+0x19e/0xa00
     vfs_fsync_range+0x17b/0x190
     ext4_buffered_write_iter+0x488/0x530
     ext4_file_write_iter+0x449/0x1b90
     vfs_write+0xbcd/0xf40
     ksys_write+0x198/0x2c0
     __x64_sys_write+0x7b/0x90
     do_syscall_64+0x3d/0x90
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
     </TASK>
    
    Fix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doing
    direct IO write to a file.
    
    Cc: stable@kernel.org
    Reported-by: Tadeusz Struk <tadeusz.struk@linaro.org>
    Reported-by: syzbot+bd13648a53ed6933ca49@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=a1e89d09bbbcbd5c4cb45db230ee28c822953984
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Lukas Czerner <lczerner@redhat.com>
    Tested-by: Tadeusz Struk<tadeusz.struk@linaro.org>
    Link: https://lore.kernel.org/r/20220727155753.13969-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9043a24c6e340d45b204d294a25044726fd2770
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Tue Oct 4 00:05:19 2022 +0900

    nilfs2: fix use-after-free bug of struct nilfs_root
    
    commit d325dc6eb763c10f591c239550b8c7e5466a5d09 upstream.
    
    If the beginning of the inode bitmap area is corrupted on disk, an inode
    with the same inode number as the root inode can be allocated and fail
    soon after.  In this case, the subsequent call to nilfs_clear_inode() on
    that bogus root inode will wrongly decrement the reference counter of
    struct nilfs_root, and this will erroneously free struct nilfs_root,
    causing kernel oopses.
    
    This fixes the problem by changing nilfs_new_inode() to skip reserved
    inode numbers while repairing the inode bitmap.
    
    Link: https://lkml.kernel.org/r/20221003150519.39789-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+b8c672b0e22615c80fe0@syzkaller.appspotmail.com
    Reported-by: Khalid Masum <khalid.masum.92@gmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 347a969b130c2a496f471f14b354119b82664f0a
Author: Hyunwoo Kim <imv4bel@gmail.com>
Date:   Sun Sep 25 06:32:43 2022 -0700

    fbdev: smscufx: Fix use-after-free in ufx_ops_open()
    
    commit 5610bcfe8693c02e2e4c8b31427f1bdbdecc839c upstream.
    
    A race condition may occur if the user physically removes the
    USB device while calling open() for this device node.
    
    This is a race condition between the ufx_ops_open() function and
    the ufx_usb_disconnect() function, which may eventually result in UAF.
    
    So, add a mutex to the ufx_ops_open() and ufx_usb_disconnect() functions
    to avoid race contidion of krefs.
    
    Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 691c8290847dcde260e93766b143b4e881fc7176
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Wed Sep 21 20:49:16 2022 +0100

    PCI: Sanitise firmware BAR assignments behind a PCI-PCI bridge
    
    commit 0e32818397426a688f598f35d3bc762eca6d7592 upstream.
    
    When pci_assign_resource() is unable to assign resources to a BAR, it uses
    pci_revert_fw_address() to fall back to a firmware assignment (if any).
    Previously pci_revert_fw_address() assumed all addresses could reach the
    device, but this is not true if the device is below a bridge that only
    forwards addresses within its windows.
    
    This problem was observed on a Tyan Tomcat IV S1564D system where the BIOS
    did not assign valid addresses to several bridges and USB devices:
    
      pci 0000:00:11.0: PCI-to-PCIe bridge to [bus 01-ff]
      pci 0000:00:11.0:   bridge window [io  0xe000-0xefff]
      pci 0000:01:00.0: PCIe Upstream Port to [bus 02-ff]
      pci 0000:01:00.0:   bridge window [io  0x0000-0x0fff]   # unreachable
      pci 0000:02:02.0: PCIe Downstream Port to [bus 05-ff]
      pci 0000:02:02.0:   bridge window [io  0x0000-0x0fff]   # unreachable
      pci 0000:05:00.0: PCIe-to-PCI bridge to [bus 06-ff]
      pci 0000:05:00.0:   bridge window [io  0x0000-0x0fff]   # unreachable
      pci 0000:06:08.0: USB UHCI 1.1
      pci 0000:06:08.0: BAR 4: [io  0xfce0-0xfcff]            # unreachable
      pci 0000:06:08.1: USB UHCI 1.1
      pci 0000:06:08.1: BAR 4: [io  0xfce0-0xfcff]            # unreachable
      pci 0000:06:08.0: can't claim BAR 4 [io  0xfce0-0xfcff]: no compatible bridge window
      pci 0000:06:08.1: can't claim BAR 4 [io  0xfce0-0xfcff]: no compatible bridge window
    
    During the first pass of assigning unassigned resources, there was not
    enough I/O space available, so we couldn't assign the 06:08.0 BAR and
    reverted to the firmware assignment (still unreachable).  Reverting the
    06:08.1 assignment failed because it conflicted with 06:08.0:
    
      pci 0000:00:11.0:   bridge window [io  0xe000-0xefff]
      pci 0000:01:00.0: no space for bridge window [io  size 0x2000]
      pci 0000:02:02.0: no space for bridge window [io  size 0x1000]
      pci 0000:05:00.0: no space for bridge window [io  size 0x1000]
      pci 0000:06:08.0: BAR 4: no space for [io  size 0x0020]
      pci 0000:06:08.0: BAR 4: trying firmware assignment [io  0xfce0-0xfcff]
      pci 0000:06:08.1: BAR 4: no space for [io  size 0x0020]
      pci 0000:06:08.1: BAR 4: trying firmware assignment [io  0xfce0-0xfcff]
      pci 0000:06:08.1: BAR 4: [io  0xfce0-0xfcff] conflicts with 0000:06:08.0 [io  0xfce0-0xfcff]
    
    A subsequent pass assigned valid bridge windows and a valid 06:08.1 BAR,
    but left the 06:08.0 BAR alone, so the UHCI device was still unusable:
    
      pci 0000:00:11.0:   bridge window [io  0xe000-0xefff] released
      pci 0000:00:11.0:   bridge window [io  0x1000-0x2fff]   # reassigned
      pci 0000:01:00.0:   bridge window [io  0x1000-0x2fff]   # reassigned
      pci 0000:02:02.0:   bridge window [io  0x2000-0x2fff]   # reassigned
      pci 0000:05:00.0:   bridge window [io  0x2000-0x2fff]   # reassigned
      pci 0000:06:08.0: BAR 4: assigned [io  0xfce0-0xfcff]   # left alone
      pci 0000:06:08.1: BAR 4: assigned [io  0x2000-0x201f]
      ...
      uhci_hcd 0000:06:08.0: host system error, PCI problems?
      uhci_hcd 0000:06:08.0: host controller process error, something bad happened!
      uhci_hcd 0000:06:08.0: host controller halted, very bad!
      uhci_hcd 0000:06:08.0: HCRESET not completed yet!
      uhci_hcd 0000:06:08.0: HC died; cleaning up
    
    If the address assigned by firmware is not reachable because it's not
    within upstream bridge windows, fail instead of assigning the unusable
    address from firmware.
    
    [bhelgaas: commit log, use pci_upstream_bridge()]
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=16263
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203012338460.46819@angie.orcam.me.uk
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209211921250.29493@angie.orcam.me.uk
    Fixes: 58c84eda0756 ("PCI: fall back to original BIOS BAR addresses")
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org # v2.6.35+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f96aa67c2ccbd7e41b8dc992b8d13cfe206d571
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Tue Jul 12 15:52:55 2022 +0800

    UM: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK
    
    commit 16c546e148fa6d14a019431436a6f7b4087dbccd upstream.
    
    When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
    cpu_max_bits_warn() generates a runtime warning similar as below while
    we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)
    instead of NR_CPUS to iterate CPUs.
    
    [    3.052463] ------------[ cut here ]------------
    [    3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0
    [    3.070072] Modules linked in: efivarfs autofs4
    [    3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052
    [    3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000
    [    3.109127]         9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430
    [    3.118774]         90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff
    [    3.128412]         0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890
    [    3.138056]         0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa
    [    3.147711]         ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000
    [    3.157364]         900000000101c998 0000000000000004 9000000000ef7430 0000000000000000
    [    3.167012]         0000000000000009 000000000000006c 0000000000000000 0000000000000000
    [    3.176641]         9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286
    [    3.186260]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c
    [    3.195868]         ...
    [    3.199917] Call Trace:
    [    3.203941] [<90000000002086d8>] show_stack+0x38/0x14c
    [    3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88
    [    3.217625] [<900000000023d268>] __warn+0xd0/0x100
    [    3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc
    [    3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0
    [    3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4
    [    3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4
    [    3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0
    [    3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100
    [    3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94
    [    3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160
    [    3.281824] ---[ end trace 8b484262b4b8c24c ]---
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 263db3d8c886d62c30385591d4c59d8fd9ee79ba
Author: Helge Deller <deller@gmx.de>
Date:   Fri Oct 14 10:13:55 2022 +0200

    parisc: fbdev/stifb: Align graphics memory size to 4MB
    
    commit aca7c13d3bee81a968337a5515411409ae9d095d upstream.
    
    Independend of the current graphics resolution, adjust the reported
    graphics card memory size to the next 4MB boundary.
    This fixes the fbtest program which expects a naturally aligned size.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4314f552eddfd6e1fd8b7fa2154545aa1b82e954
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri Sep 9 13:25:29 2022 +0200

    regulator: qcom_rpm: Fix circular deferral regression
    
    commit 8478ed5844588703a1a4c96a004b1525fbdbdd5e upstream.
    
    On recent kernels, the PM8058 L16 (or any other PM8058 LDO-regulator)
    does not come up if they are supplied by an SMPS-regulator. This
    is not very strange since the regulators are registered in a long
    array and the L-regulators are registered before the S-regulators,
    and if an L-regulator defers, it will never get around to registering
    the S-regulator that it needs.
    
    See arch/arm/boot/dts/qcom-apq8060-dragonboard.dts:
    
    pm8058-regulators {
        (...)
        vdd_l13_l16-supply = <&pm8058_s4>;
        (...)
    
    Ooops.
    
    Fix this by moving the PM8058 S-regulators first in the array.
    
    Do the same for the PM8901 S-regulators (though this is currently
    not causing any problems with out device trees) so that the pattern
    of registration order is the same on all PMnnnn chips.
    
    Fixes: 087a1b5cdd55 ("regulator: qcom: Rework to single platform device")
    Cc: stable@vger.kernel.org
    Cc: Andy Gross <agross@kernel.org>
    Cc: Bjorn Andersson <andersson@kernel.org>
    Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
    Cc: linux-arm-msm@vger.kernel.org
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20220909112529.239143-1-linus.walleij@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c01e527d406707f69d76404e7b827e14ab2b4077
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Fri Sep 23 21:45:52 2022 +0800

    quota: Check next/prev free block number after reading from quota file
    
    commit 6c8ea8b8cd4722efd419f91ca46a2dc81b7d89a3 upstream.
    
    Following process:
     Init: v2_read_file_info: <3> dqi_free_blk 0 dqi_free_entry 5 dqi_blks 6
    
     Step 1. chown bin f_a -> dquot_acquire -> v2_write_dquot:
      qtree_write_dquot
       do_insert_tree
        find_free_dqentry
         get_free_dqblk
          write_blk(info->dqi_blocks) // info->dqi_blocks = 6, failure. The
               content in physical block (corresponding to blk 6) is random.
    
     Step 2. chown root f_a -> dquot_transfer -> dqput_all -> dqput ->
             ext4_release_dquot -> v2_release_dquot -> qtree_delete_dquot:
      dquot_release
       remove_tree
        free_dqentry
         put_free_dqblk(6)
          info->dqi_free_blk = blk    // info->dqi_free_blk = 6
    
     Step 3. drop cache (buffer head for block 6 is released)
    
     Step 4. chown bin f_b -> dquot_acquire -> commit_dqblk -> v2_write_dquot:
      qtree_write_dquot
       do_insert_tree
        find_free_dqentry
         get_free_dqblk
          dh = (struct qt_disk_dqdbheader *)buf
          blk = info->dqi_free_blk     // 6
          ret = read_blk(info, blk, buf)  // The content of buf is random
          info->dqi_free_blk = le32_to_cpu(dh->dqdh_next_free)  // random blk
    
     Step 5. chown bin f_c -> notify_change -> ext4_setattr -> dquot_transfer:
      dquot = dqget -> acquire_dquot -> ext4_acquire_dquot -> dquot_acquire ->
              commit_dqblk -> v2_write_dquot -> dq_insert_tree:
       do_insert_tree
        find_free_dqentry
         get_free_dqblk
          blk = info->dqi_free_blk    // If blk < 0 and blk is not an error
                                         code, it will be returned as dquot
    
      transfer_to[USRQUOTA] = dquot  // A random negative value
      __dquot_transfer(transfer_to)
       dquot_add_inodes(transfer_to[cnt])
        spin_lock(&dquot->dq_dqb_lock)  // page fault
    
    , which will lead to kernel page fault:
     Quota error (device sda): qtree_write_dquot: Error -8000 occurred
     while creating quota
     BUG: unable to handle page fault for address: ffffffffffffe120
     #PF: supervisor write access in kernel mode
     #PF: error_code(0x0002) - not-present page
     Oops: 0002 [#1] PREEMPT SMP
     CPU: 0 PID: 5974 Comm: chown Not tainted 6.0.0-rc1-00004
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
     RIP: 0010:_raw_spin_lock+0x3a/0x90
     Call Trace:
      dquot_add_inodes+0x28/0x270
      __dquot_transfer+0x377/0x840
      dquot_transfer+0xde/0x540
      ext4_setattr+0x405/0x14d0
      notify_change+0x68e/0x9f0
      chown_common+0x300/0x430
      __x64_sys_fchownat+0x29/0x40
    
    In order to avoid accessing invalid quota memory address, this patch adds
    block number checking of next/prev free block read from quota file.
    
    Fetch a reproducer in [Link].
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216372
    Fixes: 1da177e4c3f4152 ("Linux-2.6.12-rc2")
    CC: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220923134555.2623931-2-chengzhihao1@huawei.com
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ab0c40bd8a0c2bb82981010a101a8f2f81b403f5
Author: Alexander Aring <aahringo@redhat.com>
Date:   Mon Aug 15 15:43:15 2022 -0400

    fs: dlm: handle -EBUSY first in lock arg validation
    
    commit 44637ca41d551d409a481117b07fa209b330fca9 upstream.
    
    During lock arg validation, first check for -EBUSY cases, then for
    -EINVAL cases. The -EINVAL checks look at lkb state variables
    which are not stable when an lkb is busy and would cause an
    -EBUSY result, e.g. lkb->lkb_grmode.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e07ea4e8624285cc59384634e294abb8ed873c47
Author: Alexander Aring <aahringo@redhat.com>
Date:   Mon Aug 15 15:43:14 2022 -0400

    fs: dlm: fix race between test_bit() and queue_work()
    
    commit eef6ec9bf390e836a6c4029f3620fe49528aa1fe upstream.
    
    This patch fixes a race by using ls_cb_mutex around the bit
    operations and conditional code blocks for LSFL_CB_DELAY.
    
    The function dlm_callback_stop() expects to stop all callbacks and
    flush all currently queued onces. The set_bit() is not enough because
    there can still be queue_work() after the workqueue was flushed.
    To avoid queue_work() after set_bit(), surround both by ls_cb_mutex.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 805df046c9aa51f28bd78cafe8e8bc4ca072dc9d
Author: Michael Hennerich <michael.hennerich@analog.com>
Date:   Tue Sep 13 09:34:12 2022 +0200

    iio: dac: ad5593r: Fix i2c read protocol requirements
    
    commit 558a25f903b4af6361b7fbeea08a6446a0745653 upstream.
    
    For reliable operation across the full range of supported
    interface rates, the AD5593R needs a STOP condition between
    address write, and data read (like show in the datasheet Figure 40)
    so in turn i2c_smbus_read_word_swapped cannot be used.
    
    While at it, a simple helper was added to make the code simpler.
    
    Fixes: 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs")
    Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
    Signed-off-by: Nuno Sá <nuno.sa@analog.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220913073413.140475-2-nuno.sa@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 848f473a1e9d98a79bc83e9979ee5c6ba8e436bc
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Sep 30 12:01:29 2022 +0200

    ALSA: usb-audio: Fix NULL dererence at error path
    
    commit 568be8aaf8a535f79c4db76cabe17b035aa2584d upstream.
    
    At an error path to release URB buffers and contexts, the driver might
    hit a NULL dererence for u->urb pointer, when u->buffer_size has been
    already set but the actual URB allocation failed.
    
    Fix it by adding the NULL check of urb.  Also, make sure that
    buffer_size is cleared after the error path or the close.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Sabri N. Ferreiro <snferreiro1@gmail.com>
    Link: https://lore.kernel.org/r/CAKG+3NRjTey+fFfUEGwuxL-pi_=T4cUskYG9OzpzHytF+tzYng@mail.gmail.com
    Link: https://lore.kernel.org/r/20220930100129.19445-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0604e5e5537af099ea2f6dfd892afe5c92db8a80
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Sep 30 12:01:51 2022 +0200

    ALSA: usb-audio: Fix potential memory leaks
    
    commit 6382da0828995af87aa8b8bef28cc61aceb4aff3 upstream.
    
    When the driver hits -ENOMEM at allocating a URB or a buffer, it
    aborts and goes to the error path that releases the all previously
    allocated resources.  However, when -ENOMEM hits at the middle of the
    sync EP URB allocation loop, the partially allocated URBs might be
    left without released, because ep->nurbs is still zero at that point.
    
    Fix it by setting ep->nurbs at first, so that the error handler loops
    over the full URB list.
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20220930100151.19461-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b2baa49c8396e2cfdae9a9aab2790c554ea086f
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Oct 11 09:01:46 2022 +0200

    ALSA: rawmidi: Drop register_mutex in snd_rawmidi_free()
    
    commit a70aef7982b012e86dfd39fbb235e76a21ae778a upstream.
    
    The register_mutex taken around the dev_unregister callback call in
    snd_rawmidi_free() may potentially lead to a mutex deadlock, when OSS
    emulation and a hot unplug are involved.
    
    Since the mutex doesn't protect the actual race (as the registration
    itself is already protected by another means), let's drop it.
    
    Link: https://lore.kernel.org/r/CAB7eexJP7w1B0mVgDF0dQ+gWor7UdkiwPczmL7pn91xx8xpzOA@mail.gmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20221011070147.7611-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 090f988f0415ff664667f85e4156e6109567e440
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Oct 11 09:01:47 2022 +0200

    ALSA: oss: Fix potential deadlock at unregistration
    
    commit 97d917879d7f92df09c3f21fd54609a8bcd654b2 upstream.
    
    We took sound_oss_mutex around the calls of unregister_sound_special()
    at unregistering OSS devices.  This may, however, lead to a deadlock,
    because we manage the card release via the card's device object, and
    the release may happen at unregister_sound_special() call -- which
    will take sound_oss_mutex again in turn.
    
    Although the deadlock might be fixed by relaxing the rawmidi mutex in
    the previous commit, it's safer to move unregister_sound_special()
    calls themselves out of the sound_oss_mutex, too.  The call is
    race-safe as the function has a spinlock protection by itself.
    
    Link: https://lore.kernel.org/r/CAB7eexJP7w1B0mVgDF0dQ+gWor7UdkiwPczmL7pn91xx8xpzOA@mail.gmail.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20221011070147.7611-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e8a4fed4b3249a1b414f3e5f343bb39f616f001
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Sep 22 18:46:04 2022 +0200

    random: use expired timer rather than wq for mixing fast pool
    
    commit 748bc4dd9e663f23448d8ad7e58c011a67ea1eca upstream.
    
    Previously, the fast pool was dumped into the main pool periodically in
    the fast pool's hard IRQ handler. This worked fine and there weren't
    problems with it, until RT came around. Since RT converts spinlocks into
    sleeping locks, problems cropped up. Rather than switching to raw
    spinlocks, the RT developers preferred we make the transformation from
    originally doing:
    
        do_some_stuff()
        spin_lock()
        do_some_other_stuff()
        spin_unlock()
    
    to doing:
    
        do_some_stuff()
        queue_work_on(some_other_stuff_worker)
    
    This is an ordinary pattern done all over the kernel. However, Sherry
    noticed a 10% performance regression in qperf TCP over a 40gbps
    InfiniBand card. Quoting her message:
    
    > MT27500 Family [ConnectX-3] cards:
    > Infiniband device 'mlx4_0' port 1 status:
    > default gid: fe80:0000:0000:0000:0010:e000:0178:9eb1
    > base lid: 0x6
    > sm lid: 0x1
    > state: 4: ACTIVE
    > phys state: 5: LinkUp
    > rate: 40 Gb/sec (4X QDR)
    > link_layer: InfiniBand
    >
    > Cards are configured with IP addresses on private subnet for IPoIB
    > performance testing.
    > Regression identified in this bug is in TCP latency in this stack as reported
    > by qperf tcp_lat metric:
    >
    > We have one system listen as a qperf server:
    > [root@yourQperfServer ~]# qperf
    >
    > Have the other system connect to qperf server as a client (in this
    > case, it’s X7 server with Mellanox card):
    > [root@yourQperfClient ~]# numactl -m0 -N0 qperf 20.20.20.101 -v -uu -ub --time 60 --wait_server 20 -oo msg_size:4K:1024K:*2 tcp_lat
    
    Rather than incur the scheduling latency from queue_work_on, we can
    instead switch to running on the next timer tick, on the same core. This
    also batches things a bit more -- once per jiffy -- which is okay now
    that mix_interrupt_randomness() can credit multiple bits at once.
    
    Reported-by: Sherry Yang <sherry.yang@oracle.com>
    Tested-by: Paul Webb <paul.x.webb@oracle.com>
    Cc: Sherry Yang <sherry.yang@oracle.com>
    Cc: Phillip Goerl <phillip.goerl@oracle.com>
    Cc: Jack Vogel <jack.vogel@oracle.com>
    Cc: Nicky Veitch <nicky.veitch@oracle.com>
    Cc: Colm Harrington <colm.harrington@oracle.com>
    Cc: Ramanan Govindarajan <ramanan.govindarajan@oracle.com>
    Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: Dominik Brodowski <linux@dominikbrodowski.net>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Sultan Alsawaf <sultan@kerneltoast.com>
    Cc: stable@vger.kernel.org
    Fixes: 58340f8e952b ("random: defer fast pool mixing to worker")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6496eb4353eb55f12fca7a6f812662f477c301a9
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Thu Aug 18 17:44:09 2022 +0200

    Input: xpad - fix wireless 360 controller breaking after suspend
    
    commit a17b9841152e7f4621619902b347e2cc39c32996 upstream.
    
    Suspending and resuming the system can sometimes cause the out
    URB to get hung after a reset_resume. This causes LED setting
    and force feedback to break on resume. To avoid this, just drop
    the reset_resume callback so the USB core rebinds xpad to the
    wireless pads on resume if a reset happened.
    
    A nice side effect of this change is the LED ring on wireless
    controllers is now set correctly on system resume.
    
    Cc: stable@vger.kernel.org
    Fixes: 4220f7db1e42 ("Input: xpad - workaround dead irq_out after suspend/ resume")
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Link: https://lore.kernel.org/r/20220818154411.510308-3-rojtberg@gmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8520bbe9a79f1ea99de7e282f61764fcff1ed15
Author: Pavel Rojtberg <rojtberg@gmail.com>
Date:   Thu Aug 18 17:44:08 2022 +0200

    Input: xpad - add supported devices as contributed on github
    
    commit b382c5e37344883dc97525d05f1f6b788f549985 upstream.
    
    This is based on multiple commits at https://github.com/paroj/xpad
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jasper Poppe <jgpoppe@gmail.com>
    Signed-off-by: Jeremy Palmer <jpalmer@linz.govt.nz>
    Signed-off-by: Ruineka <ruinairas1992@gmail.com>
    Signed-off-by: Cleber de Mattos Casali <clebercasali@gmail.com>
    Signed-off-by: Kyle Gospodnetich <me@kylegospodneti.ch>
    Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
    Link: https://lore.kernel.org/r/20220818154411.510308-2-rojtberg@gmail.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dedb8fa88af4006945e590c0d9ca8d97d75c6d53
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Sep 8 16:14:00 2022 +0200

    random: restore O_NONBLOCK support
    
    commit cd4f24ae9404fd31fc461066e57889be3b68641b upstream.
    
    Prior to 5.6, when /dev/random was opened with O_NONBLOCK, it would
    return -EAGAIN if there was no entropy. When the pools were unified in
    5.6, this was lost. The post 5.6 behavior of blocking until the pool is
    initialized, and ignoring O_NONBLOCK in the process, went unnoticed,
    with no reports about the regression received for two and a half years.
    However, eventually this indeed did break somebody's userspace.
    
    So we restore the old behavior, by returning -EAGAIN if the pool is not
    initialized. Unlike the old /dev/random, this can only occur during
    early boot, after which it never blocks again.
    
    In order to make this O_NONBLOCK behavior consistent with other
    expectations, also respect users reading with preadv2(RWF_NOWAIT) and
    similar.
    
    Fixes: 30c08efec888 ("random: make /dev/random be almost like /dev/urandom")
    Reported-by: Guozihua <guozihua@huawei.com>
    Reported-by: Zhongguohua <zhongguohua1@huawei.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Andrew Lutomirski <luto@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27ed7d15c675c046375da15257e7b6b8c20bef02
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Oct 5 15:10:09 2022 +0200

    wifi: mac80211_hwsim: avoid mac80211 warning on bad rate
    
    commit 1833b6f46d7e2830251a063935ab464256defe22 upstream.
    
    If the tool on the other side (e.g. wmediumd) gets confused
    about the rate, we hit a warning in mac80211. Silence that
    by effectively duplicating the check here and dropping the
    frame silently (in mac80211 it's dropped with the warning).
    
    Reported-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Tested-by: Sönke Huster <shuster@seemoo.tu-darmstadt.de>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b0ca6c9977884895afc1af3f4a8d13f2b05a526
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Sep 22 18:46:04 2022 +0200

    random: avoid reading two cache lines on irq randomness
    
    commit 9ee0507e896b45af6d65408c77815800bce30008 upstream.
    
    In order to avoid reading and dirtying two cache lines on every IRQ,
    move the work_struct to the bottom of the fast_pool struct. add_
    interrupt_randomness() always touches .pool and .count, which are
    currently split, because .mix pushes everything down. Instead, move .mix
    to the bottom, so that .pool and .count are always in the first cache
    line, since .mix is only accessed when the pool is full.
    
    Fixes: 58340f8e952b ("random: defer fast pool mixing to worker")
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6a282df600143a54f97b989123c01a8ab4a3ccb
Author: Frank Wunderlich <frank-w@public-files.de>
Date:   Mon Sep 26 17:07:39 2022 +0200

    USB: serial: qcserial: add new usb-id for Dell branded EM7455
    
    commit eee48781ea199e32c1d0c4732641c494833788ca upstream.
    
    Add support for Dell 5811e (EM7455) with USB-id 0x413c:0x81c2.
    
    Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35db0282da84ad200054ad5af0fd6c2f693b17f8
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Sep 9 08:54:47 2022 +0200

    scsi: stex: Properly zero out the passthrough command structure
    
    commit 6022f210461fef67e6e676fd8544ca02d1bcfa7a upstream.
    
    The passthrough structure is declared off of the stack, so it needs to be
    set to zero before copied back to userspace to prevent any unintentional
    data leakage.  Switch things to be statically allocated which will fill the
    unused fields with 0 automatically.
    
    Link: https://lore.kernel.org/r/YxrjN3OOw2HHl9tx@kroah.com
    Cc: stable@kernel.org
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Reported-by: hdthky <hdthky0@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4a13e588ad07977fadb6095a01d1bb5515346b7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sat Oct 1 16:21:24 2022 +0200

    ALSA: hda: Fix position reporting on Poulsbo
    
    commit 56e696c0f0c71b77fff921fc94b58a02f0445b2c upstream.
    
    Hans reported that his Sony VAIO VPX11S1E showed the broken sound
    behavior at the start of the stream for a couple of seconds, and it
    turned out that the position_fix=1 option fixes the issue.  It implies
    that the position reporting is inaccurate, and very likely hitting on
    all Poulsbo devices.
    
    The patch applies the workaround for Poulsbo generically to switch to
    LPIB mode instead of the default position buffer.
    
    Reported-and-tested-by: Hans de Goede <hdegoede@redhat.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/3e8697e1-87c6-7a7b-d2e8-b21f1d2f181b@redhat.com
    Link: https://lore.kernel.org/r/20221001142124.7241-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d1f1a0d96869df9df821a5270ba52e05bbeacda
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Fri Sep 23 02:42:51 2022 +0200

    random: clamp credited irq bits to maximum mixed
    
    commit e78a802a7b4febf53f2a92842f494b01062d85a8 upstream.
    
    Since the most that's mixed into the pool is sizeof(long)*2, don't
    credit more than that many bytes of entropy.
    
    Fixes: e3e33fc2ea7f ("random: do not use input pool from hard IRQs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a223145bd21536f80636d13d1fbfa97562225cc
Author: Hu Weiwen <sehuww@mail.scut.edu.cn>
Date:   Fri Jul 1 10:52:27 2022 +0800

    ceph: don't truncate file in atomic_open
    
    commit 7cb9994754f8a36ae9e5ec4597c5c4c2d6c03832 upstream.
    
    Clear O_TRUNC from the flags sent in the MDS create request.
    
    `atomic_open' is called before permission check. We should not do any
    modification to the file here. The caller will do the truncation
    afterward.
    
    Fixes: 124e68e74099 ("ceph: file operations")
    Signed-off-by: Hu Weiwen <sehuww@mail.scut.edu.cn>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    [Xiubo: fixed a trivial conflict for 4.9 backport]
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b63026b5e13040cd5afa11769dd0d9e1504b031a
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Thu Sep 29 21:33:30 2022 +0900

    nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failure
    
    commit 723ac751208f6d6540191689cfbf6c77135a7a1b upstream.
    
    If creation or finalization of a checkpoint fails due to anomalies in the
    checkpoint metadata on disk, a kernel warning is generated.
    
    This patch replaces the WARN_ONs by nilfs_error, so that a kernel, booted
    with panic_on_warn, does not panic.  A nilfs_error is appropriate here to
    handle the abnormal filesystem condition.
    
    This also replaces the detected error codes with an I/O error so that
    neither of the internal error codes is returned to callers.
    
    Link: https://lkml.kernel.org/r/20220929123330.19658-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+fbb3e0b24e8dae5a16ee@syzkaller.appspotmail.com
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81fe58e4e7f61a1f5200898e7cd4c9748f83051f
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Fri Oct 7 17:52:26 2022 +0900

    nilfs2: fix leak of nilfs_root in case of writer thread creation failure
    
    commit d0d51a97063db4704a5ef6bc978dddab1636a306 upstream.
    
    If nilfs_attach_log_writer() failed to create a log writer thread, it
    frees a data structure of the log writer without any cleanup.  After
    commit e912a5b66837 ("nilfs2: use root object to get ifile"), this causes
    a leak of struct nilfs_root, which started to leak an ifile metadata inode
    and a kobject on that struct.
    
    In addition, if the kernel is booted with panic_on_warn, the above
    ifile metadata inode leak will cause the following panic when the
    nilfs2 kernel module is removed:
    
      kmem_cache_destroy nilfs2_inode_cache: Slab cache still has objects when
      called from nilfs_destroy_cachep+0x16/0x3a [nilfs2]
      WARNING: CPU: 8 PID: 1464 at mm/slab_common.c:494 kmem_cache_destroy+0x138/0x140
      ...
      RIP: 0010:kmem_cache_destroy+0x138/0x140
      Code: 00 20 00 00 e8 a9 55 d8 ff e9 76 ff ff ff 48 8b 53 60 48 c7 c6 20 70 65 86 48 c7 c7 d8 69 9c 86 48 8b 4c 24 28 e8 ef 71 c7 00 <0f> 0b e9 53 ff ff ff c3 48 81 ff ff 0f 00 00 77 03 31 c0 c3 53 48
      ...
      Call Trace:
       <TASK>
       ? nilfs_palloc_freev.cold.24+0x58/0x58 [nilfs2]
       nilfs_destroy_cachep+0x16/0x3a [nilfs2]
       exit_nilfs_fs+0xa/0x1b [nilfs2]
        __x64_sys_delete_module+0x1d9/0x3a0
       ? __sanitizer_cov_trace_pc+0x1a/0x50
       ? syscall_trace_enter.isra.19+0x119/0x190
       do_syscall_64+0x34/0x80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
       ...
       </TASK>
      Kernel panic - not syncing: panic_on_warn set ...
    
    This patch fixes these issues by calling nilfs_detach_log_writer() cleanup
    function if spawning the log writer thread fails.
    
    Link: https://lkml.kernel.org/r/20221007085226.57667-1-konishi.ryusuke@gmail.com
    Fixes: e912a5b66837 ("nilfs2: use root object to get ifile")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+7381dc4ad60658ca4c05@syzkaller.appspotmail.com
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb63454b66f4a73d4b267fd5061aaf3a5657172c
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sun Oct 2 12:08:04 2022 +0900

    nilfs2: fix NULL pointer dereference at nilfs_bmap_lookup_at_level()
    
    commit 21a87d88c2253350e115029f14fe2a10a7e6c856 upstream.
    
    If the i_mode field in inode of metadata files is corrupted on disk, it
    can cause the initialization of bmap structure, which should have been
    called from nilfs_read_inode_common(), not to be called.  This causes a
    lockdep warning followed by a NULL pointer dereference at
    nilfs_bmap_lookup_at_level().
    
    This patch fixes these issues by adding a missing sanitiy check for the
    i_mode field of metadata file's inode.
    
    Link: https://lkml.kernel.org/r/20221002030804.29978-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+2b32eb36c1a825b7a74c@syzkaller.appspotmail.com
    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2e04e675d2809a3ee534d8510ee253121b3aa11
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Sep 13 16:53:12 2022 +0200

    USB: serial: ftdi_sio: fix 300 bps rate for SIO
    
    commit 7bd7ad3c310cd6766f170927381eea0aa6f46c69 upstream.
    
    The 300 bps rate of SIO devices has been mapped to 9600 bps since
    2003... Let's fix the regression.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b5ad3786a2f2cdbfed34071aa467f80e4903a0b
Author: Tadeusz Struk <tadeusz.struk@linaro.org>
Date:   Mon Sep 19 14:59:57 2022 -0700

    usb: mon: make mmapped memory read only
    
    commit a659daf63d16aa883be42f3f34ff84235c302198 upstream.
    
    Syzbot found an issue in usbmon module, where the user space client can
    corrupt the monitor's internal memory, causing the usbmon module to
    crash the kernel with segfault, UAF, etc.
    
    The reproducer mmaps the /dev/usbmon memory to user space, and
    overwrites it with arbitrary data, which causes all kinds of issues.
    
    Return an -EPERM error from mon_bin_mmap() if the flag VM_WRTIE is set.
    Also clear VM_MAYWRITE to make it impossible to change it to writable
    later.
    
    Cc: "Dmitry Vyukov" <dvyukov@google.com>
    Cc: stable <stable@kernel.org>
    Fixes: 6f23ee1fefdc ("USB: add binary API to usbmon")
    Suggested-by: PaX Team <pageexec@freemail.hu>   # for the VM_MAYRITE portion
    Link: https://syzkaller.appspot.com/bug?id=2eb1f35d6525fa4a74d75b4244971e5b1411c95a
    Reported-by: syzbot+23f57c5ae902429285d7@syzkaller.appspotmail.com
    Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
    Link: https://lore.kernel.org/r/20220919215957.205681-1-tadeusz.struk@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1214f7294523866c315fd50b4ae5ee37d509d8b2
Author: Lukas Straub <lukasstraub2@web.de>
Date:   Fri Aug 26 15:29:31 2022 +0000

    um: Cleanup compiler warning in arch/x86/um/tls_32.c
    
    [ Upstream commit d27fff3499671dc23a08efd01cdb8b3764a391c4 ]
    
    arch.tls_array is statically allocated so checking for NULL doesn't
    make sense. This causes the compiler warning below.
    
    Remove the checks to silence these warnings.
    
    ../arch/x86/um/tls_32.c: In function 'get_free_idx':
    ../arch/x86/um/tls_32.c:68:13: warning: the comparison will always evaluate as 'true' for the address of 'tls_array' will never be NULL [-Waddress]
       68 |         if (!t->arch.tls_array)
          |             ^
    In file included from ../arch/x86/um/asm/processor.h:10,
                     from ../include/linux/rcupdate.h:30,
                     from ../include/linux/rculist.h:11,
                     from ../include/linux/pid.h:5,
                     from ../include/linux/sched.h:14,
                     from ../arch/x86/um/tls_32.c:7:
    ../arch/x86/um/asm/processor_32.h:22:31: note: 'tls_array' declared here
       22 |         struct uml_tls_struct tls_array[GDT_ENTRY_TLS_ENTRIES];
          |                               ^~~~~~~~~
    ../arch/x86/um/tls_32.c: In function 'get_tls_entry':
    ../arch/x86/um/tls_32.c:243:13: warning: the comparison will always evaluate as 'true' for the address of 'tls_array' will never be NULL [-Waddress]
      243 |         if (!t->arch.tls_array)
          |             ^
    ../arch/x86/um/asm/processor_32.h:22:31: note: 'tls_array' declared here
       22 |         struct uml_tls_struct tls_array[GDT_ENTRY_TLS_ENTRIES];
          |                               ^~~~~~~~~
    
    Signed-off-by: Lukas Straub <lukasstraub2@web.de>
    Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ec019859f2383cf4c7198b8167810ea9c4ee37e
Author: Lukas Straub <lukasstraub2@web.de>
Date:   Fri Aug 26 15:29:27 2022 +0000

    um: Cleanup syscall_handler_t cast in syscalls_32.h
    
    [ Upstream commit 61670b4d270c71219def1fbc9441debc2ac2e6e9 ]
    
    Like in f4f03f299a56ce4d73c5431e0327b3b6cb55ebb9
    "um: Cleanup syscall_handler_t definition/cast, fix warning",
    remove the cast to to fix the compiler warning.
    
    Signed-off-by: Lukas Straub <lukasstraub2@web.de>
    Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4075717937c8ab692d6e35ecc100fffc528ac0c
Author: Haimin Zhang <tcs.kernel@gmail.com>
Date:   Thu Sep 8 20:19:27 2022 +0800

    net/ieee802154: fix uninit value bug in dgram_sendmsg
    
    [ Upstream commit 94160108a70c8af17fa1484a37e05181c0e094af ]
    
    There is uninit value bug in dgram_sendmsg function in
    net/ieee802154/socket.c when the length of valid data pointed by the
    msg->msg_name isn't verified.
    
    We introducing a helper function ieee802154_sockaddr_check_size to
    check namelen. First we check there is addr_type in ieee802154_addr_sa.
    Then, we check namelen according to addr_type.
    
    Also fixed in raw_bind, dgram_bind, dgram_connect.
    
    Signed-off-by: Haimin Zhang <tcs_kernel@tencent.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d9a46b9593573503485050f7b08d1afa3412dfb
Author: Sergei Antonov <saproj@gmail.com>
Date:   Wed Sep 7 20:53:41 2022 +0300

    ARM: dts: fix Moxa SDIO 'compatible', remove 'sdhci' misnomer
    
    [ Upstream commit 02181e68275d28cab3c3f755852770367f1bc229 ]
    
    Driver moxart-mmc.c has .compatible = "moxa,moxart-mmc".
    
    But moxart .dts/.dtsi and the documentation file moxa,moxart-dma.txt
    contain compatible = "moxa,moxart-sdhci".
    
    Change moxart .dts/.dtsi files and moxa,moxart-dma.txt to match the driver.
    
    Replace 'sdhci' with 'mmc' in names too, since SDHCI is a different
    controller from FTSDC010.
    
    Suggested-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sergei Antonov <saproj@gmail.com>
    Cc: Jonas Jensen <jonas.jensen@gmail.com>
    Link: https://lore.kernel.org/r/20220907175341.1477383-1-saproj@gmail.com'
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ebab37c5d46334fa749ef1d277bd9a56a0c710d
Author: Swati Agarwal <swati.agarwal@xilinx.com>
Date:   Wed Aug 17 11:41:25 2022 +0530

    dmaengine: xilinx_dma: Report error in case of dma_set_mask_and_coherent API failure
    
    [ Upstream commit 8f2b6bc79c32f0fa60df000ae387a790ec80eae9 ]
    
    The driver does not handle the failure case while calling
    dma_set_mask_and_coherent API.
    
    In case of failure, capture the return value of API and then report an
    error.
    
    Addresses-coverity: Unchecked return value (CHECKED_RETURN)
    
    Signed-off-by: Swati Agarwal <swati.agarwal@xilinx.com>
    Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
    Link: https://lore.kernel.org/r/20220817061125.4720-4-swati.agarwal@xilinx.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8e89f033b0ba0a2d934debc3c71d92d02ac7601
Author: Swati Agarwal <swati.agarwal@xilinx.com>
Date:   Wed Aug 17 11:41:24 2022 +0530

    dmaengine: xilinx_dma: cleanup for fetching xlnx,num-fstores property
    
    [ Upstream commit 462bce790e6a7e68620a4ce260cc38f7ed0255d5 ]
    
    Free the allocated resources for missing xlnx,num-fstores property.
    
    Signed-off-by: Swati Agarwal <swati.agarwal@xilinx.com>
    Link: https://lore.kernel.org/r/20220817061125.4720-3-swati.agarwal@xilinx.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1ff475d7c83289d0a7faef346ea3bbf90818bad
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Tue Aug 16 12:08:58 2022 +0800

    fs: fix UAF/GPF bug in nilfs_mdt_destroy
    
    commit 2e488f13755ffbb60f307e991b27024716a33b29 upstream.
    
    In alloc_inode, inode_init_always() could return -ENOMEM if
    security_inode_alloc() fails, which causes inode->i_private
    uninitialized. Then nilfs_is_metadata_file_inode() returns
    true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(),
    which frees the uninitialized inode->i_private
    and leads to crashes(e.g., UAF/GPF).
    
    Fix this by moving security_inode_alloc just prior to
    this_cpu_inc(nr_inodes)
    
    Link: https://lkml.kernel.org/r/CAFcO6XOcf1Jj2SeGt=jJV59wmhESeSKpfR0omdFRq+J9nD1vfQ@mail.gmail.com
    Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
    Reported-by: Hao Sun <sunhao.th@gmail.com>
    Reported-by: Jiacheng Xu <stitch@zju.edu.cn>
    Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: stable@vger.kernel.org
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0393727901ed19111fa82e691f99b484c5e3793
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Tue Apr 23 17:09:38 2019 +0100

    ARM: fix function graph tracer and unwinder dependencies
    
    commit 503621628b32782a07b2318e4112bd4372aa3401 upstream.
    
    Naresh Kamboju recently reported that the function-graph tracer crashes
    on ARM. The function-graph tracer assumes that the kernel is built with
    frame pointers.
    
    We explicitly disabled the function-graph tracer when building Thumb2,
    since the Thumb2 ABI doesn't have frame pointers.
    
    We recently changed the way the unwinder method was selected, which
    seems to have made it more likely that we can end up with the function-
    graph tracer enabled but without the kernel built with frame pointers.
    
    Fix up the function graph tracer dependencies so the option is not
    available when we have no possibility of having frame pointers, and
    adjust the dependencies on the unwinder option to hide the non-frame
    pointer unwinder options if the function-graph tracer is enabled.
    
    Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reported-by: Danilo Cezar Zanella <danilo.zanella@iag.usp.br>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 158346d3dc3b189be46f41e298ebf82a0ca2c4ee
Author: Sami Tolvanen <samitolvanen@google.com>
Date:   Fri Sep 30 20:33:10 2022 +0000

    Makefile.extrawarn: Move -Wcast-function-type-strict to W=1
    
    commit 2120635108b35ecad9c59c8b44f6cbdf4f98214e upstream.
    
    We enable -Wcast-function-type globally in the kernel to warn about
    mismatching types in function pointer casts. Compilers currently
    warn only about ABI incompability with this flag, but Clang 16 will
    enable a stricter version of the check by default that checks for an
    exact type match. This will be very noisy in the kernel, so disable
    -Wcast-function-type-strict without W=1 until the new warnings have
    been addressed.
    
    Cc: stable@vger.kernel.org
    Link: https://reviews.llvm.org/D134831
    Link: https://github.com/ClangBuiltLinux/linux/issues/1724
    Suggested-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20220930203310.4010564-1-samitolvanen@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27c2c6d3512fd82b7eb5c36cb5343169ac5b04ad
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Mon Sep 5 09:15:03 2022 -0700

    clk: iproc: Do not rely on node name for correct PLL setup
    
    [ Upstream commit 1b24a132eba7a1c19475ba2510ec1c00af3ff914 ]
    
    After commit 31fd9b79dc58 ("ARM: dts: BCM5301X: update CRU block
    description") a warning from clk-iproc-pll.c was generated due to a
    duplicate PLL name as well as the console stopped working. Upon closer
    inspection it became clear that iproc_pll_clk_setup() used the Device
    Tree node unit name as an unique identifier as well as a parent name to
    parent all clocks under the PLL.
    
    BCM5301X was the first platform on which that got noticed because of the
    DT node unit name renaming but the same assumptions hold true for any
    user of the iproc_pll_clk_setup() function.
    
    The first 'clock-output-names' property is always guaranteed to be
    unique as well as providing the actual desired PLL clock name, so we
    utilize that to register the PLL and as a parent name of all children
    clock.
    
    Fixes: 5fe225c105fd ("clk: iproc: add initial common clock support")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Acked-by: Rafał Miłecki <rafal@milecki.pl>
    Link: https://lore.kernel.org/r/20220905161504.1526-1-f.fainelli@gmail.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d1e20818ed53549f63be90daa3645c0eb2243e3
Author: Lori Hikichi <lhikichi@broadcom.com>
Date:   Mon Aug 14 12:00:41 2017 -0700

    clk: iproc: Minor tidy up of iproc pll data structures
    
    [ Upstream commit b33db49783763e1b2a63b12fbe0e91fb7147a987 ]
    
    There were a few fields in the iproc pll data structures that were
    holding information that was not true state information.
    Using stack variables is sufficient and simplifies the structure.
    There are not any functional changes in this commit.
    
    Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Stable-dep-of: 1b24a132eba7 ("clk: iproc: Do not rely on node name for correct PLL setup")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b67ed299146e810a848ea80158327f90b5c1772
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Fri Sep 23 15:02:37 2022 +0800

    selftests: Fix the if conditions of in test_extra_filter()
    
    [ Upstream commit bc7a319844891746135dc1f34ab9df78d636a3ac ]
    
    The socket 2 bind the addr in use, bind should fail with EADDRINUSE. So
    if bind success or errno != EADDRINUSE, testcase should be failed.
    
    Fixes: 3ca8e4029969 ("soreuseport: BPF selection functional test")
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Link: https://lore.kernel.org/r/1663916557-10730-1-git-send-email-wangyufen@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1463575044abc50619107e69762fdf24aeb4087d
Author: Michael Kelley <mikelley@microsoft.com>
Date:   Thu Sep 22 21:49:09 2022 -0700

    nvme: Fix IOC_PR_CLEAR and IOC_PR_RELEASE ioctls for nvme devices
    
    [ Upstream commit c292a337d0e45a292c301e3cd51c35aa0ae91e95 ]
    
    The IOC_PR_CLEAR and IOC_PR_RELEASE ioctls are
    non-functional on NVMe devices because the nvme_pr_clear()
    and nvme_pr_release() functions set the IEKEY field incorrectly.
    The IEKEY field should be set only when the key is zero (i.e,
    not specified).  The current code does it backwards.
    
    Furthermore, the NVMe spec describes the persistent
    reservation "clear" function as an option on the reservation
    release command. The current implementation of nvme_pr_clear()
    erroneously uses the reservation register command.
    
    Fix these errors. Note that NVMe version 1.3 and later specify
    that setting the IEKEY field will return an error of Invalid
    Field in Command.  The fix will set IEKEY when the key is zero,
    which is appropriate as these ioctls consider a zero key to
    be "unspecified", and the intention of the spec change is
    to require a valid key.
    
    Tested on a version 1.4 PCI NVMe device in an Azure VM.
    
    Fixes: 1673f1f08c88 ("nvme: move block_device_operations and ns/ctrl freeing to common code")
    Fixes: 1d277a637a71 ("NVMe: Add persistent reservation ops")
    Signed-off-by: Michael Kelley <mikelley@microsoft.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d1e103c6d817c324e0cbca81ed245821a132b87
Author: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Date:   Sun Feb 28 18:06:11 2021 -0800

    nvme: add new line after variable declatation
    
    [ Upstream commit f1c772d581843e3a14bbd62ef7e40b56fc307f27 ]
    
    Add a new line in functions nvme_pr_preempt(), nvme_pr_clear(), and
    nvme_pr_release() after variable declaration which follows the rest of
    the code in the nvme/host/core.c.
    
    No functional change(s) in this patch.
    
    Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Stable-dep-of: c292a337d0e4 ("nvme: Fix IOC_PR_CLEAR and IOC_PR_RELEASE ioctls for nvme devices")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 08e3d353b7c284126247a5329d4437778738d730
Author: Peilin Ye <peilin.ye@bytedance.com>
Date:   Thu Sep 22 21:25:51 2022 -0700

    usbnet: Fix memory leak in usbnet_disconnect()
    
    [ Upstream commit a43206156263fbaf1f2b7f96257441f331e91bb7 ]
    
    Currently usbnet_disconnect() unanchors and frees all deferred URBs
    using usb_scuttle_anchored_urbs(), which does not free urb->context,
    causing a memory leak as reported by syzbot.
    
    Use a usb_get_from_anchor() while loop instead, similar to what we did
    in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in
    play_deferred").  Also free urb->sg.
    
    Reported-and-tested-by: syzbot+dcd3e13cf4472f2e0ba1@syzkaller.appspotmail.com
    Fixes: 69ee472f2706 ("usbnet & cdc-ether: Autosuspend for online devices")
    Fixes: 638c5115a794 ("USBNET: support DMA SG")
    Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
    Link: https://lore.kernel.org/r/20220923042551.2745-1-yepeilin.cs@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ff53a9234c0a84befacf01ac39e59db69ef7aa7b
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Sat Sep 24 11:07:15 2022 +0800

    Input: melfas_mip4 - fix return value check in mip4_probe()
    
    [ Upstream commit a54dc27bd25f20ee3ea2009584b3166d25178243 ]
    
    devm_gpiod_get_optional() may return ERR_PTR(-EPROBE_DEFER),
    add a minus sign to fix it.
    
    Fixes: 6ccb1d8f78bd ("Input: add MELFAS MIP4 Touchscreen driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20220924030715.1653538-1-yangyingliang@huawei.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06f80dd61a1d8aeb194a2e3368daf84a21ad1131
Author: Brian Norris <briannorris@chromium.org>
Date:   Mon Aug 22 18:08:04 2022 -0700

    Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time"
    
    [ Upstream commit cc62d98bd56d45de4531844ca23913a15136c05b ]
    
    This reverts commit 211f276ed3d96e964d2d1106a198c7f4a4b3f4c0.
    
    For quite some time, core DRM helpers already ensure that any relevant
    connectors/CRTCs/etc. are disabled, as well as their associated
    components (e.g., bridges) when suspending the system. Thus,
    analogix_dp_bridge_{enable,disable}() already get called, which in turn
    call drm_panel_{prepare,unprepare}(). This makes these drm_panel_*()
    calls redundant.
    
    Besides redundancy, there are a few problems with this handling:
    
    (1) drm_panel_{prepare,unprepare}() are *not* reference-counted APIs and
    are not in general designed to be handled by multiple callers --
    although some panel drivers have a coarse 'prepared' flag that mitigates
    some damage, at least. So at a minimum this is redundant and confusing,
    but in some cases, this could be actively harmful.
    
    (2) The error-handling is a bit non-standard. We ignored errors in
    suspend(), but handled errors in resume(). And recently, people noticed
    that the clk handling is unbalanced in error paths, and getting *that*
    right is not actually trivial, given the current way errors are mostly
    ignored.
    
    (3) In the particular way analogix_dp_{suspend,resume}() get used (e.g.,
    in rockchip_dp_*(), as a late/early callback), we don't necessarily have
    a proper PM relationship between the DP/bridge device and the panel
    device. So while the DP bridge gets resumed, the panel's parent device
    (e.g., platform_device) may still be suspended, and so any prepare()
    calls may fail.
    
    So remove the superfluous, possibly-harmful suspend()/resume() handling
    of panel state.
    
    Fixes: 211f276ed3d9 ("drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time")
    Link: https://lore.kernel.org/all/Yv2CPBD3Picg%2FgVe@google.com/
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220822180729.1.I8ac5abe3a4c1c6fd5c061686c6e883c22f69022c@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fe16be4cecd335745beee1c79aa937c097c71466
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Fri Jul 15 14:50:13 2022 +0200

    mm: prevent page_frag_alloc() from corrupting the memory
    
    commit dac22531bbd4af2426c4e29e05594415ccfa365d upstream.
    
    A number of drivers call page_frag_alloc() with a fragment's size >
    PAGE_SIZE.
    
    In low memory conditions, __page_frag_cache_refill() may fail the order
    3 cache allocation and fall back to order 0; In this case, the cache
    will be smaller than the fragment, causing memory corruptions.
    
    Prevent this from happening by checking if the newly allocated cache is
    large enough for the fragment; if not, the allocation will fail and
    page_frag_alloc() will return NULL.
    
    Link: https://lkml.kernel.org/r/20220715125013.247085-1-mlombard@redhat.com
    Fixes: b63ae8ca096d ("mm/net: Rename and move page fragment handling from net/ to mm/")
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Cc: Chen Lin <chen45464546@163.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ec35f52c341bc594868dc8ed732a2f80365487e
Author: Sergei Antonov <saproj@gmail.com>
Date:   Wed Sep 7 23:57:53 2022 +0300

    mmc: moxart: fix 4-bit bus width and remove 8-bit bus width
    
    commit 35ca91d1338ae158f6dcc0de5d1e86197924ffda upstream.
    
    According to the datasheet [1] at page 377, 4-bit bus width is turned on by
    bit 2 of the Bus Width Register. Thus the current bitmask is wrong: define
    BUS_WIDTH_4 BIT(1)
    
    BIT(1) does not work but BIT(2) works. This has been verified on real MOXA
    hardware with FTSDC010 controller revision 1_6_0.
    
    The corrected value of BUS_WIDTH_4 mask collides with: define BUS_WIDTH_8
    BIT(2). Additionally, 8-bit bus width mode isn't supported according to the
    datasheet, so let's remove the corresponding code.
    
    [1]
    https://bitbucket.org/Kasreyn/mkrom-uc7112lx/src/master/documents/FIC8120_DS_v1.2.pdf
    
    Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver")
    Signed-off-by: Sergei Antonov <saproj@gmail.com>
    Cc: Jonas Jensen <jonas.jensen@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20220907205753.1577434-1-saproj@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ddce74782f1b2fc6cc5d47db4d1edd04cf6a019
Author: ChenXiaoSong <chenxiaosong2@huawei.com>
Date:   Tue Aug 9 14:47:30 2022 +0800

    ntfs: fix BUG_ON in ntfs_lookup_inode_by_name()
    
    commit 1b513f613731e2afc05550e8070d79fac80c661e upstream.
    
    Syzkaller reported BUG_ON as follows:
    
    ------------[ cut here ]------------
    kernel BUG at fs/ntfs/dir.c:86!
    invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
    CPU: 3 PID: 758 Comm: a.out Not tainted 5.19.0-next-20220808 #5
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:ntfs_lookup_inode_by_name+0xd11/0x2d10
    Code: ff e9 b9 01 00 00 e8 1e fe d6 fe 48 8b 7d 98 49 8d 5d 07 e8 91 85 29 ff 48 c7 45 98 00 00 00 00 e9 5a fb ff ff e8 ff fd d6 fe <0f> 0b e8 f8 fd d6 fe 0f 0b e8 f1 fd d6 fe 48 8b b5 50 ff ff ff 4c
    RSP: 0018:ffff888079607978 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: 0000000000008000 RCX: 0000000000000000
    RDX: ffff88807cf10000 RSI: ffffffff82a4a081 RDI: 0000000000000003
    RBP: ffff888079607a70 R08: 0000000000000001 R09: ffff88807a6d01d7
    R10: ffffed100f4da03a R11: 0000000000000000 R12: ffff88800f0fb110
    R13: ffff88800f0ee000 R14: ffff88800f0fb000 R15: 0000000000000001
    FS:  00007f33b63c7540(0000) GS:ffff888108580000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f33b635c090 CR3: 000000000f39e005 CR4: 0000000000770ee0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     load_system_files+0x1f7f/0x3620
     ntfs_fill_super+0xa01/0x1be0
     mount_bdev+0x36a/0x440
     ntfs_mount+0x3a/0x50
     legacy_get_tree+0xfb/0x210
     vfs_get_tree+0x8f/0x2f0
     do_new_mount+0x30a/0x760
     path_mount+0x4de/0x1880
     __x64_sys_mount+0x2b3/0x340
     do_syscall_64+0x38/0x90
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7f33b62ff9ea
    Code: 48 8b 0d a9 f4 0b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 76 f4 0b 00 f7 d8 64 89 01 48
    RSP: 002b:00007ffd0c471aa8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f33b62ff9ea
    RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd0c471be0
    RBP: 00007ffd0c471c60 R08: 00007ffd0c471ae0 R09: 00007ffd0c471c24
    R10: 0000000000000000 R11: 0000000000000202 R12: 000055bac5afc160
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
     </TASK>
    Modules linked in:
    ---[ end trace 0000000000000000 ]---
    
    Fix this by adding sanity check on extended system files' directory inode
    to ensure that it is directory, just like ntfs_extend_init() when mounting
    ntfs3.
    
    Link: https://lkml.kernel.org/r/20220809064730.2316892-1-chenxiaosong2@huawei.com
    Signed-off-by: ChenXiaoSong <chenxiaosong2@huawei.com>
    Cc: Anton Altaparmakov <anton@tuxera.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0016ac290134520d84788adde65ae245e4a16ba7
Author: Frank Wunderlich <frank-w@public-files.de>
Date:   Mon Sep 26 17:07:40 2022 +0200

    net: usb: qmi_wwan: Add new usb-id for Dell branded EM7455
    
    commit 797666cd5af041ffb66642fff62f7389f08566a2 upstream.
    
    Add support for Dell 5811e (EM7455) with USB-id 0x413c:0x81c2.
    
    Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
    Cc: stable@vger.kernel.org
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Link: https://lore.kernel.org/r/20220926150740.6684-3-linux@fw-web.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a9c27b7acf9c402778f430ccca5e424ff8988522
Author: Hongling Zeng <zenghongling@kylinos.cn>
Date:   Fri Sep 23 10:46:35 2022 +0800

    uas: ignore UAS for Thinkplus chips
    
    commit 0fb9703a3eade0bb84c635705d9c795345e55053 upstream.
    
    The UAS mode of Thinkplus(0x17ef, 0x3899) is reported to influence
    performance and trigger kernel panic on several platforms with the
    following error message:
    
    [   39.702439] xhci_hcd 0000:0c:00.3: ERROR Transfer event for disabled
                   endpoint or incorrect stream ring
    [   39.702442] xhci_hcd 0000:0c:00.3: @000000026c61f810 00000000 00000000
                   1b000000 05038000
    
    [  720.545894][13] Workqueue: usb_hub_wq hub_event
    [  720.550971][13]  ffff88026c143c38 0000000000016300 ffff8802755bb900 ffff880
                        26cb80000
    [  720.559673][13]  ffff88026c144000 ffff88026ca88100 0000000000000000 ffff880
                        26cb80000
    [  720.568374][13]  ffff88026cb80000 ffff88026c143c50 ffffffff8186ae25 ffff880
                        26ca880f8
    [  720.577076][13] Call Trace:
    [  720.580201][13]  [<ffffffff8186ae25>] schedule+0x35/0x80
    [  720.586137][13]  [<ffffffff8186b0ce>] schedule_preempt_disabled+0xe/0x10
    [  720.593623][13]  [<ffffffff8186cb94>] __mutex_lock_slowpath+0x164/0x1e0
    [  720.601012][13]  [<ffffffff8186cc3f>] mutex_lock+0x2f/0x40
    [  720.607141][13]  [<ffffffff8162b8e9>] usb_disconnect+0x59/0x290
    
    Falling back to USB mass storage can solve this problem, so ignore UAS
    function of this chip.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
    Link: https://lore.kernel.org/r/1663902249837086.19.seg@mailgw
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d661b5353caddfe7a4952d44a9aba70c43b1554f
Author: Hongling Zeng <zenghongling@kylinos.cn>
Date:   Fri Sep 23 10:46:25 2022 +0800

    usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS
    
    commit e00b488e813f0f1ad9f778e771b7cd2fe2877023 upstream.
    
    The UAS mode of Hiksemi USB_HDD is reported to fail to work on several
    platforms with the following error message, then after re-connecting the
    device will be offlined and not working at all.
    
    [  592.518442][ 2] sd 8:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 18
                       inflight: CMD
    [  592.527575][ 2] sd 8:0:0:0: [sda] tag#17 CDB: Write(10) 2a 00 03 6f 88 00 00
                       04 00 00
    [  592.536330][ 2] sd 8:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1
                       inflight: CMD
    [  592.545266][ 2] sd 8:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 07 44 1a 88 00
                       00 08 00
    
    These disks have a broken uas implementation, the tag field of the status
    iu-s is not set properly,so we need to fall-back to usb-storage.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
    Link: https://lore.kernel.org/r/1663901185-21067-1-git-send-email-zenghongling@kylinos.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46e791e18c5469e1bb0dc9607961aa5c9bb96147
Author: Hongling Zeng <zenghongling@kylinos.cn>
Date:   Fri Sep 23 10:46:13 2022 +0800

    uas: add no-uas quirk for Hiksemi usb_disk
    
    commit a625a4b8806cc1e928b7dd2cca1fee709c9de56e upstream.
    
    The UAS mode of Hiksemi is reported to fail to work on several platforms
    with the following error message, then after re-connecting the device will
    be offlined and not working at all.
    
    [  592.518442][ 2] sd 8:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 18
                       inflight: CMD
    [  592.527575][ 2] sd 8:0:0:0: [sda] tag#17 CDB: Write(10) 2a 00 03 6f 88 00 00
                       04 00 00
    [  592.536330][ 2] sd 8:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1
                       inflight: CMD
    [  592.545266][ 2] sd 8:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 07 44 1a 88 00
                       00 08 00
    
    These disks have a broken uas implementation, the tag field of the status
    iu-s is not set properly,so we need to fall-back to usb-storage.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@kernel.org>
    Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
    Link: https://lore.kernel.org/r/1663901173-21020-1-git-send-email-zenghongling@kylinos.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>