Linux 5.15.149

 
ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events [+ + +]
Author: Shuai Xue <xueshuai@linux.alibaba.com>
Date:   Mon Dec 18 14:45:18 2023 +0800

    ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
    
    [ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ]
    
    There are two major types of uncorrected recoverable (UCR) errors :
    
     - Synchronous error: The error is detected and raised at the point of
       the consumption in the execution flow, e.g. when a CPU tries to
       access a poisoned cache line. The CPU will take a synchronous error
       exception such as Synchronous External Abort (SEA) on Arm64 and
       Machine Check Exception (MCE) on X86. OS requires to take action (for
       example, offline failure page/kill failure thread) to recover this
       uncorrectable error.
    
     - Asynchronous error: The error is detected out of processor execution
       context, e.g. when an error is detected by a background scrubber.
       Some data in the memory are corrupted. But the data have not been
       consumed. OS is optional to take action to recover this uncorrectable
       error.
    
    When APEI firmware first is enabled, a platform may describe one error
    source for the handling of synchronous errors (e.g. MCE or SEA notification
    ), or for handling asynchronous errors (e.g. SCI or External Interrupt
    notification). In other words, we can distinguish synchronous errors by
    APEI notification. For synchronous errors, kernel will kill the current
    process which accessing the poisoned page by sending SIGBUS with
    BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the
    process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in
    early kill mode. However, the GHES driver always sets mf_flags to 0 so that
    all synchronous errors are handled as asynchronous errors in memory failure.
    
    To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
    events.
    
    Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
    Tested-by: Ma Wupeng <mawupeng1@huawei.com>
    Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Reviewed-by: Xiaofei Tan <tanxiaofei@huawei.com>
    Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
    Reviewed-by: James Morse <james.morse@arm.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: extlog: fix NULL pointer dereference check [+ + +]
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Mon Dec 4 13:00:37 2023 -0500

    ACPI: extlog: fix NULL pointer dereference check
    
    [ Upstream commit 72d9b9747e78979510e9aafdd32eb99c7aa30dd1 ]
    
    The gcc plugin -fanalyzer [1] tries to detect various
    patterns of incorrect behaviour.  The tool reports:
    
    drivers/acpi/acpi_extlog.c: In function ‘extlog_exit’:
    drivers/acpi/acpi_extlog.c:307:12: warning: check of ‘extlog_l1_addr’ for NULL after already dereferencing it [-Wanalyzer-deref-before-check]
        |
        |  306 |         ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN;
        |      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
        |      |                                                  |
        |      |                                                  (1) pointer ‘extlog_l1_addr’ is dereferenced here
        |  307 |         if (extlog_l1_addr)
        |      |            ~
        |      |            |
        |      |            (2) pointer ‘extlog_l1_addr’ is checked for NULL here but it was already dereferenced at (1)
        |
    
    Fix the NULL pointer dereference check in extlog_exit().
    
    Link: https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Static-Analyzer-Options.html # [1]
    
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: video: Add quirk for the Colorful X15 AT 23 Laptop [+ + +]
Author: Yuluo Qiu <qyl27@outlook.com>
Date:   Sun Nov 26 21:59:13 2023 +0800

    ACPI: video: Add quirk for the Colorful X15 AT 23 Laptop
    
    [ Upstream commit 143176a46bdd3bfbe9ba2462bf94458e80d65ebf ]
    
    The Colorful X15 AT 23 ACPI video-bus device report spurious
    ACPI_VIDEO_NOTIFY_CYCLE events resulting in spurious KEY_SWITCHVIDEOMODE
    events being reported to userspace (and causing trouble there) when
    an external screen plugged in.
    
    Add a quirk setting the report_key_events mask to
    REPORT_BRIGHTNESS_KEY_EVENTS so that the ACPI_VIDEO_NOTIFY_CYCLE
    events will be ignored, while still reporting brightness up/down
    hotkey-presses to userspace normally.
    
    Signed-off-by: Yuluo Qiu <qyl27@outlook.com>
    Co-developed-by: Celeste Liu <CoelacanthusHex@gmail.com>
    Signed-off-by: Celeste Liu <CoelacanthusHex@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Sat Feb 3 10:31:49 2024 -0800

    af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.
    
    [ Upstream commit 1279f9d9dec2d7462823a18c29ad61359e0a007d ]
    
    syzbot reported a warning [0] in __unix_gc() with a repro, which
    creates a socketpair and sends one socket's fd to itself using the
    peer.
    
      socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
      sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}],
              msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,
                                          cmsg_type=SCM_RIGHTS, cmsg_data=[3]}],
              msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1
    
    This forms a self-cyclic reference that GC should finally untangle
    but does not due to lack of MSG_OOB handling, resulting in memory
    leak.
    
    Recently, commit 11498715f266 ("af_unix: Remove io_uring code for
    GC.") removed io_uring's dead code in GC and revealed the problem.
    
    The code was executed at the final stage of GC and unconditionally
    moved all GC candidates from gc_candidates to gc_inflight_list.
    That papered over the reported problem by always making the following
    WARN_ON_ONCE(!list_empty(&gc_candidates)) false.
    
    The problem has been there since commit 2aab4b969002 ("af_unix: fix
    struct pid leaks in OOB support") added full scm support for MSG_OOB
    while fixing another bug.
    
    To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb
    if the socket still exists in gc_candidates after purging collected skb.
    
    Then, we need to set NULL to oob_skb before calling kfree_skb() because
    it calls last fput() and triggers unix_release_sock(), where we call
    duplicate kfree_skb(u->oob_skb) if not NULL.
    
    Note that the leaked socket remained being linked to a global list, so
    kmemleak also could not detect it.  We need to check /proc/net/protocol
    to notice the unfreed socket.
    
    [0]:
    WARNING: CPU: 0 PID: 2863 at net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345
    Modules linked in:
    CPU: 0 PID: 2863 Comm: kworker/u4:11 Not tainted 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
    Workqueue: events_unbound __unix_gc
    RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345
    Code: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8
    RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX: ffffffff816c493e
    RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30
    RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66
    R10: 0000000000000003 R11: 0000000000000002 R12: dffffc0000000000
    R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001
    FS:  0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     process_one_work+0x889/0x15e0 kernel/workqueue.c:2633
     process_scheduled_works kernel/workqueue.c:2706 [inline]
     worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787
     kthread+0x2c6/0x3b0 kernel/kthread.c:388
     ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242
     </TASK>
    
    Reported-by: syzbot+fa3ef895554bdbfd1183@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=fa3ef895554bdbfd1183
    Fixes: 2aab4b969002 ("af_unix: fix struct pid leaks in OOB support")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240203183149.63573-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: fix lockdep positive in sk_diag_dump_icons() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 30 18:42:35 2024 +0000

    af_unix: fix lockdep positive in sk_diag_dump_icons()
    
    [ Upstream commit 4d322dce82a1d44f8c83f0f54f95dd1b8dcf46c9 ]
    
    syzbot reported a lockdep splat [1].
    
    Blamed commit hinted about the possible lockdep
    violation, and code used unix_state_lock_nested()
    in an attempt to silence lockdep.
    
    It is not sufficient, because unix_state_lock_nested()
    is already used from unix_state_double_lock().
    
    We need to use a separate subclass.
    
    This patch adds a distinct enumeration to make things
    more explicit.
    
    Also use swap() in unix_state_double_lock() as a clean up.
    
    v2: add a missing inline keyword to unix_state_lock_nested()
    
    [1]
    WARNING: possible circular locking dependency detected
    6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 Not tainted
    
    syz-executor.1/2542 is trying to acquire lock:
     ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}, at: skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863
    
    but task is already holding lock:
     ffff88808b5dfe70 (&u->lock/1){+.+.}-{2:2}, at: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (&u->lock/1){+.+.}-{2:2}:
            lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
            _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378
            sk_diag_dump_icons net/unix/diag.c:87 [inline]
            sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157
            sk_diag_dump net/unix/diag.c:196 [inline]
            unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220
            netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264
            __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370
            netlink_dump_start include/linux/netlink.h:338 [inline]
            unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319
           sock_diag_rcv_msg+0xe3/0x400
            netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543
            sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280
            netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
            netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367
            netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908
            sock_sendmsg_nosec net/socket.c:730 [inline]
            __sock_sendmsg net/socket.c:745 [inline]
            sock_write_iter+0x39a/0x520 net/socket.c:1160
            call_write_iter include/linux/fs.h:2085 [inline]
            new_sync_write fs/read_write.c:497 [inline]
            vfs_write+0xa74/0xca0 fs/read_write.c:590
            ksys_write+0x1a0/0x2c0 fs/read_write.c:643
            do_syscall_x64 arch/x86/entry/common.c:52 [inline]
            do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
           entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    -> #0 (rlock-AF_UNIX){+.+.}-{2:2}:
            check_prev_add kernel/locking/lockdep.c:3134 [inline]
            check_prevs_add kernel/locking/lockdep.c:3253 [inline]
            validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869
            __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137
            lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
            __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
            _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162
            skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863
            unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112
            sock_sendmsg_nosec net/socket.c:730 [inline]
            __sock_sendmsg net/socket.c:745 [inline]
            ____sys_sendmsg+0x592/0x890 net/socket.c:2584
            ___sys_sendmsg net/socket.c:2638 [inline]
            __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724
            __do_sys_sendmmsg net/socket.c:2753 [inline]
            __se_sys_sendmmsg net/socket.c:2750 [inline]
            __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750
            do_syscall_x64 arch/x86/entry/common.c:52 [inline]
            do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
           entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&u->lock/1);
                                   lock(rlock-AF_UNIX);
                                   lock(&u->lock/1);
      lock(rlock-AF_UNIX);
    
     *** DEADLOCK ***
    
    1 lock held by syz-executor.1/2542:
      #0: ffff88808b5dfe70 (&u->lock/1){+.+.}-{2:2}, at: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089
    
    stack backtrace:
    CPU: 1 PID: 2542 Comm: syz-executor.1 Not tainted 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
      check_noncircular+0x366/0x490 kernel/locking/lockdep.c:2187
      check_prev_add kernel/locking/lockdep.c:3134 [inline]
      check_prevs_add kernel/locking/lockdep.c:3253 [inline]
      validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869
      __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137
      lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
      __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
      _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162
      skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863
      unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg net/socket.c:745 [inline]
      ____sys_sendmsg+0x592/0x890 net/socket.c:2584
      ___sys_sendmsg net/socket.c:2638 [inline]
      __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724
      __do_sys_sendmmsg net/socket.c:2753 [inline]
      __se_sys_sendmmsg net/socket.c:2750 [inline]
      __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    RIP: 0033:0x7f26d887cda9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f26d95a60c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
    RAX: ffffffffffffffda RBX: 00007f26d89abf80 RCX: 00007f26d887cda9
    RDX: 000000000000003e RSI: 00000000200bd000 RDI: 0000000000000004
    RBP: 00007f26d88c947a R08: 0000000000000000 R09: 0000000000000000
    R10: 00000000000008c0 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000000b R14: 00007f26d89abf80 R15: 00007ffcfe081a68
    
    Fixes: 2aac7a2cb0d9 ("unix_diag: Pending connections IDs NLA")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240130184235.1620738-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Fix task hung while purging oob_skb in GC. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Fri Feb 9 14:04:53 2024 -0800

    af_unix: Fix task hung while purging oob_skb in GC.
    
    commit 25236c91b5ab4a26a56ba2e79b8060cf4e047839 upstream.
    
    syzbot reported a task hung; at the same time, GC was looping infinitely
    in list_for_each_entry_safe() for OOB skb.  [0]
    
    syzbot demonstrated that the list_for_each_entry_safe() was not actually
    safe in this case.
    
    A single skb could have references for multiple sockets.  If we free such
    a skb in the list_for_each_entry_safe(), the current and next sockets could
    be unlinked in a single iteration.
    
    unix_notinflight() uses list_del_init() to unlink the socket, so the
    prefetched next socket forms a loop itself and list_for_each_entry_safe()
    never stops.
    
    Here, we must use while() and make sure we always fetch the first socket.
    
    [0]:
    Sending NMI from CPU 0 to CPUs 1:
    NMI backtrace for cpu 1
    CPU: 1 PID: 5065 Comm: syz-executor236 Not tainted 6.8.0-rc3-syzkaller-00136-g1f719a2f3fa6 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
    RIP: 0010:preempt_count arch/x86/include/asm/preempt.h:26 [inline]
    RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]
    RIP: 0010:__sanitizer_cov_trace_pc+0xd/0x60 kernel/kcov.c:207
    Code: cc cc cc cc 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 48 8b 14 25 40 c2 03 00 <65> 8b 05 b4 7c 78 7e a9 00 01 ff 00 48 8b 34 24 74 0f f6 c4 01 74
    RSP: 0018:ffffc900033efa58 EFLAGS: 00000283
    RAX: ffff88807b077800 RBX: ffff88807b077800 RCX: 1ffffffff27b1189
    RDX: ffff88802a5a3b80 RSI: ffffffff8968488d RDI: ffff88807b077f70
    RBP: ffffc900033efbb0 R08: 0000000000000001 R09: fffffbfff27a900c
    R10: ffffffff93d48067 R11: ffffffff8ae000eb R12: ffff88807b077800
    R13: dffffc0000000000 R14: ffff88807b077e40 R15: 0000000000000001
    FS:  0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000564f4fc1e3a8 CR3: 000000000d57a000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <NMI>
     </NMI>
     <TASK>
     unix_gc+0x563/0x13b0 net/unix/garbage.c:319
     unix_release_sock+0xa93/0xf80 net/unix/af_unix.c:683
     unix_release+0x91/0xf0 net/unix/af_unix.c:1064
     __sock_release+0xb0/0x270 net/socket.c:659
     sock_close+0x1c/0x30 net/socket.c:1421
     __fput+0x270/0xb80 fs/file_table.c:376
     task_work_run+0x14f/0x250 kernel/task_work.c:180
     exit_task_work include/linux/task_work.h:38 [inline]
     do_exit+0xa8a/0x2ad0 kernel/exit.c:871
     do_group_exit+0xd4/0x2a0 kernel/exit.c:1020
     __do_sys_exit_group kernel/exit.c:1031 [inline]
     __se_sys_exit_group kernel/exit.c:1029 [inline]
     __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1029
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xd5/0x270 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x6f/0x77
    RIP: 0033:0x7f9d6cbdac09
    Code: Unable to access opcode bytes at 0x7f9d6cbdabdf.
    RSP: 002b:00007fff5952feb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9d6cbdac09
    RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
    RBP: 00007f9d6cc552b0 R08: ffffffffffffffb8 R09: 0000000000000006
    R10: 0000000000000006 R11: 0000000000000246 R12: 00007f9d6cc552b0
    R13: 0000000000000000 R14: 00007f9d6cc55d00 R15: 00007f9d6cbabe70
     </TASK>
    
    Reported-by: syzbot+4fa4a2d1f5a5ee06f006@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=4fa4a2d1f5a5ee06f006
    Fixes: 1279f9d9dec2 ("af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240209220453.96053-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
afs: fix the usage of read_seqbegin_or_lock() in afs_find_server*() [+ + +]
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Thu Nov 30 12:56:14 2023 +0100

    afs: fix the usage of read_seqbegin_or_lock() in afs_find_server*()
    
    [ Upstream commit 1702e0654ca9a7bcd7c7619c8a5004db58945b71 ]
    
    David Howells says:
    
     (5) afs_find_server().
    
         There could be a lot of servers in the list and each server can have
         multiple addresses, so I think this would be better with an exclusive
         second pass.
    
         The server list isn't likely to change all that often, but when it does
         change, there's a good chance several servers are going to be
         added/removed one after the other.  Further, this is only going to be
         used for incoming cache management/callback requests from the server,
         which hopefully aren't going to happen too often - but it is remotely
         drivable.
    
     (6) afs_find_server_by_uuid().
    
         Similarly to (5), there could be a lot of servers to search through, but
         they are in a tree not a flat list, so it should be faster to process.
         Again, it's not likely to change that often and, again, when it does
         change it's likely to involve multiple changes.  This can be driven
         remotely by an incoming cache management request but is mostly going to
         be driven by setting up or reconfiguring a volume's server list -
         something that also isn't likely to happen often.
    
    Make the "seq" counter odd on the 2nd pass, otherwise read_seqbegin_or_lock()
    never takes the lock.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: https://lore.kernel.org/r/20231130115614.GA21581@redhat.com/
    Signed-off-by: Sasha Levin <sashal@kernel.org>

afs: fix the usage of read_seqbegin_or_lock() in afs_lookup_volume_rcu() [+ + +]
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Thu Nov 30 12:56:06 2023 +0100

    afs: fix the usage of read_seqbegin_or_lock() in afs_lookup_volume_rcu()
    
    [ Upstream commit 4121b4337146b64560d1e46ebec77196d9287802 ]
    
    David Howells says:
    
     (2) afs_lookup_volume_rcu().
    
         There can be a lot of volumes known by a system.  A thousand would
         require a 10-step walk and this is drivable by remote operation, so I
         think this should probably take a lock on the second pass too.
    
    Make the "seq" counter odd on the 2nd pass, otherwise read_seqbegin_or_lock()
    never takes the lock.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: https://lore.kernel.org/r/20231130115606.GA21571@redhat.com/
    Signed-off-by: Sasha Levin <sashal@kernel.org>

afs: Hide silly-rename files from userspace [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Mon Jan 8 17:22:36 2024 +0000

    afs: Hide silly-rename files from userspace
    
    [ Upstream commit 57e9d49c54528c49b8bffe6d99d782ea051ea534 ]
    
    There appears to be a race between silly-rename files being created/removed
    and various userspace tools iterating over the contents of a directory,
    leading to such errors as:
    
            find: './kernel/.tmp_cpio_dir/include/dt-bindings/reset/.__afs2080': No such file or directory
            tar: ./include/linux/greybus/.__afs3C95: File removed before we read it
    
    when building a kernel.
    
    Fix afs_readdir() so that it doesn't return .__afsXXXX silly-rename files
    to userspace.  This doesn't stop them being looked up directly by name as
    we need to be able to look them up from within the kernel as part of the
    silly-rename algorithm.
    
    Fixes: 79ddbfa500b3 ("afs: Implement sillyrename for unlink and rename")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: hda/conexant: Add quirk for SWS JS201D [+ + +]
Author: bo liu <bo.liu@senarytech.com>
Date:   Mon Feb 5 09:38:02 2024 +0800

    ALSA: hda/conexant: Add quirk for SWS JS201D
    
    commit 4639c5021029d49fd2f97fa8d74731f167f98919 upstream.
    
    The SWS JS201D need a different pinconfig from windows driver.
    Add a quirk to use a specific pinconfig to SWS JS201D.
    
    Signed-off-by: bo liu <bo.liu@senarytech.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240205013802.51907-1-bo.liu@senarytech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/conexant: Fix headset auto detect fail in cx8070 and SN6140 [+ + +]
Author: bo liu <bo.liu@senarytech.com>
Date:   Mon Jan 8 19:02:35 2024 +0800

    ALSA: hda/conexant: Fix headset auto detect fail in cx8070 and SN6140
    
    [ Upstream commit 7aeb259086487417f0fecf66e325bee133e8813a ]
    
    When OMTP headset plugin the headset jack of CX8070 and SN6160 sound cards,
    the headset type detection circuit will recognize the headset type as CTIA.
    At this point, plugout and plugin the headset will get the correct headset
    type as OMTP.
    The reason for the failure of headset type recognition is that the sound
    card creation will enable the VREF voltage of the headset mic, which
    interferes with the headset type automatic detection circuit. Plugout and
    plugin the headset will restart the headset detection and get the correct
    headset type.
    The patch is disable the VREF voltage when the headset is not present, and
    will enable the VREF voltage when the headset is present.
    
    Signed-off-by: bo liu <bo.liu@senarytech.com>
    Link: https://lore.kernel.org/r/20240108110235.3867-1-bo.liu@senarytech.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/cs8409: Suppress vmaster control for Dolphin models [+ + +]
Author: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Date:   Mon Jan 22 18:47:10 2024 +0000

    ALSA: hda/cs8409: Suppress vmaster control for Dolphin models
    
    commit a2ed0a44d637ef9deca595054c206da7d6cbdcbc upstream.
    
    Customer has reported an issue with specific desktop platform
    where two CS42L42 codecs are connected to CS8409 HDA bridge.
    If "Master Volume Control" is created then on Ubuntu OS UCM
    left/right balance slider in UI audio settings has no effect.
    This patch will fix this issue for a target paltform.
    
    Fixes: 20e507724113 ("ALSA: hda/cs8409: Add support for dolphin")
    Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240122184710.5802-1-vitalyr@opensource.cirrus.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Enable headset mic on Vaio VJFE-ADL [+ + +]
Author: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Date:   Thu Feb 1 09:21:14 2024 -0300

    ALSA: hda/realtek: Enable headset mic on Vaio VJFE-ADL
    
    commit c7de2d9bb68a5fc71c25ff96705a80a76c8436eb upstream.
    
    Vaio VJFE-ADL is equipped with ALC269VC, and it needs
    ALC298_FIXUP_SPK_VOLUME quirk to make its headset mic work.
    
    Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240201122114.30080-1-edson.drosdeck@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Enable Mute LED on HP Laptop 14-fq0xxx [+ + +]
Author: Luka Guzenko <l.guzenko@web.de>
Date:   Sun Jan 28 16:57:04 2024 +0100

    ALSA: hda/realtek: Enable Mute LED on HP Laptop 14-fq0xxx
    
    commit f0d78972f27dc1d1d51fbace2713ad3cdc60a877 upstream.
    
    This HP Laptop uses ALC236 codec with COEF 0x07 controlling the
    mute LED. Enable existing quirk for this device.
    
    Signed-off-by: Luka Guzenko <l.guzenko@web.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240128155704.2333812-1-l.guzenko@web.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Fix the external mic not being recognised for Acer Swift 1 SF114-32 [+ + +]
Author: David Senoner <seda18@rolmail.net>
Date:   Fri Jan 26 16:56:26 2024 +0100

    ALSA: hda/realtek: Fix the external mic not being recognised for Acer Swift 1 SF114-32
    
    commit efb56d84dd9c3de3c99fc396abb57c6d330038b5 upstream.
    
    If you connect an external headset/microphone to the 3.5mm jack on the
    Acer Swift 1 SF114-32 it does not recognize the microphone. This fixes
    that and gives the user the ability to choose between internal and
    headset mic.
    
    Signed-off-by: David Senoner <seda18@rolmail.net>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240126155626.2304465-1-seda18@rolmail.net
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda: intel-dspcfg: add filters for ARL-S and ARL [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Dec 4 15:27:08 2023 -0600

    ALSA: hda: intel-dspcfg: add filters for ARL-S and ARL
    
    [ Upstream commit 7a9d6bbe8a663c817080be55d9fecf19a4a8fd8f ]
    
    Same usual filters, SOF is required for DMIC and/or SoundWire support.
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Acked-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20231204212710.185976-4-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: Intel: add HDA_ARL PCI ID support [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Dec 4 15:27:07 2023 -0600

    ALSA: hda: Intel: add HDA_ARL PCI ID support
    
    [ Upstream commit a31014ebad617868c246d3985ff80d891f03711e ]
    
    Yet another PCI ID.
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Acked-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20231204212710.185976-3-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: Refer to correct stream index at loops [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Nov 21 16:41:25 2023 +0100

    ALSA: hda: Refer to correct stream index at loops
    
    [ Upstream commit 26257869672fd4a06a60c2da841e15fb2cb47bbe ]
    
    In a couple of loops over the all streams, we check the bitmap against
    the loop counter.  A more correct reference would be, however, the
    index of each stream, instead.
    
    This patch corrects the check of bitmaps to the stream index.
    
    Note that this change doesn't fix anything for now; all existing
    drivers set up the stream indices properly, hence the loop count is
    always equal with the stream index.  That said, this change is only
    for consistency.
    
    Link: https://lore.kernel.org/r/20231121154125.4888-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Add a quirk for Yamaha YIT-W12TX transmitter [+ + +]
Author: Julian Sikorski <belegdol+github@gmail.com>
Date:   Tue Jan 23 09:49:35 2024 +0100

    ALSA: usb-audio: Add a quirk for Yamaha YIT-W12TX transmitter
    
    commit a969210066054ea109d8b7aff29a9b1c98776841 upstream.
    
    The device fails to initialize otherwise, giving the following error:
    [ 3676.671641] usb 2-1.1: 1:1: cannot get freq at ep 0x1
    
    Signed-off-by: Julian Sikorski <belegdol+github@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240123084935.2745-1-belegdol+github@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Add delay quirk for MOTU M Series 2nd revision [+ + +]
Author: Alexander Tsoy <alexander@tsoy.me>
Date:   Wed Jan 24 16:02:39 2024 +0300

    ALSA: usb-audio: Add delay quirk for MOTU M Series 2nd revision
    
    commit d915a6850e27efb383cd4400caadfe47792623df upstream.
    
    Audio control requests that sets sampling frequency sometimes fail on
    this card. Adding delay between control messages eliminates that problem.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217601
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
    Link: https://lore.kernel.org/r/20240124130239.358298-1-alexander@tsoy.me
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arch: consolidate arch_irq_work_raise prototypes [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 8 13:58:29 2023 +0100

    arch: consolidate arch_irq_work_raise prototypes
    
    [ Upstream commit 64bac5ea17d527872121adddfee869c7a0618f8f ]
    
    The prototype was hidden in an #ifdef on x86, which causes a warning:
    
    kernel/irq_work.c:72:13: error: no previous prototype for 'arch_irq_work_raise' [-Werror=missing-prototypes]
    
    Some architectures have a working prototype, while others don't.
    Fix this by providing it in only one place that is always visible.
    
    Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
    Acked-by: Guo Ren <guoren@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: qcom: msm8996: Fix 'in-ports' is a required property [+ + +]
Author: Mao Jinlong <quic_jinlmao@quicinc.com>
Date:   Sat Dec 9 23:26:29 2023 -0800

    arm64: dts: qcom: msm8996: Fix 'in-ports' is a required property
    
    [ Upstream commit 9a6fc510a6a3ec150cb7450aec1e5f257e6fc77b ]
    
    Add the inport of funnel@3023000 to fix 'in-ports' is a required property
    warning.
    
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>
    Link: https://lore.kernel.org/r/20231210072633.4243-3-quic_jinlmao@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8998: Fix 'out-ports' is a required property [+ + +]
Author: Mao Jinlong <quic_jinlmao@quicinc.com>
Date:   Sat Dec 9 23:26:30 2023 -0800

    arm64: dts: qcom: msm8998: Fix 'out-ports' is a required property
    
    [ Upstream commit ae5ee3562a2519214b12228545e88a203dd68bbd ]
    
    out-ports is a required property for coresight ETM. Add out-ports for
    ETM nodes to fix the warning.
    
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>
    Link: https://lore.kernel.org/r/20231210072633.4243-4-quic_jinlmao@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc7180: fix USB wakeup interrupt types [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Nov 20 17:43:23 2023 +0100

    arm64: dts: qcom: sc7180: fix USB wakeup interrupt types
    
    commit 9b956999bf725fd62613f719c3178fdbee6e5f47 upstream.
    
    The DP/DM wakeup interrupts are edge triggered and which edge to trigger
    on depends on use-case and whether a Low speed or Full/High speed device
    is connected.
    
    Fixes: 0b766e7fe5a2 ("arm64: dts: qcom: sc7180: Add USB related nodes")
    Cc: stable@vger.kernel.org      # 5.10
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20231120164331.8116-4-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sdm845: fix USB DP/DM HS PHY interrupts [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed Dec 13 18:34:00 2023 +0100

    arm64: dts: qcom: sdm845: fix USB DP/DM HS PHY interrupts
    
    commit 204f9ed4bad6293933179517624143b8f412347c upstream.
    
    The USB DP/DM HS PHY interrupts need to be provided by the PDC interrupt
    controller in order to be able to wake the system up from low-power
    states and to be able to detect disconnect events, which requires
    triggering on falling edges.
    
    A recent commit updated the trigger type but failed to change the
    interrupt provider as required. This leads to the current Linux driver
    failing to probe instead of printing an error during suspend and USB
    wakeup not working as intended.
    
    Fixes: 84ad9ac8d9ca ("arm64: dts: qcom: sdm845: fix USB wakeup interrupt types")
    Fixes: ca4db2b538a1 ("arm64: dts: qcom: sdm845: Add USB-related nodes")
    Cc: stable@vger.kernel.org      # 4.20
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20231213173403.29544-3-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sdm845: fix USB wakeup interrupt types [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Nov 20 17:43:28 2023 +0100

    arm64: dts: qcom: sdm845: fix USB wakeup interrupt types
    
    commit 84ad9ac8d9ca29033d589e79a991866b38e23b85 upstream.
    
    The DP/DM wakeup interrupts are edge triggered and which edge to trigger
    on depends on use-case and whether a Low speed or Full/High speed device
    is connected.
    
    Fixes: ca4db2b538a1 ("arm64: dts: qcom: sdm845: Add USB-related nodes")
    Cc: stable@vger.kernel.org      # 4.20
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20231120164331.8116-9-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: qcom: sm8150: fix USB wakeup interrupt types [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Nov 20 17:43:30 2023 +0100

    arm64: dts: qcom: sm8150: fix USB wakeup interrupt types
    
    commit 54524b6987d1fffe64cbf3dded1b2fa6b903edf9 upstream.
    
    The DP/DM wakeup interrupts are edge triggered and which edge to trigger
    on depends on use-case and whether a Low speed or Full/High speed device
    is connected.
    
    Fixes: 0c9dde0d2015 ("arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes")
    Fixes: b33d2868e8d3 ("arm64: dts: qcom: sm8150: Add USB and PHY device nodes")
    Cc: stable@vger.kernel.org      # 5.10
    Cc: Jonathan Marek <jonathan@marek.ca>
    Cc: Jack Pham <quic_jackp@quicinc.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Jack Pham <quic_jackp@quicinc.com>
    Link: https://lore.kernel.org/r/20231120164331.8116-11-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: irq: set the correct node for shadow call stack [+ + +]
Author: Huang Shijie <shijie@os.amperecomputing.com>
Date:   Wed Dec 13 09:20:46 2023 +0800

    arm64: irq: set the correct node for shadow call stack
    
    commit 7b1a09e44dc64f4f5930659b6d14a27183c00705 upstream.
    
    The init_irq_stacks() has been changed to use the correct node:
    https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf
    
    The init_irq_scs() has the same issue with init_irq_stacks():
            cpu_to_node() is not initialized yet, it does not work.
    
    This patch uses early_cpu_to_node() to set the init_irq_scs()
    with the correct node.
    
    Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Link: https://lore.kernel.org/r/20231213012046.12014-1-shijie@os.amperecomputing.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: irq: set the correct node for VMAP stack [+ + +]
Author: Huang Shijie <shijie@os.amperecomputing.com>
Date:   Fri Nov 24 11:15:13 2023 +0800

    arm64: irq: set the correct node for VMAP stack
    
    [ Upstream commit 75b5e0bf90bffaca4b1f19114065dc59f5cc161f ]
    
    In current code, init_irq_stacks() will call cpu_to_node().
    The cpu_to_node() depends on percpu "numa_node" which is initialized in:
         arch_call_rest_init() --> rest_init() -- kernel_init()
            --> kernel_init_freeable() --> smp_prepare_cpus()
    
    But init_irq_stacks() is called in init_IRQ() which is before
    arch_call_rest_init().
    
    So in init_irq_stacks(), the cpu_to_node() does not work, it
    always return 0. In NUMA, it makes the node 1 cpu accesses the IRQ stack which
    is in the node 0.
    
    This patch fixes it by:
      1.) export the early_cpu_to_node(), and use it in the init_irq_stacks().
      2.) change init_irq_stacks() to __init function.
    
    Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
    Link: https://lore.kernel.org/r/20231124031513.81548-1-shijie@os.amperecomputing.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata [+ + +]
Author: Easwar Hariharan <eahariha@linux.microsoft.com>
Date:   Wed Feb 14 17:55:18 2024 +0000

    arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata
    
    commit fb091ff394792c018527b3211bbdfae93ea4ac02 upstream.
    
    Add the MIDR value of Microsoft Azure Cobalt 100, which is a Microsoft
    implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and therefore
    suffers from all the same errata.
    
    CC: stable@vger.kernel.org # 5.15+
    Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
    Link: https://lore.kernel.org/r/20240214175522.2457857-1-eahariha@linux.microsoft.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ARM: dts: imx1: Fix sram node [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Wed Dec 6 09:39:21 2023 -0300

    ARM: dts: imx1: Fix sram node
    
    [ Upstream commit c248e535973088ba7071ff6f26ab7951143450af ]
    
    Per sram.yaml, address-cells, size-cells and ranges are mandatory.
    
    The node name should be sram.
    
    Change the node name and pass the required properties to fix the
    following dt-schema warnings:
    
    imx1-apf9328.dtb: esram@300000: $nodename:0: 'esram@300000' does not match '^sram(@.*)?'
            from schema $id: http://devicetree.org/schemas/sram/sram.yaml#
    imx1-apf9328.dtb: esram@300000: '#address-cells' is a required property
            from schema $id: http://devicetree.org/schemas/sram/sram.yaml#
    imx1-apf9328.dtb: esram@300000: '#size-cells' is a required property
            from schema $id: http://devicetree.org/schemas/sram/sram.yaml#
    imx1-apf9328.dtb: esram@300000: 'ranges' is a required property
            from schema $id: http://devicetree.org/schemas/sram/sram.yaml#
    
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx23-sansa: Use preferred i2c-gpios properties [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Thu Dec 7 07:12:12 2023 -0300

    ARM: dts: imx23-sansa: Use preferred i2c-gpios properties
    
    [ Upstream commit e3aa1a82fb20ee97597022f6528823a8ab82bde6 ]
    
    The 'gpios' property to describe the SDA and SCL GPIOs is considered
    deprecated according to i2c-gpio.yaml.
    
    Switch to the preferred 'sda-gpios' and 'scl-gpios' properties.
    
    This fixes the following schema warnings:
    
    imx23-sansa.dtb: i2c-0: 'sda-gpios' is a required property
            from schema $id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml#
    imx23-sansa.dtb: i2c-0: 'scl-gpios' is a required property
            from schema $id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml#
    
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx23/28: Fix the DMA controller node name [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Thu Dec 7 07:26:31 2023 -0300

    ARM: dts: imx23/28: Fix the DMA controller node name
    
    [ Upstream commit 858d83ca4b50bbc8693d95cc94310e6d791fb2e6 ]
    
    Per fsl,mxs-dma.yaml, the node name should be 'dma-controller'.
    
    Change it to fix the following dt-schema warning.
    
    imx28-apf28.dtb: dma-apbx@80024000: $nodename:0: 'dma-apbx@80024000' does not match '^dma-controller(@.*)?$'
            from schema $id: http://devicetree.org/schemas/dma/fsl,mxs-dma.yaml#
    
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx25/27-eukrea: Fix RTC node name [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Wed Dec 6 08:58:26 2023 -0300

    ARM: dts: imx25/27-eukrea: Fix RTC node name
    
    [ Upstream commit 68c711b882c262e36895547cddea2c2d56ce611d ]
    
    Node names should be generic. Use 'rtc' as node name to fix
    the following dt-schema warning:
    
    imx25-eukrea-mbimxsd25-baseboard.dtb: pcf8563@51: $nodename:0: 'pcf8563@51' does not match '^rtc(@.*|-([0-9]|[1-9][0-9]+))?$'
            from schema $id: http://devicetree.org/schemas/rtc/nxp,pcf8563.yaml#
    
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx25/27: Pass timing0 [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Wed Dec 6 17:14:05 2023 -0300

    ARM: dts: imx25/27: Pass timing0
    
    [ Upstream commit 11ab7ad6f795ae23c398a4a5c56505d3dab27c4c ]
    
    Per display-timings.yaml, the 'timing' pattern should be used to
    describe the display timings.
    
    Change it accordingly to fix the following dt-schema warning:
    
    imx27-apf27dev.dtb: display-timings: '800x480' does not match any of the regexes: '^timing', 'pinctrl-[0-9]+'
            from schema $id: http://devicetree.org/schemas/display/panel/display-timings.yaml#
    
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx25: Fix the iim compatible string [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Wed Dec 6 17:00:33 2023 -0300

    ARM: dts: imx25: Fix the iim compatible string
    
    [ Upstream commit f0b929f58719fc57a4926ab4fc972f185453d6a5 ]
    
    Per imx-iim.yaml, the compatible string should only contain a single
    entry.
    
    Use it as "fsl,imx25-iim" to fix the following dt-schema warning:
    
    imx25-karo-tx25.dtb: efuse@53ff0000: compatible: ['fsl,imx25-iim', 'fsl,imx27-iim'] is too long
            from schema $id: http://devicetree.org/schemas/nvmem/imx-iim.yaml#
    
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx27-apf27dev: Fix LED name [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Wed Dec 6 17:19:05 2023 -0300

    ARM: dts: imx27-apf27dev: Fix LED name
    
    [ Upstream commit dc35e253d032b959d92e12f081db5b00db26ae64 ]
    
    Per leds-gpio.yaml, the led names should start with 'led'.
    
    Change it to fix the following dt-schema warning:
    
    imx27-apf27dev.dtb: leds: 'user' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
            from schema $id: http://devicetree.org/schemas/leds/leds-gpio.yaml#
    
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx27: Fix sram node [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Wed Dec 6 09:39:20 2023 -0300

    ARM: dts: imx27: Fix sram node
    
    [ Upstream commit 2fb7b2a2f06bb3f8321cf26c33e4e820c5b238b6 ]
    
    Per sram.yaml, address-cells, size-cells and ranges are mandatory.
    
    Pass them to fix the following dt-schema warnings:
    
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx7d: Fix coresight funnel ports [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Thu Oct 12 10:15:53 2023 +0200

    ARM: dts: imx7d: Fix coresight funnel ports
    
    [ Upstream commit 0d4ac04fa7c3f6dc263dba6f575a2ec7a2d4eca8 ]
    
    imx7d uses two ports for 'in-ports', so the syntax port@<num> has to
    be used. imx7d has both port and port@1 nodes present, raising these
    error:
    funnel@30041000: in-ports: More than one condition true in oneOf schema
    funnel@30041000: Unevaluated properties are not allowed
    ('in-ports' was unexpected)
    
    Fix this by also using port@0 for imx7s as well.
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx7s: Fix lcdif compatible [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Thu Oct 12 10:15:54 2023 +0200

    ARM: dts: imx7s: Fix lcdif compatible
    
    [ Upstream commit 5f55da4cc37051cda600ea870ce8cf29f1297715 ]
    
    imx7d-lcdif is compatible to imx6sx-lcdif. MXSFB_V6 supports overlay
    by using LCDC_AS_CTRL register. This registers used by overlay plane:
    * LCDC_AS_CTRL
    * LCDC_AS_BUF
    * LCDC_AS_NEXT_BUF
    are listed in i.MX7D RM as well.
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx7s: Fix nand-controller #size-cells [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Thu Oct 12 10:15:55 2023 +0200

    ARM: dts: imx7s: Fix nand-controller #size-cells
    
    [ Upstream commit 4aadb841ed49bada1415c48c44d21f5b69e01299 ]
    
    nand-controller.yaml bindings says #size-cells shall be set to 0.
    Fixes the dtbs_check warning:
    arch/arm/boot/dts/nxp/imx/imx7s-mba7.dtb: nand-controller@33002000:
     #size-cells:0:0: 0 was expected
      from schema $id: http://devicetree.org/schemas/mtd/gpmi-nand.yaml#
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx: Use flash@0,0 pattern [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Wed Dec 6 09:36:05 2023 -0300

    ARM: dts: imx: Use flash@0,0 pattern
    
    [ Upstream commit 1e1d7cc478fb16816de09740e3c323c0c188d58f ]
    
    Per mtd-physmap.yaml, 'nor@0,0' is not a valid node pattern.
    
    Change it to 'flash@0,0' to fix the following dt-schema warning:
    
    imx1-ads.dtb: nor@0,0: $nodename:0: 'nor@0,0' does not match '^(flash|.*sram|nand)(@.*)?$'
            from schema $id: http://devicetree.org/schemas/mtd/mtd-physmap.yaml#
    
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: sdx55: fix pdc '#interrupt-cells' [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed Dec 13 18:31:29 2023 +0100

    ARM: dts: qcom: sdx55: fix pdc '#interrupt-cells'
    
    [ Upstream commit cc25bd06c16aa582596a058d375b2e3133f79b93 ]
    
    The Qualcomm PDC interrupt controller binding expects two cells in
    interrupt specifiers.
    
    Fixes: 9d038b2e62de ("ARM: dts: qcom: Add SDX55 platform and MTP board support")
    Cc: stable@vger.kernel.org      # 5.12
    Cc: Manivannan Sadhasivam <mani@kernel.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20231213173131.29436-2-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: sdx55: fix USB DP/DM HS PHY interrupts [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed Dec 13 18:31:30 2023 +0100

    ARM: dts: qcom: sdx55: fix USB DP/DM HS PHY interrupts
    
    [ Upstream commit de95f139394a5ed82270f005bc441d2e7c1e51b7 ]
    
    The USB DP/DM HS PHY interrupts need to be provided by the PDC interrupt
    controller in order to be able to wake the system up from low-power
    states and to be able to detect disconnect events, which requires
    triggering on falling edges.
    
    A recent commit updated the trigger type but failed to change the
    interrupt provider as required. This leads to the current Linux driver
    failing to probe instead of printing an error during suspend and USB
    wakeup not working as intended.
    
    Fixes: d0ec3c4c11c3 ("ARM: dts: qcom: sdx55: fix USB wakeup interrupt types")
    Fixes: fea4b41022f3 ("ARM: dts: qcom: sdx55: Add USB3 and PHY support")
    Cc: stable@vger.kernel.org      # 5.12
    Cc: Manivannan Sadhasivam <mani@kernel.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20231213173131.29436-3-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: sdx55: fix USB SS wakeup [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed Dec 13 18:31:31 2023 +0100

    ARM: dts: qcom: sdx55: fix USB SS wakeup
    
    [ Upstream commit 710dd03464e4ab5b3d329768388b165d61958577 ]
    
    The USB SS PHY interrupt needs to be provided by the PDC interrupt
    controller in order to be able to wake the system up from low-power
    states.
    
    Fixes: fea4b41022f3 ("ARM: dts: qcom: sdx55: Add USB3 and PHY support")
    Cc: stable@vger.kernel.org      # 5.12
    Cc: Manivannan Sadhasivam <mani@kernel.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20231213173131.29436-4-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: sdx55: fix USB wakeup interrupt types [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Nov 20 17:43:21 2023 +0100

    ARM: dts: qcom: sdx55: fix USB wakeup interrupt types
    
    [ Upstream commit d0ec3c4c11c3b30e1f2d344973b2a7bf0f986734 ]
    
    The DP/DM wakeup interrupts are edge triggered and which edge to trigger
    on depends on use-case and whether a Low speed or Full/High speed device
    is connected.
    
    Fixes: fea4b41022f3 ("ARM: dts: qcom: sdx55: Add USB3 and PHY support")
    Cc: stable@vger.kernel.org      # 5.12
    Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20231120164331.8116-2-johan+linaro@kernel.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: rockchip: fix rk3036 hdmi ports node [+ + +]
Author: Johan Jonker <jbx6244@gmail.com>
Date:   Mon Dec 4 18:40:27 2023 +0100

    ARM: dts: rockchip: fix rk3036 hdmi ports node
    
    [ Upstream commit 27ded76ef0fcfcf939914532aae575cf23c221b4 ]
    
    Fix hdmi ports node so that it matches the
    rockchip,inno-hdmi.yaml binding.
    
    Signed-off-by: Johan Jonker <jbx6244@gmail.com>
    Link: https://lore.kernel.org/r/9a2afac1-ed5c-382d-02b0-b2f5f1af3abb@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: samsung: exynos4210-i9100: Unconditionally enable LDO12 [+ + +]
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Wed Dec 6 23:15:54 2023 +0100

    ARM: dts: samsung: exynos4210-i9100: Unconditionally enable LDO12
    
    [ Upstream commit 84228d5e29dbc7a6be51e221000e1d122125826c ]
    
    The kernel hangs for a good 12 seconds without any info being printed to
    dmesg, very early in the boot process, if this regulator is not enabled.
    
    Force-enable it to work around this issue, until we know more about the
    underlying problem.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the Galaxy S2")
    Cc: stable@vger.kernel.org # v5.8+
    Link: https://lore.kernel.org/r/20231206221556.15348-2-paul@crapouillou.net
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: codecs: lpass-wsa-macro: fix compander volume hack [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Jan 19 12:24:19 2024 +0100

    ASoC: codecs: lpass-wsa-macro: fix compander volume hack
    
    commit 46188db080bd1df7d2d28031b89e56f2fdbabd67 upstream.
    
    The LPASS WSA macro codec driver is updating the digital gain settings
    behind the back of user space on DAPM events if companding has been
    enabled.
    
    As compander control is exported to user space, this can result in the
    digital gain setting being incremented (or decremented) every time the
    sound server is started and the codec suspended depending on what the
    UCM configuration looks like.
    
    Soon enough playback will become distorted (or too quiet).
    
    This is specifically a problem on the Lenovo ThinkPad X13s as this
    bypasses the limit for the digital gain setting that has been set by the
    machine driver.
    
    Fix this by simply dropping the compander gain offset hack. If someone
    cares about modelling the impact of the compander setting this can
    possibly be done by exporting it as a volume control later.
    
    Note that the volume registers still need to be written after enabling
    clocks in order for any prior updates to take effect.
    
    Fixes: 2c4066e5d428 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route")
    Cc: stable@vger.kernel.org      # 5.11
    Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://msgid.link/r/20240119112420.7446-4-johan+linaro@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: codecs: wcd938x: handle deferred probe [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Jan 17 16:12:06 2024 +0100

    ASoC: codecs: wcd938x: handle deferred probe
    
    commit 086df711d9b886194481b4fbe525eb43e9ae7403 upstream.
    
    WCD938x sound codec driver ignores return status of getting regulators
    and returns EINVAL instead of EPROBE_DEFER.  If regulator provider
    probes after the codec, system is left without probed audio:
    
      wcd938x_codec audio-codec: wcd938x_probe: Fail to obtain platform data
      wcd938x_codec: probe of audio-codec failed with error -22
    
    Fixes: 16572522aece ("ASoC: codecs: wcd938x-sdw: add SoundWire driver")
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://msgid.link/r/20240117151208.1219755-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ASoC: doc: Fix undefined SND_SOC_DAPM_NOPM argument [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Tue Nov 21 14:07:51 2023 +0200

    ASoC: doc: Fix undefined SND_SOC_DAPM_NOPM argument
    
    [ Upstream commit 67c7666fe808c3a7af3cc6f9d0a3dd3acfd26115 ]
    
    The virtual widget example makes use of an undefined SND_SOC_DAPM_NOPM
    argument passed to SND_SOC_DAPM_MIXER().  Replace with the correct
    SND_SOC_NOPM definition.
    
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Link: https://lore.kernel.org/r/20231121120751.77355-1-cristian.ciocaltea@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work() [+ + +]
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date:   Sun Feb 11 12:58:34 2024 +0300

    ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work()
    
    [ Upstream commit 6ef5d5b92f7117b324efaac72b3db27ae8bb3082 ]
    
    There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex
    is left locked forever. That may lead to deadlock
    when rt5645_jack_detect_work() is called for the second time.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: cdba4301adda ("ASoC: rt5650: add mutex to avoid the jack detection failure")
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Link: https://lore.kernel.org/r/1707645514-21196-1-git-send-email-khoroshilov@ispras.ru
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
async: Introduce async_schedule_dev_nocall() [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Dec 27 21:38:23 2023 +0100

    async: Introduce async_schedule_dev_nocall()
    
    commit 7d4b5d7a37bdd63a5a3371b988744b060d5bb86f upstream.
    
    In preparation for subsequent changes, introduce a specialized variant
    of async_schedule_dev() that will not invoke the argument function
    synchronously when it cannot be scheduled for asynchronous execution.
    
    The new function, async_schedule_dev_nocall(), will be used for fixing
    possible deadlocks in the system-wide power management core code.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> for the series.
    Tested-by: Youngmin Nam <youngmin.nam@samsung.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

async: Split async_schedule_node_domain() [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Dec 27 21:37:02 2023 +0100

    async: Split async_schedule_node_domain()
    
    commit 6aa09a5bccd8e224d917afdb4c278fc66aacde4d upstream.
    
    In preparation for subsequent changes, split async_schedule_node_domain()
    in two pieces so as to allow the bottom part of it to be called from a
    somewhat different code path.
    
    No functional impact.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
    Tested-by: Youngmin Nam <youngmin.nam@samsung.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
atm: idt77252: fix a memleak in open_card_ubr0 [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Thu Feb 1 20:41:05 2024 +0800

    atm: idt77252: fix a memleak in open_card_ubr0
    
    [ Upstream commit f3616173bf9be9bf39d131b120d6eea4e6324cb5 ]
    
    When alloc_scq fails, card->vcs[0] (i.e. vc) should be freed. Otherwise,
    in the following call chain:
    
    idt77252_init_one
      |-> idt77252_dev_open
            |-> open_card_ubr0
                  |-> alloc_scq [failed]
      |-> deinit_card
            |-> vfree(card->vcs);
    
    card->vcs is freed and card->vcs[0] is leaked.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
audit: Send netlink ACK before setting connection in auditd_set [+ + +]
Author: Chris Riches <chris.riches@nutanix.com>
Date:   Wed Oct 18 09:23:51 2023 +0000

    audit: Send netlink ACK before setting connection in auditd_set
    
    [ Upstream commit 022732e3d846e197539712e51ecada90ded0572a ]
    
    When auditd_set sets the auditd_conn pointer, audit messages can
    immediately be put on the socket by other kernel threads. If the backlog
    is large or the rate is high, this can immediately fill the socket
    buffer. If the audit daemon requested an ACK for this operation, a full
    socket buffer causes the ACK to get dropped, also setting ENOBUFS on the
    socket.
    
    To avoid this race and ensure ACKs get through, fast-track the ACK in
    this specific case to ensure it is sent before auditd_conn is set.
    
    Signed-off-by: Chris Riches <chris.riches@nutanix.com>
    [PM: fix some tab vs space damage]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
binder: signal epoll threads of self-work [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Wed Jan 31 21:53:46 2024 +0000

    binder: signal epoll threads of self-work
    
    commit 97830f3c3088638ff90b20dfba2eb4d487bf14d7 upstream.
    
    In (e)poll mode, threads often depend on I/O events to determine when
    data is ready for consumption. Within binder, a thread may initiate a
    command via BINDER_WRITE_READ without a read buffer and then make use
    of epoll_wait() or similar to consume any responses afterwards.
    
    It is then crucial that epoll threads are signaled via wakeup when they
    queue their own work. Otherwise, they risk waiting indefinitely for an
    event leaving their work unhandled. What is worse, subsequent commands
    won't trigger a wakeup either as the thread has pending work.
    
    Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
    Cc: Arve Hjønnevåg <arve@android.com>
    Cc: Martijn Coenen <maco@android.com>
    Cc: Alice Ryhl <aliceryhl@google.com>
    Cc: Steven Moreland <smoreland@google.com>
    Cc: stable@vger.kernel.org # v4.19+
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Link: https://lore.kernel.org/r/20240131215347.1808751-1-cmllamas@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
blk-iocost: Fix an UBSAN shift-out-of-bounds warning [+ + +]
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Nov 20 12:25:56 2023 -1000

    blk-iocost: Fix an UBSAN shift-out-of-bounds warning
    
    [ Upstream commit 2a427b49d02995ea4a6ff93a1432c40fa4d36821 ]
    
    When iocg_kick_delay() is called from a CPU different than the one which set
    the delay, @now may be in the past of @iocg->delay_at leading to the
    following warning:
    
      UBSAN: shift-out-of-bounds in block/blk-iocost.c:1359:23
      shift exponent 18446744073709 is too large for 64-bit type 'u64' (aka 'unsigned long long')
      ...
      Call Trace:
       <TASK>
       dump_stack_lvl+0x79/0xc0
       __ubsan_handle_shift_out_of_bounds+0x2ab/0x300
       iocg_kick_delay+0x222/0x230
       ioc_rqos_merge+0x1d7/0x2c0
       __rq_qos_merge+0x2c/0x80
       bio_attempt_back_merge+0x83/0x190
       blk_attempt_plug_merge+0x101/0x150
       blk_mq_submit_bio+0x2b1/0x720
       submit_bio_noacct_nocheck+0x320/0x3e0
       __swap_writepage+0x2ab/0x9d0
    
    The underflow itself doesn't really affect the behavior in any meaningful
    way; however, the past timestamp may exaggerate the delay amount calculated
    later in the code, which shouldn't be a material problem given the nature of
    the delay mechanism.
    
    If @now is in the past, this CPU is racing another CPU which recently set up
    the delay and there's nothing this CPU can contribute w.r.t. the delay.
    Let's bail early from iocg_kick_delay() in such cases.
    
    Reported-by: Breno Leitão <leitao@debian.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Fixes: 5160a5a53c0c ("blk-iocost: implement delay adjustment hysteresis")
    Link: https://lore.kernel.org/r/ZVvc9L_CYk5LO1fT@slm.duckdns.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
blk-mq: fix IO hang from sbitmap wakeup race [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Fri Jan 12 20:26:26 2024 +0800

    blk-mq: fix IO hang from sbitmap wakeup race
    
    [ Upstream commit 5266caaf5660529e3da53004b8b7174cab6374ed ]
    
    In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
    with the following blk_mq_get_driver_tag() in case of getting driver
    tag failure.
    
    Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
    the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
    blk_mq_mark_tag_wait() can't get driver tag successfully.
    
    This issue can be reproduced by running the following test in loop, and
    fio hang can be observed in < 30min when running it on my test VM
    in laptop.
    
            modprobe -r scsi_debug
            modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
            dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
            fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
                    --runtime=100 --numjobs=40 --time_based --name=test \
                    --ioengine=libaio
    
    Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
    is just fine in case of running out of tag.
    
    Cc: Jan Kara <jack@suse.cz>
    Cc: Kemeng Shi <shikemeng@huaweicloud.com>
    Reported-by: Changhui Zhong <czhong@redhat.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20240112122626.4181044-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block/rnbd-srv: Check for unlikely string overflow [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Dec 12 13:47:42 2023 -0800

    block/rnbd-srv: Check for unlikely string overflow
    
    [ Upstream commit 9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41 ]
    
    Since "dev_search_path" can technically be as large as PATH_MAX,
    there was a risk of truncation when copying it and a second string
    into "full_path" since it was also PATH_MAX sized. The W=1 builds were
    reporting this warning:
    
    drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':
    drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
      616 |                 snprintf(full_path, PATH_MAX, "%s/%s",
          |                                                   ^~
    In function 'rnbd_srv_get_full_path',
        inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096
      616 |                 snprintf(full_path, PATH_MAX, "%s/%s",
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      617 |                          dev_search_path, dev_name);
          |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    To fix this, unconditionally check for truncation (as was already done
    for the case where "%SESSNAME%" was present).
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202312100355.lHoJPgKy-lkp@intel.com/
    Cc: Md. Haris Iqbal <haris.iqbal@ionos.com>
    Cc: Jack Wang <jinpu.wang@ionos.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc:  <linux-block@vger.kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Acked-by: Guoqing Jiang <guoqing.jiang@linux.dev>
    Acked-by: Jack Wang <jinpu.wang@ionos.com>
    Link: https://lore.kernel.org/r/20231212214738.work.169-kees@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: Move checking GENHD_FL_NO_PART to bdev_add_partition() [+ + +]
Author: Li Lingfeng <lilingfeng3@huawei.com>
Date:   Thu Jan 18 21:04:01 2024 +0800

    block: Move checking GENHD_FL_NO_PART to bdev_add_partition()
    
    [ Upstream commit 7777f47f2ea64efd1016262e7b59fab34adfb869 ]
    
    Commit 1a721de8489f ("block: don't add or resize partition on the disk
    with GENHD_FL_NO_PART") prevented all operations about partitions on disks
    with GENHD_FL_NO_PART in blkpg_do_ioctl() since they are meaningless.
    However, it changed error code in some scenarios. So move checking
    GENHD_FL_NO_PART to bdev_add_partition() to eliminate impact.
    
    Fixes: 1a721de8489f ("block: don't add or resize partition on the disk with GENHD_FL_NO_PART")
    Reported-by: Allison Karlitskaya <allison.karlitskaya@redhat.com>
    Closes: https://lore.kernel.org/all/CAOYeF9VsmqKMcQjo1k6YkGNujwN-nzfxY17N3F-CMikE1tYp+w@mail.gmail.com/
    Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20240118130401.792757-1-lilingfeng@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: prevent an integer overflow in bvec_try_merge_hw_page [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Mon Dec 4 18:34:18 2023 +0100

    block: prevent an integer overflow in bvec_try_merge_hw_page
    
    [ Upstream commit 3f034c374ad55773c12dd8f3c1607328e17c0072 ]
    
    Reordered a check to avoid a possible overflow when adding len to bv_len.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Link: https://lore.kernel.org/r/20231204173419.782378-2-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: L2CAP: Fix possible multiple reject send [+ + +]
Author: Frédéric Danis <frederic.danis@collabora.com>
Date:   Tue Dec 19 09:10:22 2023 +0100

    Bluetooth: L2CAP: Fix possible multiple reject send
    
    [ Upstream commit 96a3398b467ab8aada3df2f3a79f4b7835d068b8 ]
    
    In case of an incomplete command or a command with a null identifier 2
    reject packets will be sent, one with the identifier and one with 0.
    Consuming the data of the command will prevent it.
    This allows to send a reject packet for each corrupted command in a
    multi-command packet.
    
    Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: qca: Set both WIDEBAND_SPEECH and LE_STATES quirks for QCA2066 [+ + +]
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Mon Nov 6 14:02:46 2023 +0800

    Bluetooth: qca: Set both WIDEBAND_SPEECH and LE_STATES quirks for QCA2066
    
    [ Upstream commit 5d192b697c7417254cdd9edc3d5e9e0364eb9045 ]
    
    Set both WIDEBAND_SPEECH_SUPPORTED and VALID_LE_STATES quirks
    for QCA2066.
    
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bnxt_en: Wait for FLR to complete during probe [+ + +]
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Wed Jan 17 15:45:11 2024 -0800

    bnxt_en: Wait for FLR to complete during probe
    
    [ Upstream commit 3c1069fa42872f95cf3c6fedf80723d391e12d57 ]
    
    The first message to firmware may fail if the device is undergoing FLR.
    The driver has some recovery logic for this failure scenario but we must
    wait 100 msec for FLR to complete before proceeding.  Otherwise the
    recovery will always fail.
    
    Fixes: ba02629ff6cb ("bnxt_en: log firmware status on firmware init failure")
    Reviewed-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/20240117234515.226944-2-michael.chan@broadcom.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bonding: remove print in bond_verify_device_path [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Thu Nov 23 09:55:15 2023 +0800

    bonding: remove print in bond_verify_device_path
    
    commit 486058f42a4728053ae69ebbf78e9731d8ce6f8b upstream.
    
    As suggested by Paolo in link[1], if the memory allocation fails, the mm
    layer will emit a lot warning comprising the backtrace, so remove the
    print.
    
    [1] https://lore.kernel.org/all/20231118081653.1481260-1-shaozhengchao@huawei.com/
    
    Suggested-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bonding: return -ENOMEM instead of BUG in alb_upper_dev_walk [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Sat Nov 18 16:16:53 2023 +0800

    bonding: return -ENOMEM instead of BUG in alb_upper_dev_walk
    
    [ Upstream commit d6b83f1e3707c4d60acfa58afd3515e17e5d5384 ]
    
    If failed to allocate "tags" or could not find the final upper device from
    start_dev's upper list in bond_verify_device_path(), only the loopback
    detection of the current upper device should be affected, and the system is
    no need to be panic.
    So return -ENOMEM in alb_upper_dev_walk to stop walking, print some warn
    information when failed to allocate memory for vlan tags in
    bond_verify_device_path.
    
    I also think that the following function calls
    netdev_walk_all_upper_dev_rcu
    ---->>>alb_upper_dev_walk
    ---------->>>bond_verify_device_path
    From this way, "end device" can eventually be obtained from "start device"
    in bond_verify_device_path, IS_ERR(tags) could be instead of
    IS_ERR_OR_NULL(tags) in alb_upper_dev_walk.
    
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Link: https://lore.kernel.org/r/20231118081653.1481260-1-shaozhengchao@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Add map and need_defer parameters to .map_fd_put_ptr() [+ + +]
Author: Hou Tao <houtao1@huawei.com>
Date:   Mon Dec 4 22:04:20 2023 +0800

    bpf: Add map and need_defer parameters to .map_fd_put_ptr()
    
    [ Upstream commit 20c20bd11a0702ce4dc9300c3da58acf551d9725 ]
    
    map is the pointer of outer map, and need_defer needs some explanation.
    need_defer tells the implementation to defer the reference release of
    the passed element and ensure that the element is still alive before
    the bpf program, which may manipulate it, exits.
    
    The following three cases will invoke map_fd_put_ptr() and different
    need_defer values will be passed to these callers:
    
    1) release the reference of the old element in the map during map update
       or map deletion. The release must be deferred, otherwise the bpf
       program may incur use-after-free problem, so need_defer needs to be
       true.
    2) release the reference of the to-be-added element in the error path of
       map update. The to-be-added element is not visible to any bpf
       program, so it is OK to pass false for need_defer parameter.
    3) release the references of all elements in the map during map release.
       Any bpf program which has access to the map must have been exited and
       released, so need_defer=false will be OK.
    
    These two parameters will be used by the following patches to fix the
    potential use-after-free problem for map-in-map.
    
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/r/20231204140425.1480317-3-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Set uattr->batch.count as zero before batched update or deletion [+ + +]
Author: Hou Tao <houtao1@huawei.com>
Date:   Fri Dec 8 18:23:53 2023 +0800

    bpf: Set uattr->batch.count as zero before batched update or deletion
    
    [ Upstream commit 06e5c999f10269a532304e89a6adb2fbfeb0593c ]
    
    generic_map_{delete,update}_batch() doesn't set uattr->batch.count as
    zero before it tries to allocate memory for key. If the memory
    allocation fails, the value of uattr->batch.count will be incorrect.
    
    Fix it by setting uattr->batch.count as zero beore batched update or
    deletion.
    
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/r/20231208102355.2628918-6-houtao@huaweicloud.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bridge: cfm: fix enum typo in br_cc_ccm_tx_parse [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Thu Dec 21 00:34:51 2023 +0800

    bridge: cfm: fix enum typo in br_cc_ccm_tx_parse
    
    [ Upstream commit c2b2ee36250d967c21890cb801e24af4b6a9eaa5 ]
    
    It appears that there is a typo in the code where the nlattr array is
    being parsed with policy br_cfm_cc_ccm_tx_policy, but the instance is
    being accessed via IFLA_BRIDGE_CFM_CC_RDI_INSTANCE, which is associated
    with the policy br_cfm_cc_rdi_policy.
    
    This problem was introduced by commit 2be665c3940d ("bridge: cfm: Netlink
    SET configuration Interface.").
    
    Though it seems like a harmless typo since these two enum owns the exact
    same value (1 here), it is quite misleading hence fix it by using the
    correct enum IFLA_BRIDGE_CFM_CC_CCM_TX_INSTANCE here.
    
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bridge: mcast: fix disabled snooping after long uptime [+ + +]
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Sat Jan 27 18:50:32 2024 +0100

    bridge: mcast: fix disabled snooping after long uptime
    
    [ Upstream commit f5c3eb4b7251baba5cd72c9e93920e710ac8194a ]
    
    The original idea of the delay_time check was to not apply multicast
    snooping too early when an MLD querier appears. And to instead wait at
    least for MLD reports to arrive before switching from flooding to group
    based, MLD snooped forwarding, to avoid temporary packet loss.
    
    However in a batman-adv mesh network it was noticed that after 248 days of
    uptime 32bit MIPS based devices would start to signal that they had
    stopped applying multicast snooping due to missing queriers - even though
    they were the elected querier and still sending MLD queries themselves.
    
    While time_is_before_jiffies() generally is safe against jiffies
    wrap-arounds, like the code comments in jiffies.h explain, it won't
    be able to track a difference larger than ULONG_MAX/2. With a 32bit
    large jiffies and one jiffies tick every 10ms (CONFIG_HZ=100) on these MIPS
    devices running OpenWrt this would result in a difference larger than
    ULONG_MAX/2 after 248 (= 2^32/100/60/60/24/2) days and
    time_is_before_jiffies() would then start to return false instead of
    true. Leading to multicast snooping not being applied to multicast
    packets anymore.
    
    Fix this issue by using a proper timer_list object which won't have this
    ULONG_MAX/2 difference limitation.
    
    Fixes: b00589af3b04 ("bridge: disable snooping if there is no querier")
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
    Link: https://lore.kernel.org/r/20240127175033.9640-1-linus.luessing@c0d3.blue
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: add definition for EXTENT_TREE_V2 [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Dec 15 15:39:58 2021 -0500

    btrfs: add definition for EXTENT_TREE_V2
    
    [ Upstream commit 2c7d2a230237e7c43fa067d695937b7e484bb92a ]
    
    This adds the initial definition of the EXTENT_TREE_V2 incompat feature
    flag.  This also hides the support behind CONFIG_BTRFS_DEBUG.
    
    THIS IS A IN DEVELOPMENT FORMAT CHANGE, DO NOT USE UNLESS YOU ARE A
    DEVELOPER OR A TESTER.
    
    The format is in flux and will be added in stages, any fs will need to
    be re-made between updates to the format.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Stable-dep-of: 7081929ab257 ("btrfs: don't abort filesystem when attempting to snapshot deleted subvolume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: avoid copying BTRFS_ROOT_SUBVOL_DEAD flag to snapshot of subvolume being deleted [+ + +]
Author: Omar Sandoval <osandov@fb.com>
Date:   Thu Jan 4 11:48:47 2024 -0800

    btrfs: avoid copying BTRFS_ROOT_SUBVOL_DEAD flag to snapshot of subvolume being deleted
    
    commit 3324d0547861b16cf436d54abba7052e0c8aa9de upstream.
    
    Sweet Tea spotted a race between subvolume deletion and snapshotting
    that can result in the root item for the snapshot having the
    BTRFS_ROOT_SUBVOL_DEAD flag set. The race is:
    
    Thread 1                                      | Thread 2
    ----------------------------------------------|----------
    btrfs_delete_subvolume                        |
      btrfs_set_root_flags(BTRFS_ROOT_SUBVOL_DEAD)|
                                                  |btrfs_mksubvol
                                                  |  down_read(subvol_sem)
                                                  |  create_snapshot
                                                  |    ...
                                                  |    create_pending_snapshot
                                                  |      copy root item from source
      down_write(subvol_sem)                      |
    
    This flag is only checked in send and swap activate, which this would
    cause to fail mysteriously.
    
    create_snapshot() now checks the root refs to reject a deleted
    subvolume, so we can fix this by locking subvol_sem earlier so that the
    BTRFS_ROOT_SUBVOL_DEAD flag and the root refs are updated atomically.
    
    CC: stable@vger.kernel.org # 4.14+
    Reported-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
    Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: defrag: reject unknown flags of btrfs_ioctl_defrag_range_args [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Wed Jan 10 08:58:26 2024 +1030

    btrfs: defrag: reject unknown flags of btrfs_ioctl_defrag_range_args
    
    commit 173431b274a9a54fc10b273b46e67f46bcf62d2e upstream.
    
    Add extra sanity check for btrfs_ioctl_defrag_range_args::flags.
    
    This is not really to enhance fuzzing tests, but as a preparation for
    future expansion on btrfs_ioctl_defrag_range_args.
    
    In the future we're going to add new members, allowing more fine tuning
    for btrfs defrag.  Without the -ENONOTSUPP error, there would be no way
    to detect if the kernel supports those new defrag features.
    
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: do not ASSERT() if the newly created subvolume already got read [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Sat Jan 20 19:41:28 2024 +1030

    btrfs: do not ASSERT() if the newly created subvolume already got read
    
    commit e03ee2fe873eb68c1f9ba5112fee70303ebf9dfb upstream.
    
    [BUG]
    There is a syzbot crash, triggered by the ASSERT() during subvolume
    creation:
    
     assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319
     ------------[ cut here ]------------
     kernel BUG at fs/btrfs/disk-io.c:1319!
     invalid opcode: 0000 [#1] PREEMPT SMP KASAN
     RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60
      <TASK>
      btrfs_get_new_fs_root+0xd3/0xf0
      create_subvol+0xd02/0x1650
      btrfs_mksubvol+0xe95/0x12b0
      __btrfs_ioctl_snap_create+0x2f9/0x4f0
      btrfs_ioctl_snap_create+0x16b/0x200
      btrfs_ioctl+0x35f0/0x5cf0
      __x64_sys_ioctl+0x19d/0x210
      do_syscall_64+0x3f/0xe0
      entry_SYSCALL_64_after_hwframe+0x63/0x6b
     ---[ end trace 0000000000000000 ]---
    
    [CAUSE]
    During create_subvol(), after inserting root item for the newly created
    subvolume, we would trigger btrfs_get_new_fs_root() to get the
    btrfs_root of that subvolume.
    
    The idea here is, we have preallocated an anonymous device number for
    the subvolume, thus we can assign it to the new subvolume.
    
    But there is really nothing preventing things like backref walk to read
    the new subvolume.
    If that happens before we call btrfs_get_new_fs_root(), the subvolume
    would be read out, with a new anonymous device number assigned already.
    
    In that case, we would trigger ASSERT(), as we really expect no one to
    read out that subvolume (which is not yet accessible from the fs).
    But things like backref walk is still possible to trigger the read on
    the subvolume.
    
    Thus our assumption on the ASSERT() is not correct in the first place.
    
    [FIX]
    Fix it by removing the ASSERT(), and just free the @anon_dev, reset it
    to 0, and continue.
    
    If the subvolume tree is read out by something else, it should have
    already get a new anon_dev assigned thus we only need to free the
    preallocated one.
    
    Reported-by: Chenyuan Yang <chenyuan0y@gmail.com>
    Fixes: 2dfb1e43f57d ("btrfs: preallocate anon block device at first phase of snapshot creation")
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: don't abort filesystem when attempting to snapshot deleted subvolume [+ + +]
Author: Omar Sandoval <osandov@fb.com>
Date:   Thu Jan 4 11:48:46 2024 -0800

    btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
    
    commit 7081929ab2572920e94d70be3d332e5c9f97095a upstream.
    
    If the source file descriptor to the snapshot ioctl refers to a deleted
    subvolume, we get the following abort:
    
      BTRFS: Transaction aborted (error -2)
      WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]
      Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c
      CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
      RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]
      RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027
      RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840
      RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998
      R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe
      R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80
      FS:  00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0
      Call Trace:
       <TASK>
       ? create_pending_snapshot+0x1040/0x1190 [btrfs]
       ? __warn+0x81/0x130
       ? create_pending_snapshot+0x1040/0x1190 [btrfs]
       ? report_bug+0x171/0x1a0
       ? handle_bug+0x3a/0x70
       ? exc_invalid_op+0x17/0x70
       ? asm_exc_invalid_op+0x1a/0x20
       ? create_pending_snapshot+0x1040/0x1190 [btrfs]
       ? create_pending_snapshot+0x1040/0x1190 [btrfs]
       create_pending_snapshots+0x92/0xc0 [btrfs]
       btrfs_commit_transaction+0x66b/0xf40 [btrfs]
       btrfs_mksubvol+0x301/0x4d0 [btrfs]
       btrfs_mksnapshot+0x80/0xb0 [btrfs]
       __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]
       btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]
       btrfs_ioctl+0x8a6/0x2650 [btrfs]
       ? kmem_cache_free+0x22/0x340
       ? do_sys_openat2+0x97/0xe0
       __x64_sys_ioctl+0x97/0xd0
       do_syscall_64+0x46/0xf0
       entry_SYSCALL_64_after_hwframe+0x6e/0x76
      RIP: 0033:0x7fe20abe83af
      RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af
      RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003
      RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58
       </TASK>
      ---[ end trace 0000000000000000 ]---
      BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry
      BTRFS info (device vdc: state EA): forced readonly
      BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.
      BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry
    
    This happens because create_pending_snapshot() initializes the new root
    item as a copy of the source root item. This includes the refs field,
    which is 0 for a deleted subvolume. The call to btrfs_insert_root()
    therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then
    finds the root and returns -ENOENT if refs == 0, which causes
    create_pending_snapshot() to abort.
    
    Fix it by checking the source root's refs before attempting the
    snapshot, but after locking subvol_sem to avoid racing with deletion.
    
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: don't warn if discard range is not aligned to sector [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Mon Jan 15 20:30:26 2024 +0100

    btrfs: don't warn if discard range is not aligned to sector
    
    commit a208b3f132b48e1f94f620024e66fea635925877 upstream.
    
    There's a warning in btrfs_issue_discard() when the range is not aligned
    to 512 bytes, originally added in 4d89d377bbb0 ("btrfs:
    btrfs_issue_discard ensure offset/length are aligned to sector
    boundaries"). We can't do sub-sector writes anyway so the adjustment is
    the only thing that we can do and the warning is unnecessary.
    
    CC: stable@vger.kernel.org # 4.19+
    Reported-by: syzbot+4a4f1eba14eb5c3417d1@syzkaller.appspotmail.com
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix infinite directory reads [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jan 25 11:59:35 2024 +0000

    btrfs: fix infinite directory reads
    
    commit 9b378f6ad48cfa195ed868db9123c09ee7ec5ea2 upstream.
    
    The readdir implementation currently processes always up to the last index
    it finds. This however can result in an infinite loop if the directory has
    a large number of entries such that they won't all fit in the given buffer
    passed to the readdir callback, that is, dir_emit() returns a non-zero
    value. Because in that case readdir() will be called again and if in the
    meanwhile new directory entries were added and we still can't put all the
    remaining entries in the buffer, we keep repeating this over and over.
    
    The following C program and test script reproduce the problem:
    
      $ cat /mnt/readdir_prog.c
      #include <sys/types.h>
      #include <dirent.h>
      #include <stdio.h>
    
      int main(int argc, char *argv[])
      {
        DIR *dir = opendir(".");
        struct dirent *dd;
    
        while ((dd = readdir(dir))) {
          printf("%s\n", dd->d_name);
          rename(dd->d_name, "TEMPFILE");
          rename("TEMPFILE", dd->d_name);
        }
        closedir(dir);
      }
    
      $ gcc -o /mnt/readdir_prog /mnt/readdir_prog.c
    
      $ cat test.sh
      #!/bin/bash
    
      DEV=/dev/sdi
      MNT=/mnt/sdi
    
      mkfs.btrfs -f $DEV &> /dev/null
      #mkfs.xfs -f $DEV &> /dev/null
      #mkfs.ext4 -F $DEV &> /dev/null
    
      mount $DEV $MNT
    
      mkdir $MNT/testdir
      for ((i = 1; i <= 2000; i++)); do
          echo -n > $MNT/testdir/file_$i
      done
    
      cd $MNT/testdir
      /mnt/readdir_prog
    
      cd /mnt
    
      umount $MNT
    
    This behaviour is surprising to applications and it's unlike ext4, xfs,
    tmpfs, vfat and other filesystems, which always finish. In this case where
    new entries were added due to renames, some file names may be reported
    more than once, but this varies according to each filesystem - for example
    ext4 never reported the same file more than once while xfs reports the
    first 13 file names twice.
    
    So change our readdir implementation to track the last index number when
    opendir() is called and then make readdir() never process beyond that
    index number. This gives the same behaviour as ext4.
    
    Reported-by: Rob Landley <rob@landley.net>
    Link: https://lore.kernel.org/linux-btrfs/2c8c55ec-04c6-e0dc-9c5c-8c7924778c35@landley.net/
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=217681
    CC: stable@vger.kernel.org # 5.15
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    [ Resolve a conflict due to member changes in 96d89923fa94 ]
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Eugeniu Rosca <eugeniu.rosca@bosch.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: fix race between reading a directory and adding entries to it [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jan 25 11:59:38 2024 +0000

    btrfs: fix race between reading a directory and adding entries to it
    
    commit 8e7f82deb0c0386a03b62e30082574347f8b57d5 upstream.
    
    When opening a directory (opendir(3)) or rewinding it (rewinddir(3)), we
    are not holding the directory's inode locked, and this can result in later
    attempting to add two entries to the directory with the same index number,
    resulting in a transaction abort, with -EEXIST (-17), when inserting the
    second delayed dir index. This results in a trace like the following:
    
      Sep 11 22:34:59 myhostname kernel: BTRFS error (device dm-3): err add delayed dir index item(name: cockroach-stderr.log) into the insertion tree of the delayed node(root id: 5, inode id: 4539217, errno: -17)
      Sep 11 22:34:59 myhostname kernel: ------------[ cut here ]------------
      Sep 11 22:34:59 myhostname kernel: kernel BUG at fs/btrfs/delayed-inode.c:1504!
      Sep 11 22:34:59 myhostname kernel: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
      Sep 11 22:34:59 myhostname kernel: CPU: 0 PID: 7159 Comm: cockroach Not tainted 6.4.15-200.fc38.x86_64 #1
      Sep 11 22:34:59 myhostname kernel: Hardware name: ASUS ESC500 G3/P9D WS, BIOS 2402 06/27/2018
      Sep 11 22:34:59 myhostname kernel: RIP: 0010:btrfs_insert_delayed_dir_index+0x1da/0x260
      Sep 11 22:34:59 myhostname kernel: Code: eb dd 48 (...)
      Sep 11 22:34:59 myhostname kernel: RSP: 0000:ffffa9980e0fbb28 EFLAGS: 00010282
      Sep 11 22:34:59 myhostname kernel: RAX: 0000000000000000 RBX: ffff8b10b8f4a3c0 RCX: 0000000000000000
      Sep 11 22:34:59 myhostname kernel: RDX: 0000000000000000 RSI: ffff8b177ec21540 RDI: ffff8b177ec21540
      Sep 11 22:34:59 myhostname kernel: RBP: ffff8b110cf80888 R08: 0000000000000000 R09: ffffa9980e0fb938
      Sep 11 22:34:59 myhostname kernel: R10: 0000000000000003 R11: ffffffff86146508 R12: 0000000000000014
      Sep 11 22:34:59 myhostname kernel: R13: ffff8b1131ae5b40 R14: ffff8b10b8f4a418 R15: 00000000ffffffef
      Sep 11 22:34:59 myhostname kernel: FS:  00007fb14a7fe6c0(0000) GS:ffff8b177ec00000(0000) knlGS:0000000000000000
      Sep 11 22:34:59 myhostname kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      Sep 11 22:34:59 myhostname kernel: CR2: 000000c00143d000 CR3: 00000001b3b4e002 CR4: 00000000001706f0
      Sep 11 22:34:59 myhostname kernel: Call Trace:
      Sep 11 22:34:59 myhostname kernel:  <TASK>
      Sep 11 22:34:59 myhostname kernel:  ? die+0x36/0x90
      Sep 11 22:34:59 myhostname kernel:  ? do_trap+0xda/0x100
      Sep 11 22:34:59 myhostname kernel:  ? btrfs_insert_delayed_dir_index+0x1da/0x260
      Sep 11 22:34:59 myhostname kernel:  ? do_error_trap+0x6a/0x90
      Sep 11 22:34:59 myhostname kernel:  ? btrfs_insert_delayed_dir_index+0x1da/0x260
      Sep 11 22:34:59 myhostname kernel:  ? exc_invalid_op+0x50/0x70
      Sep 11 22:34:59 myhostname kernel:  ? btrfs_insert_delayed_dir_index+0x1da/0x260
      Sep 11 22:34:59 myhostname kernel:  ? asm_exc_invalid_op+0x1a/0x20
      Sep 11 22:34:59 myhostname kernel:  ? btrfs_insert_delayed_dir_index+0x1da/0x260
      Sep 11 22:34:59 myhostname kernel:  ? btrfs_insert_delayed_dir_index+0x1da/0x260
      Sep 11 22:34:59 myhostname kernel:  btrfs_insert_dir_item+0x200/0x280
      Sep 11 22:34:59 myhostname kernel:  btrfs_add_link+0xab/0x4f0
      Sep 11 22:34:59 myhostname kernel:  ? ktime_get_real_ts64+0x47/0xe0
      Sep 11 22:34:59 myhostname kernel:  btrfs_create_new_inode+0x7cd/0xa80
      Sep 11 22:34:59 myhostname kernel:  btrfs_symlink+0x190/0x4d0
      Sep 11 22:34:59 myhostname kernel:  ? schedule+0x5e/0xd0
      Sep 11 22:34:59 myhostname kernel:  ? __d_lookup+0x7e/0xc0
      Sep 11 22:34:59 myhostname kernel:  vfs_symlink+0x148/0x1e0
      Sep 11 22:34:59 myhostname kernel:  do_symlinkat+0x130/0x140
      Sep 11 22:34:59 myhostname kernel:  __x64_sys_symlinkat+0x3d/0x50
      Sep 11 22:34:59 myhostname kernel:  do_syscall_64+0x5d/0x90
      Sep 11 22:34:59 myhostname kernel:  ? syscall_exit_to_user_mode+0x2b/0x40
      Sep 11 22:34:59 myhostname kernel:  ? do_syscall_64+0x6c/0x90
      Sep 11 22:34:59 myhostname kernel:  entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    The race leading to the problem happens like this:
    
    1) Directory inode X is loaded into memory, its ->index_cnt field is
       initialized to (u64)-1 (at btrfs_alloc_inode());
    
    2) Task A is adding a new file to directory X, holding its vfs inode lock,
       and calls btrfs_set_inode_index() to get an index number for the entry.
    
       Because the inode's index_cnt field is set to (u64)-1 it calls
       btrfs_inode_delayed_dir_index_count() which fails because no dir index
       entries were added yet to the delayed inode and then it calls
       btrfs_set_inode_index_count(). This functions finds the last dir index
       key and then sets index_cnt to that index value + 1. It found that the
       last index key has an offset of 100. However before it assigns a value
       of 101 to index_cnt...
    
    3) Task B calls opendir(3), ending up at btrfs_opendir(), where the VFS
       lock for inode X is not taken, so it calls btrfs_get_dir_last_index()
       and sees index_cnt still with a value of (u64)-1. Because of that it
       calls btrfs_inode_delayed_dir_index_count() which fails since no dir
       index entries were added to the delayed inode yet, and then it also
       calls btrfs_set_inode_index_count(). This also finds that the last
       index key has an offset of 100, and before it assigns the value 101
       to the index_cnt field of inode X...
    
    4) Task A assigns a value of 101 to index_cnt. And then the code flow
       goes to btrfs_set_inode_index() where it increments index_cnt from
       101 to 102. Task A then creates a delayed dir index entry with a
       sequence number of 101 and adds it to the delayed inode;
    
    5) Task B assigns 101 to the index_cnt field of inode X;
    
    6) At some later point when someone tries to add a new entry to the
       directory, btrfs_set_inode_index() will return 101 again and shortly
       after an attempt to add another delayed dir index key with index
       number 101 will fail with -EEXIST resulting in a transaction abort.
    
    Fix this by locking the inode at btrfs_get_dir_last_index(), which is only
    only used when opening a directory or attempting to lseek on it.
    
    Reported-by: ken <ken@bllue.org>
    Link: https://lore.kernel.org/linux-btrfs/CAE6xmH+Lp=Q=E61bU+v9eWX8gYfLvu6jLYxjxjFpo3zHVPR0EQ@mail.gmail.com/
    Reported-by: syzbot+d13490c82ad5353c779d@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/linux-btrfs/00000000000036e1290603e097e0@google.com/
    Fixes: 9b378f6ad48c ("btrfs: fix infinite directory reads")
    CC: stable@vger.kernel.org # 6.5+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Reviewed-by: Eugeniu Rosca <eugeniu.rosca@bosch.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: forbid creating subvol qgroups [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Wed Jan 10 17:51:26 2024 -0800

    btrfs: forbid creating subvol qgroups
    
    commit 0c309d66dacddf8ce939b891d9ead4a8e21ad6f0 upstream.
    
    Creating a qgroup 0/subvolid leads to various races and it isn't
    helpful, because you can't specify a subvol id when creating a subvol,
    so you can't be sure it will be the right one. Any requirements on the
    automatic subvol can be gratified by using a higher level qgroup and the
    inheritance parameters of subvol creation.
    
    Fixes: cecbb533b5fc ("btrfs: record simple quota deltas in delayed refs")
    CC: stable@vger.kernel.org # 4.14+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: forbid deleting live subvol qgroup [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Wed Jan 10 17:30:00 2024 -0800

    btrfs: forbid deleting live subvol qgroup
    
    commit a8df35619948bd8363d330c20a90c9a7fbff28c0 upstream.
    
    If a subvolume still exists, forbid deleting its qgroup 0/subvolid.
    This behavior generally leads to incorrect behavior in squotas and
    doesn't have a legitimate purpose.
    
    Fixes: cecbb533b5fc ("btrfs: record simple quota deltas in delayed refs")
    CC: stable@vger.kernel.org # 5.4+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: ref-verify: free ref cache before clearing mount opt [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Wed Jan 3 13:31:27 2024 +0300

    btrfs: ref-verify: free ref cache before clearing mount opt
    
    commit f03e274a8b29d1d1c1bbd7f764766cb5ca537ab7 upstream.
    
    As clearing REF_VERIFY mount option indicates there were some errors in a
    ref-verify process, a ref cache is not relevant anymore and should be
    freed.
    
    btrfs_free_ref_cache() requires REF_VERIFY option being set so call
    it just before clearing the mount option.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Reported-by: syzbot+be14ed7728594dc8bd42@syzkaller.appspotmail.com
    Fixes: fd708b81d972 ("Btrfs: add a extent ref verify tool")
    CC: stable@vger.kernel.org # 5.4+
    Closes: https://lore.kernel.org/lkml/000000000000e5a65c05ee832054@google.com/
    Reported-by: syzbot+c563a3c79927971f950f@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/lkml/0000000000007fe09705fdc6086c@google.com/
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: refresh dir last index during a rewinddir(3) call [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jan 25 11:59:37 2024 +0000

    btrfs: refresh dir last index during a rewinddir(3) call
    
    commit e60aa5da14d01fed8411202dbe4adf6c44bd2a57 upstream.
    
    When opening a directory we find what's the index of its last entry and
    then store it in the directory's file handle private data (struct
    btrfs_file_private::last_index), so that in the case new directory entries
    are added to a directory after an opendir(3) call we don't end up in an
    infinite loop (see commit 9b378f6ad48c ("btrfs: fix infinite directory
    reads")) when calling readdir(3).
    
    However once rewinddir(3) is called, POSIX states [1] that any new
    directory entries added after the previous opendir(3) call, must be
    returned by subsequent calls to readdir(3):
    
      "The rewinddir() function shall reset the position of the directory
       stream to which dirp refers to the beginning of the directory.
       It shall also cause the directory stream to refer to the current
       state of the corresponding directory, as a call to opendir() would
       have done."
    
    We currently don't refresh the last_index field of the struct
    btrfs_file_private associated to the directory, so after a rewinddir(3)
    we are not returning any new entries added after the opendir(3) call.
    
    Fix this by finding the current last index of the directory when llseek
    is called against the directory.
    
    This can be reproduced by the following C program provided by Ian Johnson:
    
       #include <dirent.h>
       #include <stdio.h>
    
       int main(void) {
         DIR *dir = opendir("test");
    
         FILE *file;
         file = fopen("test/1", "w");
         fwrite("1", 1, 1, file);
         fclose(file);
    
         file = fopen("test/2", "w");
         fwrite("2", 1, 1, file);
         fclose(file);
    
         rewinddir(dir);
    
         struct dirent *entry;
         while ((entry = readdir(dir))) {
            printf("%s\n", entry->d_name);
         }
         closedir(dir);
         return 0;
       }
    
    Reported-by: Ian Johnson <ian@ianjohnson.dev>
    Link: https://lore.kernel.org/linux-btrfs/YR1P0S.NGASEG570GJ8@ianjohnson.dev/
    Fixes: 9b378f6ad48c ("btrfs: fix infinite directory reads")
    CC: stable@vger.kernel.org # 6.5+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Reviewed-by: Eugeniu Rosca <eugeniu.rosca@bosch.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: send: return EOPNOTSUPP on unknown flags [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Wed Jan 10 17:48:44 2024 +0100

    btrfs: send: return EOPNOTSUPP on unknown flags
    
    commit f884a9f9e59206a2d41f265e7e403f080d10b493 upstream.
    
    When some ioctl flags are checked we return EOPNOTSUPP, like for
    BTRFS_SCRUB_SUPPORTED_FLAGS, BTRFS_SUBVOL_CREATE_ARGS_MASK or fallocate
    modes. The EINVAL is supposed to be for a supported but invalid
    values or combination of options. Fix that when checking send flags so
    it's consistent with the rest.
    
    CC: stable@vger.kernel.org # 4.14+
    Link: https://lore.kernel.org/linux-btrfs/CAL3q7H5rryOLzp3EKq8RTbjMHMHeaJubfpsVLF6H4qJnKCUR1w@mail.gmail.com/
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: set last dir index to the current last index when opening dir [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Jan 25 11:59:36 2024 +0000

    btrfs: set last dir index to the current last index when opening dir
    
    commit 357950361cbc6d54fb68ed878265c647384684ae upstream.
    
    When opening a directory for reading it, we set the last index where we
    stop iteration to the value in struct btrfs_inode::index_cnt. That value
    does not match the index of the most recently added directory entry but
    it's instead the index number that will be assigned the next directory
    entry.
    
    This means that if after the call to opendir(3) new directory entries are
    added, a readdir(3) call will return the first new directory entry. This
    is fine because POSIX says the following [1]:
    
      "If a file is removed from or added to the directory after the most
       recent call to opendir() or rewinddir(), whether a subsequent call to
       readdir() returns an entry for that file is unspecified."
    
    For example for the test script from commit 9b378f6ad48c ("btrfs: fix
    infinite directory reads"), where we have 2000 files in a directory, ext4
    doesn't return any new directory entry after opendir(3), while xfs returns
    the first 13 new directory entries added after the opendir(3) call.
    
    If we move to a shorter example with an empty directory when opendir(3) is
    called, and 2 files added to the directory after the opendir(3) call, then
    readdir(3) on btrfs will return the first file, ext4 and xfs return the 2
    files (but in a different order). A test program for this, reported by
    Ian Johnson, is the following:
    
       #include <dirent.h>
       #include <stdio.h>
    
       int main(void) {
         DIR *dir = opendir("test");
    
         FILE *file;
         file = fopen("test/1", "w");
         fwrite("1", 1, 1, file);
         fclose(file);
    
         file = fopen("test/2", "w");
         fwrite("2", 1, 1, file);
         fclose(file);
    
         struct dirent *entry;
         while ((entry = readdir(dir))) {
            printf("%s\n", entry->d_name);
         }
         closedir(dir);
         return 0;
       }
    
    To make this less odd, change the behaviour to never return new entries
    that were added after the opendir(3) call. This is done by setting the
    last_index field of the struct btrfs_file_private attached to the
    directory's file handle with a value matching btrfs_inode::index_cnt
    minus 1, since that value always matches the index of the next new
    directory entry and not the index of the most recently added entry.
    
    [1] https://pubs.opengroup.org/onlinepubs/007904875/functions/readdir_r.html
    
    Link: https://lore.kernel.org/linux-btrfs/YR1P0S.NGASEG570GJ8@ianjohnson.dev/
    CC: stable@vger.kernel.org # 6.5+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Reviewed-by: Eugeniu Rosca <eugeniu.rosca@bosch.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: sysfs: validate scrub_speed_max value [+ + +]
Author: David Disseldorp <ddiss@suse.de>
Date:   Fri Dec 8 11:41:56 2023 +1100

    btrfs: sysfs: validate scrub_speed_max value
    
    commit 2b0122aaa800b021e36027d7f29e206f87c761d6 upstream.
    
    The value set as scrub_speed_max accepts size with suffixes
    (k/m/g/t/p/e) but we should still validate it for trailing characters,
    similar to what we do with chunk_size_store.
    
    CC: stable@vger.kernel.org # 5.15+
    Signed-off-by: David Disseldorp <ddiss@suse.de>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: tree-checker: fix inline ref size in error messages [+ + +]
Author: Chung-Chiang Cheng <cccheng@synology.com>
Date:   Fri Jan 12 15:41:05 2024 +0800

    btrfs: tree-checker: fix inline ref size in error messages
    
    commit f398e70dd69e6ceea71463a5380e6118f219197e upstream.
    
    The error message should accurately reflect the size rather than the
    type.
    
    Fixes: f82d1c7ca8ae ("btrfs: tree-checker: Add EXTENT_ITEM and METADATA_ITEM check")
    CC: stable@vger.kernel.org # 5.4+
    Reviewed-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bus: mhi: host: Add alignment check for event ring read pointer [+ + +]
Author: Krishna chaitanya chundru <quic_krichai@quicinc.com>
Date:   Tue Oct 31 15:21:05 2023 +0530

    bus: mhi: host: Add alignment check for event ring read pointer
    
    [ Upstream commit eff9704f5332a13b08fbdbe0f84059c9e7051d5f ]
    
    Though we do check the event ring read pointer by "is_valid_ring_ptr"
    to make sure it is in the buffer range, but there is another risk the
    pointer may be not aligned.  Since we are expecting event ring elements
    are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer
    could lead to multiple issues like DoS or ring buffer memory corruption.
    
    So add a alignment check for event ring read pointer.
    
    Fixes: ec32332df764 ("bus: mhi: core: Sanity check values from remote device before use")
    cc: stable@vger.kernel.org
    Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20231031-alignment_check-v2-1-1441db7c5efd@quicinc.com
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bus: mhi: host: Add spinlock to protect WP access when queueing TREs [+ + +]
Author: Bhaumik Bhatt <bbhatt@codeaurora.org>
Date:   Mon Dec 11 14:42:51 2023 +0800

    bus: mhi: host: Add spinlock to protect WP access when queueing TREs
    
    commit b89b6a863dd53bc70d8e52d50f9cfaef8ef5e9c9 upstream.
    
    Protect WP accesses such that multiple threads queueing buffers for
    incoming data do not race.
    
    Meanwhile, if CONFIG_TRACE_IRQFLAGS is enabled, irq will be enabled once
    __local_bh_enable_ip is called as part of write_unlock_bh. Hence, let's
    take irqsave lock after TRE is generated to avoid running write_unlock_bh
    when irqsave lock is held.
    
    Cc: stable@vger.kernel.org
    Fixes: 189ff97cca53 ("bus: mhi: core: Add support for data transfer")
    Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
    Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/1702276972-41296-2-git-send-email-quic_qianyu@quicinc.com
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bus: mhi: host: Drop chan lock before queuing buffers [+ + +]
Author: Qiang Yu <quic_qianyu@quicinc.com>
Date:   Mon Dec 11 14:42:52 2023 +0800

    bus: mhi: host: Drop chan lock before queuing buffers
    
    commit 01bd694ac2f682fb8017e16148b928482bc8fa4b upstream.
    
    Ensure read and write locks for the channel are not taken in succession by
    dropping the read lock from parse_xfer_event() such that a callback given
    to client can potentially queue buffers and acquire the write lock in that
    process. Any queueing of buffers should be done without channel read lock
    acquired as it can result in multiple locks and a soft lockup.
    
    Cc: <stable@vger.kernel.org> # 5.7
    Fixes: 1d3173a3bae7 ("bus: mhi: core: Add support for processing events from client device")
    Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/1702276972-41296-3-git-send-email-quic_qianyu@quicinc.com
    [mani: added fixes tag and cc'ed stable]
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bus: mhi: host: Rename "struct mhi_tre" to "struct mhi_ring_element" [+ + +]
Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Date:   Tue Mar 1 21:33:06 2022 +0530

    bus: mhi: host: Rename "struct mhi_tre" to "struct mhi_ring_element"
    
    [ Upstream commit 84f5f31f110e5e8cd5581e8efdbf8c369e962eb9 ]
    
    Structure "struct mhi_tre" is representing a generic MHI ring element and
    not specifically a Transfer Ring Element (TRE). Fix the naming.
    
    Reviewed-by: Alex Elder <elder@linaro.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20220301160308.107452-9-manivannan.sadhasivam@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: eff9704f5332 ("bus: mhi: host: Add alignment check for event ring read pointer")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bus: moxtet: Add spi device table [+ + +]
Author: Sjoerd Simons <sjoerd@collabora.com>
Date:   Tue Nov 28 22:35:05 2023 +0100

    bus: moxtet: Add spi device table
    
    [ Upstream commit aaafe88d5500ba18b33be72458439367ef878788 ]
    
    The moxtet module fails to auto-load on. Add a SPI id table to
    allow it to do so.
    
    Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
    Cc:  <stable@vger.kernel.org>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) [+ + +]
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Fri Oct 20 15:38:14 2023 +0200

    can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
    
    commit efe7cf828039aedb297c1f9920b638fffee6aabc upstream.
    
    Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
    modifies jsk->filters while receiving packets.
    
    Following trace was seen on affected system:
     ==================================================================
     BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
     Read of size 4 at addr ffff888012144014 by task j1939/350
    
     CPU: 0 PID: 350 Comm: j1939 Tainted: G        W  OE      6.5.0-rc5 #1
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
     Call Trace:
      print_report+0xd3/0x620
      ? kasan_complete_mode_report_info+0x7d/0x200
      ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
      kasan_report+0xc2/0x100
      ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
      __asan_load4+0x84/0xb0
      j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
      j1939_sk_recv+0x20b/0x320 [can_j1939]
      ? __kasan_check_write+0x18/0x20
      ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
      ? j1939_simple_recv+0x69/0x280 [can_j1939]
      ? j1939_ac_recv+0x5e/0x310 [can_j1939]
      j1939_can_recv+0x43f/0x580 [can_j1939]
      ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
      ? raw_rcv+0x42/0x3c0 [can_raw]
      ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
      can_rcv_filter+0x11f/0x350 [can]
      can_receive+0x12f/0x190 [can]
      ? __pfx_can_rcv+0x10/0x10 [can]
      can_rcv+0xdd/0x130 [can]
      ? __pfx_can_rcv+0x10/0x10 [can]
      __netif_receive_skb_one_core+0x13d/0x150
      ? __pfx___netif_receive_skb_one_core+0x10/0x10
      ? __kasan_check_write+0x18/0x20
      ? _raw_spin_lock_irq+0x8c/0xe0
      __netif_receive_skb+0x23/0xb0
      process_backlog+0x107/0x260
      __napi_poll+0x69/0x310
      net_rx_action+0x2a1/0x580
      ? __pfx_net_rx_action+0x10/0x10
      ? __pfx__raw_spin_lock+0x10/0x10
      ? handle_irq_event+0x7d/0xa0
      __do_softirq+0xf3/0x3f8
      do_softirq+0x53/0x80
      </IRQ>
      <TASK>
      __local_bh_enable_ip+0x6e/0x70
      netif_rx+0x16b/0x180
      can_send+0x32b/0x520 [can]
      ? __pfx_can_send+0x10/0x10 [can]
      ? __check_object_size+0x299/0x410
      raw_sendmsg+0x572/0x6d0 [can_raw]
      ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
      ? apparmor_socket_sendmsg+0x2f/0x40
      ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
      sock_sendmsg+0xef/0x100
      sock_write_iter+0x162/0x220
      ? __pfx_sock_write_iter+0x10/0x10
      ? __rtnl_unlock+0x47/0x80
      ? security_file_permission+0x54/0x320
      vfs_write+0x6ba/0x750
      ? __pfx_vfs_write+0x10/0x10
      ? __fget_light+0x1ca/0x1f0
      ? __rcu_read_unlock+0x5b/0x280
      ksys_write+0x143/0x170
      ? __pfx_ksys_write+0x10/0x10
      ? __kasan_check_read+0x15/0x20
      ? fpregs_assert_state_consistent+0x62/0x70
      __x64_sys_write+0x47/0x60
      do_syscall_64+0x60/0x90
      ? do_syscall_64+0x6d/0x90
      ? irqentry_exit+0x3f/0x50
      ? exc_page_fault+0x79/0xf0
      entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
     Allocated by task 348:
      kasan_save_stack+0x2a/0x50
      kasan_set_track+0x29/0x40
      kasan_save_alloc_info+0x1f/0x30
      __kasan_kmalloc+0xb5/0xc0
      __kmalloc_node_track_caller+0x67/0x160
      j1939_sk_setsockopt+0x284/0x450 [can_j1939]
      __sys_setsockopt+0x15c/0x2f0
      __x64_sys_setsockopt+0x6b/0x80
      do_syscall_64+0x60/0x90
      entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
     Freed by task 349:
      kasan_save_stack+0x2a/0x50
      kasan_set_track+0x29/0x40
      kasan_save_free_info+0x2f/0x50
      __kasan_slab_free+0x12e/0x1c0
      __kmem_cache_free+0x1b9/0x380
      kfree+0x7a/0x120
      j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
      __sys_setsockopt+0x15c/0x2f0
      __x64_sys_setsockopt+0x6b/0x80
      do_syscall_64+0x60/0x90
      entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
    Fixes: 9d71dd0c70099 ("can: add support of SAE J1939 protocol")
    Reported-by: Sili Luo <rootlab@huawei.com>
    Suggested-by: Sili Luo <rootlab@huawei.com>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/all/20231020133814.383996-1-o.rempel@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock [+ + +]
Author: Ziqi Zhao <astrajoan@yahoo.com>
Date:   Fri Jul 21 09:22:26 2023 -0700

    can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
    
    commit 6cdedc18ba7b9dacc36466e27e3267d201948c8d upstream.
    
    The following 3 locks would race against each other, causing the
    deadlock situation in the Syzbot bug report:
    
    - j1939_socks_lock
    - active_session_list_lock
    - sk_session_queue_lock
    
    A reasonable fix is to change j1939_socks_lock to an rwlock, since in
    the rare situations where a write lock is required for the linked list
    that j1939_socks_lock is protecting, the code does not attempt to
    acquire any more locks. This would break the circular lock dependency,
    where, for example, the current thread already locks j1939_socks_lock
    and attempts to acquire sk_session_queue_lock, and at the same time,
    another thread attempts to acquire j1939_socks_lock while holding
    sk_session_queue_lock.
    
    NOTE: This patch along does not fix the unregister_netdevice bug
    reported by Syzbot; instead, it solves a deadlock situation to prepare
    for one or more further patches to actually fix the Syzbot bug, which
    appears to be a reference counting problem within the j1939 codebase.
    
    Reported-by: <syzbot+1591462f226d9cbf0564@syzkaller.appspotmail.com>
    Signed-off-by: Ziqi Zhao <astrajoan@yahoo.com>
    Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/all/20230721162226.8639-1-astrajoan@yahoo.com
    [mkl: remove unrelated newline change]
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ceph: fix deadlock or deadcode of misusing dget() [+ + +]
Author: Xiubo Li <xiubli@redhat.com>
Date:   Fri Nov 17 13:26:18 2023 +0800

    ceph: fix deadlock or deadcode of misusing dget()
    
    [ Upstream commit b493ad718b1f0357394d2cdecbf00a44a36fa085 ]
    
    The lock order is incorrect between denty and its parent, we should
    always make sure that the parent get the lock first.
    
    But since this deadcode is never used and the parent dir will always
    be set from the callers, let's just remove it.
    
    Link: https://lore.kernel.org/r/20231116081919.GZ1957730@ZenIV
    Reported-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ceph: prevent use-after-free in encode_cap_msg() [+ + +]
Author: Rishabh Dave <ridave@redhat.com>
Date:   Thu Feb 1 17:07:16 2024 +0530

    ceph: prevent use-after-free in encode_cap_msg()
    
    commit cda4672da1c26835dcbd7aec2bfed954eda9b5ef upstream.
    
    In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
    caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This
    implies before the refcount could be increment here, it was freed.
    
    In same file, in "handle_cap_grant()" refcount is decremented by this
    line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race
    occurred and resource was freed by the latter line before the former
    line could increment it.
    
    encode_cap_msg() is called by __send_cap() and __send_cap() is called by
    ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
    arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where
    the refcount must be increased to prevent "use after free" error.
    
    Cc: stable@vger.kernel.org
    Link: https://tracker.ceph.com/issues/59259
    Signed-off-by: Rishabh Dave <ridave@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
clk: hi3620: Fix memory leak in hi3620_mmc_clk_init() [+ + +]
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date:   Mon Dec 11 00:50:40 2023 +0800

    clk: hi3620: Fix memory leak in hi3620_mmc_clk_init()
    
    [ Upstream commit bfbea9e5667cfa9552c3d88f023386f017f6c308 ]
    
    In cases where kcalloc() fails for the 'clk_data->clks' allocation, the
    code path does not handle the failure gracefully, potentially leading
    to a memory leak. This fix ensures proper cleanup by freeing the
    allocated memory for 'clk_data' before returning.
    
    Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
    Link: https://lore.kernel.org/r/20231210165040.3407545-1-visitorckw@gmail.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx: clk-imx8qxp: fix LVDS bypass, pixel and phy clocks [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Mon Dec 18 13:24:07 2023 +0100

    clk: imx: clk-imx8qxp: fix LVDS bypass, pixel and phy clocks
    
    [ Upstream commit 3f5f63adeea7e7aa715e101ffe4b4ac9705f9664 ]
    
    To be compatible with SCU firmware based on 1.15 a different clock
    routing for LVDS is needed.
    
    Signed-off-by: Oliver F. Brown <oliver.brown@oss.nxp.com>
    Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20231218122407.2757175-1-alexander.stein@ew.tq-group.com/
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx: scu: Fix memory leak in __imx_clk_gpr_scu() [+ + +]
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date:   Mon Dec 11 01:19:07 2023 +0800

    clk: imx: scu: Fix memory leak in __imx_clk_gpr_scu()
    
    [ Upstream commit 21c0efbcb45cf94724d17b040ebc03fcd4a81f22 ]
    
    In cases where imx_clk_is_resource_owned() returns false, the code path
    does not handle the failure gracefully, potentially leading to a memory
    leak. This fix ensures proper cleanup by freeing the allocated memory
    for 'clk_node' before returning.
    
    Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Link: https://lore.kernel.org/all/20231210171907.3410922-1-visitorckw@gmail.com/
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mmp: pxa168: Fix memory leak in pxa168_clk_init() [+ + +]
Author: Kuan-Wei Chiu <visitorckw@gmail.com>
Date:   Mon Dec 11 01:52:32 2023 +0800

    clk: mmp: pxa168: Fix memory leak in pxa168_clk_init()
    
    [ Upstream commit 2fbabea626b6467eb4e6c4cb7a16523da12e43b4 ]
    
    In cases where mapping of mpmu/apmu/apbc registers fails, the code path
    does not handle the failure gracefully, potentially leading to a memory
    leak. This fix ensures proper cleanup by freeing the allocated memory
    for 'pxa_unit' before returning.
    
    Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
    Link: https://lore.kernel.org/r/20231210175232.3414584-1-visitorckw@gmail.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clocksource: Skip watchdog check for large watchdog intervals [+ + +]
Author: Jiri Wiesner <jwiesner@suse.de>
Date:   Mon Jan 22 18:23:50 2024 +0100

    clocksource: Skip watchdog check for large watchdog intervals
    
    commit 644649553508b9bacf0fc7a5bdc4f9e0165576a5 upstream.
    
    There have been reports of the watchdog marking clocksources unstable on
    machines with 8 NUMA nodes:
    
      clocksource: timekeeping watchdog on CPU373:
      Marking clocksource 'tsc' as unstable because the skew is too large:
      clocksource:   'hpet' wd_nsec: 14523447520
      clocksource:   'tsc'  cs_nsec: 14524115132
    
    The measured clocksource skew - the absolute difference between cs_nsec
    and wd_nsec - was 668 microseconds:
    
      cs_nsec - wd_nsec = 14524115132 - 14523447520 = 667612
    
    The kernel used 200 microseconds for the uncertainty_margin of both the
    clocksource and watchdog, resulting in a threshold of 400 microseconds (the
    md variable). Both the cs_nsec and the wd_nsec value indicate that the
    readout interval was circa 14.5 seconds.  The observed behaviour is that
    watchdog checks failed for large readout intervals on 8 NUMA node
    machines. This indicates that the size of the skew was directly proportinal
    to the length of the readout interval on those machines. The measured
    clocksource skew, 668 microseconds, was evaluated against a threshold (the
    md variable) that is suited for readout intervals of roughly
    WATCHDOG_INTERVAL, i.e. HZ >> 1, which is 0.5 second.
    
    The intention of 2e27e793e280 ("clocksource: Reduce clocksource-skew
    threshold") was to tighten the threshold for evaluating skew and set the
    lower bound for the uncertainty_margin of clocksources to twice
    WATCHDOG_MAX_SKEW. Later in c37e85c135ce ("clocksource: Loosen clocksource
    watchdog constraints"), the WATCHDOG_MAX_SKEW constant was increased to
    125 microseconds to fit the limit of NTP, which is able to use a
    clocksource that suffers from up to 500 microseconds of skew per second.
    Both the TSC and the HPET use default uncertainty_margin. When the
    readout interval gets stretched the default uncertainty_margin is no
    longer a suitable lower bound for evaluating skew - it imposes a limit
    that is far stricter than the skew with which NTP can deal.
    
    The root causes of the skew being directly proportinal to the length of
    the readout interval are:
    
      * the inaccuracy of the shift/mult pairs of clocksources and the watchdog
      * the conversion to nanoseconds is imprecise for large readout intervals
    
    Prevent this by skipping the current watchdog check if the readout
    interval exceeds 2 * WATCHDOG_INTERVAL. Considering the maximum readout
    interval of 2 * WATCHDOG_INTERVAL, the current default uncertainty margin
    (of the TSC and HPET) corresponds to a limit on clocksource skew of 250
    ppm (microseconds of skew per second).  To keep the limit imposed by NTP
    (500 microseconds of skew per second) for all possible readout intervals,
    the margins would have to be scaled so that the threshold value is
    proportional to the length of the actual readout interval.
    
    As for why the readout interval may get stretched: Since the watchdog is
    executed in softirq context the expiration of the watchdog timer can get
    severely delayed on account of a ksoftirqd thread not getting to run in a
    timely manner. Surely, a system with such belated softirq execution is not
    working well and the scheduling issue should be looked into but the
    clocksource watchdog should be able to deal with it accordingly.
    
    Fixes: 2e27e793e280 ("clocksource: Reduce clocksource-skew threshold")
    Suggested-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Jiri Wiesner <jwiesner@suse.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Paul E. McKenney <paulmck@kernel.org>
    Reviewed-by: Feng Tang <feng.tang@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240122172350.GA740@incl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cpufreq: intel_pstate: Drop redundant intel_pstate_get_hwp_cap() call [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Dec 10 17:12:18 2021 +0100

    cpufreq: intel_pstate: Drop redundant intel_pstate_get_hwp_cap() call
    
    [ Upstream commit 458b03f81afbb27143c45d47c2d8f418b2ba2407 ]
    
    It is not necessary to call intel_pstate_get_hwp_cap() from
    intel_pstate_update_perf_limits(), because it gets called from
    intel_pstate_verify_cpu_policy() which is either invoked directly
    right before intel_pstate_update_perf_limits(), in
    intel_cpufreq_verify_policy() in the passive mode, or called
    from driver callbacks in a sequence that causes it to be followed
    by an immediate intel_pstate_update_perf_limits().
    
    Namely, in the active mode intel_cpufreq_verify_policy() is called
    by intel_pstate_verify_policy() which is the ->verify() callback
    routine of intel_pstate and gets called by the cpufreq core right
    before intel_pstate_set_policy(), which is the driver's ->setoplicy()
    callback routine, where intel_pstate_update_perf_limits() is called.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 192cdb1c907f ("cpufreq: intel_pstate: Refine computation of P-state for given frequency")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: intel_pstate: Refine computation of P-state for given frequency [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon Jan 22 15:18:11 2024 +0100

    cpufreq: intel_pstate: Refine computation of P-state for given frequency
    
    [ Upstream commit 192cdb1c907fd8df2d764c5bb17496e415e59391 ]
    
    On systems using HWP, if a given frequency is equal to the maximum turbo
    frequency or the maximum non-turbo frequency, the HWP performance level
    corresponding to it is already known and can be used directly without
    any computation.
    
    Accordingly, adjust the code to use the known HWP performance levels in
    the cases mentioned above.
    
    This also helps to avoid limiting CPU capacity artificially in some
    cases when the BIOS produces the HWP_CAP numbers using a different
    E-core-to-P-core performance scaling factor than expected by the kernel.
    
    Fixes: f5c8cf2a4992 ("cpufreq: intel_pstate: hybrid: Use known scaling factor for P-cores")
    Cc: 6.1+ <stable@vger.kernel.org> # 6.1+
    Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: api - Disallow identical driver names [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Dec 7 18:36:57 2023 +0800

    crypto: api - Disallow identical driver names
    
    commit 27016f75f5ed47e2d8e0ca75a8ff1f40bc1a5e27 upstream.
    
    Disallow registration of two algorithms with identical driver names.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Ovidiu Panait <ovidiu.panait@windriver.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked [+ + +]
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Thu Jan 25 17:12:53 2024 -0600

    crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked
    
    commit ccb88e9549e7cfd8bcd511c538f437e20026e983 upstream.
    
    The SEV platform device can be shutdown with a null psp_master,
    e.g., using DEBUG_TEST_DRIVER_REMOVE.  Found using KASAN:
    
    [  137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002)
    [  137.162647] ccp 0000:23:00.1: no command queues available
    [  137.170598] ccp 0000:23:00.1: sev enabled
    [  137.174645] ccp 0000:23:00.1: psp enabled
    [  137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI
    [  137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7]
    [  137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311
    [  137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180
    [  137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c
    [  137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216
    [  137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e
    [  137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0
    [  137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66
    [  137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28
    [  137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8
    [  137.182693] FS:  0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000
    [  137.182693] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0
    [  137.182693] Call Trace:
    [  137.182693]  <TASK>
    [  137.182693]  ? show_regs+0x6c/0x80
    [  137.182693]  ? __die_body+0x24/0x70
    [  137.182693]  ? die_addr+0x4b/0x80
    [  137.182693]  ? exc_general_protection+0x126/0x230
    [  137.182693]  ? asm_exc_general_protection+0x2b/0x30
    [  137.182693]  ? __sev_platform_shutdown_locked+0x51/0x180
    [  137.182693]  sev_firmware_shutdown.isra.0+0x1e/0x80
    [  137.182693]  sev_dev_destroy+0x49/0x100
    [  137.182693]  psp_dev_destroy+0x47/0xb0
    [  137.182693]  sp_destroy+0xbb/0x240
    [  137.182693]  sp_pci_remove+0x45/0x60
    [  137.182693]  pci_device_remove+0xaa/0x1d0
    [  137.182693]  device_remove+0xc7/0x170
    [  137.182693]  really_probe+0x374/0xbe0
    [  137.182693]  ? srso_return_thunk+0x5/0x5f
    [  137.182693]  __driver_probe_device+0x199/0x460
    [  137.182693]  driver_probe_device+0x4e/0xd0
    [  137.182693]  __driver_attach+0x191/0x3d0
    [  137.182693]  ? __pfx___driver_attach+0x10/0x10
    [  137.182693]  bus_for_each_dev+0x100/0x190
    [  137.182693]  ? __pfx_bus_for_each_dev+0x10/0x10
    [  137.182693]  ? __kasan_check_read+0x15/0x20
    [  137.182693]  ? srso_return_thunk+0x5/0x5f
    [  137.182693]  ? _raw_spin_unlock+0x27/0x50
    [  137.182693]  driver_attach+0x41/0x60
    [  137.182693]  bus_add_driver+0x2a8/0x580
    [  137.182693]  driver_register+0x141/0x480
    [  137.182693]  __pci_register_driver+0x1d6/0x2a0
    [  137.182693]  ? srso_return_thunk+0x5/0x5f
    [  137.182693]  ? esrt_sysfs_init+0x1cd/0x5d0
    [  137.182693]  ? __pfx_sp_mod_init+0x10/0x10
    [  137.182693]  sp_pci_init+0x22/0x30
    [  137.182693]  sp_mod_init+0x14/0x30
    [  137.182693]  ? __pfx_sp_mod_init+0x10/0x10
    [  137.182693]  do_one_initcall+0xd1/0x470
    [  137.182693]  ? __pfx_do_one_initcall+0x10/0x10
    [  137.182693]  ? parameq+0x80/0xf0
    [  137.182693]  ? srso_return_thunk+0x5/0x5f
    [  137.182693]  ? __kmalloc+0x3b0/0x4e0
    [  137.182693]  ? kernel_init_freeable+0x92d/0x1050
    [  137.182693]  ? kasan_populate_vmalloc_pte+0x171/0x190
    [  137.182693]  ? srso_return_thunk+0x5/0x5f
    [  137.182693]  kernel_init_freeable+0xa64/0x1050
    [  137.182693]  ? __pfx_kernel_init+0x10/0x10
    [  137.182693]  kernel_init+0x24/0x160
    [  137.182693]  ? __switch_to_asm+0x3e/0x70
    [  137.182693]  ret_from_fork+0x40/0x80
    [  137.182693]  ? __pfx_kernel_init+0x10/0x10
    [  137.182693]  ret_from_fork_asm+0x1b/0x30
    [  137.182693]  </TASK>
    [  137.182693] Modules linked in:
    [  137.538483] ---[ end trace 0000000000000000 ]---
    
    Fixes: 1b05ece0c931 ("crypto: ccp - During shutdown, check SEV data pointer before using")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
    Acked-by: John Allen <john.allen@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init [+ + +]
Author: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Date:   Thu Dec 14 11:08:34 2023 +0800

    crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
    
    [ Upstream commit ba3c5574203034781ac4231acf117da917efcd2a ]
    
    When the mpi_ec_ctx structure is initialized, some fields are not
    cleared, causing a crash when referencing the field when the
    structure was released. Initially, this issue was ignored because
    memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
    For example, this error will be triggered when calculating the
    Za value for SM2 separately.
    
    Fixes: d58bb7e55a8a ("lib/mpi: Introduce ec implementation to MPI library")
    Cc: stable@vger.kernel.org # v6.5
    Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: octeontx2 - Fix cptvf driver cleanup [+ + +]
Author: Bharat Bhushan <bbhushan2@marvell.com>
Date:   Mon Dec 11 15:59:11 2023 +0530

    crypto: octeontx2 - Fix cptvf driver cleanup
    
    [ Upstream commit c480a421a4faf693c38e60b0fe6e554c9a3fee02 ]
    
    This patch fixes following cleanup issues:
     - Missing instruction queue free on cleanup. This
       will lead to memory leak.
     - lfs->lfs_num is set to zero before cleanup, which
       will lead to improper cleanup.
    
    Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: s390/aes - Fix buffer overread in CTR mode [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Nov 28 14:22:13 2023 +0800

    crypto: s390/aes - Fix buffer overread in CTR mode
    
    commit d07f951903fa9922c375b8ab1ce81b18a0034e3b upstream.
    
    When processing the last block, the s390 ctr code will always read
    a whole block, even if there isn't a whole block of data left.  Fix
    this by using the actual length left and copy it into a buffer first
    for processing.
    
    Fixes: 0200f3ecc196 ("crypto: s390 - add System z hardware support for CTR mode")
    Cc: <stable@vger.kernel.org>
    Reported-by: Guangwu Zhang <guazhang@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Reviewd-by: Harald Freudenberger <freude@de.ibm.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: stm32/crc32 - fix parsing list of devices [+ + +]
Author: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
Date:   Fri Dec 15 12:17:24 2023 +0100

    crypto: stm32/crc32 - fix parsing list of devices
    
    [ Upstream commit 0eaef675b94c746900dcea7f6c41b9a103ed5d53 ]
    
    smatch warnings:
    drivers/crypto/stm32/stm32-crc32.c:108 stm32_crc_get_next_crc() warn:
    can 'crc' even be NULL?
    
    Use list_first_entry_or_null instead of list_first_entry to retrieve
    the first device registered.
    The function list_first_entry always return a non NULL pointer even if
    the list is empty. Hence checking if the pointer returned is NULL does
    not tell if the list is empty or not.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp@intel.com/
    Reported-by: Dan Carpenter <error27@gmail.com>
    Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp@intel.com/
    Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
debugobjects: Stop accessing objects after releasing hash bucket lock [+ + +]
Author: Andrzej Hajda <andrzej.hajda@intel.com>
Date:   Wed Oct 25 23:39:07 2023 +0200

    debugobjects: Stop accessing objects after releasing hash bucket lock
    
    [ Upstream commit 9bb6362652f3f4d74a87d572a91ee1b38e673ef6 ]
    
    After release of the hashbucket lock the tracking object can be modified or
    freed by a concurrent thread.  Using it in such a case is error prone, even
    for printing the object state:
    
        1. T1 tries to deactivate destroyed object, debugobjects detects it,
           hash bucket lock is released.
    
        2. T2 preempts T1 and frees the tracking object.
    
        3. The freed tracking object is allocated and initialized for a
           different to be tracked kernel object.
    
        4. T1 resumes and reports error for wrong kernel object.
    
    Create a local copy of the tracking object before releasing the hash bucket
    lock and use the local copy for reporting and fixups to prevent this.
    
    Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20231025-debugobjects_fix-v3-1-2bc3bf7084c2@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm: limit the number of targets and parameter size area [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Jan 9 15:57:56 2024 +0100

    dm: limit the number of targets and parameter size area
    
    commit bd504bcfec41a503b32054da5472904b404341a4 upstream.
    
    The kvmalloc function fails with a warning if the size is larger than
    INT_MAX. The warning was triggered by a syscall testing robot.
    
    In order to avoid the warning, this commit limits the number of targets to
    1048576 and the size of the parameter area to 1073741824.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: He Gao <hegao@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dma-buf: add dma_fence_timestamp helper [+ + +]
Author: Christian König <christian.koenig@amd.com>
Date:   Fri Sep 8 10:27:23 2023 +0200

    dma-buf: add dma_fence_timestamp helper
    
    [ Upstream commit b83ce9cb4a465b8f9a3fa45561b721a9551f60e3 ]
    
    When a fence signals there is a very small race window where the timestamp
    isn't updated yet. sync_file solves this by busy waiting for the
    timestamp to appear, but on other ocassions didn't handled this
    correctly.
    
    Provide a dma_fence_timestamp() helper function for this and use it in
    all appropriate cases.
    
    Another alternative would be to grab the spinlock when that happens.
    
    v2 by teddy: add a wait parameter to wait for the timestamp to show up, in case
       the accurate timestamp is needed and/or the timestamp is not based on
       ktime (e.g. hw timestamp)
    v3 chk: drop the parameter again for unified handling
    
    Signed-off-by: Yunxiang Li <Yunxiang.Li@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Fixes: 1774baa64f93 ("drm/scheduler: Change scheduled fence track v2")
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    CC: stable@vger.kernel.org
    Link: https://patchwork.freedesktop.org/patch/msgid/20230929104725.2358-1-christian.koenig@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: fix is_slave_direction() return false when DMA_DEV_TO_DEV [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Tue Jan 23 12:28:41 2024 -0500

    dmaengine: fix is_slave_direction() return false when DMA_DEV_TO_DEV
    
    [ Upstream commit a22fe1d6dec7e98535b97249fdc95c2be79120bb ]
    
    is_slave_direction() should return true when direction is DMA_DEV_TO_DEV.
    
    Fixes: 49920bc66984 ("dmaengine: add new enum dma_transfer_direction")
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20240123172842.3764529-1-Frank.Li@nxp.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: fix NULL pointer in channel unregistration function [+ + +]
Author: Amelie Delaunay <amelie.delaunay@foss.st.com>
Date:   Wed Dec 13 17:04:52 2023 +0100

    dmaengine: fix NULL pointer in channel unregistration function
    
    [ Upstream commit f5c24d94512f1b288262beda4d3dcb9629222fc7 ]
    
    __dma_async_device_channel_register() can fail. In case of failure,
    chan->local is freed (with free_percpu()), and chan->local is nullified.
    When dma_async_device_unregister() is called (because of managed API or
    intentionally by DMA controller driver), channels are unconditionally
    unregistered, leading to this NULL pointer:
    [    1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
    [...]
    [    1.484499] Call trace:
    [    1.486930]  device_del+0x40/0x394
    [    1.490314]  device_unregister+0x20/0x7c
    [    1.494220]  __dma_async_device_channel_unregister+0x68/0xc0
    
    Look at dma_async_device_register() function error path, channel device
    unregistration is done only if chan->local is not NULL.
    
    Then add the same condition at the beginning of
    __dma_async_device_channel_unregister() function, to avoid NULL pointer
    issue whatever the API used to reach this function.
    
    Fixes: d2fb0a043838 ("dmaengine: break out channel registration")
    Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20231213160452.2598073-1-amelie.delaunay@foss.st.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: fsl-dpaa2-qdma: Fix the size of dma pools [+ + +]
Author: Guanhua Gao <guanhua.gao@nxp.com>
Date:   Thu Jan 18 11:29:16 2024 -0500

    dmaengine: fsl-dpaa2-qdma: Fix the size of dma pools
    
    [ Upstream commit b73e43dcd7a8be26880ef8ff336053b29e79dbc5 ]
    
    In case of long format of qDMA command descriptor, there are one frame
    descriptor, three entries in the frame list and two data entries. So the
    size of dma_pool_create for these three fields should be the same with
    the total size of entries respectively, or the contents may be overwritten
    by the next allocated descriptor.
    
    Fixes: 7fdf9b05c73b ("dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA controller driver for Layerscape SoCs")
    Signed-off-by: Guanhua Gao <guanhua.gao@nxp.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20240118162917.2951450-1-Frank.Li@nxp.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jan 7 11:02:04 2024 +0100

    dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA
    
    [ Upstream commit 3aa58cb51318e329d203857f7a191678e60bb714 ]
    
    This dma_alloc_coherent() is undone neither in the remove function, nor in
    the error handling path of fsl_qdma_probe().
    
    Switch to the managed version to fix both issues.
    
    Fixes: b092529e0aa0 ("dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/7f66aa14f59d32b13672dde28602b47deb294e1f.1704621515.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: fsl-qdma: Fix a memory leak related to the status queue DMA [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Jan 7 11:02:03 2024 +0100

    dmaengine: fsl-qdma: Fix a memory leak related to the status queue DMA
    
    [ Upstream commit 968bc1d7203d384e72afe34124a1801b7af76514 ]
    
    This dma_alloc_coherent() is undone in the remove function, but not in the
    error handling path of fsl_qdma_probe().
    
    Switch to the managed version to fix the issue in the probe and simplify
    the remove function.
    
    Fixes: b092529e0aa0 ("dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/a0ef5d0f5a47381617ef339df776ddc68ce48173.1704621515.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ti: k3-udma: Report short packet errors [+ + +]
Author: Jai Luthra <j-luthra@ti.com>
Date:   Wed Jan 3 14:37:55 2024 +0530

    dmaengine: ti: k3-udma: Report short packet errors
    
    [ Upstream commit bc9847c9ba134cfe3398011e343dcf6588c1c902 ]
    
    Propagate the TR response status to the device using BCDMA
    split-channels. For example CSI-RX driver should be able to check if a
    frame was not transferred completely (short packet) and needs to be
    discarded.
    
    Fixes: 25dcb5dd7b7c ("dmaengine: ti: New driver for K3 UDMA")
    Signed-off-by: Jai Luthra <j-luthra@ti.com>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Link: https://lore.kernel.org/r/20240103-tr_resp_err-v1-1-2fdf6d48ab92@ti.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/perf: pmuv3: don't expose SW_INCR event in sysfs [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Mon Dec 4 11:58:47 2023 +0000

    drivers/perf: pmuv3: don't expose SW_INCR event in sysfs
    
    [ Upstream commit ca6f537e459e2da4b331fe8928d1a0b0f9301f42 ]
    
    The SW_INCR event is somewhat unusual, and depends on the specific HW
    counter that it is programmed into. When programmed into PMEVCNTR<n>,
    SW_INCR will count any writes to PMSWINC_EL0 with bit n set, ignoring
    writes to SW_INCR with bit n clear.
    
    Event rotation means that there's no fixed relationship between
    perf_events and HW counters, so this isn't all that useful.
    
    Further, we program PMUSERENR.{SW,EN}=={0,0}, which causes EL0 writes to
    PMSWINC_EL0 to be trapped and handled as UNDEFINED, resulting in a
    SIGILL to userspace.
    
    Given that, it's not a good idea to expose SW_INCR in sysfs. Hide it as
    we did for CHAIN back in commit:
    
      4ba2578fa7b55701 ("arm64: perf: don't expose CHAIN event in sysfs")
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20231204115847.2993026-1-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers: lkdtm: fix clang -Wformat warning [+ + +]
Author: Justin Stitt <justinstitt@google.com>
Date:   Thu Jul 21 14:57:06 2022 -0700

    drivers: lkdtm: fix clang -Wformat warning
    
    [ Upstream commit b4909252da9be56fe1e0a23c2c1908c5630525fa ]
    
    When building with Clang we encounter the following warning
    (ARCH=hexagon + CONFIG_FRAME_WARN=0):
    | ../drivers/misc/lkdtm/bugs.c:107:3: error: format specifies type
    | 'unsigned long' but the argument has type 'int' [-Werror,-Wformat]
    |                 REC_STACK_SIZE, recur_count);
    |                 ^~~~~~~~~~~~~~
    
    Cast REC_STACK_SIZE to `unsigned long` to match format specifier `%lu`
    as well as maintain symmetry with `#define REC_STACK_SIZE
    (_AC(CONFIG_FRAME_WARN, UL) / 2)`.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/378
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Suggested-by: Nathan Chancellor <nathan@kernel.org>
    Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Justin Stitt <justinstitt@google.com>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Acked-by: Kees Cook <keescook@chromium.org>
    Fixes: 24cccab42c419 ("lkdtm/bugs: Adjust recursion test to avoid elision")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20220721215706.4153027-1-justinstitt@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Fix multiple memory leaks reported by coverity [+ + +]
Author: Anson Jacob <Anson.Jacob@amd.com>
Date:   Mon Aug 23 13:41:13 2021 -0400

    drm/amd/display: Fix multiple memory leaks reported by coverity
    
    [ Upstream commit 7b89bf83181363a84f86da787159ddbbef505b8c ]
    
    coccinelle patch used:
    
    @@ expression enc1,vpg,afmt; @@
    -       if (!enc1 || !vpg || !afmt)
    +       if (!enc1 || !vpg || !afmt) {
    +               kfree(enc1);
    +               kfree(vpg);
    +               kfree(afmt);
                    return NULL;
    +       }
    
    Addresses-Coverity-ID: 1466017: ("Resource leaks")
    
    Reviewed-by: Aurabindo Jayamohanan Pillai <Aurabindo.Pillai@amd.com>
    Acked-by: Mikita Lipski <mikita.lipski@amd.com>
    Signed-off-by: Anson Jacob <Anson.Jacob@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 58fca355ad37 ("drm/amd/display: Implement bounds check for stream encoder creation in DCN301")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix tiled display misalignment [+ + +]
Author: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
Date:   Thu Nov 9 00:04:36 2023 -0500

    drm/amd/display: Fix tiled display misalignment
    
    [ Upstream commit c4b8394e76adba4f50a3c2696c75b214a291e24a ]
    
    [Why]
    When otg workaround is applied during clock update, otgs of
    tiled display went out of sync.
    
    [How]
    To call dc_trigger_sync() after clock update to sync otgs again.
    
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Implement bounds check for stream encoder creation in DCN301 [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Wed Feb 7 10:20:57 2024 +0530

    drm/amd/display: Implement bounds check for stream encoder creation in DCN301
    
    [ Upstream commit 58fca355ad37dcb5f785d9095db5f748b79c5dc2 ]
    
    'stream_enc_regs' array is an array of dcn10_stream_enc_registers
    structures. The array is initialized with four elements, corresponding
    to the four calls to stream_enc_regs() in the array initializer. This
    means that valid indices for this array are 0, 1, 2, and 3.
    
    The error message 'stream_enc_regs' 4 <= 5 below, is indicating that
    there is an attempt to access this array with an index of 5, which is
    out of bounds. This could lead to undefined behavior
    
    Here, eng_id is used as an index to access the stream_enc_regs array. If
    eng_id is 5, this would result in an out-of-bounds access on the
    stream_enc_regs array.
    
    Thus fixing Buffer overflow error in dcn301_stream_encoder_create
    reported by Smatch:
    drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5
    
    Fixes: 3a83e4e64bb1 ("drm/amd/display: Add dcn3.01 support to DC (v2)")
    Cc: Roman Li <Roman.Li@amd.com>
    Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Roman Li <roman.li@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/powerplay: Fix kzalloc parameter 'ATOM_Tonga_PPM_Table' in 'get_platform_power_management_table()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Fri Jan 5 12:05:09 2024 +0530

    drm/amd/powerplay: Fix kzalloc parameter 'ATOM_Tonga_PPM_Table' in 'get_platform_power_management_table()'
    
    [ Upstream commit 6616b5e1999146b1304abe78232af810080c67e3 ]
    
    In 'struct phm_ppm_table *ptr' allocation using kzalloc, an incorrect
    structure type is passed to sizeof() in kzalloc, larger structure types
    were used, thus using correct type 'struct phm_ppm_table' fixes the
    below:
    
    drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:203 get_platform_power_management_table() warn: struct type mismatch 'phm_ppm_table vs _ATOM_Tonga_PPM_Table'
    
    Cc: Eric Huang <JinHuiEric.Huang@amd.com>
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@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>

 
drm/amdgpu: Drop 'fence' check in 'to_amdgpu_amdkfd_fence()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Wed Dec 27 12:54:44 2023 +0530

    drm/amdgpu: Drop 'fence' check in 'to_amdgpu_amdkfd_fence()'
    
    [ Upstream commit bf2ad4fb8adca89374b54b225d494e0b1956dbea ]
    
    Return value of container_of(...) can't be null, so null check is not
    required for 'fence'. Hence drop its NULL check.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c:93 to_amdgpu_amdkfd_fence() warn: can 'fence' even be NULL?
    
    Cc: Felix Kuehling <Felix.Kuehling@amd.com>
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap [+ + +]
Author: Wang, Beyond <Wang.Beyond@amd.com>
Date:   Tue Dec 12 21:03:04 2023 +0800

    drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap
    
    [ Upstream commit 94aeb4117343d072e3a35b9595bcbfc0058ee724 ]
    
    Issue: during evict or validate happened on amdgpu_bo, the 'from' and
    'to' is always same in ftrace event of amdgpu_bo_move
    
    where calling the 'trace_amdgpu_bo_move', the comment says move_notify
    is called before move happens, but actually it is called after move
    happens, here the new_mem is same as bo->resource
    
    Fix: move trace_amdgpu_bo_move from move_notify to amdgpu_bo_move
    
    Signed-off-by: Wang, Beyond <Wang.Beyond@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Let KFD sync with VM fences [+ + +]
Author: Felix Kuehling <Felix.Kuehling@amd.com>
Date:   Mon Dec 18 16:17:23 2023 -0500

    drm/amdgpu: Let KFD sync with VM fences
    
    [ Upstream commit ec9ba4821fa52b5efdbc4cdf0a77497990655231 ]
    
    Change the rules for amdgpu_sync_resv to let KFD synchronize with VM
    fences on page table reservations. This fixes intermittent memory
    corruption after evictions when using amdgpu_vm_handle_moved to update
    page tables for VM mappings managed through render nodes.
    
    Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Release 'adev->pm.fw' before return in 'amdgpu_device_need_post()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Thu Dec 21 18:13:11 2023 +0530

    drm/amdgpu: Release 'adev->pm.fw' before return in 'amdgpu_device_need_post()'
    
    [ Upstream commit 8a44fdd3cf91debbd09b43bd2519ad2b2486ccf4 ]
    
    In function 'amdgpu_device_need_post(struct amdgpu_device *adev)' -
    'adev->pm.fw' may not be released before return.
    
    Using the function release_firmware() to release adev->pm.fw.
    
    Thus fixing the below:
    drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1571 amdgpu_device_need_post() warn: 'adev->pm.fw' from request_firmware() not released on lines: 1554.
    
    Cc: Monk Liu <Monk.Liu@amd.com>
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Suggested-by: Lijo Lazar <lijo.lazar@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>

 
drm/amdkfd: Fix 'node' NULL check in 'svm_range_get_range_boundaries()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Tue Jan 9 16:57:26 2024 +0530

    drm/amdkfd: Fix 'node' NULL check in 'svm_range_get_range_boundaries()'
    
    [ Upstream commit d7a254fad873775ce6c32b77796c81e81e6b7f2e ]
    
    Range interval [start, last] is ordered by rb_tree, rb_prev, rb_next
    return value still needs NULL check, thus modified from "node" to "rb_node".
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:2691 svm_range_get_range_boundaries() warn: can 'node' even be NULL?
    
    Suggested-by: Philip Yang <Philip.Yang@amd.com>
    Cc: Felix Kuehling <Felix.Kuehling@amd.com>
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdkfd: Fix lock dependency warning [+ + +]
Author: Felix Kuehling <felix.kuehling@amd.com>
Date:   Tue Jan 2 15:07:44 2024 -0500

    drm/amdkfd: Fix lock dependency warning
    
    [ Upstream commit 47bf0f83fc86df1bf42b385a91aadb910137c5c9 ]
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.5.0-kfd-fkuehlin #276 Not tainted
    ------------------------------------------------------
    kworker/8:2/2676 is trying to acquire lock:
    ffff9435aae95c88 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}, at: __flush_work+0x52/0x550
    
    but task is already holding lock:
    ffff9435cd8e1720 (&svms->lock){+.+.}-{3:3}, at: svm_range_deferred_list_work+0xe8/0x340 [amdgpu]
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #2 (&svms->lock){+.+.}-{3:3}:
           __mutex_lock+0x97/0xd30
           kfd_ioctl_alloc_memory_of_gpu+0x6d/0x3c0 [amdgpu]
           kfd_ioctl+0x1b2/0x5d0 [amdgpu]
           __x64_sys_ioctl+0x86/0xc0
           do_syscall_64+0x39/0x80
           entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    -> #1 (&mm->mmap_lock){++++}-{3:3}:
           down_read+0x42/0x160
           svm_range_evict_svm_bo_worker+0x8b/0x340 [amdgpu]
           process_one_work+0x27a/0x540
           worker_thread+0x53/0x3e0
           kthread+0xeb/0x120
           ret_from_fork+0x31/0x50
           ret_from_fork_asm+0x11/0x20
    
    -> #0 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}:
           __lock_acquire+0x1426/0x2200
           lock_acquire+0xc1/0x2b0
           __flush_work+0x80/0x550
           __cancel_work_timer+0x109/0x190
           svm_range_bo_release+0xdc/0x1c0 [amdgpu]
           svm_range_free+0x175/0x180 [amdgpu]
           svm_range_deferred_list_work+0x15d/0x340 [amdgpu]
           process_one_work+0x27a/0x540
           worker_thread+0x53/0x3e0
           kthread+0xeb/0x120
           ret_from_fork+0x31/0x50
           ret_from_fork_asm+0x11/0x20
    
    other info that might help us debug this:
    
    Chain exists of:
      (work_completion)(&svm_bo->eviction_work) --> &mm->mmap_lock --> &svms->lock
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&svms->lock);
                                   lock(&mm->mmap_lock);
                                   lock(&svms->lock);
      lock((work_completion)(&svm_bo->eviction_work));
    
    I believe this cannot really lead to a deadlock in practice, because
    svm_range_evict_svm_bo_worker only takes the mmap_read_lock if the BO
    refcount is non-0. That means it's impossible that svm_range_bo_release
    is running concurrently. However, there is no good way to annotate this.
    
    To avoid the problem, take a BO reference in
    svm_range_schedule_evict_svm_bo instead of in the worker. That way it's
    impossible for a BO to get freed while eviction work is pending and the
    cancel_work_sync call in svm_range_bo_release can be eliminated.
    
    v2: Use svm_bo_ref_unless_zero and explained why that's safe. Also
    removed redundant checks that are already done in
    amdkfd_fence_enable_signaling.
    
    Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
    Reviewed-by: Philip Yang <philip.yang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/bridge: nxp-ptn3460: fix i2c_master_send() error checking [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Mon Dec 4 15:29:00 2023 +0300

    drm/bridge: nxp-ptn3460: fix i2c_master_send() error checking
    
    commit 914437992876838662c968cb416f832110fb1093 upstream.
    
    The i2c_master_send/recv() functions return negative error codes or the
    number of bytes that were able to be sent/received.  This code has
    two problems.  1)  Instead of checking if all the bytes were sent or
    received, it checks that at least one byte was sent or received.
    2) If there was a partial send/receive then we should return a negative
    error code but this code returns success.
    
    Fixes: a9fe713d7d45 ("drm/bridge: Add PTN3460 bridge driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/0cdc2dce-ca89-451a-9774-1482ab2f4762@moroto.mountain
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/bridge: nxp-ptn3460: simplify some error checking [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Dec 6 18:05:15 2023 +0300

    drm/bridge: nxp-ptn3460: simplify some error checking
    
    commit 28d3d0696688154cc04983f343011d07bf0508e4 upstream.
    
    The i2c_master_send/recv() functions return negative error codes or
    they return "len" on success.  So the error handling here can be written
    as just normal checks for "if (ret < 0) return ret;".  No need to
    complicate things.
    
    Btw, in this code the "len" parameter can never be zero, but even if
    it were, then I feel like this would still be the best way to write it.
    
    Fixes: 914437992876 ("drm/bridge: nxp-ptn3460: fix i2c_master_send() error checking")
    Suggested-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/04242630-42d8-4920-8c67-24ac9db6b3c9@moroto.mountain
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/drm_file: fix use of uninitialized variable [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Fri Nov 3 15:14:03 2023 +0200

    drm/drm_file: fix use of uninitialized variable
    
    [ Upstream commit 1d3062fad9c7313fff9970a88e0538a24480ffb8 ]
    
    smatch reports:
    
    drivers/gpu/drm/drm_file.c:967 drm_show_memory_stats() error: uninitialized symbol 'supported_status'.
    
    'supported_status' is only set in one code path. I'm not familiar with
    the code to say if that path will always be ran in real life, but
    whether that is the case or not, I think it is good to initialize
    'supported_status' to 0 to silence the warning (and possibly fix a bug).
    
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Acked-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231103-uninit-fixes-v2-1-c22b2444f5f5@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind time [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Sep 21 12:26:52 2023 -0700

    drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind time
    
    [ Upstream commit 16ac5b21b31b439f03cdf44c153c5f5af94fb3eb ]
    
    Based on grepping through the source code this driver appears to be
    missing a call to drm_atomic_helper_shutdown() at system shutdown time
    and at driver unbind time. Among other things, this means that if a
    panel is in use that it won't be cleanly powered off at system
    shutdown time.
    
    The fact that we should call drm_atomic_helper_shutdown() in the case
    of OS shutdown/restart and at driver remove (or unbind) time comes
    straight out of the kernel doc "driver instance overview" in
    drm_drv.c.
    
    A few notes about this fix:
    - When adding drm_atomic_helper_shutdown() to the unbind path, I added
      it after drm_kms_helper_poll_fini() since that's when other drivers
      seemed to have it.
    - Technically with a previous patch, ("drm/atomic-helper:
      drm_atomic_helper_shutdown(NULL) should be a noop"), we don't
      actually need to check to see if our "drm" pointer is NULL before
      calling drm_atomic_helper_shutdown(). We'll leave the "if" test in,
      though, so that this patch can land without any dependencies. It
      could potentially be removed later.
    - This patch also makes sure to set the drvdata to NULL in the case of
      bind errors to make sure that shutdown can't access freed data.
    
    Suggested-by: Maxime Ripard <mripard@kernel.org>
    Reviewed-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/exynos: fix accidental on-stack copy of exynos_drm_plane [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Dec 14 13:32:15 2023 +0100

    drm/exynos: fix accidental on-stack copy of exynos_drm_plane
    
    [ Upstream commit 960b537e91725bcb17dd1b19e48950e62d134078 ]
    
    gcc rightfully complains about excessive stack usage in the fimd_win_set_pixfmt()
    function:
    
    drivers/gpu/drm/exynos/exynos_drm_fimd.c: In function 'fimd_win_set_pixfmt':
    drivers/gpu/drm/exynos/exynos_drm_fimd.c:750:1: error: the frame size of 1032 bytes is larger than 1024 byte
    drivers/gpu/drm/exynos/exynos5433_drm_decon.c: In function 'decon_win_set_pixfmt':
    drivers/gpu/drm/exynos/exynos5433_drm_decon.c:381:1: error: the frame size of 1032 bytes is larger than 1024 bytes
    
    There is really no reason to copy the large exynos_drm_plane
    structure to the stack before using one of its members, so just
    use a pointer instead.
    
    Fixes: 6f8ee5c21722 ("drm/exynos: fimd: Make plane alpha configurable")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/exynos: gsc: minor fix for loop iteration in gsc_runtime_resume [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Wed Dec 20 12:53:15 2023 +0300

    drm/exynos: gsc: minor fix for loop iteration in gsc_runtime_resume
    
    [ Upstream commit 4050957c7c2c14aa795dbf423b4180d5ac04e113 ]
    
    Do not forget to call clk_disable_unprepare() on the first element of
    ctx->clocks array.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: 8b7d3ec83aba ("drm/exynos: gsc: Convert driver to IPP v2 core API")
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/framebuffer: Fix use of uninitialized variable [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Fri Nov 3 15:14:04 2023 +0200

    drm/framebuffer: Fix use of uninitialized variable
    
    [ Upstream commit f9af8f0c1dc567a5a6a6318ff324c45d80d4a60f ]
    
    smatch reports:
    
    drivers/gpu/drm/drm_framebuffer.c:654 drm_mode_getfb2_ioctl() error: uninitialized symbol 'ret'.
    
    'ret' is possibly not set when there are no errors, causing the error
    above. I can't say if that ever happens in real-life, but in any case I
    think it is good to initialize 'ret' to 0.
    
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Acked-by: Maxime Ripard <mripard@kernel.org>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231103-uninit-fixes-v2-2-c22b2444f5f5@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/mipi-dsi: Fix detach call without attach [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Thu Sep 21 13:50:32 2023 +0300

    drm/mipi-dsi: Fix detach call without attach
    
    [ Upstream commit 90d50b8d85834e73536fdccd5aa913b30494fef0 ]
    
    It's been reported that DSI host driver's detach can be called without
    the attach ever happening:
    
    https://lore.kernel.org/all/20230412073954.20601-1-tony@atomide.com/
    
    After reading the code, I think this is what happens:
    
    We have a DSI host defined in the device tree and a DSI peripheral under
    that host (i.e. an i2c device using the DSI as data bus doesn't exhibit
    this behavior).
    
    The host driver calls mipi_dsi_host_register(), which causes (via a few
    functions) mipi_dsi_device_add() to be called for the DSI peripheral. So
    now we have a DSI device under the host, but attach hasn't been called.
    
    Normally the probing of the devices continues, and eventually the DSI
    peripheral's driver will call mipi_dsi_attach(), attaching the
    peripheral.
    
    However, if the host driver's probe encounters an error after calling
    mipi_dsi_host_register(), and before the peripheral has called
    mipi_dsi_attach(), the host driver will do cleanups and return an error
    from its probe function. The cleanups include calling
    mipi_dsi_host_unregister().
    
    mipi_dsi_host_unregister() will call two functions for all its DSI
    peripheral devices: mipi_dsi_detach() and mipi_dsi_device_unregister().
    The latter makes sense, as the device exists, but the former may be
    wrong as attach has not necessarily been done.
    
    To fix this, track the attached state of the peripheral, and only detach
    from mipi_dsi_host_unregister() if the peripheral was attached.
    
    Note that I have only tested this with a board with an i2c DSI
    peripheral, not with a "pure" DSI peripheral.
    
    However, slightly related, the unregister machinery still seems broken.
    E.g. if the DSI host driver is unbound, it'll detach and unregister the
    DSI peripherals. After that, when the DSI peripheral driver unbound
    it'll call detach either directly or using the devm variant, leading to
    a crash. And probably the driver will crash if it happens, for some
    reason, to try to send a message via the DSI bus.
    
    But that's another topic.
    
    Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
    Acked-by: Maxime Ripard <mripard@kernel.org>
    Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Tested-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230921-dsi-detach-fix-v1-1-d0de2d1621d9@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dp: return correct Colorimetry for DP_TEST_DYNAMIC_RANGE_CEA case [+ + +]
Author: Kuogee Hsieh <quic_khsieh@quicinc.com>
Date:   Wed Jan 17 13:13:30 2024 -0800

    drm/msm/dp: return correct Colorimetry for DP_TEST_DYNAMIC_RANGE_CEA case
    
    [ Upstream commit fcccdafd91f8bdde568b86ff70848cf83f029add ]
    
    MSA MISC0 bit 1 to 7 contains Colorimetry Indicator Field.
    dp_link_get_colorimetry_config() returns wrong colorimetry value
    in the DP_TEST_DYNAMIC_RANGE_CEA case in the current implementation.
    Hence fix this problem by having dp_link_get_colorimetry_config()
    return defined CEA RGB colorimetry value in the case of
    DP_TEST_DYNAMIC_RANGE_CEA.
    
    Changes in V2:
    -- drop retrieving colorimetry from colorspace
    -- drop dr = link->dp_link.test_video.test_dyn_range assignment
    
    Changes in V3:
    -- move defined MISCr0a Colorimetry vale to dp_reg.h
    -- rewording commit title
    -- rewording commit text to more precise describe this patch
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/574888/
    Link: https://lore.kernel.org/r/1705526010-597-1-git-send-email-quic_khsieh@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dpu: Ratelimit framedone timeout msgs [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Mon Dec 11 10:19:55 2023 -0800

    drm/msm/dpu: Ratelimit framedone timeout msgs
    
    [ Upstream commit 2b72e50c62de60ad2d6bcd86aa38d4ccbdd633f2 ]
    
    When we start getting these, we get a *lot*.  So ratelimit it to not
    flood dmesg.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Patchwork: https://patchwork.freedesktop.org/patch/571584/
    Link: https://lore.kernel.org/r/20231211182000.218088-1-robdclark@gmail.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dsi: Enable runtime PM [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Jan 30 18:28:47 2024 +0530

    drm/msm/dsi: Enable runtime PM
    
    [ Upstream commit 6ab502bc1cf3147ea1d8540d04b83a7a4cb6d1f1 ]
    
    Some devices power the DSI PHY/PLL through a power rail that we model
    as a GENPD. Enable runtime PM to make it suspendable.
    
    Change-Id: I70b04b7fbf75ccf508ab2dcbe393dbb2be6e4eaa
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/543352/
    Link: https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v2-2-a11a751f34f0@linaro.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Stable-dep-of: 3d07a411b4fa ("drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks")
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/prime: Support page array >= 4GB [+ + +]
Author: Philip Yang <Philip.Yang@amd.com>
Date:   Mon Aug 21 16:02:01 2023 -0400

    drm/prime: Support page array >= 4GB
    
    commit b671cd3d456315f63171a670769356a196cf7fd0 upstream.
    
    Without unsigned long typecast, the size is passed in as zero if page
    array size >= 4GB, nr_pages >= 0x100000, then sg list converted will
    have the first and the last chunk lost.
    
    Signed-off-by: Philip Yang <Philip.Yang@amd.com>
    Acked-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230821200201.24685-1-Philip.Yang@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/tidss: Fix atomic_flush check [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Thu Nov 9 09:38:03 2023 +0200

    drm/tidss: Fix atomic_flush check
    
    commit 95d4b471953411854f9c80b568da7fcf753f3801 upstream.
    
    tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not,
    returns immediately as there's no reason to do any register changes.
    
    However, the code checks for 'crtc->state->enable', which does not
    reflect the actual HW state. We should instead look at the
    'crtc->state->active' flag.
    
    This causes the tidss_crtc_atomic_flush() to proceed with the flush even
    if the active state is false, which then causes us to hit the
    WARN_ON(!crtc->state->event) check.
    
    Fix this by checking the active flag, and while at it, fix the related
    debug print which had "active" and "needs modeset" wrong way.
    
    Cc:  <stable@vger.kernel.org>
    Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")
    Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com>
    Link: https://lore.kernel.org/r/20231109-tidss-probe-v2-10-ac91b5ea35c0@ideasonboard.com
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm: Don't unref the same fb many times by mistake due to deadlock handling [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Dec 11 10:16:24 2023 +0200

    drm: Don't unref the same fb many times by mistake due to deadlock handling
    
    commit cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c upstream.
    
    If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
    we proceed to unref the fb and then retry the whole thing from the top.
    But we forget to reset the fb pointer back to NULL, and so if we then
    get another error during the retry, before the fb lookup, we proceed
    the unref the same fb again without having gotten another reference.
    The end result is that the fb will (eventually) end up being freed
    while it's still in use.
    
    Reset fb to NULL once we've unreffed it to avoid doing it again
    until we've done another fb lookup.
    
    This turned out to be pretty easy to hit on a DG2 when doing async
    flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
    saw that drm_closefb() simply got stuck in a busy loop while walking
    the framebuffer list. Fortunately I was able to convince it to oops
    instead, and from there it was easier to track down the culprit.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231211081625.25704-1-ville.syrjala@linux.intel.com
    Acked-by: Javier Martinez Canillas <javierm@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm: panel-simple: add missing bus flags for Tianma tm070jvhg[30/33] [+ + +]
Author: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Date:   Thu Oct 12 10:42:08 2023 +0200

    drm: panel-simple: add missing bus flags for Tianma tm070jvhg[30/33]
    
    [ Upstream commit 45dd7df26cee741b31c25ffdd44fb8794eb45ccd ]
    
    The DE signal is active high on this display, fill in the missing
    bus_flags. This aligns panel_desc with its display_timing.
    
    Fixes: 9a2654c0f62a ("drm/panel: Add and fill drm_panel type field")
    Fixes: b3bfcdf8a3b6 ("drm/panel: simple: add Tianma TM070JVHG33")
    
    Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://lore.kernel.org/r/20231012084208.2731650-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231012084208.2731650-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: using mul_u32_u32() requires linux/math64.h [+ + +]
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Tue Dec 19 14:57:34 2023 +1100

    drm: using mul_u32_u32() requires linux/math64.h
    
    [ Upstream commit 933a2a376fb3f22ba4774f74233571504ac56b02 ]
    
    Some pending include file cleanups produced this error:
    
    In file included from include/linux/kernel.h:27,
                     from drivers/gpu/ipu-v3/ipu-dp.c:7:
    include/drm/drm_color_mgmt.h: In function 'drm_color_lut_extract':
    include/drm/drm_color_mgmt.h:45:46: error: implicit declaration of function 'mul_u32_u32' [-Werror=implicit-function-declaration]
       45 |                 return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(user_input, (1 << bit_precision) - 1),
          |                                              ^~~~~~~~~~~
    
    Fixes: c6fbb6bca108 ("drm: Fix color LUT rounding")
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231219145734.13e40e1e@canb.auug.org.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ecryptfs: Reject casefold directory inodes [+ + +]
Author: Gabriel Krisman Bertazi <krisman@suse.de>
Date:   Fri Aug 11 14:38:12 2023 -0400

    ecryptfs: Reject casefold directory inodes
    
    [ Upstream commit cd72c7ef5fed44272272a105b1da22810c91be69 ]
    
    Even though it seems to be able to resolve some names of
    case-insensitive directories, the lack of d_hash and d_compare means we
    end up with a broken state in the d_cache.  Considering it was never a
    goal to support these two together, and we are preparing to use
    d_revalidate in case-insensitive filesystems, which would make the
    combination even more broken, reject any attempt to get a casefolded
    inode from ecryptfs.
    
    Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
exec: Fix error handling in begin_new_exec() [+ + +]
Author: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date:   Mon Jan 22 19:34:21 2024 +0100

    exec: Fix error handling in begin_new_exec()
    
    commit 84c39ec57d409e803a9bb6e4e85daf1243e0e80b upstream.
    
    If get_unused_fd_flags() fails, the error handling is incomplete because
    bprm->cred is already set to NULL, and therefore free_bprm will not
    unlock the cred_guard_mutex. Note there are two error conditions which
    end up here, one before and one after bprm->cred is cleared.
    
    Fixes: b8a61c9e7b4a ("exec: Generic execfd support")
    Signed-off-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
    Acked-by: Eric W. Biederman <ebiederm@xmission.com>
    Link: https://lore.kernel.org/r/AS8P193MB128517ADB5EFF29E04389EDAE4752@AS8P193MB1285.EURP193.PROD.OUTLOOK.COM
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ext4: allow for the last group to be marked as trimmed [+ + +]
Author: Suraj Jitindar Singh <surajjs@amazon.com>
Date:   Wed Dec 13 16:16:35 2023 +1100

    ext4: allow for the last group to be marked as trimmed
    
    commit 7c784d624819acbeefb0018bac89e632467cca5a upstream.
    
    The ext4 filesystem tracks the trim status of blocks at the group
    level.  When an entire group has been trimmed then it is marked as
    such and subsequent trim invocations with the same minimum trim size
    will not be attempted on that group unless it is marked as able to be
    trimmed again such as when a block is freed.
    
    Currently the last group can't be marked as trimmed due to incorrect
    logic in ext4_last_grp_cluster(). ext4_last_grp_cluster() is supposed
    to return the zero based index of the last cluster in a group. This is
    then used by ext4_try_to_trim_range() to determine if the trim
    operation spans the entire group and as such if the trim status of the
    group should be recorded.
    
    ext4_last_grp_cluster() takes a 0 based group index, thus the valid
    values for grp are 0..(ext4_get_groups_count - 1). Any group index
    less than (ext4_get_groups_count - 1) is not the last group and must
    have EXT4_CLUSTERS_PER_GROUP(sb) clusters. For the last group we need
    to calculate the number of clusters based on the number of blocks in
    the group. Finally subtract 1 from the number of clusters as zero
    based indexing is expected.  Rearrange the function slightly to make
    it clear what we are calculating and returning.
    
    Reproducer:
    // Create file system where the last group has fewer blocks than
    // blocks per group
    $ mkfs.ext4 -b 4096 -g 8192 /dev/nvme0n1 8191
    $ mount /dev/nvme0n1 /mnt
    
    Before Patch:
    $ fstrim -v /mnt
    /mnt: 25.9 MiB (27156480 bytes) trimmed
    // Group not marked as trimmed so second invocation still discards blocks
    $ fstrim -v /mnt
    /mnt: 25.9 MiB (27156480 bytes) trimmed
    
    After Patch:
    fstrim -v /mnt
    /mnt: 25.9 MiB (27156480 bytes) trimmed
    // Group marked as trimmed so second invocation DOESN'T discard any blocks
    fstrim -v /mnt
    /mnt: 0 B (0 bytes) trimmed
    
    Fixes: 45e4ab320c9b ("ext4: move setting of trimmed bit into ext4_try_to_trim_range()")
    Cc:  <stable@vger.kernel.org> # 4.19+
    Signed-off-by: Suraj Jitindar Singh <surajjs@amazon.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231213051635.37731-1-surajjs@amazon.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: avoid online resizing failures due to oversized flex bg [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Oct 23 09:30:56 2023 +0800

    ext4: avoid online resizing failures due to oversized flex bg
    
    [ Upstream commit 5d1935ac02ca5aee364a449a35e2977ea84509b0 ]
    
    When we online resize an ext4 filesystem with a oversized flexbg_size,
    
         mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
         mount $dev $dir
         resize2fs $dev 16G
    
    the following WARN_ON is triggered:
    ==================================================================
    WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
    Modules linked in: sg(E)
    CPU: 0 PID: 427 Comm: resize2fs Tainted: G  E  6.6.0-rc5+ #314
    RIP: 0010:__alloc_pages+0x411/0x550
    Call Trace:
     <TASK>
     __kmalloc_large_node+0xa2/0x200
     __kmalloc+0x16e/0x290
     ext4_resize_fs+0x481/0xd80
     __ext4_ioctl+0x1616/0x1d90
     ext4_ioctl+0x12/0x20
     __x64_sys_ioctl+0xf0/0x150
     do_syscall_64+0x3b/0x90
    ==================================================================
    
    This is because flexbg_size is too large and the size of the new_group_data
    array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
    MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
    maximum number of groups that can be allocated is:
    
     (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845
    
    And the value that is down-aligned to the power of 2 is 16384. Therefore,
    this value is defined as MAX_RESIZE_BG, and the number of groups added
    each time does not exceed this value during resizing, and is added multiple
    times to complete the online resizing. The difference is that the metadata
    in a flex_bg may be more dispersed.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231023013057.2117948-4-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix double-free of blocks due to wrong extents moved_len [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:33 2024 +0800

    ext4: fix double-free of blocks due to wrong extents moved_len
    
    commit 55583e899a5357308274601364741a83e78d6ac4 upstream.
    
    In ext4_move_extents(), moved_len is only updated when all moves are
    successfully executed, and only discards orig_inode and donor_inode
    preallocations when moved_len is not zero. When the loop fails to exit
    after successfully moving some extents, moved_len is not updated and
    remains at 0, so it does not discard the preallocations.
    
    If the moved extents overlap with the preallocated extents, the
    overlapped extents are freed twice in ext4_mb_release_inode_pa() and
    ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:
    Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is
    incremented twice. Hence when trim is executed, a zero-division bug is
    triggered in mb_update_avg_fragment_size() because bb_free is not zero
    and bb_fragments is zero.
    
    Therefore, update move_len after each extent move to avoid the issue.
    
    Reported-by: Wei Chen <harperchen1110@gmail.com>
    Reported-by: xingwei lee <xrivendell7@gmail.com>
    Closes: https://lore.kernel.org/r/CAO4mrferzqBUnCag8R3m2zf897ts9UEuhjFQGPtODT92rYyR2Q@mail.gmail.com
    Fixes: fcf6b1b729bc ("ext4: refactor ext4_move_extents code base")
    CC:  <stable@vger.kernel.org> # 3.18
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-2-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix inconsistent between segment fstrim and full fstrim [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Sat Dec 16 09:09:19 2023 +0800

    ext4: fix inconsistent between segment fstrim and full fstrim
    
    [ Upstream commit 68da4c44b994aea797eb9821acb3a4a36015293e ]
    
    Suppose we issue two FITRIM ioctls for ranges [0,15] and [16,31] with
    mininum length of trimmed range set to 8 blocks. If we have say a range of
    blocks 10-22 free, this range will not be trimmed because it straddles the
    boundary of the two FITRIM ranges and neither part is big enough. This is a
    bit surprising to some users that call FITRIM on smaller ranges of blocks
    to limit impact on the system. Also XFS trims all free space extents that
    overlap with the specified range so we are inconsistent among filesystems.
    Let's change ext4_try_to_trim_range() to consider for trimming the whole
    free space extent that straddles the end of specified range, not just the
    part of it within the range.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231216010919.1995851-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: remove unnecessary check from alloc_flex_gd() [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Oct 23 09:30:55 2023 +0800

    ext4: remove unnecessary check from alloc_flex_gd()
    
    [ Upstream commit b099eb87de105cf07cad731ded6fb40b2675108b ]
    
    In commit 967ac8af4475 ("ext4: fix potential integer overflow in
    alloc_flex_gd()"), an overflow check is added to alloc_flex_gd() to
    prevent the allocated memory from being smaller than expected due to
    the overflow. However, after kmalloc() is replaced with kmalloc_array()
    in commit 6da2ec56059c ("treewide: kmalloc() -> kmalloc_array()"), the
    kmalloc_array() function has an overflow check, so the above problem
    will not occur. Therefore, the extra check is removed.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231023013057.2117948-3-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: unify the type of flexbg_size to unsigned int [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Oct 23 09:30:54 2023 +0800

    ext4: unify the type of flexbg_size to unsigned int
    
    [ Upstream commit 658a52344fb139f9531e7543a6e0015b630feb38 ]
    
    The maximum value of flexbg_size is 2^31, but the maximum value of int
    is (2^31 - 1), so overflow may occur when the type of flexbg_size is
    declared as int.
    
    For example, when uninit_mask is initialized in ext4_alloc_group_tables(),
    if flexbg_size == 2^31, the initialized uninit_mask is incorrect, and this
    may causes set_flexbg_block_bitmap() to trigger a BUG_ON().
    
    Therefore, the flexbg_size type is declared as unsigned int to avoid
    overflow and memory waste.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231023013057.2117948-2-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
f2fs: fix to check return value of f2fs_reserve_new_block() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Thu Nov 16 14:25:56 2023 +0800

    f2fs: fix to check return value of f2fs_reserve_new_block()
    
    [ Upstream commit 956fa1ddc132e028f3b7d4cf17e6bfc8cb36c7fd ]
    
    Let's check return value of f2fs_reserve_new_block() in do_recover_data()
    rather than letting it fails silently.
    
    Also refactoring check condition on return value of f2fs_reserve_new_block()
    as below:
    - trigger f2fs_bug_on() only for ENOSPC case;
    - use do-while statement to avoid redundant codes;
    
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix to tag gcing flag on page during block migration [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Sun Dec 10 19:35:42 2023 +0800

    f2fs: fix to tag gcing flag on page during block migration
    
    [ Upstream commit 4961acdd65c956e97c1a000c82d91a8c1cdbe44b ]
    
    It needs to add missing gcing flag on page during block migration,
    in order to garantee migrated data be persisted during checkpoint,
    otherwise out-of-order persistency between data and node may cause
    data corruption after SPOR.
    
    Similar issue was fixed by commit 2d1fe8a86bf5 ("f2fs: fix to tag
    gcing flag on page during file defragment").
    
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix write pointers on zoned device after roll forward [+ + +]
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Sat Dec 2 00:08:57 2023 -0800

    f2fs: fix write pointers on zoned device after roll forward
    
    [ Upstream commit 9dad4d964291295ef48243d4e03972b85138bc9f ]
    
    1. do roll forward recovery
    2. update current segments pointers
    3. fix the entire zones' write pointers
    4. do checkpoint
    
    Reviewed-by: Daeho Jeong <daehojeong@google.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fast_dput(): handle underflows gracefully [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Nov 1 01:08:54 2023 -0400

    fast_dput(): handle underflows gracefully
    
    [ Upstream commit 504e08cebe1d4e1efe25f915234f646e74a364a8 ]
    
    If refcount is less than 1, we should just warn, unlock dentry and
    return true, so that the caller doesn't try to do anything else.
    
    Taking care of that leaves the rest of "lockref_put_return() has
    failed" case equivalent to "decrement refcount and rejoin the
    normal slow path after the point where we grab ->d_lock".
    
    NOTE: lockref_put_return() is strictly a fastpath thing - unlike
    the rest of lockref primitives, it does not contain a fallback.
    Caller (and it looks like fast_dput() is the only legitimate one
    in the entire kernel) has to do that itself.  Reasons for
    lockref_put_return() failures:
            * ->d_lock held by somebody
            * refcount <= 0
            * ... or an architecture not supporting lockref use of
    cmpxchg - sparc, anything non-SMP, config with spinlock debugging...
    
    We could add a fallback, but it would be a clumsy API - we'd have
    to distinguish between:
            (1) refcount > 1 - decremented, lock not held on return
            (2) refcount < 1 - left alone, probably no sense to hold the lock
            (3) refcount is 1, no cmphxcg - decremented, lock held on return
            (4) refcount is 1, cmphxcg supported - decremented, lock *NOT* held
                on return.
    We want to return with no lock held in case (4); that's the whole point of that
    thing.  We very much do not want to have the fallback in case (3) return without
    a lock, since the caller might have to retake it in that case.
    So it wouldn't be more convenient than doing the fallback in the caller and
    it would be very easy to screw up, especially since the test coverage would
    suck - no way to test (3) and (4) on the same kernel build.
    
    Reviewed-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev/defio: Early-out if page is already enlisted [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Fri Feb 11 10:46:39 2022 +0100

    fbdev/defio: Early-out if page is already enlisted
    
    [ Upstream commit 105a940416fc622406653b6fe54732897642dfbc ]
    
    Return early if a page is already in the list of dirty pages for
    deferred I/O. This can be detected if the page's list head is not
    empty. Keep the list head initialized while the page is not enlisted
    to make this work reliably.
    
    v2:
            * update comment and fix spelling (Sam)
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220211094640.21632-2-tzimmermann@suse.de
    Stable-dep-of: 33cd6ea9c067 ("fbdev: flush deferred IO before closing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev: defio: fix the pagelist corruption [+ + +]
Author: Chuansheng Liu <chuansheng.liu@intel.com>
Date:   Fri Mar 18 08:50:03 2022 +0800

    fbdev: defio: fix the pagelist corruption
    
    [ Upstream commit 856082f021a28221db2c32bd0531614a8382be67 ]
    
    Easily hit the below list corruption:
    ==
    list_add corruption. prev->next should be next (ffffffffc0ceb090), but
    was ffffec604507edc8. (prev=ffffec604507edc8).
    WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26
    __list_add_valid+0x53/0x80
    CPU: 65 PID: 3959 Comm: fbdev Tainted: G     U
    RIP: 0010:__list_add_valid+0x53/0x80
    Call Trace:
     <TASK>
     fb_deferred_io_mkwrite+0xea/0x150
     do_page_mkwrite+0x57/0xc0
     do_wp_page+0x278/0x2f0
     __handle_mm_fault+0xdc2/0x1590
     handle_mm_fault+0xdd/0x2c0
     do_user_addr_fault+0x1d3/0x650
     exc_page_fault+0x77/0x180
     ? asm_exc_page_fault+0x8/0x30
     asm_exc_page_fault+0x1e/0x30
    RIP: 0033:0x7fd98fc8fad1
    ==
    
    Figure out the race happens when one process is adding &page->lru into
    the pagelist tail in fb_deferred_io_mkwrite(), another process is
    re-initializing the same &page->lru in fb_deferred_io_fault(), which is
    not protected by the lock.
    
    This fix is to init all the page lists one time during initialization,
    it not only fixes the list corruption, but also avoids INIT_LIST_HEAD()
    redundantly.
    
    V2: change "int i" to "unsigned int i" (Geert Uytterhoeven)
    
    Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
    Fixes: 105a940416fc ("fbdev/defio: Early-out if page is already enlisted")
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220318005003.51810-1-chuansheng.liu@intel.com
    Stable-dep-of: 33cd6ea9c067 ("fbdev: flush deferred IO before closing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: Don't sort deferred-I/O pages by default [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Fri Feb 11 10:46:40 2022 +0100

    fbdev: Don't sort deferred-I/O pages by default
    
    [ Upstream commit 8c30e2d81bfddc5ab9f6b04db1c0f7d6ca7bdf46 ]
    
    Fbdev's deferred I/O sorts all dirty pages by default, which incurs a
    significant overhead. Make the sorting step optional and update the few
    drivers that require it. Use a FIFO list by default.
    
    Most fbdev drivers with deferred I/O build a bounding rectangle around
    the dirty pages or simply flush the whole screen. The only two affected
    DRM drivers, generic fbdev and vmwgfx, both use a bounding rectangle.
    In those cases, the exact order of the pages doesn't matter. The other
    drivers look at the page index or handle pages one-by-one. The patch
    sets the sort_pagelist flag for those, even though some of them would
    probably work correctly without sorting. Driver maintainers should update
    their driver accordingly.
    
    Sorting pages by memory offset for deferred I/O performs an implicit
    bubble-sort step on the list of dirty pages. The algorithm goes through
    the list of dirty pages and inserts each new page according to its
    index field. Even worse, list traversal always starts at the first
    entry. As video memory is most likely updated scanline by scanline, the
    algorithm traverses through the complete list for each updated page.
    
    For example, with 1024x768x32bpp each page covers exactly one scanline.
    Writing a single screen update from top to bottom requires updating
    768 pages. With an average list length of 384 entries, a screen update
    creates (768 * 384 =) 294912 compare operation.
    
    Fix this by making the sorting step opt-in and update the few drivers
    that require it. All other drivers work with unsorted page lists. Pages
    are appended to the list. Therefore, in the common case of writing the
    framebuffer top to bottom, pages are still sorted by offset, which may
    have a positive effect on performance.
    
    Playing a video [1] in mplayer's benchmark mode shows the difference
    (i7-4790, FullHD, simpledrm, kernel with debugging).
    
      mplayer -benchmark -nosound -vo fbdev ./big_buck_bunny_720p_stereo.ogg
    
    With sorted page lists:
    
      BENCHMARKs: VC:  32.960s VO:  73.068s A:   0.000s Sys:   2.413s =  108.441s
      BENCHMARK%: VC: 30.3947% VO: 67.3802% A:  0.0000% Sys:  2.2251% = 100.0000%
    
    With unsorted page lists:
    
      BENCHMARKs: VC:  31.005s VO:  42.889s A:   0.000s Sys:   2.256s =   76.150s
      BENCHMARK%: VC: 40.7156% VO: 56.3219% A:  0.0000% Sys:  2.9625% = 100.0000%
    
    VC shows the overhead of video decoding, VO shows the overhead of the
    video output. Using unsorted page lists reduces the benchmark's run time
    by ~32s/~25%.
    
    v2:
            * Make sorted pagelists the special case (Sam)
            * Comment on drivers' use of pagelist (Sam)
            * Warn about the overhead in comment
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_720p_stereo.ogg # [1]
    Link: https://patchwork.freedesktop.org/patch/msgid/20220211094640.21632-3-tzimmermann@suse.de
    Stable-dep-of: 33cd6ea9c067 ("fbdev: flush deferred IO before closing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: Fix incorrect page mapping clearance at fb_deferred_io_release() [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Mar 8 11:50:12 2023 +0100

    fbdev: Fix incorrect page mapping clearance at fb_deferred_io_release()
    
    [ Upstream commit fe9ae05cfbe587dda724fcf537c00bc2f287da62 ]
    
    The recent fix for the deferred I/O by the commit
      3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices")
    caused a regression when the same fb device is opened/closed while
    it's being used.  It resulted in a frozen screen even if something
    is redrawn there after the close.  The breakage is because the patch
    was made under a wrong assumption of a single open; in the current
    code, fb_deferred_io_release() cleans up the page mapping of the
    pageref list and it calls cancel_delayed_work_sync() unconditionally,
    where both are no correct behavior for multiple opens.
    
    This patch adds a refcount for the opens of the device, and applies
    the cleanup only when all files get closed.
    
    As both fb_deferred_io_open() and _close() are called always in the
    fb_info lock (mutex), it's safe to use the normal int for the
    refcounting.
    
    Also, a useless BUG_ON() is dropped.
    
    Fixes: 3efc61d95259 ("fbdev: Fix invalid page access after closing deferred I/O devices")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230308105012.1845-1-tiwai@suse.de
    Stable-dep-of: 33cd6ea9c067 ("fbdev: flush deferred IO before closing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: Fix invalid page access after closing deferred I/O devices [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sun Jan 29 09:28:56 2023 +0100

    fbdev: Fix invalid page access after closing deferred I/O devices
    
    [ Upstream commit 3efc61d95259956db25347e2a9562c3e54546e20 ]
    
    When a fbdev with deferred I/O is once opened and closed, the dirty
    pages still remain queued in the pageref list, and eventually later
    those may be processed in the delayed work.  This may lead to a
    corruption of pages, hitting an Oops.
    
    This patch makes sure to cancel the delayed work and clean up the
    pageref list at closing the device for addressing the bug.  A part of
    the cleanup code is factored out as a new helper function that is
    called from the common fb_release().
    
    Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Tested-by: Miko Larsson <mikoxyzzz@gmail.com>
    Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230129082856.22113-1-tiwai@suse.de
    Stable-dep-of: 33cd6ea9c067 ("fbdev: flush deferred IO before closing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: flush deferred IO before closing [+ + +]
Author: Nam Cao <namcao@linutronix.de>
Date:   Mon Dec 18 10:57:31 2023 +0100

    fbdev: flush deferred IO before closing
    
    [ Upstream commit 33cd6ea9c0673517cdb06ad5c915c6f22e9615fc ]
    
    When framebuffer gets closed, the queued deferred IO gets cancelled. This
    can cause some last display data to vanish. This is problematic for users
    who send a still image to the framebuffer, then close the file: the image
    may never appear.
    
    To ensure none of display data get lost, flush the queued deferred IO
    first before closing.
    
    Another possible solution is to delete the cancel_delayed_work_sync()
    instead. The difference is that the display may appear some time after
    closing. However, the clearing of page mapping after this needs to be
    removed too, because the page mapping is used by the deferred work. It is
    not completely obvious whether it is okay to not clear the page mapping.
    For a patch intended for stable trees, go with the simple and obvious
    solution.
    
    Fixes: 60b59beafba8 ("fbdev: mm: Deferred IO support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: Rename pagelist to pagereflist for deferred I/O [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Fri Apr 29 12:08:33 2022 +0200

    fbdev: Rename pagelist to pagereflist for deferred I/O
    
    [ Upstream commit e80eec1b871a2acb8f5c92db4c237e9ae6dd322b ]
    
    Rename various instances of pagelist to pagereflist. The list now
    stores pageref structures, so the new name is more appropriate.
    
    In their write-back helpers, several fbdev drivers refer to the
    pageref list in struct fb_deferred_io instead of using the one
    supplied as argument to the function. Convert them over to the
    supplied one. It's the same instance, so no change of behavior
    occurs.
    
    v4:
            * fix commit message (Javier)
    
    Suggested-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-5-tzimmermann@suse.de
    Stable-dep-of: 33cd6ea9c067 ("fbdev: flush deferred IO before closing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: Track deferred-I/O pages in pageref struct [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Fri Apr 29 12:08:31 2022 +0200

    fbdev: Track deferred-I/O pages in pageref struct
    
    [ Upstream commit 56c134f7f1b58be08bdb0ca8372474a4a5165f31 ]
    
    Store the per-page state for fbdev's deferred I/O in struct
    fb_deferred_io_pageref. Maintain a list of pagerefs for the pages
    that have to be written back to video memory. Update all affected
    drivers.
    
    As with pages before, fbdev acquires a pageref when an mmaped page
    of the framebuffer is being written to. It holds the pageref in a
    list of all currently written pagerefs until it flushes the written
    pages to video memory. Writeback occurs periodically. After writeback
    fbdev releases all pagerefs and builds up a new dirty list until the
    next writeback occurs.
    
    Using pagerefs has a number of benefits.
    
    For pages of the framebuffer, the deferred I/O code used struct
    page.lru as an entry into the list of dirty pages. The lru field is
    owned by the page cache, which makes deferred I/O incompatible with
    some memory pages (e.g., most notably DRM's GEM SHMEM allocator).
    struct fb_deferred_io_pageref now provides an entry into a list of
    dirty framebuffer pages, freeing lru for use with the page cache.
    
    Drivers also assumed that struct page.index is the page offset into
    the framebuffer. This is not true for DRM buffers, which are located
    at various offset within a mapped area. struct fb_deferred_io_pageref
    explicitly stores an offset into the framebuffer. struct page.index
    is now only the page offset into the mapped area.
    
    These changes will allow DRM to use fbdev deferred I/O without an
    intermediate shadow buffer.
    
    v3:
            * use pageref->offset for sorting
            * fix grammar in comment
    v2:
            * minor fixes in commit message
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-3-tzimmermann@suse.de
    Stable-dep-of: 33cd6ea9c067 ("fbdev: flush deferred IO before closing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firewire: core: correct documentation of fw_csr_string() kernel API [+ + +]
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Thu Feb 1 20:53:18 2024 +0900

    firewire: core: correct documentation of fw_csr_string() kernel API
    
    commit 5f9ab17394f831cb7986ec50900fa37507a127f1 upstream.
    
    Against its current description, the kernel API can accepts all types of
    directory entries.
    
    This commit corrects the documentation.
    
    Cc: stable@vger.kernel.org
    Fixes: 3c2c58cb33b3 ("firewire: core: fw_csr_string addendum")
    Link: https://lore.kernel.org/r/20240130100409.30128-2-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
firmware: arm_scmi: Check mailbox/SMT channel for consistency [+ + +]
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Wed Dec 20 17:21:12 2023 +0000

    firmware: arm_scmi: Check mailbox/SMT channel for consistency
    
    commit 437a310b22244d4e0b78665c3042e5d1c0f45306 upstream.
    
    On reception of a completion interrupt the shared memory area is accessed
    to retrieve the message header at first and then, if the message sequence
    number identifies a transaction which is still pending, the related
    payload is fetched too.
    
    When an SCMI command times out the channel ownership remains with the
    platform until eventually a late reply is received and, as a consequence,
    any further transmission attempt remains pending, waiting for the channel
    to be relinquished by the platform.
    
    Once that late reply is received the channel ownership is given back
    to the agent and any pending request is then allowed to proceed and
    overwrite the SMT area of the just delivered late reply; then the wait
    for the reply to the new request starts.
    
    It has been observed that the spurious IRQ related to the late reply can
    be wrongly associated with the freshly enqueued request: when that happens
    the SCMI stack in-flight lookup procedure is fooled by the fact that the
    message header now present in the SMT area is related to the new pending
    transaction, even though the real reply has still to arrive.
    
    This race-condition on the A2P channel can be detected by looking at the
    channel status bits: a genuine reply from the platform will have set the
    channel free bit before triggering the completion IRQ.
    
    Add a consistency check to validate such condition in the A2P ISR.
    
    Reported-by: Xinglong Yang <xinglong.yang@cixtech.com>
    Closes: https://lore.kernel.org/all/PUZPR06MB54981E6FA00D82BFDBB864FBF08DA@PUZPR06MB5498.apcprd06.prod.outlook.com/
    Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type")
    Cc: stable@vger.kernel.org # 5.15+
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Tested-by: Xinglong Yang <xinglong.yang@cixtech.com>
    Link: https://lore.kernel.org/r/20231220172112.763539-1-cristian.marussi@arm.com
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fjes: fix memleaks in fjes_hw_setup [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Tue Jan 23 01:24:42 2024 +0800

    fjes: fix memleaks in fjes_hw_setup
    
    [ Upstream commit f6cc4b6a3ae53df425771000e9c9540cce9b7bb1 ]
    
    In fjes_hw_setup, it allocates several memory and delay the deallocation
    to the fjes_hw_exit in fjes_probe through the following call chain:
    
    fjes_probe
      |-> fjes_hw_init
            |-> fjes_hw_setup
      |-> fjes_hw_exit
    
    However, when fjes_hw_setup fails, fjes_hw_exit won't be called and thus
    all the resources allocated in fjes_hw_setup will be leaked. In this
    patch, we free those resources in fjes_hw_setup and prevents such leaks.
    
    Fixes: 2fcbca687702 ("fjes: platform_driver's .probe and .remove routine")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240122172445.3841883-1-alexious@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/kernfs/dir: obey S_ISGID [+ + +]
Author: Max Kellermann <max.kellermann@ionos.com>
Date:   Fri Dec 8 10:33:10 2023 +0100

    fs/kernfs/dir: obey S_ISGID
    
    [ Upstream commit 5133bee62f0ea5d4c316d503cc0040cac5637601 ]
    
    Handling of S_ISGID is usually done by inode_init_owner() in all other
    filesystems, but kernfs doesn't use that function.  In kernfs, struct
    kernfs_node is the primary data structure, and struct inode is only
    created from it on demand.  Therefore, inode_init_owner() can't be
    used and we need to imitate its behavior.
    
    S_ISGID support is useful for the cgroup filesystem; it allows
    subtrees managed by an unprivileged process to retain a certain owner
    gid, which then enables sharing access to the subtree with another
    unprivileged process.
    
    --
    v1 -> v2: minor coding style fix (comment)
    
    Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: https://lore.kernel.org/r/20231208093310.297233-2-max.kellermann@ionos.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/ntfs3: Add null pointer checks [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Thu Dec 29 15:44:43 2022 +0400

    fs/ntfs3: Add null pointer checks
    
    commit fc4992458e0aa2d2e82a25c922e6ac36c2d91083 upstream.
    
    Added null pointer checks in function ntfs_security_init.
    Also added le32_to_cpu in functions ntfs_security_init and indx_read.
    
    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>

fs/ntfs3: Fix an NULL dereference bug [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Oct 17 17:04:39 2023 +0300

    fs/ntfs3: Fix an NULL dereference bug
    
    [ Upstream commit b2dd7b953c25ffd5912dda17e980e7168bebcf6c ]
    
    The issue here is when this is called from ntfs_load_attr_list().  The
    "size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow
    on a 64bit systems but on 32bit systems the "+ 1023" can overflow and
    the result is zero.  This means that the kmalloc will succeed by
    returning the ZERO_SIZE_PTR and then the memcpy() will crash with an
    Oops on the next line.
    
    Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/pipe: move check to pipe_has_watch_queue() [+ + +]
Author: Max Kellermann <max.kellermann@ionos.com>
Date:   Thu Sep 21 09:57:53 2023 +0200

    fs/pipe: move check to pipe_has_watch_queue()
    
    [ Upstream commit b4bd6b4bac8edd61eb8f7b836969d12c0c6af165 ]
    
    This declutters the code by reducing the number of #ifdefs and makes
    the watch_queue checks simpler.  This has no runtime effect; the
    machine code is identical.
    
    Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
    Message-Id: <20230921075755.1378787-2-max.kellermann@ionos.com>
    Reviewed-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Stable-dep-of: e95aada4cb93 ("pipe: wakeup wr_wait after setting max_usage")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree [+ + +]
Author: Osama Muhammad <osmtendev@gmail.com>
Date:   Wed Oct 11 23:46:37 2023 +0500

    FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
    
    [ Upstream commit 9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68 ]
    
    Syzkaller reported the following issue:
    
    UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
    index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
    CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
     ubsan_epilogue lib/ubsan.c:217 [inline]
     __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
     dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
     dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
     dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
     dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
     dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
     txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
     txUpdateMap+0x342/0x9e0
     txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
     jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
     kthread+0x2d3/0x370 kernel/kthread.c:388
     ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
     </TASK>
    ================================================================================
    Kernel panic - not syncing: UBSAN: panic_on_warn set ...
    CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
     panic+0x30f/0x770 kernel/panic.c:340
     check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
     ubsan_epilogue lib/ubsan.c:223 [inline]
     __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
     dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
     dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
     dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
     dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
     dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
     txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
     txUpdateMap+0x342/0x9e0
     txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
     jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
     kthread+0x2d3/0x370 kernel/kthread.c:388
     ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
     </TASK>
    Kernel Offset: disabled
    Rebooting in 86400 seconds..
    
    The issue is caused when the value of lp becomes greater than
    CTLTREESIZE which is the max size of stree. Adding a simple check
    solves this issue.
    
    Dave:
    As the function returns a void, good error handling
    would require a more intrusive code reorganization, so I modified
    Osama's patch at use WARN_ON_ONCE for lack of a cleaner option.
    
    The patch is tested via syzbot.
    
    Reported-by: syzbot+39ba34a099ac2e9bd3cb@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?extid=39ba34a099ac2e9bd3cb
    Signed-off-by: Osama Muhammad <osmtendev@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpio: eic-sprd: Clear interrupt after set the interrupt type [+ + +]
Author: Wenhua Lin <Wenhua.Lin@unisoc.com>
Date:   Tue Jan 9 15:38:48 2024 +0800

    gpio: eic-sprd: Clear interrupt after set the interrupt type
    
    [ Upstream commit 84aef4ed59705585d629e81d633a83b7d416f5fb ]
    
    The raw interrupt status of eic maybe set before the interrupt is enabled,
    since the eic interrupt has a latch function, which would trigger the
    interrupt event once enabled it from user side. To solve this problem,
    interrupts generated before setting the interrupt trigger type are ignored.
    
    Fixes: 25518e024e3a ("gpio: Add Spreadtrum EIC driver support")
    Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
    Signed-off-by: Wenhua Lin <Wenhua.Lin@unisoc.com>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpiolib: acpi: Ignore touchpad wakeup on GPD G1619-04 [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Jan 17 08:29:42 2024 -0600

    gpiolib: acpi: Ignore touchpad wakeup on GPD G1619-04
    
    commit 805c74eac8cb306dc69b87b6b066ab4da77ceaf1 upstream.
    
    Spurious wakeups are reported on the GPD G1619-04 which
    can be absolved by programming the GPIO to ignore wakeups.
    
    Cc: stable@vger.kernel.org
    Reported-and-tested-by: George Melikov <mail@gmelikov.ru>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3073
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gve: Fix use-after-free vulnerability [+ + +]
Author: Praveen Kaligineedi <pkaligineedi@google.com>
Date:   Tue Jan 30 13:45:07 2024 -0800

    gve: Fix use-after-free vulnerability
    
    From: Bailey Forrest <bcf@google.com>
    
    Call skb_shinfo() after gve_prep_tso() on DQO TX path.
    gve_prep_tso() calls skb_cow_head(), which may reallocate
    shinfo causing a use after free.
    
    This bug was unintentionally fixed by 'a6fb8d5a8b69
    ("gve: Tx path for DQO-QPL")' while adding DQO-QPL format
    support in 6.6. That patch is not appropriate for stable releases.
    
    Fixes: a57e5de476be ("gve: DQO: Add TX path")
    Signed-off-by: Praveen Kaligineedi <pkaligineedi@google.com>
    Signed-off-by: Bailey Forrest <bcf@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Jeroen de Borst <jeroendb@google.com>
    Reviewed-by: Kevin DeCabooter <decabooter@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HID: apple: Add 2021 magic keyboard FN key mapping [+ + +]
Author: Benjamin Berg <bberg@redhat.com>
Date:   Mon Nov 8 13:50:38 2021 +0100

    HID: apple: Add 2021 magic keyboard FN key mapping
    
    commit 531cb56972f2773c941499fcfb639cd5128dfb27 upstream.
    
    The new 2021 apple models have a different FN key assignment. Add a new
    translation table and use that for the 2021 magic keyboard.
    
    Signed-off-by: Benjamin Berg <bberg@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Aseda Aboagye <aaboagye@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: apple: Add support for the 2021 Magic Keyboard [+ + +]
Author: Alex Henrie <alexhenrie24@gmail.com>
Date:   Fri Oct 8 01:37:01 2021 -0600

    HID: apple: Add support for the 2021 Magic Keyboard
    
    commit 0cd3be51733febb4f8acb92bcf55b75fe824dd05 upstream.
    
    Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Aseda Aboagye <aaboagye@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: i2c-hid-of: fix NULL-deref on failed power up [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Jan 26 18:09:01 2024 +0100

    HID: i2c-hid-of: fix NULL-deref on failed power up
    
    commit 00aab7dcb2267f2aef59447602f34501efe1a07f upstream.
    
    A while back the I2C HID implementation was split in an ACPI and OF
    part, but the new OF driver never initialises the client pointer which
    is dereferenced on power-up failures.
    
    Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules")
    Cc: stable@vger.kernel.org      # 5.12
    Cc: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: wacom: Do not register input devices until after hid_hw_start [+ + +]
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Jan 29 14:35:45 2024 -0800

    HID: wacom: Do not register input devices until after hid_hw_start
    
    commit c1d6708bf0d3dd976460d435373cf5abf21ce258 upstream.
    
    If a input device is opened before hid_hw_start is called, events may
    not be received from the hardware. In the case of USB-backed devices,
    for example, the hid_hw_start function is responsible for filling in
    the URB which is submitted when the input device is opened. If a device
    is opened prematurely, polling will never start because the device will
    not have been in the correct state to send the URB.
    
    Because the wacom driver registers its input devices before calling
    hid_hw_start, there is a window of time where a device can be opened
    and end up in an inoperable state. Some ARM-based Chromebooks in particular
    reliably trigger this bug.
    
    This commit splits the wacom_register_inputs function into two pieces.
    One which is responsible for setting up the allocated inputs (and runs
    prior to hid_hw_start so that devices are ready for any input events
    they may end up receiving) and another which only registers the devices
    (and runs after hid_hw_start to ensure devices can be immediately opened
    without issue). Note that the functions to initialize the LEDs and remotes
    are also moved after hid_hw_start to maintain their own dependency chains.
    
    Fixes: 7704ac937345 ("HID: wacom: implement generic HID handling for pen generic devices")
    Cc: stable@vger.kernel.org # v3.18+
    Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Tested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: wacom: generic: Avoid reporting a serial of '0' to userspace [+ + +]
Author: Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com>
Date:   Thu Feb 1 13:40:55 2024 +0900

    HID: wacom: generic: Avoid reporting a serial of '0' to userspace
    
    commit ab41a31dd5e2681803642b6d08590b61867840ec upstream.
    
    The xf86-input-wacom driver does not treat '0' as a valid serial
    number and will drop any input report which contains an
    MSC_SERIAL = 0 event. The kernel driver already takes care to
    avoid sending any MSC_SERIAL event if the value of serial[0] == 0
    (which is the case for devices that don't actually report a
    serial number), but this is not quite sufficient.
    Only the lower 32 bits of the serial get reported to userspace,
    so if this portion of the serial is zero then there can still
    be problems.
    
    This commit allows the driver to report either the lower 32 bits
    if they are non-zero or the upper 32 bits otherwise.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com>
    Fixes: f85c9dc678a5 ("HID: wacom: generic: Support tool ID and additional tool types")
    CC: stable@vger.kernel.org # v4.10
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hrtimer: Ignore slack time for RT tasks in schedule_hrtimeout_range() [+ + +]
Author: Davidlohr Bueso <dave@stgolabs.net>
Date:   Mon Jan 23 09:32:06 2023 -0800

    hrtimer: Ignore slack time for RT tasks in schedule_hrtimeout_range()
    
    commit 0c52310f260014d95c1310364379772cb74cf82d upstream.
    
    While in theory the timer can be triggered before expires + delta, for the
    cases of RT tasks they really have no business giving any lenience for
    extra slack time, so override any passed value by the user and always use
    zero for schedule_hrtimeout_range() calls. Furthermore, this is similar to
    what the nanosleep(2) family already does with current->timer_slack_ns.
    
    Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20230123173206.6764-3-dave@stgolabs.net
    Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hrtimer: Report offline hrtimer enqueue [+ + +]
Author: Frederic Weisbecker <frederic@kernel.org>
Date:   Mon Jan 29 15:56:36 2024 -0800

    hrtimer: Report offline hrtimer enqueue
    
    commit dad6a09f3148257ac1773cd90934d721d68ab595 upstream.
    
    The hrtimers migration on CPU-down hotplug process has been moved
    earlier, before the CPU actually goes to die. This leaves a small window
    of opportunity to queue an hrtimer in a blind spot, leaving it ignored.
    
    For example a practical case has been reported with RCU waking up a
    SCHED_FIFO task right before the CPUHP_AP_IDLE_DEAD stage, queuing that
    way a sched/rt timer to the local offline CPU.
    
    Make sure such situations never go unnoticed and warn when that happens.
    
    Fixes: 5c0930ccaad5 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier")
    Reported-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240129235646.3171983-4-boqun.feng@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hv_netvsc: Calculate correct ring size when PAGE_SIZE is not 4 Kbytes [+ + +]
Author: Michael Kelley <mhklinux@outlook.com>
Date:   Mon Jan 22 08:20:28 2024 -0800

    hv_netvsc: Calculate correct ring size when PAGE_SIZE is not 4 Kbytes
    
    commit 6941f67ad37d5465b75b9ffc498fcf6897a3c00e upstream.
    
    Current code in netvsc_drv_init() incorrectly assumes that PAGE_SIZE
    is 4 Kbytes, which is wrong on ARM64 with 16K or 64K page size. As a
    result, the default VMBus ring buffer size on ARM64 with 64K page size
    is 8 Mbytes instead of the expected 512 Kbytes. While this doesn't break
    anything, a typical VM with 8 vCPUs and 8 netvsc channels wastes 120
    Mbytes (8 channels * 2 ring buffers/channel * 7.5 Mbytes/ring buffer).
    
    Unfortunately, the module parameter specifying the ring buffer size
    is in units of 4 Kbyte pages. Ideally, it should be in units that
    are independent of PAGE_SIZE, but backwards compatibility prevents
    changing that now.
    
    Fix this by having netvsc_drv_init() hardcode 4096 instead of using
    PAGE_SIZE when calculating the ring buffer size in bytes. Also
    use the VMBUS_RING_SIZE macro to ensure proper alignment when running
    with page size larger than 4K.
    
    Cc: <stable@vger.kernel.org> # 5.15.x
    Fixes: 7aff79e297ee ("Drivers: hv: Enable Hyper-V code to be built on ARM64")
    Signed-off-by: Michael Kelley <mhklinux@outlook.com>
    Link: https://lore.kernel.org/r/20240122162028.348885-1-mhklinux@outlook.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove [+ + +]
Author: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
Date:   Tue Jan 30 23:35:51 2024 -0800

    hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
    
    commit e0526ec5360a48ad3ab2e26e802b0532302a7e11 upstream.
    
    In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
    VMBus channel"), napi_disable was getting called for all channels,
    including all subchannels without confirming if they are enabled or not.
    
    This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
    has finished running but nvdev->subchan_work has not started yet.
    netvsc_subchan_work() -> rndis_set_subchannel() has not created the
    sub-channels and because of that netvsc_sc_open() is not running.
    netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which
    netvsc_subchan_work did not run.
    
    netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
    cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the
    NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
    opposite.
    
    Now during netvsc_device_remove(), when napi_disable is called for those
    subchannels, napi_disable gets stuck on infinite msleep.
    
    This fix addresses this problem by ensuring that napi_disable() is not
    getting called for non-enabled NAPI struct.
    But netif_napi_del() is still necessary for these non-enabled NAPI struct
    for cleanup purpose.
    
    Call trace:
    [  654.559417] task:modprobe        state:D stack:    0 pid: 2321 ppid:  1091 flags:0x00004002
    [  654.568030] Call Trace:
    [  654.571221]  <TASK>
    [  654.573790]  __schedule+0x2d6/0x960
    [  654.577733]  schedule+0x69/0xf0
    [  654.581214]  schedule_timeout+0x87/0x140
    [  654.585463]  ? __bpf_trace_tick_stop+0x20/0x20
    [  654.590291]  msleep+0x2d/0x40
    [  654.593625]  napi_disable+0x2b/0x80
    [  654.597437]  netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
    [  654.603935]  rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
    [  654.611101]  ? do_wait_intr+0xb0/0xb0
    [  654.615753]  netvsc_remove+0x7c/0x120 [hv_netvsc]
    [  654.621675]  vmbus_remove+0x27/0x40 [hv_vmbus]
    
    Cc: stable@vger.kernel.org
    Fixes: ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel")
    Signed-off-by: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/1706686551-28510-1-git-send-email-schakrabarti@linux.microsoft.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hwmon: (aspeed-pwm-tacho) mutex for tach reading [+ + +]
Author: Loic Prylli <lprylli@netflix.com>
Date:   Fri Nov 3 11:30:55 2023 +0100

    hwmon: (aspeed-pwm-tacho) mutex for tach reading
    
    [ Upstream commit 1168491e7f53581ba7b6014a39a49cfbbb722feb ]
    
    the ASPEED_PTCR_RESULT Register can only hold the result for a
    single fan input. Adding a mutex to protect the register until the
    reading is done.
    
    Signed-off-by: Loic Prylli <lprylli@netflix.com>
    Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
    Fixes: 2d7a548a3eff ("drivers: hwmon: Support for ASPEED PWM/Fan tach")
    Link: https://lore.kernel.org/r/121d888762a1232ef403cf35230ccf7b3887083a.1699007401.git.alexander.hansen@9elements.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (coretemp) Fix bogus core_id to attr name mapping [+ + +]
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Feb 2 17:21:35 2024 +0800

    hwmon: (coretemp) Fix bogus core_id to attr name mapping
    
    [ Upstream commit fdaf0c8629d4524a168cb9e4ad4231875749b28c ]
    
    Before commit 7108b80a542b ("hwmon/coretemp: Handle large core ID
    value"), there is a fixed mapping between
    1. cpu_core_id
    2. the index in pdata->core_data[] array
    3. the sysfs attr name, aka "tempX_"
    The later two always equal cpu_core_id + 2.
    
    After the commit, pdata->core_data[] index is got from ida so that it
    can handle sparse core ids and support more cores within a package.
    
    However, the commit erroneously maps the sysfs attr name to
    pdata->core_data[] index instead of cpu_core_id + 2.
    
    As a result, the code is not aligned with the comments, and brings user
    visible changes in hwmon sysfs on systems with sparse core id.
    
    For example, before commit 7108b80a542b ("hwmon/coretemp: Handle large
    core ID value"),
    /sys/class/hwmon/hwmon2/temp2_label:Core 0
    /sys/class/hwmon/hwmon2/temp3_label:Core 1
    /sys/class/hwmon/hwmon2/temp4_label:Core 2
    /sys/class/hwmon/hwmon2/temp5_label:Core 3
    /sys/class/hwmon/hwmon2/temp6_label:Core 4
    /sys/class/hwmon/hwmon3/temp10_label:Core 8
    /sys/class/hwmon/hwmon3/temp11_label:Core 9
    after commit,
    /sys/class/hwmon/hwmon2/temp2_label:Core 0
    /sys/class/hwmon/hwmon2/temp3_label:Core 1
    /sys/class/hwmon/hwmon2/temp4_label:Core 2
    /sys/class/hwmon/hwmon2/temp5_label:Core 3
    /sys/class/hwmon/hwmon2/temp6_label:Core 4
    /sys/class/hwmon/hwmon2/temp7_label:Core 8
    /sys/class/hwmon/hwmon2/temp8_label:Core 9
    
    Restore the previous behavior and rework the code, comments and variable
    names to avoid future confusions.
    
    Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value")
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Link: https://lore.kernel.org/r/20240202092144.71180-3-rui.zhang@intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (coretemp) Fix out-of-bounds memory access [+ + +]
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Feb 2 17:21:34 2024 +0800

    hwmon: (coretemp) Fix out-of-bounds memory access
    
    [ Upstream commit 4e440abc894585a34c2904a32cd54af1742311b3 ]
    
    Fix a bug that pdata->cpu_map[] is set before out-of-bounds check.
    The problem might be triggered on systems with more than 128 cores per
    package.
    
    Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value")
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240202092144.71180-2-rui.zhang@intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Stable-dep-of: fdaf0c8629d4 ("hwmon: (coretemp) Fix bogus core_id to attr name mapping")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwrng: core - Fix page fault dead lock on mmap-ed hwrng [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Sat Dec 2 09:01:54 2023 +0800

    hwrng: core - Fix page fault dead lock on mmap-ed hwrng
    
    commit 78aafb3884f6bc6636efcc1760c891c8500b9922 upstream.
    
    There is a dead-lock in the hwrng device read path.  This triggers
    when the user reads from /dev/hwrng into memory also mmap-ed from
    /dev/hwrng.  The resulting page fault triggers a recursive read
    which then dead-locks.
    
    Fix this by using a stack buffer when calling copy_to_user.
    
    Reported-by: Edward Adam Davis <eadavis@qq.com>
    Reported-by: syzbot+c52ab18308964d248092@syzkaller.appspotmail.com
    Fixes: 9996508b3353 ("hwrng: core - Replace u32 in driver API with byte array")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i2c: i801: Fix block process call transactions [+ + +]
Author: Jean Delvare <jdelvare@suse.de>
Date:   Wed Feb 14 15:59:39 2024 +0100

    i2c: i801: Fix block process call transactions
    
    [ Upstream commit c1c9d0f6f7f1dbf29db996bd8e166242843a5f21 ]
    
    According to the Intel datasheets, software must reset the block
    buffer index twice for block process call transactions: once before
    writing the outgoing data to the buffer, and once again before
    reading the incoming data from the buffer.
    
    The driver is currently missing the second reset, causing the wrong
    portion of the block buffer to be read.
    
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Reported-by: Piotr Zakowski <piotr.zakowski@intel.com>
    Closes: https://lore.kernel.org/linux-i2c/20240213120553.7b0ab120@endymion.delvare/
    Fixes: 315cd67c9453 ("i2c: i801: Add Block Write-Block Read Process Call support")
    Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: i801: Remove i801_set_block_buffer_mode [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Thu Nov 18 23:58:17 2021 +0100

    i2c: i801: Remove i801_set_block_buffer_mode
    
    [ Upstream commit 1e1d6582f483a4dba4ea03445e6f2f05d9de5bcf ]
    
    If FEATURE_BLOCK_BUFFER is set then bit SMBAUXCTL_E32B is supported
    and there's no benefit in reading it back. Origin of this check
    seems to be 14 yrs ago when people were not completely sure which
    chip versions support the block buffer mode.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Tested-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Stable-dep-of: c1c9d0f6f7f1 ("i2c: i801: Fix block process call transactions")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i3c: master: cdns: Update maximum prescaler value for i2c clock [+ + +]
Author: Harshit Shah <harshitshah.opendev@gmail.com>
Date:   Sat Dec 30 14:41:23 2023 +0530

    i3c: master: cdns: Update maximum prescaler value for i2c clock
    
    [ Upstream commit 374c13f9080a1b9835a5ed3e7bea93cf8e2dc262 ]
    
    As per the Cadence IP document fixed the I2C clock divider value limit from
    16 bits instead of 10 bits. Without this change setting up the I2C clock to
    low frequencies will not work as the prescaler value might be greater than
    10 bit number.
    
    I3C clock divider value is 10 bits only. Updating the macro names for both.
    
    Signed-off-by: Harshit Shah <harshitshah.opendev@gmail.com>
    Link: https://lore.kernel.org/r/1703927483-28682-1-git-send-email-harshitshah.opendev@gmail.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: Fix VF disable behavior to block all traffic [+ + +]
Author: Andrii Staikov <andrii.staikov@intel.com>
Date:   Wed Nov 29 15:24:12 2023 +0100

    i40e: Fix VF disable behavior to block all traffic
    
    [ Upstream commit 31deb12e85c35ddd2c037f0107d05d8674cab2c0 ]
    
    Currently, if a VF is disabled using the
    'ip link set dev $ETHX vf $VF_NUM state disable' command, the VF is still
    able to receive traffic.
    
    Fix the behavior of the 'ip link set dev $ETHX vf $VF_NUM state disable'
    to completely shutdown the VF's queues making it entirely disabled and
    not able to receive or send any traffic.
    
    Modify the behavior of the 'ip link set $ETHX vf $VF_NUM state enable'
    command to make a VF do reinitialization bringing the queues back up.
    
    Co-developed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Reviewed-by: Jan Sokolowski <jan.sokolowski@intel.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Signed-off-by: Andrii Staikov <andrii.staikov@intel.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i40e: Fix waiting for queues of all VSIs to be disabled [+ + +]
Author: Ivan Vecera <ivecera@redhat.com>
Date:   Wed Nov 8 17:01:03 2023 +0100

    i40e: Fix waiting for queues of all VSIs to be disabled
    
    [ Upstream commit c73729b64bb692186da080602cd13612783f52ac ]
    
    The function i40e_pf_wait_queues_disabled() iterates all PF's VSIs
    up to 'pf->hw.func_caps.num_vsis' but this is incorrect because
    the real number of VSIs can be up to 'pf->num_alloc_vsi' that
    can be higher. Fix this loop.
    
    Fixes: 69129dc39fac ("i40e: Modify Tx disable wait flow in case of DCB reconfiguration")
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/ipoib: Fix mcast list locking [+ + +]
Author: Daniel Vacek <neelx@redhat.com>
Date:   Tue Dec 12 09:07:45 2023 +0100

    IB/ipoib: Fix mcast list locking
    
    [ Upstream commit 4f973e211b3b1c6d36f7c6a19239d258856749f9 ]
    
    Releasing the `priv->lock` while iterating the `priv->multicast_list` in
    `ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
    remove the items while in the middle of iteration. If the mcast is removed
    while the lock was dropped, the for loop spins forever resulting in a hard
    lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
    
        Task A (kworker/u72:2 below)       | Task B (kworker/u72:0 below)
        -----------------------------------+-----------------------------------
        ipoib_mcast_join_task(work)        | ipoib_ib_dev_flush_light(work)
          spin_lock_irq(&priv->lock)       | __ipoib_ib_dev_flush(priv, ...)
          list_for_each_entry(mcast,       | ipoib_mcast_dev_flush(dev = priv->dev)
              &priv->multicast_list, list) |
            ipoib_mcast_join(dev, mcast)   |
              spin_unlock_irq(&priv->lock) |
                                           |   spin_lock_irqsave(&priv->lock, flags)
                                           |   list_for_each_entry_safe(mcast, tmcast,
                                           |                  &priv->multicast_list, list)
                                           |     list_del(&mcast->list);
                                           |     list_add_tail(&mcast->list, &remove_list)
                                           |   spin_unlock_irqrestore(&priv->lock, flags)
              spin_lock_irq(&priv->lock)   |
                                           |   ipoib_mcast_remove_list(&remove_list)
       (Here, `mcast` is no longer on the  |     list_for_each_entry_safe(mcast, tmcast,
        `priv->multicast_list` and we keep |                            remove_list, list)
        spinning on the `remove_list` of   |  >>>  wait_for_completion(&mcast->done)
        the other thread which is blocked  |
        and the list is still valid on     |
        it's stack.)
    
    Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
    eventual sleeps.
    Unfortunately we could not reproduce the lockup and confirm this fix but
    based on the code review I think this fix should address such lockups.
    
    crash> bc 31
    PID: 747      TASK: ff1c6a1a007e8000  CPU: 31   COMMAND: "kworker/u72:2"
    --
        [exception RIP: ipoib_mcast_join_task+0x1b1]
        RIP: ffffffffc0944ac1  RSP: ff646f199a8c7e00  RFLAGS: 00000002
        RAX: 0000000000000000  RBX: ff1c6a1a04dc82f8  RCX: 0000000000000000
                                      work (&priv->mcast_task{,.work})
        RDX: ff1c6a192d60ac68  RSI: 0000000000000286  RDI: ff1c6a1a04dc8000
               &mcast->list
        RBP: ff646f199a8c7e90   R8: ff1c699980019420   R9: ff1c6a1920c9a000
        R10: ff646f199a8c7e00  R11: ff1c6a191a7d9800  R12: ff1c6a192d60ac00
                                                             mcast
        R13: ff1c6a1d82200000  R14: ff1c6a1a04dc8000  R15: ff1c6a1a04dc82d8
               dev                    priv (&priv->lock)     &priv->multicast_list (aka head)
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: accel: bma400: Fix a compilation problem [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Jan 31 16:52:46 2024 -0600

    iio: accel: bma400: Fix a compilation problem
    
    commit 4cb81840d8f29b66d9d05c6d7f360c9560f7e2f4 upstream.
    
    The kernel fails when compiling without `CONFIG_REGMAP_I2C` but with
    `CONFIG_BMA400`.
    ```
    ld: drivers/iio/accel/bma400_i2c.o: in function `bma400_i2c_probe':
    bma400_i2c.c:(.text+0x23): undefined reference to `__devm_regmap_init_i2c'
    ```
    
    Link: https://download.01.org/0day-ci/archive/20240131/202401311634.FE5CBVwe-lkp@intel.com/config
    Fixes: 465c811f1f20 ("iio: accel: Add driver for the BMA400")
    Fixes: 9bea10642396 ("iio: accel: bma400: add support for bma400 spi")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20240131225246.14169-1-mario.limonciello@amd.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: adc: ad7091r: Allow users to configure device events [+ + +]
Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
Date:   Tue Dec 19 17:26:01 2023 -0300

    iio: adc: ad7091r: Allow users to configure device events
    
    [ Upstream commit 020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f ]
    
    AD7091R-5 devices are supported by the ad7091r-5 driver together with
    the ad7091r-base driver. Those drivers declared iio events for notifying
    user space when ADC readings fall bellow the thresholds of low limit
    registers or above the values set in high limit registers.
    However, to configure iio events and their thresholds, a set of callback
    functions must be implemented and those were not present until now.
    The consequence of trying to configure ad7091r-5 events without the
    proper callback functions was a null pointer dereference in the kernel
    because the pointers to the callback functions were not set.
    
    Implement event configuration callbacks allowing users to read/write
    event thresholds and enable/disable event generation.
    
    Since the event spec structs are generic to AD7091R devices, also move
    those from the ad7091r-5 driver the base driver so they can be reused
    when support for ad7091r-2/-4/-8 be added.
    
    Fixes: ca69300173b6 ("iio: adc: Add support for AD7091R5 ADC")
    Suggested-by: David Lechner <dlechner@baylibre.com>
    Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
    Link: https://lore.kernel.org/r/59552d3548dabd56adc3107b7b4869afee2b0c3c.1703013352.git.marcelo.schmitt1@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: ad7091r: Enable internal vref if external vref is not supplied [+ + +]
Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
Date:   Tue Dec 19 17:26:27 2023 -0300

    iio: adc: ad7091r: Enable internal vref if external vref is not supplied
    
    [ Upstream commit e71c5c89bcb165a02df35325aa13d1ee40112401 ]
    
    The ADC needs a voltage reference to work correctly.
    Users can provide an external voltage reference or use the chip internal
    reference to operate the ADC.
    The availability of an in chip reference for the ADC saves the user from
    having to supply an external voltage reference, which makes the external
    reference an optional property as described in the device tree
    documentation.
    Though, to use the internal reference, it must be enabled by writing to
    the configuration register.
    Enable AD7091R internal voltage reference if no external vref is supplied.
    
    Fixes: 260442cc5be4 ("iio: adc: ad7091r5: Add scale and external VREF support")
    Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
    Link: https://lore.kernel.org/r/b865033fa6a4fc4bf2b4a98ec51a6144e0f64f77.1703013352.git.marcelo.schmitt1@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: ad7091r: Set alert bit in config register [+ + +]
Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
Date:   Sat Dec 16 14:46:37 2023 -0300

    iio: adc: ad7091r: Set alert bit in config register
    
    [ Upstream commit 149694f5e79b0c7a36ceb76e7c0d590db8f151c1 ]
    
    The ad7091r-base driver sets up an interrupt handler for firing events
    when inputs are either above or below a certain threshold.
    However, for the interrupt signal to come from the device it must be
    configured to enable the ALERT/BUSY/GPO pin to be used as ALERT, which
    was not being done until now.
    Enable interrupt signals on the ALERT/BUSY/GPO pin by setting the proper
    bit in the configuration register.
    
    Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
    Link: https://lore.kernel.org/r/e8da2ee98d6df88318b14baf3dc9630e20218418.1702746240.git.marcelo.schmitt1@gmail.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 020e71c7ffc2 ("iio: adc: ad7091r: Allow users to configure device events")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: core: fix memleak in iio_device_register_sysfs [+ + +]
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Fri Dec 8 15:31:19 2023 +0800

    iio: core: fix memleak in iio_device_register_sysfs
    
    commit 95a0d596bbd0552a78e13ced43f2be1038883c81 upstream.
    
    When iio_device_register_sysfs_group() fails, we should
    free iio_dev_opaque->chan_attr_group.attrs to prevent
    potential memleak.
    
    Fixes: 32f171724e5c ("iio: core: rework iio device group creation")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Link: https://lore.kernel.org/r/20231208073119.29283-1-dinghao.liu@zju.edu.cn
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: hid-sensor-als: Return 0 for HID_USAGE_SENSOR_TIME_TIMESTAMP [+ + +]
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Sun Feb 4 04:56:17 2024 -0800

    iio: hid-sensor-als: Return 0 for HID_USAGE_SENSOR_TIME_TIMESTAMP
    
    commit 621c6257128149e45b36ffb973a01c3f3461b893 upstream.
    
    When als_capture_sample() is called with usage ID
    HID_USAGE_SENSOR_TIME_TIMESTAMP, return 0. The HID sensor core ignores
    the return value for capture_sample() callback, so return value doesn't
    make difference. But correct the return value to return success instead
    of -EINVAL.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Link: https://lore.kernel.org/r/20240204125617.2635574-1-srinivas.pandruvada@linux.intel.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC [+ + +]
Author: zhili.liu <zhili.liu@ucas.com.cn>
Date:   Tue Jan 2 09:07:11 2024 +0800

    iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC
    
    commit 792595bab4925aa06532a14dd256db523eb4fa5e upstream.
    
    Recently, we encounter kernel crash in function rm3100_common_probe
    caused by out of bound access of array rm3100_samp_rates (because of
    underlying hardware failures). Add boundary check to prevent out of
    bound access.
    
    Fixes: 121354b2eceb ("iio: magnetometer: Add driver support for PNI RM3100")
    Suggested-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
    Signed-off-by: zhili.liu <zhili.liu@ucas.com.cn>
    Link: https://lore.kernel.org/r/1704157631-3814-1-git-send-email-zhouzhouyi@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: iio:adc:ad7091r: Move exports into IIO_AD7091R namespace. [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Jan 30 20:56:47 2022 +0000

    iio:adc:ad7091r: Move exports into IIO_AD7091R namespace.
    
    commit 8a0080af84d3fb2423f0b3b55eff666f545eb097 upstream.
    
    In order to avoid unnecessary pollution of the global symbol namespace
    move the core/library functions into a specific namespace and import
    that into the various specific device drivers that use them.
    
    For more information see https://lwn.net/Articles/760045/
    
    An alternative here would be to conclude that we are unlikely to see
    support for the other ad7091r parts in the near future and just merge
    the two modules into one supporting just the i2c -5 variant.
    
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Paul Cercueil <paul@crapouillou.net>
    Reviewed-by: Paul Cercueil <paul@crapouillou.net>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20220130205701.334592-3-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
inet: read sk->sk_family once in inet_recv_error() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 2 09:54:04 2024 +0000

    inet: read sk->sk_family once in inet_recv_error()
    
    [ Upstream commit eef00a82c568944f113f2de738156ac591bbd5cd ]
    
    inet_recv_error() is called without holding the socket lock.
    
    IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
    socket option and trigger a KCSAN warning.
    
    Fixes: f4713a3dfad0 ("net-timestamp: make tcp_recvmsg call ipv6_recv_error for AF_INET6 socks")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Jan 26 17:07:23 2024 +0100

    Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID
    
    commit 683cd8259a9b883a51973511f860976db2550a6e upstream.
    
    After commit 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in
    translated mode") the keyboard on Dell XPS 13 9350 / 9360 / 9370 models
    has stopped working after a suspend/resume.
    
    The problem appears to be that atkbd_probe() fails when called
    from atkbd_reconnect() on resume, which on systems where
    ATKBD_CMD_GETID is skipped can only happen by ATKBD_CMD_SETLEDS
    failing. ATKBD_CMD_SETLEDS failing because ATKBD_CMD_GETID was
    skipped is weird, but apparently that is what is happening.
    
    Fix this by also skipping ATKBD_CMD_SETLEDS when skipping
    ATKBD_CMD_GETID.
    
    Fixes: 936e4d49ecbc ("Input: atkbd - skip ATKBD_CMD_GETID in translated mode")
    Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Closes: https://lore.kernel.org/linux-input/0aa4a61f-c939-46fe-a572-08022e8931c7@molgen.mpg.de/
    Closes: https://bbs.archlinux.org/viewtopic.php?pid=2146300
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218424
    Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2260517
    Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240126160724.13278-2-hdegoede@redhat.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: i8042 - fix strange behavior of touchpad on Clevo NS70PU [+ + +]
Author: Werner Sembach <wse@tuxedocomputers.com>
Date:   Tue Dec 5 17:36:01 2023 +0100

    Input: i8042 - fix strange behavior of touchpad on Clevo NS70PU
    
    commit a60e6c3918d20848906ffcdfcf72ca6a8cfbcf2e upstream.
    
    When closing the laptop lid with an external screen connected, the mouse
    pointer has a constant movement to the lower right corner. Opening the
    lid again stops this movement, but after that the touchpad does no longer
    register clicks.
    
    The touchpad is connected both via i2c-hid and PS/2, the predecessor of
    this device (NS70MU) has the same layout in this regard and also strange
    behaviour caused by the psmouse and the i2c-hid driver fighting over
    touchpad control. This fix is reusing the same workaround by just
    disabling the PS/2 aux port, that is only used by the touchpad, to give the
    i2c-hid driver the lone control over the touchpad.
    
    v2: Rebased on current master
    
    Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231205163602.16106-1-wse@tuxedocomputers.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ionic: pass opcode to devcmd_wait [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Mon Dec 11 10:57:57 2023 -0800

    ionic: pass opcode to devcmd_wait
    
    [ Upstream commit 24f110240c03c6b5368f1203bac72883d511e606 ]
    
    Don't rely on the PCI memory for the devcmd opcode because we
    read a 0xff value if the PCI bus is broken, which can cause us
    to report a bogus dev_cmd opcode later.
    
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Reviewed-by: Brett Creeley <brett.creeley@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jan 25 17:05:57 2024 +0000

    ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
    
    [ Upstream commit 8d975c15c0cd744000ca386247432d57b21f9df0 ]
    
    syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
    
    Call pskb_inet_may_pull() to fix this, and initialize ipv6h
    variable after this call as it can change skb->head.
    
    [1]
     BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
     BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
     BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
      __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
      INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
      IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
      ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727
      __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845
      ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888
     gre_rcv+0x143f/0x1870
      ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
      ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
      ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
      dst_input include/net/dst.h:461 [inline]
      ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5532 [inline]
      __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646
      netif_receive_skb_internal net/core/dev.c:5732 [inline]
      netif_receive_skb+0x58/0x660 net/core/dev.c:5791
      tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
      tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
      call_write_iter include/linux/fs.h:2084 [inline]
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0x786/0x1200 fs/read_write.c:590
      ksys_write+0x20f/0x4c0 fs/read_write.c:643
      __do_sys_write fs/read_write.c:655 [inline]
      __se_sys_write fs/read_write.c:652 [inline]
      __x64_sys_write+0x93/0xd0 fs/read_write.c:652
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Uninit was created at:
      slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
      slab_alloc_node mm/slub.c:3478 [inline]
      kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
      kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
      __alloc_skb+0x318/0x740 net/core/skbuff.c:651
      alloc_skb include/linux/skbuff.h:1286 [inline]
      alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
      sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
      tun_alloc_skb drivers/net/tun.c:1531 [inline]
      tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
      call_write_iter include/linux/fs.h:2084 [inline]
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0x786/0x1200 fs/read_write.c:590
      ksys_write+0x20f/0x4c0 fs/read_write.c:643
      __do_sys_write fs/read_write.c:655 [inline]
      __se_sys_write fs/read_write.c:652 [inline]
      __x64_sys_write+0x93/0xd0 fs/read_write.c:652
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    
    Fixes: 0d3c703a9d17 ("ipv6: Cleanup IPv6 tunnel receive path")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240125170557.2663942-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ip6_tunnel: use dev_sw_netstats_rx_add() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jun 8 08:46:35 2022 -0700

    ip6_tunnel: use dev_sw_netstats_rx_add()
    
    [ Upstream commit afd2051b18404640a116fd3bb2460da214ccbda4 ]
    
    We have a convenient helper, let's use it.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: Ensure natural alignment of const ipv6 loopback and router addresses [+ + +]
Author: Helge Deller <deller@kernel.org>
Date:   Fri Jan 26 09:32:20 2024 +0100

    ipv6: Ensure natural alignment of const ipv6 loopback and router addresses
    
    [ Upstream commit 60365049ccbacd101654a66ddcb299abfabd4fc5 ]
    
    On a parisc64 kernel I sometimes notice this kernel warning:
    Kernel unaligned access to 0x40ff8814 at ndisc_send_skb+0xc0/0x4d8
    
    The address 0x40ff8814 points to the in6addr_linklocal_allrouters
    variable and the warning simply means that some ipv6 function tries to
    read a 64-bit word directly from the not-64-bit aligned
    in6addr_linklocal_allrouters variable.
    
    Unaligned accesses are non-critical as the architecture or exception
    handlers usually will fix it up at runtime. Nevertheless it may trigger
    a performance penality for some architectures. For details read the
    "unaligned-memory-access" kernel documentation.
    
    The patch below ensures that the ipv6 loopback and router addresses will
    always be naturally aligned. This prevents the unaligned accesses for
    all architectures.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Fixes: 034dfc5df99eb ("ipv6: export in6addr_loopback to modules")
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/ZbNuFM1bFqoH-UoY@p100
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: init the accept_queue's spinlocks in inet6_create [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Mon Jan 22 18:20:01 2024 +0800

    ipv6: init the accept_queue's spinlocks in inet6_create
    
    [ Upstream commit 435e202d645c197dcfd39d7372eb2a56529b6640 ]
    
    In commit 198bc90e0e73("tcp: make sure init the accept_queue's spinlocks
    once"), the spinlocks of accept_queue are initialized only when socket is
    created in the inet4 scenario. The locks are not initialized when socket
    is created in the inet6 scenario. The kernel reports the following error:
    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.
    Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    Call Trace:
    <TASK>
            dump_stack_lvl (lib/dump_stack.c:107)
            register_lock_class (kernel/locking/lockdep.c:1289)
            __lock_acquire (kernel/locking/lockdep.c:5015)
            lock_acquire.part.0 (kernel/locking/lockdep.c:5756)
            _raw_spin_lock_bh (kernel/locking/spinlock.c:178)
            inet_csk_listen_stop (net/ipv4/inet_connection_sock.c:1386)
            tcp_disconnect (net/ipv4/tcp.c:2981)
            inet_shutdown (net/ipv4/af_inet.c:935)
            __sys_shutdown (./include/linux/file.h:32 net/socket.c:2438)
            __x64_sys_shutdown (net/socket.c:2445)
            do_syscall_64 (arch/x86/entry/common.c:52)
            entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
    RIP: 0033:0x7f52ecd05a3d
    Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 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 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
    RSP: 002b:00007f52ecf5dde8 EFLAGS: 00000293 ORIG_RAX: 0000000000000030
    RAX: ffffffffffffffda RBX: 00007f52ecf5e640 RCX: 00007f52ecd05a3d
    RDX: 00007f52ecc8b188 RSI: 0000000000000000 RDI: 0000000000000004
    RBP: 00007f52ecf5de20 R08: 00007ffdae45c69f R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000293 R12: 00007f52ecf5e640
    R13: 0000000000000000 R14: 00007f52ecc8b060 R15: 00007ffdae45c6e0
    
    Fixes: 198bc90e0e73 ("tcp: make sure init the accept_queue's spinlocks once")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240122102001.2851701-1-shaozhengchao@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/gic-v3-its: Fix GICv4.1 VPE affinity update [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Feb 13 10:12:06 2024 +0000

    irqchip/gic-v3-its: Fix GICv4.1 VPE affinity update
    
    commit af9acbfc2c4b72c378d0b9a2ee023ed01055d3e2 upstream.
    
    When updating the affinity of a VPE, the VMOVP command is currently skipped
    if the two CPUs are part of the same VPE affinity.
    
    But this is wrong, as the doorbell corresponding to this VPE is still
    delivered on the 'old' CPU, which screws up the balancing.  Furthermore,
    offlining that 'old' CPU results in doorbell interrupts generated for this
    VPE being discarded.
    
    The harsh reality is that VMOVP cannot be elided when a set_affinity()
    request occurs. It needs to be obeyed, and if an optimisation is to be
    made, it is at the point where the affinity change request is made (such as
    in KVM).
    
    Drop the VMOVP elision altogether, and only use the vpe_table_mask
    to try and stay within the same ITS affinity group if at all possible.
    
    Fixes: dd3f050a216e (irqchip/gic-v4.1: Implement the v4.1 flavour of VMOVP)
    Reported-by: Kunkun Jiang <jiangkunkun@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240213101206.2137483-4-maz@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
irqchip/irq-brcmstb-l2: Add write memory barrier before exit [+ + +]
Author: Doug Berger <opendmb@gmail.com>
Date:   Fri Feb 9 17:24:49 2024 -0800

    irqchip/irq-brcmstb-l2: Add write memory barrier before exit
    
    commit b0344d6854d25a8b3b901c778b1728885dd99007 upstream.
    
    It was observed on Broadcom devices that use GIC v3 architecture L1
    interrupt controllers as the parent of brcmstb-l2 interrupt controllers
    that the deactivation of the parent interrupt could happen before the
    brcmstb-l2 deasserted its output. This would lead the GIC to reactivate the
    interrupt only to find that no L2 interrupt was pending. The result was a
    spurious interrupt invoking handle_bad_irq() with its associated
    messaging. While this did not create a functional problem it is a waste of
    cycles.
    
    The hazard exists because the memory mapped bus writes to the brcmstb-l2
    registers are buffered and the GIC v3 architecture uses a very efficient
    system register write to deactivate the interrupt.
    
    Add a write memory barrier prior to invoking chained_irq_exit() to
    introduce a dsb(st) on those systems to ensure the system register write
    cannot be executed until the memory mapped writes are visible to the
    system.
    
    [ florian: Added Fixes tag ]
    
    Fixes: 7f646e92766e ("irqchip: brcmstb-l2: Add Broadcom Set Top Box  Level-2 interrupt controller")
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240210012449.3009125-1-florian.fainelli@broadcom.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ixgbe: Fix an error handling path in ixgbe_read_iosf_sb_reg_x550() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jan 20 18:25:36 2024 +0100

    ixgbe: Fix an error handling path in ixgbe_read_iosf_sb_reg_x550()
    
    [ Upstream commit bbc404d20d1b46d89b461918bc44587620eda200 ]
    
    All error handling paths, except this one, go to 'out' where
    release_swfw_sync() is called.
    This call balances the acquire_swfw_sync() call done at the beginning of
    the function.
    
    Branch to the error handling path in order to correctly release some
    resources in case of error.
    
    Fixes: ae14a1d8e104 ("ixgbe: Fix IOSF SB access issues")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ixgbe: Refactor overtemp event handling [+ + +]
Author: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Date:   Mon Dec 18 11:39:25 2023 +0100

    ixgbe: Refactor overtemp event handling
    
    [ Upstream commit 6c1b4af8c1b20c70dde01e58381685d6a4a1d2c8 ]
    
    Currently ixgbe driver is notified of overheating events
    via internal IXGBE_ERR_OVERTEMP error code.
    
    Change the approach for handle_lasi() to use freshly introduced
    is_overtemp function parameter which set when such event occurs.
    Change check_overtemp() to bool and return true if overtemp
    event occurs.
    
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ixgbe: Refactor returning internal error codes [+ + +]
Author: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Date:   Mon Dec 18 11:39:26 2023 +0100

    ixgbe: Refactor returning internal error codes
    
    [ Upstream commit 5795f533f30a80aa0473652876296ebc9129e33a ]
    
    Change returning codes to the kernel ones instead of
    the internal ones for the entire ixgbe driver.
    
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
    Tested-by: Sunitha Mekala <sunithax.d.mekala@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Stable-dep-of: bbc404d20d1b ("ixgbe: Fix an error handling path in ixgbe_read_iosf_sb_reg_x550()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ixgbe: Remove non-inclusive language [+ + +]
Author: Piotr Skajewski <piotrx.skajewski@intel.com>
Date:   Tue Jan 11 11:27:23 2022 +0100

    ixgbe: Remove non-inclusive language
    
    [ Upstream commit 93b067f154b3edfd3d75a272fd9433bf787e2e1d ]
    
    Remove non-inclusive language from the driver.
    
    Additionally correct the duplication "from from"
    reported by checkpatch after the changes above.
    
    Signed-off-by: Piotr Skajewski <piotrx.skajewski@intel.com>
    Tested-by: Dave Switzer <david.switzer@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Stable-dep-of: bbc404d20d1b ("ixgbe: Fix an error handling path in ixgbe_read_iosf_sb_reg_x550()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jfs: fix array-index-out-of-bounds in dbAdjTree [+ + +]
Author: Manas Ghandat <ghandatmanas@gmail.com>
Date:   Tue Oct 17 17:33:56 2023 +0530

    jfs: fix array-index-out-of-bounds in dbAdjTree
    
    [ Upstream commit 74ecdda68242b174920fe7c6133a856fb7d8559b ]
    
    Currently there is a bound check missing in the dbAdjTree while
    accessing the dmt_stree. To add the required check added the bool is_ctl
    which is required to determine the size as suggest in the following
    commit.
    https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/
    
    Reported-by: syzbot+39ba34a099ac2e9bd3cb@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=39ba34a099ac2e9bd3cb
    Signed-off-by: Manas Ghandat <ghandatmanas@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

jfs: fix array-index-out-of-bounds in diNewExt [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Tue Dec 12 09:36:22 2023 +0800

    jfs: fix array-index-out-of-bounds in diNewExt
    
    [ Upstream commit 49f9637aafa6e63ba686c13cb8549bf5e6920402 ]
    
    [Syz report]
    UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2
    index -878706688 is out of range for type 'struct iagctl[128]'
    CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
     ubsan_epilogue lib/ubsan.c:217 [inline]
     __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
     diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360
     diAllocExt fs/jfs/jfs_imap.c:1949 [inline]
     diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666
     diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587
     ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56
     jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225
     vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106
     do_mkdirat+0x264/0x3a0 fs/namei.c:4129
     __do_sys_mkdir fs/namei.c:4149 [inline]
     __se_sys_mkdir fs/namei.c:4147 [inline]
     __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    RIP: 0033:0x7fcb7e6a0b57
    Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 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:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053
    RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57
    RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140
    RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    
    [Analysis]
    When the agstart is too large, it can cause agno overflow.
    
    [Fix]
    After obtaining agno, if the value is invalid, exit the subsequent process.
    
    Reported-and-tested-by: syzbot+553d90297e6d2f50dbc7@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    
    Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next
    report by kernel test robot (Dan Carpenter).
    
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

jfs: fix slab-out-of-bounds Read in dtSearch [+ + +]
Author: Manas Ghandat <ghandatmanas@gmail.com>
Date:   Wed Oct 25 11:39:07 2023 +0530

    jfs: fix slab-out-of-bounds Read in dtSearch
    
    [ Upstream commit fa5492ee89463a7590a1449358002ff7ef63529f ]
    
    Currently while searching for current page in the sorted entry table
    of the page there is a out of bound access. Added a bound check to fix
    the error.
    
    Dave:
    Set return code to -EIO
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/r/202310241724.Ed02yUz9-lkp@intel.com/
    Signed-off-by: Manas Ghandat <ghandatmanas@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

jfs: fix uaf in jfs_evict_inode [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Tue Oct 31 13:39:04 2023 +0800

    jfs: fix uaf in jfs_evict_inode
    
    [ Upstream commit e0e1958f4c365e380b17ccb35617345b31ef7bf3 ]
    
    When the execution of diMount(ipimap) fails, the object ipimap that has been
    released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs
    when rcu_core() calls jfs_free_node().
    
    Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as
    ipimap.
    
    Reported-and-tested-by: syzbot+01cf2dbcbe2022454388@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kbuild: Fix changing ELF file type for output of gen_btf for big endian [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Feb 12 19:05:10 2024 -0700

    kbuild: Fix changing ELF file type for output of gen_btf for big endian
    
    commit e3a9ee963ad8ba677ca925149812c5932b49af69 upstream.
    
    Commit 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
    changed the ELF type of .btf.vmlinux.bin.o to ET_REL via dd, which works
    fine for little endian platforms:
    
       00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
      -00000010  03 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|
      +00000010  01 00 b7 00 01 00 00 00  00 00 00 80 00 80 ff ff  |................|
    
    However, for big endian platforms, it changes the wrong byte, resulting
    in an invalid ELF file type, which ld.lld rejects:
    
       00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
      -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
      +00000010  01 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
    
      Type:                              <unknown>: 103
    
      ld.lld: error: .btf.vmlinux.bin.o: unknown file type
    
    Fix this by updating the entire 16-bit e_type field rather than just a
    single byte, so that everything works correctly for all platforms and
    linkers.
    
       00000000  7f 45 4c 46 02 02 01 00  00 00 00 00 00 00 00 00  |.ELF............|
      -00000010  00 03 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
      +00000010  00 01 00 16 00 00 00 01  00 00 00 00 00 10 00 00  |................|
    
      Type:                              REL (Relocatable file)
    
    While in the area, update the comment to mention that binutils 2.35+
    matches LLD's behavior of rejecting an ET_EXEC input, which occurred
    after the comment was added.
    
    Cc: stable@vger.kernel.org
    Fixes: 90ceddcb4950 ("bpf: Support llvm-objcopy for vmlinux BTF")
    Link: https://github.com/llvm/llvm-project/pull/75643
    Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Fangrui Song <maskray@google.com>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Justin Stitt <justinstitt@google.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    [nathan: Fix silent conflict due to lack of 7d153696e5db in older trees]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ksmbd: Add missing set_freezable() for freezable kthread [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Jan 21 23:30:35 2024 +0900

    ksmbd: Add missing set_freezable() for freezable kthread
    
    From: Kevin Hao <haokexin@gmail.com>
    
    [ Upstream commit 8fb7b723924cc9306bc161f45496497aec733904 ]
    
    The kernel thread function ksmbd_conn_handler_loop() invokes
    the try_to_freeze() in its loop. But all the kernel threads are
    non-freezable by default. So if we want to make a kernel thread to be
    freezable, we have to invoke set_freezable() explicitly.
    
    Signed-off-by: Kevin Hao <haokexin@gmail.com>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: don't allow O_TRUNC open on read-only share [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Jan 7 21:24:07 2024 +0900

    ksmbd: don't allow O_TRUNC open on read-only share
    
    [ Upstream commit d592a9158a112d419f341f035d18d02f8d232def ]
    
    When file is changed using notepad on read-only share(read_only = yes in
    ksmbd.conf), There is a problem where existing data is truncated.
    notepad in windows try to O_TRUNC open(FILE_OVERWRITE_IF) and all data
    in file is truncated. This patch don't allow  O_TRUNC open on read-only
    share and add KSMBD_TREE_CONN_FLAG_WRITABLE check in smb2_set_info().
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: don't increment epoch if current state and request state are same [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Jan 21 23:30:31 2024 +0900

    ksmbd: don't increment epoch if current state and request state are same
    
    [ Upstream commit b6e9a44e99603fe10e1d78901fdd97681a539612 ]
    
    If existing lease state and request state are same, don't increment
    epoch in create context.
    
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: fix global oob in ksmbd_nl_policy [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Sun Jan 21 15:35:06 2024 +0800

    ksmbd: fix global oob in ksmbd_nl_policy
    
    [ Upstream commit ebeae8adf89d9a82359f6659b1663d09beec2faa ]
    
    Similar to a reported issue (check the commit b33fb5b801c6 ("net:
    qualcomm: rmnet: fix global oob in rmnet_policy"), my local fuzzer finds
    another global out-of-bounds read for policy ksmbd_nl_policy. See bug
    trace below:
    
    ==================================================================
    BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
    BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
    Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810
    
    CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G                 N 6.1.0 #3
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:284 [inline]
     print_report+0x172/0x475 mm/kasan/report.c:395
     kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
     validate_nla lib/nlattr.c:386 [inline]
     __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
     __nla_parse+0x3e/0x50 lib/nlattr.c:697
     __nlmsg_parse include/net/netlink.h:748 [inline]
     genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565
     genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734
     genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]
     genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850
     netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
     genl_rcv+0x24/0x40 net/netlink/genetlink.c:861
     netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
     netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
     netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg+0x154/0x190 net/socket.c:734
     ____sys_sendmsg+0x6df/0x840 net/socket.c:2482
     ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
     __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7fdd66a8f359
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359
    RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003
    RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000
     </TASK>
    
    The buggy address belongs to the variable:
     ksmbd_nl_policy+0x100/0xa80
    
    The buggy address belongs to the physical page:
    page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b
    flags: 0x200000000001000(reserved|node=0|zone=2)
    raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000
    raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9
                       ^
     ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05
     ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9
    ==================================================================
    
    To fix it, add a placeholder named __KSMBD_EVENT_MAX and let
    KSMBD_EVENT_MAX to be its original value - 1 according to what other
    netlink families do. Also change two sites that refer the
    KSMBD_EVENT_MAX to correct value.
    
    Cc: stable@vger.kernel.org
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: fix potential circular locking issue in smb2_set_ea() [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Jan 21 23:30:30 2024 +0900

    ksmbd: fix potential circular locking issue in smb2_set_ea()
    
    [ Upstream commit 6fc0a265e1b932e5e97a038f99e29400a93baad0 ]
    
    smb2_set_ea() can be called in parent inode lock range.
    So add get_write argument to smb2_set_ea() not to call nested
    mnt_want_write().
    
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: fix UAF issue in ksmbd_tcp_new_connection() [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sat Jan 13 15:30:07 2024 +0900

    ksmbd: fix UAF issue in ksmbd_tcp_new_connection()
    
    [ Upstream commit 38d20c62903d669693a1869aa68c4dd5674e2544 ]
    
    The race is between the handling of a new TCP connection and
    its disconnection. It leads to UAF on `struct tcp_transport` in
    ksmbd_tcp_new_connection() function.
    
    Cc: stable@vger.kernel.org
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-22991
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: free ppace array on error in parse_dacl [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Tue Jan 9 17:14:44 2024 +0300

    ksmbd: free ppace array on error in parse_dacl
    
    [ Upstream commit 8cf9bedfc3c47d24bb0de386f808f925dc52863e ]
    
    The ppace array is not freed if one of the init_acl_state() calls inside
    parse_dacl() fails. At the moment the function may fail only due to the
    memory allocation errors so it's highly unlikely in this case but
    nevertheless a fix is needed.
    
    Move ppace allocation after the init_acl_state() calls with proper error
    handling.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Cc: stable@vger.kernel.org
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
ksmbd: only v2 leases handle the directory [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Mon Jan 15 10:24:54 2024 +0900

    ksmbd: only v2 leases handle the directory
    
    [ Upstream commit 77bebd186442a7d703b796784db7495129cc3e70 ]
    
    When smb2 leases is disable, ksmbd can send oplock break notification
    and cause wait oplock break ack timeout. It may appear like hang when
    accessing a directory. This patch make only v2 leases handle the
    directory.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: send lease break notification on FILE_RENAME_INFORMATION [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Jan 21 23:30:33 2024 +0900

    ksmbd: send lease break notification on FILE_RENAME_INFORMATION
    
    [ Upstream commit 3fc74c65b367476874da5fe6f633398674b78e5a ]
    
    Send lease break notification on FILE_RENAME_INFORMATION request.
    This patch fix smb2.lease.v2_epoch2 test failure.
    
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: set v2 lease version on lease upgrade [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sun Jan 21 23:30:29 2024 +0900

    ksmbd: set v2 lease version on lease upgrade
    
    [ Upstream commit bb05367a66a9990d2c561282f5620bb1dbe40c28 ]
    
    If file opened with v2 lease is upgraded with v1 lease, smb server
    should response v2 lease create context to client.
    This patch fix smb2.lease.v2_epoch2 test failure.
    
    This test case assumes the following scenario:
     1. smb2 create with v2 lease(R, LEASE1 key)
     2. smb server return smb2 create response with v2 lease context(R,
    LEASE1 key, epoch + 1)
     3. smb2 create with v1 lease(RH, LEASE1 key)
     4. smb server return smb2 create response with v2 lease context(RH,
    LEASE1 key, epoch + 2)
    
    i.e. If same client(same lease key) try to open a file that is being
    opened with v2 lease with v1 lease, smb server should return v2 lease.
    
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Acked-by: Tom Talpey <tom@talpey.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: validate mech token in session setup [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sat Jan 13 15:11:41 2024 +0900

    ksmbd: validate mech token in session setup
    
    [ Upstream commit 92e470163d96df8db6c4fa0f484e4a229edb903d ]
    
    If client send invalid mech token in session setup request, ksmbd
    validate and make the error if it is invalid.
    
    Cc: stable@vger.kernel.org
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-22890
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: s390: fix setting of fpc register [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Thu Nov 30 18:56:00 2023 +0100

    KVM: s390: fix setting of fpc register
    
    [ Upstream commit b988b1bb0053c0dcd26187d29ef07566a565cf55 ]
    
    kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control
    (fpc) register of a guest cpu. The new value is tested for validity by
    temporarily loading it into the fpc register.
    
    This may lead to corruption of the fpc register of the host process:
    if an interrupt happens while the value is temporarily loaded into the fpc
    register, and within interrupt context floating point or vector registers
    are used, the current fp/vx registers are saved with save_fpu_regs()
    assuming they belong to user space and will be loaded into fp/vx registers
    when returning to user space.
    
    test_fp_ctl() restores the original user space / host process fpc register
    value, however it will be discarded, when returning to user space.
    
    In result the host process will incorrectly continue to run with the value
    that was supposed to be used for a guest cpu.
    
    Fix this by simply removing the test. There is another test right before
    the SIE context is entered which will handles invalid values.
    
    This results in a change of behaviour: invalid values will now be accepted
    instead of that the ioctl fails with -EINVAL. This seems to be acceptable,
    given that this interface is most likely not used anymore, and this is in
    addition the same behaviour implemented with the memory mapped interface
    (replace invalid values with zero) - see sync_regs() in kvm-s390.c.
    
    Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
leds: trigger: panic: Don't register panic notifier if creating the trigger failed [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sat Dec 16 21:05:33 2023 +0100

    leds: trigger: panic: Don't register panic notifier if creating the trigger failed
    
    [ Upstream commit afacb21834bb02785ddb0c3ec197208803b74faa ]
    
    It doesn't make sense to register the panic notifier if creating the
    panic trigger failed.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/8a61e229-5388-46c7-919a-4d18cc7362b2@gmail.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libbpf: Fix NULL pointer dereference in bpf_object__collect_prog_relos [+ + +]
Author: Mingyi Zhang <zhangmingyi5@huawei.com>
Date:   Thu Dec 21 11:39:47 2023 +0800

    libbpf: Fix NULL pointer dereference in bpf_object__collect_prog_relos
    
    [ Upstream commit fc3a5534e2a8855427403113cbeb54af5837bbe0 ]
    
    An issue occurred while reading an ELF file in libbpf.c during fuzzing:
    
            Program received signal SIGSEGV, Segmentation fault.
            0x0000000000958e97 in bpf_object.collect_prog_relos () at libbpf.c:4206
            4206 in libbpf.c
            (gdb) bt
            #0 0x0000000000958e97 in bpf_object.collect_prog_relos () at libbpf.c:4206
            #1 0x000000000094f9d6 in bpf_object.collect_relos () at libbpf.c:6706
            #2 0x000000000092bef3 in bpf_object_open () at libbpf.c:7437
            #3 0x000000000092c046 in bpf_object.open_mem () at libbpf.c:7497
            #4 0x0000000000924afa in LLVMFuzzerTestOneInput () at fuzz/bpf-object-fuzzer.c:16
            #5 0x000000000060be11 in testblitz_engine::fuzzer::Fuzzer::run_one ()
            #6 0x000000000087ad92 in tracing::span::Span::in_scope ()
            #7 0x00000000006078aa in testblitz_engine::fuzzer::util::walkdir ()
            #8 0x00000000005f3217 in testblitz_engine::entrypoint::main::{{closure}} ()
            #9 0x00000000005f2601 in main ()
            (gdb)
    
    scn_data was null at this code(tools/lib/bpf/src/libbpf.c):
    
            if (rel->r_offset % BPF_INSN_SZ || rel->r_offset >= scn_data->d_size) {
    
    The scn_data is derived from the code above:
    
            scn = elf_sec_by_idx(obj, sec_idx);
            scn_data = elf_sec_data(obj, scn);
    
            relo_sec_name = elf_sec_str(obj, shdr->sh_name);
            sec_name = elf_sec_name(obj, scn);
            if (!relo_sec_name || !sec_name)// don't check whether scn_data is NULL
                    return -EINVAL;
    
    In certain special scenarios, such as reading a malformed ELF file,
    it is possible that scn_data may be a null pointer
    
    Signed-off-by: Mingyi Zhang <zhangmingyi5@huawei.com>
    Signed-off-by: Xin Liu <liuxin350@huawei.com>
    Signed-off-by: Changye Wu <wuchangye@huawei.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20231221033947.154564-1-liuxin350@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libsubcmd: Fix memory leak in uniq() [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu Dec 7 16:05:13 2023 -0800

    libsubcmd: Fix memory leak in uniq()
    
    [ Upstream commit ad30469a841b50dbb541df4d6971d891f703c297 ]
    
    uniq() will write one command name over another causing the overwritten
    string to be leaked. Fix by doing a pass that removes duplicates and a
    second that removes the holes.
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Chenyuan Mi <cymi20@fudan.edu.cn>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20231208000515.1693746-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.15.149 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Feb 23 08:55:16 2024 +0100

    Linux 5.15.149
    
    Link: https://lore.kernel.org/r/20240221130007.738356493@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
llc: call sock_orphan() at release time [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 26 16:55:32 2024 +0000

    llc: call sock_orphan() at release time
    
    [ Upstream commit aa2b2eb3934859904c287bf5434647ba72e14c1c ]
    
    syzbot reported an interesting trace [1] caused by a stale sk->sk_wq
    pointer in a closed llc socket.
    
    In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after
    calling proto_ops::release()") Eric Biggers hinted that some protocols
    are missing a sock_orphan(), we need to perform a full audit.
    
    In net-next, I plan to clear sock->sk from sock_orphan() and
    amend Eric patch to add a warning.
    
    [1]
     BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]
     BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
     BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]
     BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
    Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27
    
    CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
      print_address_description mm/kasan/report.c:377 [inline]
      print_report+0xc4/0x620 mm/kasan/report.c:488
      kasan_report+0xda/0x110 mm/kasan/report.c:601
      list_empty include/linux/list.h:373 [inline]
      waitqueue_active include/linux/wait.h:127 [inline]
      sock_def_write_space_wfree net/core/sock.c:3384 [inline]
      sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
      skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080
      skb_release_all net/core/skbuff.c:1092 [inline]
      napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404
      e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970
      e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]
      e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801
      __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576
      napi_poll net/core/dev.c:6645 [inline]
      net_rx_action+0x956/0xe90 net/core/dev.c:6778
      __do_softirq+0x21a/0x8de kernel/softirq.c:553
      run_ksoftirqd kernel/softirq.c:921 [inline]
      run_ksoftirqd+0x31/0x60 kernel/softirq.c:913
      smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164
      kthread+0x2c6/0x3a0 kernel/kthread.c:388
      ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
      ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
     </TASK>
    
    Allocated by task 5167:
      kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
      kasan_save_track+0x14/0x30 mm/kasan/common.c:68
      unpoison_slab_object mm/kasan/common.c:314 [inline]
      __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340
      kasan_slab_alloc include/linux/kasan.h:201 [inline]
      slab_post_alloc_hook mm/slub.c:3813 [inline]
      slab_alloc_node mm/slub.c:3860 [inline]
      kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879
      alloc_inode_sb include/linux/fs.h:3019 [inline]
      sock_alloc_inode+0x25/0x1c0 net/socket.c:308
      alloc_inode+0x5d/0x220 fs/inode.c:260
      new_inode_pseudo+0x16/0x80 fs/inode.c:1005
      sock_alloc+0x40/0x270 net/socket.c:634
      __sock_create+0xbc/0x800 net/socket.c:1535
      sock_create net/socket.c:1622 [inline]
      __sys_socket_create net/socket.c:1659 [inline]
      __sys_socket+0x14c/0x260 net/socket.c:1706
      __do_sys_socket net/socket.c:1720 [inline]
      __se_sys_socket net/socket.c:1718 [inline]
      __x64_sys_socket+0x72/0xb0 net/socket.c:1718
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Freed by task 0:
      kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
      kasan_save_track+0x14/0x30 mm/kasan/common.c:68
      kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
      poison_slab_object mm/kasan/common.c:241 [inline]
      __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257
      kasan_slab_free include/linux/kasan.h:184 [inline]
      slab_free_hook mm/slub.c:2121 [inline]
      slab_free mm/slub.c:4299 [inline]
      kmem_cache_free+0x129/0x350 mm/slub.c:4363
      i_callback+0x43/0x70 fs/inode.c:249
      rcu_do_batch kernel/rcu/tree.c:2158 [inline]
      rcu_core+0x819/0x1680 kernel/rcu/tree.c:2433
      __do_softirq+0x21a/0x8de kernel/softirq.c:553
    
    Last potentially related work creation:
      kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
      __kasan_record_aux_stack+0xba/0x100 mm/kasan/generic.c:586
      __call_rcu_common.constprop.0+0x9a/0x7b0 kernel/rcu/tree.c:2683
      destroy_inode+0x129/0x1b0 fs/inode.c:315
      iput_final fs/inode.c:1739 [inline]
      iput.part.0+0x560/0x7b0 fs/inode.c:1765
      iput+0x5c/0x80 fs/inode.c:1755
      dentry_unlink_inode+0x292/0x430 fs/dcache.c:400
      __dentry_kill+0x1ca/0x5f0 fs/dcache.c:603
      dput.part.0+0x4ac/0x9a0 fs/dcache.c:845
      dput+0x1f/0x30 fs/dcache.c:835
      __fput+0x3b9/0xb70 fs/file_table.c:384
      task_work_run+0x14d/0x240 kernel/task_work.c:180
      exit_task_work include/linux/task_work.h:38 [inline]
      do_exit+0xa8a/0x2ad0 kernel/exit.c:871
      do_group_exit+0xd4/0x2a0 kernel/exit.c:1020
      __do_sys_exit_group kernel/exit.c:1031 [inline]
      __se_sys_exit_group kernel/exit.c:1029 [inline]
      __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1029
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    The buggy address belongs to the object at ffff88802f4fc800
     which belongs to the cache sock_inode_cache of size 1408
    The buggy address is located 128 bytes inside of
     freed 1408-byte region [ffff88802f4fc800, ffff88802f4fcd80)
    
    The buggy address belongs to the physical page:
    page:ffffea0000bd3e00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2f4f8
    head:ffffea0000bd3e00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
    anon flags: 0xfff00000000840(slab|head|node=0|zone=1|lastcpupid=0x7ff)
    page_type: 0xffffffff()
    raw: 00fff00000000840 ffff888013b06b40 0000000000000000 0000000000000001
    raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 3, migratetype Reclaimable, gfp_mask 0xd20d0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_RECLAIMABLE), pid 4956, tgid 4956 (sshd), ts 31423924727, free_ts 0
      set_page_owner include/linux/page_owner.h:31 [inline]
      post_alloc_hook+0x2d0/0x350 mm/page_alloc.c:1533
      prep_new_page mm/page_alloc.c:1540 [inline]
      get_page_from_freelist+0xa28/0x3780 mm/page_alloc.c:3311
      __alloc_pages+0x22f/0x2440 mm/page_alloc.c:4567
      __alloc_pages_node include/linux/gfp.h:238 [inline]
      alloc_pages_node include/linux/gfp.h:261 [inline]
      alloc_slab_page mm/slub.c:2190 [inline]
      allocate_slab mm/slub.c:2354 [inline]
      new_slab+0xcc/0x3a0 mm/slub.c:2407
      ___slab_alloc+0x4af/0x19a0 mm/slub.c:3540
      __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3625
      __slab_alloc_node mm/slub.c:3678 [inline]
      slab_alloc_node mm/slub.c:3850 [inline]
      kmem_cache_alloc_lru+0x379/0x6f0 mm/slub.c:3879
      alloc_inode_sb include/linux/fs.h:3019 [inline]
      sock_alloc_inode+0x25/0x1c0 net/socket.c:308
      alloc_inode+0x5d/0x220 fs/inode.c:260
      new_inode_pseudo+0x16/0x80 fs/inode.c:1005
      sock_alloc+0x40/0x270 net/socket.c:634
      __sock_create+0xbc/0x800 net/socket.c:1535
      sock_create net/socket.c:1622 [inline]
      __sys_socket_create net/socket.c:1659 [inline]
      __sys_socket+0x14c/0x260 net/socket.c:1706
      __do_sys_socket net/socket.c:1720 [inline]
      __se_sys_socket net/socket.c:1718 [inline]
      __x64_sys_socket+0x72/0xb0 net/socket.c:1718
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    page_owner free stack trace missing
    
    Memory state around the buggy address:
     ffff88802f4fc780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff88802f4fc800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff88802f4fc880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
     ffff88802f4fc900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88802f4fc980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    
    Fixes: 43815482370c ("net: sock_def_readable() and friends RCU conversion")
    Reported-and-tested-by: syzbot+32b89eaa102b372ff76d@syzkaller.appspotmail.com
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Eric Biggers <ebiggers@google.com>
    Cc: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240126165532.3396702-1-edumazet@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

llc: Drop support for ETH_P_TR_802_2. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu Jan 18 17:55:15 2024 -0800

    llc: Drop support for ETH_P_TR_802_2.
    
    [ Upstream commit e3f9bed9bee261e3347131764e42aeedf1ffea61 ]
    
    syzbot reported an uninit-value bug below. [0]
    
    llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
    (0x0011), and syzbot abused the latter to trigger the bug.
    
      write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)
    
    llc_conn_handler() initialises local variables {saddr,daddr}.mac
    based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
    them to __llc_lookup().
    
    However, the initialisation is done only when skb->protocol is
    htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
    __llc_lookup_listener() will read garbage.
    
    The missing initialisation existed prior to commit 211ed865108e
    ("net: delete all instances of special processing for token ring").
    
    It removed the part to kick out the token ring stuff but forgot to
    close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
    
    Let's remove llc_tr_packet_type and complete the deprecation.
    
    [0]:
    BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
     __llc_lookup_established+0xe9d/0xf90
     __llc_lookup net/llc/llc_conn.c:611 [inline]
     llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
     llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
     __netif_receive_skb_one_core net/core/dev.c:5527 [inline]
     __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
     netif_receive_skb_internal net/core/dev.c:5727 [inline]
     netif_receive_skb+0x58/0x660 net/core/dev.c:5786
     tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
     tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
     tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
     call_write_iter include/linux/fs.h:2020 [inline]
     new_sync_write fs/read_write.c:491 [inline]
     vfs_write+0x8ef/0x1490 fs/read_write.c:584
     ksys_write+0x20f/0x4c0 fs/read_write.c:637
     __do_sys_write fs/read_write.c:649 [inline]
     __se_sys_write fs/read_write.c:646 [inline]
     __x64_sys_write+0x93/0xd0 fs/read_write.c:646
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    Local variable daddr created at:
     llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783
     llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
    
    CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
    
    Fixes: 211ed865108e ("net: delete all instances of special processing for token ring")
    Reported-by: syzbot+b5ad66046b913bc04c6f@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=b5ad66046b913bc04c6f
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240119015515.61898-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

llc: make llc_ui_sendmsg() more robust against bonding changes [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jan 18 18:36:25 2024 +0000

    llc: make llc_ui_sendmsg() more robust against bonding changes
    
    [ Upstream commit dad555c816a50c6a6a8a86be1f9177673918c647 ]
    
    syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no
    headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
    
    Like some others, llc_ui_sendmsg() releases the socket lock before
    calling sock_alloc_send_skb().
    Then it acquires it again, but does not redo all the sanity checks
    that were performed.
    
    This fix:
    
    - Uses LL_RESERVED_SPACE() to reserve space.
    - Check all conditions again after socket lock is held again.
    - Do not account Ethernet header for mtu limitation.
    
    [1]
    
    skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
    
     kernel BUG at net/core/skbuff.c:193 !
    Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : skb_panic net/core/skbuff.c:189 [inline]
     pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
     lr : skb_panic net/core/skbuff.c:189 [inline]
     lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
    sp : ffff800096f97000
    x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000
    x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2
    x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0
    x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce
    x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001
    x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000
    x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400
    x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000
    x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714
    x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089
    Call trace:
      skb_panic net/core/skbuff.c:189 [inline]
      skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
      skb_push+0xf0/0x108 net/core/skbuff.c:2451
      eth_header+0x44/0x1f8 net/ethernet/eth.c:83
      dev_hard_header include/linux/netdevice.h:3188 [inline]
      llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33
      llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85
      llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
      llc_sap_next_state net/llc/llc_sap.c:182 [inline]
      llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209
      llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270
      llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg net/socket.c:745 [inline]
      sock_sendmsg+0x194/0x274 net/socket.c:767
      splice_to_socket+0x7cc/0xd58 fs/splice.c:881
      do_splice_from fs/splice.c:933 [inline]
      direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142
      splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088
      do_splice_direct+0x20c/0x348 fs/splice.c:1194
      do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
      __do_sys_sendfile64 fs/read_write.c:1322 [inline]
      __se_sys_sendfile64 fs/read_write.c:1308 [inline]
      __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308
      __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
      invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
      el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
      do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
      el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678
      el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
      el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
    Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-and-tested-by: syzbot+2a7024e9502df538e8ef@syzkaller.appspotmail.com
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240118183625.4007013-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
lsm: fix the logic in security_inode_getsecctx() [+ + +]
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Fri Jan 26 11:44:03 2024 +0100

    lsm: fix the logic in security_inode_getsecctx()
    
    commit 99b817c173cd213671daecd25ca27f56b0c7c4ec upstream.
    
    The inode_getsecctx LSM hook has previously been corrected to have
    -EOPNOTSUPP instead of 0 as the default return value to fix BPF LSM
    behavior. However, the call_int_hook()-generated loop in
    security_inode_getsecctx() was left treating 0 as the neutral value, so
    after an LSM returns 0, the loop continues to try other LSMs, and if one
    of them returns a non-zero value, the function immediately returns with
    said value. So in a situation where SELinux and the BPF LSMs registered
    this hook, -EOPNOTSUPP would be incorrectly returned whenever SELinux
    returned 0.
    
    Fix this by open-coding the call_int_hook() loop and making it use the
    correct LSM_RET_DEFAULT() value as the neutral one, similar to what
    other hooks do.
    
    Cc: stable@vger.kernel.org
    Reported-by: Stephen Smalley <stephen.smalley.work@gmail.com>
    Link: https://lore.kernel.org/selinux/CAEjxPJ4ev-pasUwGx48fDhnmjBnq_Wh90jYPwRQRAqXxmOKD4Q@mail.gmail.com/
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2257983
    Fixes: b36995b8609a ("lsm: fix default return value for inode_getsecctx")
    Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
    Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
    [PM: subject line tweak]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

lsm: new security_file_ioctl_compat() hook [+ + +]
Author: Alfred Piccioni <alpic@google.com>
Date:   Tue Dec 19 10:09:09 2023 +0100

    lsm: new security_file_ioctl_compat() hook
    
    commit f1bb47a31dff6d4b34fb14e99850860ee74bb003 upstream.
    
    Some ioctl commands do not require ioctl permission, but are routed to
    other permissions such as FILE_GETATTR or FILE_SETATTR. This routing is
    done by comparing the ioctl cmd to a set of 64-bit flags (FS_IOC_*).
    
    However, if a 32-bit process is running on a 64-bit kernel, it emits
    32-bit flags (FS_IOC32_*) for certain ioctl operations. These flags are
    being checked erroneously, which leads to these ioctl operations being
    routed to the ioctl permission, rather than the correct file
    permissions.
    
    This was also noted in a RED-PEN finding from a while back -
    "/* RED-PEN how should LSM module know it's handling 32bit? */".
    
    This patch introduces a new hook, security_file_ioctl_compat(), that is
    called from the compat ioctl syscall. All current LSMs have been changed
    to support this hook.
    
    Reviewing the three places where we are currently using
    security_file_ioctl(), it appears that only SELinux needs a dedicated
    compat change; TOMOYO and SMACK appear to be functional without any
    change.
    
    Cc: stable@vger.kernel.org
    Fixes: 0b24dcb7f2f7 ("Revert "selinux: simplify ioctl checking"")
    Signed-off-by: Alfred Piccioni <alpic@google.com>
    Reviewed-by: Stephen Smalley <stephen.smalley.work@gmail.com>
    [PM: subject tweak, line length fixes, and alignment corrections]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mailbox: arm_mhuv2: Fix a bug for mhuv2_sender_interrupt [+ + +]
Author: Xiaowu.ding <xiaowu.ding@jaguarmicro.com>
Date:   Tue Dec 12 19:37:22 2023 +0800

    mailbox: arm_mhuv2: Fix a bug for mhuv2_sender_interrupt
    
    [ Upstream commit ee01c0b4384d19ecc5dfa7db3fd4303f965c3eba ]
    
    Message Handling Unit version is v2.1.
    
    When arm_mhuv2 working with the data protocol transfer mode.
    We have split one mhu into two channels, and every channel
    include four channel windows, the two channels share
    one gic spi interrupt.
    
    There is a problem with the sending scenario.
    
    The first channel will take up 0-3 channel windows, and the second
    channel take up 4-7 channel windows. When the first channel send the
    data, and the receiver will clear all the four channels status.
    Although we only enabled the interrupt on the last channel window with
    register CH_INT_EN,the register CHCOMB_INT_ST0 will be 0xf, not be 0x8.
    Currently we just clear the last channel windows int status with the
    data proctol mode.So after that,the CHCOMB_INT_ST0 status will be 0x7,
    not be the 0x0.
    
    Then the second channel send the data, the receiver read the
    data, clear all the four channel windows status, trigger the sender
    interrupt. But currently the CHCOMB_INT_ST0 register will be 0xf7,
    get_irq_chan_comb function will always return the first channel.
    
    So this patch clear all channel windows int status to avoid this interrupt
    confusion.
    
    Signed-off-by: Xiaowu.ding <xiaowu.ding@jaguarmicro.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md: Whenassemble the array, consult the superblock of the freshest device [+ + +]
Author: Alex Lyakas <alex.lyakas@zadara.com>
Date:   Wed Dec 13 14:24:31 2023 +0200

    md: Whenassemble the array, consult the superblock of the freshest device
    
    [ Upstream commit dc1cc22ed58f11d58d8553c5ec5f11cbfc3e3039 ]
    
    Upon assembling the array, both kernel and mdadm allow the devices to have event
    counter difference of 1, and still consider them as up-to-date.
    However, a device whose event count is behind by 1, may in fact not be up-to-date,
    and array resync with such a device may cause data corruption.
    To avoid this, consult the superblock of the freshest device about the status
    of a device, whose event counter is behind by 1.
    
    Signed-off-by: Alex Lyakas <alex.lyakas@zadara.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/1702470271-16073-1-git-send-email-alex.lyakas@zadara.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: ddbridge: fix an error code problem in ddb_probe [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Fri Oct 20 17:17:23 2023 +0800

    media: ddbridge: fix an error code problem in ddb_probe
    
    [ Upstream commit 09b4195021be69af1e1936cca995712a6d0f2562 ]
    
    Error code is assigned to 'stat', return 'stat' rather than '-1'.
    
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: i2c: imx335: Fix hblank min/max values [+ + +]
Author: Kieran Bingham <kieran.bingham@ideasonboard.com>
Date:   Mon Dec 11 18:29:48 2023 +0530

    media: i2c: imx335: Fix hblank min/max values
    
    [ Upstream commit d7b95ad7a8d56248dfc34f861e445fad7a4004f4 ]
    
    The V4L2_CID_HBLANK control is marked as readonly and can only be a
    single value.
    
    Set the minimum and maximum value to match the mode value.
    
    Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
    Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imx355: Enable runtime PM before registering async sub-device [+ + +]
Author: Bingbu Cao <bingbu.cao@intel.com>
Date:   Wed Nov 22 17:46:06 2023 +0800

    media: imx355: Enable runtime PM before registering async sub-device
    
    commit efa5fe19c0a9199f49e36e1f5242ed5c88da617d upstream.
    
    As the sensor device maybe accessible right after its async sub-device is
    registered, such as ipu-bridge will try to power up sensor by sensor's
    client device's runtime PM from the async notifier callback, if runtime PM
    is not enabled, it will fail.
    
    So runtime PM should be ready before its async sub-device is registered
    and accessible by others.
    
    Fixes: df0b5c4a7ddd ("media: add imx355 camera sensor driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: ir_toy: fix a memleak in irtoy_tx [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Wed Jan 17 09:14:19 2024 +0100

    media: ir_toy: fix a memleak in irtoy_tx
    
    [ Upstream commit dc9ceb90c4b42c6e5c6757df1d6257110433788e ]
    
    When irtoy_command fails, buf should be freed since it is allocated by
    irtoy_tx, or there is a memleak.
    
    Fixes: 4114978dcd24 ("media: ir_toy: prevent device from hanging during transmit")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run [+ + +]
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Mon Nov 6 15:48:10 2023 +0100

    media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run
    
    [ Upstream commit 206c857dd17d4d026de85866f1b5f0969f2a109e ]
    
    In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with
    mtk_jpeg_job_timeout_work.
    
    In mtk_jpeg_dec_device_run, if error happens in
    mtk_jpeg_set_dec_dst, it will finally start the worker while
    mark the job as finished by invoking v4l2_m2m_job_finish.
    
    There are two methods to trigger the bug. If we remove the
    module, it which will call mtk_jpeg_remove to make cleanup.
    The possible sequence is as follows, which will cause a
    use-after-free bug.
    
    CPU0                  CPU1
    mtk_jpeg_dec_...    |
      start worker      |
                        |mtk_jpeg_job_timeout_work
    mtk_jpeg_remove     |
      v4l2_m2m_release  |
        kfree(m2m_dev); |
                        |
                        | v4l2_m2m_get_curr_priv
                        |   m2m_dev->curr_ctx //use
    
    If we close the file descriptor, which will call mtk_jpeg_release,
    it will have a similar sequence.
    
    Fix this bug by starting timeout worker only if started jpegdec worker
    successfully. Then v4l2_m2m_job_finish will only be called in
    either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.
    
    Fixes: b2f0d2724ba4 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov9734: Enable runtime PM before registering async sub-device [+ + +]
Author: Bingbu Cao <bingbu.cao@intel.com>
Date:   Wed Nov 22 17:46:09 2023 +0800

    media: ov9734: Enable runtime PM before registering async sub-device
    
    commit e242e9c144050ed120cf666642ba96b7c4462a4c upstream.
    
    As the sensor device maybe accessible right after its async sub-device is
    registered, such as ipu-bridge will try to power up sensor by sensor's
    client device's runtime PM from the async notifier callback, if runtime PM
    is not enabled, it will fail.
    
    So runtime PM should be ready before its async sub-device is registered
    and accessible by others.
    
    Fixes: d3f863a63fe4 ("media: i2c: Add ov9734 image sensor driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: rc: bpf attach/detach requires write permission [+ + +]
Author: Sean Young <sean@mess.org>
Date:   Thu Apr 13 10:50:32 2023 +0200

    media: rc: bpf attach/detach requires write permission
    
    commit 6a9d552483d50953320b9d3b57abdee8d436f23f upstream.
    
    Note that bpf attach/detach also requires CAP_NET_ADMIN.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: Revert "media: rkisp1: Drop IRQF_SHARED" [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Mon Dec 18 08:54:00 2023 +0100

    media: Revert "media: rkisp1: Drop IRQF_SHARED"
    
    commit a107d643b2a3382e0a2d2c4ef08bf8c6bff4561d upstream.
    
    This reverts commit 85d2a31fe4d9be1555f621ead7a520d8791e0f74.
    
    The rkisp1 does share interrupt lines on some platforms, after all. Thus
    we need to revert this, and implement a fix for the rkisp1 shared irq
    handling in a follow-up patch.
    
    Closes: https://lore.kernel.org/all/87o7eo8vym.fsf@gmail.com/
    Link: https://lore.kernel.org/r/20231218-rkisp-shirq-fix-v1-1-173007628248@ideasonboard.com
    
    Reported-by: Mikhail Rudenko <mike.rudenko@gmail.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: rkisp1: Drop IRQF_SHARED [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Thu Dec 7 08:57:45 2023 +0100

    media: rkisp1: Drop IRQF_SHARED
    
    [ Upstream commit 85d2a31fe4d9be1555f621ead7a520d8791e0f74 ]
    
    In all known platforms the ISP has dedicated IRQ lines, but for some
    reason the driver uses IRQF_SHARED.
    
    Supporting IRQF_SHARED properly requires handling interrupts even when
    our device is disabled, and the driver does not handle this. To avoid
    adding such code, and to be sure the driver won't accidentally be used
    in a platform with shared interrupts, let's drop the IRQF_SHARED flag.
    
    Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-1-358a2c871a3c@ideasonboard.com
    
    Tested-by: Adam Ford <aford173@gmail.com>  #imx8mp-beacon
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: rockchip: rga: fix swizzling for RGB formats [+ + +]
Author: Michael Tretter <m.tretter@pengutronix.de>
Date:   Fri Oct 13 13:00:22 2023 +0200

    media: rockchip: rga: fix swizzling for RGB formats
    
    [ Upstream commit 9e7dc39260edac180c206bb6149595a40eabae3e ]
    
    When using 32 bit RGB formats, the RGA on the rk3568 produces wrong
    colors as the wrong color channels are read or written.  The reason is
    that the format description for the channel swizzeling is wrong and the
    wrong bits are configured. For example, when converting ARGB32 to NV12,
    the alpha channel is used as blue channel.. This doesn't happen if the
    color format is the same on both sides.
    
    Fix the color_swap settings of the formats to correctly handle 32 bit
    RGB formats.
    
    For RGA_COLOR_FMT_XBGR8888, the RGA_COLOR_ALPHA_SWAP bit doesn't have an
    effect. Thus, it isn't possible to handle the V4L2_PIX_FMT_XRGB32. Thus,
    it is removed from the list of supported formats.
    
    Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: stk1160: Fixed high volume of stk1160_dbg messages [+ + +]
Author: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
Date:   Sat Nov 25 14:32:36 2023 +0530

    media: stk1160: Fixed high volume of stk1160_dbg messages
    
    [ Upstream commit b3695e86d25aafbe175dd51f6aaf6f68d341d590 ]
    
    The function stk1160_dbg gets called too many times, which causes
    the output to get flooded with messages. Since stk1160_dbg uses
    printk, it is now replaced with printk_ratelimited.
    
    Suggested-by: Phillip Potter <phil@philpotter.co.uk>
    Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mfd: ti_am335x_tscadc: Fix TI SoC dependencies [+ + +]
Author: Peter Robinson <pbrobinson@gmail.com>
Date:   Wed Dec 20 15:56:39 2023 +0000

    mfd: ti_am335x_tscadc: Fix TI SoC dependencies
    
    [ Upstream commit 284d16c456e5d4b143f375b8ccc4038ab3f4ee0f ]
    
    The ti_am335x_tscadc is specific to some TI SoCs, update
    the dependencies for those SoCs and compile testing.
    
    Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
    Link: https://lore.kernel.org/r/20231220155643.445849-1-pbrobinson@gmail.com
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: Add 'memory' clobber to csum_ipv6_magic() inline assembler [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Feb 11 08:08:37 2024 -0800

    MIPS: Add 'memory' clobber to csum_ipv6_magic() inline assembler
    
    [ Upstream commit d55347bfe4e66dce2e1e7501e5492f4af3e315f8 ]
    
    After 'lib: checksum: Use aligned accesses for ip_fast_csum and
    csum_ipv6_magic tests' was applied, the test_csum_ipv6_magic unit test
    started failing for all mips platforms, both little and bit endian.
    Oddly enough, adding debug code into test_csum_ipv6_magic() made the
    problem disappear.
    
    The gcc manual says:
    
    "The "memory" clobber tells the compiler that the assembly code performs
     memory reads or writes to items other than those listed in the input
     and output operands (for example, accessing the memory pointed to by one
     of the input parameters)
    "
    
    This is definitely the case for csum_ipv6_magic(). Indeed, adding the
    'memory' clobber fixes the problem.
    
    Cc: Charlie Jenkins <charlie@rivosinc.com>
    Cc: Palmer Dabbelt <palmer@rivosinc.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mips: Call lose_fpu(0) before initializing fcr31 in mips_set_personality_nan [+ + +]
Author: Xi Ruoyao <xry111@xry111.site>
Date:   Sat Jan 27 05:05:57 2024 +0800

    mips: Call lose_fpu(0) before initializing fcr31 in mips_set_personality_nan
    
    commit 59be5c35850171e307ca5d3d703ee9ff4096b948 upstream.
    
    If we still own the FPU after initializing fcr31, when we are preempted
    the dirty value in the FPU will be read out and stored into fcr31,
    clobbering our setting.  This can cause an improper floating-point
    environment after execve().  For example:
    
        zsh% cat measure.c
        #include <fenv.h>
        int main() { return fetestexcept(FE_INEXACT); }
        zsh% cc measure.c -o measure -lm
        zsh% echo $((1.0/3)) # raising FE_INEXACT
        0.33333333333333331
        zsh% while ./measure; do ; done
        (stopped in seconds)
    
    Call lose_fpu(0) before setting fcr31 to prevent this.
    
    Closes: https://lore.kernel.org/linux-mips/7a6aa1bbdbbe2e63ae96ff163fab0349f58f1b9e.camel@xry111.site/
    Fixes: 9b26616c8d9d ("MIPS: Respect the ISA level in FCSR handling")
    Cc: stable@vger.kernel.org
    Signed-off-by: Xi Ruoyao <xry111@xry111.site>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mips: Fix max_mapnr being uninitialized on early stages [+ + +]
Author: Serge Semin <fancer.lancer@gmail.com>
Date:   Sat Dec 2 14:14:20 2023 +0300

    mips: Fix max_mapnr being uninitialized on early stages
    
    commit e1a9ae45736989c972a8d1c151bc390678ae6205 upstream.
    
    max_mapnr variable is utilized in the pfn_valid() method in order to
    determine the upper PFN space boundary. Having it uninitialized
    effectively makes any PFN passed to that method invalid. That in its turn
    causes the kernel mm-subsystem occasion malfunctions even after the
    max_mapnr variable is actually properly updated. For instance,
    pfn_valid() is called in the init_unavailable_range() method in the
    framework of the calls-chain on MIPS:
    setup_arch()
    +-> paging_init()
        +-> free_area_init()
            +-> memmap_init()
                +-> memmap_init_zone_range()
                    +-> init_unavailable_range()
    
    Since pfn_valid() always returns "false" value before max_mapnr is
    initialized in the mem_init() method, any flatmem page-holes will be left
    in the poisoned/uninitialized state including the IO-memory pages. Thus
    any further attempts to map/remap the IO-memory by using MMU may fail.
    In particular it happened in my case on attempt to map the SRAM region.
    The kernel bootup procedure just crashed on the unhandled unaligned access
    bug raised in the __update_cache() method:
    
    > Unhandled kernel unaligned access[#1]:
    > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc1-XXX-dirty #2056
    > ...
    > Call Trace:
    > [<8011ef9c>] __update_cache+0x88/0x1bc
    > [<80385944>] ioremap_page_range+0x110/0x2a4
    > [<80126948>] ioremap_prot+0x17c/0x1f4
    > [<80711b80>] __devm_ioremap+0x8c/0x120
    > [<80711e0c>] __devm_ioremap_resource+0xf4/0x218
    > [<808bf244>] sram_probe+0x4f4/0x930
    > [<80889d20>] platform_probe+0x68/0xec
    > ...
    
    Let's fix the problem by initializing the max_mapnr variable as soon as
    the required data is available. In particular it can be done right in the
    paging_init() method before free_area_init() is called since all the PFN
    zone boundaries have already been calculated by that time.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
misc: fastrpc: Mark all sessions as invalid in cb_remove [+ + +]
Author: Ekansh Gupta <quic_ekangupt@quicinc.com>
Date:   Mon Jan 8 17:18:33 2024 +0530

    misc: fastrpc: Mark all sessions as invalid in cb_remove
    
    commit a4e61de63e34860c36a71d1a364edba16fb6203b upstream.
    
    In remoteproc shutdown sequence, rpmsg_remove will get called which
    would depopulate all the child nodes that have been created during
    rpmsg_probe. This would result in cb_remove call for all the context
    banks for the remoteproc. In cb_remove function, session 0 is
    getting skipped which is not correct as session 0 will never become
    available again. Add changes to mark session 0 also as invalid.
    
    Fixes: f6f9279f2bf0 ("misc: fastrpc: Add Qualcomm fastrpc basic driver model")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ekansh Gupta <quic_ekangupt@quicinc.com>
    Link: https://lore.kernel.org/r/20240108114833.20480-1-quic_ekangupt@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/sparsemem: fix race in accessing memory_section->usage [+ + +]
Author: Charan Teja Kalla <quic_charante@quicinc.com>
Date:   Fri Oct 13 18:34:27 2023 +0530

    mm/sparsemem: fix race in accessing memory_section->usage
    
    [ Upstream commit 5ec8e8ea8b7783fab150cf86404fc38cb4db8800 ]
    
    The below race is observed on a PFN which falls into the device memory
    region with the system memory configuration where PFN's are such that
    [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL].  Since normal zone start and end
    pfn contains the device memory PFN's as well, the compaction triggered
    will try on the device memory PFN's too though they end up in NOP(because
    pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections).  When
    from other core, the section mappings are being removed for the
    ZONE_DEVICE region, that the PFN in question belongs to, on which
    compaction is currently being operated is resulting into the kernel crash
    with CONFIG_SPASEMEM_VMEMAP enabled.  The crash logs can be seen at [1].
    
    compact_zone()                  memunmap_pages
    -------------                   ---------------
    __pageblock_pfn_to_page
       ......
     (a)pfn_valid():
         valid_section()//return true
                                  (b)__remove_pages()->
                                      sparse_remove_section()->
                                        section_deactivate():
                                        [Free the array ms->usage and set
                                         ms->usage = NULL]
         pfn_section_valid()
         [Access ms->usage which
         is NULL]
    
    NOTE: From the above it can be said that the race is reduced to between
    the pfn_valid()/pfn_section_valid() and the section deactivate with
    SPASEMEM_VMEMAP enabled.
    
    The commit b943f045a9af("mm/sparse: fix kernel crash with
    pfn_section_valid check") tried to address the same problem by clearing
    the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns
    false thus ms->usage is not accessed.
    
    Fix this issue by the below steps:
    
    a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage.
    
    b) RCU protected read side critical section will either return NULL
       when SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage.
    
    c) Free the ->usage with kfree_rcu() and set ms->usage = NULL.  No
       attempt will be made to access ->usage after this as the
       SECTION_HAS_MEM_MAP is cleared thus valid_section() return false.
    
    Thanks to David/Pavan for their inputs on this patch.
    
    [1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/
    
    On Snapdragon SoC, with the mentioned memory configuration of PFN's as
    [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of
    issues daily while testing on a device farm.
    
    For this particular issue below is the log.  Though the below log is
    not directly pointing to the pfn_section_valid(){ ms->usage;}, when we
    loaded this dump on T32 lauterbach tool, it is pointing.
    
    [  540.578056] Unable to handle kernel NULL pointer dereference at
    virtual address 0000000000000000
    [  540.578068] Mem abort info:
    [  540.578070]   ESR = 0x0000000096000005
    [  540.578073]   EC = 0x25: DABT (current EL), IL = 32 bits
    [  540.578077]   SET = 0, FnV = 0
    [  540.578080]   EA = 0, S1PTW = 0
    [  540.578082]   FSC = 0x05: level 1 translation fault
    [  540.578085] Data abort info:
    [  540.578086]   ISV = 0, ISS = 0x00000005
    [  540.578088]   CM = 0, WnR = 0
    [  540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--)
    [  540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c
    [  540.579454] lr : compact_zone+0x994/0x1058
    [  540.579460] sp : ffffffc03579b510
    [  540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c
    [  540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640
    [  540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000
    [  540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140
    [  540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff
    [  540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001
    [  540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440
    [  540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4
    [  540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000001
    [  540.579518] x2 : ffffffdebf7e3940 x1 : 0000000000235c00 x0 :0000000000235800
    [  540.579524] Call trace:
    [  540.579527]  __pageblock_pfn_to_page+0x6c/0x14c
    [  540.579533]  compact_zone+0x994/0x1058
    [  540.579536]  try_to_compact_pages+0x128/0x378
    [  540.579540]  __alloc_pages_direct_compact+0x80/0x2b0
    [  540.579544]  __alloc_pages_slowpath+0x5c0/0xe10
    [  540.579547]  __alloc_pages+0x250/0x2d0
    [  540.579550]  __iommu_dma_alloc_noncontiguous+0x13c/0x3fc
    [  540.579561]  iommu_dma_alloc+0xa0/0x320
    [  540.579565]  dma_alloc_attrs+0xd4/0x108
    
    [quic_charante@quicinc.com: use kfree_rcu() in place of synchronize_rcu(), per David]
      Link: https://lkml.kernel.org/r/1698403778-20938-1-git-send-email-quic_charante@quicinc.com
    Link: https://lkml.kernel.org/r/1697202267-23600-1-git-send-email-quic_charante@quicinc.com
    Fixes: f46edbd1b151 ("mm/sparsemem: add helpers track active portions of a section at boot")
    Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
    Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again [+ + +]
Author: Zach O'Keefe <zokeefe@google.com>
Date:   Thu Jan 18 10:19:53 2024 -0800

    mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
    
    commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78 upstream.
    
    (struct dirty_throttle_control *)->thresh is an unsigned long, but is
    passed as the u32 divisor argument to div_u64().  On architectures where
    unsigned long is 64 bytes, the argument will be implicitly truncated.
    
    Use div64_u64() instead of div_u64() so that the value used in the "is
    this a safe division" check is the same as the divisor.
    
    Also, remove redundant cast of the numerator to u64, as that should happen
    implicitly.
    
    This would be difficult to exploit in memcg domain, given the ratio-based
    arithmetic domain_drity_limits() uses, but is much easier in global
    writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g.
    vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32)
    
    Link: https://lkml.kernel.org/r/20240118181954.1415197-1-zokeefe@google.com
    Fixes: f6789593d5ce ("mm/page-writeback.c: fix divide by zero in bdi_dirty_limits()")
    Signed-off-by: Zach O'Keefe <zokeefe@google.com>
    Cc: Maxim Patlasov <MPatlasov@parallels.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: hugetlb pages should not be reserved by shmat() if SHM_NORESERVE [+ + +]
Author: Prakash Sangappa <prakash.sangappa@oracle.com>
Date:   Tue Jan 23 12:04:42 2024 -0800

    mm: hugetlb pages should not be reserved by shmat() if SHM_NORESERVE
    
    commit e656c7a9e59607d1672d85ffa9a89031876ffe67 upstream.
    
    For shared memory of type SHM_HUGETLB, hugetlb pages are reserved in
    shmget() call.  If SHM_NORESERVE flags is specified then the hugetlb pages
    are not reserved.  However when the shared memory is attached with the
    shmat() call the hugetlb pages are getting reserved incorrectly for
    SHM_HUGETLB shared memory created with SHM_NORESERVE which is a bug.
    
    -------------------------------
    Following test shows the issue.
    
    $cat shmhtb.c
    
    int main()
    {
            int shmflags = 0660 | IPC_CREAT | SHM_HUGETLB | SHM_NORESERVE;
            int shmid;
    
            shmid = shmget(SKEY, SHMSZ, shmflags);
            if (shmid < 0)
            {
                    printf("shmat: shmget() failed, %d\n", errno);
                    return 1;
            }
            printf("After shmget()\n");
            system("cat /proc/meminfo | grep -i hugepages_");
    
            shmat(shmid, NULL, 0);
            printf("\nAfter shmat()\n");
            system("cat /proc/meminfo | grep -i hugepages_");
    
            shmctl(shmid, IPC_RMID, NULL);
            return 0;
    }
    
     #sysctl -w vm.nr_hugepages=20
     #./shmhtb
    
    After shmget()
    HugePages_Total:      20
    HugePages_Free:       20
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    
    After shmat()
    HugePages_Total:      20
    HugePages_Free:       20
    HugePages_Rsvd:        5 <--
    HugePages_Surp:        0
    --------------------------------
    
    Fix is to ensure that hugetlb pages are not reserved for SHM_HUGETLB shared
    memory in the shmat() call.
    
    Link: https://lkml.kernel.org/r/1706040282-12388-1-git-send-email-prakash.sangappa@oracle.com
    Signed-off-by: Prakash Sangappa <prakash.sangappa@oracle.com>
    Acked-by: Muchun Song <muchun.song@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>

mm: use __pfn_to_section() instead of open coding it [+ + +]
Author: Rolf Eike Beer <eb@emlix.com>
Date:   Fri Nov 5 13:38:15 2021 -0700

    mm: use __pfn_to_section() instead of open coding it
    
    [ Upstream commit f1dc0db296bd25960273649fc6ef2ecbf5aaa0e0 ]
    
    It is defined in the same file just a few lines above.
    
    Link: https://lkml.kernel.org/r/4598487.Rc0NezkW7i@mobilepool36.emlix.com
    Signed-off-by: Rolf Eike Beer <eb@emlix.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Stable-dep-of: 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mmc: core: Use mrq.sbc in close-ended ffu [+ + +]
Author: Avri Altman <avri.altman@wdc.com>
Date:   Wed Nov 29 11:25:35 2023 +0200

    mmc: core: Use mrq.sbc in close-ended ffu
    
    commit 4d0c8d0aef6355660b6775d57ccd5d4ea2e15802 upstream.
    
    Field Firmware Update (ffu) may use close-ended or open ended sequence.
    Each such sequence is comprised of a write commands enclosed between 2
    switch commands - to and from ffu mode. So for the close-ended case, it
    will be: cmd6->cmd23-cmd25-cmd6.
    
    Some host controllers however, get confused when multi-block rw is sent
    without sbc, and may generate auto-cmd12 which breaks the ffu sequence.
    I encountered  this issue while testing fwupd (github.com/fwupd/fwupd)
    on HP Chromebook x2, a qualcomm based QC-7c, code name - strongbad.
    
    Instead of a quirk, or hooking the request function of the msm ops,
    it would be better to fix the ioctl handling and make it use mrq.sbc
    instead of issuing SET_BLOCK_COUNT separately.
    
    Signed-off-by: Avri Altman <avri.altman@wdc.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231129092535.3278-1-avri.altman@wdc.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: mmc_spi: remove custom DMA mapped buffers [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Fri Dec 8 00:19:01 2023 +0200

    mmc: mmc_spi: remove custom DMA mapped buffers
    
    commit 84a6be7db9050dd2601c9870f65eab9a665d2d5d upstream.
    
    There is no need to duplicate what SPI core or individual controller
    drivers already do, i.e. mapping the buffers for DMA capable transfers.
    
    Note, that the code, besides its redundancy, was buggy: strictly speaking
    there is no guarantee, while it's true for those which can use this code
    (see below), that the SPI host controller _is_ the device which does DMA.
    
    Also see the Link tags below.
    
    Additional notes. Currently only two SPI host controller drivers may use
    premapped (by the user) DMA buffers:
    
      - drivers/spi/spi-au1550.c
    
      - drivers/spi/spi-fsl-spi.c
    
    Both of them have DMA mapping support code. I don't expect that SPI host
    controller code is worse than what has been done in mmc_spi. Hence I do
    not expect any regressions here. Otherwise, I'm pretty much sure these
    regressions have to be fixed in the respective drivers, and not here.
    
    That said, remove all related pieces of DMA mapping code from mmc_spi.
    
    Link: https://lore.kernel.org/linux-mmc/c73b9ba9-1699-2aff-e2fd-b4b4f292a3ca@raspberrypi.org/
    Link: https://stackoverflow.com/questions/67620728/mmc-spi-issue-not-able-to-setup-mmc-sd-card-in-linux
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231207221901.3259962-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: slot-gpio: Allow non-sleeping GPIO ro [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Tue Feb 6 09:39:12 2024 +0100

    mmc: slot-gpio: Allow non-sleeping GPIO ro
    
    commit cc9432c4fb159a3913e0ce3173b8218cd5bad2e0 upstream.
    
    This change uses the appropriate _cansleep or non-sleeping API for
    reading GPIO read-only state. This allows users with GPIOs that
    never sleepbeing called in atomic context.
    
    Implement the same mechanism as in commit 52af318c93e97 ("mmc: Allow
    non-sleeping GPIO cd").
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240206083912.2543142-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
modpost: trim leading spaces when processing source files list [+ + +]
Author: Radek Krejci <radek.krejci@oracle.com>
Date:   Wed Feb 14 10:14:07 2024 +0100

    modpost: trim leading spaces when processing source files list
    
    [ Upstream commit 5d9a16b2a4d9e8fa028892ded43f6501bc2969e5 ]
    
    get_line() does not trim the leading spaces, but the
    parse_source_files() expects to get lines with source files paths where
    the first space occurs after the file path.
    
    Fixes: 70f30cfe5b89 ("modpost: use read_text_file() and get_line() for reading text files")
    Signed-off-by: Radek Krejci <radek.krejci@oracle.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: fix data re-injection from stale subflow [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed Jan 31 22:49:46 2024 +0100

    mptcp: fix data re-injection from stale subflow
    
    commit b6c620dc43ccb4e802894e54b651cf81495e9598 upstream.
    
    When the MPTCP PM detects that a subflow is stale, all the packet
    scheduler must re-inject all the mptcp-level unacked data. To avoid
    acquiring unneeded locks, it first try to check if any unacked data
    is present at all in the RTX queue, but such check is currently
    broken, as it uses TCP-specific helper on an MPTCP socket.
    
    Funnily enough fuzzers and static checkers are happy, as the accessed
    memory still belongs to the mptcp_sock struct, and even from a
    functional perspective the recovery completed successfully, as
    the short-cut test always failed.
    
    A recent unrelated TCP change - commit d5fed5addb2b ("tcp: reorganize
    tcp_sock fast path variables") - exposed the issue, as the tcp field
    reorganization makes the mptcp code always skip the re-inection.
    
    Fix the issue dropping the bogus call: we are on a slow path, the early
    optimization proved once again to be evil.
    
    Fixes: 1e1d9d6f119c ("mptcp: handle pending data on closed subflow")
    Cc: stable@vger.kernel.org
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/468
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240131-upstream-net-20240131-mptcp-ci-issues-v1-1-4c1c11e571ff@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5: DR, Align mlx5dv_dr API vport action with FW behavior [+ + +]
Author: Shun Hao <shunh@nvidia.com>
Date:   Mon Jan 17 14:01:12 2022 +0200

    net/mlx5: DR, Align mlx5dv_dr API vport action with FW behavior
    
    [ Upstream commit aa818fbf8f36e8c6f3e608ea960567906c2d6112 ]
    
    This aligns the behavior with FW when creating an FDB rule with wire
    vport destination but no source port matching. Until now such rules
    would fail on internal DR RX rule creation since the source and
    destination are the wire vport.
    The new behavior is the same as done on FW steering, if destination is
    wire, we will create both TX and RX rules, but the RX packet coming from
    wire will be dropped due to loopback not supported.
    
    Signed-off-by: Shun Hao <shunh@nvidia.com>
    Reviewed-by: Alex Vesker <valex@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Stable-dep-of: 5b2a2523eeea ("net/mlx5: DR, Can't go to uplink vport on RX rule")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: DR, Can't go to uplink vport on RX rule [+ + +]
Author: Yevgeny Kliteynik <kliteyn@nvidia.com>
Date:   Sun Dec 17 13:20:36 2023 +0200

    net/mlx5: DR, Can't go to uplink vport on RX rule
    
    [ Upstream commit 5b2a2523eeea5f03d39a9d1ff1bad2e9f8eb98d2 ]
    
    Go-To-Vport action on RX is not allowed when the vport is uplink.
    In such case, the packet should be dropped.
    
    Fixes: 9db810ed2d37 ("net/mlx5: DR, Expose steering action functionality")
    Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
    Reviewed-by: Erez Shitrit <erezsh@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: DR, Replace local WIRE_PORT macro with the existing MLX5_VPORT_UPLINK [+ + +]
Author: Yevgeny Kliteynik <kliteyn@nvidia.com>
Date:   Thu Sep 23 02:23:23 2021 +0300

    net/mlx5: DR, Replace local WIRE_PORT macro with the existing MLX5_VPORT_UPLINK
    
    [ Upstream commit 7ae8ac9a582088c85154970982766617c9ebf8dc ]
    
    SW steering defines its own macro for uplink vport number.
    Replace this macro with an already existing mlx5 macro.
    
    Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Stable-dep-of: 5b2a2523eeea ("net/mlx5: DR, Can't go to uplink vport on RX rule")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: DR, Use the right GVMI number for drop action [+ + +]
Author: Yevgeny Kliteynik <kliteyn@nvidia.com>
Date:   Sun Dec 17 11:24:08 2023 +0200

    net/mlx5: DR, Use the right GVMI number for drop action
    
    [ Upstream commit 5665954293f13642f9c052ead83c1e9d8cff186f ]
    
    When FW provides ICM addresses for drop RX/TX, the provided capability
    is 64 bits that contain its GVMI as well as the ICM address itself.
    In case of TX DROP this GVMI is different from the GVMI that the
    domain is operating on.
    
    This patch fixes the action to use these GVMI IDs, as provided by FW.
    
    Fixes: 9db810ed2d37 ("net/mlx5: DR, Expose steering action functionality")
    Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: fix a double-free in arfs_create_groups [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Wed Jan 17 15:17:36 2024 +0800

    net/mlx5e: fix a double-free in arfs_create_groups
    
    [ Upstream commit 3c6d5189246f590e4e1f167991558bdb72a4738b ]
    
    When `in` allocated by kvzalloc fails, arfs_create_groups will free
    ft->g and return an error. However, arfs_create_table, the only caller of
    arfs_create_groups, will hold this error and call to
    mlx5e_destroy_flow_table, in which the ft->g will be freed again.
    
    Fixes: 1cabe6b0965e ("net/mlx5e: Create aRFS flow tables")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: fix a potential double-free in fs_any_create_groups [+ + +]
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Tue Nov 28 17:29:01 2023 +0800

    net/mlx5e: fix a potential double-free in fs_any_create_groups
    
    [ Upstream commit aef855df7e1bbd5aa4484851561211500b22707e ]
    
    When kcalloc() for ft->g succeeds but kvzalloc() for in fails,
    fs_any_create_groups() will free ft->g. However, its caller
    fs_any_create_table() will free ft->g again through calling
    mlx5e_destroy_flow_table(), which will lead to a double-free.
    Fix this by setting ft->g to NULL in fs_any_create_groups().
    
    Fixes: 0f575c20bf06 ("net/mlx5e: Introduce Flow Steering ANY API")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/rds: Fix UBSAN: array-index-out-of-bounds in rds_cmsg_recv [+ + +]
Author: Sharath Srinivasan <sharath.srinivasan@oracle.com>
Date:   Fri Jan 19 17:48:39 2024 -0800

    net/rds: Fix UBSAN: array-index-out-of-bounds in rds_cmsg_recv
    
    [ Upstream commit 13e788deb7348cc88df34bed736c3b3b9927ea52 ]
    
    Syzcaller UBSAN crash occurs in rds_cmsg_recv(),
    which reads inc->i_rx_lat_trace[j + 1] with index 4 (3 + 1),
    but with array size of 4 (RDS_RX_MAX_TRACES).
    Here 'j' is assigned from rs->rs_rx_trace[i] and in-turn from
    trace.rx_trace_pos[i] in rds_recv_track_latency(),
    with both arrays sized 3 (RDS_MSG_RX_DGRAM_TRACE_MAX). So fix the
    off-by-one bounds check in rds_recv_track_latency() to prevent
    a potential crash in rds_cmsg_recv().
    
    Found by syzcaller:
    =================================================================
    UBSAN: array-index-out-of-bounds in net/rds/recv.c:585:39
    index 4 is out of range for type 'u64 [4]'
    CPU: 1 PID: 8058 Comm: syz-executor228 Not tainted 6.6.0-gd2f51b3516da #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS 1.15.0-1 04/01/2014
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x136/0x150 lib/dump_stack.c:106
     ubsan_epilogue lib/ubsan.c:217 [inline]
     __ubsan_handle_out_of_bounds+0xd5/0x130 lib/ubsan.c:348
     rds_cmsg_recv+0x60d/0x700 net/rds/recv.c:585
     rds_recvmsg+0x3fb/0x1610 net/rds/recv.c:716
     sock_recvmsg_nosec net/socket.c:1044 [inline]
     sock_recvmsg+0xe2/0x160 net/socket.c:1066
     __sys_recvfrom+0x1b6/0x2f0 net/socket.c:2246
     __do_sys_recvfrom net/socket.c:2264 [inline]
     __se_sys_recvfrom net/socket.c:2260 [inline]
     __x64_sys_recvfrom+0xe0/0x1b0 net/socket.c:2260
     do_syscall_x64 arch/x86/entry/common.c:51 [inline]
     do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    ==================================================================
    
    Fixes: 3289025aedc0 ("RDS: add receive message trace used by application")
    Reported-by: Chenyuan Yang <chenyuan0y@gmail.com>
    Closes: https://lore.kernel.org/linux-rdma/CALGdzuoVdq-wtQ4Az9iottBqC5cv9ZhcE5q8N7LfYFvkRsOVcw@mail.gmail.com/
    Signed-off-by: Sharath Srinivasan <sharath.srinivasan@oracle.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/smc: fix illegal rmb_desc access in SMC-D connection dump [+ + +]
Author: Wen Gu <guwen@linux.alibaba.com>
Date:   Thu Jan 18 12:32:10 2024 +0800

    net/smc: fix illegal rmb_desc access in SMC-D connection dump
    
    [ Upstream commit dbc153fd3c142909e564bb256da087e13fbf239c ]
    
    A crash was found when dumping SMC-D connections. It can be reproduced
    by following steps:
    
    - run nginx/wrk test:
      smc_run nginx
      smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>
    
    - continuously dump SMC-D connections in parallel:
      watch -n 1 'smcss -D'
    
     BUG: kernel NULL pointer dereference, address: 0000000000000030
     CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G  E      6.7.0+ #55
     RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
     Call Trace:
      <TASK>
      ? __die+0x24/0x70
      ? page_fault_oops+0x66/0x150
      ? exc_page_fault+0x69/0x140
      ? asm_exc_page_fault+0x26/0x30
      ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
      ? __kmalloc_node_track_caller+0x35d/0x430
      ? __alloc_skb+0x77/0x170
      smc_diag_dump_proto+0xd0/0xf0 [smc_diag]
      smc_diag_dump+0x26/0x60 [smc_diag]
      netlink_dump+0x19f/0x320
      __netlink_dump_start+0x1dc/0x300
      smc_diag_handler_dump+0x6a/0x80 [smc_diag]
      ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]
      sock_diag_rcv_msg+0x121/0x140
      ? __pfx_sock_diag_rcv_msg+0x10/0x10
      netlink_rcv_skb+0x5a/0x110
      sock_diag_rcv+0x28/0x40
      netlink_unicast+0x22a/0x330
      netlink_sendmsg+0x1f8/0x420
      __sock_sendmsg+0xb0/0xc0
      ____sys_sendmsg+0x24e/0x300
      ? copy_msghdr_from_user+0x62/0x80
      ___sys_sendmsg+0x7c/0xd0
      ? __do_fault+0x34/0x160
      ? do_read_fault+0x5f/0x100
      ? do_fault+0xb0/0x110
      ? __handle_mm_fault+0x2b0/0x6c0
      __sys_sendmsg+0x4d/0x80
      do_syscall_64+0x69/0x180
      entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    It is possible that the connection is in process of being established
    when we dump it. Assumed that the connection has been registered in a
    link group by smc_conn_create() but the rmb_desc has not yet been
    initialized by smc_buf_create(), thus causing the illegal access to
    conn->rmb_desc. So fix it by checking before dump.
    
    Fixes: 4b1b7d3b30a6 ("net/smc: add SMC-D diag support")
    Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
    Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
    Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: bcmgenet: Fix EEE implementation [+ + +]
Author: Florian Fainelli <florian.fainelli@broadcom.com>
Date:   Tue Jun 6 14:43:47 2023 -0700

    net: bcmgenet: Fix EEE implementation
    
    commit a9f31047baca57d47440c879cf259b86f900260c upstream.
    
    We had a number of short comings:
    
    - EEE must be re-evaluated whenever the state machine detects a link
      change as wight be switching from a link partner with EEE
      enabled/disabled
    
    - tx_lpi_enabled controls whether EEE should be enabled/disabled for the
      transmit path, which applies to the TBUF block
    
    - We do not need to forcibly enable EEE upon system resume, as the PHY
      state machine will trigger a link event that will do that, too
    
    Fixes: 6ef398ea60d9 ("net: bcmgenet: add EEE support")
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Link: https://lore.kernel.org/r/20230606214348.2408018-1-florian.fainelli@broadcom.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: dsa: mv88e6xxx: Fix mv88e6352_serdes_get_stats error path [+ + +]
Author: Tobias Waldekranz <tobias@waldekranz.com>
Date:   Thu Dec 14 14:50:24 2023 +0100

    net: dsa: mv88e6xxx: Fix mv88e6352_serdes_get_stats error path
    
    [ Upstream commit fc82a08ae795ee6b73fb6b50785f7be248bec7b5 ]
    
    mv88e6xxx_get_stats, which collects stats from various sources,
    expects all callees to return the number of stats read. If an error
    occurs, 0 should be returned.
    
    Prevent future mishaps of this kind by updating the return type to
    reflect this contract.
    
    Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: ti: cpsw: enable mac_managed_pm to fix mdio [+ + +]
Author: Sinthu Raja <sinthu.raja@ti.com>
Date:   Tue Feb 6 06:29:28 2024 +0530

    net: ethernet: ti: cpsw: enable mac_managed_pm to fix mdio
    
    commit bc4ce46b1e3d1da4309405cd4afc7c0fcddd0b90 upstream.
    
    The below commit  introduced a WARN when phy state is not in the states:
    PHY_HALTED, PHY_READY and PHY_UP.
    commit 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    
    When cpsw resumes, there have port in PHY_NOLINK state, so the below
    warning comes out. Set mac_managed_pm be true to tell mdio that the phy
    resume/suspend is managed by the mac, to fix the following warning:
    
    WARNING: CPU: 0 PID: 965 at drivers/net/phy/phy_device.c:326 mdio_bus_phy_resume+0x140/0x144
    CPU: 0 PID: 965 Comm: sh Tainted: G           O       6.1.46-g247b2535b2 #1
    Hardware name: Generic AM33XX (Flattened Device Tree)
     unwind_backtrace from show_stack+0x18/0x1c
     show_stack from dump_stack_lvl+0x24/0x2c
     dump_stack_lvl from __warn+0x84/0x15c
     __warn from warn_slowpath_fmt+0x1a8/0x1c8
     warn_slowpath_fmt from mdio_bus_phy_resume+0x140/0x144
     mdio_bus_phy_resume from dpm_run_callback+0x3c/0x140
     dpm_run_callback from device_resume+0xb8/0x2b8
     device_resume from dpm_resume+0x144/0x314
     dpm_resume from dpm_resume_end+0x14/0x20
     dpm_resume_end from suspend_devices_and_enter+0xd0/0x924
     suspend_devices_and_enter from pm_suspend+0x2e0/0x33c
     pm_suspend from state_store+0x74/0xd0
     state_store from kernfs_fop_write_iter+0x104/0x1ec
     kernfs_fop_write_iter from vfs_write+0x1b8/0x358
     vfs_write from ksys_write+0x78/0xf8
     ksys_write from ret_fast_syscall+0x0/0x54
    Exception stack(0xe094dfa8 to 0xe094dff0)
    dfa0:                   00000004 005c3fb8 00000001 005c3fb8 00000004 00000001
    dfc0: 00000004 005c3fb8 b6f6bba0 00000004 00000004 0059edb8 00000000 00000000
    dfe0: 00000004 bed918f0 b6f09bd3 b6e89a66
    
    Cc: <stable@vger.kernel.org> # v6.0+
    Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM")
    Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: ethernet: ti: cpsw_new: enable mac_managed_pm to fix mdio [+ + +]
Author: Sinthu Raja <sinthu.raja@ti.com>
Date:   Tue Feb 6 06:29:27 2024 +0530

    net: ethernet: ti: cpsw_new: enable mac_managed_pm to fix mdio
    
    commit 9def04e759caa5a3d741891037ae99f81e2fff01 upstream.
    
    The below commit  introduced a WARN when phy state is not in the states:
    PHY_HALTED, PHY_READY and PHY_UP.
    commit 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    
    When cpsw_new resumes, there have port in PHY_NOLINK state, so the below
    warning comes out. Set mac_managed_pm be true to tell mdio that the phy
    resume/suspend is managed by the mac, to fix the following warning:
    
    WARNING: CPU: 0 PID: 965 at drivers/net/phy/phy_device.c:326 mdio_bus_phy_resume+0x140/0x144
    CPU: 0 PID: 965 Comm: sh Tainted: G           O       6.1.46-g247b2535b2 #1
    Hardware name: Generic AM33XX (Flattened Device Tree)
     unwind_backtrace from show_stack+0x18/0x1c
     show_stack from dump_stack_lvl+0x24/0x2c
     dump_stack_lvl from __warn+0x84/0x15c
     __warn from warn_slowpath_fmt+0x1a8/0x1c8
     warn_slowpath_fmt from mdio_bus_phy_resume+0x140/0x144
     mdio_bus_phy_resume from dpm_run_callback+0x3c/0x140
     dpm_run_callback from device_resume+0xb8/0x2b8
     device_resume from dpm_resume+0x144/0x314
     dpm_resume from dpm_resume_end+0x14/0x20
     dpm_resume_end from suspend_devices_and_enter+0xd0/0x924
     suspend_devices_and_enter from pm_suspend+0x2e0/0x33c
     pm_suspend from state_store+0x74/0xd0
     state_store from kernfs_fop_write_iter+0x104/0x1ec
     kernfs_fop_write_iter from vfs_write+0x1b8/0x358
     vfs_write from ksys_write+0x78/0xf8
     ksys_write from ret_fast_syscall+0x0/0x54
    Exception stack(0xe094dfa8 to 0xe094dff0)
    dfa0:                   00000004 005c3fb8 00000001 005c3fb8 00000004 00000001
    dfc0: 00000004 005c3fb8 b6f6bba0 00000004 00000004 0059edb8 00000000 00000000
    dfe0: 00000004 bed918f0 b6f09bd3 b6e89a66
    
    Cc: <stable@vger.kernel.org> # v6.0+
    Fixes: 744d23c71af3 ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
    Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM")
    Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: fec: fix the unhandled context fault from smmu [+ + +]
Author: Shenwei Wang <shenwei.wang@nxp.com>
Date:   Tue Jan 23 10:51:41 2024 -0600

    net: fec: fix the unhandled context fault from smmu
    
    [ Upstream commit 5e344807735023cd3a67c37a1852b849caa42620 ]
    
    When repeatedly changing the interface link speed using the command below:
    
    ethtool -s eth0 speed 100 duplex full
    ethtool -s eth0 speed 1000 duplex full
    
    The following errors may sometimes be reported by the ARM SMMU driver:
    
    [ 5395.035364] fec 5b040000.ethernet eth0: Link is Down
    [ 5395.039255] arm-smmu 51400000.iommu: Unhandled context fault:
    fsr=0x402, iova=0x00000000, fsynr=0x100001, cbfrsynra=0x852, cb=2
    [ 5398.108460] fec 5b040000.ethernet eth0: Link is Up - 100Mbps/Full -
    flow control off
    
    It is identified that the FEC driver does not properly stop the TX queue
    during the link speed transitions, and this results in the invalid virtual
    I/O address translations from the SMMU and causes the context faults.
    
    Fixes: dbc64a8ea231 ("net: fec: move calls to quiesce/resume packet processing out of fec_restart()")
    Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
    Link: https://lore.kernel.org/r/20240123165141.2008104-1-shenwei.wang@nxp.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame() [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Wed Jan 24 02:21:47 2024 -0800

    net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
    
    commit 37e8c97e539015637cb920d3e6f1e404f707a06e upstream.
    
    Syzkaller reported [1] hitting a warning after failing to allocate
    resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
    not help much in this case, it might be prudent to switch to
    netdev_warn_once(). At the very least it will suppress syzkaller
    reports such as [1].
    
    Just in case, use netdev_warn_once() in send_prp_supervision_frame()
    for similar reasons.
    
    [1]
    HSR: Could not send supervision frame
    WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
    RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
    ...
    Call Trace:
     <IRQ>
     hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
     call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
     expire_timers kernel/time/timer.c:1751 [inline]
     __run_timers+0x764/0xb20 kernel/time/timer.c:2022
     run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
     __do_softirq+0x21a/0x8de kernel/softirq.c:553
     invoke_softirq kernel/softirq.c:427 [inline]
     __irq_exit_rcu kernel/softirq.c:632 [inline]
     irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
     sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
     </IRQ>
     <TASK>
     asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
    ...
    
    This issue is also found in older kernels (at least up to 5.10).
    
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+3ae0a3f42c84074b7c8e@syzkaller.appspotmail.com
    Fixes: 121c33b07b31 ("net: hsr: introduce common code for skb initialization")
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: ipv4: fix a memleak in ip_setup_cork [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Mon Jan 29 17:10:17 2024 +0800

    net: ipv4: fix a memleak in ip_setup_cork
    
    [ Upstream commit 5dee6d6923458e26966717f2a3eae7d09fc10bf6 ]
    
    When inetdev_valid_mtu fails, cork->opt should be freed if it is
    allocated in ip_setup_cork. Otherwise there could be a memleak.
    
    Fixes: 501a90c94510 ("inet: protect against too small mtu values.")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240129091017.2938835-1-alexious@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mvpp2: clear BM pool before initialization [+ + +]
Author: Jenishkumar Maheshbhai Patel <jpatel2@marvell.com>
Date:   Thu Jan 18 19:59:14 2024 -0800

    net: mvpp2: clear BM pool before initialization
    
    [ Upstream commit 9f538b415db862e74b8c5d3abbccfc1b2b6caa38 ]
    
    Register value persist after booting the kernel using
    kexec which results in kernel panic. Thus clear the
    BM pool registers before initialisation to fix the issue.
    
    Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
    Signed-off-by: Jenishkumar Maheshbhai Patel <jpatel2@marvell.com>
    Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Link: https://lore.kernel.org/r/20240119035914.2595665-1-jpatel2@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: openvswitch: limit the number of recursions from action sets [+ + +]
Author: Aaron Conole <aconole@redhat.com>
Date:   Wed Feb 7 08:24:15 2024 -0500

    net: openvswitch: limit the number of recursions from action sets
    
    [ Upstream commit 6e2f90d31fe09f2b852de25125ca875aabd81367 ]
    
    The ovs module allows for some actions to recursively contain an action
    list for complex scenarios, such as sampling, checking lengths, etc.
    When these actions are copied into the internal flow table, they are
    evaluated to validate that such actions make sense, and these calls
    happen recursively.
    
    The ovs-vswitchd userspace won't emit more than 16 recursion levels
    deep.  However, the module has no such limit and will happily accept
    limits larger than 16 levels nested.  Prevent this by tracking the
    number of recursions happening and manually limiting it to 16 levels
    nested.
    
    The initial implementation of the sample action would track this depth
    and prevent more than 3 levels of recursion, but this was removed to
    support the clone use case, rather than limited at the current userspace
    limit.
    
    Fixes: 798c166173ff ("openvswitch: Optimize sample action for the clone use cases")
    Signed-off-by: Aaron Conole <aconole@redhat.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240207132416.1488485-2-aconole@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: prevent mss overflow in skb_segment() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Dec 12 16:46:21 2023 +0000

    net: prevent mss overflow in skb_segment()
    
    commit 23d05d563b7e7b0314e65c8e882bc27eac2da8e7 upstream.
    
    Once again syzbot is able to crash the kernel in skb_segment() [1]
    
    GSO_BY_FRAGS is a forbidden value, but unfortunately the following
    computation in skb_segment() can reach it quite easily :
    
            mss = mss * partial_segs;
    
    65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
    a bad final result.
    
    Make sure to limit segmentation so that the new mss value is smaller
    than GSO_BY_FRAGS.
    
    [1]
    
    general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
    CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
    RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
    Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
    RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
    RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
    RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
    R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
    R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
    FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109
    ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120
    skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
    __skb_gso_segment+0x339/0x710 net/core/gso.c:124
    skb_gso_segment include/net/gso.h:83 [inline]
    validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626
    __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338
    dev_queue_xmit include/linux/netdevice.h:3134 [inline]
    packet_xmit+0x257/0x380 net/packet/af_packet.c:276
    packet_snd net/packet/af_packet.c:3087 [inline]
    packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190
    __do_sys_sendto net/socket.c:2202 [inline]
    __se_sys_sendto net/socket.c:2198 [inline]
    __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b
    RIP: 0033:0x7f8692032aa9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9
    RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003
    RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480
    R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003
    </TASK>
    Modules linked in:
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
    Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
    RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
    RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
    RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
    R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
    R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
    FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Fixes: 3953c46c3ac7 ("sk_buff: allow segmenting based on frag sizes")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20231212164621.4131800-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: stmmac: Wait a bit for the reset to take effect [+ + +]
Author: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date:   Mon Jan 22 19:19:09 2024 +0100

    net: stmmac: Wait a bit for the reset to take effect
    
    [ Upstream commit a5f5eee282a0aae80227697e1d9c811b1726d31d ]
    
    otherwise the synopsys_id value may be read out wrong,
    because the GMAC_VERSION register might still be in reset
    state, for at least 1 us after the reset is de-asserted.
    
    Add a wait for 10 us before continuing to be on the safe side.
    
    > From what have you got that delay value?
    
    Just try and error, with very old linux versions and old gcc versions
    the synopsys_id was read out correctly most of the time (but not always),
    with recent linux versions and recnet gcc versions it was read out
    wrongly most of the time, but again not always.
    I don't have access to the VHDL code in question, so I cannot
    tell why it takes so long to get the correct values, I also do not
    have more than a few hardware samples, so I cannot tell how long
    this timeout must be in worst case.
    Experimentally I can tell that the register is read several times
    as zero immediately after the reset is de-asserted, also adding several
    no-ops is not enough, adding a printk is enough, also udelay(1) seems to
    be enough but I tried that not very often, and I have not access to many
    hardware samples to be 100% sure about the necessary delay.
    And since the udelay here is only executed once per device instance,
    it seems acceptable to delay the boot for 10 us.
    
    BTW: my hardware's synopsys id is 0x37.
    
    Fixes: c5e4ddbdfa11 ("net: stmmac: Add support for optional reset control")
    Signed-off-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Link: https://lore.kernel.org/r/AS8P193MB1285A810BD78C111E7F6AA34E4752@AS8P193MB1285.EURP193.PROD.OUTLOOK.COM
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: xgmac: fix a typo of register name in DPP safety handling [+ + +]
Author: Furong Xu <0x1207@gmail.com>
Date:   Sat Feb 3 13:31:33 2024 +0800

    net: stmmac: xgmac: fix a typo of register name in DPP safety handling
    
    commit 1ce2654d87e2fb91fea83b288bd9b2641045e42a upstream.
    
    DDPP is copied from Synopsys Data book:
    
    DDPP: Disable Data path Parity Protection.
        When it is 0x0, Data path Parity Protection is enabled.
        When it is 0x1, Data path Parity Protection is disabled.
    
    The macro name should be XGMAC_DPP_DISABLE.
    
    Fixes: 46eba193d04f ("net: stmmac: xgmac: fix handling of DPP safety error for DMA channels")
    Signed-off-by: Furong Xu <0x1207@gmail.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Link: https://lore.kernel.org/r/20240203053133.1129236-1-0x1207@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: stmmac: xgmac: fix handling of DPP safety error for DMA channels [+ + +]
Author: Furong Xu <0x1207@gmail.com>
Date:   Wed Jan 31 10:08:28 2024 +0800

    net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
    
    [ Upstream commit 46eba193d04f8bd717e525eb4110f3c46c12aec3 ]
    
    Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in
    XGMAC core") checks and reports safety errors, but leaves the
    Data Path Parity Errors for each channel in DMA unhandled at all, lead to
    a storm of interrupt.
    Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.
    
    Fixes: 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core")
    Signed-off-by: Furong Xu <0x1207@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: xgmac: use #define for string constants [+ + +]
Author: Simon Horman <horms@kernel.org>
Date:   Thu Feb 8 09:48:27 2024 +0000

    net: stmmac: xgmac: use #define for string constants
    
    commit 1692b9775e745f84b69dc8ad0075b0855a43db4e upstream.
    
    The cited commit introduces and uses the string constants dpp_tx_err and
    dpp_rx_err. These are assigned to constant fields of the array
    dwxgmac3_error_desc.
    
    It has been reported that on GCC 6 and 7.5.0 this results in warnings
    such as:
    
      .../dwxgmac2_core.c:836:20: error: initialiser element is not constant
       { true, "TDPES0", dpp_tx_err },
    
    I have been able to reproduce this using: GCC 7.5.0, 8.4.0, 9.4.0 and 10.5.0.
    But not GCC 13.2.0.
    
    So it seems this effects older compilers but not newer ones.
    As Jon points out in his report, the minimum compiler supported by
    the kernel is GCC 5.1, so it does seem that this ought to be fixed.
    
    It is not clear to me what combination of 'const', if any, would address
    this problem.  So this patch takes of using #defines for the string
    constants
    
    Compile tested only.
    
    Fixes: 46eba193d04f ("net: stmmac: xgmac: fix handling of DPP safety error for DMA channels")
    Reported-by: Jon Hunter <jonathanh@nvidia.com>
    Closes: https://lore.kernel.org/netdev/c25eb595-8d91-40ea-9f52-efa15ebafdbc@nvidia.com/
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202402081135.lAxxBXHk-lkp@intel.com/
    Signed-off-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240208-xgmac-const-v1-1-e69a1eeabfc8@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: sysfs: Fix /sys/class/net/ path [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Wed Jan 31 02:21:49 2024 -0800

    net: sysfs: Fix /sys/class/net/<iface> path
    
    [ Upstream commit ae3f4b44641dfff969604735a0dcbf931f383285 ]
    
    The documentation is pointing to the wrong path for the interface.
    Documentation is pointing to /sys/class/<iface>, instead of
    /sys/class/net/<iface>.
    
    Fix it by adding the `net/` directory before the interface.
    
    Fixes: 1a02ef76acfa ("net: sysfs: add documentation entries for /sys/class/<iface>/queues")
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Link: https://lore.kernel.org/r/20240131102150.728960-2-leitao@debian.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: sysfs: Fix /sys/class/net/ path for statistics [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Fri Feb 9 01:55:18 2024 -0800

    net: sysfs: Fix /sys/class/net/<iface> path for statistics
    
    [ Upstream commit 5b3fbd61b9d1f4ed2db95aaf03f9adae0373784d ]
    
    The Documentation/ABI/testing/sysfs-class-net-statistics documentation
    is pointing to the wrong path for the interface.  Documentation is
    pointing to /sys/class/<iface>, instead of /sys/class/net/<iface>.
    
    Fix it by adding the `net/` directory before the interface.
    
    Fixes: 6044f9700645 ("net: sysfs: document /sys/class/net/statistics/*")
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: ipset: fix performance regression in swap operation [+ + +]
Author: Jozsef Kadlecsik <kadlec@netfilter.org>
Date:   Mon Jan 29 10:57:01 2024 +0100

    netfilter: ipset: fix performance regression in swap operation
    
    commit 97f7cf1cd80eeed3b7c808b7c12463295c751001 upstream.
    
    The patch "netfilter: ipset: fix race condition between swap/destroy
    and kernel side add/del/test", commit 28628fa9 fixes a race condition.
    But the synchronize_rcu() added to the swap function unnecessarily slows
    it down: it can safely be moved to destroy and use call_rcu() instead.
    
    Eric Dumazet pointed out that simply calling the destroy functions as
    rcu callback does not work: sets with timeout use garbage collectors
    which need cancelling at destroy which can wait. Therefore the destroy
    functions are split into two: cancelling garbage collectors safely at
    executing the command received by netlink and moving the remaining
    part only into the rcu callback.
    
    Link: https://lore.kernel.org/lkml/C0829B10-EAA6-4809-874E-E1E9C05A8D84@automattic.com/
    Fixes: 28628fa952fe ("netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test")
    Reported-by: Ale Crismani <ale.crismani@automattic.com>
    Reported-by: David Wang <00107082@163.com>
    Tested-by: David Wang <00107082@163.com>
    Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: ipset: Missing gc cancellations fixed [+ + +]
Author: Jozsef Kadlecsik <kadlec@netfilter.org>
Date:   Sun Feb 4 16:26:42 2024 +0100

    netfilter: ipset: Missing gc cancellations fixed
    
    commit 27c5a095e2518975e20a10102908ae8231699879 upstream.
    
    The patch fdb8e12cc2cc ("netfilter: ipset: fix performance regression
    in swap operation") missed to add the calls to gc cancellations
    at the error path of create operations and at module unload. Also,
    because the half of the destroy operations now executed by a
    function registered by call_rcu(), neither NFNL_SUBSYS_IPSET mutex
    or rcu read lock is held and therefore the checking of them results
    false warnings.
    
    Fixes: 97f7cf1cd80e ("netfilter: ipset: fix performance regression in swap operation")
    Reported-by: syzbot+52bbc0ad036f6f0d4a25@syzkaller.appspotmail.com
    Reported-by: Brad Spengler <spender@grsecurity.net>
    Reported-by: Стас Ничипорович <stasn77@gmail.com>
    Tested-by: Brad Spengler <spender@grsecurity.net>
    Tested-by: Стас Ничипорович <stasn77@gmail.com>
    Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_log: replace BUG_ON by WARN_ON_ONCE when putting logger [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Jan 29 11:09:43 2024 +0100

    netfilter: nf_log: replace BUG_ON by WARN_ON_ONCE when putting logger
    
    [ Upstream commit 259eb32971e9eb24d1777a28d82730659f50fdcb ]
    
    Module reference is bumped for each user, this should not ever happen.
    
    But BUG_ON check should use rcu_access_pointer() instead.
    
    If this ever happens, do WARN_ON_ONCE() instead of BUG_ON() and
    consolidate pointer check under the rcu read side lock section.
    
    Fixes: fab4085f4e24 ("netfilter: log: nf_log_packet() as real unified interface")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: reject QUEUE/DROP verdict parameters [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Sat Jan 20 22:50:04 2024 +0100

    netfilter: nf_tables: reject QUEUE/DROP verdict parameters
    
    commit f342de4e2f33e0e39165d8639387aa6c19dff660 upstream.
    
    This reverts commit e0abdadcc6e1.
    
    core.c:nf_hook_slow assumes that the upper 16 bits of NF_DROP
    verdicts contain a valid errno, i.e. -EPERM, -EHOSTUNREACH or similar,
    or 0.
    
    Due to the reverted commit, its possible to provide a positive
    value, e.g. NF_ACCEPT (1), which results in use-after-free.
    
    Its not clear to me why this commit was made.
    
    NF_QUEUE is not used by nftables; "queue" rules in nftables
    will result in use of "nft_queue" expression.
    
    If we later need to allow specifiying errno values from userspace
    (do not know why), this has to call NF_DROP_GETERR and check that
    "err <= 0" holds true.
    
    Fixes: e0abdadcc6e1 ("netfilter: nf_tables: accept QUEUE/DROP verdict parameters")
    Cc: stable@vger.kernel.org
    Reported-by: Notselwyn <notselwyn@pwning.tech>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: restrict anonymous set and map names to 16 bytes [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Jan 19 13:34:32 2024 +0100

    netfilter: nf_tables: restrict anonymous set and map names to 16 bytes
    
    [ Upstream commit b462579b2b86a8f5230543cadd3a4836be27baf7 ]
    
    nftables has two types of sets/maps, one where userspace defines the
    name, and anonymous sets/maps, where userspace defines a template name.
    
    For the latter, kernel requires presence of exactly one "%d".
    nftables uses "__set%d" and "__map%d" for this.  The kernel will
    expand the format specifier and replaces it with the smallest unused
    number.
    
    As-is, userspace could define a template name that allows to move
    the set name past the 256 bytes upperlimit (post-expansion).
    
    I don't see how this could be a problem, but I would prefer if userspace
    cannot do this, so add a limit of 16 bytes for the '%d' template name.
    
    16 bytes is the old total upper limit for set names that existed when
    nf_tables was merged initially.
    
    Fixes: 387454901bd6 ("netfilter: nf_tables: Allow set names of up to 255 chars")
    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>

netfilter: nf_tables: restrict tunnel object to NFPROTO_NETDEV [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Jan 23 23:45:32 2024 +0100

    netfilter: nf_tables: restrict tunnel object to NFPROTO_NETDEV
    
    [ Upstream commit 776d451648443f9884be4a1b4e38e8faf1c621f9 ]
    
    Bail out on using the tunnel dst template from other than netdev family.
    Add the infrastructure to check for the family in objects.
    
    Fixes: af308b94a2a4 ("netfilter: nf_tables: add tunnel support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: validate NFPROTO_* family [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Jan 23 16:38:25 2024 +0100

    netfilter: nf_tables: validate NFPROTO_* family
    
    [ Upstream commit d0009effa8862c20a13af4cb7475d9771b905693 ]
    
    Several expressions explicitly refer to NF_INET_* hook definitions
    from expr->ops->validate, however, family is not validated.
    
    Bail out with EOPNOTSUPP in case they are used from unsupported
    families.
    
    Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
    Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression")
    Fixes: 2fa841938c64 ("netfilter: nf_tables: introduce routing expression")
    Fixes: 554ced0a6e29 ("netfilter: nf_tables: add support for native socket matching")
    Fixes: ad49d86e07a4 ("netfilter: nf_tables: Add synproxy support")
    Fixes: 4ed8eb6570a4 ("netfilter: nf_tables: Add native tproxy support")
    Fixes: 6c47260250fc ("netfilter: nf_tables: add xfrm expression")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Jan 18 10:56:26 2024 +0100

    netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain
    
    commit 01acb2e8666a6529697141a6017edbf206921913 upstream.
    
    Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER
    event is reported, otherwise a stale reference to netdevice remains in
    the hook list.
    
    Fixes: 60a3815da702 ("netfilter: add inet ingress support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nft_compat: reject unused compat flag [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Feb 1 23:33:29 2024 +0100

    netfilter: nft_compat: reject unused compat flag
    
    [ Upstream commit 292781c3c5485ce33bd22b2ef1b2bed709b4d672 ]
    
    Flag (1 << 0) is ignored is set, never used, reject it it with EINVAL
    instead.
    
    Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_compat: restrict match/target protocol to u16 [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Feb 2 00:05:23 2024 +0100

    netfilter: nft_compat: restrict match/target protocol to u16
    
    [ Upstream commit d694b754894c93fb4d71a7f3699439dec111decc ]
    
    xt_check_{match,target} expects u16, but NFTA_RULE_COMPAT_PROTO is u32.
    
    NLA_POLICY_MAX(NLA_BE32, 65535) cannot be used because .max in
    nla_policy is s16, see 3e48be05f3c7 ("netlink: add attribute range
    validation to policy").
    
    Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_ct: reject direction for ct id [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Feb 5 14:59:24 2024 +0100

    netfilter: nft_ct: reject direction for ct id
    
    [ Upstream commit 38ed1c7062ada30d7c11e7a7acc749bf27aa14aa ]
    
    Direction attribute is ignored, reject it in case this ever needs to be
    supported
    
    Fixes: 3087c3f7c23b ("netfilter: nft_ct: Add ct id support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Jan 29 13:12:33 2024 +0100

    netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations
    
    [ Upstream commit 8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4 ]
    
    - Disallow families other than NFPROTO_{IPV4,IPV6,INET}.
    - Disallow layer 4 protocol with no ports, since destination port is a
      mandatory attribute for this object.
    
    Fixes: 857b46027d6f ("netfilter: nft_ct: add ct expectations support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_limit: reject configurations that cause integer overflow [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Jan 19 13:11:32 2024 +0100

    netfilter: nft_limit: reject configurations that cause integer overflow
    
    [ Upstream commit c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa ]
    
    Reject bogus configs where internal token counter wraps around.
    This only occurs with very very large requests, such as 17gbyte/s.
    
    Its better to reject this rather than having incorrect ratelimit.
    
    Fixes: d2168e849ebf ("netfilter: nft_limit: add per-byte limiting")
    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>

netfilter: nft_set_pipapo: add helper to release pcpu scratch area [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Feb 7 21:52:47 2024 +0100

    netfilter: nft_set_pipapo: add helper to release pcpu scratch area
    
    [ Upstream commit 47b1c03c3c1a119435480a1e73f27197dc59131d ]
    
    After next patch simple kfree() is not enough anymore, so add
    a helper for it.
    
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Stable-dep-of: 5a8cdf6fd860 ("netfilter: nft_set_pipapo: remove scratch_aligned pointer")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_set_pipapo: remove scratch_aligned pointer [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Thu Feb 8 10:31:29 2024 +0100

    netfilter: nft_set_pipapo: remove scratch_aligned pointer
    
    [ Upstream commit 5a8cdf6fd860ac5e6d08d72edbcecee049a7fec4 ]
    
    use ->scratch for both avx2 and the generic implementation.
    
    After previous change the scratch->map member is always aligned properly
    for AVX2, so we can just use scratch->map in AVX2 too.
    
    The alignoff delta is stored in the scratchpad so we can reconstruct
    the correct address to free the area again.
    
    Fixes: 7400b063969b ("nft_set_pipapo: Introduce AVX2-based lookup implementation")
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_set_pipapo: store index in scratch maps [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Feb 7 21:52:46 2024 +0100

    netfilter: nft_set_pipapo: store index in scratch maps
    
    [ Upstream commit 76313d1a4aa9e30d5b43dee5efd8bcd4d8250006 ]
    
    Pipapo needs a scratchpad area to keep state during matching.
    This state can be large and thus cannot reside on stack.
    
    Each set preallocates percpu areas for this.
    
    On each match stage, one scratchpad half starts with all-zero and the other
    is inited to all-ones.
    
    At the end of each stage, the half that starts with all-ones is
    always zero.  Before next field is tested, pointers to the two halves
    are swapped, i.e.  resmap pointer turns into fill pointer and vice versa.
    
    After the last field has been processed, pipapo stashes the
    index toggle in a percpu variable, with assumption that next packet
    will start with the all-zero half and sets all bits in the other to 1.
    
    This isn't reliable.
    
    There can be multiple sets and we can't be sure that the upper
    and lower half of all set scratch map is always in sync (lookups
    can be conditional), so one set might have swapped, but other might
    not have been queried.
    
    Thus we need to keep the index per-set-and-cpu, just like the
    scratchpad.
    
    Note that this bug fix is incomplete, there is a related issue.
    
    avx2 and normal implementation might use slightly different areas of the
    map array space due to the avx2 alignment requirements, so
    m->scratch (generic/fallback implementation) and ->scratch_aligned
    (avx) may partially overlap. scratch and scratch_aligned are not distinct
    objects, the latter is just the aligned address of the former.
    
    After this change, write to scratch_align->map_index may write to
    scratch->map, so this issue becomes more prominent, we can set to 1
    a bit in the supposedly-all-zero area of scratch->map[].
    
    A followup patch will remove the scratch_aligned and makes generic and
    avx code use the same (aligned) area.
    
    Its done in a separate change to ease review.
    
    Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges")
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_set_rbtree: skip end interval element from gc [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Feb 7 18:49:51 2024 +0100

    netfilter: nft_set_rbtree: skip end interval element from gc
    
    commit 60c0c230c6f046da536d3df8b39a20b9a9fd6af0 upstream.
    
    rbtree lazy gc on insert might collect an end interval element that has
    been just added in this transactions, skip end interval elements that
    are not yet active.
    
    Fixes: f718863aca46 ("netfilter: nft_set_rbtree: fix overlap expiration walk")
    Cc: stable@vger.kernel.org
    Reported-by: lonial con <kongln9170@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netlink: fix potential sleeping issue in mqueue_flush_file [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Mon Jan 22 09:18:07 2024 +0800

    netlink: fix potential sleeping issue in mqueue_flush_file
    
    [ Upstream commit 234ec0b6034b16869d45128b8cd2dc6ffe596f04 ]
    
    I analyze the potential sleeping issue of the following processes:
    Thread A                                Thread B
    ...                                     netlink_create  //ref = 1
    do_mq_notify                            ...
      sock = netlink_getsockbyfilp          ...     //ref = 2
      info->notify_sock = sock;             ...
    ...                                     netlink_sendmsg
    ...                                       skb = netlink_alloc_large_skb  //skb->head is vmalloced
    ...                                       netlink_unicast
    ...                                         sk = netlink_getsockbyportid //ref = 3
    ...                                         netlink_sendskb
    ...                                           __netlink_sendskb
    ...                                             skb_queue_tail //put skb to sk_receive_queue
    ...                                         sock_put //ref = 2
    ...                                     ...
    ...                                     netlink_release
    ...                                       deferred_put_nlk_sk //ref = 1
    mqueue_flush_file
      spin_lock
      remove_notification
        netlink_sendskb
          sock_put  //ref = 0
            sk_free
              ...
              __sk_destruct
                netlink_sock_destruct
                  skb_queue_purge  //get skb from sk_receive_queue
                    ...
                    __skb_queue_purge_reason
                      kfree_skb_reason
                        __kfree_skb
                        ...
                        skb_release_all
                          skb_release_head_state
                            netlink_skb_destructor
                              vfree(skb->head)  //sleeping while holding spinlock
    
    In netlink_sendmsg, if the memory pointed to by skb->head is allocated by
    vmalloc, and is put to sk_receive_queue queue, also the skb is not freed.
    When the mqueue executes flush, the sleeping bug will occur. Use
    vfree_atomic instead of vfree in netlink_skb_destructor to solve the issue.
    
    Fixes: c05cdb1b864f ("netlink: allow large data transfers from user-space")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Link: https://lore.kernel.org/r/20240122011807.2110357-1-shaozhengchao@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfc: nci: free rx_data_reassembly skb on NCI device cleanup [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Thu Jan 25 12:53:09 2024 +0300

    nfc: nci: free rx_data_reassembly skb on NCI device cleanup
    
    commit bfb007aebe6bff451f7f3a4be19f4f286d0d5d9c upstream.
    
    rx_data_reassembly skb is stored during NCI data exchange for processing
    fragmented packets. It is dropped only when the last fragment is processed
    or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
    However, the NCI device may be deallocated before that which leads to skb
    leak.
    
    As by design the rx_data_reassembly skb is bound to the NCI device and
    nothing prevents the device to be freed before the skb is processed in
    some way and cleaned, free it on the NCI device cleanup.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+6b7c68d9c21e4ee4251b@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/lkml/000000000000f43987060043da7b@google.com/
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfp: flower: prevent re-adding mac index for bonded port [+ + +]
Author: Daniel de Villiers <daniel.devilliers@corigine.com>
Date:   Fri Feb 2 13:37:18 2024 +0200

    nfp: flower: prevent re-adding mac index for bonded port
    
    commit 1a1c13303ff6d64e6f718dc8aa614e580ca8d9b4 upstream.
    
    When physical ports are reset (either through link failure or manually
    toggled down and up again) that are slaved to a Linux bond with a tunnel
    endpoint IP address on the bond device, not all tunnel packets arriving
    on the bond port are decapped as expected.
    
    The bond dev assigns the same MAC address to itself and each of its
    slaves. When toggling a slave device, the same MAC address is therefore
    offloaded to the NFP multiple times with different indexes.
    
    The issue only occurs when re-adding the shared mac. The
    nfp_tunnel_add_shared_mac() function has a conditional check early on
    that checks if a mac entry already exists and if that mac entry is
    global: (entry && nfp_tunnel_is_mac_idx_global(entry->index)). In the
    case of a bonded device (For example br-ex), the mac index is obtained,
    and no new index is assigned.
    
    We therefore modify the conditional in nfp_tunnel_add_shared_mac() to
    check if the port belongs to the LAG along with the existing checks to
    prevent a new global mac index from being re-assigned to the slave port.
    
    Fixes: 20cce8865098 ("nfp: flower: enable MAC address sharing for offloadable devs")
    CC: stable@vger.kernel.org # 5.1+
    Signed-off-by: Daniel de Villiers <daniel.devilliers@corigine.com>
    Signed-off-by: Louis Peens <louis.peens@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfp: use correct macro for LengthSelect in BAR config [+ + +]
Author: Daniel Basilio <daniel.basilio@corigine.com>
Date:   Fri Feb 2 13:37:17 2024 +0200

    nfp: use correct macro for LengthSelect in BAR config
    
    commit b3d4f7f2288901ed2392695919b3c0e24c1b4084 upstream.
    
    The 1st and 2nd expansion BAR configuration registers are configured,
    when the driver starts up, in variables 'barcfg_msix_general' and
    'barcfg_msix_xpb', respectively. The 'LengthSelect' field is ORed in
    from bit 0, which is incorrect. The 'LengthSelect' field should
    start from bit 27.
    
    This has largely gone un-noticed because
    NFP_PCIE_BAR_PCIE2CPP_LengthSelect_32BIT happens to be 0.
    
    Fixes: 4cb584e0ee7d ("nfp: add CPP access core")
    Cc: stable@vger.kernel.org # 4.11+
    Signed-off-by: Daniel Basilio <daniel.basilio@corigine.com>
    Signed-off-by: Louis Peens <louis.peens@corigine.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nilfs2: fix data corruption in dsync block recovery for small block sizes [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Jan 24 21:19:36 2024 +0900

    nilfs2: fix data corruption in dsync block recovery for small block sizes
    
    commit 67b8bcbaed4777871bb0dcc888fb02a614a98ab1 upstream.
    
    The helper function nilfs_recovery_copy_block() of
    nilfs_recovery_dsync_blocks(), which recovers data from logs created by
    data sync writes during a mount after an unclean shutdown, incorrectly
    calculates the on-page offset when copying repair data to the file's page
    cache.  In environments where the block size is smaller than the page
    size, this flaw can cause data corruption and leak uninitialized memory
    bytes during the recovery process.
    
    Fix these issues by correcting this byte offset calculation on the page.
    
    Link: https://lkml.kernel.org/r/20240124121936.10575-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Jan 31 23:56:57 2024 +0900

    nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
    
    commit 38296afe3c6ee07319e01bb249aa4bb47c07b534 upstream.
    
    Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
    and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
    
    While migrate_pages_batch() locks a folio and waits for the writeback to
    complete, the log writer thread that should bring the writeback to
    completion picks up the folio being written back in
    nilfs_lookup_dirty_data_buffers() that it calls for subsequent log
    creation and was trying to lock the folio.  Thus causing a deadlock.
    
    In the first place, it is unexpected that folios/pages in the middle of
    writeback will be updated and become dirty.  Nilfs2 adds a checksum to
    verify the validity of the log being written and uses it for recovery at
    mount, so data changes during writeback are suppressed.  Since this is
    broken, an unclean shutdown could potentially cause recovery to fail.
    
    Investigation revealed that the root cause is that the wait for writeback
    completion in nilfs_page_mkwrite() is conditional, and if the backing
    device does not require stable writes, data may be modified without
    waiting.
    
    Fix these issues by making nilfs_page_mkwrite() wait for writeback to
    finish regardless of the stable write requirement of the backing device.
    
    Link: https://lkml.kernel.org/r/20240131145657.4209-1-konishi.ryusuke@gmail.com
    Fixes: 1d1d1a767206 ("mm: only enforce stable page writes if the backing device requires it")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+ee2ae68da3b22d04cd8d@syzkaller.appspotmail.com
    Closes: https://lkml.kernel.org/r/00000000000047d819061004ad6c@google.com
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: fix potential bug in end_buffer_async_write [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sun Feb 4 01:16:45 2024 +0900

    nilfs2: fix potential bug in end_buffer_async_write
    
    commit 5bc09b397cbf1221f8a8aacb1152650c9195b02b upstream.
    
    According to a syzbot report, end_buffer_async_write(), which handles the
    completion of block device writes, may detect abnormal condition of the
    buffer async_write flag and cause a BUG_ON failure when using nilfs2.
    
    Nilfs2 itself does not use end_buffer_async_write().  But, the async_write
    flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue
    with race condition of competition between segments for dirty blocks") as
    a means of resolving double list insertion of dirty blocks in
    nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the
    resulting crash.
    
    This modification is safe as long as it is used for file data and b-tree
    node blocks where the page caches are independent.  However, it was
    irrelevant and redundant to also introduce async_write for segment summary
    and super root blocks that share buffers with the backing device.  This
    led to the possibility that the BUG_ON check in end_buffer_async_write
    would fail as described above, if independent writebacks of the backing
    device occurred in parallel.
    
    The use of async_write for segment summary buffers has already been
    removed in a previous change.
    
    Fix this issue by removing the manipulation of the async_write flag for
    the remaining super root block buffer.
    
    Link: https://lkml.kernel.org/r/20240203161645.4992-1-konishi.ryusuke@gmail.com
    Fixes: 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+5c04210f7c7f897c1e7f@syzkaller.appspotmail.com
    Closes: https://lkml.kernel.org/r/00000000000019a97c05fd42f8c8@google.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: replace WARN_ONs for invalid DAT metadata block requests [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Fri Jan 27 01:41:14 2023 +0900

    nilfs2: replace WARN_ONs for invalid DAT metadata block requests
    
    commit 5124a0a549857c4b87173280e192eea24dea72ad upstream.
    
    If DAT metadata file block access fails due to corruption of the DAT file
    or abnormal virtual block numbers held by b-trees or inodes, a kernel
    warning is generated.
    
    This replaces the WARN_ONs by error output, so that a kernel, booted with
    panic_on_warn, does not panic.  This patch also replaces the detected
    return code -ENOENT with another internal code -EINVAL to notify the bmap
    layer of metadata corruption.  When the bmap layer sees -EINVAL, it
    handles the abnormal situation with nilfs_bmap_convert_error() and finally
    returns code -EIO as it should.
    
    Link: https://lkml.kernel.org/r/0000000000005cc3d205ea23ddcf@google.com
    Link: https://lkml.kernel.org/r/20230126164114.6911-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: <syzbot+5d5d25f90f195a3cfcb4@syzkaller.appspotmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nouveau/vmm: don't set addr on the fail path to avoid warning [+ + +]
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Jan 18 06:19:57 2024 +1000

    nouveau/vmm: don't set addr on the fail path to avoid warning
    
    commit cacea81390fd8c8c85404e5eb2adeb83d87a912e upstream.
    
    nvif_vmm_put gets called if addr is set, but if the allocation
    fails we don't need to call put, otherwise we get a warning like
    
    [523232.435671] ------------[ cut here ]------------
    [523232.435674] WARNING: CPU: 8 PID: 1505697 at drivers/gpu/drm/nouveau/nvif/vmm.c:68 nvif_vmm_put+0x72/0x80 [nouveau]
    [523232.435795] Modules linked in: uinput rfcomm snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink qrtr bnep sunrpc binfmt_misc intel_rapl_msr intel_rapl_common intel_uncore_frequency intel_uncore_frequency_common isst_if_common iwlmvm nfit libnvdimm vfat fat x86_pkg_temp_thermal intel_powerclamp mac80211 snd_soc_avs snd_soc_hda_codec coretemp snd_hda_ext_core snd_soc_core snd_hda_codec_realtek kvm_intel snd_hda_codec_hdmi snd_compress snd_hda_codec_generic ac97_bus snd_pcm_dmaengine snd_hda_intel libarc4 snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec kvm iwlwifi snd_hda_core btusb snd_hwdep btrtl snd_seq btintel irqbypass btbcm rapl snd_seq_device eeepc_wmi btmtk intel_cstate iTCO_wdt cfg80211 snd_pcm asus_wmi bluetooth intel_pmc_bxt iTCO_vendor_support snd_timer ledtrig_audio pktcdvd snd mei_me
    [523232.435828]  sparse_keymap intel_uncore i2c_i801 platform_profile wmi_bmof mei pcspkr ioatdma soundcore i2c_smbus rfkill idma64 dca joydev acpi_tad loop zram nouveau drm_ttm_helper ttm video drm_exec drm_gpuvm gpu_sched crct10dif_pclmul i2c_algo_bit nvme crc32_pclmul crc32c_intel drm_display_helper polyval_clmulni nvme_core polyval_generic e1000e mxm_wmi cec ghash_clmulni_intel r8169 sha512_ssse3 nvme_common wmi pinctrl_sunrisepoint uas usb_storage ip6_tables ip_tables fuse
    [523232.435849] CPU: 8 PID: 1505697 Comm: gnome-shell Tainted: G        W          6.6.0-rc7-nvk-uapi+ #12
    [523232.435851] Hardware name: System manufacturer System Product Name/ROG STRIX X299-E GAMING II, BIOS 1301 09/24/2021
    [523232.435852] RIP: 0010:nvif_vmm_put+0x72/0x80 [nouveau]
    [523232.435934] Code: 00 00 48 89 e2 be 02 00 00 00 48 c7 04 24 00 00 00 00 48 89 44 24 08 e8 fc bf ff ff 85
    c0 75 0a 48 c7 43 08 00 00 00 00 eb b3 <0f> 0b eb f2 e8 f5 c9 b2 e6 0f 1f 44 00 00 90 90 90 90 90 90 90 90
    [523232.435936] RSP: 0018:ffffc900077ffbd8 EFLAGS: 00010282
    [523232.435937] RAX: 00000000fffffffe RBX: ffffc900077ffc00 RCX: 0000000000000010
    [523232.435938] RDX: 0000000000000010 RSI: ffffc900077ffb38 RDI: ffffc900077ffbd8
    [523232.435940] RBP: ffff888e1c4f2140 R08: 0000000000000000 R09: 0000000000000000
    [523232.435940] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888503811800
    [523232.435941] R13: ffffc900077ffca0 R14: ffff888e1c4f2140 R15: ffff88810317e1e0
    [523232.435942] FS:  00007f933a769640(0000) GS:ffff88905fa00000(0000) knlGS:0000000000000000
    [523232.435943] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [523232.435944] CR2: 00007f930bef7000 CR3: 00000005d0322001 CR4: 00000000003706e0
    [523232.435945] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [523232.435946] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [523232.435964] Call Trace:
    [523232.435965]  <TASK>
    [523232.435966]  ? nvif_vmm_put+0x72/0x80 [nouveau]
    [523232.436051]  ? __warn+0x81/0x130
    [523232.436055]  ? nvif_vmm_put+0x72/0x80 [nouveau]
    [523232.436138]  ? report_bug+0x171/0x1a0
    [523232.436142]  ? handle_bug+0x3c/0x80
    [523232.436144]  ? exc_invalid_op+0x17/0x70
    [523232.436145]  ? asm_exc_invalid_op+0x1a/0x20
    [523232.436149]  ? nvif_vmm_put+0x72/0x80 [nouveau]
    [523232.436230]  ? nvif_vmm_put+0x64/0x80 [nouveau]
    [523232.436342]  nouveau_vma_del+0x80/0xd0 [nouveau]
    [523232.436506]  nouveau_vma_new+0x1a0/0x210 [nouveau]
    [523232.436671]  nouveau_gem_object_open+0x1d0/0x1f0 [nouveau]
    [523232.436835]  drm_gem_handle_create_tail+0xd1/0x180
    [523232.436840]  drm_prime_fd_to_handle_ioctl+0x12e/0x200
    [523232.436844]  ? __pfx_drm_prime_fd_to_handle_ioctl+0x10/0x10
    [523232.436847]  drm_ioctl_kernel+0xd3/0x180
    [523232.436849]  drm_ioctl+0x26d/0x4b0
    [523232.436851]  ? __pfx_drm_prime_fd_to_handle_ioctl+0x10/0x10
    [523232.436855]  nouveau_drm_ioctl+0x5a/0xb0 [nouveau]
    [523232.437032]  __x64_sys_ioctl+0x94/0xd0
    [523232.437036]  do_syscall_64+0x5d/0x90
    [523232.437040]  ? syscall_exit_to_user_mode+0x2b/0x40
    [523232.437044]  ? do_syscall_64+0x6c/0x90
    [523232.437046]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
    Reported-by: Faith Ekstrand <faith.ekstrand@collabora.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240117213852.295565-1-airlied@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
octeontx2-af: Fix max NPC MCAM entry check while validating ref_entry [+ + +]
Author: Suman Ghosh <sumang@marvell.com>
Date:   Mon Jan 1 20:20:42 2024 +0530

    octeontx2-af: Fix max NPC MCAM entry check while validating ref_entry
    
    [ Upstream commit 4ebb1f95e0c3c3e0eec5bb21aa43097580c4b6e4 ]
    
    As of today, the last MCAM entry was not getting allocated because of
    a <= check with the max_bmap count. This patch modifies that and if the
    requested entry is greater than the available entries then set it to the
    max value.
    
    Signed-off-by: Suman Ghosh <sumang@marvell.com>
    Link: https://lore.kernel.org/r/20240101145042.419697-1-sumang@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-pf: Fix a memleak otx2_sq_init [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Thu Feb 1 20:47:13 2024 +0800

    octeontx2-pf: Fix a memleak otx2_sq_init
    
    [ Upstream commit b09b58e31b0f43d76f79b9943da3fb7c2843dcbb ]
    
    When qmem_alloc and pfvf->hw_ops->sq_aq_init fails, sq->sg should be
    freed to prevent memleak.
    
    Fixes: c9c12d339d93 ("octeontx2-pf: Add support for PTP clock")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Acked-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
of: property: fix typo in io-channels [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Tue Jan 23 16:14:22 2024 +0100

    of: property: fix typo in io-channels
    
    commit 8f7e917907385e112a845d668ae2832f41e64bf5 upstream.
    
    The property is io-channels and not io-channel. This was effectively
    preventing the devlink creation.
    
    Fixes: 8e12257dead7 ("of: property: Add device link support for iommus, mboxes and io-channels")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Reviewed-by: Saravana Kannan <saravanak@google.com>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20240123-iio-backend-v7-1-1bff236b8693@analog.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

of: unittest: Fix compile in the non-dynamic case [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Mon Jan 29 20:25:56 2024 +0100

    of: unittest: Fix compile in the non-dynamic case
    
    [ Upstream commit 607aad1e4356c210dbef9022955a3089377909b2 ]
    
    If CONFIG_OF_KOBJ is not set, a device_node does not contain a
    kobj and attempts to access the embedded kobj via kref_read break
    the compile.
    
    Replace affected kref_read calls with a macro that reads the
    refcount if it exists and returns 1 if there is no embedded kobj.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202401291740.VP219WIz-lkp@intel.com/
    Fixes: 4dde83569832 ("of: Fix double free in of_parse_phandle_with_args_map")
    Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
    Link: https://lore.kernel.org/r/20240129192556.403271-1-lk@c--e.de
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
overflow: Allow mixed type arguments [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Mon Aug 29 13:37:17 2022 -0700

    overflow: Allow mixed type arguments
    
    commit d219d2a9a92e39aa92799efe8f2aa21259b6dd82 upstream.
    
    When the check_[op]_overflow() helpers were introduced, all arguments
    were required to be the same type to make the fallback macros simpler.
    However, now that the fallback macros have been removed[1], it is fine
    to allow mixed types, which makes using the helpers much more useful,
    as they can be used to test for type-based overflows (e.g. adding two
    large ints but storing into a u8), as would be handy in the drm core[2].
    
    Remove the restriction, and add additional self-tests that exercise
    some of the mixed-type overflow cases, and double-check for accidental
    macro side-effects.
    
    [1] https://git.kernel.org/linus/4eb6bd55cfb22ffc20652732340c4962f3ac9a91
    [2] https://lore.kernel.org/lkml/20220824084514.2261614-2-gwan-gyeong.mun@intel.com
    
    Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
    Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: linux-hardening@vger.kernel.org
    Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
    Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
    Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    [ dropped the test portion of the commit as that doesn't apply to
      5.15.y - gregkh]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
parisc/firmware: Fix F-extend for PDC addresses [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Wed Jan 3 21:02:16 2024 +0100

    parisc/firmware: Fix F-extend for PDC addresses
    
    commit 735ae74f73e55c191d48689bd11ff4a06ea0508f upstream.
    
    When running with narrow firmware (64-bit kernel using a 32-bit
    firmware), extend PDC addresses into the 0xfffffff0.00000000
    region instead of the 0xf0f0f0f0.00000000 region.
    
    This fixes the power button on the C3700 machine in qemu (64-bit CPU
    with 32-bit firmware), and my assumption is that the previous code was
    really never used (because most 64-bit machines have a 64-bit firmware),
    or it just worked on very old machines because they may only decode
    40-bit of virtual addresses.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PCI/AER: Decode Requester ID when no error info found [+ + +]
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Wed Dec 6 16:42:30 2023 -0600

    PCI/AER: Decode Requester ID when no error info found
    
    [ Upstream commit 1291b716bbf969e101d517bfb8ba18d958f758b8 ]
    
    When a device with AER detects an error, it logs error information in its
    own AER Error Status registers.  It may send an Error Message to the Root
    Port (RCEC in the case of an RCiEP), which logs the fact that an Error
    Message was received (Root Error Status) and the Requester ID of the
    message source (Error Source Identification).
    
    aer_print_port_info() prints the Requester ID from the Root Port Error
    Source in the usual Linux "bb:dd.f" format, but when find_source_device()
    finds no error details in the hierarchy below the Root Port, it printed the
    raw Requester ID without decoding it.
    
    Decode the Requester ID in the usual Linux format so it matches other
    messages.
    
    Sample message changes:
    
      - pcieport 0000:00:1c.5: AER: Correctable error received: 0000:00:1c.5
      - pcieport 0000:00:1c.5: AER: can't find device of ID00e5
      + pcieport 0000:00:1c.5: AER: Correctable error message received from 0000:00:1c.5
      + pcieport 0000:00:1c.5: AER: found no error details for 0000:00:1c.5
    
    Link: https://lore.kernel.org/r/20231206224231.732765-3-helgaas@kernel.org
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI: add INTEL_HDA_ARL to pci_ids.h [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Dec 4 15:27:06 2023 -0600

    PCI: add INTEL_HDA_ARL to pci_ids.h
    
    [ Upstream commit 5ec42bf04d72fd6d0a6855810cc779e0ee31dfd7 ]
    
    The PCI ID insertion follows the increasing order in the table, but
    this hardware follows MTL (MeteorLake).
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Acked-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20231204212710.185976-2-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: Add no PM reset quirk for NVIDIA Spectrum devices [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Wed Nov 15 13:17:16 2023 +0100

    PCI: Add no PM reset quirk for NVIDIA Spectrum devices
    
    [ Upstream commit 3ed48c80b28d8dcd584d6ddaf00c75b7673e1a05 ]
    
    Spectrum-{1,2,3,4} devices report that a D3hot->D0 transition causes a
    reset (i.e., they advertise NoSoftRst-). However, this transition does
    not have any effect on the device: It continues to be operational and
    network ports remain up. Advertising this support makes it seem as if a
    PM reset is viable for these devices. Mark it as unavailable to skip it
    when testing reset methods.
    
    Before:
    
     # cat /sys/bus/pci/devices/0000\:03\:00.0/reset_method
     pm bus
    
    After:
    
     # cat /sys/bus/pci/devices/0000\:03\:00.0/reset_method
     bus
    
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Acked-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: Fix 64GT/s effective data rate calculation [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Tue Jan 2 19:27:00 2024 +0200

    PCI: Fix 64GT/s effective data rate calculation
    
    [ Upstream commit ac4f1897fa5433a1b07a625503a91b6aa9d7e643 ]
    
    Unlike the lower rates, the PCIe 64GT/s Data Rate uses 1b/1b encoding, not
    128b/130b (PCIe r6.1 sec 1.2, Table 1-1).  Correct the PCIE_SPEED2MBS_ENC()
    calculation to reflect that.
    
    Link: https://lore.kernel.org/r/20240102172701.65501-1-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: Only override AMD USB controller if required [+ + +]
Author: Guilherme G. Piccoli <gpiccoli@igalia.com>
Date:   Mon Nov 20 13:04:36 2023 -0300

    PCI: Only override AMD USB controller if required
    
    [ Upstream commit e585a37e5061f6d5060517aed1ca4ccb2e56a34c ]
    
    By running a Van Gogh device (Steam Deck), the following message
    was noticed in the kernel log:
    
      pci 0000:04:00.3: PCI class overridden (0x0c03fe -> 0x0c03fe) so dwc3 driver can claim this instead of xhci
    
    Effectively this means the quirk executed but changed nothing, since the
    class of this device was already the proper one (likely adjusted by newer
    firmware versions).
    
    Check and perform the override only if necessary.
    
    Link: https://lore.kernel.org/r/20231120160531.361552-1-gpiccoli@igalia.com
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Huang Rui <ray.huang@amd.com>
    Cc: Vicki Pfau <vi@endrift.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: switchtec: Fix stdev_release() crash after surprise hot remove [+ + +]
Author: Daniel Stodden <dns@arista.com>
Date:   Tue Nov 21 20:23:16 2023 -0800

    PCI: switchtec: Fix stdev_release() crash after surprise hot remove
    
    [ Upstream commit df25461119d987b8c81d232cfe4411e91dcabe66 ]
    
    A PCI device hot removal may occur while stdev->cdev is held open. The call
    to stdev_release() then happens during close or exit, at a point way past
    switchtec_pci_remove(). Otherwise the last ref would vanish with the
    trailing put_device(), just before return.
    
    At that later point in time, the devm cleanup has already removed the
    stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted
    one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause
    a fatal page fault, and the subsequent dma_free_coherent(), if reached,
    would pass a stale &stdev->pdev->dev pointer.
    
    Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after
    stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent
    future accidents.
    
    Reproducible via the script at
    https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com
    
    Link: https://lore.kernel.org/r/20231122042316.91208-2-dns@arista.com
    Signed-off-by: Daniel Stodden <dns@arista.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
    Reviewed-by: Dmitry Safonov <dima@arista.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf cs-etm: Bump minimum OpenCSD version to ensure a bugfix is present [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Fri Sep 1 14:37:15 2023 +0100

    perf cs-etm: Bump minimum OpenCSD version to ensure a bugfix is present
    
    [ Upstream commit 2dbba30fd69b604802a9535b74bddb5bcca23793 ]
    
    Since commit d927ef5004ef ("perf cs-etm: Add exception level consistency
    check"), the exception that was added to Perf will be triggered unless
    the following bugfix from OpenCSD is present:
    
     - _Version 1.2.1_:
      - __Bugfix__:
        ETM4x / ETE - output of context elements to client can in some
        circumstances be delayed until after subsequent atoms have been
        processed leading to incorrect memory decode access via the client
        callbacks. Fixed to flush context elements immediately they are
        committed.
    
    Rather than remove the assert and silently fail, just increase the
    minimum version requirement to avoid hard to debug issues and
    regressions.
    
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: James Clark <james.clark@arm.com>
    Tested-by: Leo Yan <leo.yan@linaro.org>
    Cc: John Garry <john.g.garry@oracle.com>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Will Deacon <will@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Link: https://lore.kernel.org/r/20230901133716.677499-1-james.clark@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/core: Fix narrow startup race when creating the perf nr_addr_filters sysfs file [+ + +]
Author: Greg KH <gregkh@linuxfoundation.org>
Date:   Mon Jun 12 15:09:09 2023 +0200

    perf/core: Fix narrow startup race when creating the perf nr_addr_filters sysfs file
    
    [ Upstream commit 652ffc2104ec1f69dd4a46313888c33527145ccf ]
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/2023061204-decal-flyable-6090@gregkh
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf: Fix the nr_addr_filters fix [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Wed Nov 22 11:07:56 2023 +0100

    perf: Fix the nr_addr_filters fix
    
    [ Upstream commit 388a1fb7da6aaa1970c7e2a7d7fcd983a87a8484 ]
    
    Thomas reported that commit 652ffc2104ec ("perf/core: Fix narrow
    startup race when creating the perf nr_addr_filters sysfs file") made
    the entire attribute group vanish, instead of only the nr_addr_filters
    attribute.
    
    Additionally a stray return.
    
    Insufficient coffee was involved with both writing and merging the
    patch.
    
    Fixes: 652ffc2104ec ("perf/core: Fix narrow startup race when creating the perf nr_addr_filters sysfs file")
    Reported-by: Thomas Richter <tmricht@linux.ibm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Tested-by: Thomas Richter <tmricht@linux.ibm.com>
    Link: https://lkml.kernel.org/r/20231122100756.GP8262@noisy.programming.kicks-ass.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phy: renesas: rcar-gen3-usb2: Fix returning wrong error code [+ + +]
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Fri Jan 5 18:37:03 2024 +0900

    phy: renesas: rcar-gen3-usb2: Fix returning wrong error code
    
    [ Upstream commit 249abaf3bf0dd07f5ddebbb2fe2e8f4d675f074e ]
    
    Even if device_create_file() returns error code,
    rcar_gen3_phy_usb2_probe() will return zero because the "ret" is
    variable shadowing.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Closes: https://lore.kernel.org/r/202312161021.gOLDl48K-lkp@intel.com/
    Fixes: 441a681b8843 ("phy: rcar-gen3-usb2: fix implementation for runtime PM")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20240105093703.3359949-1-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Sun Jan 28 14:05:54 2024 +0200

    phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
    
    [ Upstream commit 7104ba0f1958adb250319e68a15eff89ec4fd36d ]
    
    If the external phy working together with phy-omap-usb2 does not implement
    send_srp(), we may still attempt to call it. This can happen on an idle
    Ethernet gadget triggering a wakeup for example:
    
    configfs-gadget.g1 gadget.0: ECM Suspend
    configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
    ...
    Unable to handle kernel NULL pointer dereference at virtual address
    00000000 when execute
    ...
    PC is at 0x0
    LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
    ...
    musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
    usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
    eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
    dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
    sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
    __dev_queue_xmit from arp_solicit+0xf0/0x268
    arp_solicit from neigh_probe+0x54/0x7c
    neigh_probe from __neigh_event_send+0x22c/0x47c
    __neigh_event_send from neigh_resolve_output+0x14c/0x1c0
    neigh_resolve_output from ip_finish_output2+0x1c8/0x628
    ip_finish_output2 from ip_send_skb+0x40/0xd8
    ip_send_skb from udp_send_skb+0x124/0x340
    udp_send_skb from udp_sendmsg+0x780/0x984
    udp_sendmsg from __sys_sendto+0xd8/0x158
    __sys_sendto from ret_fast_syscall+0x0/0x58
    
    Let's fix the issue by checking for send_srp() and set_vbus() before
    calling them. For USB peripheral only cases these both could be NULL.
    
    Fixes: 657b306a7bdf ("usb: phy: add a new driver for omap usb2 phy")
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20240128120556.8848-1-tony@atomide.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pipe: wakeup wr_wait after setting max_usage [+ + +]
Author: Lukas Schauer <lukas@schauer.dev>
Date:   Fri Dec 1 11:11:28 2023 +0100

    pipe: wakeup wr_wait after setting max_usage
    
    [ Upstream commit e95aada4cb93d42e25c30a0ef9eb2923d9711d4a ]
    
    Commit c73be61cede5 ("pipe: Add general notification queue support") a
    regression was introduced that would lock up resized pipes under certain
    conditions. See the reproducer in [1].
    
    The commit resizing the pipe ring size was moved to a different
    function, doing that moved the wakeup for pipe->wr_wait before actually
    raising pipe->max_usage. If a pipe was full before the resize occured it
    would result in the wakeup never actually triggering pipe_write.
    
    Set @max_usage and @nr_accounted before waking writers if this isn't a
    watch queue.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=212295 [1]
    Link: https://lore.kernel.org/r/20231201-orchideen-modewelt-e009de4562c6@brauner
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Reviewed-by: David Howells <dhowells@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Lukas Schauer <lukas@schauer.dev>
    [Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues]
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PM / devfreq: Fix buffer overflow in trans_stat_show [+ + +]
Author: Christian Marangi <ansuelsmth@gmail.com>
Date:   Tue Oct 24 20:30:15 2023 +0200

    PM / devfreq: Fix buffer overflow in trans_stat_show
    
    [ Upstream commit 08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4 ]
    
    Fix buffer overflow in trans_stat_show().
    
    Convert simple snprintf to the more secure scnprintf with size of
    PAGE_SIZE.
    
    Add condition checking if we are exceeding PAGE_SIZE and exit early from
    loop. Also add at the end a warning that we exceeded PAGE_SIZE and that
    stats is disabled.
    
    Return -EFBIG in the case where we don't have enough space to write the
    full transition table.
    
    Also document in the ABI that this function can return -EFBIG error.
    
    Link: https://lore.kernel.org/all/20231024183016.14648-2-ansuelsmth@gmail.com/
    Cc: stable@vger.kernel.org
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218041
    Fixes: e552bbaf5b98 ("PM / devfreq: Add sysfs node for representing frequency transition information.")
    Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PM / devfreq: Synchronize devfreq_monitor_[start/stop] [+ + +]
Author: Mukesh Ojha <quic_mojha@quicinc.com>
Date:   Sat Nov 25 02:41:58 2023 +0530

    PM / devfreq: Synchronize devfreq_monitor_[start/stop]
    
    [ Upstream commit aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6 ]
    
    There is a chance if a frequent switch of the governor
    done in a loop result in timer list corruption where
    timer cancel being done from two place one from
    cancel_delayed_work_sync() and followed by expire_timers()
    can be seen from the traces[1].
    
    while true
    do
            echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor
            echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor
    done
    
    It looks to be issue with devfreq driver where
    device_monitor_[start/stop] need to synchronized so that
    delayed work should get corrupted while it is either
    being queued or running or being cancelled.
    
    Let's use polling flag and devfreq lock to synchronize the
    queueing the timer instance twice and work data being
    corrupted.
    
    [1]
    ...
    ..
    <idle>-0    [003]   9436.209662:  timer_cancel   timer=0xffffff80444f0428
    <idle>-0    [003]   9436.209664:  timer_expire_entry   timer=0xffffff80444f0428  now=0x10022da1c  function=__typeid__ZTSFvP10timer_listE_global_addr  baseclk=0x10022da1c
    <idle>-0    [003]   9436.209718:  timer_expire_exit   timer=0xffffff80444f0428
    kworker/u16:6-14217    [003]   9436.209863:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2b  now=0x10022da1c  flags=182452227
    vendor.xxxyyy.ha-1593    [004]   9436.209888:  timer_cancel   timer=0xffffff80444f0428
    vendor.xxxyyy.ha-1593    [004]   9436.216390:  timer_init   timer=0xffffff80444f0428
    vendor.xxxyyy.ha-1593    [004]   9436.216392:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2c  now=0x10022da1d  flags=186646532
    vendor.xxxyyy.ha-1593    [005]   9436.220992:  timer_cancel   timer=0xffffff80444f0428
    xxxyyyTraceManag-7795    [004]   9436.261641:  timer_cancel   timer=0xffffff80444f0428
    
    [2]
    
     9436.261653][    C4] Unable to handle kernel paging request at virtual address dead00000000012a
    [ 9436.261664][    C4] Mem abort info:
    [ 9436.261666][    C4]   ESR = 0x96000044
    [ 9436.261669][    C4]   EC = 0x25: DABT (current EL), IL = 32 bits
    [ 9436.261671][    C4]   SET = 0, FnV = 0
    [ 9436.261673][    C4]   EA = 0, S1PTW = 0
    [ 9436.261675][    C4] Data abort info:
    [ 9436.261677][    C4]   ISV = 0, ISS = 0x00000044
    [ 9436.261680][    C4]   CM = 0, WnR = 1
    [ 9436.261682][    C4] [dead00000000012a] address between user and kernel address ranges
    [ 9436.261685][    C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
    [ 9436.261701][    C4] Skip md ftrace buffer dump for: 0x3a982d0
    ...
    
    [ 9436.262138][    C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S      W  O      5.10.149-android12-9-o-g17f915d29d0c #1
    [ 9436.262141][    C4] Hardware name: Qualcomm Technologies, Inc.  (DT)
    [ 9436.262144][    C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)
    [ 9436.262161][    C4] pc : expire_timers+0x9c/0x438
    [ 9436.262164][    C4] lr : expire_timers+0x2a4/0x438
    [ 9436.262168][    C4] sp : ffffffc010023dd0
    [ 9436.262171][    C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18
    [ 9436.262178][    C4] x27: ffffffd063569dd0 x26: ffffffd063536008
    [ 9436.262182][    C4] x25: 0000000000000001 x24: ffffff88f7c69280
    [ 9436.262185][    C4] x23: 00000000000000e0 x22: dead000000000122
    [ 9436.262188][    C4] x21: 000000010022da29 x20: ffffff8af72b4e80
    [ 9436.262191][    C4] x19: ffffffc010023e50 x18: ffffffc010025038
    [ 9436.262195][    C4] x17: 0000000000000240 x16: 0000000000000201
    [ 9436.262199][    C4] x15: ffffffffffffffff x14: ffffff889f3c3100
    [ 9436.262203][    C4] x13: ffffff889f3c3100 x12: 00000000049f56b8
    [ 9436.262207][    C4] x11: 00000000049f56b8 x10: 00000000ffffffff
    [ 9436.262212][    C4] x9 : ffffffc010023e50 x8 : dead000000000122
    [ 9436.262216][    C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8
    [ 9436.262220][    C4] x5 : 0000000000000000 x4 : 0000000000000101
    [ 9436.262223][    C4] x3 : 0000000000000080 x2 : ffffff889edc155c
    [ 9436.262227][    C4] x1 : ffffff8001005200 x0 : ffffff80444f0428
    [ 9436.262232][    C4] Call trace:
    [ 9436.262236][    C4]  expire_timers+0x9c/0x438
    [ 9436.262240][    C4]  __run_timers+0x1f0/0x330
    [ 9436.262245][    C4]  run_timer_softirq+0x28/0x58
    [ 9436.262255][    C4]  efi_header_end+0x168/0x5ec
    [ 9436.262265][    C4]  __irq_exit_rcu+0x108/0x124
    [ 9436.262274][    C4]  __handle_domain_irq+0x118/0x1e4
    [ 9436.262282][    C4]  gic_handle_irq.30369+0x6c/0x2bc
    [ 9436.262286][    C4]  el0_irq_naked+0x60/0x6c
    
    Link: https://lore.kernel.org/all/1700860318-4025-1-git-send-email-quic_mojha@quicinc.com/
    Reported-by: Joyyoung Huang <huangzaiyang@oppo.com>
    Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
    Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PM: core: Remove unnecessary (void *) conversions [+ + +]
Author: Li zeming <zeming@nfschina.com>
Date:   Sun Mar 26 06:19:35 2023 +0800

    PM: core: Remove unnecessary (void *) conversions
    
    [ Upstream commit 73d73f5ee7fb0c42ff87091d105bee720a9565f1 ]
    
    Assignments from pointer variables of type (void *) do not require
    explicit type casts, so remove such type cases from the code in
    drivers/base/power/main.c where applicable.
    
    Signed-off-by: Li zeming <zeming@nfschina.com>
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 7839d0078e0d ("PM: sleep: Fix possible deadlocks in core system-wide PM code")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PM: hibernate: Enforce ordering during image compression/decompression [+ + +]
Author: Hongchen Zhang <zhanghongchen@loongson.cn>
Date:   Thu Nov 16 08:56:09 2023 +0800

    PM: hibernate: Enforce ordering during image compression/decompression
    
    commit 71cd7e80cfde548959952eac7063aeaea1f2e1c6 upstream.
    
    An S4 (suspend to disk) test on the LoongArch 3A6000 platform sometimes
    fails with the following error messaged in the dmesg log:
    
            Invalid LZO compressed length
    
    That happens because when compressing/decompressing the image, the
    synchronization between the control thread and the compress/decompress/crc
    thread is based on a relaxed ordering interface, which is unreliable, and the
    following situation may occur:
    
    CPU 0                                   CPU 1
    save_image_lzo                          lzo_compress_threadfn
                                              atomic_set(&d->stop, 1);
      atomic_read(&data[thr].stop)
      data[thr].cmp = data[thr].cmp_len;
                                              WRITE data[thr].cmp_len
    
    Then CPU0 gets a stale cmp_len and writes it to disk. During resume from S4,
    wrong cmp_len is loaded.
    
    To maintain data consistency between the two threads, use the acquire/release
    variants of atomic set and read operations.
    
    Fixes: 081a9d043c98 ("PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image")
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Hongchen Zhang <zhanghongchen@loongson.cn>
    Co-developed-by: Weihao Li <liweihao@loongson.cn>
    Signed-off-by: Weihao Li <liweihao@loongson.cn>
    [ rjw: Subject rewrite and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PM: runtime: Have devm_pm_runtime_enable() handle pm_runtime_dont_use_autosuspend() [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Tue Jan 30 18:28:46 2024 +0530

    PM: runtime: Have devm_pm_runtime_enable() handle pm_runtime_dont_use_autosuspend()
    
    [ Upstream commit b4060db9251f919506e4d672737c6b8ab9a84701 ]
    
    The PM Runtime docs say:
    
      Drivers in ->remove() callback should undo the runtime PM changes done
      in ->probe(). Usually this means calling pm_runtime_disable(),
      pm_runtime_dont_use_autosuspend() etc.
    
    >From grepping code, it's clear that many people aren't aware of the
    need to call pm_runtime_dont_use_autosuspend().
    
    When brainstorming solutions, one idea that came up was to leverage
    the new-ish devm_pm_runtime_enable() function. The idea here is that:
    
     * When the devm action is called we know that the driver is being
       removed. It's the perfect time to undo the use_autosuspend.
    
     * The code of pm_runtime_dont_use_autosuspend() already handles the
       case of being called when autosuspend wasn't enabled.
    
    Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 3d07a411b4fa ("drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks")
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PM: sleep: Fix possible deadlocks in core system-wide PM code [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Dec 27 21:41:06 2023 +0100

    PM: sleep: Fix possible deadlocks in core system-wide PM code
    
    [ Upstream commit 7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557 ]
    
    It is reported that in low-memory situations the system-wide resume core
    code deadlocks, because async_schedule_dev() executes its argument
    function synchronously if it cannot allocate memory (and not only in
    that case) and that function attempts to acquire a mutex that is already
    held.  Executing the argument function synchronously from within
    dpm_async_fn() may also be problematic for ordering reasons (it may
    cause a consumer device's resume callback to be invoked before a
    requisite supplier device's one, for example).
    
    Address this by changing the code in question to use
    async_schedule_dev_nocall() for scheduling the asynchronous
    execution of device suspend and resume functions and to directly
    run them synchronously if async_schedule_dev_nocall() returns false.
    
    Link: https://lore.kernel.org/linux-pm/ZYvjiqX6EsL15moe@perf/
    Reported-by: Youngmin Nam <youngmin.nam@samsung.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
    Tested-by: Youngmin Nam <youngmin.nam@samsung.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Cc: 5.7+ <stable@vger.kernel.org> # 5.7+: 6aa09a5bccd8 async: Split async_schedule_node_domain()
    Cc: 5.7+ <stable@vger.kernel.org> # 5.7+: 7d4b5d7a37bd async: Introduce async_schedule_dev_nocall()
    Cc: 5.7+ <stable@vger.kernel.org> # 5.7+
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pmdomain: core: Move the unused cleanup to a _sync initcall [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Wed Dec 27 16:21:24 2023 +0100

    pmdomain: core: Move the unused cleanup to a _sync initcall
    
    commit 741ba0134fa7822fcf4e4a0a537a5c4cfd706b20 upstream.
    
    The unused clock cleanup uses the _sync initcall to give all users at
    earlier initcalls time to probe. Do the same to avoid leaving some PDs
    dangling at "on" (which actually happened on qcom!).
    
    Fixes: 2fe71dcdfd10 ("PM / domains: Add late_initcall to disable unused PM domains")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231227-topic-pmdomain_sync_cleanup-v1-1-5f36769d538b@linaro.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PNP: ACPI: fix fortify warning [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Tue Nov 28 05:52:10 2023 +0300

    PNP: ACPI: fix fortify warning
    
    [ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ]
    
    When compiling with gcc version 14.0.0 20231126 (experimental)
    and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
    
    In file included from ./include/linux/string.h:295,
                     from ./include/linux/bitmap.h:12,
                     from ./include/linux/cpumask.h:12,
                     from ./arch/x86/include/asm/paravirt.h:17,
                     from ./arch/x86/include/asm/cpuid.h:62,
                     from ./arch/x86/include/asm/processor.h:19,
                     from ./arch/x86/include/asm/cpufeature.h:5,
                     from ./arch/x86/include/asm/thread_info.h:53,
                     from ./include/linux/thread_info.h:60,
                     from ./arch/x86/include/asm/preempt.h:9,
                     from ./include/linux/preempt.h:79,
                     from ./include/linux/spinlock.h:56,
                     from ./include/linux/mmzone.h:8,
                     from ./include/linux/gfp.h:7,
                     from ./include/linux/slab.h:16,
                     from ./include/linux/resource_ext.h:11,
                     from ./include/linux/acpi.h:13,
                     from drivers/pnp/pnpacpi/rsparser.c:11:
    In function 'fortify_memcpy_chk',
        inlined from 'pnpacpi_parse_allocated_vendor' at drivers/pnp/pnpacpi/rsparser.c:158:3,
        inlined from 'pnpacpi_allocated_resource' at drivers/pnp/pnpacpi/rsparser.c:249:3:
    ./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field'
    declared with attribute warning: detected read beyond size of field (2nd parameter);
    maybe use struct_group()? [-Wattribute-warning]
      588 |                         __read_overflow2_field(q_size_field, size);
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    According to the comments in include/linux/fortify-string.h, 'memcpy()',
    'memmove()' and 'memset()' must not be used beyond individual struct
    members to ensure that the compiler can enforce protection against
    buffer overflows, and, IIUC, this also applies to partial copies from
    the particular member ('vendor->byte_data' in this case). So it should
    be better (and safer) to do both copies at once (and 'byte_data' of
    'struct acpi_resource_vendor_typed' seems to be a good candidate for
    '__counted_by(byte_length)' as well).
    
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/64: Set task pt_regs->link to the LR value on scv entry [+ + +]
Author: Naveen N Rao <naveen@kernel.org>
Date:   Fri Feb 2 21:13:16 2024 +0530

    powerpc/64: Set task pt_regs->link to the LR value on scv entry
    
    commit aad98efd0b121f63a2e1c221dcb4d4850128c697 upstream.
    
    Nysal reported that userspace backtraces are missing in offcputime bcc
    tool. As an example:
        $ sudo ./bcc/tools/offcputime.py -uU
        Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end.
    
        ^C
            write
            -                python (9107)
                8
    
            write
            -                sudo (9105)
                9
    
            mmap
            -                python (9107)
                16
    
            clock_nanosleep
            -                multipathd (697)
                3001604
    
    The offcputime bcc tool attaches a bpf program to a kprobe on
    finish_task_switch(), which is usually hit on a syscall from userspace.
    With the switch to system call vectored, we started setting
    pt_regs->link to zero. This is because system call vectored behaves like
    a function call with LR pointing to the system call return address, and
    with no modification to SRR0/SRR1. The LR value does indicate our next
    instruction, so it is being saved as pt_regs->nip, and pt_regs->link is
    being set to zero. This is not a problem by itself, but BPF uses perf
    callchain infrastructure for capturing stack traces, and that stores LR
    as the second entry in the stack trace. perf has code to cope with the
    second entry being zero, and skips over it. However, generic userspace
    unwinders assume that a zero entry indicates end of the stack trace,
    resulting in a truncated userspace stack trace.
    
    Rather than fixing all userspace unwinders to ignore/skip past the
    second entry, store the real LR value in pt_regs->link so that there
    continues to be a valid, though duplicate entry in the stack trace.
    
    With this change:
        $ sudo ./bcc/tools/offcputime.py -uU
        Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end.
    
        ^C
            write
            write
            [unknown]
            [unknown]
            [unknown]
            [unknown]
            [unknown]
            PyObject_VectorcallMethod
            [unknown]
            [unknown]
            PyObject_CallOneArg
            PyFile_WriteObject
            PyFile_WriteString
            [unknown]
            [unknown]
            PyObject_Vectorcall
            _PyEval_EvalFrameDefault
            PyEval_EvalCode
            [unknown]
            [unknown]
            [unknown]
            _PyRun_SimpleFileObject
            _PyRun_AnyFileObject
            Py_RunMain
            [unknown]
            Py_BytesMain
            [unknown]
            __libc_start_main
            -                python (1293)
                7
    
            write
            write
            [unknown]
            sudo_ev_loop_v1
            sudo_ev_dispatch_v1
            [unknown]
            [unknown]
            [unknown]
            [unknown]
            __libc_start_main
            -                sudo (1291)
                7
    
            syscall
            syscall
            bpf_open_perf_buffer_opts
            [unknown]
            [unknown]
            [unknown]
            [unknown]
            _PyObject_MakeTpCall
            PyObject_Vectorcall
            _PyEval_EvalFrameDefault
            PyEval_EvalCode
            [unknown]
            [unknown]
            [unknown]
            _PyRun_SimpleFileObject
            _PyRun_AnyFileObject
            Py_RunMain
            [unknown]
            Py_BytesMain
            [unknown]
            __libc_start_main
            -                python (1293)
                11
    
            clock_nanosleep
            clock_nanosleep
            nanosleep
            sleep
            [unknown]
            [unknown]
            __clone
            -                multipathd (698)
                3001661
    
    Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions")
    Cc: stable@vger.kernel.org
    Reported-by: "Nysal Jan K.A" <nysal@linux.ibm.com>
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240202154316.395276-1-naveen@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/64s: Fix CONFIG_NUMA=n build due to create_section_mapping() [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Nov 30 00:19:19 2023 +1100

    powerpc/64s: Fix CONFIG_NUMA=n build due to create_section_mapping()
    
    [ Upstream commit ede66cd22441820cbd399936bf84fdc4294bc7fa ]
    
    With CONFIG_NUMA=n the build fails with:
    
      arch/powerpc/mm/book3s64/pgtable.c:275:15: error: no previous prototype for ‘create_section_mapping’ [-Werror=missing-prototypes]
      275 | int __meminit create_section_mapping(unsigned long start, unsigned long end,
          |               ^~~~~~~~~~~~~~~~~~~~~~
    
    That happens because the prototype for create_section_mapping() is in
    asm/mmzone.h, but asm/mmzone.h is only included by linux/mmzone.h
    when CONFIG_NUMA=y.
    
    In fact the prototype is only needed by arch/powerpc/mm code, so move
    the prototype into arch/powerpc/mm/mmu_decl.h, which also fixes the
    build error.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231129131919.2528517-5-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/kasan: Fix addr error caused by page alignment [+ + +]
Author: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Date:   Tue Jan 23 09:45:59 2024 +0800

    powerpc/kasan: Fix addr error caused by page alignment
    
    [ Upstream commit 4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0 ]
    
    In kasan_init_region, when k_start is not page aligned, at the begin of
    for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then
    `va = block + k_cur - k_start` is less than block, the addr va is invalid,
    because the memory address space from va to block is not alloced by
    memblock_alloc, which will not be reserved by memblock_reserve later, it
    will be used by other places.
    
    As a result, memory overwriting occurs.
    
    for example:
    int __init __weak kasan_init_region(void *start, size_t size)
    {
    [...]
            /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */
            block = memblock_alloc(k_end - k_start, PAGE_SIZE);
            [...]
            for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) {
                    /* at the begin of for loop
                     * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)
                     * va(dcd96c00) is less than block(dcd97000), va is invalid
                     */
                    void *va = block + k_cur - k_start;
                    [...]
            }
    [...]
    }
    
    Therefore, page alignment is performed on k_start before
    memblock_alloc() to ensure the validity of the VA address.
    
    Fixes: 663c0c9496a6 ("powerpc/kasan: Fix shadow area set up for modules.")
    Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/1705974359-43790-1-git-send-email-xiaojiangfeng@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/lib: Validate size for vector operations [+ + +]
Author: Naveen N Rao <naveen@kernel.org>
Date:   Thu Nov 23 12:47:05 2023 +0530

    powerpc/lib: Validate size for vector operations
    
    [ Upstream commit 8f9abaa6d7de0a70fc68acaedce290c1f96e2e59 ]
    
    Some of the fp/vmx code in sstep.c assume a certain maximum size for the
    instructions being emulated. The size of those operations however is
    determined separately in analyse_instr().
    
    Add a check to validate the assumption on the maximum size of the
    operations, so as to prevent any unintended kernel stack corruption.
    
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Build-tested-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231123071705.397625-1-naveen@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/mm: Fix build failures due to arch_reserved_kernel_pages() [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Nov 30 22:44:32 2023 +1100

    powerpc/mm: Fix build failures due to arch_reserved_kernel_pages()
    
    [ Upstream commit d8c3f243d4db24675b653f0568bb65dae34e6455 ]
    
    With NUMA=n and FA_DUMP=y or PRESERVE_FA_DUMP=y the build fails with:
    
      arch/powerpc/kernel/fadump.c:1739:22: error: no previous prototype for ‘arch_reserved_kernel_pages’ [-Werror=missing-prototypes]
      1739 | unsigned long __init arch_reserved_kernel_pages(void)
           |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~
    
    The prototype for arch_reserved_kernel_pages() is in include/linux/mm.h,
    but it's guarded by __HAVE_ARCH_RESERVED_KERNEL_PAGES. The powerpc
    headers define __HAVE_ARCH_RESERVED_KERNEL_PAGES in asm/mmzone.h, which
    is not included into the generic headers when NUMA=n.
    
    Move the definition of __HAVE_ARCH_RESERVED_KERNEL_PAGES into asm/mmu.h
    which is included regardless of NUMA=n.
    
    Additionally the ifdef around __HAVE_ARCH_RESERVED_KERNEL_PAGES needs to
    also check for CONFIG_PRESERVE_FA_DUMP.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231130114433.3053544-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/mm: Fix null-pointer dereference in pgtable_cache_add [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Mon Dec 4 10:32:23 2023 +0800

    powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
    
    [ Upstream commit f46c8a75263f97bda13c739ba1c90aced0d3b071 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure. Ensure the allocation was successful
    by checking the pointer validity.
    
    Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231204023223.2447523-1-chentao@kylinos.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc: Fix build error due to is_valid_bugaddr() [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Nov 30 22:44:33 2023 +1100

    powerpc: Fix build error due to is_valid_bugaddr()
    
    [ Upstream commit f8d3555355653848082c351fa90775214fb8a4fa ]
    
    With CONFIG_GENERIC_BUG=n the build fails with:
    
      arch/powerpc/kernel/traps.c:1442:5: error: no previous prototype for ‘is_valid_bugaddr’ [-Werror=missing-prototypes]
      1442 | int is_valid_bugaddr(unsigned long addr)
           |     ^~~~~~~~~~~~~~~~
    
    The prototype is only defined, and the function is only needed, when
    CONFIG_GENERIC_BUG=y, so move the implementation under that.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231130114433.3053544-2-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc: pmd_move_must_withdraw() is only needed for CONFIG_TRANSPARENT_HUGEPAGE [+ + +]
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date:   Mon Nov 27 13:28:09 2023 +1100

    powerpc: pmd_move_must_withdraw() is only needed for CONFIG_TRANSPARENT_HUGEPAGE
    
    [ Upstream commit 0d555b57ee660d8a871781c0eebf006e855e918d ]
    
    The linux-next build of powerpc64 allnoconfig fails with:
    
      arch/powerpc/mm/book3s64/pgtable.c:557:5: error: no previous prototype for 'pmd_move_must_withdraw'
        557 | int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
            |     ^~~~~~~~~~~~~~~~~~~~~~
    
    Caused by commit:
    
      c6345dfa6e3e ("Makefile.extrawarn: turn on missing-prototypes globally")
    
    Fix it by moving the function definition under
    CONFIG_TRANSPARENT_HUGEPAGE like the prototype. The function is only
    called when CONFIG_TRANSPARENT_HUGEPAGE=y.
    
    Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
    [mpe: Flesh out change log from linux-next patch]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231127132809.45c2b398@canb.auug.org.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ppp_async: limit MRU to 64K [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Feb 5 17:10:04 2024 +0000

    ppp_async: limit MRU to 64K
    
    [ Upstream commit cb88cb53badb8aeb3955ad6ce80b07b598e310b8 ]
    
    syzbot triggered a warning [1] in __alloc_pages():
    
    WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)
    
    Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")
    
    Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)
    
    [1]:
    
     WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
    Modules linked in:
    CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
    Workqueue: events_unbound flush_to_ldisc
    pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
     lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537
    sp : ffff800093967580
    x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000
    x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0
    x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8
    x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120
    x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005
    x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000
    x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001
    x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f
    x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020
    x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0
    Call trace:
      __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
      __alloc_pages_node include/linux/gfp.h:238 [inline]
      alloc_pages_node include/linux/gfp.h:261 [inline]
      __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926
      __do_kmalloc_node mm/slub.c:3969 [inline]
      __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001
      kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
      __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651
      __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715
      netdev_alloc_skb include/linux/skbuff.h:3235 [inline]
      dev_alloc_skb include/linux/skbuff.h:3248 [inline]
      ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]
      ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341
      tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390
      tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37
      receive_buf drivers/tty/tty_buffer.c:444 [inline]
      flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494
      process_one_work+0x694/0x1204 kernel/workqueue.c:2633
      process_scheduled_works kernel/workqueue.c:2706 [inline]
      worker_thread+0x938/0xef4 kernel/workqueue.c:2787
      kthread+0x288/0x310 kernel/kthread.c:388
      ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-and-tested-by: syzbot+c5da1f087c9e4ec6c933@syzkaller.appspotmail.com
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20240205171004.1059724-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pstore/ram: Fix crash when setting number of cpus to an odd number [+ + +]
Author: Weichen Chen <weichen.chen@mediatek.com>
Date:   Fri Feb 24 10:36:32 2023 +0800

    pstore/ram: Fix crash when setting number of cpus to an odd number
    
    [ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ]
    
    When the number of cpu cores is adjusted to 7 or other odd numbers,
    the zone size will become an odd number.
    The address of the zone will become:
        addr of zone0 = BASE
        addr of zone1 = BASE + zone_size
        addr of zone2 = BASE + zone_size*2
        ...
    The address of zone1/3/5/7 will be mapped to non-alignment va.
    Eventually crashes will occur when accessing these va.
    
    So, use ALIGN_DOWN() to make sure the zone size is even
    to avoid this bug.
    
    Signed-off-by: Weichen Chen <weichen.chen@mediatek.com>
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Tested-by: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
    Link: https://lore.kernel.org/r/20230224023632.6840-1-weichen.chen@mediatek.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rbd: don't move requests to the running list on errors [+ + +]
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Wed Jan 17 18:59:44 2024 +0100

    rbd: don't move requests to the running list on errors
    
    commit ded080c86b3f99683774af0441a58fc2e3d60cae upstream.
    
    The running list is supposed to contain requests that are pinning the
    exclusive lock, i.e. those that must be flushed before exclusive lock
    is released.  When wake_lock_waiters() is called to handle an error,
    requests on the acquiring list are failed with that error and no
    flushing takes place.  Briefly moving them to the running list is not
    only pointless but also harmful: if exclusive lock gets acquired
    before all of their state machines are scheduled and go through
    rbd_lock_del_request(), we trigger
    
        rbd_assert(list_empty(&rbd_dev->running_list));
    
    in rbd_try_acquire_lock().
    
    Cc: stable@vger.kernel.org
    Fixes: 637cd060537d ("rbd: new exclusive lock wait/wake code")
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Dongsheng Yang <dongsheng.yang@easystack.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/IPoIB: Fix error code return in ipoib_mcast_join [+ + +]
Author: Jack Wang <jinpu.wang@ionos.com>
Date:   Tue Nov 21 14:03:15 2023 +0100

    RDMA/IPoIB: Fix error code return in ipoib_mcast_join
    
    [ Upstream commit 753fff78f430704548f45eda52d6d55371a52c0f ]
    
    Return the error code in case of ib_sa_join_multicast fail.
    
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Link: https://lore.kernel.org/r/20231121130316.126364-2-jinpu.wang@ionos.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regulator: core: Only increment use_count when enable_count changes [+ + +]
Author: Rui Zhang <zr.zhang@vivo.com>
Date:   Fri Nov 3 15:42:31 2023 +0800

    regulator: core: Only increment use_count when enable_count changes
    
    [ Upstream commit 7993d3a9c34f609c02171e115fd12c10e2105ff4 ]
    
    The use_count of a regulator should only be incremented when the
    enable_count changes from 0 to 1. Similarly, the use_count should
    only be decremented when the enable_count changes from 1 to 0.
    
    In the previous implementation, use_count was sometimes decremented
    to 0 when some consumer called unbalanced disable,
    leading to unexpected disable even the regulator is enabled by
    other consumers. With this change, the use_count accurately reflects
    the number of users which the regulator is enabled.
    
    This should make things more robust in the case where a consumer does
    leak references.
    
    Signed-off-by: Rui Zhang <zr.zhang@vivo.com>
    Link: https://lore.kernel.org/r/20231103074231.8031-1-zr.zhang@vivo.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rename(): fix the locking of subdirectories [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Nov 19 20:25:58 2023 -0500

    rename(): fix the locking of subdirectories
    
    commit 22e111ed6c83dcde3037fc81176012721bc34c0b upstream.
    
            We should never lock two subdirectories without having taken
    ->s_vfs_rename_mutex; inode pointer order or not, the "order" proposed
    in 28eceeda130f "fs: Lock moved directories" is not transitive, with
    the usual consequences.
    
            The rationale for locking renamed subdirectory in all cases was
    the possibility of race between rename modifying .. in a subdirectory to
    reflect the new parent and another thread modifying the same subdirectory.
    For a lot of filesystems that's not a problem, but for some it can lead
    to trouble (e.g. the case when short directory contents is kept in the
    inode, but creating a file in it might push it across the size limit
    and copy its contents into separate data block(s)).
    
            However, we need that only in case when the parent does change -
    otherwise ->rename() doesn't need to do anything with .. entry in the
    first place.  Some instances are lazy and do a tautological update anyway,
    but it's really not hard to avoid.
    
    Amended locking rules for rename():
            find the parent(s) of source and target
            if source and target have the same parent
                    lock the common parent
            else
                    lock ->s_vfs_rename_mutex
                    lock both parents, in ancestor-first order; if neither
                    is an ancestor of another, lock the parent of source
                    first.
            find the source and target.
            if source and target have the same parent
                    if operation is an overwriting rename of a subdirectory
                            lock the target subdirectory
            else
                    if source is a subdirectory
                            lock the source
                    if target is a subdirectory
                            lock the target
            lock non-directories involved, in inode pointer order if both
            source and target are such.
    
    That way we are guaranteed that parents are locked (for obvious reasons),
    that any renamed non-directory is locked (nfsd relies upon that),
    that any victim is locked (emptiness check needs that, among other things)
    and subdirectory that changes parent is locked (needed to protect the update
    of .. entries).  We are also guaranteed that any operation locking more
    than one directory either takes ->s_vfs_rename_mutex or locks a parent
    followed by its child.
    
    Cc: stable@vger.kernel.org
    Fixes: 28eceeda130f "fs: Lock moved directories"
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "drm/amd: flush any delayed gfxoff on suspend entry" [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed Feb 7 23:52:54 2024 -0600

    Revert "drm/amd: flush any delayed gfxoff on suspend entry"
    
    commit 916361685319098f696b798ef1560f69ed96e934 upstream.
    
    commit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring
    callbacks") caused GFXOFF control to be used more heavily and the
    codepath that was removed from commit 0dee72639533 ("drm/amd: flush any
    delayed gfxoff on suspend entry") now can be exercised at suspend again.
    
    Users report that by using GNOME to suspend the lockscreen trigger will
    cause SDMA traffic and the system can deadlock.
    
    This reverts commit 0dee726395333fea833eaaf838bc80962df886c8.
    
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Fixes: ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring callbacks")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "selftests/bpf: Test tail call counting with bpf2bpf and data on stack" [+ + +]
Author: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Date:   Fri Feb 2 17:12:28 2024 -0800

    Revert "selftests/bpf: Test tail call counting with bpf2bpf and data on stack"
    
    This reverts commit 3eefb2fbf4ec1c1ff239b8b65e6e78aae335e4a6.
    
    libbpf support for "tc" progs doesn't exist for the linux-5.15.y tree.
    This commit was backported too far back in upstream, to a kernel where
    the libbpf support was not there for the test.
    
    Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ring-buffer: Clean ring_buffer_poll_wait() error return [+ + +]
Author: Vincent Donnefort <vdonnefort@google.com>
Date:   Wed Jan 31 14:09:55 2024 +0000

    ring-buffer: Clean ring_buffer_poll_wait() error return
    
    commit 66bbea9ed6446b8471d365a22734dc00556c4785 upstream.
    
    The return type for ring_buffer_poll_wait() is __poll_t. This is behind
    the scenes an unsigned where we can set event bits. In case of a
    non-allocated CPU, we do return instead -EINVAL (0xffffffea). Lucky us,
    this ends up setting few error bits (EPOLLERR | EPOLLHUP | EPOLLNVAL), so
    user-space at least is aware something went wrong.
    
    Nonetheless, this is an incorrect code. Replace that -EINVAL with a
    proper EPOLLERR to clean that output. As this doesn't change the
    behaviour, there's no need to treat this change as a bug fix.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240131140955.3322792-1-vdonnefort@google.com
    
    Cc: stable@vger.kernel.org
    Fixes: 6721cb6002262 ("ring-buffer: Do not poll non allocated cpu buffers")
    Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rpmsg: virtio: Free driver_override when rpmsg_remove() [+ + +]
Author: Xiaolei Wang <xiaolei.wang@windriver.com>
Date:   Fri Dec 15 10:00:49 2023 +0800

    rpmsg: virtio: Free driver_override when rpmsg_remove()
    
    commit d5362c37e1f8a40096452fc201c30e705750e687 upstream.
    
    Free driver_override when rpmsg_remove(), otherwise
    the following memory leak will occur:
    
    unreferenced object 0xffff0000d55d7080 (size 128):
      comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s)
      hex dump (first 32 bytes):
        72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00  rpmsg_ns........
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320
        [<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70
        [<00000000228a60c3>] kstrndup+0x4c/0x90
        [<0000000077158695>] driver_set_override+0xd0/0x164
        [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170
        [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30
        [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec
        [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280
        [<00000000443331cc>] really_probe+0xbc/0x2dc
        [<00000000391064b1>] __driver_probe_device+0x78/0xe0
        [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160
        [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140
        [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4
        [<000000003b929a36>] __device_attach+0x9c/0x19c
        [<00000000a94e0ba8>] device_initial_probe+0x14/0x20
        [<000000003c999637>] bus_probe_device+0xa0/0xac
    
    Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
    Fixes: b0b03b811963 ("rpmsg: Release rpmsg devices in backends")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20231215020049.78750-1-xiaolei.wang@windriver.com
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rtc: Adjust failure return code for cmos_set_alarm() [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Mon Nov 27 23:36:51 2023 -0600

    rtc: Adjust failure return code for cmos_set_alarm()
    
    commit 1311a8f0d4b23f58bbababa13623aa40b8ad4e0c upstream.
    
    When mc146818_avoid_UIP() fails to return a valid value, this is because
    UIP didn't clear in the timeout period. Adjust the return code in this
    case to -ETIMEDOUT.
    
    Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
    Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
    Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
    Cc:  <stable@vger.kernel.org>
    Fixes: cdedc45c579f ("rtc: cmos: avoid UIP when reading alarm time")
    Fixes: cd17420ebea5 ("rtc: cmos: avoid UIP when writing alarm time")
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20231128053653.101798-3-mario.limonciello@amd.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rxrpc: Fix response to PING RESPONSE ACKs to a dead call [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Fri Feb 2 15:19:15 2024 +0000

    rxrpc: Fix response to PING RESPONSE ACKs to a dead call
    
    [ Upstream commit 6f769f22822aa4124b556339781b04d810f0e038 ]
    
    Stop rxrpc from sending a DUP ACK in response to a PING RESPONSE ACK on a
    dead call.  We may have initiated the ping but the call may have beaten the
    response to completion.
    
    Fixes: 18bfeba50dfd ("rxrpc: Perform terminal call ACK/ABORT retransmission from conn processor")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: "David S. Miller" <davem@davemloft.net>
    cc: Eric Dumazet <edumazet@google.com>
    cc: Jakub Kicinski <kuba@kernel.org>
    cc: Paolo Abeni <pabeni@redhat.com>
    cc: linux-afs@lists.infradead.org
    cc: netdev@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rxrpc_find_service_conn_rcu: fix the usage of read_seqbegin_or_lock() [+ + +]
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Nov 17 17:48:46 2023 +0100

    rxrpc_find_service_conn_rcu: fix the usage of read_seqbegin_or_lock()
    
    [ Upstream commit bad1a11c0f061aa073bab785389fe04f19ba02e1 ]
    
    rxrpc_find_service_conn_rcu() should make the "seq" counter odd on the
    second pass, otherwise read_seqbegin_or_lock() never takes the lock.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: https://lore.kernel.org/r/20231117164846.GA10410@redhat.com/
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/ptrace: handle setting of fpc register correctly [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Thu Nov 30 18:55:59 2023 +0100

    s390/ptrace: handle setting of fpc register correctly
    
    [ Upstream commit 8b13601d19c541158a6e18b278c00ba69ae37829 ]
    
    If the content of the floating point control (fpc) register of a traced
    process is modified with the ptrace interface the new value is tested for
    validity by temporarily loading it into the fpc register.
    
    This may lead to corruption of the fpc register of the tracing process:
    if an interrupt happens while the value is temporarily loaded into the
    fpc register, and within interrupt context floating point or vector
    registers are used, the current fp/vx registers are saved with
    save_fpu_regs() assuming they belong to user space and will be loaded into
    fp/vx registers when returning to user space.
    
    test_fp_ctl() restores the original user space fpc register value, however
    it will be discarded, when returning to user space.
    
    In result the tracer will incorrectly continue to run with the value that
    was supposed to be used for the traced process.
    
    Fix this by saving fpu register contents with save_fpu_regs() before using
    test_fp_ctl().
    
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/qeth: Fix potential loss of L3-IP@ in case of network issues [+ + +]
Author: Alexandra Winter <wintera@linux.ibm.com>
Date:   Tue Feb 6 09:58:49 2024 +0100

    s390/qeth: Fix potential loss of L3-IP@ in case of network issues
    
    commit 2fe8a236436fe40d8d26a1af8d150fc80f04ee1a upstream.
    
    Symptom:
    In case of a bad cable connection (e.g. dirty optics) a fast sequence of
    network DOWN-UP-DOWN-UP could happen. UP triggers recovery of the qeth
    interface. In case of a second DOWN while recovery is still ongoing, it
    can happen that the IP@ of a Layer3 qeth interface is lost and will not
    be recovered by the second UP.
    
    Problem:
    When registration of IP addresses with Layer 3 qeth devices fails, (e.g.
    because of bad address format) the respective IP address is deleted from
    its hash-table in the driver. If registration fails because of a ENETDOWN
    condition, the address should stay in the hashtable, so a subsequent
    recovery can restore it.
    
    3caa4af834df ("qeth: keep ip-address after LAN_OFFLINE failure")
    fixes this for registration failures during normal operation, but not
    during recovery.
    
    Solution:
    Keep L3-IP address in case of ENETDOWN in qeth_l3_recover_ip(). For
    consistency with qeth_l3_add_ip() we also keep it in case of EADDRINUSE,
    i.e. for some reason the card already/still has this address registered.
    
    Fixes: 4a71df50047f ("qeth: new qeth device driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240206085849.2902775-1-wintera@linux.ibm.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sched/membarrier: reduce the ability to hammer on sys_membarrier [+ + +]
Author: Linus Torvalds <torvalds@linuxfoundation.org>
Date:   Sun Feb 4 15:25:12 2024 +0000

    sched/membarrier: reduce the ability to hammer on sys_membarrier
    
    commit 944d5fe50f3f03daacfea16300e656a1691c4a23 upstream.
    
    On some systems, sys_membarrier can be very expensive, causing overall
    slowdowns for everything.  So put a lock on the path in order to
    serialize the accesses to prevent the ability for this to be called at
    too high of a frequency and saturate the machine.
    
    Reviewed-and-tested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Acked-by: Borislav Petkov <bp@alien8.de>
    Fixes: 22e4ebb97582 ("membarrier: Provide expedited private command")
    Fixes: c5f58bd58f43 ("membarrier: Provide GLOBAL_EXPEDITED command")
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    [ converted to explicit mutex_*() calls - cleanup.h is not in this stable
      branch - gregkh ]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
scripts/decode_stacktrace.sh: optionally use LLVM utilities [+ + +]
Author: Carlos Llamas <cmllamas@google.com>
Date:   Fri Sep 29 03:48:17 2023 +0000

    scripts/decode_stacktrace.sh: optionally use LLVM utilities
    
    [ Upstream commit efbd6398353315b7018e6943e41fee9ec35e875f ]
    
    GNU's addr2line can have problems parsing a vmlinux built with LLVM,
    particularly when LTO was used.  In order to decode the traces correctly
    this patch adds the ability to switch to LLVM's utilities readelf and
    addr2line.  The same approach is followed by Will in [1].
    
    Before:
      $ scripts/decode_stacktrace.sh vmlinux < kernel.log
      [17716.240635] Call trace:
      [17716.240646] skb_cow_data (??:?)
      [17716.240654] esp6_input (ld-temp.o:?)
      [17716.240666] xfrm_input (ld-temp.o:?)
      [17716.240674] xfrm6_rcv (??:?)
      [...]
    
    After:
      $ LLVM=1 scripts/decode_stacktrace.sh vmlinux < kernel.log
      [17716.240635] Call trace:
      [17716.240646] skb_cow_data (include/linux/skbuff.h:2172 net/core/skbuff.c:4503)
      [17716.240654] esp6_input (net/ipv6/esp6.c:977)
      [17716.240666] xfrm_input (net/xfrm/xfrm_input.c:659)
      [17716.240674] xfrm6_rcv (net/ipv6/xfrm6_input.c:172)
      [...]
    
    Note that one could set CROSS_COMPILE=llvm- instead to hack around this
    issue.  However, doing so can break the decodecode routine as it will
    force the selection of other LLVM utilities down the line e.g.  llvm-as.
    
    [1] https://lore.kernel.org/all/20230914131225.13415-3-will@kernel.org/
    
    Link: https://lkml.kernel.org/r/20230929034836.403735-1-cmllamas@google.com
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
    Tested-by: Justin Stitt <justinstitt@google.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: John Stultz <jstultz@google.com>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Tom Rix <trix@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scripts/decode_stacktrace.sh: support old bash version [+ + +]
Author: Schspa Shi <schspa@gmail.com>
Date:   Fri Apr 29 14:37:57 2022 -0700

    scripts/decode_stacktrace.sh: support old bash version
    
    [ Upstream commit 3af8acf6aff2a98731522b52927429760f0b8006 ]
    
    Old bash version don't support associative array variables.  Avoid to use
    associative array variables to avoid error.
    
    Without this, old bash version will report error as fellowing
    [   15.954042] Kernel panic - not syncing: sysrq triggered crash
    [   15.955252] CPU: 1 PID: 167 Comm: sh Not tainted 5.18.0-rc1-00208-gb7d075db2fd5 #4
    [   15.956472] Hardware name: Hobot J5 Virtual development board (DT)
    [   15.957856] Call trace:
    ./scripts/decode_stacktrace.sh: line 128: ,dump_backtrace: syntax error: operand expected (error token is ",dump_backtrace")
    
    Link: https://lkml.kernel.org/r/20220409180331.24047-1-schspa@gmail.com
    Signed-off-by: Schspa Shi <schspa@gmail.com>
    Cc: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: efbd63983533 ("scripts/decode_stacktrace.sh: optionally use LLVM utilities")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scripts/get_abi: fix source path leak [+ + +]
Author: Vegard Nossum <vegard.nossum@oracle.com>
Date:   Mon Jan 1 00:59:58 2024 +0100

    scripts/get_abi: fix source path leak
    
    commit 5889d6ede53bc17252f79c142387e007224aa554 upstream.
    
    The code currently leaks the absolute path of the ABI files into the
    rendered documentation.
    
    There exists code to prevent this, but it is not effective when an
    absolute path is passed, which it is when $srctree is used.
    
    I consider this to be a minimal, stop-gap fix; a better fix would strip
    off the actual prefix instead of hacking it off with a regex.
    
    Link: https://mastodon.social/@vegard/111677490643495163
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Link: https://lore.kernel.org/r/20231231235959.3342928-1-vegard.nossum@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
scripts: decode_stacktrace: demangle Rust symbols [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Sun Dec 5 19:00:43 2021 +0100

    scripts: decode_stacktrace: demangle Rust symbols
    
    [ Upstream commit 99115db4ecc87af73415939439ec604ea0531e6f ]
    
    Recent versions of both Binutils (`c++filt`) and LLVM (`llvm-cxxfilt`)
    provide Rust v0 mangling support.
    
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com>
    Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com>
    Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com>
    Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com>
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Stable-dep-of: efbd63983533 ("scripts/decode_stacktrace.sh: optionally use LLVM utilities")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scs: add CONFIG_MMU dependency for vfree_atomic() [+ + +]
Author: Samuel Holland <samuel.holland@sifive.com>
Date:   Mon Jan 22 09:52:01 2024 -0800

    scs: add CONFIG_MMU dependency for vfree_atomic()
    
    commit 6f9dc684cae638dda0570154509884ee78d0f75c upstream.
    
    The shadow call stack implementation fails to build without CONFIG_MMU:
    
      ld.lld: error: undefined symbol: vfree_atomic
      >>> referenced by scs.c
      >>>               kernel/scs.o:(scs_free) in archive vmlinux.a
    
    Link: https://lkml.kernel.org/r/20240122175204.2371009-1-samuel.holland@sifive.com
    Fixes: a2abe7cbd8fe ("scs: switch to vmapped shadow stacks")
    Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
    Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
    Cc: Will Deacon <will@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>

 
scsi: arcmsr: Support new PCI device IDs 1883 and 1886 [+ + +]
Author: ching Huang <ching2048@areca.com.tw>
Date:   Mon Oct 2 17:50:27 2023 +0800

    scsi: arcmsr: Support new PCI device IDs 1883 and 1886
    
    [ Upstream commit 41c8a1a1e90fa4721f856bf3cf71211fd16d6434 ]
    
    Add support for Areca RAID controllers with PCI device IDs 1883 and 1886.
    
    Signed-off-by: ching Huang <ching2048@areca.com.tw>
    Link: https://lore.kernel.org/r/7732e743eaad57681b1552eec9c6a86c76dbe459.camel@areca.com.tw
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Fri Jan 12 15:00:00 2024 +0800

    scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler
    
    [ Upstream commit 4373534a9850627a2695317944898eb1283a2db0 ]
    
    Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host
    lock every time for deciding if error handler kthread needs to be waken up.
    
    This can be too heavy in case of recovery, such as:
    
     - N hardware queues
    
     - queue depth is M for each hardware queue
    
     - each scsi_host_busy() iterates over (N * M) tag/requests
    
    If recovery is triggered in case that all requests are in-flight, each
    scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called
    for the last in-flight request, scsi_host_busy() has been run for (N * M -
    1) times, and request has been iterated for (N*M - 1) * (N * M) times.
    
    If both N and M are big enough, hard lockup can be triggered on acquiring
    host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).
    
    Fix the issue by calling scsi_host_busy() outside the host lock. We don't
    need the host lock for getting busy count because host the lock never
    covers that.
    
    [mkp: Drop unnecessary 'busy' variables pointed out by Bart]
    
    Cc: Ewan Milne <emilne@redhat.com>
    Fixes: 6eb045e092ef ("scsi: core: avoid host-wide host_busy counter for scsi_mq")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20240112070000.4161982-1-ming.lei@redhat.com
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Reviewed-by: Sathya Prakash Veerichetty <safhya.prakash@broadcom.com>
    Tested-by: Sathya Prakash Veerichetty <safhya.prakash@broadcom.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: core: Move scsi_host_busy() out of host lock if it is for per-command [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Feb 3 10:45:21 2024 +0800

    scsi: core: Move scsi_host_busy() out of host lock if it is for per-command
    
    [ Upstream commit 4e6c9011990726f4d175e2cdfebe5b0b8cce4839 ]
    
    Commit 4373534a9850 ("scsi: core: Move scsi_host_busy() out of host lock
    for waking up EH handler") intended to fix a hard lockup issue triggered by
    EH. The core idea was to move scsi_host_busy() out of the host lock when
    processing individual commands for EH. However, a suggested style change
    inadvertently caused scsi_host_busy() to remain under the host lock. Fix
    this by calling scsi_host_busy() outside the lock.
    
    Fixes: 4373534a9850 ("scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler")
    Cc: Sathya Prakash Veerichetty <safhya.prakash@broadcom.com>
    Cc: Bart Van Assche <bvanassche@acm.org>
    Cc: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20240203024521.2006455-1-ming.lei@redhat.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: isci: Fix an error code problem in isci_io_request_build() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Fri Jan 12 12:19:27 2024 +0800

    scsi: isci: Fix an error code problem in isci_io_request_build()
    
    [ Upstream commit 658365c6b0857e6a306436e315a8633937e3af42 ]
    
    Clang static complains that Value stored to 'status' is never read. Return
    'status' rather than 'SCI_SUCCESS'.
    
    Fixes: f1f52e75939b ("isci: uplevel request infrastructure")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Link: https://lore.kernel.org/r/20240112041926.3924315-1-suhui@nfschina.com
    Reviewed-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: libfc: Don't schedule abort twice [+ + +]
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed Nov 29 17:58:30 2023 +0100

    scsi: libfc: Don't schedule abort twice
    
    [ Upstream commit b57c4db5d23b9df0118a25e2441c9288edd73710 ]
    
    The current FC error recovery is sending up to three REC (recovery) frames
    in 10 second intervals, and as a final step sending an ABTS after 30
    seconds for the command itself.  Unfortunately sending an ABTS is also the
    action for the SCSI abort handler, and the default timeout for SCSI
    commands is also 30 seconds. This causes two ABTS to be scheduled, with the
    libfc one slightly earlier. The ABTS scheduled by SCSI EH then sees the
    command to be already aborted, and will always return with a 'GOOD' status
    irrespective on the actual result from the first ABTS.  This causes the
    SCSI EH abort handler to always succeed, and SCSI EH never to be engaged.
    Fix this by not issuing an ABTS when a SCSI command is present for the
    exchange, but rather wait for the abort scheduled from SCSI EH.  And warn
    if an abort is already scheduled to avoid similar errors in the future.
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Link: https://lore.kernel.org/r/20231129165832.224100-2-hare@kernel.org
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: libfc: Fix up timeout error in fc_fcp_rec_error() [+ + +]
Author: Hannes Reinecke <hare@suse.de>
Date:   Wed Nov 29 17:58:31 2023 +0100

    scsi: libfc: Fix up timeout error in fc_fcp_rec_error()
    
    [ Upstream commit 53122a49f49796beb2c4a1bb702303b66347e29f ]
    
    We should set the status to FC_TIMED_OUT when a timeout error is passed to
    fc_fcp_rec_error().
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Link: https://lore.kernel.org/r/20231129165832.224100-3-hare@kernel.org
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: lpfc: Fix possible file string name overflow when updating firmware [+ + +]
Author: Justin Tee <justin.tee@broadcom.com>
Date:   Tue Oct 31 12:12:17 2023 -0700

    scsi: lpfc: Fix possible file string name overflow when updating firmware
    
    [ Upstream commit f5779b529240b715f0e358489ad0ed933bf77c97 ]
    
    Because file_name and phba->ModelName are both declared a size 80 bytes,
    the extra ".grp" file extension could cause an overflow into file_name.
    
    Define a ELX_FW_NAME_SIZE macro with value 84.  84 incorporates the 4 extra
    characters from ".grp".  file_name is changed to be declared as a char and
    initialized to zeros i.e. null chars.
    
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Link: https://lore.kernel.org/r/20231031191224.150862-3-justintee8345@gmail.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock" [+ + +]
Author: Lee Duncan <lduncan@suse.com>
Date:   Fri Feb 9 10:07:34 2024 -0800

    scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock"
    
    commit 977fe773dcc7098d8eaf4ee6382cb51e13e784cb upstream.
    
    This reverts commit 1a1975551943f681772720f639ff42fbaa746212.
    
    This commit causes interrupts to be lost for FCoE devices, since it changed
    sping locks from "bh" to "irqsave".
    
    Instead, a work queue should be used, and will be addressed in a separate
    commit.
    
    Fixes: 1a1975551943 ("scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock")
    Signed-off-by: Lee Duncan <lduncan@suse.com>
    Link: https://lore.kernel.org/r/c578cdcd46b60470535c4c4a953e6a1feca0dffd.1707500786.git.lduncan@suse.com
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: storvsc: Fix ring buffer size calculation [+ + +]
Author: Michael Kelley <mhklinux@outlook.com>
Date:   Mon Jan 22 09:09:56 2024 -0800

    scsi: storvsc: Fix ring buffer size calculation
    
    commit f4469f3858352ad1197434557150b1f7086762a0 upstream.
    
    Current code uses the specified ring buffer size (either the default of 128
    Kbytes or a module parameter specified value) to encompass the one page
    ring buffer header plus the actual ring itself.  When the page size is 4K,
    carving off one page for the header isn't significant.  But when the page
    size is 64K on ARM64, only half of the default 128 Kbytes is left for the
    actual ring.  While this doesn't break anything, the smaller ring size
    could be a performance bottleneck.
    
    Fix this by applying the VMBUS_RING_SIZE macro to the specified ring buffer
    size.  This macro adds a page for the header, and rounds up the size to a
    page boundary, using the page size for which the kernel is built.  Use this
    new size for subsequent ring buffer calculations.  For example, on ARM64
    with 64K page size and the default ring size, this results in the actual
    ring being 128 Kbytes, which is intended.
    
    Cc: stable@vger.kernel.org # 5.15.x
    Signed-off-by: Michael Kelley <mhklinux@outlook.com>
    Link: https://lore.kernel.org/r/20240122170956.496436-1-mhklinux@outlook.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: ufs: core: Remove the ufshcd_hba_exit() call from ufshcd_async_scan() [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Mon Dec 18 14:52:15 2023 -0800

    scsi: ufs: core: Remove the ufshcd_hba_exit() call from ufshcd_async_scan()
    
    [ Upstream commit ee36710912b2075c417100a8acc642c9c6496501 ]
    
    Calling ufshcd_hba_exit() from a function that is called asynchronously
    from ufshcd_init() is wrong because this triggers multiple race
    conditions. Instead of calling ufshcd_hba_exit(), log an error message.
    
    Reported-by: Daniel Mentz <danielmentz@google.com>
    Fixes: 1d337ec2f35e ("ufs: improve init sequence")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20231218225229.2542156-3-bvanassche@acm.org
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: core: Simplify power management during async scan [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Mon Dec 18 14:52:14 2023 -0800

    scsi: ufs: core: Simplify power management during async scan
    
    [ Upstream commit daf7795406bf307997366f694888bd317ae5b5fa ]
    
    ufshcd_init() calls pm_runtime_get_sync() before it calls
    async_schedule(). ufshcd_async_scan() calls pm_runtime_put_sync() directly
    or indirectly from ufshcd_add_lus(). Simplify ufshcd_async_scan() by always
    calling pm_runtime_put_sync() from ufshcd_async_scan().
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20231218225229.2542156-2-bvanassche@acm.org
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Stable-dep-of: ee36710912b2 ("scsi: ufs: core: Remove the ufshcd_hba_exit() call from ufshcd_async_scan()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/bpf: Fix issues in setup_classid_environment() [+ + +]
Author: Yafang Shao <laoar.shao@gmail.com>
Date:   Sat Nov 11 09:00:30 2023 +0000

    selftests/bpf: Fix issues in setup_classid_environment()
    
    [ Upstream commit 4849775587844e44d215289c425bcd70f315efe7 ]
    
    If the net_cls subsystem is already mounted, attempting to mount it again
    in setup_classid_environment() will result in a failure with the error code
    EBUSY. Despite this, tmpfs will have been successfully mounted at
    /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory
    will be empty, causing subsequent setup operations to fail.
    
    Here's an error log excerpt illustrating the issue when net_cls has already
    been mounted at /sys/fs/cgroup/net_cls prior to running
    setup_classid_environment():
    
    - Before that change
    
      $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2
      test_cgroup_v1v2:PASS:server_fd 0 nsec
      test_cgroup_v1v2:PASS:client_fd 0 nsec
      test_cgroup_v1v2:PASS:cgroup_fd 0 nsec
      test_cgroup_v1v2:PASS:server_fd 0 nsec
      run_test:PASS:skel_open 0 nsec
      run_test:PASS:prog_attach 0 nsec
      test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec
      (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs
      (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid
      run_test:PASS:skel_open 0 nsec
      run_test:PASS:prog_attach 0 nsec
      (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs
      run_test:FAIL:join_classid unexpected error: 1 (errno 2)
      test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2)
      (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs
      #44      cgroup_v1v2:FAIL
      Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED
    
    - After that change
      $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2
      #44      cgroup_v1v2:OK
      Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED
    
    Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
    Link: https://lore.kernel.org/r/20231111090034.4248-3-laoar.shao@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/bpf: Fix pyperf180 compilation failure with clang18 [+ + +]
Author: Yonghong Song <yonghong.song@linux.dev>
Date:   Fri Nov 10 11:36:44 2023 -0800

    selftests/bpf: Fix pyperf180 compilation failure with clang18
    
    [ Upstream commit 100888fb6d8a185866b1520031ee7e3182b173de ]
    
    With latest clang18 (main branch of llvm-project repo), when building bpf selftests,
        [~/work/bpf-next (master)]$ make -C tools/testing/selftests/bpf LLVM=1 -j
    
    The following compilation error happens:
        fatal error: error in backend: Branch target out of insn range
        ...
        Stack dump:
        0.      Program arguments: clang -g -Wall -Werror -D__TARGET_ARCH_x86 -mlittle-endian
          -I/home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include
          -I/home/yhs/work/bpf-next/tools/testing/selftests/bpf -I/home/yhs/work/bpf-next/tools/include/uapi
          -I/home/yhs/work/bpf-next/tools/testing/selftests/usr/include -idirafter
          /home/yhs/work/llvm-project/llvm/build.18/install/lib/clang/18/include -idirafter /usr/local/include
          -idirafter /usr/include -Wno-compare-distinct-pointer-types -DENABLE_ATOMICS_TESTS -O2 --target=bpf
          -c progs/pyperf180.c -mcpu=v3 -o /home/yhs/work/bpf-next/tools/testing/selftests/bpf/pyperf180.bpf.o
        1.      <eof> parser at end of file
        2.      Code generation
        ...
    
    The compilation failure only happens to cpu=v2 and cpu=v3. cpu=v4 is okay
    since cpu=v4 supports 32-bit branch target offset.
    
    The above failure is due to upstream llvm patch [1] where some inlining behavior
    are changed in clang18.
    
    To workaround the issue, previously all 180 loop iterations are fully unrolled.
    The bpf macro __BPF_CPU_VERSION__ (implemented in clang18 recently) is used to avoid
    unrolling changes if cpu=v4. If __BPF_CPU_VERSION__ is not available and the
    compiler is clang18, the unrollng amount is unconditionally reduced.
    
      [1] https://github.com/llvm/llvm-project/commit/1a2e77cf9e11dbf56b5720c607313a566eebb16e
    
    Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Tested-by: Alan Maguire <alan.maguire@oracle.com>
    Link: https://lore.kernel.org/bpf/20231110193644.3130906-1-yonghong.song@linux.dev
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/bpf: satisfy compiler by having explicit return in btf test [+ + +]
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Wed Nov 1 20:37:44 2023 -0700

    selftests/bpf: satisfy compiler by having explicit return in btf test
    
    [ Upstream commit f4c7e887324f5776eef6e6e47a90e0ac8058a7a8 ]
    
    Some compilers complain about get_pprint_mapv_size() not returning value
    in some code paths. Fix with explicit return.
    
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/r/20231102033759.2541186-3-andrii@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/sgx: Fix linker script asserts [+ + +]
Author: Jo Van Bulck <jo.vanbulck@cs.kuleuven.be>
Date:   Thu Oct 5 17:38:50 2023 +0200

    selftests/sgx: Fix linker script asserts
    
    [ Upstream commit 9fd552ee32c6c1e27c125016b87d295bea6faea7 ]
    
    DEFINED only considers symbols, not section names. Hence, replace the
    check for .got.plt with the _GLOBAL_OFFSET_TABLE_ symbol and remove other
    (non-essential) asserts.
    
    Signed-off-by: Jo Van Bulck <jo.vanbulck@cs.kuleuven.be>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Link: https://lore.kernel.org/all/20231005153854.25566-10-jo.vanbulck%40cs.kuleuven.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: net: avoid just another constant wait [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 1 19:42:41 2024 +0100

    selftests: net: avoid just another constant wait
    
    [ Upstream commit 691bb4e49c98a47bc643dd808453136ce78b15b4 ]
    
    Using hard-coded constant timeout to wait for some expected
    event is deemed to fail sooner or later, especially in slow
    env.
    
    Our CI has spotted another of such race:
       # TEST: ipv6: cleanup of cached exceptions - nexthop objects          [FAIL]
       #   can't delete veth device in a timely manner, PMTU dst likely leaked
    
    Replace the crude sleep with a loop looking for the expected condition
    at low interval for a much longer range.
    
    Fixes: b3cc4f8a8a41 ("selftests: pmtu: add explicit tests for PMTU exceptions cleanup")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/fd5c745e9bb665b724473af6a9373a8c2a62b247.1706812005.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: cut more slack for gro fwd tests. [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 1 19:42:38 2024 +0100

    selftests: net: cut more slack for gro fwd tests.
    
    [ Upstream commit cb9f4a30fb85e1f4f149ada595a67899adb3db19 ]
    
    The udpgro_fwd.sh self-tests are somewhat unstable. There are
    a few timing constraints the we struggle to meet on very slow
    environments.
    
    Instead of skipping the whole tests in such envs, increase the
    test resilience WRT very slow hosts: increase the inter-packets
    timeouts, avoid resetting the counters every second and finally
    disable reduce the background traffic noise.
    
    Tested with:
    
    for I in $(seq 1 100); do
            ./tools/testing/selftests/kselftest_install/run_kselftest.sh \
                    -t net:udpgro_fwd.sh || exit -1
    done
    
    in a slow environment.
    
    Fixes: a062260a9d5f ("selftests: net: add UDP GRO forwarding self-tests")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/f4b6b11064a0d39182a9ae6a853abae3e9b4426a.1706812005.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: fix available tunnels detection [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Jan 30 18:47:17 2024 +0100

    selftests: net: fix available tunnels detection
    
    [ Upstream commit e4e4b6d568d2549583cbda3f8ce567e586cb05da ]
    
    The pmtu.sh test tries to detect the tunnel protocols available
    in the running kernel and properly skip the unsupported cases.
    
    In a few more complex setup, such detection is unsuccessful, as
    the script currently ignores some intermediate error code at
    setup time.
    
    Before:
      # which: no nettest in (/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin)
      # TEST: vti6: PMTU exceptions (ESP-in-UDP)                            [FAIL]
      #   PMTU exception wasn't created after creating tunnel exceeding link layer MTU
      # ./pmtu.sh: line 931: kill: (7543) - No such process
      # ./pmtu.sh: line 931: kill: (7544) - No such process
    
    After:
      #   xfrm4 not supported
      # TEST: vti4: PMTU exceptions                                         [SKIP]
    
    Fixes: ece1278a9b81 ("selftests: net: add ESP-in-UDP PMTU test")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/cab10e75fda618e6fff8c595b632f47db58b9309.1706635101.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: give more time for GRO aggregation [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Jan 25 19:09:06 2024 +0100

    selftests: net: give more time for GRO aggregation
    
    [ Upstream commit 89abe628375301fedb68770644df845d49018d8b ]
    
    The gro.sh test-case relay on the gro_flush_timeout to ensure
    that all the segments belonging to any given batch are properly
    aggregated.
    
    The other end, the sender is a user-space program transmitting
    each packet with a separate write syscall. A busy host and/or
    stracing the sender program can make the relevant segments reach
    the GRO engine after the flush timeout triggers.
    
    Give the GRO flush timeout more slack, to avoid sporadic self-tests
    failures.
    
    Fixes: 9af771d2ec04 ("selftests/net: allow GRO coalesce test on veth")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/bffec2beab3a5672dd13ecabe4fad81d2155b367.1706206101.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: netdevsim: fix the udp_tunnel_nic test [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Mon Jan 22 22:05:29 2024 -0800

    selftests: netdevsim: fix the udp_tunnel_nic test
    
    [ Upstream commit 0879020a7817e7ce636372c016b4528f541c9f4d ]
    
    This test is missing a whole bunch of checks for interface
    renaming and one ifup. Presumably it was only used on a system
    with renaming disabled and NetworkManager running.
    
    Fixes: 91f430b2c49d ("selftests: net: add a test for UDP tunnel info infra")
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240123060529.1033912-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: 8250_exar: Fill in rs485_supported [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon Jun 6 13:04:04 2022 +0300

    serial: 8250_exar: Fill in rs485_supported
    
    [ Upstream commit 59c221f8e1269278161313048c71929c9950b2c4 ]
    
    Add information on supported serial_rs485 features.
    
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220606100433.13793-8-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 0c2a5f471ce5 ("serial: 8250_exar: Set missing rs485_supported flag")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: 8250_exar: Set missing rs485_supported flag [+ + +]
Author: Lino Sanfilippo <l.sanfilippo@kunbus.com>
Date:   Wed Jan 3 07:18:18 2024 +0100

    serial: 8250_exar: Set missing rs485_supported flag
    
    [ Upstream commit 0c2a5f471ce58bca8f8ab5fcb911aff91eaaa5eb ]
    
    The UART supports an auto-RTS mode in which the RTS pin is automatically
    activated during transmission. So mark this mode as being supported even
    if RTS is not controlled by the driver but the UART.
    
    Also the serial core expects now at least one of both modes rts-on-send or
    rts-after-send to be supported. This is since during sanitization
    unsupported flags are deleted from a RS485 configuration set by userspace.
    However if the configuration ends up with both flags unset, the core prints
    a warning since it considers such a configuration invalid (see
    uart_sanitize_serial_rs485()).
    
    Cc:  <stable@vger.kernel.org>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
    Link: https://lore.kernel.org/r/20240103061818.564-8-l.sanfilippo@kunbus.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: max310x: fail probe if clock crystal is unstable [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Tue Jan 16 16:30:00 2024 -0500

    serial: max310x: fail probe if clock crystal is unstable
    
    commit 8afa6c6decea37e7cb473d2c60473f37f46cea35 upstream.
    
    A stable clock is really required in order to use this UART, so log an
    error message and bail out if the chip reports that the clock is not
    stable.
    
    Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
    Cc: stable@vger.kernel.org
    Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
    Link: https://www.spinics.net/lists/linux-serial/msg35773.html
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20240116213001.3691629-4-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: max310x: improve crystal stable clock detection [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Tue Jan 16 16:29:59 2024 -0500

    serial: max310x: improve crystal stable clock detection
    
    commit 93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 upstream.
    
    Some people are seeing a warning similar to this when using a crystal:
    
        max310x 11-006c: clock is not stable yet
    
    The datasheet doesn't mention the maximum time to wait for the clock to be
    stable when using a crystal, and it seems that the 10ms delay in the driver
    is not always sufficient.
    
    Jan Kundrát reported that it took three tries (each separated by 10ms) to
    get a stable clock.
    
    Modify behavior to check stable clock ready bit multiple times (20), and
    waiting 10ms between each try.
    
    Note: the first draft of the driver originally used a 50ms delay, without
    checking the clock stable bit.
    Then a loop with 1000 retries was implemented, each time reading the clock
    stable bit.
    
    Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
    Cc: stable@vger.kernel.org
    Suggested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
    Link: https://www.spinics.net/lists/linux-serial/msg35773.html
    Link: https://lore.kernel.org/all/20240110174015.6f20195fde08e5c9e64e5675@hugovil.com/raw
    Link: https://github.com/boundarydevices/linux/commit/e5dfe3e4a751392515d78051973190301a37ca9a
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20240116213001.3691629-3-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: max310x: set default value when reading clock ready bit [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Tue Jan 16 16:29:58 2024 -0500

    serial: max310x: set default value when reading clock ready bit
    
    commit 0419373333c2f2024966d36261fd82a453281e80 upstream.
    
    If regmap_read() returns a non-zero value, the 'val' variable can be left
    uninitialized.
    
    Clear it before calling regmap_read() to make sure we properly detect
    the clock ready bit.
    
    Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20240116213001.3691629-2-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb3: Replace smb2pdu 1-element arrays with flex-arrays [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Feb 17 16:24:40 2023 -0800

    smb3: Replace smb2pdu 1-element arrays with flex-arrays
    
    commit eb3e28c1e89b4984308777231887e41aa8a0151f upstream.
    
    The kernel is globally removing the ambiguous 0-length and 1-element
    arrays in favor of flexible arrays, so that we can gain both compile-time
    and run-time array bounds checking[1].
    
    Replace the trailing 1-element array with a flexible array in the
    following structures:
    
            struct smb2_err_rsp
            struct smb2_tree_connect_req
            struct smb2_negotiate_rsp
            struct smb2_sess_setup_req
            struct smb2_sess_setup_rsp
            struct smb2_read_req
            struct smb2_read_rsp
            struct smb2_write_req
            struct smb2_write_rsp
            struct smb2_query_directory_req
            struct smb2_query_directory_rsp
            struct smb2_set_info_req
            struct smb2_change_notify_rsp
            struct smb2_create_rsp
            struct smb2_query_info_req
            struct smb2_query_info_rsp
    
    Replace the trailing 1-element array with a flexible array, but leave
    the existing structure padding:
    
            struct smb2_file_all_info
            struct smb2_lock_req
    
    Adjust all related size calculations to match the changes to sizeof().
    
    No machine code output or .data section differences are produced after
    these changes.
    
    [1] For lots of details, see both:
        https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays
        https://people.kernel.org/kees/bounded-flexible-arrays-in-c
    
    Cc: Steve French <sfrench@samba.org>
    Cc: Paulo Alcantara <pc@cjr.nz>
    Cc: Ronnie Sahlberg <lsahlber@redhat.com>
    Cc: Shyam Prasad N <sprasad@microsoft.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
spi: bcm-qspi: fix SFDP BFPT read by usig mspi read [+ + +]
Author: Kamal Dasu <kamal.dasu@broadcom.com>
Date:   Tue Jan 9 16:00:32 2024 -0500

    spi: bcm-qspi: fix SFDP BFPT read by usig mspi read
    
    [ Upstream commit 574bf7bbe83794a902679846770f75a9b7f28176 ]
    
    SFDP read shall use the mspi reads when using the bcm_qspi_exec_mem_op()
    call. This fixes SFDP parameter page read failures seen with parts that
    now use SFDP protocol to read the basic flash parameter table.
    
    Fixes: 5f195ee7d830 ("spi: bcm-qspi: Implement the spi_mem interface")
    Signed-off-by: Kamal Dasu <kamal.dasu@broadcom.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://msgid.link/r/20240109210033.43249-1-kamal.dasu@broadcom.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: ppc4xx: Drop write-only variable [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sat Feb 10 17:40:08 2024 +0100

    spi: ppc4xx: Drop write-only variable
    
    [ Upstream commit b3aa619a8b4706f35cb62f780c14e68796b37f3f ]
    
    Since commit 24778be20f87 ("spi: convert drivers to use
    bits_per_word_mask") the bits_per_word variable is only written to. The
    check that was there before isn't needed any more as the spi core
    ensures that only 8 bit transfers are used, so the variable can go away
    together with all assignments to it.
    
    Fixes: 24778be20f87 ("spi: convert drivers to use bits_per_word_mask")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20240210164006.208149-8-u.kleine-koenig@pengutronix.de
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
staging: fbtft: core: set smem_len before fb_deferred_io_init call [+ + +]
Author: Peter Suti <peter.suti@streamunlimited.com>
Date:   Wed Jul 27 09:35:50 2022 +0200

    staging: fbtft: core: set smem_len before fb_deferred_io_init call
    
    commit 81e878887ff82a7dd42f22951391069a5d520627 upstream.
    
    The fbtft_framebuffer_alloc() calls fb_deferred_io_init() before
    initializing info->fix.smem_len.  It is set to zero by the
    framebuffer_alloc() function.  It will trigger a WARN_ON() at the
    start of fb_deferred_io_init() and the function will not do anything.
    
    Fixes: 856082f021a2 ("fbdev: defio: fix the pagelist corruption")
    Signed-off-by: Peter Suti <peter.suti@streamunlimited.com>
    Link: https://lore.kernel.org/r/20220727073550.1491126-1-peter.suti@streamunlimited.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: iio: ad5933: fix type mismatch regression [+ + +]
Author: David Schiller <david.schiller@jku.at>
Date:   Mon Jan 22 14:49:17 2024 +0100

    staging: iio: ad5933: fix type mismatch regression
    
    commit 6db053cd949fcd6254cea9f2cd5d39f7bd64379c upstream.
    
    Commit 4c3577db3e4f ("Staging: iio: impedance-analyzer: Fix sparse
    warning") fixed a compiler warning, but introduced a bug that resulted
    in one of the two 16 bit IIO channels always being zero (when both are
    enabled).
    
    This is because int is 32 bits wide on most architectures and in the
    case of a little-endian machine the two most significant bytes would
    occupy the buffer for the second channel as 'val' is being passed as a
    void pointer to 'iio_push_to_buffers()'.
    
    Fix by defining 'val' as u16. Tested working on ARM64.
    
    Fixes: 4c3577db3e4f ("Staging: iio: impedance-analyzer: Fix sparse warning")
    Signed-off-by: David Schiller <david.schiller@jku.at>
    Link: https://lore.kernel.org/r/20240122134916.2137957-1-david.schiller@jku.at
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
SUNRPC: Fix a suspicious RCU usage warning [+ + +]
Author: Anna Schumaker <Anna.Schumaker@Netapp.com>
Date:   Mon Nov 27 17:06:18 2023 -0500

    SUNRPC: Fix a suspicious RCU usage warning
    
    [ Upstream commit 31b62908693c90d4d07db597e685d9f25a120073 ]
    
    I received the following warning while running cthon against an ontap
    server running pNFS:
    
    [   57.202521] =============================
    [   57.202522] WARNING: suspicious RCU usage
    [   57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted
    [   57.202525] -----------------------------
    [   57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!
    [   57.202527]
                   other info that might help us debug this:
    
    [   57.202528]
                   rcu_scheduler_active = 2, debug_locks = 1
    [   57.202529] no locks held by test5/3567.
    [   57.202530]
                   stack backtrace:
    [   57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e
    [   57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
    [   57.202536] Call Trace:
    [   57.202537]  <TASK>
    [   57.202540]  dump_stack_lvl+0x77/0xb0
    [   57.202551]  lockdep_rcu_suspicious+0x154/0x1a0
    [   57.202556]  rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
    [   57.202596]  rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
    [   57.202621]  ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
    [   57.202646]  rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
    [   57.202671]  ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
    [   57.202696]  nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
    [   57.202728]  ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
    [   57.202754]  nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
    [   57.202760]  filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
    [   57.202765]  pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
    [   57.202788]  __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
    [   57.202813]  nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
    [   57.202831]  nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
    [   57.202849]  nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
    [   57.202866]  write_cache_pages+0x265/0x450
    [   57.202870]  ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
    [   57.202891]  nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
    [   57.202913]  do_writepages+0xd2/0x230
    [   57.202917]  ? filemap_fdatawrite_wbc+0x5c/0x80
    [   57.202921]  filemap_fdatawrite_wbc+0x67/0x80
    [   57.202924]  filemap_write_and_wait_range+0xd9/0x170
    [   57.202930]  nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
    [   57.202947]  nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
    [   57.202969]  __se_sys_close+0x46/0xd0
    [   57.202972]  do_syscall_64+0x68/0x100
    [   57.202975]  ? do_syscall_64+0x77/0x100
    [   57.202976]  ? do_syscall_64+0x77/0x100
    [   57.202979]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
    [   57.202982] RIP: 0033:0x7fe2b12e4a94
    [   57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3
    [   57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
    [   57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94
    [   57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003
    [   57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49
    [   57.202993] R10: 00007fe2b11f8300 R11: 0000000000000202 R12: 0000000000000000
    [   57.202994] R13: 00007ffe857dfd80 R14: 00007fe2b1445000 R15: 0000000000000000
    [   57.202999]  </TASK>
    
    The problem seems to be that two out of three callers aren't taking the
    rcu_read_lock() before calling the list_for_each_entry_rcu() function in
    rpc_xprt_switch_has_addr(). I fix this by having
    rpc_xprt_switch_has_addr() unconditionaly take the rcu_read_lock(),
    which is okay to do recursively in the case that the lock has already
    been taken by a caller.
    
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: Add memory barrier to tcp_push() [+ + +]
Author: Salvatore Dipietro <dipiets@amazon.com>
Date:   Fri Jan 19 11:01:33 2024 -0800

    tcp: Add memory barrier to tcp_push()
    
    [ Upstream commit 7267e8dcad6b2f9fce05a6a06335d7040acbc2b6 ]
    
    On CPUs with weak memory models, reads and updates performed by tcp_push
    to the sk variables can get reordered leaving the socket throttled when
    it should not. The tasklet running tcp_wfree() may also not observe the
    memory updates in time and will skip flushing any packets throttled by
    tcp_push(), delaying the sending. This can pathologically cause 40ms
    extra latency due to bad interactions with delayed acks.
    
    Adding a memory barrier in tcp_push removes the bug, similarly to the
    previous commit bf06200e732d ("tcp: tsq: fix nonagle handling").
    smp_mb__after_atomic() is used to not incur in unnecessary overhead
    on x86 since not affected.
    
    Patch has been tested using an AWS c7g.2xlarge instance with Ubuntu
    22.04 and Apache Tomcat 9.0.83 running the basic servlet below:
    
    import java.io.IOException;
    import java.io.OutputStreamWriter;
    import java.io.PrintWriter;
    import javax.servlet.ServletException;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    
    public class HelloWorldServlet extends HttpServlet {
        @Override
        protected void doGet(HttpServletRequest request, HttpServletResponse response)
          throws ServletException, IOException {
            response.setContentType("text/html;charset=utf-8");
            OutputStreamWriter osw = new OutputStreamWriter(response.getOutputStream(),"UTF-8");
            String s = "a".repeat(3096);
            osw.write(s,0,s.length());
            osw.flush();
        }
    }
    
    Load was applied using wrk2 (https://github.com/kinvolk/wrk2) from an AWS
    c6i.8xlarge instance. Before the patch an additional 40ms latency from P99.99+
    values is observed while, with the patch, the extra latency disappears.
    
    No patch and tcp_autocorking=1
    ./wrk -t32 -c128 -d40s --latency -R10000  http://172.31.60.173:8080/hello/hello
      ...
     50.000%    0.91ms
     75.000%    1.13ms
     90.000%    1.46ms
     99.000%    1.74ms
     99.900%    1.89ms
     99.990%   41.95ms  <<< 40+ ms extra latency
     99.999%   48.32ms
    100.000%   48.96ms
    
    With patch and tcp_autocorking=1
    ./wrk -t32 -c128 -d40s --latency -R10000  http://172.31.60.173:8080/hello/hello
      ...
     50.000%    0.90ms
     75.000%    1.13ms
     90.000%    1.45ms
     99.000%    1.72ms
     99.900%    1.83ms
     99.990%    2.11ms  <<< no 40+ ms extra latency
     99.999%    2.53ms
    100.000%    2.62ms
    
    Patch has been also tested on x86 (m7i.2xlarge instance) which it is not
    affected by this issue and the patch doesn't introduce any additional
    delay.
    
    Fixes: 7aa5470c2c09 ("tcp: tsq: move tsq_flags close to sk_wmem_alloc")
    Signed-off-by: Salvatore Dipietro <dipiets@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240119190133.43698-1-dipiets@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: add sanity checks to rx zerocopy [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jan 25 10:33:17 2024 +0000

    tcp: add sanity checks to rx zerocopy
    
    [ Upstream commit 577e4432f3ac810049cb7e6b71f4d96ec7c6e894 ]
    
    TCP rx zerocopy intent is to map pages initially allocated
    from NIC drivers, not pages owned by a fs.
    
    This patch adds to can_map_frag() these additional checks:
    
    - Page must not be a compound one.
    - page->mapping must be NULL.
    
    This fixes the panic reported by ZhangPeng.
    
    syzbot was able to loopback packets built with sendfile(),
    mapping pages owned by an ext4 file to TCP rx zerocopy.
    
    r3 = socket$inet_tcp(0x2, 0x1, 0x0)
    mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
    r4 = socket$inet_tcp(0x2, 0x1, 0x0)
    bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
    connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
    r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
        0x181e42, 0x0)
    fallocate(r5, 0x0, 0x0, 0x85b8)
    sendfile(r4, r5, 0x0, 0x8ba0)
    getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
        &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,
        0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)
    r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
        0x181e42, 0x0)
    
    Fixes: 93ab6cc69162 ("tcp: implement mmap() for zero copy receive")
    Link: https://lore.kernel.org/netdev/5106a58e-04da-372a-b836-9d3d0bd2507b@huawei.com/T/
    Reported-and-bisected-by: ZhangPeng <zhangpeng362@huawei.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Arjun Roy <arjunroy@google.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: linux-mm@vger.kernel.org
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: linux-fsdevel@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: make sure init the accept_queue's spinlocks once [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Thu Jan 18 09:20:19 2024 +0800

    tcp: make sure init the accept_queue's spinlocks once
    
    [ Upstream commit 198bc90e0e734e5f98c3d2833e8390cac3df61b2 ]
    
    When I run syz's reproduction C program locally, it causes the following
    issue:
    pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
    WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
    Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
    Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
    30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
    RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
    RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
    RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
    R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
    R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
    FS:  00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
    Call Trace:
    <IRQ>
      _raw_spin_unlock (kernel/locking/spinlock.c:186)
      inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
      inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
      tcp_check_req (net/ipv4/tcp_minisocks.c:868)
      tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
      ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
      ip_local_deliver_finish (net/ipv4/ip_input.c:234)
      __netif_receive_skb_one_core (net/core/dev.c:5529)
      process_backlog (./include/linux/rcupdate.h:779)
      __napi_poll (net/core/dev.c:6533)
      net_rx_action (net/core/dev.c:6604)
      __do_softirq (./arch/x86/include/asm/jump_label.h:27)
      do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
    </IRQ>
    <TASK>
      __local_bh_enable_ip (kernel/softirq.c:381)
      __dev_queue_xmit (net/core/dev.c:4374)
      ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
      __ip_queue_xmit (net/ipv4/ip_output.c:535)
      __tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
      tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
      tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
      tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
      __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
      release_sock (net/core/sock.c:3536)
      inet_wait_for_connect (net/ipv4/af_inet.c:609)
      __inet_stream_connect (net/ipv4/af_inet.c:702)
      inet_stream_connect (net/ipv4/af_inet.c:748)
      __sys_connect (./include/linux/file.h:45 net/socket.c:2064)
      __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
      do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
      entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
      RIP: 0033:0x7fa10ff05a3d
      Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 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 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
      RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
      RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
      RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
      RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
      R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
    </TASK>
    
    The issue triggering process is analyzed as follows:
    Thread A                                       Thread B
    tcp_v4_rcv      //receive ack TCP packet       inet_shutdown
      tcp_check_req                                  tcp_disconnect //disconnect sock
      ...                                              tcp_set_state(sk, TCP_CLOSE)
        inet_csk_complete_hashdance                ...
          inet_csk_reqsk_queue_add                 inet_listen  //start listen
            spin_lock(&queue->rskq_lock)             inet_csk_listen_start
            ...                                        reqsk_queue_alloc
            ...                                          spin_lock_init
            spin_unlock(&queue->rskq_lock)  //warning
    
    When the socket receives the ACK packet during the three-way handshake,
    it will hold spinlock. And then the user actively shutdowns the socket
    and listens to the socket immediately, the spinlock will be initialized.
    When the socket is going to release the spinlock, a warning is generated.
    Also the same issue to fastopenq.lock.
    
    Move init spinlock to inet_create and inet_accept to make sure init the
    accept_queue's spinlocks once.
    
    Fixes: fff1f3001cc5 ("tcp: add a spinlock to protect struct request_sock_queue")
    Fixes: 168a8f58059a ("tcp: TCP Fast Open Server - main code path")
    Reported-by: Ming Shu <sming56@aliyun.com>
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240118012019.1751966-1-shaozhengchao@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tick/sched: Preserve number of idle sleeps across CPU hotplug events [+ + +]
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date:   Mon Jan 22 15:35:34 2024 -0800

    tick/sched: Preserve number of idle sleeps across CPU hotplug events
    
    commit 9a574ea9069be30b835a3da772c039993c43369b upstream.
    
    Commit 71fee48f ("tick-sched: Fix idle and iowait sleeptime accounting vs
    CPU hotplug") preserved total idle sleep time and iowait sleeptime across
    CPU hotplug events.
    
    Similar reasoning applies to the number of idle calls and idle sleeps to
    get the proper average of sleep time per idle invocation.
    
    Preserve those fields too.
    
    Fixes: 71fee48f ("tick-sched: Fix idle and iowait sleeptime accounting vs CPU hotplug")
    Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240122233534.3094238-1-tim.c.chen@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Thu Feb 1 00:23:09 2024 +0900

    tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
    
    [ Upstream commit 3871aa01e1a779d866fa9dfdd5a836f342f4eb87 ]
    
    syzbot reported the following general protection fault [1]:
    
    general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]
    ...
    RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291
    ...
    Call Trace:
     <TASK>
     tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646
     tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089
     genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972
     genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]
     genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067
     netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544
     genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
     netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
     netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367
     netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0xd5/0x180 net/socket.c:745
     ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
     ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
     __sys_sendmsg+0x117/0x1e0 net/socket.c:2667
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x63/0x6b
    
    The cause of this issue is that when tipc_nl_bearer_add() is called with
    the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called
    even if the bearer is not UDP.
    
    tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that
    the media_ptr field of the tipc_bearer has an udp_bearer type object, so
    the function goes crazy for non-UDP bearers.
    
    This patch fixes the issue by checking the bearer type before calling
    tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().
    
    Fixes: ef20cd4dd163 ("tipc: introduce UDP replicast")
    Reported-and-tested-by: syzbot+5142b87a9abc510e14fa@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=5142b87a9abc510e14fa [1]
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Reviewed-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
    Link: https://lore.kernel.org/r/20240131152310.4089541-1-syoshida@redhat.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tracing/trigger: Fix to return error if failed to alloc snapshot [+ + +]
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Fri Jan 26 09:42:58 2024 +0900

    tracing/trigger: Fix to return error if failed to alloc snapshot
    
    commit 0958b33ef5a04ed91f61cef4760ac412080c4e08 upstream.
    
    Fix register_snapshot_trigger() to return error code if it failed to
    allocate a snapshot instead of 0 (success). Unless that, it will register
    snapshot trigger without an error.
    
    Link: https://lore.kernel.org/linux-trace-kernel/170622977792.270660.2789298642759362200.stgit@devnote2
    
    Fixes: 0bbe7f719985 ("tracing: Fix the race between registering 'snapshot' event trigger and triggering 'snapshot' operation")
    Cc: stable@vger.kernel.org
    Cc: Vincent Donnefort <vdonnefort@google.com>
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing: Ensure visibility when inserting an element into tracing_map [+ + +]
Author: Petr Pavlu <petr.pavlu@suse.com>
Date:   Mon Jan 22 16:09:28 2024 +0100

    tracing: Ensure visibility when inserting an element into tracing_map
    
    [ Upstream commit 2b44760609e9eaafc9d234a6883d042fc21132a7 ]
    
    Running the following two commands in parallel on a multi-processor
    AArch64 machine can sporadically produce an unexpected warning about
    duplicate histogram entries:
    
     $ while true; do
         echo hist:key=id.syscall:val=hitcount > \
           /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger
         cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist
         sleep 0.001
       done
     $ stress-ng --sysbadaddr $(nproc)
    
    The warning looks as follows:
    
    [ 2911.172474] ------------[ cut here ]------------
    [ 2911.173111] Duplicates detected: 1
    [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408
    [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)
    [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1
    [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G            E      6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01
    [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018
    [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
    [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408
    [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408
    [ 2911.185310] sp : ffff8000a1513900
    [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001
    [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008
    [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180
    [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff
    [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8
    [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731
    [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c
    [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8
    [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000
    [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480
    [ 2911.194259] Call trace:
    [ 2911.194626]  tracing_map_sort_entries+0x3e0/0x408
    [ 2911.195220]  hist_show+0x124/0x800
    [ 2911.195692]  seq_read_iter+0x1d4/0x4e8
    [ 2911.196193]  seq_read+0xe8/0x138
    [ 2911.196638]  vfs_read+0xc8/0x300
    [ 2911.197078]  ksys_read+0x70/0x108
    [ 2911.197534]  __arm64_sys_read+0x24/0x38
    [ 2911.198046]  invoke_syscall+0x78/0x108
    [ 2911.198553]  el0_svc_common.constprop.0+0xd0/0xf8
    [ 2911.199157]  do_el0_svc+0x28/0x40
    [ 2911.199613]  el0_svc+0x40/0x178
    [ 2911.200048]  el0t_64_sync_handler+0x13c/0x158
    [ 2911.200621]  el0t_64_sync+0x1a8/0x1b0
    [ 2911.201115] ---[ end trace 0000000000000000 ]---
    
    The problem appears to be caused by CPU reordering of writes issued from
    __tracing_map_insert().
    
    The check for the presence of an element with a given key in this
    function is:
    
     val = READ_ONCE(entry->val);
     if (val && keys_match(key, val->key, map->key_size)) ...
    
    The write of a new entry is:
    
     elt = get_free_elt(map);
     memcpy(elt->key, key, map->key_size);
     entry->val = elt;
    
    The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;"
    stores may become visible in the reversed order on another CPU. This
    second CPU might then incorrectly determine that a new key doesn't match
    an already present val->key and subsequently insert a new element,
    resulting in a duplicate.
    
    Fix the problem by adding a write barrier between
    "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;", and for
    good measure, also use WRITE_ONCE(entry->val, elt) for publishing the
    element. The sequence pairs with the mentioned "READ_ONCE(entry->val);"
    and the "val->key" check which has an address dependency.
    
    The barrier is placed on a path executed when adding an element for
    a new key. Subsequent updates targeting the same key remain unaffected.
    
    From the user's perspective, the issue was introduced by commit
    c193707dde77 ("tracing: Remove code which merges duplicates"), which
    followed commit cbf4100efb8f ("tracing: Add support to detect and avoid
    duplicates"). The previous code operated differently; it inherently
    expected potential races which result in duplicates but merged them
    later when they occurred.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240122150928.27725-1-petr.pavlu@suse.com
    
    Fixes: c193707dde77 ("tracing: Remove code which merges duplicates")
    Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
    Acked-by: Tom Zanussi <tom.zanussi@linux.intel.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tracing: Fix wasted memory in saved_cmdlines logic [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Fri Feb 9 06:36:22 2024 -0500

    tracing: Fix wasted memory in saved_cmdlines logic
    
    commit 44dc5c41b5b1267d4dd037d26afc0c4d3a568acb upstream.
    
    While looking at improving the saved_cmdlines cache I found a huge amount
    of wasted memory that should be used for the cmdlines.
    
    The tracing data saves pids during the trace. At sched switch, if a trace
    occurred, it will save the comm of the task that did the trace. This is
    saved in a "cache" that maps pids to comms and exposed to user space via
    the /sys/kernel/tracing/saved_cmdlines file. Currently it only caches by
    default 128 comms.
    
    The structure that uses this creates an array to store the pids using
    PID_MAX_DEFAULT (which is usually set to 32768). This causes the structure
    to be of the size of 131104 bytes on 64 bit machines.
    
    In hex: 131104 = 0x20020, and since the kernel allocates generic memory in
    powers of two, the kernel would allocate 0x40000 or 262144 bytes to store
    this structure. That leaves 131040 bytes of wasted space.
    
    Worse, the structure points to an allocated array to store the comm names,
    which is 16 bytes times the amount of names to save (currently 128), which
    is 2048 bytes. Instead of allocating a separate array, make the structure
    end with a variable length string and use the extra space for that.
    
    This is similar to a recommendation that Linus had made about eventfs_inode names:
    
      https://lore.kernel.org/all/20240130190355.11486-5-torvalds@linux-foundation.org/
    
    Instead of allocating a separate string array to hold the saved comms,
    have the structure end with: char saved_cmdlines[]; and round up to the
    next power of two over sizeof(struct saved_cmdline_buffers) + num_cmdlines * TASK_COMM_LEN
    It will use this extra space for the saved_cmdline portion.
    
    Now, instead of saving only 128 comms by default, by using this wasted
    space at the end of the structure it can save over 8000 comms and even
    saves space by removing the need for allocating the other array.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240209063622.1f7b6d5f@rorschach.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Vincent Donnefort <vdonnefort@google.com>
    Cc: Sven Schnelle <svens@linux.ibm.com>
    Cc: Mete Durlu <meted@linux.ibm.com>
    Fixes: 939c7a4f04fcd ("tracing: Introduce saved_cmdlines_size file")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing: Inform kmemleak of saved_cmdlines allocation [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Wed Feb 14 11:20:46 2024 -0500

    tracing: Inform kmemleak of saved_cmdlines allocation
    
    commit 2394ac4145ea91b92271e675a09af2a9ea6840b7 upstream.
    
    The allocation of the struct saved_cmdlines_buffer structure changed from:
    
            s = kmalloc(sizeof(*s), GFP_KERNEL);
            s->saved_cmdlines = kmalloc_array(TASK_COMM_LEN, val, GFP_KERNEL);
    
    to:
    
            orig_size = sizeof(*s) + val * TASK_COMM_LEN;
            order = get_order(orig_size);
            size = 1 << (order + PAGE_SHIFT);
            page = alloc_pages(GFP_KERNEL, order);
            if (!page)
                    return NULL;
    
            s = page_address(page);
            memset(s, 0, sizeof(*s));
    
            s->saved_cmdlines = kmalloc_array(TASK_COMM_LEN, val, GFP_KERNEL);
    
    Where that s->saved_cmdlines allocation looks to be a dangling allocation
    to kmemleak. That's because kmemleak only keeps track of kmalloc()
    allocations. For allocations that use page_alloc() directly, the kmemleak
    needs to be explicitly informed about it.
    
    Add kmemleak_alloc() and kmemleak_free() around the page allocation so
    that it doesn't give the following false positive:
    
    unreferenced object 0xffff8881010c8000 (size 32760):
      comm "swapper", pid 0, jiffies 4294667296
      hex dump (first 32 bytes):
        ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
        ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
      backtrace (crc ae6ec1b9):
        [<ffffffff86722405>] kmemleak_alloc+0x45/0x80
        [<ffffffff8414028d>] __kmalloc_large_node+0x10d/0x190
        [<ffffffff84146ab1>] __kmalloc+0x3b1/0x4c0
        [<ffffffff83ed7103>] allocate_cmdlines_buffer+0x113/0x230
        [<ffffffff88649c34>] tracer_alloc_buffers.isra.0+0x124/0x460
        [<ffffffff8864a174>] early_trace_init+0x14/0xa0
        [<ffffffff885dd5ae>] start_kernel+0x12e/0x3c0
        [<ffffffff885f5758>] x86_64_start_reservations+0x18/0x30
        [<ffffffff885f582b>] x86_64_start_kernel+0x7b/0x80
        [<ffffffff83a001c3>] secondary_startup_64_no_verify+0x15e/0x16b
    
    Link: https://lore.kernel.org/linux-trace-kernel/87r0hfnr9r.fsf@kernel.org/
    Link: https://lore.kernel.org/linux-trace-kernel/20240214112046.09a322d6@gandalf.local.home
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Fixes: 44dc5c41b5b1 ("tracing: Fix wasted memory in saved_cmdlines logic")
    Reported-by: Kalle Valo <kvalo@kernel.org>
    Tested-by: Kalle Valo <kvalo@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tty: allow TIOCSLCKTRMIOS with CAP_CHECKPOINT_RESTORE [+ + +]
Author: Adrian Reber <areber@redhat.com>
Date:   Fri Dec 8 15:36:56 2023 +0100

    tty: allow TIOCSLCKTRMIOS with CAP_CHECKPOINT_RESTORE
    
    [ Upstream commit e0f25b8992345aa5f113da2815f5add98738c611 ]
    
    The capability CAP_CHECKPOINT_RESTORE was introduced to allow non-root
    users to checkpoint and restore processes as non-root with CRIU.
    
    This change extends CAP_CHECKPOINT_RESTORE to enable the CRIU option
    '--shell-job' as non-root. CRIU's man-page describes the '--shell-job'
    option like this:
    
      Allow one to dump shell jobs. This implies the restored task will
      inherit session and process group ID from the criu itself. This option
      also allows to migrate a single external tty connection, to migrate
      applications like top.
    
    TIOCSLCKTRMIOS can only be done if the process has CAP_SYS_ADMIN and
    this change extends it to CAP_SYS_ADMIN or CAP_CHECKPOINT_RESTORE.
    
    With this change it is possible to checkpoint and restore processes
    which have a tty connection as non-root if CAP_CHECKPOINT_RESTORE is
    set.
    
    Acked-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Adrian Reber <areber@redhat.com>
    Acked-by: Andrei Vagin <avagin@gmail.com>
    Link: https://lore.kernel.org/r/20231208143656.1019-1-areber@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tunnels: fix out of bounds access when building IPv6 PMTU error [+ + +]
Author: Antoine Tenart <atenart@kernel.org>
Date:   Thu Feb 1 09:38:15 2024 +0100

    tunnels: fix out of bounds access when building IPv6 PMTU error
    
    [ Upstream commit d75abeec401f8c86b470e7028a13fcdc87e5dd06 ]
    
    If the ICMPv6 error is built from a non-linear skb we get the following
    splat,
    
      BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240
      Read of size 4 at addr ffff88811d402c80 by task netperf/820
      CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543
      ...
       kasan_report+0xd8/0x110
       do_csum+0x220/0x240
       csum_partial+0xc/0x20
       skb_tunnel_check_pmtu+0xeb9/0x3280
       vxlan_xmit_one+0x14c2/0x4080
       vxlan_xmit+0xf61/0x5c00
       dev_hard_start_xmit+0xfb/0x510
       __dev_queue_xmit+0x7cd/0x32a0
       br_dev_queue_push_xmit+0x39d/0x6a0
    
    Use skb_checksum instead of csum_partial who cannot deal with non-linear
    SKBs.
    
    Fixes: 4cb47a8644cc ("tunnels: PMTU discovery support for directly bridged IP packets")
    Signed-off-by: Antoine Tenart <atenart@kernel.org>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Fri Dec 22 16:54:46 2023 +0800

    ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path
    
    commit 1e022216dcd248326a5bb95609d12a6815bca4e2 upstream.
    
    For error handling path in ubifs_symlink(), inode will be marked as
    bad first, then iput() is invoked. If inode->i_link is initialized by
    fscrypt_encrypt_symlink() in encryption scenario, inode->i_link won't
    be freed by callchain ubifs_free_inode -> fscrypt_free_inode in error
    handling path, because make_bad_inode() has changed 'inode->i_mode' as
    'S_IFREG'.
    Following kmemleak is easy to be reproduced by injecting error in
    ubifs_jnl_update() when doing symlink in encryption scenario:
     unreferenced object 0xffff888103da3d98 (size 8):
      comm "ln", pid 1692, jiffies 4294914701 (age 12.045s)
      backtrace:
       kmemdup+0x32/0x70
       __fscrypt_encrypt_symlink+0xed/0x1c0
       ubifs_symlink+0x210/0x300 [ubifs]
       vfs_symlink+0x216/0x360
       do_symlinkat+0x11a/0x190
       do_syscall_64+0x3b/0xe0
    There are two ways fixing it:
     1. Remove make_bad_inode() in error handling path. We can do that
        because ubifs_evict_inode() will do same processes for good
        symlink inode and bad symlink inode, for inode->i_nlink checking
        is before is_bad_inode().
     2. Free inode->i_link before marking inode bad.
    Method 2 is picked, it has less influence, personally, I think.
    
    Cc: stable@vger.kernel.org
    Fixes: 2c58d548f570 ("fscrypt: cache decrypted symlink target in ->i_link")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Suggested-by: Eric Biggers <ebiggers@kernel.org>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
UBSAN: array-index-out-of-bounds in dtSplitRoot [+ + +]
Author: Osama Muhammad <osmtendev@gmail.com>
Date:   Sat Oct 14 00:10:28 2023 +0500

    UBSAN: array-index-out-of-bounds in dtSplitRoot
    
    [ Upstream commit 27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16 ]
    
    Syzkaller reported the following issue:
    
    oop0: detected capacity change from 0 to 32768
    
    UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
    index -2 is out of range for type 'struct dtslot [128]'
    CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
     ubsan_epilogue lib/ubsan.c:151 [inline]
     __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283
     dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971
     dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]
     dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863
     jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270
     vfs_mkdir+0x3b3/0x590 fs/namei.c:4013
     do_mkdirat+0x279/0x550 fs/namei.c:4038
     __do_sys_mkdirat fs/namei.c:4053 [inline]
     __se_sys_mkdirat fs/namei.c:4051 [inline]
     __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7fcdc0113fd9
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9
    RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003
    RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0
    R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000
    R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000
     </TASK>
    
    The issue is caused when the value of fsi becomes less than -1.
    The check to break the loop when fsi value becomes -1 is present
    but syzbot was able to produce value less than -1 which cause the error.
    This patch simply add the change for the values less than 0.
    
    The patch is tested via syzbot.
    
    Reported-and-tested-by: syzbot+d4b1df2e9d4ded6488ec@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?extid=d4b1df2e9d4ded6488ec
    Signed-off-by: Osama Muhammad <osmtendev@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
um: Don't use vfprintf() for os_info() [+ + +]
Author: Benjamin Berg <benjamin@sipsolutions.net>
Date:   Fri Nov 10 12:03:41 2023 +0100

    um: Don't use vfprintf() for os_info()
    
    [ Upstream commit 236f9fe39b02c15fa5530b53e9cca48354394389 ]
    
    The threads allocated inside the kernel have only a single page of
    stack. Unfortunately, the vfprintf function in standard glibc may use
    too much stack-space, overflowing it.
    
    To make os_info safe to be used by helper threads, use the kernel
    vscnprintf function into a smallish buffer and write out the information
    to stderr.
    
    Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

um: Fix naming clash between UML and scheduler [+ + +]
Author: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Date:   Thu Sep 21 15:34:44 2023 +0100

    um: Fix naming clash between UML and scheduler
    
    [ Upstream commit 541d4e4d435c8b9bfd29f70a1da4a2db97794e0a ]
    
    __cant_sleep was already used and exported by the scheduler.
    The name had to be changed to a UML specific one.
    
    Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Reviewed-by: Peter Lafreniere <peter@n8pjl.ca>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

um: net: Fix return type of uml_net_start_xmit() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Dec 6 09:49:46 2023 -0700

    um: net: Fix return type of uml_net_start_xmit()
    
    [ Upstream commit 7d748f60a4b82b50bf25fad1bd42d33f049f76aa ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed. A
    warning in clang aims to catch these at compile time, which reveals:
    
      arch/um/drivers/net_kern.c:353:21: warning: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Wincompatible-function-pointer-types-strict]
        353 |         .ndo_start_xmit         = uml_net_start_xmit,
            |                                   ^~~~~~~~~~~~~~~~~~
      1 warning generated.
    
    ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
    'netdev_tx_t', not 'int'. Adjust the return type of uml_net_start_xmit()
    to match the prototype's to resolve the warning. While UML does not
    currently implement support for kCFI, it could in the future, which
    means this warning becomes a fatal CFI failure at run time.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202310031340.v1vPh207-lkp@intel.com/
    Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

um: time-travel: fix time corruption [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Oct 25 22:45:05 2023 +0200

    um: time-travel: fix time corruption
    
    [ Upstream commit abe4eaa8618bb36c2b33e9cdde0499296a23448c ]
    
    In 'basic' time-travel mode (without =inf-cpu or =ext), we
    still get timer interrupts. These can happen at arbitrary
    points in time, i.e. while in timer_read(), which pushes
    time forward just a little bit. Then, if we happen to get
    the interrupt after calculating the new time to push to,
    but before actually finishing that, the interrupt will set
    the time to a value that's incompatible with the forward,
    and we'll crash because time goes backwards when we do the
    forwarding.
    
    Fix this by reading the time_travel_time, calculating the
    adjustment, and doing the adjustment all with interrupts
    disabled.
    
    Reported-by: Vincent Whitchurch <Vincent.Whitchurch@axis.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: dwc3: ep0: Don't prepare beyond Setup stage [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Apr 21 19:22:50 2022 -0700

    usb: dwc3: ep0: Don't prepare beyond Setup stage
    
    [ Upstream commit c96683798e272366866a5c0ce3073c0b5a256db7 ]
    
    Since we can't guarantee that the host won't send new Setup packet
    before going through the device-initiated disconnect, don't prepare
    beyond the Setup stage and keep the device in EP0_SETUP_PHASE. This
    ensures that the device-initated disconnect sequence can go through
    gracefully. Note that the controller won't service the End Transfer
    command if it can't DMA out the Setup packet.
    
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/6bacec56ecabb2c6e49a09cedfcac281fdc97de0.1650593829.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 730e12fbec53 ("usb: dwc3: gadget: Handle EP0 request dequeuing properly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: Fix ep0 handling when getting reset while doing control transfer [+ + +]
Author: Mayank Rana <quic_mrana@quicinc.com>
Date:   Wed May 4 12:36:41 2022 -0700

    usb: dwc3: Fix ep0 handling when getting reset while doing control transfer
    
    [ Upstream commit 9d778f0c5f95ca5aa2ff628ea281978697e8d89b ]
    
    According to the databook ep0 should be in setup phase during reset.
    If host issues reset between control transfers, ep0 will be  in an
    invalid state. Fix this by issuing stall and restart on ep0 if it
    is not in setup phase.
    
    Also SW needs to complete pending control transfer and setup core for
    next setup stage as per data book. Hence check ep0 state during reset
    interrupt handling and make sure active transfers on ep0 out/in
    endpoint are stopped by queuing ENDXFER command for that endpoint and
    restart ep0 out again to receive next setup packet.
    
    Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
    Link: https://lore.kernel.org/r/1651693001-29891-1-git-send-email-quic_mrana@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 730e12fbec53 ("usb: dwc3: gadget: Handle EP0 request dequeuing properly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: gadget: Delay issuing End Transfer [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Apr 21 19:23:03 2022 -0700

    usb: dwc3: gadget: Delay issuing End Transfer
    
    [ Upstream commit f66eef8fb8989a7193cafc3870f7c7b2b97f16cb ]
    
    If the controller hasn't DMA'ed the Setup data from its fifo, it won't
    process the End Transfer command. Polling for the command completion may
    block the driver from servicing the Setup phase and cause a timeout.
    Previously we only check and delay issuing End Transfer in the case of
    endpoint dequeue. Let's do that for all End Transfer scenarios.
    
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/2fcf3b5d90068d549589a57a27a79f76c6769b04.1650593829.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 730e12fbec53 ("usb: dwc3: gadget: Handle EP0 request dequeuing properly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: gadget: Don't delay End Transfer on delayed_status [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Tue Oct 18 19:39:01 2022 -0700

    usb: dwc3: gadget: Don't delay End Transfer on delayed_status
    
    commit 4db0fbb601361767144e712beb96704b966339f5 upstream.
    
    The gadget driver may wait on the request completion when it sets the
    USB_GADGET_DELAYED_STATUS. Make sure that the End Transfer command can
    go through if the dwc->delayed_status is set so that the request can
    complete. When the delayed_status is set, the Setup packet is already
    processed, and the next phase should be either Data or Status. It's
    unlikely that the host would cancel the control transfer and send a new
    Setup packet during End Transfer command. But if that's the case, we can
    try again when ep0state returns to EP0_SETUP_PHASE.
    
    Fixes: e1ee843488d5 ("usb: dwc3: gadget: Force sending delayed status during soft disconnect")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/3f9f59e5d74efcbaee444cf4b30ef639cc7b124e.1666146954.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: gadget: Execute gadget stop after halting the controller [+ + +]
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Thu Apr 20 14:27:58 2023 -0700

    usb: dwc3: gadget: Execute gadget stop after halting the controller
    
    commit 39674be56fba1cd3a03bf4617f523a35f85fd2c1 upstream.
    
    Do not call gadget stop until the poll for controller halt is
    completed.  DEVTEN is cleared as part of gadget stop, so the intention to
    allow ep0 events to continue while waiting for controller halt is not
    happening.
    
    Fixes: c96683798e27 ("usb: dwc3: ep0: Don't prepare beyond Setup stage")
    Cc: stable@vger.kernel.org
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20230420212759.29429-2-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend [+ + +]
Author: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
Date:   Fri Jan 19 15:18:25 2024 +0530

    usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend
    
    commit 61a348857e869432e6a920ad8ea9132e8d44c316 upstream.
    
    In current scenario if Plug-out and Plug-In performed continuously
    there could be a chance while checking for dwc->gadget_driver in
    dwc3_gadget_suspend, a NULL pointer dereference may occur.
    
    Call Stack:
    
            CPU1:                           CPU2:
            gadget_unbind_driver            dwc3_suspend_common
            dwc3_gadget_stop                dwc3_gadget_suspend
                                            dwc3_disconnect_gadget
    
    CPU1 basically clears the variable and CPU2 checks the variable.
    Consider CPU1 is running and right before gadget_driver is cleared
    and in parallel CPU2 executes dwc3_gadget_suspend where it finds
    dwc->gadget_driver which is not NULL and resumes execution and then
    CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where
    it checks dwc->gadget_driver is already NULL because of which the
    NULL pointer deference occur.
    
    Cc: stable@vger.kernel.org
    Fixes: 9772b47a4c29 ("usb: dwc3: gadget: Fix suspend/resume during device mode")
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
    Link: https://lore.kernel.org/r/20240119094825.26530-1-quic_uaggarwa@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: gadget: Force sending delayed status during soft disconnect [+ + +]
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Wed Aug 17 11:23:52 2022 -0700

    usb: dwc3: gadget: Force sending delayed status during soft disconnect
    
    [ Upstream commit e1ee843488d58099a89979627ef85d5bd6c5cacd ]
    
    If any function drivers request for a delayed status phase, this leads to a
    SETUP transfer timeout error, since the function may take longer to process
    the DATA stage.  This eventually results in end transfer timeouts, as there
    is a pending SETUP transaction.
    
    In addition, allow the DWC3_EP_DELAY_STOP to be set for if there is a
    delayed status requested.  Ocasionally, a host may abort the current SETUP
    transaction, by issuing a subsequent SETUP token.  In those situations, it
    would result in an endxfer timeout as well.
    
    Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20220817182359.13550-3-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 730e12fbec53 ("usb: dwc3: gadget: Handle EP0 request dequeuing properly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: gadget: Handle EP0 request dequeuing properly [+ + +]
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Wed Dec 6 12:18:14 2023 -0800

    usb: dwc3: gadget: Handle EP0 request dequeuing properly
    
    [ Upstream commit 730e12fbec53ab59dd807d981a204258a4cfb29a ]
    
    Current EP0 dequeue path will share the same as other EPs.  However, there
    are some special considerations that need to be made for EP0 transfers:
    
      - EP0 transfers never transition into the started_list
      - EP0 only has one active request at a time
    
    In case there is a vendor specific control message for a function over USB
    FFS, then there is no guarantee on the timeline which the DATA/STATUS stage
    is responded to.  While this occurs, any attempt to end transfers on
    non-control EPs will end up having the DWC3_EP_DELAY_STOP flag set, and
    defer issuing of the end transfer command.  If the USB FFS application
    decides to timeout the control transfer, or if USB FFS AIO path exits, the
    USB FFS driver will issue a call to usb_ep_dequeue() for the ep0 request.
    
    In case of the AIO exit path, the AIO FS blocks until all pending USB
    requests utilizing the AIO path is completed.  However, since the dequeue
    of ep0 req does not happen properly, all non-control EPs with the
    DWC3_EP_DELAY_STOP flag set will not be handled, and the AIO exit path will
    be stuck waiting for the USB FFS data endpoints to receive a completion
    callback.
    
    Fix is to utilize dwc3_ep0_reset_state() in the dequeue API to ensure EP0
    is brought back to the SETUP state, and ensures that any deferred end
    transfer commands are handled.  This also will end any active transfers
    on EP0, compared to the previous implementation which directly called
    giveback only.
    
    Fixes: fcd2def66392 ("usb: dwc3: gadget: Refactor dwc3_gadget_ep_dequeue")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20231206201814.32664-1-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: gadget: Ignore End Transfer delay on teardown [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Dec 8 16:50:35 2022 -0800

    usb: dwc3: gadget: Ignore End Transfer delay on teardown
    
    commit c4e3ef5685393c5051b52cf1e94b8891d49793ab upstream.
    
    If we delay sending End Transfer for Setup TRB to be prepared, we need
    to check if the End Transfer was in preparation for a driver
    teardown/soft-disconnect. In those cases, just send the End Transfer
    command without delay.
    
    In the case of soft-disconnect, there's a very small chance the command
    may not go through immediately. But should it happen, the Setup TRB will
    be prepared during the polling of the controller halted state, allowing
    the command to go through then.
    
    In the case of disabling endpoint due to reconfiguration (e.g.
    set_interface(alt-setting) or usb reset), then it's driven by the host.
    Typically the host wouldn't immediately cancel the control request and
    send another control transfer to trigger the End Transfer command
    timeout.
    
    Fixes: 4db0fbb60136 ("usb: dwc3: gadget: Don't delay End Transfer on delayed_status")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/f1617a323e190b9cc408fb8b65456e32b5814113.1670546756.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: gadget: Only End Transfer for ep0 data phase [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Thu Apr 21 19:22:57 2022 -0700

    usb: dwc3: gadget: Only End Transfer for ep0 data phase
    
    [ Upstream commit ace17b6ee4f92ab0375d12a1b42494f8590a96b6 ]
    
    The driver shouldn't be able to issue End Transfer to the control
    endpoint at anytime. Typically we should only do so in error cases such
    as invalid/unexpected direction of Data Phase as described in the
    control transfer flow of the programming guide. It _may_ end started
    data phase during controller deinitialization from soft disconnect or
    driver removal. However, that should not happen because the driver
    should be maintained in EP0_SETUP_PHASE during driver tear-down. On
    soft-connect, the controller should be reset from a soft-reset and there
    should be no issue starting the control endpoint.
    
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/3c6643678863a26702e4115e9e19d7d94a30d49c.1650593829.git.Thinh.Nguyen@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 730e12fbec53 ("usb: dwc3: gadget: Handle EP0 request dequeuing properly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: gadget: Queue PM runtime idle on disconnect event [+ + +]
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Wed Jan 3 13:49:46 2024 -0800

    usb: dwc3: gadget: Queue PM runtime idle on disconnect event
    
    [ Upstream commit 3c7af52c7616c3aa6dacd2336ec748d4a65df8f4 ]
    
    There is a scenario where DWC3 runtime suspend is blocked due to the
    dwc->connected flag still being true while PM usage_count is zero after
    DWC3 giveback is completed and the USB gadget session is being terminated.
    This leads to a case where nothing schedules a PM runtime idle for the
    device.
    
    The exact condition is seen with the following sequence:
      1.  USB bus reset is issued by the host
      2.  Shortly after, or concurrently, a USB PD DR SWAP request is received
          (sink->source)
      3.  USB bus reset event handler runs and issues
          dwc3_stop_active_transfers(), and pending transfer are stopped
      4.  DWC3 usage_count decremented to 0, and runtime idle occurs while
          dwc->connected == true, returns -EBUSY
      5.  DWC3 disconnect event seen, dwc->connected set to false due to DR
          swap handling
      6.  No runtime idle after this point
    
    Address this by issuing an asynchronous PM runtime idle call after the
    disconnect event is completed, as it modifies the dwc->connected flag,
    which is what blocks the initial runtime idle.
    
    Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM")
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20240103214946.2596-1-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: gadget: Refactor EP0 forced stall/restart into a separate API [+ + +]
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Thu Apr 20 14:27:59 2023 -0700

    usb: dwc3: gadget: Refactor EP0 forced stall/restart into a separate API
    
    [ Upstream commit 8f40fc0808137c157dd408d2632e63bfca2aecdb ]
    
    Several sequences utilize the same routine for forcing the control endpoint
    back into the SETUP phase.  This is required, because those operations need
    to ensure that EP0 is back in the default state.
    
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20230420212759.29429-3-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 730e12fbec53 ("usb: dwc3: gadget: Handle EP0 request dequeuing properly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: gadget: Stall and restart EP0 if host is unresponsive [+ + +]
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Thu Apr 13 12:57:40 2023 -0700

    usb: dwc3: gadget: Stall and restart EP0 if host is unresponsive
    
    [ Upstream commit 02435a739b81ae24aff5d6e930efef9458e2af3c ]
    
    It was observed that there are hosts that may complete pending SETUP
    transactions before the stop active transfers and controller halt occurs,
    leading to lingering endxfer commands on DEPs on subsequent pullup/gadget
    start iterations.
    
      dwc3_gadget_ep_disable   name=ep8in flags=0x3009  direction=1
      dwc3_gadget_ep_disable   name=ep4in flags=1  direction=1
      dwc3_gadget_ep_disable   name=ep3out flags=1  direction=0
      usb_gadget_disconnect   deactivated=0  connected=0  ret=0
    
    The sequence shows that the USB gadget disconnect (dwc3_gadget_pullup(0))
    routine completed successfully, allowing for the USB gadget to proceed with
    a USB gadget connect.  However, if this occurs the system runs into an
    issue where:
    
      BUG: spinlock already unlocked on CPU
      spin_bug+0x0
      dwc3_remove_requests+0x278
      dwc3_ep0_out_start+0xb0
      __dwc3_gadget_start+0x25c
    
    This is due to the pending endxfers, leading to gadget start (w/o lock
    held) to execute the remove requests, which will unlock the dwc3
    spinlock as part of giveback.
    
    To mitigate this, resolve the pending endxfers on the pullup disable
    path by re-locating the SETUP phase check after stop active transfers, since
    that is where the DWC3_EP_DELAY_STOP is potentially set.  This also allows
    for handling of a host that may be unresponsive by using the completion
    timeout to trigger the stall and restart for EP0.
    
    Fixes: c96683798e27 ("usb: dwc3: ep0: Don't prepare beyond Setup stage")
    Cc: stable@vger.kernel.org
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20230413195742.11821-2-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 730e12fbec53 ("usb: dwc3: gadget: Handle EP0 request dequeuing properly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: gadget: Submit endxfer command if delayed during disconnect [+ + +]
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Thu Sep 1 12:36:25 2022 -0700

    usb: dwc3: gadget: Submit endxfer command if delayed during disconnect
    
    [ Upstream commit 8422b769fa46bd429dc0f324012629a4691f0dd9 ]
    
    During a cable disconnect sequence, if ep0state is not in the SETUP phase,
    then nothing will trigger any pending end transfer commands.  Force
    stopping of any pending SETUP transaction, and move back to the SETUP
    phase.
    
    Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20220901193625.8727-6-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 730e12fbec53 ("usb: dwc3: gadget: Handle EP0 request dequeuing properly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: gadget: Wait for ep0 xfers to complete during dequeue [+ + +]
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Wed Mar 9 12:54:02 2022 -0800

    usb: dwc3: gadget: Wait for ep0 xfers to complete during dequeue
    
    [ Upstream commit e4cf6580ac740f766dae26203bd6311d353dcd42 ]
    
    If a Setup packet is received but yet to DMA out, the controller will
    not process the End Transfer command of any endpoint. Polling of its
    DEPCMD.CmdAct may block setting up TRB for Setup packet, causing a
    command timeout.
    
    This may occur if the driver doesn’t service the completion interrupt of
    the control status stage yet due to system latency, then it won’t
    prepare TRB and start the transfer for the next Setup Stage. To the host
    side, the control transfer had completed, and the host can send a new
    Setup packet at this point.
    
    In the meanwhile, if the driver receives an async call to dequeue a
    request (triggering End Transfer) to any endpoint, then the driver will
    service that End transfer first, blocking the control status stage
    completion handler. Since no TRB is available for the Setup stage, the
    Setup packet can’t be DMA’ed out and the End Transfer gets hung.
    
    The driver must not block setting up of the Setup stage. So track and
    only issue the End Transfer command only when there’s Setup TRB prepared
    so that the controller can DMA out the Setup packet. Delay the End
    transfer command if there's no Setup TRB available. This is applicable to
    all DWC_usb3x IPs.
    
    Co-developed-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20220309205402.4467-1-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 730e12fbec53 ("usb: dwc3: gadget: Handle EP0 request dequeuing properly")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: host: Set XHCI_SG_TRB_CACHE_SIZE_QUIRK [+ + +]
Author: Prashanth K <quic_prashk@quicinc.com>
Date:   Tue Jan 16 11:28:15 2024 +0530

    usb: dwc3: host: Set XHCI_SG_TRB_CACHE_SIZE_QUIRK
    
    commit 817349b6d26aadd8b38283a05ce0bab106b4c765 upstream.
    
    Upstream commit bac1ec551434 ("usb: xhci: Set quirk for
    XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
    which fixes XHC timeout, which was seen on synopsys XHCs while
    using SG buffers. But the support for this quirk isn't present
    in the DWC3 layer.
    
    We will encounter this XHCI timeout/hung issue if we run iperf
    loopback tests using RTL8156 ethernet adaptor on DWC3 targets
    with scatter-gather enabled. This gets resolved after enabling
    the XHCI_SG_TRB_CACHE_SIZE_QUIRK. This patch enables it using
    the xhci device property since its needed for DWC3 controller.
    
    In Synopsys DWC3 databook,
    Table 9-3: xHCI Debug Capability Limitations
    Chained TRBs greater than TRB cache size: The debug capability
    driver must not create a multi-TRB TD that describes smaller
    than a 1K packet that spreads across 8 or more TRBs on either
    the IN TR or the OUT TR.
    
    Cc: stable@vger.kernel.org #5.11
    Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240116055816.1169821-2-quic_prashk@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: f_mass_storage: forbid async queue when shutdown happen [+ + +]
Author: yuan linyu <yuanlinyu@hihonor.com>
Date:   Tue Jan 23 11:48:29 2024 +0800

    usb: f_mass_storage: forbid async queue when shutdown happen
    
    commit b2d2d7ea0dd09802cf5a0545bf54d8ad8987d20c upstream.
    
    When write UDC to empty and unbind gadget driver from gadget device, it is
    possible that there are many queue failures for mass storage function.
    
    The root cause is mass storage main thread alaways try to queue request to
    receive a command from host if running flag is on, on platform like dwc3,
    if pull down called, it will not queue request again and return
    -ESHUTDOWN, but it not affect running flag of mass storage function.
    
    Check return code from mass storage function and clear running flag if it
    is -ESHUTDOWN, also indicate start in/out transfer failure to break loops.
    
    Cc: stable <stable@kernel.org>
    Signed-off-by: yuan linyu <yuanlinyu@hihonor.com>
    Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20240123034829.3848409-1-yuanlinyu@hihonor.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: host: xhci-plat: Add support for XHCI_SG_TRB_CACHE_SIZE_QUIRK [+ + +]
Author: Prashanth K <quic_prashk@quicinc.com>
Date:   Tue Jan 16 11:28:16 2024 +0530

    usb: host: xhci-plat: Add support for XHCI_SG_TRB_CACHE_SIZE_QUIRK
    
    commit 520b391e3e813c1dd142d1eebb3ccfa6d08c3995 upstream.
    
    Upstream commit bac1ec551434 ("usb: xhci: Set quirk for
    XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
    which fixes XHC timeout, which was seen on synopsys XHCs while
    using SG buffers. Currently this quirk can only be set using
    xhci private data. But there are some drivers like dwc3/host.c
    which adds adds quirks using software node for xhci device.
    Hence set this xhci quirk by iterating over device properties.
    
    Cc: stable@vger.kernel.org # 5.11
    Fixes: bac1ec551434 ("usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK")
    Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
    Link: https://lore.kernel.org/r/20240116055816.1169821-3-quic_prashk@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: hub: check for alternate port before enabling A_ALT_HNP_SUPPORT [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Mon Jan 22 16:35:32 2024 +0100

    USB: hub: check for alternate port before enabling A_ALT_HNP_SUPPORT
    
    commit f17c34ffc792bbb520e4b61baa16b6cfc7d44b13 upstream.
    
    The OTG 1.3 spec has the feature A_ALT_HNP_SUPPORT, which tells
    a device that it is connected to the wrong port. Some devices
    refuse to operate if you enable that feature, because it indicates
    to them that they ought to request to be connected to another port.
    
    According to the spec this feature may be used based only the following
    three conditions:
    
    6.5.3 a_alt_hnp_support
    Setting this feature indicates to the B-device that it is connected to
    an A-device port that is not capable of HNP, but that the A-device does
    have an alternate port that is capable of HNP.
    The A-device is required to set this feature under the following conditions:
    • the A-device has multiple receptacles
    • the A-device port that connects to the B-device does not support HNP
    • the A-device has another port that does support HNP
    
    A check for the third and first condition is missing. Add it.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@kernel.org>
    Fixes: 7d2d641c44269 ("usb: otg: don't set a_alt_hnp_support feature for OTG 2.0 device")
    Link: https://lore.kernel.org/r/20240122153545.12284-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: hub: Replace hardcoded quirk value with BIT() macro [+ + +]
Author: Hardik Gajjar <hgajjar@de.adit-jv.com>
Date:   Tue Dec 5 19:18:28 2023 +0100

    usb: hub: Replace hardcoded quirk value with BIT() macro
    
    [ Upstream commit 6666ea93d2c422ebeb8039d11e642552da682070 ]
    
    This patch replaces the hardcoded quirk value in the macro with
    BIT().
    
    Signed-off-by: Hardik Gajjar <hgajjar@de.adit-jv.com>
    Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20231205181829.127353-1-hgajjar@de.adit-jv.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
USB: serial: cp210x: add ID for IMST iM871A-USB [+ + +]
Author: Leonard Dallmayr <leonard.dallmayr@mailbox.org>
Date:   Fri Jan 5 13:35:51 2024 +0100

    USB: serial: cp210x: add ID for IMST iM871A-USB
    
    commit 12b17b4eb82a41977eb848048137b5908d52845c upstream.
    
    The device IMST USB-Stick for Smart Meter is a rebranded IMST iM871A-USB
    Wireless M-Bus USB-adapter. It is used to read wireless water, gas and
    electricity meters.
    
    Signed-off-by: Leonard Dallmayr <leonard.dallmayr@mailbox.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Fibocom FM101-GL variant [+ + +]
Author: Puliang Lu <puliang.lu@fibocom.com>
Date:   Wed Jan 31 17:12:24 2024 +0800

    USB: serial: option: add Fibocom FM101-GL variant
    
    commit b4a1f4eaf1d798066affc6ad040f76eb1a16e1c9 upstream.
    
    Update the USB serial option driver support for the Fibocom
    FM101-GL
    LTE modules as there are actually several different variants.
    - VID:PID 2cb7:01a3, FM101-GL are laptop M.2 cards (with
    MBIM interfaces for /Linux/Chrome OS)
    
    0x01a3:mbim,gnss
    
    Here are the outputs of usb-devices:
    
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=01a3 Rev=05.04
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=Fibocom FM101-GL Module
    S:  SerialNumber=5ccd5cd4
    C:  #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=896mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    
    Signed-off-by: Puliang Lu <puliang.lu@fibocom.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: qcserial: add new usb-id for Dell Wireless DW5826e [+ + +]
Author: JackBB Wu <wojackbb@gmail.com>
Date:   Tue Jan 23 17:39:48 2024 +0800

    USB: serial: qcserial: add new usb-id for Dell Wireless DW5826e
    
    commit 129690fb229a20b6e563a77a2c85266acecf20bc upstream.
    
    Add support for Dell DW5826e with USB-id 0x413c:0x8217 & 0x413c:0x8218.
    
    It is 0x413c:0x8217
    T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=413c ProdID=8217 Rev= 5.04
    S:  Manufacturer=DELL
    S:  Product=COMPAL Electronics EXM-G1A
    S:  SerialNumber=359302940050401
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=qcserial
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=qcserial
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=qcserial
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=88(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    It is 0x413c:0x8218
    T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=413c ProdID=8218 Rev= 0.00
    S:  Manufacturer=DELL
    S:  Product=COMPAL Electronics EXM-G1A
    S:  SerialNumber=359302940050401
    C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=  2mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=qcserial
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: JackBB Wu <wojackbb@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: ucsi_acpi: Fix command completion handling [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Sun Jan 21 21:41:22 2024 +0100

    usb: ucsi_acpi: Fix command completion handling
    
    commit 2840143e393a4ddc1caab4372969ea337371168c upstream.
    
    In case of a spurious or otherwise delayed notification it is
    possible that CCI still reports the previous completion. The
    UCSI spec is aware of this and provides two completion bits in
    CCI, one for normal commands and one for acks. As acks and commands
    alternate the notification handler can determine if the completion
    bit is from the current command.
    
    The initial UCSI code correctly handled this but the distinction
    between the two completion bits was lost with the introduction of
    the new API.
    
    To fix this revive the ACK_PENDING bit for ucsi_acpi and only complete
    commands if the completion bit matches.
    
    Fixes: f56de278e8ec ("usb: typec: ucsi: acpi: Move to the new API")
    Cc: stable@vger.kernel.org
    Signed-off-by: "Christian A. Ehrhardt" <lk@c--e.de>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240121204123.275441-3-lk@c--e.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vhost: use kzalloc() instead of kmalloc() followed by memset() [+ + +]
Author: Prathu Baronia <prathubaronia2011@gmail.com>
Date:   Mon May 22 14:20:19 2023 +0530

    vhost: use kzalloc() instead of kmalloc() followed by memset()
    
    commit 4d8df0f5f79f747d75a7d356d9b9ea40a4e4c8a9 upstream.
    
    Use kzalloc() to allocate new zeroed out msg node instead of
    memsetting a node allocated with kmalloc().
    
    Signed-off-by: Prathu Baronia <prathubaronia2011@gmail.com>
    Message-Id: <20230522085019.42914-1-prathubaronia2011@gmail.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Ajay Kaher <ajay.kaher@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings [+ + +]
Author: Zhu Yanjun <yanjun.zhu@linux.dev>
Date:   Thu Jan 4 10:09:02 2024 +0800

    virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings
    
    [ Upstream commit e3fe8d28c67bf6c291e920c6d04fa22afa14e6e4 ]
    
    Fix the warnings when building virtio_net driver.
    
    "
    drivers/net/virtio_net.c: In function ‘init_vqs’:
    drivers/net/virtio_net.c:4551:48: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of size 10 [-Wformat-overflow=]
     4551 |                 sprintf(vi->rq[i].name, "input.%d", i);
          |                                                ^~
    In function ‘virtnet_find_vqs’,
        inlined from ‘init_vqs’ at drivers/net/virtio_net.c:4645:8:
    drivers/net/virtio_net.c:4551:41: note: directive argument in the range [-2147483643, 65534]
     4551 |                 sprintf(vi->rq[i].name, "input.%d", i);
          |                                         ^~~~~~~~~~
    drivers/net/virtio_net.c:4551:17: note: ‘sprintf’ output between 8 and 18 bytes into a destination of size 16
     4551 |                 sprintf(vi->rq[i].name, "input.%d", i);
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/net/virtio_net.c: In function ‘init_vqs’:
    drivers/net/virtio_net.c:4552:49: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of size 9 [-Wformat-overflow=]
     4552 |                 sprintf(vi->sq[i].name, "output.%d", i);
          |                                                 ^~
    In function ‘virtnet_find_vqs’,
        inlined from ‘init_vqs’ at drivers/net/virtio_net.c:4645:8:
    drivers/net/virtio_net.c:4552:41: note: directive argument in the range [-2147483643, 65534]
     4552 |                 sprintf(vi->sq[i].name, "output.%d", i);
          |                                         ^~~~~~~~~~~
    drivers/net/virtio_net.c:4552:17: note: ‘sprintf’ output between 9 and 19 bytes into a destination of size 16
     4552 |                 sprintf(vi->sq[i].name, "output.%d", i);
    
    "
    
    Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
    Link: https://lore.kernel.org/r/20240104020902.2753599-1-yanjun.zhu@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vlan: skip nested type that is not IFLA_VLAN_QOS_MAPPING [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Thu Jan 18 21:03:06 2024 +0800

    vlan: skip nested type that is not IFLA_VLAN_QOS_MAPPING
    
    [ Upstream commit 6c21660fe221a15c789dee2bc2fd95516bc5aeaf ]
    
    In the vlan_changelink function, a loop is used to parse the nested
    attributes IFLA_VLAN_EGRESS_QOS and IFLA_VLAN_INGRESS_QOS in order to
    obtain the struct ifla_vlan_qos_mapping. These two nested attributes are
    checked in the vlan_validate_qos_map function, which calls
    nla_validate_nested_deprecated with the vlan_map_policy.
    
    However, this deprecated validator applies a LIBERAL strictness, allowing
    the presence of an attribute with the type IFLA_VLAN_QOS_UNSPEC.
    Consequently, the loop in vlan_changelink may parse an attribute of type
    IFLA_VLAN_QOS_UNSPEC and believe it carries a payload of
    struct ifla_vlan_qos_mapping, which is not necessarily true.
    
    To address this issue and ensure compatibility, this patch introduces two
    type checks that skip attributes whose type is not IFLA_VLAN_QOS_MAPPING.
    
    Fixes: 07b5b17e157b ("[VLAN]: Use rtnl_link API")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240118130306.1644001-1-linma@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
watchdog: it87_wdt: Keep WDTCTRL bit 3 unmodified for IT8784/IT8786 [+ + +]
Author: Werner Fischer <devlists@wefi.net>
Date:   Wed Dec 13 10:45:25 2023 +0100

    watchdog: it87_wdt: Keep WDTCTRL bit 3 unmodified for IT8784/IT8786
    
    [ Upstream commit d12971849d71781c1e4ffd1117d4878ce233d319 ]
    
    WDTCTRL bit 3 sets the mode choice for the clock input of IT8784/IT8786.
    Some motherboards require this bit to be set to 1 (= PCICLK mode),
    otherwise the watchdog functionality gets broken. The BIOS of those
    motherboards sets WDTCTRL bit 3 already to 1.
    
    Instead of setting all bits of WDTCTRL to 0 by writing 0x00 to it, keep
    bit 3 of it unchanged for IT8784/IT8786 chips. In this way, bit 3 keeps
    the status as set by the BIOS of the motherboard.
    
    Watchdog tests have been successful with this patch with the following
    systems:
      IT8784: Thomas-Krenn LES plus v2 (YANLING YL-KBRL2 V2)
      IT8786: Thomas-Krenn LES plus v3 (YANLING YL-CLU L2)
      IT8786: Thomas-Krenn LES network 6L v2 (YANLING YL-CLU6L)
    
    Link: https://lore.kernel.org/all/140b264d-341f-465b-8715-dacfe84b3f71@roeck-us.net/
    
    Signed-off-by: Werner Fischer <devlists@wefi.net>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20231213094525.11849-4-devlists@wefi.net
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus() [+ + +]
Author: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Date:   Wed Nov 22 20:31:04 2023 +0200

    wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()
    
    [ Upstream commit 2adc886244dff60f948497b59affb6c6ebb3c348 ]
    
    Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug
    occurs when txs->cnt, data from a URB provided by a USB device, is
    bigger than the size of the array txs->txstatus, which is
    HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug
    handling code after the check. Make the function return if that is the
    case.
    
    Found by a modified version of syzkaller.
    
    UBSAN: array-index-out-of-bounds in htc_drv_txrx.c
    index 13 is out of range for type '__wmi_event_txstatus [12]'
    Call Trace:
     ath9k_htc_txstatus
     ath9k_wmi_event_tasklet
     tasklet_action_common
     __do_softirq
     irq_exit_rxu
     sysvec_apic_timer_interrupt
    
    Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
    Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20231113065756.1491991-1-linuxlovemin@yonsei.ac.kr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: fix RCU dereference in __cfg80211_bss_update [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Wed Jan 3 20:13:51 2024 +0800

    wifi: cfg80211: fix RCU dereference in __cfg80211_bss_update
    
    [ Upstream commit 1184950e341c11b6f82bc5b59564411d9537ab27 ]
    
    Replace rcu_dereference() with rcu_access_pointer() since we hold
    the lock here (and aren't in an RCU critical section).
    
    Fixes: 32af9a9e1069 ("wifi: cfg80211: free beacon_ies when overridden from hidden BSS")
    Reported-and-tested-by: syzbot+864a269c27ee06b58374@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Link: https://msgid.link/tencent_BF8F0DF0258C8DBF124CDDE4DD8D992DCF07@qq.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: free beacon_ies when overridden from hidden BSS [+ + +]
Author: Benjamin Berg <benjamin.berg@intel.com>
Date:   Wed Dec 20 13:41:41 2023 +0200

    wifi: cfg80211: free beacon_ies when overridden from hidden BSS
    
    [ Upstream commit 32af9a9e1069e55bc02741fb00ac9d0ca1a2eaef ]
    
    This is a more of a cosmetic fix. The branch will only be taken if
    proberesp_ies is set, which implies that beacon_ies is not set unless we
    are connected to an AP that just did a channel switch. And, in that case
    we should have found the BSS in the internal storage to begin with.
    
    Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20231220133549.b898e22dadff.Id8c4c10aedd176ef2e18a4cad747b299f150f9df@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: fix a memory corruption [+ + +]
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Thu Jan 11 15:07:25 2024 +0200

    wifi: iwlwifi: fix a memory corruption
    
    commit cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d upstream.
    
    iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that
    if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in
    bytes, we'll write past the buffer.
    
    Cc: stable@vger.kernel.org
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218233
    Fixes: cf29c5b66b9f ("iwlwifi: dbg_ini: implement time point handling")
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240111150610.2d2b8b870194.I14ed76505a5cf87304e0c9cc05cc0ae85ed3bf91@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: iwlwifi: Fix some error codes [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Feb 8 13:17:06 2024 +0300

    wifi: iwlwifi: Fix some error codes
    
    [ Upstream commit c6ebb5b67641994de8bc486b33457fe0b681d6fe ]
    
    This saves the error as PTR_ERR(wifi_pkg).  The problem is that
    "wifi_pkg" is a valid pointer, not an error pointer.  Set the error code
    to -EINVAL instead.
    
    Fixes: 2a8084147bff ("iwlwifi: acpi: support reading and storing WRDS revision 1 and 2")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://msgid.link/9620bb77-2d7c-4d76-b255-ad824ebf8e35@moroto.mountain
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: reload info pointer in ieee80211_tx_dequeue() [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Jan 31 16:49:10 2024 +0100

    wifi: mac80211: reload info pointer in ieee80211_tx_dequeue()
    
    commit c98d8836b817d11fdff4ca7749cbbe04ff7f0c64 upstream.
    
    This pointer can change here since the SKB can change, so we
    actually later open-coded IEEE80211_SKB_CB() again. Reload
    the pointer where needed, so the monitor-mode case using it
    gets fixed, and then use info-> later as well.
    
    Cc: stable@vger.kernel.org
    Fixes: 531682159092 ("mac80211: fix VLAN handling with TXQs")
    Link: https://msgid.link/20240131164910.b54c28d583bc.I29450cec84ea6773cff5d9c16ff92b836c331471@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: rt2x00: restart beacon queue when hardware reset [+ + +]
Author: Shiji Yang <yangshiji66@outlook.com>
Date:   Sat Nov 4 16:58:00 2023 +0800

    wifi: rt2x00: restart beacon queue when hardware reset
    
    [ Upstream commit a11d965a218f0cd95b13fe44d0bcd8a20ce134a8 ]
    
    When a hardware reset is triggered, all registers are reset, so all
    queues are forced to stop in hardware interface. However, mac80211
    will not automatically stop the queue. If we don't manually stop the
    beacon queue, the queue will be deadlocked and unable to start again.
    This patch fixes the issue where Apple devices cannot connect to the
    AP after calling ieee80211_restart_hw().
    
    Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
    Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/TYAP286MB031530EB6D98DCE4DF20766CBCA4A@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtl8xxxu: Add additional USB IDs for RTL8192EU devices [+ + +]
Author: Zenm Chen <zenmchen@gmail.com>
Date:   Sun Dec 17 20:30:17 2023 +0800

    wifi: rtl8xxxu: Add additional USB IDs for RTL8192EU devices
    
    [ Upstream commit 4e87ca403e2008b9e182239e1abbf6876a55eb33 ]
    
    Add additional USB IDs found in the vendor driver from
    https://github.com/Mange/rtl8192eu-linux-driver to support more
    RTL8192EU devices.
    
    Signed-off-by: Zenm Chen <zenmchen@gmail.com>
    Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231217123017.1982-1-zenmchen@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtlwifi: rtl8723{be,ae}: using calculate_bit_shift() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Tue Dec 19 14:57:39 2023 +0800

    wifi: rtlwifi: rtl8723{be,ae}: using calculate_bit_shift()
    
    [ Upstream commit 5c16618bc06a41ad68fd8499a21d35ef57ca06c2 ]
    
    Using calculate_bit_shift() to replace rtl8723_phy_calculate_bit_shift().
    And fix an undefined bitwise shift behavior problem.
    
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20231219065739.1895666-12-suhui@nfschina.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/boot: Ignore NMIs during very early boot [+ + +]
Author: Jun'ichi Nomura <junichi.nomura@nec.com>
Date:   Wed Nov 29 15:44:49 2023 -0500

    x86/boot: Ignore NMIs during very early boot
    
    [ Upstream commit 78a509fba9c9b1fcb77f95b7c6be30da3d24823a ]
    
    When there are two racing NMIs on x86, the first NMI invokes NMI handler and
    the 2nd NMI is latched until IRET is executed.
    
    If panic on NMI and panic kexec are enabled, the first NMI triggers
    panic and starts booting the next kernel via kexec. Note that the 2nd
    NMI is still latched. During the early boot of the next kernel, once
    an IRET is executed as a result of a page fault, then the 2nd NMI is
    unlatched and invokes the NMI handler.
    
    However, NMI handler is not set up at the early stage of boot, which
    results in a boot failure.
    
    Avoid such problems by setting up a NOP handler for early NMIs.
    
    [ mingo: Refined the changelog. ]
    
    Signed-off-by: Jun'ichi Nomura <junichi.nomura@nec.com>
    Signed-off-by: Derek Barbosa <debarbos@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Paul E. McKenney <paulmck@kernel.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/entry/ia32: Ensure s32 is sign extended to s64 [+ + +]
Author: Richard Palethorpe <rpalethorpe@suse.com>
Date:   Wed Jan 10 15:01:22 2024 +0200

    x86/entry/ia32: Ensure s32 is sign extended to s64
    
    commit 56062d60f117dccfb5281869e0ab61e090baf864 upstream.
    
    Presently ia32 registers stored in ptregs are unconditionally cast to
    unsigned int by the ia32 stub. They are then cast to long when passed to
    __se_sys*, but will not be sign extended.
    
    This takes the sign of the syscall argument into account in the ia32
    stub. It still casts to unsigned int to avoid implementation specific
    behavior. However then casts to int or unsigned int as necessary. So that
    the following cast to long sign extends the value.
    
    This fixes the io_pgetevents02 LTP test when compiled with -m32. Presently
    the systemcall io_pgetevents_time64() unexpectedly accepts -1 for the
    maximum number of events.
    
    It doesn't appear other systemcalls with signed arguments are effected
    because they all have compat variants defined and wired up.
    
    Fixes: ebeb8c82ffaf ("syscalls/x86: Use 'struct pt_regs' based syscall calling for IA32_EMULATION and x32")
    Suggested-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Richard Palethorpe <rpalethorpe@suse.com>
    Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240110130122.3836513-1-nik.borisov@suse.com
    Link: https://lore.kernel.org/ltp/20210921130127.24131-1-rpalethorpe@suse.com/
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/Kconfig: Transmeta Crusoe is CPU family 5, not 6 [+ + +]
Author: Aleksander Mazur <deweloper@wp.pl>
Date:   Tue Jan 23 14:43:00 2024 +0100

    x86/Kconfig: Transmeta Crusoe is CPU family 5, not 6
    
    commit f6a1892585cd19e63c4ef2334e26cd536d5b678d upstream.
    
    The kernel built with MCRUSOE is unbootable on Transmeta Crusoe.  It shows
    the following error message:
    
      This kernel requires an i686 CPU, but only detected an i586 CPU.
      Unable to boot - please use a kernel appropriate for your CPU.
    
    Remove MCRUSOE from the condition introduced in commit in Fixes, effectively
    changing X86_MINIMUM_CPU_FAMILY back to 5 on that machine, which matches the
    CPU family given by CPUID.
    
      [ bp: Massage commit message. ]
    
    Fixes: 25d76ac88821 ("x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig")
    Signed-off-by: Aleksander Mazur <deweloper@wp.pl>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/20240123134309.1117782-1-deweloper@wp.pl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/mce: Mark fatal MCE's page as poison to avoid panic in the kdump kernel [+ + +]
Author: Zhiquan Li <zhiquan1.li@intel.com>
Date:   Thu Oct 26 08:39:03 2023 +0800

    x86/mce: Mark fatal MCE's page as poison to avoid panic in the kdump kernel
    
    [ Upstream commit 9f3b130048bfa2e44a8cfb1b616f826d9d5d8188 ]
    
    Memory errors don't happen very often, especially fatal ones. However,
    in large-scale scenarios such as data centers, that probability
    increases with the amount of machines present.
    
    When a fatal machine check happens, mce_panic() is called based on the
    severity grading of that error. The page containing the error is not
    marked as poison.
    
    However, when kexec is enabled, tools like makedumpfile understand when
    pages are marked as poison and do not touch them so as not to cause
    a fatal machine check exception again while dumping the previous
    kernel's memory.
    
    Therefore, mark the page containing the error as poisoned so that the
    kexec'ed kernel can avoid accessing the page.
    
      [ bp: Rewrite commit message and comment. ]
    
    Co-developed-by: Youquan Song <youquan.song@intel.com>
    Signed-off-by: Youquan Song <youquan.song@intel.com>
    Signed-off-by: Zhiquan Li <zhiquan1.li@intel.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
    Link: https://lore.kernel.org/r/20231014051754.3759099-1-zhiquan1.li@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/mm/ident_map: Use gbpages only where full GB page should be mapped. [+ + +]
Author: Steve Wahl <steve.wahl@hpe.com>
Date:   Fri Jan 26 10:48:41 2024 -0600

    x86/mm/ident_map: Use gbpages only where full GB page should be mapped.
    
    commit d794734c9bbfe22f86686dc2909c25f5ffe1a572 upstream.
    
    When ident_pud_init() uses only gbpages to create identity maps, large
    ranges of addresses not actually requested can be included in the
    resulting table; a 4K request will map a full GB.  On UV systems, this
    ends up including regions that will cause hardware to halt the system
    if accessed (these are marked "reserved" by BIOS).  Even processor
    speculation into these regions is enough to trigger the system halt.
    
    Only use gbpages when map creation requests include the full GB page
    of space.  Fall back to using smaller 2M pages when only portions of a
    GB page are included in the request.
    
    No attempt is made to coalesce mapping requests. If a request requires
    a map entry at the 2M (pmd) level, subsequent mapping requests within
    the same 1G region will also be at the pmd level, even if adjacent or
    overlapping such requests could have been combined to map a full
    gbpage.  Existing usage starts with larger regions and then adds
    smaller regions, so this should not have any great consequence.
    
    [ dhansen: fix up comment formatting, simplifty changelog ]
    
    Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/20240126164841.170866-1-steve.wahl%40hpe.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xen-netback: properly sync TX responses [+ + +]
Author: Jan Beulich <jbeulich@suse.com>
Date:   Mon Jan 29 14:03:08 2024 +0100

    xen-netback: properly sync TX responses
    
    commit 7b55984c96ffe9e236eb9c82a2196e0b1f84990d upstream.
    
    Invoking the make_tx_response() / push_tx_responses() pair with no lock
    held would be acceptable only if all such invocations happened from the
    same context (NAPI instance or dealloc thread). Since this isn't the
    case, and since the interface "spec" also doesn't demand that multicast
    operations may only be performed with no in-flight transmits,
    MCAST_{ADD,DEL} processing also needs to acquire the response lock
    around the invocations.
    
    To prevent similar mistakes going forward, "downgrade" the present
    functions to private helpers of just the two remaining ones using them
    directly, with no forward declarations anymore. This involves renaming
    what so far was make_tx_response(), for the new function of that name
    to serve the new (wrapper) purpose.
    
    While there,
    - constify the txp parameters,
    - correct xenvif_idx_release()'s status parameter's type,
    - rename {,_}make_tx_response()'s status parameters for consistency with
      xenvif_idx_release()'s.
    
    Fixes: 210c34dcd8d9 ("xen-netback: add support for multicast control")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Paul Durrant <paul@xen.org>
    Link: https://lore.kernel.org/r/980c6c3d-e10e-4459-8565-e8fbde122f00@suse.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xen/gntdev: Fix the abuse of underlying struct page in DMA-buf import [+ + +]
Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Date:   Sun Jan 7 12:34:26 2024 +0200

    xen/gntdev: Fix the abuse of underlying struct page in DMA-buf import
    
    [ Upstream commit 2d2db7d40254d5fb53b11ebd703cd1ed0c5de7a1 ]
    
    DO NOT access the underlying struct page of an sg table exported
    by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
    Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
    
    Fortunately, here (for special Xen device) we can avoid using
    pages and calculate gfns directly from dma addresses provided by
    the sg table.
    
    Suggested-by: Daniel Vetter <daniel@ffwll.ch>
    Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Acked-by: Daniel Vetter <daniel@ffwll.ch>
    Link: https://lore.kernel.org/r/20240107103426.2038075-1-olekstysh@gmail.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xfs: read only mounts with fsopen mount API are busted [+ + +]
Author: Dave Chinner <dchinner@redhat.com>
Date:   Tue Jan 16 15:33:07 2024 +1100

    xfs: read only mounts with fsopen mount API are busted
    
    commit d8d222e09dab84a17bb65dda4b94d01c565f5327 upstream.
    
    Recently xfs/513 started failing on my test machines testing "-o
    ro,norecovery" mount options. This was being emitted in dmesg:
    
    [ 9906.932724] XFS (pmem0): no-recovery mounts must be read-only.
    
    Turns out, readonly mounts with the fsopen()/fsconfig() mount API
    have been busted since day zero. It's only taken 5 years for debian
    unstable to start using this "new" mount API, and shortly after this
    I noticed xfs/513 had started to fail as per above.
    
    The syscall trace is:
    
    fsopen("xfs", FSOPEN_CLOEXEC)           = 3
    mount_setattr(-1, NULL, 0, NULL, 0)     = -1 EINVAL (Invalid argument)
    .....
    fsconfig(3, FSCONFIG_SET_STRING, "source", "/dev/pmem0", 0) = 0
    fsconfig(3, FSCONFIG_SET_FLAG, "ro", NULL, 0) = 0
    fsconfig(3, FSCONFIG_SET_FLAG, "norecovery", NULL, 0) = 0
    fsconfig(3, FSCONFIG_CMD_CREATE, NULL, NULL, 0) = -1 EINVAL (Invalid argument)
    close(3)                                = 0
    
    Showing that the actual mount instantiation (FSCONFIG_CMD_CREATE) is
    what threw out the error.
    
    During mount instantiation, we call xfs_fs_validate_params() which
    does:
    
            /* No recovery flag requires a read-only mount */
            if (xfs_has_norecovery(mp) && !xfs_is_readonly(mp)) {
                    xfs_warn(mp, "no-recovery mounts must be read-only.");
                    return -EINVAL;
            }
    
    and xfs_is_readonly() checks internal mount flags for read only
    state. This state is set in xfs_init_fs_context() from the
    context superblock flag state:
    
            /*
             * Copy binary VFS mount flags we are interested in.
             */
            if (fc->sb_flags & SB_RDONLY)
                    set_bit(XFS_OPSTATE_READONLY, &mp->m_opstate);
    
    With the old mount API, all of the VFS specific superblock flags
    had already been parsed and set before xfs_init_fs_context() is
    called, so this all works fine.
    
    However, in the brave new fsopen/fsconfig world,
    xfs_init_fs_context() is called from fsopen() context, before any
    VFS superblock have been set or parsed. Hence if we use fsopen(),
    the internal XFS readonly state is *never set*. Hence anything that
    depends on xfs_is_readonly() actually returning true for read only
    mounts is broken if fsopen() has been used to mount the filesystem.
    
    Fix this by moving this internal state initialisation to
    xfs_fs_fill_super() before we attempt to validate the parameters
    that have been set prior to the FSCONFIG_CMD_CREATE call being made.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Fixes: 73e5fff98b64 ("xfs: switch to use the new mount-api")
    cc: stable@vger.kernel.org
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>