commit a3eb3a74aa8c94e6c8130b55f3b031f29162868c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Mar 1 13:26:39 2024 +0100

    Linux 6.1.80
    
    Link: https://lore.kernel.org/r/20240227131610.391465389@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Yann Sionneau <ysionneau@kalrayinc.com>
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 277439e7cabd9d4c6334b39a4b99d49b4c97265b
Author: Edward Lo <edward.lo@ambergroup.io>
Date:   Thu Oct 27 23:33:37 2022 +0800

    fs/ntfs3: Enhance the attribute size check
    
    commit 4f082a7531223a438c757bb20e304f4c941c67a8 upstream.
    
    This combines the overflow and boundary check so that all attribute size
    will be properly examined while enumerating them.
    
    [  169.181521] BUG: KASAN: slab-out-of-bounds in run_unpack+0x2e3/0x570
    [  169.183161] Read of size 1 at addr ffff8880094b6240 by task mount/247
    [  169.184046]
    [  169.184925] CPU: 0 PID: 247 Comm: mount Not tainted 6.0.0-rc7+ #3
    [  169.185908] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
    [  169.187066] Call Trace:
    [  169.187492]  <TASK>
    [  169.188049]  dump_stack_lvl+0x49/0x63
    [  169.188495]  print_report.cold+0xf5/0x689
    [  169.188964]  ? run_unpack+0x2e3/0x570
    [  169.189331]  kasan_report+0xa7/0x130
    [  169.189714]  ? run_unpack+0x2e3/0x570
    [  169.190079]  __asan_load1+0x51/0x60
    [  169.190634]  run_unpack+0x2e3/0x570
    [  169.191290]  ? run_pack+0x840/0x840
    [  169.191569]  ? run_lookup_entry+0xb3/0x1f0
    [  169.192443]  ? mi_enum_attr+0x20a/0x230
    [  169.192886]  run_unpack_ex+0xad/0x3e0
    [  169.193276]  ? run_unpack+0x570/0x570
    [  169.193557]  ? ni_load_mi+0x80/0x80
    [  169.193889]  ? debug_smp_processor_id+0x17/0x20
    [  169.194236]  ? mi_init+0x4a/0x70
    [  169.194496]  attr_load_runs_vcn+0x166/0x1c0
    [  169.194851]  ? attr_data_write_resident+0x250/0x250
    [  169.195188]  mi_read+0x133/0x2c0
    [  169.195481]  ntfs_iget5+0x277/0x1780
    [  169.196017]  ? call_rcu+0x1c7/0x330
    [  169.196392]  ? ntfs_get_block_bmap+0x70/0x70
    [  169.196708]  ? evict+0x223/0x280
    [  169.197014]  ? __kmalloc+0x33/0x540
    [  169.197305]  ? wnd_init+0x15b/0x1b0
    [  169.197599]  ntfs_fill_super+0x1026/0x1ba0
    [  169.197994]  ? put_ntfs+0x1d0/0x1d0
    [  169.198299]  ? vsprintf+0x20/0x20
    [  169.198583]  ? mutex_unlock+0x81/0xd0
    [  169.198930]  ? set_blocksize+0x95/0x150
    [  169.199269]  get_tree_bdev+0x232/0x370
    [  169.199750]  ? put_ntfs+0x1d0/0x1d0
    [  169.200094]  ntfs_fs_get_tree+0x15/0x20
    [  169.200431]  vfs_get_tree+0x4c/0x130
    [  169.200714]  path_mount+0x654/0xfe0
    [  169.201067]  ? putname+0x80/0xa0
    [  169.201358]  ? finish_automount+0x2e0/0x2e0
    [  169.201965]  ? putname+0x80/0xa0
    [  169.202445]  ? kmem_cache_free+0x1c4/0x440
    [  169.203075]  ? putname+0x80/0xa0
    [  169.203414]  do_mount+0xd6/0xf0
    [  169.203719]  ? path_mount+0xfe0/0xfe0
    [  169.203977]  ? __kasan_check_write+0x14/0x20
    [  169.204382]  __x64_sys_mount+0xca/0x110
    [  169.204711]  do_syscall_64+0x3b/0x90
    [  169.205059]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
    [  169.205571] RIP: 0033:0x7f67a80e948a
    [  169.206327] Code: 48 8b 0d 11 fa 2a 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 008
    [  169.208296] RSP: 002b:00007ffddf020f58 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
    [  169.209253] RAX: ffffffffffffffda RBX: 000055e2547a6060 RCX: 00007f67a80e948a
    [  169.209777] RDX: 000055e2547a6260 RSI: 000055e2547a62e0 RDI: 000055e2547aeaf0
    [  169.210342] RBP: 0000000000000000 R08: 000055e2547a6280 R09: 0000000000000020
    [  169.210843] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 000055e2547aeaf0
    [  169.211307] R13: 000055e2547a6260 R14: 0000000000000000 R15: 00000000ffffffff
    [  169.211913]  </TASK>
    [  169.212304]
    [  169.212680] Allocated by task 0:
    [  169.212963] (stack is not available)
    [  169.213200]
    [  169.213472] The buggy address belongs to the object at ffff8880094b5e00
    [  169.213472]  which belongs to the cache UDP of size 1152
    [  169.214095] The buggy address is located 1088 bytes inside of
    [  169.214095]  1152-byte region [ffff8880094b5e00, ffff8880094b6280)
    [  169.214639]
    [  169.215004] The buggy address belongs to the physical page:
    [  169.215766] page:000000002e324c8c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x94b4
    [  169.218412] head:000000002e324c8c order:2 compound_mapcount:0 compound_pincount:0
    [  169.219078] flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
    [  169.220272] raw: 000fffffc0010200 0000000000000000 dead000000000122 ffff888002409b40
    [  169.221006] raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
    [  169.222320] page dumped because: kasan: bad access detected
    [  169.222922]
    [  169.223119] Memory state around the buggy address:
    [  169.224056]  ffff8880094b6100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [  169.224908]  ffff8880094b6180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [  169.225677] >ffff8880094b6200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [  169.226445]                                            ^
    [  169.227055]  ffff8880094b6280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [  169.227638]  ffff8880094b6300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    Signed-off-by: Edward Lo <edward.lo@ambergroup.io>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Cc: "Doebel, Bjoern" <doebel@amazon.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f119f2325ba70cbfdec701000dcad4d88805d5b0
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu Feb 15 15:05:16 2024 -0800

    arp: Prevent overflow in arp_req_get().
    
    commit a7d6027790acea24446ddd6632d394096c0f4667 upstream.
    
    syzkaller reported an overflown write in arp_req_get(). [0]
    
    When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
    entry and copies neigh->ha to struct arpreq.arp_ha.sa_data.
    
    The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
    the sa_data buffer is just 14 bytes.
    
    In the splat below, 2 bytes are overflown to the next int field,
    arp_flags.  We initialise the field just after the memcpy(), so it's
    not a problem.
    
    However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
    arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
    in arp_ioctl() before calling arp_req_get().
    
    To avoid the overflow, let's limit the max length of memcpy().
    
    Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
    array in struct sockaddr") just silenced syzkaller.
    
    [0]:
    memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
    WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
    Modules linked in:
    CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
    RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
    Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
    RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
    RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
    RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
    R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
    FS:  00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
     inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
     sock_do_ioctl+0xdf/0x260 net/socket.c:1204
     sock_ioctl+0x3ef/0x650 net/socket.c:1321
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:870 [inline]
     __se_sys_ioctl fs/ioctl.c:856 [inline]
     __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
     entry_SYSCALL_64_after_hwframe+0x64/0xce
    RIP: 0033:0x7f172b262b8d
    Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
    RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
    RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
     </TASK>
    
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Reported-by: Bjoern Doebel <doebel@amazon.de>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240215230516.31330-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8fc1f1d9f65b89e7b90ffea5dfd58d427e48017
Author: Lennert Buytenhek <kernel@wantstofly.org>
Date:   Tue Jan 30 15:21:51 2024 +0200

    ahci: Extend ASM1061 43-bit DMA address quirk to other ASM106x parts
    
    commit 51af8f255bdaca6d501afc0d085b808f67b44d91 upstream.
    
    ASMedia have confirmed that all ASM106x parts currently listed in
    ahci_pci_tbl[] suffer from the 43-bit DMA address limitation that we ran
    into on the ASM1061, and therefore, we need to apply the quirk added by
    commit 20730e9b2778 ("ahci: add 43-bit DMA address quirk for ASMedia
    ASM1061 controllers") to the other supported ASM106x parts as well.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/linux-ide/ZbopwKZJAKQRA4Xv@x1-carbon/
    Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
    [cassel: add link to ASMedia confirmation email]
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a37c6c068345ca2e4001e47555f5031872361d2
Author: Szuying Chen <chensiying21@gmail.com>
Date:   Thu Sep 21 17:33:51 2023 +0800

    ata: ahci: add identifiers for ASM2116 series adapters
    
    commit 3bf6141060948e27b62b13beb216887f2e54591e upstream.
    
    Add support for PCIe SATA adapter cards based on Asmedia 2116 controllers.
    These cards can provide up to 10 SATA ports on PCIe card.
    
    Signed-off-by: Szuying Chen <Chloe_Chen@asmedia.com.tw>
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70a4a26572013738ee9b4d0e18487ef22f97be7c
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Thu Feb 15 19:25:29 2024 +0100

    mptcp: add needs_id for netlink appending addr
    
    commit 584f3894262634596532cf43a5e782e34a0ce374 upstream.
    
    Just the same as userspace PM, a new parameter needs_id is added for
    in-kernel PM mptcp_pm_nl_append_new_local_addr() too.
    
    Add a new helper mptcp_pm_has_addr_attr_id() to check whether an address
    ID is set from PM or not.
    
    In mptcp_pm_nl_get_local_id(), needs_id is always true, but in
    mptcp_pm_nl_add_addr_doit(), pass mptcp_pm_has_addr_attr_id() to
    needs_it.
    
    Fixes: efd5a4c04e18 ("mptcp: add the address ID assignment bitmap")
    Cc: stable@vger.kernel.org
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b03bca85617b95965a1af5722e452775a1ab8f32
Author: Geliang Tang <geliang@kernel.org>
Date:   Wed Oct 25 16:37:04 2023 -0700

    mptcp: userspace pm send RM_ADDR for ID 0
    
    commit 84c531f54ad9a124a924c9505d74e33d16965146 upstream.
    
    This patch adds the ability to send RM_ADDR for local ID 0. Check
    whether id 0 address is removed, if not, put id 0 into a removing
    list, pass it to mptcp_pm_remove_addr() to remove id 0 address.
    
    There is no reason not to allow the userspace to remove the initial
    address (ID 0). This special case was not taken into account not
    letting the userspace to delete all addresses as announced.
    
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/379
    Reviewed-by: Matthieu Baerts <matttbe@kernel.org>
    Signed-off-by: Geliang Tang <geliang.tang@suse.com>
    Signed-off-by: Mat Martineau <martineau@kernel.org>
    Link: https://lore.kernel.org/r/20231025-send-net-next-20231025-v1-3-db8f25f798eb@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Fixes: d9a4594edabf ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14f1992430ef9e647b02aa8ca12c5bcb9a1dffea
Author: Yosry Ahmed <yosryahmed@google.com>
Date:   Thu Jan 25 08:51:27 2024 +0000

    mm: zswap: fix missing folio cleanup in writeback race path
    
    commit e3b63e966cac0bf78aaa1efede1827a252815a1d upstream.
    
    In zswap_writeback_entry(), after we get a folio from
    __read_swap_cache_async(), we grab the tree lock again to check that the
    swap entry was not invalidated and recycled.  If it was, we delete the
    folio we just added to the swap cache and exit.
    
    However, __read_swap_cache_async() returns the folio locked when it is
    newly allocated, which is always true for this path, and the folio is
    ref'd.  Make sure to unlock and put the folio before returning.
    
    This was discovered by code inspection, probably because this path handles
    a race condition that should not happen often, and the bug would not crash
    the system, it will only strand the folio indefinitely.
    
    Link: https://lkml.kernel.org/r/20240125085127.1327013-1-yosryahmed@google.com
    Fixes: 04fc7816089c ("mm: fix zswap writeback race condition")
    Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
    Reviewed-by: Chengming Zhou <zhouchengming@bytedance.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Nhat Pham <nphamcs@gmail.com>
    Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18f614369def2a11a52f569fe0f910b199d13487
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Feb 15 12:47:38 2024 -0800

    fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio
    
    commit b820de741ae48ccf50dd95e297889c286ff4f760 upstream.
    
    If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
    following kernel warning appears:
    
    WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
    Call trace:
     kiocb_set_cancel_fn+0x9c/0xa8
     ffs_epfile_read_iter+0x144/0x1d0
     io_read+0x19c/0x498
     io_issue_sqe+0x118/0x27c
     io_submit_sqes+0x25c/0x5fc
     __arm64_sys_io_uring_enter+0x104/0xab0
     invoke_syscall+0x58/0x11c
     el0_svc_common+0xb4/0xf4
     do_el0_svc+0x2c/0xb0
     el0_svc+0x2c/0xa4
     el0t_64_sync_handler+0x68/0xb4
     el0t_64_sync+0x1a4/0x1a8
    
    Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
    submitted by libaio.
    
    Suggested-by: Jens Axboe <axboe@kernel.dk>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Avi Kivity <avi@scylladb.com>
    Cc: Sandeep Dhavale <dhavale@google.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Kent Overstreet <kent.overstreet@linux.dev>
    Cc: stable@vger.kernel.org
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20240215204739.2677806-2-bvanassche@acm.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ebeee513f8f2abdfe98632afdba0b8ebe44339b
Author: SeongJae Park <sj@kernel.org>
Date:   Fri Feb 16 11:40:24 2024 -0800

    mm/damon/reclaim: fix quota stauts loss due to online tunings
    
    commit 1b0ca4e4ff10a2c8402e2cf70132c683e1c772e4 upstream.
    
    Patch series "mm/damon: fix quota status loss due to online tunings".
    
    DAMON_RECLAIM and DAMON_LRU_SORT is not preserving internal quota status
    when applying new user parameters, and hence could cause temporal quota
    accuracy degradation.  Fix it by preserving the status.
    
    
    This patch (of 2):
    
    For online parameters change, DAMON_RECLAIM creates new scheme based on
    latest values of the parameters and replaces the old scheme with the new
    one.  When creating it, the internal status of the quota of the old
    scheme is not preserved.  As a result, charging of the quota starts from
    zero after the online tuning.  The data that collected to estimate the
    throughput of the scheme's action is also reset, and therefore the
    estimation should start from the scratch again.  Because the throughput
    estimation is being used to convert the time quota to the effective size
    quota, this could result in temporal time quota inaccuracy.  It would be
    recovered over time, though.  In short, the quota accuracy could be
    temporarily degraded after online parameters update.
    
    Fix the problem by checking the case and copying the internal fields for
    the status.
    
    Link: https://lkml.kernel.org/r/20240216194025.9207-1-sj@kernel.org
    Link: https://lkml.kernel.org/r/20240216194025.9207-2-sj@kernel.org
    Fixes: e035c280f6df ("mm/damon/reclaim: support online inputs update")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>    [5.19+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47467e04816cb297905c0f09bc2d11ef865942d9
Author: Gao Xiang <xiang@kernel.org>
Date:   Sat Jan 13 23:06:02 2024 +0800

    erofs: fix inconsistent per-file compression format
    
    commit 118a8cf504d7dfa519562d000f423ee3ca75d2c4 upstream.
    
    EROFS can select compression algorithms on a per-file basis, and each
    per-file compression algorithm needs to be marked in the on-disk
    superblock for initialization.
    
    However, syzkaller can generate inconsistent crafted images that use
    an unsupported algorithmtype for specific inodes, e.g. use MicroLZMA
    algorithmtype even it's not set in `sbi->available_compr_algs`.  This
    can lead to an unexpected "BUG: kernel NULL pointer dereference" if
    the corresponding decompressor isn't built-in.
    
    Fix this by checking against `sbi->available_compr_algs` for each
    m_algorithmformat request.  Incorrect !erofs_sb_has_compr_cfgs preset
    bitmap is now fixed together since it was harmless previously.
    
    Reported-by: <bugreport@ubisectech.com>
    Fixes: 8f89926290c4 ("erofs: get compression algorithms directly on mapping")
    Fixes: 622ceaddb764 ("erofs: lzma compression support")
    Reviewed-by: Yue Hu <huyue2@coolpad.com>
    Link: https://lore.kernel.org/r/20240113150602.1471050-1-hsiangkao@linux.alibaba.com
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Yue Hu <huyue2@coolpad.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 54407d9bc5e32e51d4e8488d2cfbaa976e9127fb
Author: Gao Xiang <xiang@kernel.org>
Date:   Sun Oct 22 21:09:57 2023 +0800

    erofs: simplify compression configuration parser
    
    commit efb4fb02cef3ab410b603c8f0e1c67f61d55f542 upstream.
    
    Move erofs_load_compr_cfgs() into decompressor.c as well as introduce
    a callback instead of a hard-coded switch for each algorithm for
    simplicity.
    
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20231022130957.11398-1-xiang@kernel.org
    Stable-dep-of: 118a8cf504d7 ("erofs: fix inconsistent per-file compression format")
    Signed-off-by: Yue Hu <huyue2@coolpad.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1301f15ddc26d53f7e77e76c8c7236ce4bc2a18
Author: Corey Minyard <minyard@acm.org>
Date:   Wed Feb 21 20:27:13 2024 +0100

    i2c: imx: when being a target, mark the last read as processed
    
    [ Upstream commit 87aec499368d488c20292952d6d4be7cb9e49c5e ]
    
    When being a target, NAK from the controller means that all bytes have
    been transferred. So, the last byte needs also to be marked as
    'processed'. Otherwise index registers of backends may not increase.
    
    Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
    Signed-off-by: Corey Minyard <minyard@acm.org>
    Tested-by: Andrew Manley <andrew.manley@sealingtech.com>
    Reviewed-by: Andrew Manley <andrew.manley@sealingtech.com>
    Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
    [wsa: fixed comment and commit message to properly describe the case]
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58168005337eabef345a872be3f87d0215ff3b30
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Tue Feb 13 01:50:50 2024 +0100

    drm/amd/display: Fix memory leak in dm_sw_fini()
    
    [ Upstream commit bae67893578d608e35691dcdfa90c4957debf1d3 ]
    
    After destroying dmub_srv, the memory associated with it is
    not freed, causing a memory leak:
    
    unreferenced object 0xffff896302b45800 (size 1024):
      comm "(udev-worker)", pid 222, jiffies 4294894636
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace (crc 6265fd77):
        [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
        [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
        [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu]
        [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
        [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
        [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
        [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90
        [<ffffffff996918a3>] pci_device_probe+0xc3/0x230
        [<ffffffff99805872>] really_probe+0xe2/0x480
        [<ffffffff99805c98>] __driver_probe_device+0x78/0x160
        [<ffffffff99805daf>] driver_probe_device+0x1f/0x90
        [<ffffffff9980601e>] __driver_attach+0xce/0x1c0
        [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
        [<ffffffff99804822>] bus_add_driver+0x112/0x210
        [<ffffffff99807245>] driver_register+0x55/0x100
        [<ffffffff990012d1>] do_one_initcall+0x41/0x300
    
    Fix this by freeing dmub_srv after destroying it.
    
    Fixes: 743b9786b14a ("drm/amd/display: Hook up the DMUB service in DM")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd7b4f4fdc7cc00fb5e6812b67decdde33b3786e
Author: Erik Kurzinger <ekurzinger@nvidia.com>
Date:   Fri Jan 19 08:32:06 2024 -0800

    drm/syncobj: call drm_syncobj_fence_add_wait when WAIT_AVAILABLE flag is set
    
    [ Upstream commit 3c43177ffb54ea5be97505eb8e2690e99ac96bc9 ]
    
    When waiting for a syncobj timeline point whose fence has not yet been
    submitted with the WAIT_FOR_SUBMIT flag, a callback is registered using
    drm_syncobj_fence_add_wait and the thread is put to sleep until the
    timeout expires. If the fence is submitted before then,
    drm_syncobj_add_point will wake up the sleeping thread immediately which
    will proceed to wait for the fence to be signaled.
    
    However, if the WAIT_AVAILABLE flag is used instead,
    drm_syncobj_fence_add_wait won't get called, meaning the waiting thread
    will always sleep for the full timeout duration, even if the fence gets
    submitted earlier. If it turns out that the fence *has* been submitted
    by the time it eventually wakes up, it will still indicate to userspace
    that the wait completed successfully (it won't return -ETIME), but it
    will have taken much longer than it should have.
    
    To fix this, we must call drm_syncobj_fence_add_wait if *either* the
    WAIT_FOR_SUBMIT flag or the WAIT_AVAILABLE flag is set. The only
    difference being that with WAIT_FOR_SUBMIT we will also wait for the
    fence to be signaled after it has been submitted while with
    WAIT_AVAILABLE we will return immediately.
    
    IGT test patch: https://lists.freedesktop.org/archives/igt-dev/2024-January/067537.html
    
    v1 -> v2: adjust lockdep_assert_none_held_once condition
    
    (cherry picked from commit 8c44ea81634a4a337df70a32621a5f3791be23df)
    
    Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8")
    Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
    Signed-off-by: Simon Ser <contact@emersion.fr>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Simon Ser <contact@emersion.fr>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240119163208.3723457-1-ekurzinger@nvidia.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b9196289e36cc520ad9fa2d2f4b1c54b06f364a4
Author: Siddharth Vadapalli <s-vadapalli@ti.com>
Date:   Tue Feb 20 12:30:07 2024 +0530

    net: phy: realtek: Fix rtl8211f_config_init() for RTL8211F(D)(I)-VD-CG PHY
    
    [ Upstream commit 3489182b11d35f1944c1245fc9c4867cf622c50f ]
    
    Commit bb726b753f75 ("net: phy: realtek: add support for
    RTL8211F(D)(I)-VD-CG") extended support of the driver from the existing
    support for RTL8211F(D)(I)-CG PHY to the newer RTL8211F(D)(I)-VD-CG PHY.
    
    While that commit indicated that the RTL8211F_PHYCR2 register is not
    supported by the "VD-CG" PHY model and therefore updated the corresponding
    section in rtl8211f_config_init() to be invoked conditionally, the call to
    "genphy_soft_reset()" was left as-is, when it should have also been invoked
    conditionally. This is because the call to "genphy_soft_reset()" was first
    introduced by the commit 0a4355c2b7f8 ("net: phy: realtek: add dt property
    to disable CLKOUT clock") since the RTL8211F guide indicates that a PHY
    reset should be issued after setting bits in the PHYCR2 register.
    
    As the PHYCR2 register is not applicable to the "VD-CG" PHY model, fix the
    rtl8211f_config_init() function by invoking "genphy_soft_reset()"
    conditionally based on the presence of the "PHYCR2" register.
    
    Fixes: bb726b753f75 ("net: phy: realtek: add support for RTL8211F(D)(I)-VD-CG")
    Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240220070007.968762-1-s-vadapalli@ti.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 37919ef31d7c9967ce299af0151bd7d22d7e53f7
Author: Justin Iurman <justin.iurman@uliege.be>
Date:   Mon Feb 19 14:52:54 2024 +0100

    Fix write to cloned skb in ipv6_hop_ioam()
    
    [ Upstream commit f198d933c2e4f8f89e0620fbaf1ea7eac384a0eb ]
    
    ioam6_fill_trace_data() writes inside the skb payload without ensuring
    it's writeable (e.g., not cloned). This function is called both from the
    input and output path. The output path (ioam6_iptunnel) already does the
    check. This commit provides a fix for the input path, inside
    ipv6_hop_ioam(). It also updates ip6_parse_tlv() to refresh the network
    header pointer ("nh") when returning from ipv6_hop_ioam().
    
    Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace")
    Reported-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Justin Iurman <justin.iurman@uliege.be>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d5523e065b568e79dfaa2ea1085a5bcf74baf78
Author: Rémi Denis-Courmont <courmisch@gmail.com>
Date:   Sun Feb 18 10:12:14 2024 +0200

    phonet/pep: fix racy skb_queue_empty() use
    
    [ Upstream commit 7d2a894d7f487dcb894df023e9d3014cf5b93fe5 ]
    
    The receive queues are protected by their respective spin-lock, not
    the socket lock. This could lead to skb_peek() unexpectedly
    returning NULL or a pointer to an already dequeued socket buffer.
    
    Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol")
    Signed-off-by: Rémi Denis-Courmont <courmisch@gmail.com>
    Link: https://lore.kernel.org/r/20240218081214.4806-2-remi@remlab.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f556a352fdb2489d50f1231f58b6dfbadb4e3756
Author: Rémi Denis-Courmont <courmisch@gmail.com>
Date:   Sun Feb 18 10:12:13 2024 +0200

    phonet: take correct lock to peek at the RX queue
    
    [ Upstream commit 3b2d9bc4d4acdf15a876eae2c0d83149250e85ba ]
    
    The receive queue is protected by its embedded spin-lock, not the
    socket lock, so we need the former lock here (and only that one).
    
    Fixes: 107d0d9b8d9a ("Phonet: Phonet datagram transport protocol")
    Reported-by: Luosili <rootlab@huawei.com>
    Signed-off-by: Rémi Denis-Courmont <courmisch@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240218081214.4806-1-remi@remlab.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1623161f80a4b8bb284b0cc3118daf3ccd5bf923
Author: Horatiu Vultur <horatiu.vultur@microchip.com>
Date:   Mon Feb 19 09:00:43 2024 +0100

    net: sparx5: Add spinlock for frame transmission from CPU
    
    [ Upstream commit 603ead96582d85903baec2d55f021b8dac5c25d2 ]
    
    Both registers used when doing manual injection or fdma injection are
    shared between all the net devices of the switch. It was noticed that
    when having two process which each of them trying to inject frames on
    different ethernet ports, that the HW started to behave strange, by
    sending out more frames then expected. When doing fdma injection it is
    required to set the frame in the DCB and then make sure that the next
    pointer of the last DCB is invalid. But because there is no locks for
    this, then easily this pointer between the DCB can be broken and then it
    would create a loop of DCBs. And that means that the HW will
    continuously transmit these frames in a loop. Until the SW will break
    this loop.
    Therefore to fix this issue, add a spin lock for when accessing the
    registers for manual or fdma injection.
    
    Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
    Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support")
    Link: https://lore.kernel.org/r/20240219080043.1561014-1-horatiu.vultur@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c22ad76cfc43a2c7923de1a9acc0d05b9fa2c63c
Author: Jeremy Kerr <jk@codeconstruct.com.au>
Date:   Thu Feb 15 15:53:08 2024 +0800

    net: mctp: put sock on tag allocation failure
    
    [ Upstream commit 9990889be14288d4f1743e4768222d5032a79c27 ]
    
    We may hold an extra reference on a socket if a tag allocation fails: we
    optimistically allocate the sk_key, and take a ref there, but do not
    drop if we end up not using the allocated key.
    
    Ensure we're dropping the sock on this failure by doing a proper unref
    rather than directly kfree()ing.
    
    Fixes: de8a6b15d965 ("net: mctp: add an explicit reference from a mctp_sk_key to sock")
    Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/ce9b61e44d1cdae7797be0c5e3141baf582d23a0.1707983487.git.jk@codeconstruct.com.au
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea33b816691255d1d5eeb7f5a02f2acf6a556393
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Feb 21 18:38:45 2024 +0100

    netfilter: nf_tables: use kzalloc for hook allocation
    
    [ Upstream commit 195e5f88c2e48330ba5483e0bad2de3b3fad484f ]
    
    KMSAN reports unitialized variable when registering the hook,
       reg->hook_ops_type == NF_HOOK_OP_BPF)
            ~~~~~~~~~~~ undefined
    
    This is a small structure, just use kzalloc to make sure this
    won't happen again when new fields get added to nf_hook_ops.
    
    Fixes: 7b4b2fa37587 ("netfilter: annotate nf_tables base hook ops")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f305359186724ac4bc058d5cd01782e6e6f9a3e7
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Feb 19 19:43:53 2024 +0100

    netfilter: nf_tables: register hooks last when adding new chain/flowtable
    
    [ Upstream commit d472e9853d7b46a6b094224d131d09ccd3a03daf ]
    
    Register hooks last when adding chain/flowtable to ensure that packets do
    not walk over datastructure that is being released in the error path
    without waiting for the rcu grace period.
    
    Fixes: 91c7b38dc9f0 ("netfilter: nf_tables: use new transaction infrastructure to handle chain")
    Fixes: 3b49e2e94e6e ("netfilter: nf_tables: add flow table netlink frontend")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 26994a04b0ba50388600a617afe7baaa239cad25
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Apr 21 00:34:30 2023 +0200

    netfilter: nf_tables: rename function to destroy hook list
    
    [ Upstream commit cdc32546632354305afdcf399a5431138a31c9e0 ]
    
    Rename nft_flowtable_hooks_destroy() by nft_hooks_destroy() to prepare
    for netdev chain device updates.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Stable-dep-of: d472e9853d7b ("netfilter: nf_tables: register hooks last when adding new chain/flowtable")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a6cafdb49a7bbf4a88367db209703eee6941e023
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Feb 20 21:36:39 2024 +0100

    netfilter: nft_flow_offload: release dst in case direct xmit path is used
    
    [ Upstream commit 8762785f459be1cfe6fcf7285c123aad6a3703f0 ]
    
    Direct xmit does not use it since it calls dev_queue_xmit() to send
    packets, hence it calls dst_release().
    
    kmemleak reports:
    
    unreferenced object 0xffff88814f440900 (size 184):
      comm "softirq", pid 0, jiffies 4294951896
      hex dump (first 32 bytes):
        00 60 5b 04 81 88 ff ff 00 e6 e8 82 ff ff ff ff  .`[.............
        21 0b 50 82 ff ff ff ff 00 00 00 00 00 00 00 00  !.P.............
      backtrace (crc cb2bf5d6):
        [<000000003ee17107>] kmem_cache_alloc+0x286/0x340
        [<0000000021a5de2c>] dst_alloc+0x43/0xb0
        [<00000000f0671159>] rt_dst_alloc+0x2e/0x190
        [<00000000fe5092c9>] __mkroute_output+0x244/0x980
        [<000000005fb96fb0>] ip_route_output_flow+0xc0/0x160
        [<0000000045367433>] nf_ip_route+0xf/0x30
        [<0000000085da1d8e>] nf_route+0x2d/0x60
        [<00000000d1ecd1cb>] nft_flow_route+0x171/0x6a0 [nft_flow_offload]
        [<00000000d9b2fb60>] nft_flow_offload_eval+0x4e8/0x700 [nft_flow_offload]
        [<000000009f447dbb>] expr_call_ops_eval+0x53/0x330 [nf_tables]
        [<00000000072e1be6>] nft_do_chain+0x17c/0x840 [nf_tables]
        [<00000000d0551029>] nft_do_chain_inet+0xa1/0x210 [nf_tables]
        [<0000000097c9d5c6>] nf_hook_slow+0x5b/0x160
        [<0000000005eccab1>] ip_forward+0x8b6/0x9b0
        [<00000000553a269b>] ip_rcv+0x221/0x230
        [<00000000412872e5>] __netif_receive_skb_one_core+0xfe/0x110
    
    Fixes: fa502c865666 ("netfilter: flowtable: simplify route logic")
    Reported-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 012df10717da02367aaf92c65f9c89db206c15f4
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Feb 21 12:32:58 2024 +0100

    netfilter: nft_flow_offload: reset dst in route object after setting up flow
    
    [ Upstream commit 9e0f0430389be7696396c62f037be4bf72cf93e3 ]
    
    dst is transferred to the flow object, route object does not own it
    anymore.  Reset dst in route object, otherwise if flow_offload_add()
    fails, error path releases dst twice, leading to a refcount underflow.
    
    Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c5662e95a8dcc232c3ef4deb21033badcd260f6
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu May 11 07:35:33 2023 +0200

    netfilter: flowtable: simplify route logic
    
    [ Upstream commit fa502c86566680ac62bc28ec883a069bf7a2aa5e ]
    
    Grab reference to dst from skbuff earlier to simplify route caching.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Stable-dep-of: 9e0f0430389b ("netfilter: nft_flow_offload: reset dst in route object after setting up flow")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c9302a6da262e6ab6a6c1d30f04a6130ed97376
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Feb 19 16:58:04 2024 +0100

    netfilter: nf_tables: set dormant flag on hook register failure
    
    [ Upstream commit bccebf64701735533c8db37773eeacc6566cc8ec ]
    
    We need to set the dormant flag again if we fail to register
    the hooks.
    
    During memory pressure hook registration can fail and we end up
    with a table marked as active but no registered hooks.
    
    On table/base chain deletion, nf_tables will attempt to unregister
    the hook again which yields a warn splat from the nftables core.
    
    Reported-and-tested-by: syzbot+de4025c006ec68ac56fc@syzkaller.appspotmail.com
    Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bdaf6bbfc1f231bacc22d222d830b9dc817d7d23
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Thu Feb 15 17:17:31 2024 +0100

    tls: don't skip over different type records from the rx_list
    
    [ Upstream commit ec823bf3a479d42c589dc0f28ef4951c49cd2d2a ]
    
    If we queue 3 records:
     - record 1, type DATA
     - record 2, some other type
     - record 3, type DATA
    and do a recv(PEEK), the rx_list will contain the first two records.
    
    The next large recv will walk through the rx_list and copy data from
    record 1, then stop because record 2 is a different type. Since we
    haven't filled up our buffer, we will process the next available
    record. It's also DATA, so we can merge it with the current read.
    
    We shouldn't do that, since there was a record in between that we
    ignored.
    
    Add a flag to let process_rx_list inform tls_sw_recvmsg that it had
    more data available.
    
    Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/f00c0c0afa080c60f016df1471158c1caf983c34.1708007371.git.sd@queasysnail.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6756168add1c6c3ef1c32c335bb843a5d1f99a75
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Thu Feb 15 17:17:30 2024 +0100

    tls: stop recv() if initial process_rx_list gave us non-DATA
    
    [ Upstream commit fdfbaec5923d9359698cbb286bc0deadbb717504 ]
    
    If we have a non-DATA record on the rx_list and another record of the
    same type still on the queue, we will end up merging them:
     - process_rx_list copies the non-DATA record
     - we start the loop and process the first available record since it's
       of the same type
     - we break out of the loop since the record was not DATA
    
    Just check the record type and jump to the end in case process_rx_list
    did some work.
    
    Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/bd31449e43bd4b6ff546f5c51cf958c31c511deb.1708007371.git.sd@queasysnail.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca89b4f5034d5c775956cd3830e9e7930d7053ff
Author: Sabrina Dubroca <sd@queasysnail.net>
Date:   Thu Feb 15 17:17:29 2024 +0100

    tls: break out of main loop when PEEK gets a non-data record
    
    [ Upstream commit 10f41d0710fc81b7af93fa6106678d57b1ff24a7 ]
    
    PEEK needs to leave decrypted records on the rx_list so that we can
    receive them later on, so it jumps back into the async code that
    queues the skb. Unfortunately that makes us skip the
    TLS_RECORD_TYPE_DATA check at the bottom of the main loop, so if two
    records of the same (non-DATA) type are queued, we end up merging
    them.
    
    Add the same record type check, and make it unlikely to not penalize
    the async fastpath. Async decrypt only applies to data record, so this
    check is only needed for PEEK.
    
    process_rx_list also has similar issues.
    
    Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records")
    Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/3df2eef4fdae720c55e69472b5bea668772b45a2.1708007371.git.sd@queasysnail.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4588b13abcbd561ec67f5b3c1cb2eff690990a54
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Mon Feb 19 00:09:33 2024 +0900

    bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()
    
    [ Upstream commit 4cd12c6065dfcdeba10f49949bffcf383b3952d8 ]
    
    syzbot reported the following NULL pointer dereference issue [1]:
    
      BUG: kernel NULL pointer dereference, address: 0000000000000000
      [...]
      RIP: 0010:0x0
      [...]
      Call Trace:
       <TASK>
       sk_psock_verdict_data_ready+0x232/0x340 net/core/skmsg.c:1230
       unix_stream_sendmsg+0x9b4/0x1230 net/unix/af_unix.c:2293
       sock_sendmsg_nosec net/socket.c:730 [inline]
       __sock_sendmsg+0x221/0x270 net/socket.c:745
       ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
       ___sys_sendmsg net/socket.c:2638 [inline]
       __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
       do_syscall_64+0xf9/0x240
       entry_SYSCALL_64_after_hwframe+0x6f/0x77
    
    If sk_psock_verdict_data_ready() and sk_psock_stop_verdict() are called
    concurrently, psock->saved_data_ready can be NULL, causing the above issue.
    
    This patch fixes this issue by calling the appropriate data ready function
    using the sk_psock_data_ready() helper and protecting it from concurrency
    with sk->sk_callback_lock.
    
    Fixes: 6df7f764cd3c ("bpf, sockmap: Wake up polling after data copy")
    Reported-by: syzbot+fd7b34375c1c8ce29c93@syzkaller.appspotmail.com
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: syzbot+fd7b34375c1c8ce29c93@syzkaller.appspotmail.com
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=fd7b34375c1c8ce29c93 [1]
    Link: https://lore.kernel.org/bpf/20240218150933.6004-1-syoshida@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 11277d18926717a3c00ef745714b16f82b8f8504
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Fri Feb 16 20:48:14 2024 -0400

    s390: use the correct count for __iowrite64_copy()
    
    [ Upstream commit 723a2cc8d69d4342b47dfddbfe6c19f1b135f09b ]
    
    The signature for __iowrite64_copy() requires the number of 64 bit
    quantities, not bytes. Multiple by 8 to get to a byte length before
    invoking zpci_memcpy_toio()
    
    Fixes: 87bc359b9822 ("s390/pci: speed up __iowrite64_copy by using pci store block insn")
    Acked-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Link: https://lore.kernel.org/r/0-v1-9223d11a7662+1d7785-s390_iowrite64_jgg@nvidia.com
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18580e48e624f04bcd1ed854ccc2d8f2e2225e02
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date:   Mon Feb 19 18:25:14 2024 +0530

    octeontx2-af: Consider the action set by PF
    
    [ Upstream commit 3b1ae9b71c2a97f848b00fb085a2bd29bddbe8d9 ]
    
    AF reserves MCAM entries for each PF, VF present in the
    system and populates the entry with DMAC and action with
    default RSS so that basic packet I/O works. Since PF/VF is
    not aware of the RSS action installed by AF, AF only fixup
    the actions of the rules installed by PF/VF with corresponding
    default RSS action. This worked well for rules installed by
    PF/VF for features like RX VLAN offload and DMAC filters but
    rules involving action like drop/forward to queue are also
    getting modified by AF. Hence fix it by setting the default
    RSS action only if requested by PF/VF.
    
    Fixes: 967db3529eca ("octeontx2-af: add support for multicast/promisc packet replication feature")
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6216509a2e11d6600aa24b92ba2735f820be4eae
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Fri Feb 16 20:23:11 2024 -0600

    platform/x86: thinkpad_acpi: Only update profile if successfully converted
    
    [ Upstream commit 427c70dec738318b7f71e1b9d829ff0e9771d493 ]
    
    Randomly a Lenovo Z13 will trigger a kernel warning traceback from this
    condition:
    
    ```
    if (WARN_ON((profile < 0) || (profile >= ARRAY_SIZE(profile_names))))
    ```
    
    This happens because thinkpad-acpi always assumes that
    convert_dytc_to_profile() successfully updated the profile. On the
    contrary a condition can occur that when dytc_profile_refresh() is called
    the profile doesn't get updated as there is a -EOPNOTSUPP branch.
    
    Catch this situation and avoid updating the profile. Also log this into
    dynamic debugging in case any other modes should be added in the future.
    
    Fixes: c3bfcd4c6762 ("platform/x86: thinkpad_acpi: Add platform profile support")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20240217022311.113879-1-mario.limonciello@amd.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38c83c2488dc3726aad855c05ce91d28e968b9f3
Author: Mark Brown <broonie@kernel.org>
Date:   Tue Feb 13 23:06:32 2024 +0000

    arm64/sme: Restore SME registers on exit from suspend
    
    [ Upstream commit 9533864816fb4a6207c63b7a98396351ce1a9fae ]
    
    The fields in SMCR_EL1 and SMPRI_EL1 reset to an architecturally UNKNOWN
    value. Since we do not otherwise manage the traps configured in this
    register at runtime we need to reconfigure them after a suspend in case
    nothing else was kind enough to preserve them for us.
    
    The vector length will be restored as part of restoring the SME state for
    the next SME using task.
    
    Fixes: a1f4ccd25cc2 ("arm64/sme: Provide Kconfig for SME")
    Reported-by: Jackson Cooper-Driver <Jackson.Cooper-Driver@arm.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20240213-arm64-sme-resume-v3-1-17e05e493471@kernel.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd84a5fae03c0a6ca66d6d7eb9f473b2c7957c21
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Oct 18 02:56:03 2022 -0700

    net: dev: Convert sa_data to flexible array in struct sockaddr
    
    [ Upstream commit b5f0de6df6dce8d641ef58ef7012f3304dffb9a1 ]
    
    One of the worst offenders of "fake flexible arrays" is struct sockaddr,
    as it is the classic example of why GCC and Clang have been traditionally
    forced to treat all trailing arrays as fake flexible arrays: in the
    distant misty past, sa_data became too small, and code started just
    treating it as a flexible array, even though it was fixed-size. The
    special case by the compiler is specifically that sizeof(sa->sa_data)
    and FORTIFY_SOURCE (which uses __builtin_object_size(sa->sa_data, 1))
    do not agree (14 and -1 respectively), which makes FORTIFY_SOURCE treat
    it as a flexible array.
    
    However, the coming -fstrict-flex-arrays compiler flag will remove
    these special cases so that FORTIFY_SOURCE can gain coverage over all
    the trailing arrays in the kernel that are _not_ supposed to be treated
    as a flexible array. To deal with this change, convert sa_data to a true
    flexible array. To keep the structure size the same, move sa_data into
    a union with a newly introduced sa_data_min with the original size. The
    result is that FORTIFY_SOURCE can continue to have no idea how large
    sa_data may actually be, but anything using sizeof(sa->sa_data) must
    switch to sizeof(sa->sa_data_min).
    
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Pavel Begunkov <asml.silence@gmail.com>
    Cc: David Ahern <dsahern@kernel.org>
    Cc: Dylan Yudaken <dylany@fb.com>
    Cc: Yajun Deng <yajun.deng@linux.dev>
    Cc: Petr Machata <petrm@nvidia.com>
    Cc: Hangbin Liu <liuhangbin@gmail.com>
    Cc: Leon Romanovsky <leon@kernel.org>
    Cc: syzbot <syzkaller@googlegroups.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221018095503.never.671-kees@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: a7d6027790ac ("arp: Prevent overflow in arp_req_get().")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8391b9b651cfdf80ab0f1dc4a489f9d67386e197
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Thu Feb 15 23:27:17 2024 +0300

    ipv6: sr: fix possible use-after-free and null-ptr-deref
    
    [ Upstream commit 5559cea2d5aa3018a5f00dd2aca3427ba09b386b ]
    
    The pernet operations structure for the subsystem must be registered
    before registering the generic netlink family.
    
    Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of SR-IPv6")
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Link: https://lore.kernel.org/r/20240215202717.29815-1-kovalev@altlinux.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e8530b170e464017203e3b8c6c49af6e916aece1
Author: Daniil Dulov <d.dulov@aladdin.ru>
Date:   Mon Feb 19 14:39:03 2024 +0000

    afs: Increase buffer size in afs_update_volume_status()
    
    [ Upstream commit 6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d ]
    
    The max length of volume->vid value is 20 characters.
    So increase idbuf[] size up to 24 to avoid overflow.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    [DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()]
    
    Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation")
    Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/r/20240211150442.3416-1-d.dulov@aladdin.ru/ # v1
    Link: https://lore.kernel.org/r/20240212083347.10742-1-d.dulov@aladdin.ru/ # v2
    Link: https://lore.kernel.org/r/20240219143906.138346-3-dhowells@redhat.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit addf5e297e6cbf5341f9c07720693ca9ba0057b5
Author: Martin KaFai Lau <martin.lau@kernel.org>
Date:   Thu Feb 15 13:12:17 2024 -0800

    bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel
    
    [ Upstream commit 0281b919e175bb9c3128bd3872ac2903e9436e3f ]
    
    The following race is possible between bpf_timer_cancel_and_free
    and bpf_timer_cancel. It will lead a UAF on the timer->timer.
    
    bpf_timer_cancel();
            spin_lock();
            t = timer->time;
            spin_unlock();
    
                                            bpf_timer_cancel_and_free();
                                                    spin_lock();
                                                    t = timer->timer;
                                                    timer->timer = NULL;
                                                    spin_unlock();
                                                    hrtimer_cancel(&t->timer);
                                                    kfree(t);
    
            /* UAF on t */
            hrtimer_cancel(&t->timer);
    
    In bpf_timer_cancel_and_free, this patch frees the timer->timer
    after a rcu grace period. This requires a rcu_head addition
    to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init,
    this does not need a kfree_rcu because it is still under the
    spin_lock and timer->timer has not been visible by others yet.
    
    In bpf_timer_cancel, rcu_read_lock() is added because this helper
    can be used in a non rcu critical section context (e.g. from
    a sleepable bpf prog). Other timer->timer usages in helpers.c
    have been audited, bpf_timer_cancel() is the only place where
    timer->timer is used outside of the spin_lock.
    
    Another solution considered is to mark a t->flag in bpf_timer_cancel
    and clear it after hrtimer_cancel() is done.  In bpf_timer_cancel_and_free,
    it busy waits for the flag to be cleared before kfree(t). This patch
    goes with a straight forward solution and frees timer->timer after
    a rcu grace period.
    
    Fixes: b00628b1c7d5 ("bpf: Introduce bpf timers.")
    Suggested-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/bpf/20240215211218.990808-1-martin.lau@linux.dev
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a581b17b7227bfba3f109f0452d61582b3b662e
Author: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Date:   Fri Feb 16 23:44:57 2024 +0530

    ata: ahci_ceva: fix error handling for Xilinx GT PHY support
    
    [ Upstream commit 26c8404e162b43dddcb037ba2d0cb58c0ed60aab ]
    
    Platform clock and phy error resources are not cleaned up in Xilinx GT PHY
    error path.
    
    To fix introduce the function ceva_ahci_platform_enable_resources() which
    is a customized version of ahci_platform_enable_resources() and inline with
    SATA IP programming sequence it does:
    
    - Assert SATA reset
    - Program PS GTR phy
    - Bring SATA by de-asserting the reset
    - Wait for GT lane PLL to be locked
    
    ceva_ahci_platform_enable_resources() is also used in the resume path
    as the same SATA programming sequence (as in probe) should be followed.
    Also cleanup the mixed usage of ahci_platform_enable_resources() and custom
    implementation in the probe function as both are not required.
    
    Fixes: 9a9d3abe24bb ("ata: ahci: ceva: Update the driver to support xilinx GT phy")
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e5703735e57a3f1171b9b708f58850af55ef9602
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 15 17:21:07 2024 +0000

    ipv6: properly combine dev_base_seq and ipv6.dev_addr_genid
    
    [ Upstream commit e898e4cd1aab271ca414f9ac6e08e4c761f6913c ]
    
    net->dev_base_seq and ipv6.dev_addr_genid are monotonically increasing.
    
    If we XOR their values, we could miss to detect if both values
    were changed with the same amount.
    
    Fixes: 63998ac24f83 ("ipv6: provide addr and netconf dump consistency info")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b43a4fb42fefa69b00a4bc697c59b8107d9293cb
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 15 17:21:06 2024 +0000

    ipv4: properly combine dev_base_seq and ipv4.dev_addr_genid
    
    [ Upstream commit 081a0e3b0d4c061419d3f4679dec9f68725b17e4 ]
    
    net->dev_base_seq and ipv4.dev_addr_genid are monotonically increasing.
    
    If we XOR their values, we could miss to detect if both values
    were changed with the same amount.
    
    Fixes: 0465277f6b3f ("ipv4: provide addr and netconf dump consistency info")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e29f988ad32e87fbfe263d7d22d24c6a9eaba05
Author: Pavel Sakharov <p.sakharov@ispras.ru>
Date:   Wed Feb 14 12:27:17 2024 +0300

    net: stmmac: Fix incorrect dereference in interrupt handlers
    
    [ Upstream commit 97dde84026339e4b4af9a6301f825d1828d7874b ]
    
    If 'dev' or 'data' is NULL, the 'priv' variable has an incorrect address
    when dereferencing calling netdev_err().
    
    Since we get as 'dev_id' or 'data' what was passed as the 'dev' argument
    to request_irq() during interrupt initialization (that is, the net_device
    and rx/tx queue pointers initialized at the time of the call) and since
    there are usually no checks for the 'dev_id' argument in such handlers
    in other drivers, remove these checks from the handlers in stmmac driver.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 8532f613bc78 ("net: stmmac: introduce MSI Interrupt routines for mac, safety, RX & TX")
    Signed-off-by: Pavel Sakharov <p.sakharov@ispras.ru>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25bd33b87f8a337c7dbbb2887c82120ef99851e7
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Fri Jan 12 12:09:51 2024 -0800

    x86/numa: Fix the sort compare func used in numa_fill_memblks()
    
    [ Upstream commit b626070ffc14acca5b87a2aa5f581db98617584c ]
    
    The compare function used to sort memblks into starting address
    order fails when the result of its u64 address subtraction gets
    truncated to an int upon return.
    
    The impact of the bad sort is that memblks will be filled out
    incorrectly. Depending on the set of memblks, a user may see no
    errors at all but still have a bad fill, or see messages reporting
    a node overlap that leads to numa init failure:
    
    [] node 0 [mem: ] overlaps with node 1 [mem: ]
    [] No NUMA configuration found
    
    Replace with a comparison that can only result in: 1, 0, -1.
    
    Fixes: 8f012db27c95 ("x86/numa: Introduce numa_fill_memblks()")
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Link: https://lore.kernel.org/r/99dcb3ae87e04995e9f293f6158dc8fa0749a487.1705085543.git.alison.schofield@intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca4a1c00beffe9c1f090ea0a5912e00975146578
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Fri Jan 12 12:09:50 2024 -0800

    x86/numa: Fix the address overlap check in numa_fill_memblks()
    
    [ Upstream commit 9b99c17f7510bed2adbe17751fb8abddba5620bc ]
    
    numa_fill_memblks() fills in the gaps in numa_meminfo memblks over a
    physical address range. To do so, it first creates a list of existing
    memblks that overlap that address range. The issue is that it is off
    by one when comparing to the end of the address range, so memblks
    that do not overlap are selected.
    
    The impact of selecting a memblk that does not actually overlap is
    that an existing memblk may be filled when the expected action is to
    do nothing and return NUMA_NO_MEMBLK to the caller. The caller can
    then add a new NUMA node and memblk.
    
    Replace the broken open-coded search for address overlap with the
    memblock helper memblock_addrs_overlap(). Update the kernel doc
    and in code comments.
    
    Suggested by: "Huang, Ying" <ying.huang@intel.com>
    
    Fixes: 8f012db27c95 ("x86/numa: Introduce numa_fill_memblks()")
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>
    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Link: https://lore.kernel.org/r/10a3e6109c34c21a8dd4c513cf63df63481a2b07.1705085543.git.alison.schofield@intel.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b06a3b1cbdfbfec85af1efda3c55cc9d8a492b08
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 13 10:57:37 2024 +0100

    nouveau: fix function cast warnings
    
    [ Upstream commit 0affdba22aca5573f9d989bcb1d71d32a6a03efe ]
    
    clang-16 warns about casting between incompatible function types:
    
    drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c:161:10: error: cast from 'void (*)(const struct firmware *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
      161 |         .fini = (void(*)(void *))release_firmware,
    
    This one was done to use the generic shadow_fw_release() function as a
    callback for struct nvbios_source. Change it to use the same prototype
    as the other five instances, with a trivial helper function that actually
    calls release_firmware.
    
    Fixes: 70c0f263cc2e ("drm/nouveau/bios: pull in basic vbios subdev, more to come later")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240213095753.455062-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 729bc77af438a6e67914c97f6f3d3af8f72c0131
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Wed Feb 14 11:13:08 2024 -0800

    dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().
    
    [ Upstream commit 66b60b0c8c4a163b022a9f0ad6769b0fd3dc662f ]
    
    syzkaller reported a warning [0] in inet_csk_destroy_sock() with no
    repro.
    
      WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash);
    
    However, the syzkaller's log hinted that connect() failed just before
    the warning due to FAULT_INJECTION.  [1]
    
    When connect() is called for an unbound socket, we search for an
    available ephemeral port.  If a bhash bucket exists for the port, we
    call __inet_check_established() or __inet6_check_established() to check
    if the bucket is reusable.
    
    If reusable, we add the socket into ehash and set inet_sk(sk)->inet_num.
    
    Later, we look up the corresponding bhash2 bucket and try to allocate
    it if it does not exist.
    
    Although it rarely occurs in real use, if the allocation fails, we must
    revert the changes by check_established().  Otherwise, an unconnected
    socket could illegally occupy an ehash entry.
    
    Note that we do not put tw back into ehash because sk might have
    already responded to a packet for tw and it would be better to free
    tw earlier under such memory presure.
    
    [0]:
    WARNING: CPU: 0 PID: 350830 at net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
    Modules linked in:
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
    Code: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e7 be 03 00 00 00 e8 05
    RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40
    RDX: ffff88806e46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8
    RBP: ffff88811755c880 R08: 0000000000000003 R09: 0000000000000000
    R10: 0000000000009e78 R11: 0000000000000000 R12: ffff88811755c8e0
    R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000
    FS:  00007f03e5243800(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
     dccp_close (net/dccp/proto.c:1078)
     inet_release (net/ipv4/af_inet.c:434)
     __sock_release (net/socket.c:660)
     sock_close (net/socket.c:1423)
     __fput (fs/file_table.c:377)
     __fput_sync (fs/file_table.c:462)
     __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539)
     do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
    RIP: 0033:0x7f03e53852bb
    Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44
    RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
    RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f03e53852bb
    RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003
    RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000167c
    R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000
    R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e43170
     </TASK>
    
    [1]:
    FAULT_INJECTION: forcing a failure.
    name failslab, interval 1, probability 0, space 0, times 0
    CPU: 0 PID: 350833 Comm: syz-executor.1 Not tainted 6.7.0-12272-g2121c43f88f5 #9
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
     should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)
     should_failslab (mm/slub.c:3748)
     kmem_cache_alloc (mm/slub.c:3763 mm/slub.c:3842 mm/slub.c:3867)
     inet_bind2_bucket_create (net/ipv4/inet_hashtables.c:135)
     __inet_hash_connect (net/ipv4/inet_hashtables.c:1100)
     dccp_v4_connect (net/dccp/ipv4.c:116)
     __inet_stream_connect (net/ipv4/af_inet.c:676)
     inet_stream_connect (net/ipv4/af_inet.c:747)
     __sys_connect_file (net/socket.c:2048 (discriminator 2))
     __sys_connect (net/socket.c:2065)
     __x64_sys_connect (net/socket.c:2072)
     do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
    RIP: 0033:0x7f03e5284e5d
    Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
    RSP: 002b:00007f03e4641cc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
    RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f03e5284e5d
    RDX: 0000000000000010 RSI: 0000000020000000 RDI: 0000000000000003
    RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
    R13: 000000000000000b R14: 00007f03e52e5530 R15: 0000000000000000
     </TASK>
    
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Fixes: 28044fc1d495 ("net: Add a bhash2 table hashed by port and address")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91ac2c79e896b28a4a3a262384689ee6dfeaf083
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Feb 14 22:40:04 2024 +0100

    net: bridge: switchdev: Ensure deferred event delivery on unoffload
    
    [ Upstream commit f7a70d650b0b6b0134ccba763d672c8439d9f09b ]
    
    When unoffloading a device, it is important to ensure that all
    relevant deferred events are delivered to it before it disassociates
    itself from the bridge.
    
    Before this change, this was true for the normal case when a device
    maps 1:1 to a net_bridge_port, i.e.
    
       br0
       /
    swp0
    
    When swp0 leaves br0, the call to switchdev_deferred_process() in
    del_nbp() makes sure to process any outstanding events while the
    device is still associated with the bridge.
    
    In the case when the association is indirect though, i.e. when the
    device is attached to the bridge via an intermediate device, like a
    LAG...
    
        br0
        /
      lag0
      /
    swp0
    
    ...then detaching swp0 from lag0 does not cause any net_bridge_port to
    be deleted, so there was no guarantee that all events had been
    processed before the device disassociated itself from the bridge.
    
    Fix this by always synchronously processing all deferred events before
    signaling completion of unoffloading back to the driver.
    
    Fixes: 4e51bf44a03a ("net: bridge: move the switchdev object replay helpers to "push" mode")
    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d5b4b3376fa146a23917b8577064906d643925f
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Wed Feb 14 22:40:03 2024 +0100

    net: bridge: switchdev: Skip MDB replays of deferred events on offload
    
    [ Upstream commit dc489f86257cab5056e747344f17a164f63bff4b ]
    
    Before this change, generation of the list of MDB events to replay
    would race against the creation of new group memberships, either from
    the IGMP/MLD snooping logic or from user configuration.
    
    While new memberships are immediately visible to walkers of
    br->mdb_list, the notification of their existence to switchdev event
    subscribers is deferred until a later point in time. So if a replay
    list was generated during a time that overlapped with such a window,
    it would also contain a replay of the not-yet-delivered event.
    
    The driver would thus receive two copies of what the bridge internally
    considered to be one single event. On destruction of the bridge, only
    a single membership deletion event was therefore sent. As a
    consequence of this, drivers which reference count memberships (at
    least DSA), would be left with orphan groups in their hardware
    database when the bridge was destroyed.
    
    This is only an issue when replaying additions. While deletion events
    may still be pending on the deferred queue, they will already have
    been removed from br->mdb_list, so no duplicates can be generated in
    that scenario.
    
    To a user this meant that old group memberships, from a bridge in
    which a port was previously attached, could be reanimated (in
    hardware) when the port joined a new bridge, without the new bridge's
    knowledge.
    
    For example, on an mv88e6xxx system, create a snooping bridge and
    immediately add a port to it:
    
        root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \
        > ip link set dev x3 up master br0
    
    And then destroy the bridge:
    
        root@infix-06-0b-00:~$ ip link del dev br0
        root@infix-06-0b-00:~$ mvls atu
        ADDRESS             FID  STATE      Q  F  0  1  2  3  4  5  6  7  8  9  a
        DEV:0 Marvell 88E6393X
        33:33:00:00:00:6a     1  static     -  -  0  .  .  .  .  .  .  .  .  .  .
        33:33:ff:87:e4:3f     1  static     -  -  0  .  .  .  .  .  .  .  .  .  .
        ff:ff:ff:ff:ff:ff     1  static     -  -  0  1  2  3  4  5  6  7  8  9  a
        root@infix-06-0b-00:~$
    
    The two IPv6 groups remain in the hardware database because the
    port (x3) is notified of the host's membership twice: once via the
    original event and once via a replay. Since only a single delete
    notification is sent, the count remains at 1 when the bridge is
    destroyed.
    
    Then add the same port (or another port belonging to the same hardware
    domain) to a new bridge, this time with snooping disabled:
    
        root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \
        > ip link set dev x3 up master br1
    
    All multicast, including the two IPv6 groups from br0, should now be
    flooded, according to the policy of br1. But instead the old
    memberships are still active in the hardware database, causing the
    switch to only forward traffic to those groups towards the CPU (port
    0).
    
    Eliminate the race in two steps:
    
    1. Grab the write-side lock of the MDB while generating the replay
       list.
    
    This prevents new memberships from showing up while we are generating
    the replay list. But it leaves the scenario in which a deferred event
    was already generated, but not delivered, before we grabbed the
    lock. Therefore:
    
    2. Make sure that no deferred version of a replay event is already
       enqueued to the switchdev deferred queue, before adding it to the
       replay list, when replaying additions.
    
    Fixes: 4f2673b3a2b6 ("net: bridge: add helper to replay port and host-joined mdb entries")
    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 44148c1c82459e3227dca917f888c9bd3d73daae
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Feb 13 21:59:53 2024 -0800

    scsi: jazz_esp: Only build if SCSI core is builtin
    
    [ Upstream commit 9ddf190a7df77b77817f955fdb9c2ae9d1c9c9a3 ]
    
    JAZZ_ESP is a bool kconfig symbol that selects SCSI_SPI_ATTRS.  When
    CONFIG_SCSI=m, this results in SCSI_SPI_ATTRS=m while JAZZ_ESP=y, which
    causes many undefined symbol linker errors.
    
    Fix this by only offering to build this driver when CONFIG_SCSI=y.
    
    [mkp: JAZZ_ESP is unique in that it does not support being compiled as a
    module unlike the remaining SPI SCSI HBA drivers]
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Link: https://lore.kernel.org/r/20240214055953.9612-1-rdunlap@infradead.org
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: linux-mips@vger.kernel.org
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Nicolas Schier <nicolas@fjasle.eu>
    Cc: James E.J. Bottomley <jejb@linux.ibm.com>
    Cc: Martin K. Petersen <martin.petersen@oracle.com>
    Cc: linux-scsi@vger.kernel.org
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202402112222.Gl0udKyU-lkp@intel.com/
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c31b18a8dd8b7bf36af1cd723d455853b8f94fe
Author: Don Brace <don.brace@microchip.com>
Date:   Tue Feb 13 10:22:00 2024 -0600

    scsi: smartpqi: Fix disable_managed_interrupts
    
    [ Upstream commit 5761eb9761d2d5fe8248a9b719efc4d8baf1f24a ]
    
    Correct blk-mq registration issue with module parameter
    disable_managed_interrupts enabled.
    
    When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to
    register with blk-mq using blk_mq_map_queues(). The driver is currently
    calling blk_mq_pci_map_queues() which results in a stack trace and possibly
    undefined behavior.
    
    Stack Trace:
    [    7.860089] scsi host2: smartpqi
    [    7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0
    [    7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
    [    7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1
    [    7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022
    [    7.963026] Workqueue: events work_for_cpu_fn
    [    7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0
    [    7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54
    [    7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216
    [    7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010
    [    7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310
    [    7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00
    [    7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000
    [    7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8
    [    7.978290] FS:  0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000
    [    7.978292] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0
    [    8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [    8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [    8.172818] PKRU: 55555554
    [    8.172819] Call Trace:
    [    8.172823]  blk_mq_alloc_tag_set+0x12e/0x310
    [    8.264339]  scsi_add_host_with_dma.cold.9+0x30/0x245
    [    8.279302]  pqi_ctrl_init+0xacf/0xc8e [smartpqi]
    [    8.294085]  ? pqi_pci_probe+0x480/0x4c8 [smartpqi]
    [    8.309015]  pqi_pci_probe+0x480/0x4c8 [smartpqi]
    [    8.323286]  local_pci_probe+0x42/0x80
    [    8.337855]  work_for_cpu_fn+0x16/0x20
    [    8.351193]  process_one_work+0x1a7/0x360
    [    8.364462]  ? create_worker+0x1a0/0x1a0
    [    8.379252]  worker_thread+0x1ce/0x390
    [    8.392623]  ? create_worker+0x1a0/0x1a0
    [    8.406295]  kthread+0x10a/0x120
    [    8.418428]  ? set_kthread_struct+0x50/0x50
    [    8.431532]  ret_from_fork+0x1f/0x40
    [    8.444137] ---[ end trace 1bf0173d39354506 ]---
    
    Fixes: cf15c3e734e8 ("scsi: smartpqi: Add module param to disable managed ints")
    Tested-by: Yogesh Chandra Pandey <YogeshChandra.Pandey@microchip.com>
    Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
    Reviewed-by: Scott Teel <scott.teel@microchip.com>
    Reviewed-by: Mahesh Rajashekhara <mahesh.rajashekhara@microchip.com>
    Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
    Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com>
    Signed-off-by: Don Brace <don.brace@microchip.com>
    Link: https://lore.kernel.org/r/20240213162200.1875970-2-don.brace@microchip.com
    Reviewed-by: Tomas Henzl <thenzl@redhat.com>
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 758b8f5e04988e95a9493fe7882075e73c76a82d
Author: Gianmarco Lusvardi <glusvardi@posteo.net>
Date:   Tue Feb 13 23:05:46 2024 +0000

    bpf, scripts: Correct GPL license name
    
    [ Upstream commit e37243b65d528a8a9f8b9a57a43885f8e8dfc15c ]
    
    The bpf_doc script refers to the GPL as the "GNU Privacy License".
    I strongly suspect that the author wanted to refer to the GNU General
    Public License, under which the Linux kernel is released, as, to the
    best of my knowledge, there is no license named "GNU Privacy License".
    This patch corrects the license name in the script accordingly.
    
    Fixes: 56a092c89505 ("bpf: add script and prepare bpf.h for new helpers documentation")
    Signed-off-by: Gianmarco Lusvardi <glusvardi@posteo.net>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20240213230544.930018-3-glusvardi@posteo.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9409d33af61c8c7f58540aaca8abf12c0c99589
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 13 11:07:13 2024 +0100

    RDMA/srpt: fix function pointer cast warnings
    
    [ Upstream commit eb5c7465c3240151cd42a55c7ace9da0026308a1 ]
    
    clang-16 notices that srpt_qp_event() gets called through an incompatible
    pointer here:
    
    drivers/infiniband/ulp/srpt/ib_srpt.c:1815:5: error: cast from 'void (*)(struct ib_event *, struct srpt_rdma_ch *)' to 'void (*)(struct ib_event *, void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
     1815 |                 = (void(*)(struct ib_event *, void*))srpt_qp_event;
    
    Change srpt_qp_event() to use the correct prototype and adjust the
    argument inside of it.
    
    Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240213100728.458348-1-arnd@kernel.org
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f69c475c147f24003081cc6d9a77eec97b5a64d
Author: Heiko Stuebner <heiko.stuebner@cherry.de>
Date:   Fri Jan 19 11:16:56 2024 +0100

    arm64: dts: rockchip: set num-cs property for spi on px30
    
    [ Upstream commit 334bf0710c98d391f4067b72f535d6c4c84dfb6f ]
    
    The px30 has two spi controllers with two chip-selects each.
    The num-cs property is specified as the total number of chip
    selects a controllers has and is used since 2020 to find uses
    of chipselects outside that range in the Rockchip spi driver.
    
    Without the property set, the default is 1, so spi devices
    using the second chipselect will not be created.
    
    Fixes: eb1262e3cc8b ("spi: spi-rockchip: use num-cs property and ctlr->enable_gpiods")
    Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
    Reviewed-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
    Link: https://lore.kernel.org/r/20240119101656.965744-1-heiko@sntech.de
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7f31a244c753aacf40b71d01f03ca6742f81bbbc
Author: Kamal Heib <kheib@redhat.com>
Date:   Thu Feb 8 17:36:28 2024 -0500

    RDMA/qedr: Fix qedr_create_user_qp error flow
    
    [ Upstream commit 5ba4e6d5863c53e937f49932dee0ecb004c65928 ]
    
    Avoid the following warning by making sure to free the allocated
    resources in case that qedr_init_user_queue() fail.
    
    -----------[ cut here ]-----------
    WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
    ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
    CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
    Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
    RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
    RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
    RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
    RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
    RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
    R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
    R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
    FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
    Call Trace:
    <TASK>
    ? show_trace_log_lvl+0x1c4/0x2df
    ? show_trace_log_lvl+0x1c4/0x2df
    ? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
    ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    ? __warn+0x81/0x110
    ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    ? report_bug+0x10a/0x140
    ? handle_bug+0x3c/0x70
    ? exc_invalid_op+0x14/0x70
    ? asm_exc_invalid_op+0x16/0x20
    ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
    __fput+0x94/0x250
    task_work_run+0x5c/0x90
    do_exit+0x270/0x4a0
    do_group_exit+0x2d/0x90
    get_signal+0x87c/0x8c0
    arch_do_signal_or_restart+0x25/0x100
    ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]
    exit_to_user_mode_loop+0x9c/0x130
    exit_to_user_mode_prepare+0xb6/0x100
    syscall_exit_to_user_mode+0x12/0x40
    do_syscall_64+0x69/0x90
    ? syscall_exit_work+0x103/0x130
    ? syscall_exit_to_user_mode+0x22/0x40
    ? do_syscall_64+0x69/0x90
    ? syscall_exit_work+0x103/0x130
    ? syscall_exit_to_user_mode+0x22/0x40
    ? do_syscall_64+0x69/0x90
    ? do_syscall_64+0x69/0x90
    ? common_interrupt+0x43/0xa0
    entry_SYSCALL_64_after_hwframe+0x72/0xdc
    RIP: 0033:0x1470abe3ec6b
    Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.
    RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b
    RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004
    RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00
    R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358
    R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470
    </TASK>
    --[ end trace 888a9b92e04c5c97 ]--
    
    Fixes: df15856132bc ("RDMA/qedr: restructure functions that create/destroy QPs")
    Signed-off-by: Kamal Heib <kheib@redhat.com>
    Link: https://lore.kernel.org/r/20240208223628.2040841-1-kheib@redhat.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47e93d2f286eb062175ee1d89128887f0a2e8dc5
Author: Joao Martins <joao.m.martins@oracle.com>
Date:   Fri Feb 2 13:34:15 2024 +0000

    iommufd/iova_bitmap: Consider page offset for the pages to be pinned
    
    [ Upstream commit 4bbcbc6ea2fa379632a24c14cfb47aa603816ac6 ]
    
    For small bitmaps that aren't PAGE_SIZE aligned *and* that are less than
    512 pages in bitmap length, use an extra page to be able to cover the
    entire range e.g. [1M..3G] which would be iterated more efficiently in a
    single iteration, rather than two.
    
    Fixes: b058ea3ab5af ("vfio/iova_bitmap: refactor iova_bitmap_set() to better handle page boundaries")
    Link: https://lore.kernel.org/r/20240202133415.23819-10-joao.m.martins@oracle.com
    Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
    Tested-by: Avihai Horon <avihaih@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5bc02f60d278637101837c3c295021efeca74d9
Author: Joao Martins <joao.m.martins@oracle.com>
Date:   Fri Feb 2 13:34:08 2024 +0000

    iommufd/iova_bitmap: Switch iova_bitmap::bitmap to an u8 array
    
    [ Upstream commit d18411ec305728c6371806c4fb09be07016aad0b ]
    
    iova_bitmap_mapped_length() don't deal correctly with the small bitmaps
    (< 2M bitmaps) when the starting address isn't u64 aligned, leading to
    skipping a tiny part of the IOVA range. This is materialized as not
    marking data dirty that should otherwise have been.
    
    Fix that by using a u8 * in the internal state of IOVA bitmap. Most of the
    data structures use the type of the bitmap to adjust its indexes, thus
    changing the type of the bitmap decreases the granularity of the bitmap
    indexes.
    
    Fixes: b058ea3ab5af ("vfio/iova_bitmap: refactor iova_bitmap_set() to better handle page boundaries")
    Link: https://lore.kernel.org/r/20240202133415.23819-3-joao.m.martins@oracle.com
    Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
    Tested-by: Avihai Horon <avihaih@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d3a5cbc1e92a0da912578afa44506679339aaf3
Author: Joao Martins <joao.m.martins@oracle.com>
Date:   Fri Feb 2 13:34:07 2024 +0000

    iommufd/iova_bitmap: Bounds check mapped::pages access
    
    [ Upstream commit a4ab7dedaee0e39b15653c5fd0367e420739f7ef ]
    
    Dirty IOMMU hugepages reported on a base page page-size granularity can
    lead to an attempt to set dirty pages in the bitmap beyond the limits that
    are pinned.
    
    Bounds check the page index of the array we are trying to access is within
    the limits before we kmap() and return otherwise.
    
    While it is also a defensive check, this is also in preparation to defer
    setting bits (outside the mapped range) to the next iteration(s) when the
    pages become available.
    
    Fixes: b058ea3ab5af ("vfio/iova_bitmap: refactor iova_bitmap_set() to better handle page boundaries")
    Link: https://lore.kernel.org/r/20240202133415.23819-2-joao.m.martins@oracle.com
    Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
    Tested-by: Avihai Horon <avihaih@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aee4dcfe17219fe60f2821923adea98549060af8
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Sun Feb 4 16:42:07 2024 -0800

    RDMA/srpt: Support specifying the srpt_service_guid parameter
    
    [ Upstream commit fdfa083549de5d50ebf7f6811f33757781e838c0 ]
    
    Make loading ib_srpt with this parameter set work. The current behavior is
    that setting that parameter while loading the ib_srpt kernel module
    triggers the following kernel crash:
    
    BUG: kernel NULL pointer dereference, address: 0000000000000000
    Call Trace:
     <TASK>
     parse_one+0x18c/0x1d0
     parse_args+0xe1/0x230
     load_module+0x8de/0xa60
     init_module_from_file+0x8b/0xd0
     idempotent_init_module+0x181/0x240
     __x64_sys_finit_module+0x5a/0xb0
     do_syscall_64+0x5f/0xe0
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    Cc: LiHonggang <honggangli@163.com>
    Reported-by: LiHonggang <honggangli@163.com>
    Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20240205004207.17031-1-bvanassche@acm.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit edc2a9afbebda04a43dd9bb4217b1becce0efc03
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Wed Jan 31 17:38:49 2024 -0600

    RDMA/irdma: Add AE for too many RNRS
    
    [ Upstream commit 630bdb6f28ca9e5ff79e244030170ac788478332 ]
    
    Add IRDMA_AE_LLP_TOO_MANY_RNRS to the list of AE's processed as an
    abnormal asyncronous event.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Sindhu Devale <sindhu.devale@gmail.com>
    Link: https://lore.kernel.org/r/20240131233849.400285-5-sindhu.devale@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f4553096eceefe5b41e4c1bc03d9892cb903284
Author: Mustafa Ismail <mustafa.ismail@intel.com>
Date:   Wed Jan 31 17:38:48 2024 -0600

    RDMA/irdma: Set the CQ read threshold for GEN 1
    
    [ Upstream commit 666047f3ece9f991774c1fe9b223139a9ef8908d ]
    
    The CQ shadow read threshold is currently not set for GEN 2.  This could
    cause an invalid CQ overflow condition, so remove the GEN check that
    exclused GEN 1.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Sindhu Devale <sindhu.devale@intel.com>
    Link: https://lore.kernel.org/r/20240131233849.400285-4-sindhu.devale@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 429999729d4a85126cec4a1305db67d9a7774545
Author: Shiraz Saleem <shiraz.saleem@intel.com>
Date:   Wed Jan 31 17:38:47 2024 -0600

    RDMA/irdma: Validate max_send_wr and max_recv_wr
    
    [ Upstream commit ee107186bcfd25d7873258f3f75440e20f5e6416 ]
    
    Validate that max_send_wr and max_recv_wr is within the
    supported range.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Change-Id: I2fc8b10292b641fddd20b36986a9dae90a93f4be
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Sindhu Devale <sindhu.devale@intel.com>
    Link: https://lore.kernel.org/r/20240131233849.400285-3-sindhu.devale@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa
Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
Date:   Wed Jan 31 17:38:46 2024 -0600

    RDMA/irdma: Fix KASAN issue with tasklet
    
    [ Upstream commit bd97cea7b18a0a553773af806dfbfac27a7c4acb ]
    
    KASAN testing revealed the following issue assocated with freeing an IRQ.
    
    [50006.466686] Call Trace:
    [50006.466691]  <IRQ>
    [50006.489538]  dump_stack+0x5c/0x80
    [50006.493475]  print_address_description.constprop.6+0x1a/0x150
    [50006.499872]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
    [50006.505742]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
    [50006.511644]  kasan_report.cold.11+0x7f/0x118
    [50006.516572]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
    [50006.522473]  irdma_sc_process_ceq+0x483/0x790 [irdma]
    [50006.528232]  irdma_process_ceq+0xb2/0x400 [irdma]
    [50006.533601]  ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma]
    [50006.540298]  irdma_ceq_dpc+0x44/0x100 [irdma]
    [50006.545306]  tasklet_action_common.isra.14+0x148/0x2c0
    [50006.551096]  __do_softirq+0x1d0/0xaf8
    [50006.555396]  irq_exit_rcu+0x219/0x260
    [50006.559670]  irq_exit+0xa/0x20
    [50006.563320]  smp_apic_timer_interrupt+0x1bf/0x690
    [50006.568645]  apic_timer_interrupt+0xf/0x20
    [50006.573341]  </IRQ>
    
    The issue is that a tasklet could be pending on another core racing
    the delete of the irq.
    
    Fix by insuring any scheduled tasklet is killed after deleting the
    irq.
    
    Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions")
    Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
    Signed-off-by: Sindhu Devale <sindhu.devale@intel.com>
    Link: https://lore.kernel.org/r/20240131233849.400285-2-sindhu.devale@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75a64c641cf2c694556e8113e475235d7994c15e
Author: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Date:   Mon Jan 22 20:54:36 2024 -0800

    RDMA/bnxt_re: Return error for SRQ resize
    
    [ Upstream commit 3687b450c5f32e80f179ce4b09e0454da1449eac ]
    
    SRQ resize is not supported in the driver. But driver is not
    returning error from bnxt_re_modify_srq() for SRQ resize.
    
    Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters")
    Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://lore.kernel.org/r/1705985677-15551-5-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0d857ce31a6bc7a82afcdbadb8f7417d482604b
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Fri Jan 12 16:55:23 2024 +0800

    IB/hfi1: Fix a memleak in init_credit_return
    
    [ Upstream commit 809aa64ebff51eb170ee31a95f83b2d21efa32e2 ]
    
    When dma_alloc_coherent fails to allocate dd->cr_base[i].va,
    init_credit_return should deallocate dd->cr_base and
    dd->cr_base[i] that allocated before. Or those resources
    would be never freed and a memleak is triggered.
    
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Link: https://lore.kernel.org/r/20240112085523.3731720-1-alexious@zju.edu.cn
    Acked-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a6cada89ee5af2194f3ae62bebe4a821eaebe690
Author: Sohaib Nadeem <sohaib.nadeem@amd.com>
Date:   Mon Jan 29 17:33:40 2024 -0500

    Revert "drm/amd/display: increased min_dcfclk_mhz and min_fclk_mhz"
    
    commit a538dabf772c169641e151834e161e241802ab33 upstream.
    
    [why]:
    This reverts commit 2ff33c759a4247c84ec0b7815f1f223e155ba82a.
    
    The commit caused corruption when running some applications in fullscreen
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Alvin Lee <alvin.lee2@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Sohaib Nadeem <sohaib.nadeem@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71787c665d09a970b9280c285181d3a2d1bf3bb0
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 15 19:25:30 2024 +0100

    mptcp: fix lockless access in subflow ULP diag
    
    commit b8adb69a7d29c2d33eb327bca66476fb6066516b upstream.
    
    Since the introduction of the subflow ULP diag interface, the
    dump callback accessed all the subflow data with lockless.
    
    We need either to annotate all the read and write operation accordingly,
    or acquire the subflow socket lock. Let's do latter, even if slower, to
    avoid a diffstat havoc.
    
    Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace")
    Cc: stable@vger.kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e8e59af3a4aad2494e0ea23c8bda2433a338349
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Thu Feb 15 19:25:28 2024 +0100

    mptcp: add needs_id for userspace appending addr
    
    commit 6c347be62ae963b301ead8e7fa7b9973e6e0d6e1 upstream.
    
    When userspace PM requires to create an ID 0 subflow in "userspace pm
    create id 0 subflow" test like this:
    
            userspace_pm_add_sf $ns2 10.0.3.2 0
    
    An ID 1 subflow, in fact, is created.
    
    Since in mptcp_pm_nl_append_new_local_addr(), 'id 0' will be treated as
    no ID is set by userspace, and will allocate a new ID immediately:
    
         if (!e->addr.id)
                 e->addr.id = find_next_zero_bit(pernet->id_bitmap,
                                                 MPTCP_PM_MAX_ADDR_ID + 1,
                                                 1);
    
    To solve this issue, a new parameter needs_id is added for
    mptcp_userspace_pm_append_new_local_addr() to distinguish between
    whether userspace PM has set an ID 0 or whether userspace PM has
    not set any address.
    
    needs_id is true in mptcp_userspace_pm_get_local_id(), but false in
    mptcp_pm_nl_announce_doit() and mptcp_pm_nl_subflow_create_doit().
    
    Fixes: e5ed101a6028 ("mptcp: userspace pm allow creating id 0 subflow")
    Cc: stable@vger.kernel.org
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42a841a84ffd84f8166b9b4c5897a5f30feb7e1c
Author: Geliang Tang <geliang@kernel.org>
Date:   Fri Apr 14 17:47:06 2023 +0200

    mptcp: make userspace_pm_append_new_local_addr static
    
    commit aa5887dca2d236fc50000e27023d4d78dce3af30 upstream.
    
    mptcp_userspace_pm_append_new_local_addr() has always exclusively been
    used in pm_userspace.c since its introduction in
    commit 4638de5aefe5 ("mptcp: handle local addrs announced by userspace PMs").
    
    So make it static.
    
    Signed-off-by: Geliang Tang <geliang.tang@suse.com>
    Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f414a56b369129cfdac6ecaf9899f9807a264aa
Author: Xu Yang <xu.yang_2@nxp.com>
Date:   Mon Jan 29 17:37:39 2024 +0800

    usb: roles: don't get/set_role() when usb_role_switch is unregistered
    
    commit b787a3e781759026a6212736ef8e52cf83d1821a upstream.
    
    There is a possibility that usb_role_switch device is unregistered before
    the user put usb_role_switch. In this case, the user may still want to
    get/set_role() since the user can't sense the changes of usb_role_switch.
    
    This will add a flag to show if usb_role_switch is already registered and
    avoid unwanted behaviors.
    
    Fixes: fde0aa6c175a ("usb: common: Small class for USB role switches")
    cc: stable@vger.kernel.org
    Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240129093739.2371530-2-xu.yang_2@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0158216805ca7e498d07de38840d2732166ae5fa
Author: Xu Yang <xu.yang_2@nxp.com>
Date:   Mon Jan 29 17:37:38 2024 +0800

    usb: roles: fix NULL pointer issue when put module's reference
    
    commit 1c9be13846c0b2abc2480602f8ef421360e1ad9e upstream.
    
    In current design, usb role class driver will get usb_role_switch parent's
    module reference after the user get usb_role_switch device and put the
    reference after the user put the usb_role_switch device. However, the
    parent device of usb_role_switch may be removed before the user put the
    usb_role_switch. If so, then, NULL pointer issue will be met when the user
    put the parent module's reference.
    
    This will save the module pointer in structure of usb_role_switch. Then,
    we don't need to find module by iterating long relations.
    
    Fixes: 5c54fcac9a9d ("usb: roles: Take care of driver module reference counting")
    cc: stable@vger.kernel.org
    Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240129093739.2371530-1-xu.yang_2@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 35b604a37ec70d68b19dafd10bbacf1db505c9ca
Author: Krishna Kurapati <quic_kriskura@quicinc.com>
Date:   Mon Feb 5 13:16:50 2024 +0530

    usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
    
    commit 76c51146820c5dac629f21deafab0a7039bc3ccd upstream.
    
    It is observed sometimes when tethering is used over NCM with Windows 11
    as host, at some instances, the gadget_giveback has one byte appended at
    the end of a proper NTB. When the NTB is parsed, unwrap call looks for
    any leftover bytes in SKB provided by u_ether and if there are any pending
    bytes, it treats them as a separate NTB and parses it. But in case the
    second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that
    were parsed properly in the first NTB and saved in rx_list are dropped.
    
    Adding a few custom traces showed the following:
    [002] d..1  7828.532866: dwc3_gadget_giveback: ep1out:
    req 000000003868811a length 1025/16384 zsI ==> 0
    [002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025
    [002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
    [002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67
    [002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400
    [002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10
    [002] d..1  7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames
    
    In this case, the giveback is of 1025 bytes and block length is 1024.
    The rest 1 byte (which is 0x00) won't be parsed resulting in drop of
    all datagrams in rx_list.
    
    Same is case with packets of size 2048:
    [002] d..1  7828.557948: dwc3_gadget_giveback: ep1out:
    req 0000000011dfd96e length 2049/16384 zsI ==> 0
    [002] d..1  7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
    [002] d..1  7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
    
    Lecroy shows one byte coming in extra confirming that the byte is coming
    in from PC:
    
     Transfer 2959 - Bytes Transferred(1025)  Timestamp((18.524 843 590)
     - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)
     --- Packet 4063861
           Data(1024 bytes)
           Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)
     --- Packet 4063863
           Data(1 byte)
           Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)
    
    According to Windows driver, no ZLP is needed if wBlockLength is non-zero,
    because the non-zero wBlockLength has already told the function side the
    size of transfer to be expected. However, there are in-market NCM devices
    that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.
    To deal with such devices, it pads an extra 0 at end so the transfer is no
    longer multiple of wMaxPacketSize.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 9f6ce4240a2b ("usb: gadget: f_ncm.c added")
    Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Reviewed-by: Maciej Żenczykowski <maze@google.com>
    Link: https://lore.kernel.org/r/20240205074650.200304-1-quic_kriskura@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a52b694b066f299d8b9800854a8503457a8b64c
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Feb 2 10:42:17 2024 -0500

    usb: cdns3: fix memory double free when handle zero packet
    
    commit 5fd9e45f1ebcd57181358af28506e8a661a260b3 upstream.
    
    829  if (request->complete) {
    830          spin_unlock(&priv_dev->lock);
    831          usb_gadget_giveback_request(&priv_ep->endpoint,
    832                                    request);
    833          spin_lock(&priv_dev->lock);
    834  }
    835
    836  if (request->buf == priv_dev->zlp_buf)
    837      cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);
    
    Driver append an additional zero packet request when queue a packet, which
    length mod max packet size is 0. When transfer complete, run to line 831,
    usb_gadget_giveback_request() will free this requestion. 836 condition is
    true, so cdns3_gadget_ep_free_request() free this request again.
    
    Log:
    
    [ 1920.140696][  T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]
    [ 1920.140696][  T150]
    [ 1920.151837][  T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):
    [ 1920.159082][  T150]  cdns3_gadget_giveback+0x134/0x2c0 [cdns3]
    [ 1920.164988][  T150]  cdns3_transfer_completed+0x438/0x5f8 [cdns3]
    
    Add check at line 829, skip call usb_gadget_giveback_request() if it is
    additional zero length packet request. Needn't call
    usb_gadget_giveback_request() because it is allocated in this driver.
    
    Cc: stable@vger.kernel.org
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Reviewed-by: Roger Quadros <rogerq@kernel.org>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/20240202154217.661867-2-Frank.Li@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2134e9906e17b1e5284300fab547869ebacfd7d9
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Feb 2 10:42:16 2024 -0500

    usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()
    
    commit cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6 upstream.
    
      ...
      cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request);
      list_del_init(&priv_req->list);
      ...
    
    'priv_req' actually free at cdns3_gadget_ep_free_request(). But
    list_del_init() use priv_req->list after it.
    
    [ 1542.642868][  T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4
    [ 1542.642868][  T534]
    [ 1542.653162][  T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):
    [ 1542.660311][  T534]  __list_del_entry_valid+0x10/0xd4
    [ 1542.665375][  T534]  cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]
    [ 1542.671571][  T534]  usb_ep_disable+0x44/0xe4
    [ 1542.675948][  T534]  ffs_func_eps_disable+0x64/0xc8
    [ 1542.680839][  T534]  ffs_func_set_alt+0x74/0x368
    [ 1542.685478][  T534]  ffs_func_disable+0x18/0x28
    
    Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this
    problem.
    
    Cc: stable@vger.kernel.org
    Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Reviewed-by: Roger Quadros <rogerq@kernel.org>
    Acked-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/20240202154217.661867-1-Frank.Li@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c66a8008489bddef8d9bab3545a7d868d95a8b38
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Thu Feb 15 13:16:09 2024 +0100

    usb: cdnsp: fixed issue with incorrect detecting CDNSP family controllers
    
    commit 47625b018c6bc788bc10dd654c82696eb0a5ef11 upstream.
    
    Cadence have several controllers from 0x000403xx family but current
    driver suuport detecting only one with DID equal 0x0004034E.
    It causes that if someone uses different CDNSP controller then driver
    will use incorrect version and register space.
    Patch fix this issue.
    
    cc: stable@vger.kernel.org
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Link: https://lore.kernel.org/r/20240215121609.259772-1-pawell@cadence.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 748cee4417f68b09ca8dbf8b702803ad2d082010
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Tue Feb 6 11:40:18 2024 +0100

    usb: cdnsp: blocked some cdns3 specific code
    
    commit 18a6be674306c9acb05c08e5c3fd376ef50a917c upstream.
    
    host.c file has some parts of code that were introduced for CDNS3 driver
    and should not be used with CDNSP driver.
    This patch blocks using these parts of codes by CDNSP driver.
    These elements include:
    - xhci_plat_cdns3_xhci object
    - cdns3 specific XECP_PORT_CAP_REG register
    - cdns3 specific XECP_AUX_CTRL_REG1 register
    
    cc: stable@vger.kernel.org
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Link: https://lore.kernel.org/r/20240206104018.48272-1-pawell@cadence.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4dc87908b1836ac7194fd4bd2c89ff3d79ebc075
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Fri Feb 16 00:41:02 2024 +0000

    usb: dwc3: gadget: Don't disconnect if not started
    
    commit b191a18cb5c47109ca696370a74a5062a70adfd0 upstream.
    
    Don't go through soft-disconnection sequence if the controller hasn't
    started. Otherwise, there will be timeout and warning reports from the
    soft-disconnection flow.
    
    Cc: stable@vger.kernel.org
    Fixes: 61a348857e86 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend")
    Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Closes: https://lore.kernel.org/linux-usb/20240215233536.7yejlj3zzkl23vjd@synopsys.com/T/#mb0661cd5f9272602af390c18392b9a36da4f96e6
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/e3be9b929934e0680a6f4b8f6eb11b18ae9c7e07.1708043922.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4c7e4b1b0249598d2093d09be5a286f81fc4a36
Author: Lino Sanfilippo <l.sanfilippo@kunbus.com>
Date:   Fri Feb 16 23:47:08 2024 +0100

    serial: amba-pl011: Fix DMA transmission in RS485 mode
    
    commit 3b69e32e151bc4a4e3c785cbdb1f918d5ee337ed upstream.
    
    When DMA is used in RS485 mode make sure that the UARTs tx section is
    enabled before the DMA buffers are queued for transmission.
    
    Cc: stable@vger.kernel.org
    Fixes: 8d479237727c ("serial: amba-pl011: add RS485 support")
    Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
    Link: https://lore.kernel.org/r/20240216224709.9928-2-l.sanfilippo@kunbus.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9d24262535360fceebacaf93eaba281d4135c52
Author: Sandeep Dhavale <dhavale@google.com>
Date:   Wed Feb 21 13:03:47 2024 -0800

    erofs: fix refcount on the metabuf used for inode lookup
    
    commit 56ee7db31187dc36d501622cb5f1415e88e01c2a upstream.
    
    In erofs_find_target_block() when erofs_dirnamecmp() returns 0,
    we do not assign the target metabuf. This causes the caller
    erofs_namei()'s erofs_put_metabuf() at the end to be not effective
    leaving the refcount on the page.
    As the page from metabuf (buf->page) is never put, such page cannot be
    migrated or reclaimed. Fix it now by putting the metabuf from
    previous loop and assigning the current metabuf to target before
    returning so caller erofs_namei() can do the final put as it was
    intended.
    
    Fixes: 500edd095648 ("erofs: use meta buffers for inode lookup")
    Cc: <stable@vger.kernel.org> # 5.18+
    Signed-off-by: Sandeep Dhavale <dhavale@google.com>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Link: https://lore.kernel.org/r/20240221210348.3667795-1-dhavale@google.com
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 943c8b1fcc86210ac7a62cbba77360936554477c
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sat Feb 24 14:48:03 2024 +0100

    dm-integrity, dm-verity: reduce stack usage for recheck
    
    commit 66ad2fbcdbeab0edfd40c5d94f32f053b98c2320 upstream.
    
    The newly added integrity_recheck() function has another larger stack
    allocation, just like its caller integrity_metadata(). When it gets
    inlined, the combination of the two exceeds the warning limit for 32-bit
    architectures and possibly risks an overflow when this is called from
    a deep call chain through a file system:
    
    drivers/md/dm-integrity.c:1767:13: error: stack frame size (1048) exceeds limit (1024) in 'integrity_metadata' [-Werror,-Wframe-larger-than]
     1767 | static void integrity_metadata(struct work_struct *w)
    
    Since the caller at this point is done using its checksum buffer,
    just reuse the same buffer in the new function to avoid the double
    allocation.
    
    [Mikulas: add "noinline" to integrity_recheck and verity_recheck.
    These functions are only called on error, so they shouldn't bloat the
    stack frame or code size of the caller.]
    
    Fixes: c88f5e553fe3 ("dm-integrity: recheck the integrity tag after a failure")
    Fixes: 9177f3c0dea6 ("dm-verity: recheck the hash after a failure")
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 545a94ffc29a4afb3bec7cbb4b830cc9c35fad7a
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Mon Aug 14 13:44:30 2023 +0200

    x86/alternative: Make custom return thunk unconditional
    
    Upstream commit: 095b8303f3835c68ac4a8b6d754ca1c3b6230711
    
    There is infrastructure to rewrite return thunks to point to any
    random thunk one desires, unwrap that from CALL_THUNKS, which up to
    now was the sole user of that.
    
      [ bp: Make the thunks visible on 32-bit and add ifdeffery for the
        32-bit builds. ]
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/20230814121148.775293785@infradead.org
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b012dcf39d9e79f9a71aa72b485c740aba84b47f
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Sat Feb 24 12:01:34 2024 +0100

    Revert "x86/alternative: Make custom return thunk unconditional"
    
    This reverts commit 53ebbe1c8c02aa7b7f072dd2f96bca4faa1daa59.
    
    Revert the backport of upstream commit:
    
      095b8303f383 ("x86/alternative: Make custom return thunk unconditional")
    
    in order to backport the full version now that
    
      770ae1b70952 ("x86/returnthunk: Allow different return thunks")
    
    has been backported.
    
    Revert it here so that the build breakage is kept at minimum.
    
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1221b8ea25cc8db5096fa328b835b8b6fdb6180b
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Thu Sep 15 13:11:25 2022 +0200

    x86/returnthunk: Allow different return thunks
    
    Upstream commit: 770ae1b709528a6a173b5c7b183818ee9b45e376
    
    In preparation for call depth tracking on Intel SKL CPUs, make it possible
    to patch in a SKL specific return thunk.
    
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20220915111147.680469665@infradead.org
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 786f089086b505372fb3f4f008d57e7845fff0d8
Author: Nikita Shubin <nikita.shubin@maquefel.me>
Date:   Mon Feb 5 11:23:34 2024 +0100

    ARM: ep93xx: Add terminator to gpiod_lookup_table
    
    commit fdf87a0dc26d0550c60edc911cda42f9afec3557 upstream.
    
    Without the terminator, if a con_id is passed to gpio_find() that
    does not exist in the lookup table the function will not stop looping
    correctly, and eventually cause an oops.
    
    Cc: stable@vger.kernel.org
    Fixes: b2e63555592f ("i2c: gpio: Convert to use descriptors")
    Reported-by: Andy Shevchenko <andriy.shevchenko@intel.com>
    Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Link: https://lore.kernel.org/r/20240205102337.439002-1-alexander.sverdlin@gmail.com
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13cd1daeea848614e585b2c6ecc11ca9c8ab2500
Author: Tom Parkin <tparkin@katalix.com>
Date:   Tue Feb 20 12:21:56 2024 +0000

    l2tp: pass correct message length to ip6_append_data
    
    commit 359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79 upstream.
    
    l2tp_ip6_sendmsg needs to avoid accounting for the transport header
    twice when splicing more data into an already partially-occupied skbuff.
    
    To manage this, we check whether the skbuff contains data using
    skb_queue_empty when deciding how much data to append using
    ip6_append_data.
    
    However, the code which performed the calculation was incorrect:
    
         ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0;
    
    ...due to C operator precedence, this ends up setting ulen to
    transhdrlen for messages with a non-zero length, which results in
    corrupted packets on the wire.
    
    Add parentheses to correct the calculation in line with the original
    intent.
    
    Fixes: 9d4c75800f61 ("ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()")
    Cc: David Howells <dhowells@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Tom Parkin <tparkin@katalix.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240220122156.43131-1-tparkin@katalix.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a19e0042bf14c9f5386b71d17089e2c6fc7dded
Author: Vidya Sagar <vidyas@nvidia.com>
Date:   Mon Jan 15 19:26:49 2024 +0530

    PCI/MSI: Prevent MSI hardware interrupt number truncation
    
    commit db744ddd59be798c2627efbfc71f707f5a935a40 upstream.
    
    While calculating the hardware interrupt number for a MSI interrupt, the
    higher bits (i.e. from bit-5 onwards a.k.a domain_nr >= 32) of the PCI
    domain number gets truncated because of the shifted value casting to return
    type of pci_domain_nr() which is 'int'. This for example is resulting in
    same hardware interrupt number for devices 0019:00:00.0 and 0039:00:00.0.
    
    To address this cast the PCI domain number to 'irq_hw_number_t' before left
    shifting it to calculate the hardware interrupt number.
    
    Please note that this fixes the issue only on 64-bit systems and doesn't
    change the behavior for 32-bit systems i.e. the 32-bit systems continue to
    have the issue. Since the issue surfaces only if there are too many PCIe
    controllers in the system which usually is the case in modern server
    systems and they don't tend to run 32-bit kernels.
    
    Fixes: 3878eaefb89a ("PCI/MSI: Enhance core to support hierarchy irqdomain")
    Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Shanker Donthineni <sdonthineni@nvidia.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240115135649.708536-1-vidyas@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e90211b1f7ace2a57838343c2a2847cecebead7d
Author: Nam Cao <namcao@linutronix.de>
Date:   Wed Jan 31 09:19:33 2024 +0100

    irqchip/sifive-plic: Enable interrupt if needed before EOI
    
    commit 9c92006b896c767218aabe8947b62026a571cfd0 upstream.
    
    RISC-V PLIC cannot "end-of-interrupt" (EOI) disabled interrupts, as
    explained in the description of Interrupt Completion in the PLIC spec:
    
    "The PLIC signals it has completed executing an interrupt handler by
    writing the interrupt ID it received from the claim to the claim/complete
    register. The PLIC does not check whether the completion ID is the same
    as the last claim ID for that target. If the completion ID does not match
    an interrupt source that *is currently enabled* for the target, the
    completion is silently ignored."
    
    Commit 69ea463021be ("irqchip/sifive-plic: Fixup EOI failed when masked")
    ensured that EOI is successful by enabling interrupt first, before EOI.
    
    Commit a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask
    operations") removed the interrupt enabling code from the previous
    commit, because it assumes that interrupt should already be enabled at the
    point of EOI.
    
    However, this is incorrect: there is a window after a hart claiming an
    interrupt and before irq_desc->lock getting acquired, interrupt can be
    disabled during this window. Thus, EOI can be invoked while the interrupt
    is disabled, effectively nullify this EOI. This results in the interrupt
    never gets asserted again, and the device who uses this interrupt appears
    frozen.
    
    Make sure that interrupt is really enabled before EOI.
    
    Fixes: a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations")
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Palmer Dabbelt <palmer@dabbelt.com>
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: Samuel Holland <samuel@sholland.org>
    Cc: Marc Zyngier <maz@kernel.org>
    Cc: Guo Ren <guoren@kernel.org>
    Cc: linux-riscv@lists.infradead.org
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240131081933.144512-1-namcao@linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75eaa3666e2cce5656e8f0564a845a5da5a9617a
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Mon Feb 19 18:58:06 2024 +0000

    irqchip/gic-v3-its: Do not assume vPE tables are preallocated
    
    commit ec4308ecfc887128a468f03fb66b767559c57c23 upstream.
    
    The GIC/ITS code is designed to ensure to pick up any preallocated LPI
    tables on the redistributors, as enabling LPIs is a one-way switch. There
    is no such restriction for vLPIs, and for GICv4.1 it is expected to
    allocate a new vPE table at boot.
    
    This works as intended when initializing an ITS, however when setting up a
    redistributor in cpu_init_lpis() the early return for preallocated RD
    tables skips straight past the GICv4 setup. This all comes to a head when
    trying to kexec() into a new kernel, as the new kernel silently fails to
    set up GICv4, leading to a complete loss of SGIs and LPIs for KVM VMs.
    
    Slap a band-aid on the problem by ensuring its_cpu_init_lpis() always
    initializes GICv4 on the way out, even if the other RD tables were
    preallocated.
    
    Fixes: 6479450f72c1 ("irqchip/gic-v4: Fix occasional VLPI drop")
    Reported-by: George Cherian <gcherian@marvell.com>
    Co-developed-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240219185809.286724-2-oliver.upton@linux.dev
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62f361bfea60c6afc3df09c1ad4152e6507f6f47
Author: zhenwei pi <pizhenwei@bytedance.com>
Date:   Tue Jan 30 19:27:40 2024 +0800

    crypto: virtio/akcipher - Fix stack overflow on memcpy
    
    commit c0ec2a712daf133d9996a8a1b7ee2d4996080363 upstream.
    
    sizeof(struct virtio_crypto_akcipher_session_para) is less than
    sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from
    stack variable leads stack overflow. Clang reports this issue by
    commands:
    make -j CC=clang-14 mrproper >/dev/null 2>&1
    make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1
    make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/
      virtio_crypto_akcipher_algs.o
    
    Fixes: 59ca6c93387d ("virtio-crypto: implement RSA algorithm")
    Link: https://lore.kernel.org/all/0a194a79-e3a3-45e7-be98-83abd3e1cb7e@roeck-us.net/
    Cc: <stable@vger.kernel.org>
    Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
    Tested-by: Nathan Chancellor <nathan@kernel.org> # build
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3963f16cc7643b461271989b712329520374ad2a
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Wed Feb 14 19:27:33 2024 +0300

    gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
    
    commit 136cfaca22567a03bbb3bf53a43d8cb5748b80ec upstream.
    
    The gtp_net_ops pernet operations structure for the subsystem must be
    registered before registering the generic netlink family.
    
    Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
    
    general protection fault, probably for non-canonical address
    0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI
    KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
    CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
    RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
    Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
          df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
          3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
    RSP: 0018:ffff888014107220 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
    R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000
    FS:  00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? show_regs+0x90/0xa0
     ? die_addr+0x50/0xd0
     ? exc_general_protection+0x148/0x220
     ? asm_exc_general_protection+0x22/0x30
     ? gtp_genl_dump_pdp+0x1be/0x800 [gtp]
     ? __alloc_skb+0x1dd/0x350
     ? __pfx___alloc_skb+0x10/0x10
     genl_dumpit+0x11d/0x230
     netlink_dump+0x5b9/0xce0
     ? lockdep_hardirqs_on_prepare+0x253/0x430
     ? __pfx_netlink_dump+0x10/0x10
     ? kasan_save_track+0x10/0x40
     ? __kasan_kmalloc+0x9b/0xa0
     ? genl_start+0x675/0x970
     __netlink_dump_start+0x6fc/0x9f0
     genl_family_rcv_msg_dumpit+0x1bb/0x2d0
     ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10
     ? genl_op_from_small+0x2a/0x440
     ? cap_capable+0x1d0/0x240
     ? __pfx_genl_start+0x10/0x10
     ? __pfx_genl_dumpit+0x10/0x10
     ? __pfx_genl_done+0x10/0x10
     ? security_capable+0x9d/0xe0
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
    Link: https://lore.kernel.org/r/20240214162733.34214-1-kovalev@altlinux.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3ac3624a74cf251cf7c32b6b29231d4696e9291d
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Wed Feb 21 09:27:31 2024 +0000

    KVM: arm64: vgic-its: Test for valid IRQ in its_sync_lpi_pending_table()
    
    commit 8d3a7dfb801d157ac423261d7cd62c33e95375f8 upstream.
    
    vgic_get_irq() may not return a valid descriptor if there is no ITS that
    holds a valid translation for the specified INTID. If that is the case,
    it is safe to silently ignore it and continue processing the LPI pending
    table.
    
    Cc: stable@vger.kernel.org
    Fixes: 33d3bc9556a7 ("KVM: arm64: vgic-its: Read initial LPI pending table")
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Link: https://lore.kernel.org/r/20240221092732.4126848-2-oliver.upton@linux.dev
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72fdbc728c339413f2fee7c042ebc124d6b223d2
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Wed Feb 21 09:27:32 2024 +0000

    KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handler
    
    commit 85a71ee9a0700f6c18862ef3b0011ed9dad99aca upstream.
    
    It is possible that an LPI mapped in a different ITS gets unmapped while
    handling the MOVALL command. If that is the case, there is no state that
    can be migrated to the destination. Silently ignore it and continue
    migrating other LPIs.
    
    Cc: stable@vger.kernel.org
    Fixes: ff9c114394aa ("KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE")
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Link: https://lore.kernel.org/r/20240221092732.4126848-3-oliver.upton@linux.dev
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b2ff10390b19a2364af622b6666b690443f9f3f
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu Feb 1 17:25:51 2024 +0800

    md: Fix missing release of 'active_io' for flush
    
    commit 855678ed8534518e2b428bcbcec695de9ba248e8 upstream.
    
    submit_flushes
     atomic_set(&mddev->flush_pending, 1);
     rdev_for_each_rcu(rdev, mddev)
      atomic_inc(&mddev->flush_pending);
      bi->bi_end_io = md_end_flush
      submit_bio(bi);
                            /* flush io is done first */
                            md_end_flush
                             if (atomic_dec_and_test(&mddev->flush_pending))
                              percpu_ref_put(&mddev->active_io)
                              -> active_io is not released
    
     if (atomic_dec_and_test(&mddev->flush_pending))
      -> missing release of active_io
    
    For consequence, mddev_suspend() will wait for 'active_io' to be zero
    forever.
    
    Fix this problem by releasing 'active_io' in submit_flushes() if
    'flush_pending' is decreased to zero.
    
    Fixes: fa2bbff7b0b4 ("md: synchronize flush io with array reconfiguration")
    Cc: stable@vger.kernel.org # v6.1+
    Reported-by: Blazej Kucman <blazej.kucman@linux.intel.com>
    Closes: https://lore.kernel.org/lkml/20240130172524.0000417b@linux.intel.com/
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240201092559.910982-7-yukuai1@huaweicloud.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8b218e2f0a27a9f09428b1847b4580640b9d1e58
Author: Baokun Li <libaokun1@huawei.com>
Date:   Sat Feb 17 16:14:31 2024 +0800

    cachefiles: fix memory leak in cachefiles_add_cache()
    
    commit e21a2f17566cbd64926fb8f16323972f7a064444 upstream.
    
    The following memory leak was reported after unbinding /dev/cachefiles:
    
    ==================================================================
    unreferenced object 0xffff9b674176e3c0 (size 192):
      comm "cachefilesd2", pid 680, jiffies 4294881224
      hex dump (first 32 bytes):
        01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace (crc ea38a44b):
        [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
        [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0
        [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120
        [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
        [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0
        [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
        [<ffffffff8ebc5069>] ksys_write+0x69/0xf0
        [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
        [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
    ==================================================================
    
    Put the reference count of cache_cred in cachefiles_daemon_unbind() to
    fix the problem. And also put cache_cred in cachefiles_add_cache() error
    branch to avoid memory leaks.
    
    Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem")
    CC: stable@vger.kernel.org
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Link: https://lore.kernel.org/r/20240217081431.796809-1-libaokun1@huawei.com
    Acked-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e7fc40377ec28d15a46cf59c413616fe9a78d57
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Feb 12 13:06:07 2024 +0100

    platform/x86: touchscreen_dmi: Allow partial (prefix) matches for ACPI names
    
    commit dbcbfd662a725641d118fb3ae5ffb7be4e3d0fb0 upstream.
    
    On some devices the ACPI name of the touchscreen is e.g. either
    MSSL1680:00 or MSSL1680:01 depending on the BIOS version.
    
    This happens for example on the "Chuwi Hi8 Air" tablet where the initial
    commit's ts_data uses "MSSL1680:00" but the tablets from the github issue
    and linux-hardware.org probe linked below both use "MSSL1680:01".
    
    Replace the strcmp() match on ts_data->acpi_name with a strstarts()
    check to allow using a partial match on just the ACPI HID of "MSSL1680"
    and change the ts_data->acpi_name for the "Chuwi Hi8 Air" accordingly
    to fix the touchscreen not working on models where it is "MSSL1680:01".
    
    Note this drops the length check for I2C_NAME_SIZE. This never was
    necessary since the ACPI names used are never more then 11 chars and
    I2C_NAME_SIZE is 20 so the replaced strncmp() would always stop long
    before reaching I2C_NAME_SIZE.
    
    Link: https://linux-hardware.org/?computer=AC4301C0542A
    Fixes: bbb97d728f77 ("platform/x86: touchscreen_dmi: Add info for the Chuwi Hi8 Air tablet")
    Closes: https://github.com/onitake/gsl-firmware/issues/91
    Cc: stable@vger.kernel.org
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240212120608.30469-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fff39f496265edd728457ac39030c52a2113aa13
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Feb 16 21:33:00 2024 +0100

    platform/x86: intel-vbtn: Stop calling "VBDL" from notify_handler
    
    commit 84c16d01ff219bc0a5dca5219db6b8b86a6854fb upstream.
    
    Commit 14c200b7ca46 ("platform/x86: intel-vbtn: Fix missing
    tablet-mode-switch events") causes 2 issues on the ThinkPad X1 Tablet Gen2:
    
    1. The ThinkPad will wake up immediately from suspend
    2. When put in tablet mode SW_TABLET_MODE reverts to 0 after about 1 second
    
    Both these issues are caused by the "VBDL" ACPI method call added
    at the end of the notify_handler.
    
    And it never became entirely clear if this call is even necessary to fix
    the issue of missing tablet-mode-switch events on the Dell Inspiron 7352.
    
    Drop the "VBDL" ACPI method call again to fix the 2 issues this is
    causing on the ThinkPad X1 Tablet Gen2.
    
    Fixes: 14c200b7ca46 ("platform/x86: intel-vbtn: Fix missing tablet-mode-switch events")
    Reported-by: Alexander Kobel <a-kobel@a-kobel.de>
    Closes: https://lore.kernel.org/platform-driver-x86/295984ce-bd4b-49bd-adc5-ffe7c898d7f0@a-kobel.de/
    Cc: regressions@lists.linux.dev
    Cc: Arnold Gozum <arngozum@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Alexander Kobel <a-kobel@a-kobel.de>
    Link: https://lore.kernel.org/r/20240216203300.245826-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19e5dc2e6bf7cb2160bbb996f18f3bfb4621e770
Author: Johannes Weiner <hannes@cmpxchg.org>
Date:   Tue Feb 13 03:16:34 2024 -0500

    mm: memcontrol: clarify swapaccount=0 deprecation warning
    
    commit 118642d7f606fc9b9c92ee611275420320290ffb upstream.
    
    The swapaccount deprecation warning is throwing false positives.  Since we
    deprecated the knob and defaulted to enabling, the only reports we've been
    getting are from folks that set swapaccount=1.  While this is a nice
    affirmation that always-enabling was the right choice, we certainly don't
    want to warn when users request the supported mode.
    
    Only warn when disabling is requested, and clarify the warning.
    
    [colin.i.king@gmail.com: spelling: "commdandline" -> "commandline"]
      Link: https://lkml.kernel.org/r/20240215090544.1649201-1-colin.i.king@gmail.com
    Link: https://lkml.kernel.org/r/20240213081634.3652326-1-hannes@cmpxchg.org
    Fixes: b25806dcd3d5 ("mm: memcontrol: deprecate swapaccounting=0 mode")
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Reported-by: "Jonas Schäfer" <jonas@wielicki.name>
    Reported-by: Narcis Garcia <debianlists@actiu.net>
    Suggested-by: Yosry Ahmed <yosryahmed@google.com>
    Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
    Reviewed-by: Yosry Ahmed <yosryahmed@google.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Shakeel Butt <shakeelb@google.com>
    Cc: Roman Gushchin <roman.gushchin@linux.dev>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c815c3a48349842cc43a4101f7387af8904a0fb
Author: SeongJae Park <sj@kernel.org>
Date:   Fri Feb 16 11:40:25 2024 -0800

    mm/damon/lru_sort: fix quota status loss due to online tunings
    
    commit 13d0599ab3b2ff17f798353f24bcbef1659d3cfc upstream.
    
    For online parameters change, DAMON_LRU_SORT creates new schemes based on
    latest values of the parameters and replaces the old schemes with the new
    one.  When creating it, the internal status of the quotas of the old
    schemes is not preserved.  As a result, charging of the quota starts from
    zero after the online tuning.  The data that collected to estimate the
    throughput of the scheme's action is also reset, and therefore the
    estimation should start from the scratch again.  Because the throughput
    estimation is being used to convert the time quota to the effective size
    quota, this could result in temporal time quota inaccuracy.  It would be
    recovered over time, though.  In short, the quota accuracy could be
    temporarily degraded after online parameters update.
    
    Fix the problem by checking the case and copying the internal fields for
    the status.
    
    Link: https://lkml.kernel.org/r/20240216194025.9207-3-sj@kernel.org
    Fixes: 40e983cca927 ("mm/damon: introduce DAMON-based LRU-lists Sorting")
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Cc: <stable@vger.kernel.org>    [6.0+]
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dedda77d4493f3e92e414b272bfa60f1f51ed95
Author: Kairui Song <kasong@tencent.com>
Date:   Wed Feb 7 02:25:59 2024 +0800

    mm/swap: fix race when skipping swapcache
    
    commit 13ddaf26be324a7f951891ecd9ccd04466d27458 upstream.
    
    When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads
    swapin the same entry at the same time, they get different pages (A, B).
    Before one thread (T0) finishes the swapin and installs page (A) to the
    PTE, another thread (T1) could finish swapin of page (B), swap_free the
    entry, then swap out the possibly modified page reusing the same entry.
    It breaks the pte_same check in (T0) because PTE value is unchanged,
    causing ABA problem.  Thread (T0) will install a stalled page (A) into the
    PTE and cause data corruption.
    
    One possible callstack is like this:
    
    CPU0                                 CPU1
    ----                                 ----
    do_swap_page()                       do_swap_page() with same entry
    <direct swapin path>                 <direct swapin path>
    <alloc page A>                       <alloc page B>
    swap_read_folio() <- read to page A  swap_read_folio() <- read to page B
    <slow on later locks or interrupt>   <finished swapin first>
    ...                                  set_pte_at()
                                         swap_free() <- entry is free
                                         <write to page B, now page A stalled>
                                         <swap out page B to same swap entry>
    pte_same() <- Check pass, PTE seems
                  unchanged, but page A
                  is stalled!
    swap_free() <- page B content lost!
    set_pte_at() <- staled page A installed!
    
    And besides, for ZRAM, swap_free() allows the swap device to discard the
    entry content, so even if page (B) is not modified, if swap_read_folio()
    on CPU0 happens later than swap_free() on CPU1, it may also cause data
    loss.
    
    To fix this, reuse swapcache_prepare which will pin the swap entry using
    the cache flag, and allow only one thread to swap it in, also prevent any
    parallel code from putting the entry in the cache.  Release the pin after
    PT unlocked.
    
    Racers just loop and wait since it's a rare and very short event.  A
    schedule_timeout_uninterruptible(1) call is added to avoid repeated page
    faults wasting too much CPU, causing livelock or adding too much noise to
    perf statistics.  A similar livelock issue was described in commit
    029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead")
    
    Reproducer:
    
    This race issue can be triggered easily using a well constructed
    reproducer and patched brd (with a delay in read path) [1]:
    
    With latest 6.8 mainline, race caused data loss can be observed easily:
    $ gcc -g -lpthread test-thread-swap-race.c && ./a.out
      Polulating 32MB of memory region...
      Keep swapping out...
      Starting round 0...
      Spawning 65536 workers...
      32746 workers spawned, wait for done...
      Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss!
      Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss!
      Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss!
      Round 0 Failed, 15 data loss!
    
    This reproducer spawns multiple threads sharing the same memory region
    using a small swap device.  Every two threads updates mapped pages one by
    one in opposite direction trying to create a race, with one dedicated
    thread keep swapping out the data out using madvise.
    
    The reproducer created a reproduce rate of about once every 5 minutes, so
    the race should be totally possible in production.
    
    After this patch, I ran the reproducer for over a few hundred rounds and
    no data loss observed.
    
    Performance overhead is minimal, microbenchmark swapin 10G from 32G
    zram:
    
    Before:     10934698 us
    After:      11157121 us
    Cached:     13155355 us (Dropping SWP_SYNCHRONOUS_IO flag)
    
    [kasong@tencent.com: v4]
      Link: https://lkml.kernel.org/r/20240219082040.7495-1-ryncsn@gmail.com
    Link: https://lkml.kernel.org/r/20240206182559.32264-1-ryncsn@gmail.com
    Fixes: 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device")
    Reported-by: "Huang, Ying" <ying.huang@intel.com>
    Closes: https://lore.kernel.org/lkml/87bk92gqpx.fsf_-_@yhuang6-desk2.ccr.corp.intel.com/
    Link: https://github.com/ryncsn/emm-test-project/tree/master/swap-stress-race [1]
    Signed-off-by: Kairui Song <kasong@tencent.com>
    Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
    Acked-by: Yu Zhao <yuzhao@google.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Acked-by: Chris Li <chrisl@kernel.org>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Yosry Ahmed <yosryahmed@google.com>
    Cc: Yu Zhao <yuzhao@google.com>
    Cc: Barry Song <21cnbao@gmail.com>
    Cc: SeongJae Park <sj@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 e3bf0a24e050538d3e4c8d8319b8e04e18188ce7
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Wed Feb 14 17:14:11 2024 -0500

    scsi: core: Consult supported VPD page list prior to fetching page
    
    commit b5fc07a5fb56216a49e6c1d0b172d5464d99a89b upstream.
    
    Commit c92a6b5d6335 ("scsi: core: Query VPD size before getting full
    page") removed the logic which checks whether a VPD page is present on
    the supported pages list before asking for the page itself. That was
    done because SPC helpfully states "The Supported VPD Pages VPD page
    list may or may not include all the VPD pages that are able to be
    returned by the device server". Testing had revealed a few devices
    that supported some of the 0xBn pages but didn't actually list them in
    page 0.
    
    Julian Sikorski bisected a problem with his drive resetting during
    discovery to the commit above. As it turns out, this particular drive
    firmware will crash if we attempt to fetch page 0xB9.
    
    Various approaches were attempted to work around this. In the end,
    reinstating the logic that consults VPD page 0 before fetching any
    other page was the path of least resistance. A firmware update for the
    devices which originally compelled us to remove the check has since
    been released.
    
    Link: https://lore.kernel.org/r/20240214221411.2888112-1-martin.petersen@oracle.com
    Fixes: c92a6b5d6335 ("scsi: core: Query VPD size before getting full page")
    Cc: stable@vger.kernel.org
    Cc: Bart Van Assche <bvanassche@acm.org>
    Reported-by: Julian Sikorski <belegdol@gmail.com>
    Tested-by: Julian Sikorski <belegdol@gmail.com>
    Reviewed-by: Lee Duncan <lee.duncan@suse.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f49b20fd0134da84a6bd8108f9e73c077b7d6231
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Wed Feb 14 23:43:56 2024 +0900

    scsi: target: pscsi: Fix bio_put() for error case
    
    commit de959094eb2197636f7c803af0943cb9d3b35804 upstream.
    
    As of commit 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc
    wrapper"), a bio allocated by bio_kmalloc() must be freed by bio_uninit()
    and kfree(). That is not done properly for the error case, hitting WARN and
    NULL pointer dereference in bio_free().
    
    Fixes: 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc wrapper")
    CC: stable@vger.kernel.org # 6.1+
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Link: https://lore.kernel.org/r/20240214144356.101814-1-naohiro.aota@wdc.com
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 031217128990d7f0ab8c46db1afb3cf1e075fd29
Author: Robert Richter <rrichter@amd.com>
Date:   Fri Feb 16 17:01:13 2024 +0100

    cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window
    
    commit 0cab687205986491302cd2e440ef1d253031c221 upstream.
    
    The Linux CXL subsystem is built on the assumption that HPA == SPA.
    That is, the host physical address (HPA) the HDM decoder registers are
    programmed with are system physical addresses (SPA).
    
    During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1,
    8.1.3.8) are checked if the memory is enabled and the CXL range is in
    a HPA window that is described in a CFMWS structure of the CXL host
    bridge (cxl-3.1, 9.18.1.3).
    
    Now, if the HPA is not an SPA, the CXL range does not match a CFMWS
    window and the CXL memory range will be disabled then. The HDM decoder
    stops working which causes system memory being disabled and further a
    system hang during HDM decoder initialization, typically when a CXL
    enabled kernel boots.
    
    Prevent a system hang and do not disable the HDM decoder if the
    decoder's CXL range is not found in a CFMWS window.
    
    Note the change only fixes a hardware hang, but does not implement
    HPA/SPA translation. Support for this can be added in a follow on
    patch series.
    
    Signed-off-by: Robert Richter <rrichter@amd.com>
    Fixes: 34e37b4c432c ("cxl/port: Enable HDM Capability after validating DVSEC Ranges")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240216160113.407141-1-rrichter@amd.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27c1ade6068fe4de9eee0fa1dc9393fd4b79246c
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Feb 19 21:28:09 2024 +0100

    dm-verity: recheck the hash after a failure
    
    commit 9177f3c0dea6143d05cac1bbd28668fd0e216d11 upstream.
    
    If a userspace process reads (with O_DIRECT) multiple blocks into the same
    buffer, dm-verity reports an error [1].
    
    This commit fixes dm-verity, so that if hash verification fails, the data
    is read again into a kernel buffer (where userspace can't modify it) and
    the hash is rechecked. If the recheck succeeds, the content of the kernel
    buffer is copied into the user buffer; if the recheck fails, an error is
    reported.
    
    [1] https://people.redhat.com/~mpatocka/testcases/blk-auth-modify/read2.c
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e08c2a8d27e989f0f5b0888792643027d7e691e6
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Feb 19 21:30:10 2024 +0100

    dm-crypt: don't modify the data when using authenticated encryption
    
    commit 50c70240097ce41fe6bce6478b80478281e4d0f7 upstream.
    
    It was said that authenticated encryption could produce invalid tag when
    the data that is being encrypted is modified [1]. So, fix this problem by
    copying the data into the clone bio first and then encrypt them inside the
    clone bio.
    
    This may reduce performance, but it is needed to prevent the user from
    corrupting the device by writing data with O_DIRECT and modifying them at
    the same time.
    
    [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 906414f4596469004632de29126c55751ed82c5e
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Feb 19 21:27:39 2024 +0100

    dm-integrity: recheck the integrity tag after a failure
    
    commit c88f5e553fe38b2ffc4c33d08654e5281b297677 upstream.
    
    If a userspace process reads (with O_DIRECT) multiple blocks into the same
    buffer, dm-integrity reports an error [1]. The error is reported in a log
    and it may cause RAID leg being kicked out of the array.
    
    This commit fixes dm-integrity, so that if integrity verification fails,
    the data is read again into a kernel buffer (where userspace can't modify
    it) and the integrity tag is rechecked. If the recheck succeeds, the
    content of the kernel buffer is copied into the user buffer; if the
    recheck fails, an integrity error is reported.
    
    [1] https://people.redhat.com/~mpatocka/testcases/blk-auth-modify/read2.c
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6437b0b4ddcd258b400baec9d4601ba9e19e3faf
Author: Helge Deller <deller@gmx.de>
Date:   Mon Feb 5 10:39:20 2024 +0100

    Revert "parisc: Only list existing CPUs in cpu_possible_mask"
    
    commit 82b143aeb169b8b55798d7d2063032e1a6ceeeb0 upstream.
    
    This reverts commit 0921244f6f4f0d05698b953fe632a99b38907226.
    
    It broke CPU hotplugging because it modifies the __cpu_possible_mask
    after bootup, so that it will be different than nr_cpu_ids, which
    then effictively breaks the workqueue setup code and triggers crashes
    when shutting down CPUs at runtime.
    
    Guenter was the first who noticed the wrong values in __cpu_possible_mask,
    since the cpumask Kunit tests were failig.
    
    Reverting this commit fixes both issues, but sadly brings back this
    uncritical runtime warning:
    register_cpu_capacity_sysctl: too early to get CPU4 device!
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lkml.org/lkml/2024/2/4/146
    Link: https://lore.kernel.org/lkml/Zb0mbHlIud_bqftx@slm.duckdns.org/t/
    Cc: stable@vger.kernel.org # 6.0+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5583552eec30eb58acac404948e50609b070cb98
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Mon Feb 19 21:31:11 2024 +0100

    dm-crypt: recheck the integrity tag after a failure
    
    commit 42e15d12070b4ff9af2b980f1b65774c2dab0507 upstream.
    
    If a userspace process reads (with O_DIRECT) multiple blocks into the same
    buffer, dm-crypt reports an authentication error [1]. The error is
    reported in a log and it may cause RAID leg being kicked out of the
    array.
    
    This commit fixes dm-crypt, so that if integrity verification fails, the
    data is read again into a kernel buffer (where userspace can't modify it)
    and the integrity tag is rechecked. If the recheck succeeds, the content
    of the kernel buffer is copied into the user buffer; if the recheck fails,
    an integrity error is reported.
    
    [1] https://people.redhat.com/~mpatocka/testcases/blk-auth-modify/read2.c
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 287abdcb9e2b0836716655908d8f4cccd0925da8
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Thu Jan 11 20:51:22 2024 +0900

    ata: libata-core: Do not try to set sleeping devices to standby
    
    commit 4b085736e44dbbe69b5eea1a8a294f404678a1f4 upstream.
    
    In ata ata_dev_power_set_standby(), check that the target device is not
    sleeping. If it is, there is no need to do anything.
    
    Fixes: aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65c5a1ba2c32dc90bf112c11151bf912d317906d
Author: Peter Oberparleiter <oberpar@linux.ibm.com>
Date:   Wed Feb 14 16:06:28 2024 +0100

    s390/cio: fix invalid -EBUSY on ccw_device_start
    
    commit 5ef1dc40ffa6a6cb968b0fdc43c3a61727a9e950 upstream.
    
    The s390 common I/O layer (CIO) returns an unexpected -EBUSY return code
    when drivers try to start I/O while a path-verification (PV) process is
    pending. This can lead to failed device initialization attempts with
    symptoms like broken network connectivity after boot.
    
    Fix this by replacing the -EBUSY return code with a deferred condition
    code 1 reply to make path-verification handling consistent from a
    driver's point of view.
    
    The problem can be reproduced semi-regularly using the following process,
    while repeating steps 2-3 as necessary (example assumes an OSA device
    with bus-IDs 0.0.a000-0.0.a002 on CHPID 0.02):
    
    1. echo 0.0.a000,0.0.a001,0.0.a002 >/sys/bus/ccwgroup/drivers/qeth/group
    2. echo 0 > /sys/bus/ccwgroup/devices/0.0.a000/online
    3. echo 1 > /sys/bus/ccwgroup/devices/0.0.a000/online ; \
       echo on > /sys/devices/css0/chp0.02/status
    
    Background information:
    
    The common I/O layer starts path-verification I/Os when it receives
    indications about changes in a device path's availability. This occurs
    for example when hardware events indicate a change in channel-path
    status, or when a manual operation such as a CHPID vary or configure
    operation is performed.
    
    If a driver attempts to start I/O while a PV is running, CIO reports a
    successful I/O start (ccw_device_start() return code 0). Then, after
    completion of PV, CIO synthesizes an interrupt response that indicates
    an asynchronous status condition that prevented the start of the I/O
    (deferred condition code 1).
    
    If a PV indication arrives while a device is busy with driver-owned I/O,
    PV is delayed until after I/O completion was reported to the driver's
    interrupt handler. To ensure that PV can be started eventually, CIO
    reports a device busy condition (ccw_device_start() return code -EBUSY)
    if a driver tries to start another I/O while PV is pending.
    
    In some cases this -EBUSY return code causes device drivers to consider
    a device not operational, resulting in failed device initialization.
    
    Note: The code that introduced the problem was added in 2003. Symptoms
    started appearing with the following CIO commit that causes a PV
    indication when a device is removed from the cio_ignore list after the
    associated parent subchannel device was probed, but before online
    processing of the CCW device has started:
    
    2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")
    
    During boot, the cio_ignore list is modified by the cio_ignore dracut
    module [1] as well as Linux vendor-specific systemd service scripts[2].
    When combined, this commit and boot scripts cause a frequent occurrence
    of the problem during boot.
    
    [1] https://github.com/dracutdevs/dracut/tree/master/modules.d/81cio_ignore
    [2] https://github.com/SUSE/s390-tools/blob/master/cio_ignore.service
    
    Cc: stable@vger.kernel.org # v5.15+
    Fixes: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")
    Tested-By: Thorsten Winkler <twinkler@linux.ibm.com>
    Reviewed-by: Thorsten Winkler <twinkler@linux.ibm.com>
    Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47647795a630e74a2a727dfc0fe362b30cbf8905
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Date:   Wed Feb 21 08:33:24 2024 +0100

    drm/ttm: Fix an invalid freeing on already freed page in error path
    
    commit 40510a941d27d405a82dc3320823d875f94625df upstream.
    
    If caching mode change fails due to, for example, OOM we
    free the allocated pages in a two-step process. First the pages
    for which the caching change has already succeeded. Secondly
    the pages for which a caching change did not succeed.
    
    However the second step was incorrectly freeing the pages already
    freed in the first step.
    
    Fix.
    
    Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
    Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Christian Koenig <christian.koenig@amd.com>
    Cc: Huang Rui <ray.huang@amd.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v6.4+
    Reviewed-by: Matthew Auld <matthew.auld@intel.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellstrom@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a262b78dd085dbe9b3c75dc1d9c4cd102b110b53
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Fri Feb 23 14:36:31 2024 +0800

    LoongArch: Disable IRQ before init_fn() for nonboot CPUs
    
    commit 1001db6c42e4012b55e5ee19405490f23e033b5a upstream.
    
    Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to
    silence such warnings (and also avoid potential errors due to unexpected
    interrupts):
    
    WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198
    pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0
    a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000
    a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c
    t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e
    t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000
    t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001
    s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001
    s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8
       ra: 90000000047bd56c tlb_init+0x24c/0x528
      ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280
     CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
     PRMD: 00000000 (PPLV0 -PIE -PWE)
     EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
     ECFG: 00071000 (LIE=12 VS=7)
    ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
     PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198
    Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000
            900000010039fa30 0000000000000000 900000010039fa38 900000000619a140
            9000000006456888 9000000006456880 900000010039f950 0000000000000001
            0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700
            0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003
            0000000000040000 9000000007930370 0000000002b90000 0000000000000004
            9000000006366000 900000000619a140 0000000000000000 0000000000000004
            0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940
            9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8
            00000000000000b0 0000000000000000 0000000000000000 0000000000071000
            ...
    Call Trace:
    [<90000000047a4828>] show_stack+0x48/0x1a0
    [<9000000005b61874>] dump_stack_lvl+0x84/0xcc
    [<90000000047f60ac>] __warn+0x8c/0x1e0
    [<9000000005b0ab34>] report_bug+0x1b4/0x280
    [<9000000005b63110>] do_bp+0x2d0/0x480
    [<90000000047a2e20>] handle_bp+0x120/0x1c0
    [<90000000048e3334>] rcu_cpu_starting+0x214/0x280
    [<90000000047bd568>] tlb_init+0x248/0x528
    [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160
    [<90000000047a19f4>] cpu_probe+0x494/0xa00
    [<90000000047b551c>] start_secondary+0x3c/0xc0
    [<9000000005b66134>] smpboot_entry+0x50/0x58
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52dc9a7a573dbf778625a0efca0fca55489f084b
Author: Daniel Vacek <neelx@redhat.com>
Date:   Thu Feb 1 09:10:08 2024 +0100

    IB/hfi1: Fix sdma.h tx->num_descs off-by-one error
    
    commit e6f57c6881916df39db7d95981a8ad2b9c3458d6 upstream.
    
    Unfortunately the commit `fd8958efe877` introduced another error
    causing the `descs` array to overflow. This reults in further crashes
    easily reproducible by `sendmsg` system call.
    
    [ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI
    [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]
    --
    [ 1080.974535] Call Trace:
    [ 1080.976990]  <TASK>
    [ 1081.021929]  hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]
    [ 1081.027364]  hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]
    [ 1081.032633]  hfi1_ipoib_send+0x112/0x300 [hfi1]
    [ 1081.042001]  ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]
    [ 1081.046978]  dev_hard_start_xmit+0xc4/0x210
    --
    [ 1081.148347]  __sys_sendmsg+0x59/0xa0
    
    crash> ipoib_txreq 0xffff9cfeba229f00
    struct ipoib_txreq {
      txreq = {
        list = {
          next = 0xffff9cfeba229f00,
          prev = 0xffff9cfeba229f00
        },
        descp = 0xffff9cfeba229f40,
        coalesce_buf = 0x0,
        wait = 0xffff9cfea4e69a48,
        complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>,
        packet_len = 0x46d,
        tlen = 0x0,
        num_desc = 0x0,
        desc_limit = 0x6,
        next_descq_idx = 0x45c,
        coalesce_idx = 0x0,
        flags = 0x0,
        descs = {{
            qw = {0x8024000120dffb00, 0x4}  # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)
          }, {
            qw = {  0x3800014231b108, 0x4}
          }, {
            qw = { 0x310000e4ee0fcf0, 0x8}
          }, {
            qw = {  0x3000012e9f8000, 0x8}
          }, {
            qw = {  0x59000dfb9d0000, 0x8}
          }, {
            qw = {  0x78000e02e40000, 0x8}
          }}
      },
      sdma_hdr =  0x400300015528b000,  <<< invalid pointer in the tx request structure
      sdma_status = 0x0,                   SDMA_DESC0_LAST_DESC_FLAG (bit 62)
      complete = 0x0,
      priv = 0x0,
      txq = 0xffff9cfea4e69880,
      skb = 0xffff9d099809f400
    }
    
    If an SDMA send consists of exactly 6 descriptors and requires dword
    padding (in the 7th descriptor), the sdma_txreq descriptor array is not
    properly expanded and the packet will overflow into the container
    structure. This results in a panic when the send completion runs. The
    exact panic varies depending on what elements of the container structure
    get corrupted. The fix is to use the correct expression in
    _pad_sdma_tx_descs() to test the need to expand the descriptor array.
    
    With this patch the crashes are no longer reproducible and the machine is
    stable.
    
    Fixes: fd8958efe877 ("IB/hfi1: Fix sdma.h tx->num_descs off-by-one errors")
    Cc: stable@vger.kernel.org
    Reported-by: Mats Kronberg <kronberg@nsc.liu.se>
    Tested-by: Mats Kronberg <kronberg@nsc.liu.se>
    Signed-off-by: Daniel Vacek <neelx@redhat.com>
    Link: https://lore.kernel.org/r/20240201081009.1109442-1-neelx@redhat.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4aa4ea70f37c18d5c2db347858327efea20ade18
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Fri Jan 12 17:33:55 2024 +0100

    pmdomain: renesas: r8a77980-sysc: CR7 must be always on
    
    [ Upstream commit f0e4a1356466ec1858ae8e5c70bea2ce5e55008b ]
    
    The power domain containing the Cortex-R7 CPU core on the R-Car V3H SoC
    must always be in power-on state, unlike on other SoCs in the R-Car Gen3
    family.  See Table 9.4 "Power domains" in the R-Car Series, 3rd
    Generation Hardware User’s Manual Rev.1.00 and later.
    
    Fix this by marking the domain as a CPU domain without control
    registers, so the driver will not touch it.
    
    Fixes: 41d6d8bd8ae9 ("soc: renesas: rcar-sysc: add R8A77980 support")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/fdad9a86132d53ecddf72b734dac406915c4edc0.1705076735.git.geert+renesas@glider.be
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 339ddc983bc1622341d95f244c361cda3da3a4ff
Author: Eugen Hristev <eugen.hristev@collabora.com>
Date:   Mon Dec 25 15:36:15 2023 +0200

    pmdomain: mediatek: fix race conditions with genpd
    
    [ Upstream commit c41336f4d69057cbf88fed47951379b384540df5 ]
    
    If the power domains are registered first with genpd and *after that*
    the driver attempts to power them on in the probe sequence, then it is
    possible that a race condition occurs if genpd tries to power them on
    in the same time.
    The same is valid for powering them off before unregistering them
    from genpd.
    Attempt to fix race conditions by first removing the domains from genpd
    and *after that* powering down domains.
    Also first power up the domains and *after that* register them
    to genpd.
    
    Fixes: 59b644b01cf4 ("soc: mediatek: Add MediaTek SCPSYS power domains")
    Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231225133615.78993-1-eugen.hristev@collabora.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4dd73641d7ac7273751a893c7445f9d2dbcec2cb
Author: Steve French <stfrench@microsoft.com>
Date:   Tue Feb 6 23:57:18 2024 -0600

    smb3: clarify mount warning
    
    [ Upstream commit a5cc98eba2592d6e3c5a4351319595ddde2a5901 ]
    
    When a user tries to use the "sec=krb5p" mount parameter to encrypt
    data on connection to a server (when authenticating with Kerberos), we
    indicate that it is not supported, but do not note the equivalent
    recommended mount parameter ("sec=krb5,seal") which turns on encryption
    for that mount (and uses Kerberos for auth).  Update the warning message.
    
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit db48acce75d73dfe51c43d56893cce067b73cf08
Author: Yi Sun <yi.sun@unisoc.com>
Date:   Mon Jan 29 16:52:50 2024 +0800

    virtio-blk: Ensure no requests in virtqueues before deleting vqs.
    
    [ Upstream commit 4ce6e2db00de8103a0687fb0f65fd17124a51aaa ]
    
    Ensure no remaining requests in virtqueues before resetting vdev and
    deleting virtqueues. Otherwise these requests will never be completed.
    It may cause the system to become unresponsive.
    
    Function blk_mq_quiesce_queue() can ensure that requests have become
    in_flight status, but it cannot guarantee that requests have been
    processed by the device. Virtqueues should never be deleted before
    all requests become complete status.
    
    Function blk_mq_freeze_queue() ensure that all requests in virtqueues
    become complete status. And no requests can enter in virtqueues.
    
    Signed-off-by: Yi Sun <yi.sun@unisoc.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Link: https://lore.kernel.org/r/20240129085250.1550594-1-yi.sun@unisoc.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0947d0d463d4e6fad75f3a3066613cb3d9689b26
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Fri Feb 2 12:38:24 2024 -0300

    smb: client: set correct d_type for reparse points under DFS mounts
    
    [ Upstream commit 55c7788c37242702868bfac7861cdf0c358d6c3d ]
    
    Send query dir requests with an info level of
    SMB_FIND_FILE_FULL_DIRECTORY_INFO rather than
    SMB_FIND_FILE_DIRECTORY_INFO when the client is generating its own
    inode numbers (e.g. noserverino) so that reparse tags still
    can be parsed directly from the responses, but server won't
    send UniqueId (server inode number)
    
    Signed-off-by: Paulo Alcantara <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b661fb17bfad9e2b72ed713c86a52829f9b0473
Author: Prike Liang <Prike.Liang@amd.com>
Date:   Wed Jan 17 13:39:37 2024 +0800

    drm/amdgpu: reset gpu for s3 suspend abort case
    
    [ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]
    
    In the s3 suspend abort case some type of gfx9 power
    rail not turn off from FCH side and this will put the
    GPU in an unknown power status, so let's reset the gpu
    to a known good power state before reinitialize gpu
    device.
    
    Signed-off-by: Prike Liang <Prike.Liang@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d56edd0f1b3013e0a452c53cb476b6b7b39210a1
Author: Prike Liang <Prike.Liang@amd.com>
Date:   Tue Jan 16 19:10:45 2024 +0800

    drm/amdgpu: skip to program GFXDEC registers for suspend abort
    
    [ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]
    
    In the suspend abort cases, the gfx power rail doesn't turn off so
    some GFXDEC registers/CSB can't reset to default value and at this
    moment reinitialize GFXDEC/CSB will result in an unexpected error.
    So let skip those program sequence for the suspend abort case.
    
    Signed-off-by: Prike Liang <Prike.Liang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b82ffe7a265b832b40fd31ee5503170cb3407e2
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Wed Feb 7 08:01:17 2024 +0900

    firewire: core: send bus reset promptly on gap count error
    
    [ Upstream commit 7ed4380009e96d9e9c605e12822e987b35b05648 ]
    
    If we are bus manager and the bus has inconsistent gap counts, send a
    bus reset immediately instead of trying to read the root node's config
    ROM first. Otherwise, we could spend a lot of time trying to read the
    config ROM but never succeeding.
    
    This eliminates a 50+ second delay before the FireWire bus is usable after
    a newly connected device is powered on in certain circumstances.
    
    The delay occurs if a gap count inconsistency occurs, we are not the root
    node, and we become bus manager. One scenario that causes this is with a TI
    XIO2213B OHCI, the first time a Sony DSR-25 is powered on after being
    connected to the FireWire cable. In this configuration, the Linux box will
    not receive the initial PHY configuration packet sent by the DSR-25 as IRM,
    resulting in the DSR-25 having a gap count of 44 while the Linux box has a
    gap count of 63.
    
    FireWire devices have a gap count parameter, which is set to 63 on power-up
    and can be changed with a PHY configuration packet. This determines the
    duration of the subaction and arbitration gaps. For reliable communication,
    all nodes on a FireWire bus must have the same gap count.
    
    A node may have zero or more of the following roles: root node, bus manager
    (BM), isochronous resource manager (IRM), and cycle master. Unless a root
    node was forced with a PHY configuration packet, any node might become root
    node after a bus reset. Only the root node can become cycle master. If the
    root node is not cycle master capable, the BM or IRM should force a change
    of root node.
    
    After a bus reset, each node sends a self-ID packet, which contains its
    current gap count. A single bus reset does not change the gap count, but
    two bus resets in a row will set the gap count to 63. Because a consistent
    gap count is required for reliable communication, IEEE 1394a-2000 requires
    that the bus manager generate a bus reset if it detects that the gap count
    is inconsistent.
    
    When the gap count is inconsistent, build_tree() will notice this after the
    self identification process. It will set card->gap_count to the invalid
    value 0. If we become bus master, this will force bm_work() to send a bus
    reset when it performs gap count optimization.
    
    After a bus reset, there is no bus manager. We will almost always try to
    become bus manager. Once we become bus manager, we will first determine
    whether the root node is cycle master capable. Then, we will determine if
    the gap count should be changed. If either the root node or the gap count
    should be changed, we will generate a bus reset.
    
    To determine if the root node is cycle master capable, we read its
    configuration ROM. bm_work() will wait until we have finished trying to
    read the configuration ROM.
    
    However, an inconsistent gap count can make this take a long time.
    read_config_rom() will read the first few quadlets from the config ROM. Due
    to the gap count inconsistency, eventually one of the reads will time out.
    When read_config_rom() fails, fw_device_init() calls it again until
    MAX_RETRIES is reached. This takes 50+ seconds.
    
    Once we give up trying to read the configuration ROM, bm_work() will wake
    up, assume that the root node is not cycle master capable, and do a bus
    reset. Hopefully, this will resolve the gap count inconsistency.
    
    This change makes bm_work() check for an inconsistent gap count before
    waiting for the root node's configuration ROM. If the gap count is
    inconsistent, bm_work() will immediately do a bus reset. This eliminates
    the 50+ second delay and rapidly brings the bus to a working state.
    
    I considered that if the gap count is inconsistent, a PHY configuration
    packet might not be successful, so it could be desirable to skip the PHY
    configuration packet before the bus reset in this case. However, IEEE
    1394a-2000 and IEEE 1394-2008 say that the bus manager may transmit a PHY
    configuration packet before a bus reset when correcting a gap count error.
    Since the standard endorses this, I decided it's safe to retain the PHY
    configuration packet transmission.
    
    Normally, after a topology change, we will reset the bus a maximum of 5
    times to change the root node and perform gap count optimization. However,
    if there is a gap count inconsistency, we must always generate a bus reset.
    Otherwise the gap count inconsistency will persist and communication will
    be unreliable. For that reason, if there is a gap count inconstency, we
    generate a bus reset even if we already reached the 5 reset limit.
    
    Signed-off-by: Adam Goldman <adamg@pobox.com>
    Reference: https://sourceforge.net/p/linux1394/mailman/message/58727806/
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c0b07b4237e42cf952dc72d0f459e86fc3e2e121
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Feb 6 12:32:05 2024 +0800

    LoongArch: Select HAVE_ARCH_SECCOMP to use the common SECCOMP menu
    
    [ Upstream commit 6b79ecd084c99b31c8b4d0beda08893716d5558e ]
    
    LoongArch missed the refactoring made by commit 282a181b1a0d ("seccomp:
    Move config option SECCOMP to arch/Kconfig") because LoongArch was not
    mainlined at that time.
    
    The 'depends on PROC_FS' statement is stale as described in that commit.
    Select HAVE_ARCH_SECCOMP, and remove the duplicated config entry.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c920f604e0c896aab911efb5913ce89f74b9b69c
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Feb 6 12:32:05 2024 +0800

    LoongArch: Select ARCH_ENABLE_THP_MIGRATION instead of redefining it
    
    [ Upstream commit b3ff2d9c3a9c64cd0a011cdd407ffc38a6ea8788 ]
    
    ARCH_ENABLE_THP_MIGRATION is supposed to be selected by arch Kconfig.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7ac9c1f7f934df56fe1c1bb5ac970d543d4dc09
Author: SEO HOYOUNG <hy50.seo@samsung.com>
Date:   Mon Jan 22 17:33:24 2024 +0900

    scsi: ufs: core: Remove the ufshcd_release() in ufshcd_err_handling_prepare()
    
    [ Upstream commit 17e94b2585417e04dabc2f13bc03b4665ae687f3 ]
    
    If ufshcd_err_handler() is called in a suspend/resume situation,
    ufs_release() can be called twice and active_reqs end up going negative.
    This is because ufshcd_err_handling_prepare() and
    ufshcd_err_handling_unprepare() both call ufshcd_release().
    
    Remove superfluous call to ufshcd_release().
    
    Signed-off-by: SEO HOYOUNG <hy50.seo@samsung.com>
    Link: https://lore.kernel.org/r/20240122083324.11797-1-hy50.seo@samsung.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 75745f2b7453f21df39d913ec1e6cfee7887c88d
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed Dec 20 17:26:58 2023 +0100

    scsi: lpfc: Use unsigned type for num_sge
    
    [ Upstream commit d6c1b19153f92e95e5e1801d540e98771053afae ]
    
    LUNs going into "failed ready running" state observed on >1T and on even
    numbers of size (2T, 4T, 6T, 8T and 10T). The issue occurs when DIF is
    enabled at the host.
    
    The kernel logs:
    
      Cannot setup S/G List for HBAIO segs 1/1 SGL 512 SCSI 256: 3 0
    
    The host lpfc driver is failing to setup scatter/gather list (protection
    data) for the I/Os.
    
    The return type lpfc_bg_setup_sgl()/lpfc_bg_setup_sgl_prot() causes the
    compiler to remove the most significant bit. Use an unsigned type instead.
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    [dwagner: added commit message]
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Link: https://lore.kernel.org/r/20231220162658.12392-1-dwagner@suse.de
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 76ee44af09755afaa24964bb639730f66685657e
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Feb 2 17:21:36 2024 +0800

    hwmon: (coretemp) Enlarge per package core count limit
    
    [ Upstream commit 34cf8c657cf0365791cdc658ddbca9cc907726ce ]
    
    Currently, coretemp driver supports only 128 cores per package.
    This loses some core temperature information on systems that have more
    than 128 cores per package.
     [   58.685033] coretemp coretemp.0: Adding Core 128 failed
     [   58.692009] coretemp coretemp.0: Adding Core 129 failed
     ...
    
    Enlarge the limitation to 512 because there are platforms with more than
    256 cores per package.
    
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Link: https://lore.kernel.org/r/20240202092144.71180-4-rui.zhang@intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48a33c312526857dc8850096cc31c53b2d6b7e27
Author: Andrew Bresticker <abrestic@rivosinc.com>
Date:   Fri Feb 2 10:07:04 2024 -0800

    efi: Don't add memblocks for soft-reserved memory
    
    [ Upstream commit 0bcff59ef7a652fcdc6d535554b63278c2406c8f ]
    
    Adding memblocks for soft-reserved regions prevents them from later being
    hotplugged in by dax_kmem.
    
    Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 700c3f642c32721f246e09d3a9511acf40ae42be
Author: Andrew Bresticker <abrestic@rivosinc.com>
Date:   Fri Feb 2 10:07:03 2024 -0800

    efi: runtime: Fix potential overflow of soft-reserved region size
    
    [ Upstream commit de1034b38a346ef6be25fe8792f5d1e0684d5ff4 ]
    
    md_size will have been narrowed if we have >= 4GB worth of pages in a
    soft-reserved region.
    
    Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2bf17c3e13aab5e1e867508b2db85927810f9f97
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jan 31 16:48:23 2024 +0100

    wifi: mac80211: adding missing drv_mgd_complete_tx() call
    
    [ Upstream commit c042600c17d8c490279f0ae2baee29475fe8047d ]
    
    There's a call to drv_mgd_prepare_tx() and so there should
    be one to drv_mgd_complete_tx(), but on this path it's not.
    Add it.
    
    Link: https://msgid.link/20240131164824.2f0922a514e1.I5aac89b93bcead88c374187d70cad0599d29d2c8@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4e5bd2287021823c10862379312648dd55e17f49
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Jan 29 15:53:55 2024 +0100

    wifi: mac80211: set station RX-NSS on reconfig
    
    [ Upstream commit dd6c064cfc3fc18d871107c6f5db8837e88572e4 ]
    
    When a station is added/reconfigured by userspace, e.g. a TDLS
    peer or a SoftAP client STA, rx_nss is currently not always set,
    so that it might be left zero. Set it up properly.
    
    Link: https://msgid.link/20240129155354.98f148a3d654.I193a02155f557ea54dc9d0232da66cf96734119a@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ed6cdbe88334ca3430c5aee7754dc4597498dfb
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Sat Dec 30 17:00:03 2023 +0800

    fs/ntfs3: Fix oob in ntfs_listxattr
    
    [ Upstream commit 731ab1f9828800df871c5a7ab9ffe965317d3f15 ]
    
    The length of name cannot exceed the space occupied by ea.
    
    Reported-and-tested-by: syzbot+65e940cfb8f99a97aca7@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d67a4ff3dfe19aceb185d4c3912796e2d0ac4e1
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Mon Jan 29 10:30:09 2024 +0300

    fs/ntfs3: Update inode->i_size after success write into compressed file
    
    [ Upstream commit d68968440b1a75dee05cfac7f368f1aa139e1911 ]
    
    Reported-by: Giovanni Santini <giovannisantini93@yahoo.it>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32a3974b26dfbb059d15ab8d5683d8b9de647468
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Jan 26 11:13:59 2024 +0300

    fs/ntfs3: Correct function is_rst_area_valid
    
    [ Upstream commit 1b7dd28e14c4728ae1a815605ca33ffb4ce1b309 ]
    
    Reported-by: Robert Morris <rtm@csail.mit.edu>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d2f804b9f5424d1970403d7bfcf1f22b7853e25
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Jan 26 11:03:21 2024 +0300

    fs/ntfs3: Prevent generic message "attempt to access beyond end of device"
    
    [ Upstream commit 5ca87d01eba7bdfe9536a157ca33c1455bb8d16c ]
    
    It used in test environment.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c005ce9934c0b784b8123e2dee7aa2dbf7ebce2
Author: Ism Hong <ism.hong@gmail.com>
Date:   Tue Dec 26 16:51:41 2023 +0800

    fs/ntfs3: use non-movable memory for ntfs3 MFT buffer cache
    
    [ Upstream commit d6d33f03baa43d763fe094ca926eeae7d3421d07 ]
    
    Since the buffer cache for ntfs3 metadata is not released until the file
    system is unmounted, allocating from the movable zone may result in cma
    allocation failures. This is due to the page still being used by ntfs3,
    leading to migration failures.
    
    To address this, this commit use sb_bread_umovable() instead of
    sb_bread(). This change prevents allocation from the movable zone,
    ensuring compatibility with scenarios where the buffer head is not
    released until unmount. This patch is inspired by commit
    a8ac900b8163("ext4: use non-movable memory for the ext4 superblock").
    
    The issue is found when playing video files stored in NTFS on the
    Android TV platform. During this process, the media parser reads the
    video file, causing ntfs3 to allocate buffer cache from the CMA area.
    Subsequently, the hardware decoder attempts to allocate memory from the
    same CMA area. However, the page is still in use by ntfs3, resulting in
    a migrate failure in alloc_contig_range().
    
    The pinned page and allocating stacktrace reported by page owner shows
    below:
    
    page:ffffffff00b68880 refcount:3 mapcount:0 mapping:ffffff80046aa828
            index:0xc0040 pfn:0x20fa4
        aops:def_blk_aops ino:0
        flags: 0x2020(active|private)
        page dumped because: migration failure
        page last allocated via order 0, migratetype Movable,
            gfp_mask 0x108c48
            (GFP_NOFS|__GFP_NOFAIL|__GFP_HARDWALL|__GFP_MOVABLE),
        page_owner tracks the page as allocated
         prep_new_page
         get_page_from_freelist
         __alloc_pages_nodemask
         pagecache_get_page
         __getblk_gfp
         __bread_gfp
         ntfs_read_run_nb
         ntfs_read_bh
         mi_read
         ntfs_iget5
         dir_search_u
         ntfs_lookup
         __lookup_slow
         lookup_slow
         walk_component
         path_lookupat
    
    Signed-off-by: Ism Hong <ism.hong@gmail.com>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee12c3102027ba3c1ea08ca292dc9d7ccf7c21e4
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Thu Dec 21 13:59:43 2023 +0300

    fs/ntfs3: Disable ATTR_LIST_ENTRY size check
    
    [ Upstream commit 4cdfb6e7bc9c80142d33bf1d4653a73fa678ba56 ]
    
    The use of sizeof(struct ATTR_LIST_ENTRY) has been replaced with le_size(0)
    due to alignment peculiarities on different platforms.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202312071005.g6YrbaIe-lkp@intel.com/
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50545eb6cd5f7ff852a01fa29b7372524ef948cc
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Tue Nov 28 11:09:34 2023 +0300

    fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame()
    
    [ Upstream commit aaab47f204aaf47838241d57bf8662c8840de60a ]
    
    It is preferable to exit through the out: label because
    internal debugging functions are located there.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 95bad562e575d6bbe623cfd234946573b0a48812
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:47:30 2023 +0300

    fs/ntfs3: Fix detected field-spanning write (size 8) of single field "le->name"
    
    [ Upstream commit d155617006ebc172a80d3eb013c4b867f9a8ada4 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9f7d7656fbcea654a3db7860033cf2667730c00
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:34:24 2023 +0300

    fs/ntfs3: Print warning while fixing hard links count
    
    [ Upstream commit 85ba2a75faee759809a7e43b4c103ac59bac1026 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 25d1694d6e34321d3dacccafe85f6b15719a5c62
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:26:31 2023 +0300

    fs/ntfs3: Correct hard links updating when dealing with DOS names
    
    [ Upstream commit 1918c10e137eae266b8eb0ab1cc14421dcb0e3e2 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1970b5f2048f646d61327cd9685698b96ba31941
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:24:33 2023 +0300

    fs/ntfs3: Improve ntfs_dir_count
    
    [ Upstream commit 6a799c928b78b14999b7705c4cca0f88e297fe96 ]
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c66843606921d4f4a6f6c3275cded2963f36051
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Fri Nov 24 11:17:07 2023 +0300

    fs/ntfs3: Modified fix directory element type detection
    
    [ Upstream commit 22457c047ed971f2f2e33be593ddfabd9639a409 ]
    
    Unfortunately reparse attribute is used for many purposes (several dozens).
    It is not possible here to know is this name symlink or not.
    To get exactly the type of name we should to open inode (read mft).
    getattr for opened file (fstat) correctly returns symlink.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b3a996b106948ec2f347090b2550adfe0e6d3d4d
Author: Szilard Fabian <szfabian@bluemarch.art>
Date:   Fri Feb 2 10:28:59 2024 -0800

    Input: i8042 - add Fujitsu Lifebook U728 to i8042 quirk table
    
    [ Upstream commit 4255447ad34c5c3785fcdcf76cfa0271d6e5ed39 ]
    
    Another Fujitsu-related patch.
    
    In the initial boot stage the integrated keyboard of Fujitsu Lifebook U728
    refuses to work and it's not possible to type for example a dm-crypt
    passphrase without the help of an external keyboard.
    
    i8042.nomux kernel parameter resolves this issue but using that a PS/2
    mouse is detected. This input device is unused even when the i2c-hid-acpi
    kernel module is blacklisted making the integrated ELAN touchpad
    (04F3:3092) not working at all.
    
    So this notebook uses a hid-over-i2c touchpad which is managed by the
    i2c_designware input driver. Since you can't find a PS/2 mouse port on this
    computer and you can't connect a PS/2 mouse to it even with an official
    port replicator I think it's safe to not use the PS/2 mouse port at all.
    
    Signed-off-by: Szilard Fabian <szfabian@bluemarch.art>
    Link: https://lore.kernel.org/r/20240103014717.127307-2-szfabian@bluemarch.art
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 200627f46e0335cbef76ef52ce5cf9f1e9f3b135
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Sat Jan 27 09:58:02 2024 +0800

    ext4: correct the hole length returned by ext4_map_blocks()
    
    [ Upstream commit 6430dea07e85958fa87d0276c0c4388dd51e630b ]
    
    In ext4_map_blocks(), if we can't find a range of mapping in the
    extents cache, we are calling ext4_ext_map_blocks() to search the real
    path and ext4_ext_determine_hole() to determine the hole range. But if
    the querying range was partially or completely overlaped by a delalloc
    extent, we can't find it in the real extent path, so the returned hole
    length could be incorrect.
    
    Fortunately, ext4_ext_put_gap_in_cache() have already handle delalloc
    extent, but it searches start from the expanded hole_start, doesn't
    start from the querying range, so the delalloc extent found could not be
    the one that overlaped the querying range, plus, it also didn't adjust
    the hole length. Let's just remove ext4_ext_put_gap_in_cache(), handle
    delalloc and insert adjusted hole extent in ext4_ext_determine_hole().
    
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Suggested-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240127015825.1608160-4-yi.zhang@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit be36276cb88b361c14472dbd74805b786cf1725c
Author: Paulo Alcantara <pc@manguebit.com>
Date:   Mon Jan 29 21:04:44 2024 -0300

    smb: client: increase number of PDUs allowed in a compound request
    
    [ Upstream commit 11d4d1dba3315f73d2d1d386f5bf4811a8241d45 ]
    
    With the introduction of SMB2_OP_QUERY_WSL_EA, the client may now send
    5 commands in a single compound request in order to query xattrs from
    potential WSL reparse points, which should be fine as we currently
    allow up to 5 PDUs in a single compound request.  However, if
    encryption is enabled (e.g. 'seal' mount option) or enforced by the
    server, current MAX_COMPOUND(5) won't be enough as we require an extra
    PDU for the transform header.
    
    Fix this by increasing MAX_COMPOUND to 7 and, while we're at it, add
    an WARN_ON_ONCE() and return -EIO instead of -ENOMEM in case we
    attempt to send a compound request that couldn't include the extra
    transform header.
    
    Signed-off-by: Paulo Alcantara <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f9eef0e495159b83e46bddd9e2409ad81b2f5f96
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:11 2024 +0100

    nvmet-fc: take ref count on tgtport before delete assoc
    
    [ Upstream commit fe506a74589326183297d5abdda02d0c76ae5a8b ]
    
    We have to ensure that the tgtport is not going away
    before be have remove all the associations.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e6987f8937a7bd7516aa52f25cb7e12c0c92ee8
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:10 2024 +0100

    nvmet-fc: avoid deadlock on delete association path
    
    [ Upstream commit 710c69dbaccdac312e32931abcb8499c1525d397 ]
    
    When deleting an association the shutdown path is deadlocking because we
    try to flush the nvmet_wq nested. Avoid this by deadlock by deferring
    the put work into its own work item.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b9e4539493b4e3f3a2de7ccdf9e75fc962622d9
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:09 2024 +0100

    nvmet-fc: abort command when there is no binding
    
    [ Upstream commit 3146345c2e9c2f661527054e402b0cfad80105a4 ]
    
    When the target port has not active port binding, there is no point in
    trying to process the command as it has to fail anyway. Instead adding
    checks to all commands abort the command early.
    
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 67e2ddf2324ad55a555cdfb21802c8edce250372
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:06 2024 +0100

    nvmet-fc: hold reference on hostport match
    
    [ Upstream commit ca121a0f7515591dba0eb5532bfa7ace4dc153ce ]
    
    The hostport data structure is shared between the association, this why
    we keep track of the users via a refcount. So we should not decrement
    the refcount on a match and free the hostport several times.
    
    Reported by KASAN.
    
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b8338116689a5b541738a8bb89457e0c6c4d497e
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:04 2024 +0100

    nvmet-fc: defer cleanup using RCU properly
    
    [ Upstream commit 4049dc96b8de7aeb3addcea039446e464726a525 ]
    
    When the target executes a disconnect and the host triggers a reconnect
    immediately, the reconnect command still finds an existing association.
    
    The reconnect crashes later on because nvmet_fc_delete_target_assoc
    blindly removes resources while the reconnect code wants to use it.
    
    To address this, nvmet_fc_find_target_assoc should not be able to
    lookup an association which is being removed. The association list
    is already under RCU lifetime management, so let's properly use it
    and remove the association from the list and wait for a grace period
    before cleaning up all. This means we also can drop the RCU management
    on the queues, because this is now handled via the association itself.
    
    A second step split the execution context so that the initial disconnect
    command can complete without running the reconnect code in the same
    context. As usual, this is done by deferring the ->done to a workqueue.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6319ab29d5e01c7a50e9a6503e0555b834905fc8
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:03 2024 +0100

    nvmet-fc: release reference on target port
    
    [ Upstream commit c691e6d7e13dab81ac8c7489c83b5dea972522a5 ]
    
    In case we return early out of __nvmet_fc_finish_ls_req() we still have
    to release the reference on the target port.
    
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16b2b31ba886694d9fc06950a1a230adc4357350
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:02 2024 +0100

    nvmet-fcloop: swap the list_add_tail arguments
    
    [ Upstream commit dcfad4ab4d6733f2861cd241d8532a0004fc835a ]
    
    The first argument of list_add_tail function is the new element which
    should be added to the list which is the second argument. Swap the
    arguments to allow processing more than one element at a time.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 085195aa90a924c79e35569bcdad860d764a8e17
Author: Daniel Wagner <dwagner@suse.de>
Date:   Wed Jan 31 09:51:01 2024 +0100

    nvme-fc: do not wait in vain when unloading module
    
    [ Upstream commit 70fbfc47a392b98e5f8dba70c6efc6839205c982 ]
    
    The module exit path has race between deleting all controllers and
    freeing 'left over IDs'. To prevent double free a synchronization
    between nvme_delete_ctrl and ida_destroy has been added by the initial
    commit.
    
    There is some logic around trying to prevent from hanging forever in
    wait_for_completion, though it does not handling all cases. E.g.
    blktests is able to reproduce the situation where the module unload
    hangs forever.
    
    If we completely rely on the cleanup code executed from the
    nvme_delete_ctrl path, all IDs will be freed eventually. This makes
    calling ida_destroy unnecessary. We only have to ensure that all
    nvme_delete_ctrl code has been executed before we leave
    nvme_fc_exit_module. This is done by flushing the nvme_delete_wq
    workqueue.
    
    While at it, remove the unused nvme_fc_wq workqueue too.
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dee697ac5330e36f050b4ed0d6f520b8738fe12a
Author: Alexander Tsoy <alexander@tsoy.me>
Date:   Thu Feb 1 14:53:08 2024 +0300

    ALSA: usb-audio: Ignore clock selector errors for single connection
    
    [ Upstream commit eaa1b01fe709d6a236a9cec74813e0400601fd23 ]
    
    For devices with multiple clock sources connected to a selector, we need
    to check what a clock selector control request has returned. This is
    needed to ensure that a requested clock source is indeed selected and for
    autoclock feature to work.
    
    For devices with single clock source connected, if we get an error there
    is nothing else we can do about it. We can't skip clock selector setup as
    it is required by some devices. So lets just ignore error in this case.
    
    This should fix various buggy Mackie devices:
    
    [  649.109785] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32)
    [  649.111946] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32)
    [  649.113822] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32)
    
    There is also interesting info from the Windows documentation [1] (this
    is probably why manufacturers dont't even test this feature):
    
    "The USB Audio 2.0 driver doesn't support clock selection. The driver
    uses the Clock Source Entity, which is selected by default and never
    issues a Clock Selector Control SET CUR request."
    
    Link: https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers [1]
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217314
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218175
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218342
    Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
    Link: https://lore.kernel.org/r/20240201115308.17838-1-alexander@tsoy.me
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5653a6d65a11fd41afa79977aaab7f3aa7b6fbad
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Mon Jan 29 16:27:21 2024 +0000

    ASoC: wm_adsp: Don't overwrite fwf_name with the default
    
    [ Upstream commit daf3f0f99cde93a066240462b7a87cdfeedc04c0 ]
    
    There's no need to overwrite fwf_name with a kstrdup() of the cs_dsp part
    name. It is trivial to select either fwf_name or cs_dsp.part as the string
    to use when building the filename in wm_adsp_request_firmware_file().
    
    This leaves fwf_name entirely owned by the codec driver.
    
    It also avoids problems with freeing the pointer. With the original code
    fwf_name was either a pointer owned by the codec driver, or a kstrdup()
    created by wm_adsp. This meant wm_adsp must free it if it set it, but not
    if the codec driver set it. The code was handling this by using
    devm_kstrdup().
    But there is no absolute requirement that wm_adsp_common_init() must be
    called from probe(), so this was a pseudo-memory leak - each new call to
    wm_adsp_common_init() would allocate another block of memory but these
    would only be freed if the owning codec driver was removed.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://msgid.link/r/20240129162737.497-3-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bead6ff98689091b89591a221035d1fe90cf9cdb
Author: Sohaib Nadeem <sohaib.nadeem@amd.com>
Date:   Tue Jan 16 11:00:00 2024 -0500

    drm/amd/display: increased min_dcfclk_mhz and min_fclk_mhz
    
    [ Upstream commit 2ff33c759a4247c84ec0b7815f1f223e155ba82a ]
    
    [why]
    Originally, PMFW said min FCLK is 300Mhz, but min DCFCLK can be increased
    to 400Mhz because min FCLK is now 600Mhz so FCLK >= 1.5 * DCFCLK hardware
    requirement will still be satisfied. Increasing min DCFCLK addresses
    underflow issues (underflow occurs when phantom pipe is turned on for some
    Sub-Viewport configs).
    
    [how]
    Increasing DCFCLK by raising the min_dcfclk_mhz
    
    Reviewed-by: Chaitanya Dhere <chaitanya.dhere@amd.com>
    Reviewed-by: Alvin Lee <alvin.lee2@amd.com>
    Acked-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Sohaib Nadeem <sohaib.nadeem@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41b256f473ac0cd5b6a4973f4cd75c6103661ab5
Author: Xin Long <lucien.xin@gmail.com>
Date:   Thu Jan 25 17:29:46 2024 -0500

    netfilter: conntrack: check SCTP_CID_SHUTDOWN_ACK for vtag setting in sctp_new
    
    [ Upstream commit 6e348067ee4bc5905e35faa3a8fafa91c9124bc7 ]
    
    The annotation says in sctp_new(): "If it is a shutdown ack OOTB packet, we
    expect a return shutdown complete, otherwise an ABORT Sec 8.4 (5) and (8)".
    However, it does not check SCTP_CID_SHUTDOWN_ACK before setting vtag[REPLY]
    in the conntrack entry(ct).
    
    Because of that, if the ct in Router disappears for some reason in [1]
    with the packet sequence like below:
    
       Client > Server: sctp (1) [INIT] [init tag: 3201533963]
       Server > Client: sctp (1) [INIT ACK] [init tag: 972498433]
       Client > Server: sctp (1) [COOKIE ECHO]
       Server > Client: sctp (1) [COOKIE ACK]
       Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057809]
       Server > Client: sctp (1) [SACK] [cum ack 3075057809]
       Server > Client: sctp (1) [HB REQ]
       (the ct in Router disappears somehow)  <-------- [1]
       Client > Server: sctp (1) [HB ACK]
       Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057810]
       Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057810]
       Client > Server: sctp (1) [HB REQ]
       Client > Server: sctp (1) [DATA] (B)(E) [TSN: 3075057810]
       Client > Server: sctp (1) [HB REQ]
       Client > Server: sctp (1) [ABORT]
    
    when processing HB ACK packet in Router it calls sctp_new() to initialize
    the new ct with vtag[REPLY] set to HB_ACK packet's vtag.
    
    Later when sending DATA from Client, all the SACKs from Server will get
    dropped in Router, as the SACK packet's vtag does not match vtag[REPLY]
    in the ct. The worst thing is the vtag in this ct will never get fixed
    by the upcoming packets from Server.
    
    This patch fixes it by checking SCTP_CID_SHUTDOWN_ACK before setting
    vtag[REPLY] in the ct in sctp_new() as the annotation says. With this
    fix, it will leave vtag[REPLY] in ct to 0 in the case above, and the
    next HB REQ/ACK from Server is able to fix the vtag as its value is 0
    in nf_conntrack_sctp_packet().
    
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 17fe3616d854de8f4f0c29bcdb5de100a68bddca
Author: Will Deacon <will@kernel.org>
Date:   Fri Jan 26 15:24:10 2024 +0000

    misc: open-dice: Fix spurious lockdep warning
    
    [ Upstream commit ac9762a74c7ca7cbfcb4c65f5871373653a046ac ]
    
    When probing the open-dice driver with PROVE_LOCKING=y, lockdep
    complains that the mutex in 'drvdata->lock' has a non-static key:
    
     | INFO: trying to register non-static key.
     | The code is fine but needs lockdep annotation, or maybe
     | you didn't initialize this object before use?
     | turning off the locking correctness validator.
    
    Fix the problem by initialising the mutex memory with mutex_init()
    instead of __MUTEX_INITIALIZER().
    
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: David Brazdil <dbrazdil@google.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20240126152410.10148-1-will@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c57e5ef85c736637c36ffd44c39fa6e9c7ea4ba
Author: Brenton Simpson <appsforartists@google.com>
Date:   Tue Jan 30 13:34:16 2024 -0800

    Input: xpad - add Lenovo Legion Go controllers
    
    [ Upstream commit 80441f76ee67002437db61f3b317ed80cce085d2 ]
    
    The Lenovo Legion Go is a handheld gaming system, similar to a Steam Deck.
    It has a gamepad (including rear paddles), 3 gyroscopes, a trackpad,
    volume buttons, a power button, and 2 LED ring lights.
    
    The Legion Go firmware presents these controls as a USB hub with various
    devices attached.  In its default state, the gamepad is presented as an
    Xbox controller connected to this hub.  (By holding a combination of
    buttons, it can be changed to use the older DirectInput API.)
    
    This patch teaches the existing Xbox controller module `xpad` to bind to
    the controller in the Legion Go, which enables support for the:
    
    - directional pad,
    - analog sticks (including clicks),
    - X, Y, A, B,
    - start and select (or menu and capture),
    - shoulder buttons, and
    - rumble.
    
    The trackpad, touchscreen, volume controls, and power button are already
    supported via existing kernel modules.  Two of the face buttons, the
    gyroscopes, rear paddles, and LEDs are not.
    
    After this patch lands, the Legion Go will be mostly functional in Linux,
    out-of-the-box.  The various components of the USB hub can be synthesized
    into a single logical controller (including the additional buttons) in
    userspace with [Handheld Daemon](https://github.com/hhd-dev/hhd), which
    makes the Go fully functional.
    
    Signed-off-by: Brenton Simpson <appsforartists@google.com>
    Link: https://lore.kernel.org/r/20240118183546.418064-1-appsforartists@google.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 949296ee62db11f8afb5ea414dd317a6b9a76712
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Tue Jan 30 10:40:53 2024 +0100

    spi: sh-msiof: avoid integer overflow in constants
    
    [ Upstream commit 6500ad28fd5d67d5ca0fee9da73c463090842440 ]
    
    cppcheck rightfully warned:
    
     drivers/spi/spi-sh-msiof.c:792:28: warning: Signed integer overflow for expression '7<<29'. [integerOverflow]
     sh_msiof_write(p, SIFCTR, SIFCTR_TFWM_1 | SIFCTR_RFWM_1);
    
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://msgid.link/r/20240130094053.10672-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4dec3068eaa5b51693514d4f41ae3cc744baf4cf
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Sun Jan 28 00:32:43 2024 +0800

    ASoC: sunxi: sun4i-spdif: Add support for Allwinner H616
    
    [ Upstream commit 0adf963b8463faa44653e22e56ce55f747e68868 ]
    
    The SPDIF hardware block found in the H616 SoC has the same layout as
    the one found in the H6 SoC, except that it is missing the receiver
    side.
    
    Since the driver currently only supports the transmit function, support
    for the H616 is identical to what is currently done for the H6.
    
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Link: https://msgid.link/r/20240127163247.384439-4-wens@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7bdaff0d07505e319cf89548bc115969e9fb816
Author: Alexander Tsoy <alexander@tsoy.me>
Date:   Mon Jan 29 15:12:54 2024 +0300

    ALSA: usb-audio: Check presence of valid altsetting control
    
    [ Upstream commit 346f59d1e8ed0eed41c80e1acb657e484c308e6a ]
    
    Many devices with a single alternate setting do not have a Valid
    Alternate Setting Control and validation performed by
    validate_sample_rate_table_v2v3() doesn't work on them and is not
    really needed. So check the presense of control before sending
    altsetting validation requests.
    
    MOTU Microbook IIc is suffering the most without this check. It
    takes up to 40 seconds to bootup due to how slow it switches
    sampling rates:
    
    [ 2659.164824] usb 3-2: New USB device found, idVendor=07fd, idProduct=0004, bcdDevice= 0.60
    [ 2659.164827] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    [ 2659.164829] usb 3-2: Product: MicroBook IIc
    [ 2659.164830] usb 3-2: Manufacturer: MOTU
    [ 2659.166204] usb 3-2: Found last interface = 3
    [ 2679.322298] usb 3-2: No valid sample rate available for 1:1, assuming a firmware bug
    [ 2679.322306] usb 3-2: 1:1: add audio endpoint 0x3
    [ 2679.322321] usb 3-2: Creating new data endpoint #3
    [ 2679.322552] usb 3-2: 1:1 Set sample rate 96000, clock 1
    [ 2684.362250] usb 3-2: 2:1: cannot get freq (v2/v3): err -110
    [ 2694.444700] usb 3-2: No valid sample rate available for 2:1, assuming a firmware bug
    [ 2694.444707] usb 3-2: 2:1: add audio endpoint 0x84
    [ 2694.444721] usb 3-2: Creating new data endpoint #84
    [ 2699.482103] usb 3-2: 2:1 Set sample rate 96000, clock 1
    
    Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
    Link: https://lore.kernel.org/r/20240129121254.3454481-1-alexander@tsoy.me
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1675aae9e19e72c48e1c95338b894845944a855b
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Sun Jan 21 21:41:23 2024 +0100

    usb: ucsi_acpi: Quirk to ack a connector change ack cmd
    
    [ Upstream commit f3be347ea42dbb0358cd8b2d8dc543a23b70a976 ]
    
    The PPM on some Dell laptops seems to expect that the ACK_CC_CI
    command to clear the connector change notification is in turn
    followed by another ACK_CC_CI to acknowledge the ACK_CC_CI command
    itself. This is in violation of the UCSI spec that states:
    
        "The only notification that is not acknowledged by the OPM is
         the command completion notification for the ACK_CC_CI or the
         PPM_RESET command."
    
    Add a quirk to send this ack anyway.
    Apply the quirk to all Dell systems.
    
    On the first command that acks a connector change send a dummy
    command to determine if it runs into a timeout. Only activate
    the quirk if it does. This ensure that we do not break Dell
    systems that do not need the quirk.
    
    Signed-off-by: "Christian A. Ehrhardt" <lk@c--e.de>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240121204123.275441-4-lk@c--e.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fbd1cb2a9b77ec166eaf7931df150149116da7d1
Author: Guixin Liu <kanie@linux.alibaba.com>
Date:   Fri Jan 26 16:26:43 2024 +0800

    nvmet-tcp: fix nvme tcp ida memory leak
    
    [ Upstream commit 47c5dd66c1840524572dcdd956f4af2bdb6fbdff ]
    
    The nvmet_tcp_queue_ida should be destroy when the nvmet-tcp module
    exit.
    
    Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 13c1af5f3bc4c1959f492fbb846aee30aa1fca28
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sat Jan 13 23:46:26 2024 +0100

    regulator: pwm-regulator: Add validity checks in continuous .get_voltage
    
    [ Upstream commit c92688cac239794e4a1d976afa5203a4d3a2ac0e ]
    
    Continuous regulators can be configured to operate only in a certain
    duty cycle range (for example from 0..91%). Add a check to error out if
    the duty cycle translates to an unsupported (or out of range) voltage.
    
    Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Link: https://msgid.link/r/20240113224628.377993-2-martin.blumenstingl@googlemail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9d508c897153ae8dd79303f7f035f078139f6b49
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Thu Jan 18 11:19:29 2024 +0800

    dmaengine: ti: edma: Add some null pointer checks to the edma_probe
    
    [ Upstream commit 6e2276203ac9ff10fc76917ec9813c660f627369 ]
    
    devm_kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure. Ensure the allocation was successful
    by checking the pointer validity.
    
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Link: https://lore.kernel.org/r/20240118031929.192192-1-chentao@kylinos.cn
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e746c4e4848914fa2d1ad5192cab5c589e6be13
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Dec 23 15:16:50 2023 +0100

    Input: goodix - accept ACPI resources with gpio_count == 3 && gpio_int_idx == 0
    
    [ Upstream commit 180a8f12c21f41740fee09ca7f7aa98ff5bb99f8 ]
    
    Some devices list 3 Gpio resources in the ACPI resource list for
    the touchscreen:
    
    1. GpioInt resource pointing to the GPIO used for the interrupt
    2. GpioIo resource pointing to the reset GPIO
    3. GpioIo resource pointing to the GPIO used for the interrupt
    
    Note how the third extra GpioIo resource really is a duplicate
    of the GpioInt provided info.
    
    Ignore this extra GPIO, treating this setup the same as gpio_count == 2 &&
    gpio_int_idx == 0 fixes the touchscreen not working on the Thunderbook
    Colossus W803 rugged tablet and likely also on the CyberBook_T116K.
    
    Reported-by: Maarten van der Schrieck
    Closes: https://gitlab.com/AdyaAdya/goodix-touchscreen-linux-driver/-/issues/22
    Suggested-by: Maarten van der Schrieck
    Tested-by: Maarten van der Schrieck
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231223141650.10679-1-hdegoede@redhat.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d639102f4cbd4cb65d1225dba3b9265596aab586
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:39 2024 +0800

    ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()
    
    [ Upstream commit 832698373a25950942c04a512daa652c18a9b513 ]
    
    Places the logic for checking if the group's block bitmap is corrupt under
    the protection of the group lock to avoid allocating blocks from the group
    with a corrupted block bitmap.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-8-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f97e75fa4e12b0aa0224e83fcbda8853ac2adf36
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:38 2024 +0800

    ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()
    
    [ Upstream commit 4530b3660d396a646aad91a787b6ab37cf604b53 ]
    
    Determine if the group block bitmap is corrupted before using ac_b_ex in
    ext4_mb_try_best_found() to avoid allocating blocks from a group with a
    corrupted block bitmap in the following concurrency and making the
    situation worse.
    
    ext4_mb_regular_allocator
      ext4_lock_group(sb, group)
      ext4_mb_good_group
       // check if the group bbitmap is corrupted
      ext4_mb_complex_scan_group
       // Scan group gets ac_b_ex but doesn't use it
      ext4_unlock_group(sb, group)
                               ext4_mark_group_bitmap_corrupted(group)
                               // The block bitmap was corrupted during
                               // the group unlock gap.
      ext4_mb_try_best_found
        ext4_lock_group(ac->ac_sb, group)
        ext4_mb_use_best_found
          mb_mark_used
          // Allocating blocks in block bitmap corrupted group
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-7-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b40eb2e716b503f7a4e1090815a17b1341b2150
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:37 2024 +0800

    ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt
    
    [ Upstream commit 993bf0f4c393b3667830918f9247438a8f6fdb5b ]
    
    Determine if bb_fragments is 0 instead of determining bb_free to eliminate
    the risk of dividing by zero when the block bitmap is corrupted.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-6-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a600d7f0c1d0872131186a42f30e77700fef1e14
Author: Phoenix Chen <asbeltogf@gmail.com>
Date:   Fri Jan 26 17:53:08 2024 +0800

    platform/x86: touchscreen_dmi: Add info for the TECLAST X16 Plus tablet
    
    [ Upstream commit 1abdf288b0ef5606f76b6e191fa6df05330e3d7e ]
    
    Add touch screen info for TECLAST X16 Plus tablet.
    
    Signed-off-by: Phoenix Chen <asbeltogf@gmail.com>
    Link: https://lore.kernel.org/r/20240126095308.5042-1-asbeltogf@gmail.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c292c2f902760fcd82cbf8609ca766ea89fe34e
Author: Huang Pei <huangpei@loongson.cn>
Date:   Tue Jan 23 09:47:57 2024 +0800

    MIPS: reserve exception vector space ONLY ONCE
    
    [ Upstream commit abcabb9e30a1f9a69c76776f8abffc31c377b542 ]
    
    "cpu_probe" is called both by BP and APs, but reserving exception vector
    (like 0x0-0x1000) called by "cpu_probe" need once and calling on APs is
    too late since memblock is unavailable at that time.
    
    So, reserve exception vector ONLY by BP.
    
    Suggested-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Huang Pei <huangpei@loongson.cn>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f48a6eb2e5e88c7548a8f20f6ad8131b06427655
Author: Lennert Buytenhek <kernel@wantstofly.org>
Date:   Thu Jan 25 17:04:01 2024 +0200

    ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers
    
    [ Upstream commit 20730e9b277873deeb6637339edcba64468f3da3 ]
    
    With one of the on-board ASM1061 AHCI controllers (1b21:0612) on an
    ASUSTeK Pro WS WRX80E-SAGE SE WIFI mainboard, a controller hang was
    observed that was immediately preceded by the following kernel
    messages:
    
    ahci 0000:28:00.0: Using 64-bit DMA addresses
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00000 flags=0x0000]
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00300 flags=0x0000]
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00380 flags=0x0000]
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00400 flags=0x0000]
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00680 flags=0x0000]
    ahci 0000:28:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0035 address=0x7fffff00700 flags=0x0000]
    
    The first message is produced by code in drivers/iommu/dma-iommu.c
    which is accompanied by the following comment that seems to apply:
    
            /*
             * Try to use all the 32-bit PCI addresses first. The original SAC vs.
             * DAC reasoning loses relevance with PCIe, but enough hardware and
             * firmware bugs are still lurking out there that it's safest not to
             * venture into the 64-bit space until necessary.
             *
             * If your device goes wrong after seeing the notice then likely either
             * its driver is not setting DMA masks accurately, the hardware has
             * some inherent bug in handling >32-bit addresses, or not all the
             * expected address bits are wired up between the device and the IOMMU.
             */
    
    Asking the ASM1061 on a discrete PCIe card to DMA from I/O virtual
    address 0xffffffff00000000 produces the following I/O page faults:
    
    vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000000 flags=0x0010]
    vfio-pci 0000:07:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0x7ff00000500 flags=0x0010]
    
    Note that the upper 21 bits of the logged DMA address are zero.  (When
    asking a different PCIe device in the same PCIe slot to DMA to the
    same I/O virtual address, we do see all the upper 32 bits of the DMA
    address as 1, so this is not an issue with the chipset or IOMMU
    configuration on the test system.)
    
    Also, hacking libahci to always set the upper 21 bits of all DMA
    addresses to 1 produces no discernible effect on the behavior of the
    ASM1061, and mkfs/mount/scrub/etc work as without this hack.
    
    This all strongly suggests that the ASM1061 has a 43 bit DMA address
    limit, and this commit therefore adds a quirk to deal with this limit.
    
    This issue probably applies to (some of) the other supported ASMedia
    parts as well, but we limit it to the PCI IDs known to refer to
    ASM1061 parts, as that's the only part we know for sure to be affected
    by this issue at this point.
    
    Link: https://lore.kernel.org/linux-ide/ZaZ2PIpEId-rl6jv@wantstofly.org/
    Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
    [cassel: drop date from error messages in commit log]
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2d623c94fbba3554f4446ba6f3c764994e8b0d26
Author: Maksim Kiselev <bigunclemax@gmail.com>
Date:   Wed Jan 24 10:24:36 2024 +0300

    aoe: avoid potential deadlock at set_capacity
    
    [ Upstream commit e169bd4fb2b36c4b2bee63c35c740c85daeb2e86 ]
    
    Move set_capacity() outside of the section procected by (&d->lock).
    To avoid possible interrupt unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
    [1] lock(&bdev->bd_size_lock);
                                    local_irq_disable();
                                [2] lock(&d->lock);
                                [3] lock(&bdev->bd_size_lock);
       <Interrupt>
    [4]  lock(&d->lock);
    
      *** DEADLOCK ***
    
    Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity().
    [2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()
    is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call.
    In this situation an attempt to acquire [4]lock(&d->lock) from
    aoecmd_cfg_rsp() will lead to deadlock.
    
    So the simplest solution is breaking lock dependency
    [2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity()
    outside.
    
    Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20240124072436.3745720-2-bigunclemax@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41e137c2c75aed1b5f8595f2b2f8970539ba56bf
Author: Conrad Kostecki <conikost@gentoo.org>
Date:   Tue Jan 23 19:30:02 2024 +0100

    ahci: asm1166: correct count of reported ports
    
    [ Upstream commit 0077a504e1a4468669fd2e011108db49133db56e ]
    
    The ASM1166 SATA host controller always reports wrongly,
    that it has 32 ports. But in reality, it only has six ports.
    
    This seems to be a hardware issue, as all tested ASM1166
    SATA host controllers reports such high count of ports.
    
    Example output: ahci 0000:09:00.0: AHCI 0001.0301
    32 slots 32 ports 6 Gbps 0xffffff3f impl SATA mode.
    
    By adjusting the port_map, the count is limited to six ports.
    
    New output: ahci 0000:09:00.0: AHCI 0001.0301
    32 slots 32 ports 6 Gbps 0x3f impl SATA mode.
    
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=211873
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218346
    Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2aa77b5d8e3f521a893de21bda5d823649d1c09
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Sun Jan 21 03:32:45 2024 +0000

    cifs: translate network errors on send to -ECONNABORTED
    
    [ Upstream commit a68106a6928e0a6680f12bcc7338c0dddcfe4d11 ]
    
    When the network stack returns various errors, we today bubble
    up the error to the user (in case of soft mounts).
    
    This change translates all network errors except -EINTR and
    -EAGAIN to -ECONNABORTED. A similar approach is taken when
    we receive network errors when reading from the socket.
    
    The change also forces the cifsd thread to reconnect during
    it's next activity.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bba595eb1422749ad9aea7e98991fa9db04bb26d
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Jan 23 15:47:34 2024 -0800

    smb: Work around Clang __bdos() type confusion
    
    [ Upstream commit 8deb05c84b63b4fdb8549e08942867a68924a5b8 ]
    
    Recent versions of Clang gets confused about the possible size of the
    "user" allocation, and CONFIG_FORTIFY_SOURCE ends up emitting a
    warning[1]:
    
    repro.c:126:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
      126 |                         __write_overflow_field(p_size_field, size);
          |                         ^
    
    for this memset():
    
            int len;
            __le16 *user;
            ...
            len = ses->user_name ? strlen(ses->user_name) : 0;
            user = kmalloc(2 + (len * 2), GFP_KERNEL);
            ...
            if (len) {
                    ...
            } else {
                    memset(user, '\0', 2);
            }
    
    While Clang works on this bug[2], switch to using a direct assignment,
    which avoids memset() entirely which both simplifies the code and silences
    the false positive warning. (Making "len" size_t also silences the
    warning, but the direct assignment seems better.)
    
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Closes: https://github.com/ClangBuiltLinux/linux/issues/1966 [1]
    Link: https://github.com/llvm/llvm-project/issues/77813 [2]
    Cc: Steve French <sfrench@samba.org>
    Cc: Paulo Alcantara <pc@manguebit.com>
    Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
    Cc: Shyam Prasad N <sprasad@microsoft.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: linux-cifs@vger.kernel.org
    Cc: llvm@lists.linux.dev
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8fc80874103a5c20aebdc2401361aa01c817f75b
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Sun Jan 21 21:26:34 2024 +0100

    block: Fix WARNING in _copy_from_iter
    
    [ Upstream commit 13f3956eb5681a4045a8dfdef48df5dc4d9f58a6 ]
    
    Syzkaller reports a warning in _copy_from_iter because an
    iov_iter is supposedly used in the wrong direction. The reason
    is that syzcaller managed to generate a request with
    a transfer direction of SG_DXFER_TO_FROM_DEV. This instructs
    the kernel to copy user buffers into the kernel, read into
    the copied buffers and then copy the data back to user space.
    
    Thus the iovec is used in both directions.
    
    Detect this situation in the block layer and construct a new
    iterator with the correct direction for the copy-in.
    
    Reported-by: syzbot+a532b03fdfee2c137666@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/lkml/0000000000009b92c10604d7a5e9@google.com/t/
    Reported-by: syzbot+63dec323ac56c28e644f@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/lkml/0000000000003faaa105f6e7c658@google.com/T/
    Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20240121202634.275068-1-lk@c--e.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f19361d570c67e7e014896fa2dacd7d721bf0aa8
Author: Devyn Liu <liudingyuan@huawei.com>
Date:   Tue Jan 23 15:11:49 2024 +0800

    spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
    
    [ Upstream commit de8b6e1c231a95abf95ad097b993d34b31458ec9 ]
    
    Return IRQ_NONE from the interrupt handler when no interrupt was
    detected. Because an empty interrupt will cause a null pointer error:
    
        Unable to handle kernel NULL pointer dereference at virtual
      address 0000000000000008
        Call trace:
            complete+0x54/0x100
            hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]
            __handle_irq_event_percpu+0x64/0x1e0
            handle_irq_event+0x7c/0x1cc
    
    Signed-off-by: Devyn Liu <liudingyuan@huawei.com>
    Link: https://msgid.link/r/20240123071149.917678-1-liudingyuan@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f329523f6a65c3bbce913ad35473d83a319d5d99
Author: Fullway Wang <fullwaywang@outlook.com>
Date:   Thu Jan 18 14:24:43 2024 +0800

    fbdev: sis: Error out if pixclock equals zero
    
    [ Upstream commit e421946be7d9bf545147bea8419ef8239cb7ca52 ]
    
    The userspace program could pass any values to the driver through
    ioctl() interface. If the driver doesn't check the value of pixclock,
    it may cause divide-by-zero error.
    
    In sisfb_check_var(), var->pixclock is used as a divisor to caculate
    drate before it is checked against zero. Fix this by checking it
    at the beginning.
    
    This is similar to CVE-2022-3061 in i740fb which was fixed by
    commit 15cf0b8.
    
    Signed-off-by: Fullway Wang <fullwaywang@outlook.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 070398d32c5f3ab0e890374904ad94551c76aec4
Author: Fullway Wang <fullwaywang@outlook.com>
Date:   Thu Jan 18 11:49:40 2024 +0800

    fbdev: savage: Error out if pixclock equals zero
    
    [ Upstream commit 04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288 ]
    
    The userspace program could pass any values to the driver through
    ioctl() interface. If the driver doesn't check the value of pixclock,
    it may cause divide-by-zero error.
    
    Although pixclock is checked in savagefb_decode_var(), but it is not
    checked properly in savagefb_probe(). Fix this by checking whether
    pixclock is zero in the function savagefb_check_var() before
    info->var.pixclock is used as the divisor.
    
    This is similar to CVE-2022-3061 in i740fb which was fixed by
    commit 15cf0b8.
    
    Signed-off-by: Fullway Wang <fullwaywang@outlook.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb39bb548bf974acad7bd6780fe11f9e6652d696
Author: Felix Fietkau <nbd@nbd.name>
Date:   Thu Jan 4 19:10:59 2024 +0100

    wifi: mac80211: fix race condition on enabling fast-xmit
    
    [ Upstream commit bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f ]
    
    fast-xmit must only be enabled after the sta has been uploaded to the driver,
    otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls
    to the driver, leading to potential crashes because of uninitialized drv_priv
    data.
    Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.
    
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Link: https://msgid.link/20240104181059.84032-1-nbd@nbd.name
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e540c44983871b27db2a2d16bb9b25e5ed7cc748
Author: Michal Kazior <michal@plume.com>
Date:   Tue Jan 16 14:22:57 2024 +0000

    wifi: cfg80211: fix missing interfaces when dumping
    
    [ Upstream commit a6e4f85d3820d00694ed10f581f4c650445dbcda ]
    
    The nl80211_dump_interface() supports resumption
    in case nl80211_send_iface() doesn't have the
    resources to complete its work.
    
    The logic would store the progress as iteration
    offsets for rdev and wdev loops.
    
    However the logic did not properly handle
    resumption for non-last rdev. Assuming a system
    with 2 rdevs, with 2 wdevs each, this could
    happen:
    
     dump(cb=[0, 0]):
      if_start=cb[1] (=0)
      send rdev0.wdev0 -> ok
      send rdev0.wdev1 -> yield
      cb[1] = 1
    
     dump(cb=[0, 1]):
      if_start=cb[1] (=1)
      send rdev0.wdev1 -> ok
      // since if_start=1 the rdev0.wdev0 got skipped
      // through if_idx < if_start
      send rdev1.wdev1 -> ok
    
    The if_start needs to be reset back to 0 upon wdev
    loop end.
    
    The problem is actually hard to hit on a desktop,
    and even on most routers. The prerequisites for
    this manifesting was:
     - more than 1 wiphy
     - a few handful of interfaces
     - dump without rdev or wdev filter
    
    I was seeing this with 4 wiphys 9 interfaces each.
    It'd miss 6 interfaces from the last wiphy
    reported to userspace.
    
    Signed-off-by: Michal Kazior <michal@plume.com>
    Link: https://msgid.link/20240116142340.89678-1-kazikcz@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3dbfb9d11fceb8bda2a4f0e5d44ae7363ca9bd1
Author: Vinod Koul <vkoul@kernel.org>
Date:   Fri Jan 19 18:10:44 2024 +0530

    dmaengine: fsl-qdma: increase size of 'irq_name'
    
    [ Upstream commit 6386f6c995b3ab91c72cfb76e4465553c555a8da ]
    
    We seem to have hit warnings of 'output may be truncated' which is fixed
    by increasing the size of 'irq_name'
    
    drivers/dma/fsl-qdma.c: In function ‘fsl_qdma_irq_init’:
    drivers/dma/fsl-qdma.c:824:46: error: ‘%d’ directive writing between 1 and 11 bytes into a region of size 10 [-Werror=format-overflow=]
      824 |                 sprintf(irq_name, "qdma-queue%d", i);
          |                                              ^~
    drivers/dma/fsl-qdma.c:824:35: note: directive argument in the range [-2147483641, 2147483646]
      824 |                 sprintf(irq_name, "qdma-queue%d", i);
          |                                   ^~~~~~~~~~~~~~
    drivers/dma/fsl-qdma.c:824:17: note: ‘sprintf’ output between 12 and 22 bytes into a destination of size 20
      824 |                 sprintf(irq_name, "qdma-queue%d", i);
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8dda42b1f2e40b7fdd6a039de8558448b9016748
Author: Vinod Koul <vkoul@kernel.org>
Date:   Fri Jan 19 18:10:44 2024 +0530

    dmaengine: shdma: increase size of 'dev_id'
    
    [ Upstream commit 404290240827c3bb5c4e195174a8854eef2f89ac ]
    
    We seem to have hit warnings of 'output may be truncated' which is fixed
    by increasing the size of 'dev_id'
    
    drivers/dma/sh/shdmac.c: In function ‘sh_dmae_probe’:
    drivers/dma/sh/shdmac.c:541:34: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 9 [-Werror=format-truncation=]
      541 |                          "sh-dmae%d.%d", pdev->id, id);
          |                                  ^~
    In function ‘sh_dmae_chan_probe’,
        inlined from ‘sh_dmae_probe’ at drivers/dma/sh/shdmac.c:845:9:
    drivers/dma/sh/shdmac.c:541:26: note: directive argument in the range [0, 2147483647]
      541 |                          "sh-dmae%d.%d", pdev->id, id);
          |                          ^~~~~~~~~~~~~~
    drivers/dma/sh/shdmac.c:541:26: note: directive argument in the range [0, 19]
    drivers/dma/sh/shdmac.c:540:17: note: ‘snprintf’ output between 11 and 21 bytes into a destination of size 16
      540 |                 snprintf(sh_chan->dev_id, sizeof(sh_chan->dev_id),
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      541 |                          "sh-dmae%d.%d", pdev->id, id);
          |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2cb83539cdb54ed693e28e8569e54c49ffb6d56
Author: Shyam Prasad N <sprasad@microsoft.com>
Date:   Wed Jan 17 05:55:39 2024 +0000

    cifs: open_cached_dir should not rely on primary channel
    
    [ Upstream commit 936eba9cfb5cfbf6a2c762cd163605f2b784e03e ]
    
    open_cached_dir today selects ses->server a.k.a primary channel
    to send requests. When multichannel is used, the primary
    channel maybe down. So it does not make sense to rely only
    on that channel.
    
    This fix makes this function pick a channel with the standard
    helper function cifs_pick_channel.
    
    Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e717bd412001495f17400bfc09f606f1b594ef5a
Author: Dmitry Bogdanov <d.bogdanov@yadro.com>
Date:   Thu Jan 11 15:59:41 2024 +0300

    scsi: target: core: Add TMF to tmr_list handling
    
    [ Upstream commit 83ab68168a3d990d5ff39ab030ad5754cbbccb25 ]
    
    An abort that is responded to by iSCSI itself is added to tmr_list but does
    not go to target core. A LUN_RESET that goes through tmr_list takes a
    refcounter on the abort and waits for completion. However, the abort will
    be never complete because it was not started in target core.
    
     Unable to locate ITT: 0x05000000 on CID: 0
     Unable to locate RefTaskTag: 0x05000000 on CID: 0.
     wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop
     wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop
    ...
     INFO: task kworker/0:2:49 blocked for more than 491 seconds.
     task:kworker/0:2     state:D stack:    0 pid:   49 ppid:     2 flags:0x00000800
     Workqueue: events target_tmr_work [target_core_mod]
    Call Trace:
     __switch_to+0x2c4/0x470
     _schedule+0x314/0x1730
     schedule+0x64/0x130
     schedule_timeout+0x168/0x430
     wait_for_completion+0x140/0x270
     target_put_cmd_and_wait+0x64/0xb0 [target_core_mod]
     core_tmr_lun_reset+0x30/0xa0 [target_core_mod]
     target_tmr_work+0xc8/0x1b0 [target_core_mod]
     process_one_work+0x2d4/0x5d0
     worker_thread+0x78/0x6c0
    
    To fix this, only add abort to tmr_list if it will be handled by target
    core.
    
    Signed-off-by: Dmitry Bogdanov <d.bogdanov@yadro.com>
    Link: https://lore.kernel.org/r/20240111125941.8688-1-d.bogdanov@yadro.com
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9ae228cfd1a4e292eb9680744a40a56299aa42f
Author: Hector Martin <marcan@marcan.st>
Date:   Sun Oct 29 18:07:04 2023 +0100

    dmaengine: apple-admac: Keep upper bits of REG_BUS_WIDTH
    
    [ Upstream commit 306f5df81fcc89b462fbeb9dbe26d9a8ad7c7582 ]
    
    For RX channels, REG_BUS_WIDTH seems to default to a value of 0xf00, and
    macOS preserves the upper bits when setting the configuration in the
    lower ones. If we reset the upper bits to 0, this causes framing errors
    on suspend/resume (the data stream "tears" and channels get swapped
    around). Keeping the upper bits untouched, like the macOS driver does,
    fixes this issue.
    
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Reviewed-by: Martin Povišer <povik+lin@cutebit.org>
    Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
    Link: https://lore.kernel.org/r/20231029170704.82238-1-povik+lin@cutebit.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d27ac1779092446afb6e21666c70b7b8627d512
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Fri Jan 12 19:37:29 2024 +0100

    riscv/efistub: Ensure GP-relative addressing is not used
    
    commit afb2a4fb84555ef9e61061f6ea63ed7087b295d5 upstream.
    
    The cflags for the RISC-V efistub were missing -mno-relax, thus were
    under the risk that the compiler could use GP-relative addressing. That
    happened for _edata with binutils-2.41 and kernel 6.1, causing the
    relocation to fail due to an invalid kernel_size in handle_kernel_image.
    It was not yet observed with newer versions, but that may just be luck.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6967ddd378e9d63f5c59dbace8b2cf963d6d6a0d
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Jan 26 11:40:37 2024 +0300

    PCI: dwc: Fix a 64bit bug in dw_pcie_ep_raise_msix_irq()
    
    commit b5d1b4b46f856da1473c7ba9a5cdfcb55c9b2478 upstream.
    
    The "msg_addr" variable is u64.  However, the "aligned_offset" is an
    unsigned int.  This means that when the code does:
    
      msg_addr &= ~aligned_offset;
    
    it will unintentionally zero out the high 32 bits.  Use ALIGN_DOWN() to do
    the alignment instead.
    
    Fixes: 2217fffcd63f ("PCI: dwc: endpoint: Fix dw_pcie_ep_raise_msix_irq() alignment support")
    Link: https://lore.kernel.org/r/af59c7ad-ab93-40f7-ad4a-7ac0b14d37f5@moroto.mountain
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Niklas Cassel <cassel@kernel.org>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5552b7bf26d9ad3e1ded3ffd0caeb63257a3168f
Author: Cyril Hrubis <chrubis@suse.cz>
Date:   Wed Aug 2 17:19:06 2023 +0200

    sched/rt: sysctl_sched_rr_timeslice show default timeslice after reset
    
    commit c1fc6484e1fb7cc2481d169bfef129a1b0676abe upstream.
    
    The sched_rr_timeslice can be reset to default by writing value that is
    <= 0. However after reading from this file we always got the last value
    written, which is not useful at all.
    
    $ echo -1 > /proc/sys/kernel/sched_rr_timeslice_ms
    $ cat /proc/sys/kernel/sched_rr_timeslice_ms
    -1
    
    Fix this by setting the variable that holds the sysctl file value to the
    jiffies_to_msecs(RR_TIMESLICE) in case that <= 0 value was written.
    
    Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Petr Vorel <pvorel@suse.cz>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Tested-by: Petr Vorel <pvorel@suse.cz>
    Cc: Mahmoud Adam <mngyadam@amazon.com>
    Link: https://lore.kernel.org/r/20230802151906.25258-3-chrubis@suse.cz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89bebf2753115fed2626402d9049436a3e7ba616
Author: Cyril Hrubis <chrubis@suse.cz>
Date:   Mon Oct 2 13:55:51 2023 +0200

    sched/rt: Disallow writing invalid values to sched_rt_period_us
    
    commit 079be8fc630943d9fc70a97807feb73d169ee3fc upstream.
    
    The validation of the value written to sched_rt_period_us was broken
    because:
    
      - the sysclt_sched_rt_period is declared as unsigned int
      - parsed by proc_do_intvec()
      - the range is asserted after the value parsed by proc_do_intvec()
    
    Because of this negative values written to the file were written into a
    unsigned integer that were later on interpreted as large positive
    integers which did passed the check:
    
      if (sysclt_sched_rt_period <= 0)
            return EINVAL;
    
    This commit fixes the parsing by setting explicit range for both
    perid_us and runtime_us into the sched_rt_sysctls table and processes
    the values with proc_dointvec_minmax() instead.
    
    Alternatively if we wanted to use full range of unsigned int for the
    period value we would have to split the proc_handler and use
    proc_douintvec() for it however even the
    Documentation/scheduller/sched-rt-group.rst describes the range as 1 to
    INT_MAX.
    
    As far as I can tell the only problem this causes is that the sysctl
    file allows writing negative values which when read back may confuse
    userspace.
    
    There is also a LTP test being submitted for these sysctl files at:
    
      http://patchwork.ozlabs.org/project/ltp/patch/20230901144433.2526-1-chrubis@suse.cz/
    
    Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20231002115553.3007-2-chrubis@suse.cz
    Cc: Mahmoud Adam <mngyadam@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a41f6e170b852d2c68fc76012c49ec3332b0edcc
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Tue Feb 14 08:49:13 2023 -0500

    net/sched: Retire dsmark qdisc
    
    commit bbe77c14ee6185a61ba6d5e435c1cbb489d2a9ed upstream.
    
    The dsmark qdisc has served us well over the years for diffserv but has not
    been getting much attention due to other more popular approaches to do diffserv
    services. Most recently it has become a shooting target for syzkaller. For this
    reason, we are retiring it.
    
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Acked-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09038f47e45cd5dbb02315db2134403a6b160ceb
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Tue Feb 14 08:49:12 2023 -0500

    net/sched: Retire ATM qdisc
    
    commit fb38306ceb9e770adfb5ffa6e3c64047b55f7a07 upstream.
    
    The ATM qdisc has served us well over the years but has not been getting much
    TLC due to lack of known users. Most recently it has become a shooting target
    for syzkaller. For this reason, we are retiring it.
    
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Acked-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 02149c7cd115d3c82d20f758be4c9013d1128928
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Tue Feb 14 08:49:11 2023 -0500

    net/sched: Retire CBQ qdisc
    
    commit 051d442098421c28c7951625652f61b1e15c4bd5 upstream.
    
    While this amazing qdisc has served us well over the years it has not been
    getting any tender love and care and has bitrotted over time.
    It has become mostly a shooting target for syzkaller lately.
    For this reason, we are retiring it. Goodbye CBQ - we loved you.
    
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Acked-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>