Linux 6.1.77

 
9p: Fix initialisation of netfs_inode for 9p [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Tue Jan 2 20:33:17 2024 +0000

    9p: Fix initialisation of netfs_inode for 9p
    
    [ Upstream commit 9546ac78b232bac56ff975072b1965e0e755ebd4 ]
    
    The 9p filesystem is calling netfs_inode_init() in v9fs_init_inode() -
    before the struct inode fields have been initialised from the obtained file
    stats (ie. after v9fs_stat2inode*() has been called), but netfslib wants to
    set a couple of its fields from i_size.
    
    Reported-by: Marc Dionne <marc.dionne@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Marc Dionne <marc.dionne@auristor.com>
    Tested-by: Dominique Martinet <asmadeus@codewreck.org>
    Acked-by: Dominique Martinet <asmadeus@codewreck.org>
    cc: Eric Van Hensbergen <ericvh@kernel.org>
    cc: Latchesar Ionkov <lucho@ionkov.net>
    cc: Dominique Martinet <asmadeus@codewreck.org>
    cc: Christian Schoenebeck <linux_oss@crudebyte.com>
    cc: v9fs@lists.linux.dev
    cc: linux-cachefs@redhat.com
    cc: linux-fsdevel@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
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: NUMA: Fix the logic of getting the fake_pxm value [+ + +]
Author: Yuntao Wang <ytcoode@gmail.com>
Date:   Wed Dec 6 18:43:18 2023 +0800

    ACPI: NUMA: Fix the logic of getting the fake_pxm value
    
    [ Upstream commit e3f577830ce216b0ca21d4750cbbd64cfc21efff ]
    
    The for loop does not iterate over the last element of the node_to_pxm_map
    array. This could lead to a conflict between the final fake_pxm value and
    the existing pxm values. That is, the final fake_pxm value can not be
    guaranteed to be an unused pxm value.
    
    While at it, fix up white space in slit_valid().
    
    Signed-off-by: Yuntao Wang <ytcoode@gmail.com>
    [ rjw: Changelog edits ]
    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: 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>

 
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>

 
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: 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>

 
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: amlogic: fix format for s4 uart node [+ + +]
Author: Xianwei Zhao <xianwei.zhao@amlogic.com>
Date:   Fri Dec 15 16:28:00 2023 +0800

    arm64: dts: amlogic: fix format for s4 uart node
    
    [ Upstream commit eb54ef36282f670c704ed5af8593da62bebba80d ]
    
    Aliases use lowercase letters and place status in end.
    
    Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20231215-s4-dts-v1-1-7831ab6972be@amlogic.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    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: 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>

 
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: 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>

 
asm-generic: make sparse happy with odd-sized put_unaligned_*() [+ + +]
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Sun Jan 7 22:16:45 2024 -0800

    asm-generic: make sparse happy with odd-sized put_unaligned_*()
    
    [ Upstream commit 1ab33c03145d0f6c345823fc2da935d9a1a9e9fc ]
    
    __put_unaligned_be24() and friends use implicit casts to convert
    larger-sized data to bytes, which trips sparse truncation warnings when
    the argument is a constant:
    
        CC [M]  drivers/input/touchscreen/hynitron_cstxxx.o
        CHECK   drivers/input/touchscreen/hynitron_cstxxx.c
      drivers/input/touchscreen/hynitron_cstxxx.c: note: in included file (through arch/x86/include/generated/asm/unaligned.h):
      include/asm-generic/unaligned.h:119:16: warning: cast truncates bits from constant value (aa01a0 becomes a0)
      include/asm-generic/unaligned.h:120:20: warning: cast truncates bits from constant value (aa01 becomes 1)
      include/asm-generic/unaligned.h:119:16: warning: cast truncates bits from constant value (ab00d0 becomes d0)
      include/asm-generic/unaligned.h:120:20: warning: cast truncates bits from constant value (ab00 becomes 0)
    
    To avoid this let's mask off upper bits explicitly, the resulting code
    should be exactly the same, but it will keep sparse happy.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Closes: https://lore.kernel.org/oe-kbuild-all/202401070147.gqwVulOn-lkp@intel.com/
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
ASoC: amd: Add new dmi entries for acp5x platform [+ + +]
Author: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Date:   Wed Dec 6 16:36:12 2023 +0530

    ASoC: amd: Add new dmi entries for acp5x platform
    
    [ Upstream commit c3ab23a10771bbe06300e5374efa809789c65455 ]
    
    Add sys_vendor and product_name dmi entries for acp5x platform.
    
    Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
    Link: https://lore.kernel.org/r/20231206110620.1695591-1-venkataprasad.potturu@amd.com
    Signed-off-by: Mark Brown <broonie@kernel.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: wsa883x: fix PA volume control [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Fri Jan 19 12:24:17 2024 +0100

    ASoC: codecs: wsa883x: fix PA volume control
    
    commit b53cc6144a3f6c8b56afcdec89d81195c9b0dc69 upstream.
    
    The PA gain can be set in steps of 1.5 dB from -3 dB to 18 dB, that is,
    in 15 levels.
    
    Fix the dB values for the PA volume control as experiments using wsa8835
    show that the first 16 levels all map to the same lowest gain while the
    last three map to the highest gain.
    
    These values specifically need to be correct for the sound server to
    provide proper volume control.
    
    Note that level 0 (-3 dB) does not mute the PA so the mute flag should
    also not be set.
    
    Fixes: cdb09e623143 ("ASoC: codecs: wsa883x: add control, dapm widgets and map")
    Cc: stable@vger.kernel.org      # 6.0
    Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://msgid.link/r/20240119112420.7446-2-johan+linaro@kernel.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>

 
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>

 
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: 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: hci_sync: fix BR/EDR wakeup bug [+ + +]
Author: clancy shang <clancy.shang@quectel.com>
Date:   Mon Dec 18 18:24:17 2023 +0800

    Bluetooth: hci_sync: fix BR/EDR wakeup bug
    
    [ Upstream commit d4b70ba1eab450eff9c5ef536f07c01d424b7eda ]
    
    when Bluetooth set the event mask and enter suspend, the controller
    has hci mode change event coming, it cause controller can not enter
    sleep mode. so it should to set the hci mode change event mask before
    enter suspend.
    
    Signed-off-by: clancy shang <clancy.shang@quectel.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    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>

 
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: Check rcu_read_lock_trace_held() before calling bpf map helpers [+ + +]
Author: Hou Tao <houtao1@huawei.com>
Date:   Mon Dec 4 22:04:19 2023 +0800

    bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
    
    [ Upstream commit 169410eba271afc9f0fb476d996795aa26770c6d ]
    
    These three bpf_map_{lookup,update,delete}_elem() helpers are also
    available for sleepable bpf program, so add the corresponding lock
    assertion for sleepable bpf program, otherwise the following warning
    will be reported when a sleepable bpf program manipulates bpf map under
    interpreter mode (aka bpf_jit_enable=0):
    
      WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......
      CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
      RIP: 0010:bpf_map_lookup_elem+0x54/0x60
      ......
      Call Trace:
       <TASK>
       ? __warn+0xa5/0x240
       ? bpf_map_lookup_elem+0x54/0x60
       ? report_bug+0x1ba/0x1f0
       ? handle_bug+0x40/0x80
       ? exc_invalid_op+0x18/0x50
       ? asm_exc_invalid_op+0x1b/0x20
       ? __pfx_bpf_map_lookup_elem+0x10/0x10
       ? rcu_lockdep_current_cpu_online+0x65/0xb0
       ? rcu_is_watching+0x23/0x50
       ? bpf_map_lookup_elem+0x54/0x60
       ? __pfx_bpf_map_lookup_elem+0x10/0x10
       ___bpf_prog_run+0x513/0x3b70
       __bpf_prog_run32+0x9d/0xd0
       ? __bpf_prog_enter_sleepable_recur+0xad/0x120
       ? __bpf_prog_enter_sleepable_recur+0x3e/0x120
       bpf_trampoline_6442580665+0x4d/0x1000
       __x64_sys_getpgid+0x5/0x30
       ? do_syscall_64+0x36/0xb0
       entry_SYSCALL_64_after_hwframe+0x6e/0x76
       </TASK>
    
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/r/20231204140425.1480317-2-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>

 
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: fix invalid pointer access if get_quota_realm return ERR_PTR [+ + +]
Author: Wenchao Hao <haowenchao2@huawei.com>
Date:   Thu Nov 23 09:53:40 2023 +0800

    ceph: fix invalid pointer access if get_quota_realm return ERR_PTR
    
    [ Upstream commit 0f4cf64eabc6e16cfc2704f1960e82dc79d91c8d ]
    
    This issue is reported by smatch that get_quota_realm() might return
    ERR_PTR but we did not handle it. It's not a immediate bug, while we
    still should address it to avoid potential bugs if get_quota_realm()
    is changed to return other ERR_PTR in future.
    
    Set ceph_snap_realm's pointer in get_quota_realm()'s to address this
    issue, the pointer would be set to NULL if get_quota_realm() failed
    to get struct ceph_snap_realm, so no ERR_PTR would happen any more.
    
    [ xiubli: minor code style clean up ]
    
    Signed-off-by: Wenchao Hao <haowenchao2@huawei.com>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ceph: reinitialize mds feature bit even when session in open [+ + +]
Author: Venky Shankar <vshankar@redhat.com>
Date:   Mon Nov 6 10:02:32 2023 +0530

    ceph: reinitialize mds feature bit even when session in open
    
    [ Upstream commit f48e0342a74d7770cdf1d11894bdc3b6d989b29e ]
    
    Following along the same lines as per the user-space fix. Right
    now this isn't really an issue with the ceph kernel driver because
    of the feature bit laginess, however, that can change over time
    (when the new snaprealm info type is ported to the kernel driver)
    and depending on the MDS version that's being upgraded can cause
    message decoding issues - so, fix that early on.
    
    Link: http://tracker.ceph.com/issues/63188
    Signed-off-by: Venky Shankar <vshankar@redhat.com>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
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: 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>

 
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: 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>

 
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>

 
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: For prefetch mode > 0, extend prefetch if possible [+ + +]
Author: Alvin Lee <alvin.lee2@amd.com>
Date:   Wed Dec 6 14:52:31 2023 -0500

    drm/amd/display: For prefetch mode > 0, extend prefetch if possible
    
    [ Upstream commit dd4e4bb28843393065eed279e869fac248d03f0f ]
    
    [Description]
    For mode programming we want to extend the prefetch as much as possible
    (up to oto, or as long as we can for equ) if we're not already applying
    the 60us prefetch requirement. This is to avoid intermittent underflow
    issues during prefetch.
    
    The prefetch extension is applied under the following scenarios:
    1. We're in prefetch mode 1 (i.e. we don't support MCLK switch in blank)
    2. We're using subvp or drr methods of p-state switch, in which case we
       we don't care if prefetch takes up more of the blanking time
    
    Mode programming typically chooses the smallest prefetch time possible
    (i.e. highest bandwidth during prefetch) presumably to create margin between
    p-states / c-states that happen in vblank and prefetch. Therefore we only
    apply this prefetch extension when p-state in vblank is not required (UCLK
    p-states take up the most vblank time).
    
    Reviewed-by: Jun Lei <jun.lei@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Alvin Lee <alvin.lee2@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: make flip_timestamp_in_us a 64-bit variable [+ + +]
Author: Josip Pavic <josip.pavic@amd.com>
Date:   Tue Dec 5 12:01:05 2023 -0500

    drm/amd/display: make flip_timestamp_in_us a 64-bit variable
    
    [ Upstream commit 6fb12518ca58412dc51054e2a7400afb41328d85 ]
    
    [Why]
    This variable currently overflows after about 71 minutes. This doesn't
    cause any known functional issues but it does make debugging more
    difficult.
    
    [How]
    Make it a 64-bit variable.
    
    Reviewed-by: Aric Cyr <aric.cyr@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Josip Pavic <josip.pavic@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
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 '*fw' from request_firmware() not released in 'amdgpu_ucode_request()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Wed Jan 3 22:22:44 2024 +0530

    drm/amdgpu: Fix '*fw' from request_firmware() not released in 'amdgpu_ucode_request()'
    
    [ Upstream commit 13a1851f923d9a7a78a477497295c2dfd16ad4a4 ]
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:1404 amdgpu_ucode_request() warn: '*fw' from request_firmware() not released on lines: 1404.
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Lijo Lazar <lijo.lazar@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: 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: Fix ecc irq enable/disable unpaired [+ + +]
Author: Stanley.Yang <Stanley.Yang@amd.com>
Date:   Fri Dec 15 16:13:23 2023 +0800

    drm/amdgpu: Fix ecc irq enable/disable unpaired
    
    [ Upstream commit a32c6f7f5737cc7e31cd7ad5133f0d96fca12ea6 ]
    
    The ecc_irq is disabled while GPU mode2 reset suspending process,
    but not be enabled during GPU mode2 reset resume process.
    
    Changed from V1:
            only do sdma/gfx ras_late_init in aldebaran_mode2_restore_ip
            delete amdgpu_ras_late_resume function
    
    Changed from V2:
            check umc ras supported before put ecc_irq
    
    Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com>
    Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@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: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Tue Jan 30 12:10:38 2024 +0530

    drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()'
    
    [ Upstream commit 16da399091dca3d1e48109086403587af37cc196 ]
    
    Return 0 for success scenairos in 'gmc_v6/7/8/9_0_hw_init()'
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:920 gmc_v6_0_hw_init() warn: missing error code? 'r'
    drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:1104 gmc_v7_0_hw_init() warn: missing error code? 'r'
    drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1224 gmc_v8_0_hw_init() warn: missing error code? 'r'
    drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:2347 gmc_v9_0_hw_init() warn: missing error code? 'r'
    
    Fixes: fac4ebd79fed ("drm/amdgpu: Fix with right return code '-EIO' in 'amdgpu_gmc_vram_checking()'")
    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: 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: Fix with right return code '-EIO' in 'amdgpu_gmc_vram_checking()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Thu Jan 4 15:26:42 2024 +0530

    drm/amdgpu: Fix with right return code '-EIO' in 'amdgpu_gmc_vram_checking()'
    
    [ Upstream commit fac4ebd79fed60e79cccafdad45a2bb8d3795044 ]
    
    The amdgpu_gmc_vram_checking() function in emulation checks whether
    all of the memory range of shared system memory could be accessed by
    GPU, from this aspect, -EIO is returned for error scenarios.
    
    Fixes the below:
    drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:919 gmc_v6_0_hw_init() warn: missing error code? 'r'
    drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:1103 gmc_v7_0_hw_init() warn: missing error code? 'r'
    drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1223 gmc_v8_0_hw_init() warn: missing error code? 'r'
    drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:2344 gmc_v9_0_hw_init() warn: missing error code? 'r'
    
    Cc: Xiaojian Du <Xiaojian.Du@amd.com>
    Cc: Lijo Lazar <lijo.lazar@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: Christian König <christian.koenig@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 iterator used outside loop in 'kfd_add_peer_prop()' [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Fri Dec 29 15:07:09 2023 +0530

    drm/amdkfd: Fix iterator used outside loop in 'kfd_add_peer_prop()'
    
    [ Upstream commit b1a428b45dc7e47c7acc2ad0d08d8a6dda910c4c ]
    
    Fix the following about iterator use:
    drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1456 kfd_add_peer_prop() warn: iterator used outside loop: 'iolink3'
    
    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/amdkfd: Fix lock dependency warning with srcu [+ + +]
Author: Philip Yang <Philip.Yang@amd.com>
Date:   Fri Dec 29 15:19:25 2023 -0500

    drm/amdkfd: Fix lock dependency warning with srcu
    
    [ Upstream commit 2a9de42e8d3c82c6990d226198602be44f43f340 ]
    
    ======================================================
    WARNING: possible circular locking dependency detected
    6.5.0-kfd-yangp #2289 Not tainted
    ------------------------------------------------------
    kworker/0:2/996 is trying to acquire lock:
            (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0
    
    but task is already holding lock:
            ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at:
            process_one_work+0x211/0x560
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}:
            __flush_work+0x88/0x4f0
            svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu]
            svm_range_set_attr+0xd6/0x14c0 [amdgpu]
            kfd_ioctl+0x1d1/0x630 [amdgpu]
            __x64_sys_ioctl+0x88/0xc0
    
    -> #2 (&info->lock#2){+.+.}-{3:3}:
            __mutex_lock+0x99/0xc70
            amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu]
            restore_process_helper+0x22/0x80 [amdgpu]
            restore_process_worker+0x2d/0xa0 [amdgpu]
            process_one_work+0x29b/0x560
            worker_thread+0x3d/0x3d0
    
    -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}:
            __flush_work+0x88/0x4f0
            __cancel_work_timer+0x12c/0x1c0
            kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu]
            __mmu_notifier_release+0xad/0x240
            exit_mmap+0x6a/0x3a0
            mmput+0x6a/0x120
            do_exit+0x322/0xb90
            do_group_exit+0x37/0xa0
            __x64_sys_exit_group+0x18/0x20
            do_syscall_64+0x38/0x80
    
    -> #0 (srcu){.+.+}-{0:0}:
            __lock_acquire+0x1521/0x2510
            lock_sync+0x5f/0x90
            __synchronize_srcu+0x4f/0x1a0
            __mmu_notifier_release+0x128/0x240
            exit_mmap+0x6a/0x3a0
            mmput+0x6a/0x120
            svm_range_deferred_list_work+0x19f/0x350 [amdgpu]
            process_one_work+0x29b/0x560
            worker_thread+0x3d/0x3d0
    
    other info that might help us debug this:
    Chain exists of:
      srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work)
    
    Possible unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
            lock((work_completion)(&svms->deferred_list_work));
                            lock(&info->lock#2);
                            lock((work_completion)(&svms->deferred_list_work));
            sync(srcu);
    
    Signed-off-by: Philip Yang <Philip.Yang@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/bridge: anx7625: Fix Set HPD irq detect window to 2ms [+ + +]
Author: Xin Ji <xji@analogixsemi.com>
Date:   Mon Nov 20 17:10:37 2023 +0800

    drm/bridge: anx7625: Fix Set HPD irq detect window to 2ms
    
    [ Upstream commit e3af7053de3f685c96158373bc234b2feca1f160 ]
    
    Polling firmware HPD GPIO status, set HPD irq detect window to 2ms
    after firmware HPD GPIO initial done
    
    Signed-off-by: Xin Ji <xji@analogixsemi.com>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231120091038.284825-2-xji@analogixsemi.com
    Signed-off-by: Sasha Levin <sashal@kernel.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/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/dpu: fix writeback programming for YUV cases [+ + +]
Author: Abhinav Kumar <quic_abhinavk@quicinc.com>
Date:   Tue Dec 12 12:52:41 2023 -0800

    drm/msm/dpu: fix writeback programming for YUV cases
    
    [ Upstream commit 79caf2f2202b9eaad3a5a726e4b33807f67d0f1b ]
    
    For YUV cases, setting the required format bits was missed
    out in the register programming. Lets fix it now in preparation
    of adding YUV formats support for writeback.
    
    changes in v2:
        - dropped the fixes tag as its not a fix but adding
          new functionality
    
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/571814/
    Link: https://lore.kernel.org/r/20231212205254.12422-4-quic_abhinavk@quicinc.com
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    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 Jun 20 13:43:21 2023 +0200

    drm/msm/dsi: Enable runtime PM
    
    commit 6ab502bc1cf3147ea1d8540d04b83a7a4cb6d1f1 upstream.
    
    Some devices power the DSI PHY/PLL through a power rail that we model
    as a GENPD. Enable runtime PM to make it suspendable.
    
    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>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/panel-edp: Add override_edid_mode quirk for generic edp [+ + +]
Author: Hsin-Yi Wang <hsinyi@chromium.org>
Date:   Fri Nov 17 13:46:32 2023 -0800

    drm/panel-edp: Add override_edid_mode quirk for generic edp
    
    [ Upstream commit 9f7843b515811aea6c56527eb195b622e9c01f12 ]
    
    Generic edp gets mode from edid. However, some panels report incorrect
    mode in this way, resulting in glitches on panel. Introduce a new quirk
    additional_mode to the generic edid to pick a correct hardcoded mode.
    
    Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20231117215056.1883314-2-hsinyi@chromium.org
    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>

 
erofs: fix ztailpacking for subpage compressed blocks [+ + +]
Author: Gao Xiang <xiang@kernel.org>
Date:   Fri Dec 15 00:13:37 2023 +0800

    erofs: fix ztailpacking for subpage compressed blocks
    
    [ Upstream commit e5aba911dee5e20fa82efbe13e0af8f38ea459e7 ]
    
    `pageofs_in` should be the compressed data offset of the page rather
    than of the block.
    
    Acked-by: Chao Yu <chao@kernel.org>
    Reviewed-by: Yue Hu <huyue2@coolpad.com>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20231214161337.753049-1-hsiangkao@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.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 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>

 
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>

 
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>

 
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: hidraw: fix a problem of memory leak in hidraw_release() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Thu Jan 25 14:32:26 2024 +0800

    HID: hidraw: fix a problem of memory leak in hidraw_release()
    
    [ Upstream commit a3bdcdd022c68942a774e8e63424cc11c85aab78 ]
    
    'struct hidraw_list' is a circular queue whose head can be smaller than
    tail. Using 'list->tail != list->head' to release all memory that should
    be released.
    
    Fixes: a5623a203cff ("HID: hidraw: fix memory leak in hidraw_release()")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (nct6775) Fix fan speed set failure in automatic mode [+ + +]
Author: Xing Tong Wu <xingtong.wu@siemens.com>
Date:   Tue Nov 21 16:16:04 2023 +0800

    hwmon: (nct6775) Fix fan speed set failure in automatic mode
    
    [ Upstream commit 8b3800256abad20e91c2698607f9b28591407b19 ]
    
    Setting the fan speed is only valid in manual mode; it is not possible
    to set the fan's speed in automatic mode.
    Return error when attempting to set the fan speed in automatic mode.
    
    Signed-off-by: Xing Tong Wu <xingtong.wu@siemens.com>
    Link: https://lore.kernel.org/r/20231121081604.2499-3-xingtong_wu@163.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    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>

 
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>

 
ice: fix ICE_AQ_VSI_Q_OPT_RSS_* register values [+ + +]
Author: Ahmed Zaki <ahmed.zaki@intel.com>
Date:   Tue Dec 12 17:33:17 2023 -0700

    ice: fix ICE_AQ_VSI_Q_OPT_RSS_* register values
    
    [ Upstream commit 20f73b60bb5c276cee9b1a530f100c677bc74af8 ]
    
    Fix the values of the ICE_AQ_VSI_Q_OPT_RSS_* registers. Shifting is
    already done when the values are used, no need to double shift. Bug was
    not discovered earlier since only ICE_AQ_VSI_Q_OPT_RSS_TPLZ (Zero) is
    currently used.
    
    Also, rename ICE_AQ_VSI_Q_OPT_RSS_XXX to ICE_AQ_VSI_Q_OPT_RSS_HASH_XXX
    for consistency.
    
    Co-developed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com>
    Link: https://lore.kernel.org/r/20231213003321.605376-5-ahmed.zaki@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: fix pre-shifted bit usage [+ + +]
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date:   Tue Dec 5 17:01:06 2023 -0800

    ice: fix pre-shifted bit usage
    
    [ Upstream commit 7173be21ae29ef50ada42fd4464056a9d3f55bb3 ]
    
    While converting to FIELD_PREP() and FIELD_GET(), it was noticed that
    some of the RSS defines had *included* the shift in their definitions.
    This is completely outside of normal, such that a developer could easily
    make a mistake and shift at the usage site (like when using
    FIELD_PREP()).
    
    Rename the defines and set them to the "pre-shifted values" so they
    match the template the driver normally uses for masks and the member
    bits of the mask, which also allows the driver to use FIELD_PREP
    correctly with these values. Use GENMASK() for this changed MASK value.
    
    Do the same for the VLAN EMODE defines as well.
    
    Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@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>

 
ionic: bypass firmware cmds when stuck in reset [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Mon Dec 11 10:57:59 2023 -0800

    ionic: bypass firmware cmds when stuck in reset
    
    [ Upstream commit ca5fdf9a7c5b65968c718f2be159cda4c13556a1 ]
    
    If the driver or firmware is stuck in reset state, don't bother
    trying to use adminq commands.  This speeds up shutdown and
    prevents unnecessary timeouts and error messages.
    
    This includes a bit of rework on ionic_adminq_post_wait()
    and ionic_adminq_post_wait_nomsg() to both use
    __ionic_adminq_post_wait() which can do the checks needed in
    both cases.
    
    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>

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>

 
ipmr: fix kernel panic when forwarding mcast packets [+ + +]
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Thu Jan 25 15:18:47 2024 +0100

    ipmr: fix kernel panic when forwarding mcast packets
    
    [ Upstream commit e622502c310f1069fd9f41cd38210553115f610a ]
    
    The stacktrace was:
    [   86.305548] BUG: kernel NULL pointer dereference, address: 0000000000000092
    [   86.306815] #PF: supervisor read access in kernel mode
    [   86.307717] #PF: error_code(0x0000) - not-present page
    [   86.308624] PGD 0 P4D 0
    [   86.309091] Oops: 0000 [#1] PREEMPT SMP NOPTI
    [   86.309883] CPU: 2 PID: 3139 Comm: pimd Tainted: G     U             6.8.0-6wind-knet #1
    [   86.311027] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014
    [   86.312728] RIP: 0010:ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985)
    [ 86.313399] Code: f9 1f 0f 87 85 03 00 00 48 8d 04 5b 48 8d 04 83 49 8d 44 c5 00 48 8b 40 70 48 39 c2 0f 84 d9 00 00 00 49 8b 46 58 48 83 e0 fe <80> b8 92 00 00 00 00 0f 84 55 ff ff ff 49 83 47 38 01 45 85 e4 0f
    [   86.316565] RSP: 0018:ffffad21c0583ae0 EFLAGS: 00010246
    [   86.317497] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    [   86.318596] RDX: ffff9559cb46c000 RSI: 0000000000000000 RDI: 0000000000000000
    [   86.319627] RBP: ffffad21c0583b30 R08: 0000000000000000 R09: 0000000000000000
    [   86.320650] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
    [   86.321672] R13: ffff9559c093a000 R14: ffff9559cc00b800 R15: ffff9559c09c1d80
    [   86.322873] FS:  00007f85db661980(0000) GS:ffff955a79d00000(0000) knlGS:0000000000000000
    [   86.324291] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   86.325314] CR2: 0000000000000092 CR3: 000000002f13a000 CR4: 0000000000350ef0
    [   86.326589] Call Trace:
    [   86.327036]  <TASK>
    [   86.327434] ? show_regs (/build/work/knet/arch/x86/kernel/dumpstack.c:479)
    [   86.328049] ? __die (/build/work/knet/arch/x86/kernel/dumpstack.c:421 /build/work/knet/arch/x86/kernel/dumpstack.c:434)
    [   86.328508] ? page_fault_oops (/build/work/knet/arch/x86/mm/fault.c:707)
    [   86.329107] ? do_user_addr_fault (/build/work/knet/arch/x86/mm/fault.c:1264)
    [   86.329756] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
    [   86.330350] ? __irq_work_queue_local (/build/work/knet/kernel/irq_work.c:111 (discriminator 1))
    [   86.331013] ? exc_page_fault (/build/work/knet/./arch/x86/include/asm/paravirt.h:693 /build/work/knet/arch/x86/mm/fault.c:1515 /build/work/knet/arch/x86/mm/fault.c:1563)
    [   86.331702] ? asm_exc_page_fault (/build/work/knet/./arch/x86/include/asm/idtentry.h:570)
    [   86.332468] ? ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985)
    [   86.333183] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
    [   86.333920] ipmr_mfc_add (/build/work/knet/./include/linux/rcupdate.h:782 /build/work/knet/net/ipv4/ipmr.c:1009 /build/work/knet/net/ipv4/ipmr.c:1273)
    [   86.334583] ? __pfx_ipmr_hash_cmp (/build/work/knet/net/ipv4/ipmr.c:363)
    [   86.335357] ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470)
    [   86.336135] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
    [   86.336854] ? ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470)
    [   86.337679] do_ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:944)
    [   86.338408] ? __pfx_unix_stream_read_actor (/build/work/knet/net/unix/af_unix.c:2862)
    [   86.339232] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
    [   86.339809] ? aa_sk_perm (/build/work/knet/security/apparmor/include/cred.h:153 /build/work/knet/security/apparmor/net.c:181)
    [   86.340342] ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:1415)
    [   86.340859] raw_setsockopt (/build/work/knet/net/ipv4/raw.c:836)
    [   86.341408] ? security_socket_setsockopt (/build/work/knet/security/security.c:4561 (discriminator 13))
    [   86.342116] sock_common_setsockopt (/build/work/knet/net/core/sock.c:3716)
    [   86.342747] do_sock_setsockopt (/build/work/knet/net/socket.c:2313)
    [   86.343363] __sys_setsockopt (/build/work/knet/./include/linux/file.h:32 /build/work/knet/net/socket.c:2336)
    [   86.344020] __x64_sys_setsockopt (/build/work/knet/net/socket.c:2340)
    [   86.344766] do_syscall_64 (/build/work/knet/arch/x86/entry/common.c:52 /build/work/knet/arch/x86/entry/common.c:83)
    [   86.345433] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
    [   86.346161] ? syscall_exit_work (/build/work/knet/./include/linux/audit.h:357 /build/work/knet/kernel/entry/common.c:160)
    [   86.346938] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
    [   86.347657] ? syscall_exit_to_user_mode (/build/work/knet/kernel/entry/common.c:215)
    [   86.348538] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223)
    [   86.349262] ? do_syscall_64 (/build/work/knet/./arch/x86/include/asm/cpufeature.h:171 /build/work/knet/arch/x86/entry/common.c:98)
    [   86.349971] entry_SYSCALL_64_after_hwframe (/build/work/knet/arch/x86/entry/entry_64.S:129)
    
    The original packet in ipmr_cache_report() may be queued and then forwarded
    with ip_mr_forward(). This last function has the assumption that the skb
    dst is set.
    
    After the below commit, the skb dst is dropped by ipv4_pktinfo_prepare(),
    which causes the oops.
    
    Fixes: bb7403655b3c ("ipmr: support IP_PKTINFO on cache report IGMP msg")
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240125141847.1931933-1-nicolas.dichtel@6wind.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv4: raw: add drop reasons [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 2 09:40:59 2023 +0000

    ipv4: raw: add drop reasons
    
    [ Upstream commit 42186e6c00352ce9df9e3f12b1ff82e61978d40b ]
    
    Use existing helpers and drop reason codes for RAW input path.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: e622502c310f ("ipmr: fix kernel panic when forwarding mcast packets")
    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>

 
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>

 
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>

 
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 6.1.77 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 5 20:13:03 2024 +0000

    Linux 6.1.77
    
    Link: https://lore.kernel.org/r/20240203035317.354186483@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Yann Sionneau <ysionneau@kalrayinc.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20240203174756.358721205@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Yann Sionneau <ysionneau@kalrayinc.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.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>

 
LoongArch/smp: Call rcutree_report_cpu_starting() at tlb_init() [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Fri Jan 26 16:22:07 2024 +0800

    LoongArch/smp: Call rcutree_report_cpu_starting() at tlb_init()
    
    commit 5056c596c3d1848021a4eaa76ee42f4c05c50346 upstream.
    
    Machines which have more than 8 nodes fail to boot SMP after commit
    a2ccf46333d7b2cf96 ("LoongArch/smp: Call rcutree_report_cpu_starting()
    earlier"). Because such machines use tlb-based per-cpu base address
    rather than dmw-based per-cpu base address, resulting per-cpu variables
    can only be accessed after tlb_init(). But rcutree_report_cpu_starting()
    is now called before tlb_init() and accesses per-cpu variables indeed.
    
    Since the original patch want to avoid the lockdep warning caused by
    page allocation in tlb_init(), we can move rcutree_report_cpu_starting()
    to tlb_init() where after tlb exception configuration but before page
    allocation.
    
    Fixes: a2ccf46333d7b2cf96 ("LoongArch/smp: Call rcutree_report_cpu_starting() earlier")
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    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: amphion: remove mutext lock in condition of wait_event [+ + +]
Author: Ming Qian <ming.qian@nxp.com>
Date:   Fri Dec 8 15:33:42 2023 +0800

    media: amphion: remove mutext lock in condition of wait_event
    
    [ Upstream commit f9c8ddce2fe3b767582f299d03fc8fb85943568c ]
    
    mutext_lock should not be called in condition of wait_event, otherwise,
    when CONFIG_DEBUG_ATOMIC_SLEEP is enabled, we may meet the following
    warning:
    do not call blocking ops when !TASK_RUNNING; state=2
    WARNING: CPU: 5 PID: 741 at kernel/sched/core.c:9859
    __might_sleep+0x80/0xa4
    Hardware name: Freescale i.MX8QM MEK (DT)
    pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)  pc :
    __might_sleep+0x80/0xa4  lr : __might_sleep+0x80/0xa4  sp : ffffffc0123738a0
    x29: ffffffc0123738a0 x28: ffffffc009194c48 x27: ffffffc00bbc1050
    x26: ffffff8814b282f0 x25: ffffff8814b280d0 x24: ffffff8814b28080
    x23: 0000000000000001 x22: 0000000000000032 x21: ffffffc00bbc1000
    x20: 000000000000011b x19: ffffffc009324670 x18: 00000000fffffffd
    x17: 30303c5b20746120 x16: 74657320323d6574 x15: 617473203b474e49
    x14: 00058b5b8b9aa1f1 x13: ffffffc00903cda0 x12: 00000000d744fcc9
    x11: 000000000000001c x10: 00000000000009a0 x9 : ffffffc0090201f4
    x8 : ffffff8828245000 x7 : 0000000000000001 x6 : 0000000000000001
    x5 : 00000000410fd080 x4 : 0000000000000002 x3 : ffffff8815aab4c8
    x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8828244600
    Call trace:
     __might_sleep+0x80/0xa4
     mutex_lock+0x2c/0x80
     sync_session_response+0x110/0x310
     vpu_session_send_cmd+0x18c/0x244
     vpu_session_start+0x38/0x70
     vdec_start_session+0x1b4/0x3e0
     vpu_vb2_start_streaming+0xa0/0x1c4
     vb2_start_streaming+0x74/0x160
     vb2_core_qbuf+0x488/0x650
     vb2_qbuf+0x9c/0x100
     v4l2_m2m_qbuf+0x7c/0x224
     v4l2_m2m_ioctl_qbuf+0x20/0x2c
     v4l_qbuf+0x50/0x6c
     __video_do_ioctl+0x174/0x3f0
     video_usercopy+0x210/0x7cc
     video_ioctl2+0x20/0x30
     v4l2_ioctl+0x48/0x6c
    
    we need to refine check_is_responsed() to remove the mutext_lock, each
    cmd has a monotonically increasing id, and cmds are executed
    sequentially, so we can check the id of the last reponsed cmd, then
    determine whether a command has been responded or not.
    
    Signed-off-by: Ming Qian <ming.qian@nxp.com>
    CC: Xiaolei Wang <xiaolei.wang@windriver.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    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: 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: rkisp1: Fix IRQ disable race issue [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Thu Dec 7 08:57:48 2023 +0100

    media: rkisp1: Fix IRQ disable race issue
    
    [ Upstream commit 870565f063a58576e8a4529f122cac4325c6b395 ]
    
    In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the
    interrupts and then apparently assumes that the interrupt handler won't
    be running, and proceeds in the stop procedure. This is not the case, as
    the interrupt handler can already be running, which would lead to the
    ISP being disabled while the interrupt handler handling a captured
    frame.
    
    This brings up two issues: 1) the ISP could be powered off while the
    interrupt handler is still running and accessing registers, leading to
    board lockup, and 2) the interrupt handler code and the code that
    disables the streaming might do things that conflict.
    
    It is not clear to me if 2) causes a real issue, but 1) can be seen with
    a suitable delay (or printk in my case) in the interrupt handler,
    leading to board lockup.
    
    Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-4-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: rkisp1: Fix IRQ handler return values [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Thu Dec 7 08:57:46 2023 +0100

    media: rkisp1: Fix IRQ handler return values
    
    [ Upstream commit 3eb7910e1b16a2c136be26a8380f21469225b2f6 ]
    
    The IRQ handler rkisp1_isr() calls sub-handlers, all of which returns an
    irqreturn_t value, but rkisp1_isr() ignores those values and always
    returns IRQ_HANDLED.
    
    Fix this by collecting the return values, and returning IRQ_HANDLED or
    IRQ_NONE as appropriate.
    
    Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-2-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: rkisp1: Store IRQ lines [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Thu Dec 7 08:57:47 2023 +0100

    media: rkisp1: Store IRQ lines
    
    [ Upstream commit 0753874617de883c6d4da903142f334f76a75d70 ]
    
    Store the IRQ lines used by the driver for easy access. These are needed
    in future patches which fix IRQ race issues.
    
    Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-3-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>

 
misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Dec 24 19:34:02 2023 +0100

    misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback
    
    [ Upstream commit b1b9f7a494400c0c39f8cd83de3aaa6111c55087 ]
    
    The lis3lv02d_i2c driver was missing a line to set the lis3_dev's
    reg_ctrl callback.
    
    lis3_reg_ctrl(on) is called from the init callback, but due to
    the missing reg_ctrl callback the regulators where never turned off
    again leading to the following oops/backtrace when detaching the driver:
    
    [   82.313527] ------------[ cut here ]------------
    [   82.313546] WARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put+0x219/0x230
    ...
    [   82.313695] RIP: 0010:_regulator_put+0x219/0x230
    ...
    [   82.314767] Call Trace:
    [   82.314770]  <TASK>
    [   82.314772]  ? _regulator_put+0x219/0x230
    [   82.314777]  ? __warn+0x81/0x170
    [   82.314784]  ? _regulator_put+0x219/0x230
    [   82.314791]  ? report_bug+0x18d/0x1c0
    [   82.314801]  ? handle_bug+0x3c/0x80
    [   82.314806]  ? exc_invalid_op+0x13/0x60
    [   82.314812]  ? asm_exc_invalid_op+0x16/0x20
    [   82.314845]  ? _regulator_put+0x219/0x230
    [   82.314857]  regulator_bulk_free+0x39/0x60
    [   82.314865]  i2c_device_remove+0x22/0xb0
    
    Add the missing setting of the callback so that the regulators
    properly get turned off again when not used.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20231224183402.95640-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm, kmsan: fix infinite recursion due to RCU critical section [+ + +]
Author: Marco Elver <elver@google.com>
Date:   Thu Jan 18 11:59:14 2024 +0100

    mm, kmsan: fix infinite recursion due to RCU critical section
    
    commit f6564fce256a3944aa1bc76cb3c40e792d97c1eb upstream.
    
    Alexander Potapenko writes in [1]: "For every memory access in the code
    instrumented by KMSAN we call kmsan_get_metadata() to obtain the metadata
    for the memory being accessed.  For virtual memory the metadata pointers
    are stored in the corresponding `struct page`, therefore we need to call
    virt_to_page() to get them.
    
    According to the comment in arch/x86/include/asm/page.h,
    virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) is
    true, so KMSAN needs to call virt_addr_valid() as well.
    
    To avoid recursion, kmsan_get_metadata() must not call instrumented code,
    therefore ./arch/x86/include/asm/kmsan.h forks parts of
    arch/x86/mm/physaddr.c to check whether a virtual address is valid or not.
    
    But the introduction of rcu_read_lock() to pfn_valid() added instrumented
    RCU API calls to virt_to_page_or_null(), which is called by
    kmsan_get_metadata(), so there is an infinite recursion now.  I do not
    think it is correct to stop that recursion by doing
    kmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): that
    would prevent instrumented functions called from within the runtime from
    tracking the shadow values, which might introduce false positives."
    
    Fix the issue by switching pfn_valid() to the _sched() variant of
    rcu_read_lock/unlock(), which does not require calling into RCU.  Given
    the critical section in pfn_valid() is very small, this is a reasonable
    trade-off (with preemptible RCU).
    
    KMSAN further needs to be careful to suppress calls into the scheduler,
    which would be another source of recursion.  This can be done by wrapping
    the call to pfn_valid() into preempt_disable/enable_no_resched().  The
    downside is that this sacrifices breaking scheduling guarantees; however,
    a kernel compiled with KMSAN has already given up any performance
    guarantees due to being heavily instrumented.
    
    Note, KMSAN code already disables tracing via Makefile, and since mmzone.h
    is included, it is not necessary to use the notrace variant, which is
    generally preferred in all other cases.
    
    Link: https://lkml.kernel.org/r/20240115184430.2710652-1-glider@google.com [1]
    Link: https://lkml.kernel.org/r/20240118110022.2538350-1-elver@google.com
    Fixes: 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage")
    Signed-off-by: Marco Elver <elver@google.com>
    Reported-by: Alexander Potapenko <glider@google.com>
    Reported-by: syzbot+93a9e8a3dea8d6085e12@syzkaller.appspotmail.com
    Reviewed-by: Alexander Potapenko <glider@google.com>
    Tested-by: Alexander Potapenko <glider@google.com>
    Cc: Charan Teja Kalla <quic_charante@quicinc.com>
    Cc: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/smc: disable SEID on non-s390 archs where virtual ISM may be used [+ + +]
Author: Wen Gu <guwen@linux.alibaba.com>
Date:   Tue Dec 19 22:26:15 2023 +0800

    net/smc: disable SEID on non-s390 archs where virtual ISM may be used
    
    [ Upstream commit c6b8b8eb49904018e22e4e4b1fa502e57dc747d9 ]
    
    The system EID (SEID) is an internal EID used by SMC-D to represent the
    s390 physical machine that OS is executing on. On s390 architecture, it
    predefined by fixed string and part of cpuid and is enabled regardless
    of whether underlay device is virtual ISM or platform firmware ISM.
    
    However on non-s390 architectures where SMC-D can be used with virtual
    ISM devices, there is no similar information to identify physical
    machines, especially in virtualization scenarios. So in such cases, SEID
    is forcibly disabled and the user-defined UEID will be used to represent
    the communicable space.
    
    Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
    Reviewed-and-tested-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: atlantic: eliminate double free in error handling logic [+ + +]
Author: Igor Russkikh <irusskikh@marvell.com>
Date:   Wed Dec 13 10:50:44 2023 +0100

    net: atlantic: eliminate double free in error handling logic
    
    [ Upstream commit b3cb7a830a24527877b0bc900b9bd74a96aea928 ]
    
    Driver has a logic leak in ring data allocation/free,
    where aq_ring_free could be called multiple times on same ring,
    if system is under stress and got memory allocation error.
    
    Ring pointer was used as an indicator of failure, but this is
    not correct since only ring data is allocated/deallocated.
    Ring itself is an array member.
    
    Changing ring allocation functions to return error code directly.
    This simplifies error handling and eliminates aq_ring_free
    on higher layer.
    
    Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
    Link: https://lore.kernel.org/r/20231213095044.23146-1-irusskikh@marvell.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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: dsa: qca8k: fix illegal usage of GPIO [+ + +]
Author: Michal Vokáč <michal.vokac@ysoft.com>
Date:   Fri Jan 26 11:49:35 2024 +0100

    net: dsa: qca8k: fix illegal usage of GPIO
    
    [ Upstream commit c44fc98f0a8ffd94fa0bd291928e7e312ffc7ca4 ]
    
    When working with GPIO, its direction must be set either when the GPIO is
    requested by gpiod_get*() or later on by one of the gpiod_direction_*()
    functions. Neither of this is done here which results in undefined
    behavior on some systems.
    
    As the reset GPIO is used right after it is requested here, it makes sense
    to configure it as GPIOD_OUT_HIGH right away. With that, the following
    gpiod_set_value_cansleep(1) becomes redundant and can be safely
    removed.
    
    Fixes: a653f2f538f9 ("net: dsa: qca8k: introduce reset via gpio feature")
    Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/1706266175-3408-1-git-send-email-michal.vokac@ysoft.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: qca8k: put MDIO bus OF node on qca8k_mdio_register() failure [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Thu Jan 4 16:00:31 2024 +0200

    net: dsa: qca8k: put MDIO bus OF node on qca8k_mdio_register() failure
    
    [ Upstream commit 68e1010cda7967cfca9c8650ee1f4efcae54ab90 ]
    
    of_get_child_by_name() gives us an OF node with an elevated refcount,
    which should be dropped when we're done with it. This is so that,
    if (of_node_check_flag(node, OF_DYNAMIC)) is true, the node's memory can
    eventually be freed.
    
    There are 2 distinct paths to be considered in qca8k_mdio_register():
    
    - devm_of_mdiobus_register() succeeds: since commit 3b73a7b8ec38 ("net:
      mdio_bus: add refcounting for fwnodes to mdiobus"), the MDIO core
      treats this well.
    
    - devm_of_mdiobus_register() or anything up to that point fails: it is
      the duty of the qca8k driver to release the OF node.
    
    This change addresses the second case by making sure that the OF node
    reference is not leaked.
    
    The "mdio" node may be NULL, but of_node_put(NULL) is safe.
    
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.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: lan966x: Fix port configuration when using SGMII interface [+ + +]
Author: Horatiu Vultur <horatiu.vultur@microchip.com>
Date:   Wed Jan 24 11:17:58 2024 +0100

    net: lan966x: Fix port configuration when using SGMII interface
    
    [ Upstream commit 62b4248105353e7d1debd30ca5c57ec5e5f28e35 ]
    
    In case the interface between the MAC and the PHY is SGMII, then the bit
    GIGA_MODE on the MAC side needs to be set regardless of the speed at
    which it is running.
    
    Fixes: d28d6d2e37d1 ("net: lan966x: add port module support")
    Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: at803x: fix passing the wrong reference for config_intr [+ + +]
Author: Christian Marangi <ansuelsmth@gmail.com>
Date:   Fri Dec 8 15:51:48 2023 +0100

    net: phy: at803x: fix passing the wrong reference for config_intr
    
    [ Upstream commit f8fdbf3389f44c7026f16e36cb1f2ff017f7f5b2 ]
    
    Fix passing the wrong reference for config_initr on passing the function
    pointer, drop the wrong & from at803x_config_intr in the PHY struct.
    
    Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.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: usb: ax88179_178a: avoid two consecutive device resets [+ + +]
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Date:   Mon Nov 20 13:11:41 2023 +0100

    net: usb: ax88179_178a: avoid two consecutive device resets
    
    [ Upstream commit d2689b6a86b9d23574bd4b654bf770b6034e2c7e ]
    
    The device is always reset two consecutive times (ax88179_reset is called
    twice), one from usbnet_probe during the device binding and the other from
    usbnet_open.
    
    Remove the non-necessary reset during the device binding and let the reset
    operation from open to keep the normal behavior (tested with generic ASIX
    Electronics Corp. AX88179 Gigabit Ethernet device).
    
    Reported-by: Herb Wei <weihao.bj@ieisystem.com>
    Tested-by: Herb Wei <weihao.bj@ieisystem.com>
    Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Link: https://lore.kernel.org/r/20231120121239.54504-1-jtornosm@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: conntrack: correct window scaling with retransmitted SYN [+ + +]
Author: Ryan Schaefer <ryanschf@amazon.com>
Date:   Sun Jan 21 21:51:44 2024 +0000

    netfilter: conntrack: correct window scaling with retransmitted SYN
    
    [ Upstream commit fb366fc7541a1de521ab3df58471746aa793b833 ]
    
    commit c7aab4f17021 ("netfilter: nf_conntrack_tcp: re-init for syn packets
    only") introduces a bug where SYNs in ORIGINAL direction on reused 5-tuple
    result in incorrect window scale negotiation. This commit merged the SYN
    re-initialization and simultaneous open or SYN retransmits cases. Merging
    this block added the logic in tcp_init_sender() that performed window scale
    negotiation to the retransmitted syn case. Previously. this would only
    result in updating the sender's scale and flags. After the merge the
    additional logic results in improperly clearing the scale in ORIGINAL
    direction before any packets in the REPLY direction are received. This
    results in packets incorrectly being marked invalid for being
    out-of-window.
    
    This can be reproduced with the following trace:
    
    Packet Sequence:
    > Flags [S], seq 1687765604, win 62727, options [.. wscale 7], length 0
    > Flags [S], seq 1944817196, win 62727, options [.. wscale 7], length 0
    
    In order to fix the issue, only evaluate window negotiation for packets
    in the REPLY direction. This was tested with simultaneous open, fast
    open, and the above reproduction.
    
    Fixes: c7aab4f17021 ("netfilter: nf_conntrack_tcp: re-init for syn packets only")
    Signed-off-by: Ryan Schaefer <ryanschf@amazon.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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: 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: 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>

 
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>

 
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>

 
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>

 
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/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/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>

 
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>

 
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>

regulator: ti-abb: don't use devm_platform_ioremap_resource_byname for shared interrupt register [+ + +]
Author: Romain Naour <romain.naour@skf.com>
Date:   Tue Jan 23 12:14:56 2024 +0100

    regulator: ti-abb: don't use devm_platform_ioremap_resource_byname for shared interrupt register
    
    [ Upstream commit a67e1f0bd4564b485e0f0c3ed7f6bf17688be268 ]
    
    We can't use devm_platform_ioremap_resource_byname() to remap the
    interrupt register that can be shared between
    regulator-abb-{ivahd,dspeve,gpu} drivers instances.
    
    The combined helper introduce a call to devm_request_mem_region() that
    creates a new busy resource region on PRM_IRQSTATUS_MPU register
    (0x4ae06010). The first devm_request_mem_region() call succeeds for
    regulator-abb-ivahd but fails for the two other regulator-abb-dspeve
    and regulator-abb-gpu.
    
      # cat /proc/iomem | grep -i 4ae06
      4ae06010-4ae06013 : 4ae07e34.regulator-abb-ivahd int-address
      4ae06014-4ae06017 : 4ae07ddc.regulator-abb-mpu int-address
    
    regulator-abb-dspeve and regulator-abb-gpu are missing due to
    devm_request_mem_region() failure (EBUSY):
    
      [    1.326660] ti_abb 4ae07e30.regulator-abb-dspeve: can't request region for resource [mem 0x4ae06010-0x4ae06013]
      [    1.326660] ti_abb: probe of 4ae07e30.regulator-abb-dspeve failed with error -16
      [    1.327239] ti_abb 4ae07de4.regulator-abb-gpu: can't request region for resource [mem 0x4ae06010-0x4ae06013]
      [    1.327270] ti_abb: probe of 4ae07de4.regulator-abb-gpu failed with error -16
    
    >From arm/boot/dts/dra7.dtsi:
    
    The abb_mpu is the only instance using its own interrupt register:
      (0x4ae06014) PRM_IRQSTATUS_MPU_2, ABB_MPU_DONE_ST (bit 7)
    
    The other tree instances (abb_ivahd, abb_dspeve, abb_gpu) share
    PRM_IRQSTATUS_MPU register (0x4ae06010) but use different bits
    ABB_IVA_DONE_ST (bit 30), ABB_DSPEVE_DONE_ST( bit 29) and
    ABB_GPU_DONE_ST (but 28).
    
    The commit b36c6b1887ff ("regulator: ti-abb: Make use of the helper
    function devm_ioremap related") overlooked the following comment
    implicitly explaining why devm_ioremap() is used in this case:
    
      /*
       * We may have shared interrupt register offsets which are
       * write-1-to-clear between domains ensuring exclusivity.
       */
    
    Fixes and partially reverts commit b36c6b1887ff ("regulator: ti-abb:
    Make use of the helper function devm_ioremap related").
    
    Improve the existing comment to avoid further conversion to
    devm_platform_ioremap_resource_byname().
    
    Fixes: b36c6b1887ff ("regulator: ti-abb: Make use of the helper function devm_ioremap related")
    Signed-off-by: Romain Naour <romain.naour@skf.com>
    Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
    Link: https://msgid.link/r/20240123111456.739381-1-romain.naour@smile.fr
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "drm/amd/display: Disable PSR-SU on Parade 0803 TCON again" [+ + +]
Author: Jonathan Gray <jsg@jsg.id.au>
Date:   Fri Feb 2 13:04:47 2024 +1100

    Revert "drm/amd/display: Disable PSR-SU on Parade 0803 TCON again"
    
    This reverts commit 85d16c03ddd3f9b10212674e16ee8662b185bd14.
    
    duplicated a change made in 6.1.69
    20907717918f0487258424631b704c7248a72da2
    
    Cc: stable@vger.kernel.org # 6.1
    Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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/vfio-ap: fix sysfs status attribute for AP queue devices [+ + +]
Author: Tony Krowiak <akrowiak@linux.ibm.com>
Date:   Wed Nov 8 15:11:30 2023 -0500

    s390/vfio-ap: fix sysfs status attribute for AP queue devices
    
    [ Upstream commit a0d8f4eeb7c4ffaee21702bcc91a09b3988c5b7a ]
    
    The 'status' attribute for AP queue devices bound to the vfio_ap device
    driver displays incorrect status when the mediated device is attached to a
    guest, but the queue device is not passed through. In the current
    implementation, the status displayed is 'in_use' which is not correct; it
    should be 'assigned'. This can happen if one of the queue devices
    associated with a given adapter is not bound to the vfio_ap device driver.
    For example:
    
    Queues listed in /sys/bus/ap/drivers/vfio_ap:
    14.0005
    14.0006
    14.000d
    16.0006
    16.000d
    
    Queues listed in /sys/devices/vfio_ap/matrix/$UUID/matrix
    14.0005
    14.0006
    14.000d
    16.0005
    16.0006
    16.000d
    
    Queues listed in /sys/devices/vfio_ap/matrix/$UUID/guest_matrix
    14.0005
    14.0006
    14.000d
    
    The reason no queues for adapter 0x16 are listed in the guest_matrix is
    because queue 16.0005 is not bound to the vfio_ap device driver, so no
    queue associated with the adapter is passed through to the guest;
    therefore, each queue device for adapter 0x16 should display 'assigned'
    instead of 'in_use', because those queues are not in use by a guest, but
    only assigned to the mediated device.
    
    Let's check the AP configuration for the guest to determine whether a
    queue device is passed through before displaying a status of 'in_use'.
    
    Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
    Acked-by: Halil Pasic <pasic@linux.ibm.com>
    Acked-by: Harald Freudenberger <freude@linux.ibm.com>
    Link: https://lore.kernel.org/r/20231108201135.351419-1-akrowiak@linux.ibm.com
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.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: hisi_sas: Set .phy_attached before notifing phyup event HISI_PHYE_PHY_UP_PM [+ + +]
Author: Yihang Li <liyihang9@huawei.com>
Date:   Thu Dec 14 11:45:12 2023 +0800

    scsi: hisi_sas: Set .phy_attached before notifing phyup event HISI_PHYE_PHY_UP_PM
    
    [ Upstream commit ce26497c745d0541aec930d5211b431a1c26af97 ]
    
    Currently in directly attached scenario, the phyup event
    HISI_PHYE_PHY_UP_PM is notified before .phy_attached is set - this may
    cause the phyup work hisi_sas_bytes_dmaed() execution failed and the
    attached device will not be found.
    
    To fix it, set .phy_attached before notifing phyup event.
    
    Signed-off-by: Yihang Li <liyihang9@huawei.com>
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Link: https://lore.kernel.org/r/1702525516-51258-2-git-send-email-chenxiang66@hisilicon.com
    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: mpi3mr: Add PCI checks where SAS5116 diverges from SAS4116 [+ + +]
Author: Sumit Saxena <sumit.saxena@broadcom.com>
Date:   Thu Nov 23 21:31:29 2023 +0530

    scsi: mpi3mr: Add PCI checks where SAS5116 diverges from SAS4116
    
    [ Upstream commit c9260ff28ee561fca5f96425c9328a9698e8427b ]
    
    Add PCI IDs checks for the cases where SAS5116 diverges from SAS4116 in
    behavior.
    
    Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
    Link: https://lore.kernel.org/r/20231123160132.4155-3-sumit.saxena@broadcom.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    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: bonding: Check initial state [+ + +]
Author: Benjamin Poirier <bpoirier@nvidia.com>
Date:   Wed Jan 31 09:08:45 2024 -0500

    selftests: bonding: Check initial state
    
    [ Upstream commit 8cc063ae1b3dbe416ce62a15d49af4c2314b45fe ]
    
    The purpose of the test_LAG_cleanup() function is to check that some
    hardware addresses are removed from underlying devices after they have been
    unenslaved. The test function simply checks that those addresses are not
    present at the end. However, if the addresses were never added to begin
    with due to some error in device setup, the test function currently passes.
    This is a false positive since in that situation the test did not actually
    exercise the intended functionality.
    
    Add a check that the expected addresses are indeed present after device
    setup. This makes the test function more robust.
    
    I noticed this problem when running the team/dev_addr_lists.sh test on a
    system without support for dummy and ipv6:
    
    tools/testing/selftests/drivers/net/team# ./dev_addr_lists.sh
    Error: Unknown device type.
    Error: Unknown device type.
    This program is not intended to be run as root.
    RTNETLINK answers: Operation not supported
    TEST: team cleanup mode lacp                                        [ OK ]
    
    Fixes: bbb774d921e2 ("net: Add tests for bonding and team address list management")
    Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
    Link: https://lore.kernel.org/r/20240131140848.360618-3-bpoirier@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: add missing config for GENEVE [+ + +]
Author: Matthias May <Matthias.May@westermo.com>
Date:   Tue Jan 30 10:12:18 2024 +0000

    selftests: net: add missing config for GENEVE
    
    [ Upstream commit c9ec85153fea6873c52ed4f5055c87263f1b54f9 ]
    
    l2_tos_ttl_inherit.sh verifies the inheritance of tos and ttl
    for GRETAP, VXLAN and GENEVE.
    Before testing it checks if the required module is available
    and if not skips the tests accordingly.
    Currently only GRETAP and VXLAN are tested because the GENEVE
    module is missing.
    
    Fixes: b690842d12fd ("selftests/net: test l2 tunnel TOS/TTL inheriting")
    Signed-off-by: Matthias May <matthias.may@westermo.com>
    Link: https://lore.kernel.org/r/20240130101157.196006-1-matthias.may@westermo.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: team: Add missing config options [+ + +]
Author: Benjamin Poirier <bpoirier@nvidia.com>
Date:   Wed Jan 31 09:08:44 2024 -0500

    selftests: team: Add missing config options
    
    [ Upstream commit 7b6fb3050d8f5e2b6858eef344e47ac1f5442827 ]
    
    Similar to commit dd2d40acdbb2 ("selftests: bonding: Add more missing
    config options"), add more networking-specific config options which are
    needed for team device tests.
    
    For testing, I used the minimal config generated by virtme-ng and I added
    the options in the config file. Afterwards, the team device test passed.
    
    Fixes: bbb774d921e2 ("net: Add tests for bonding and team address list management")
    Reviewed-by: Petr Machata <petrm@nvidia.com>
    Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
    Link: https://lore.kernel.org/r/20240131140848.360618-2-bpoirier@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
soc: xilinx: Fix for call trace due to the usage of smp_processor_id() [+ + +]
Author: HariBabu Gattem <haribabu.gattem@xilinx.com>
Date:   Thu Oct 26 22:56:22 2023 -0700

    soc: xilinx: Fix for call trace due to the usage of smp_processor_id()
    
    [ Upstream commit daed80ed07580e5adc0e6d8bc79933a35154135a ]
    
    When preemption is enabled in kernel and if any task which can be
    preempted should not use smp_processor_id() directly, since CPU
    switch can happen at any time, the previous value of cpu_id
    differs with current cpu_id. As a result we see the below call trace
    during xlnx_event_manager_probe.
    
    [ 6.140197] dump_backtrace+0x0/0x190
    [ 6.143884] show_stack+0x18/0x40
    [ 6.147220] dump_stack_lvl+0x7c/0xa0
    [ 6.150907] dump_stack+0x18/0x34
    [ 6.154241] check_preemption_disabled+0x124/0x134
    [ 6.159068] debug_smp_processor_id+0x20/0x2c
    [ 6.163453] xlnx_event_manager_probe+0x48/0x250
    
    To protect cpu_id, It is recommended to use get_cpu()/put_cpu()
    to disable preemption, get the cpu_id and enable preemption respectively.
    (For Reference, Documentation/locking/preempt-locking.rst and
    Documentation/kernel-hacking/hacking.rst)
    
    Use preempt_disable()/smp_processor_id()/preempt_enable()
    API's to achieve the same.
    
    Signed-off-by: HariBabu Gattem <haribabu.gattem@xilinx.com>
    Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
    Link: https://lore.kernel.org/r/20231027055622.21544-1-jay.buddhabhatti@amd.com
    Signed-off-by: Michal Simek <michal.simek@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: xilinx: fix unhandled SGI warning message [+ + +]
Author: Tanmay Shah <tanmay.shah@xilinx.com>
Date:   Fri Oct 27 23:53:59 2023 +0530

    soc: xilinx: fix unhandled SGI warning message
    
    [ Upstream commit 9c6724abf969251af53cdae525ad8100ec78d3c2 ]
    
    Xen broadcasts SGI to each VM when multiple VMs run on Xen hypervisor. In
    such case spurious SGI is expected if one event is registered by one VM and
    not registered by another VM. We let users know that Unhandled SGI is not
    error and expected if kernel is running on Xen hypervisor.
    
    Signed-off-by: Tanmay Shah <tanmay.shah@xilinx.com>
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Link: https://lore.kernel.org/r/1698431039-2734260-1-git-send-email-radhey.shyam.pandey@amd.com
    Signed-off-by: Michal Simek <michal.simek@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spmi: mediatek: Fix UAF on device remove [+ + +]
Author: Yu-Che Cheng <giver@chromium.org>
Date:   Wed Dec 6 15:17:25 2023 -0800

    spmi: mediatek: Fix UAF on device remove
    
    [ Upstream commit e821d50ab5b956ed0effa49faaf29912fd4106d9 ]
    
    The pmif driver data that contains the clocks is allocated along with
    spmi_controller.
    On device remove, spmi_controller will be freed first, and then devres
    , including the clocks, will be cleanup.
    This leads to UAF because putting the clocks will access the clocks in
    the pmif driver data, which is already freed along with spmi_controller.
    
    This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and
    building the kernel with KASAN.
    
    Fix the UAF issue by using unmanaged clk_bulk_get() and putting the
    clocks before freeing spmi_controller.
    
    Reported-by: Fei Shao <fshao@chromium.org>
    Signed-off-by: Yu-Che Cheng <giver@chromium.org>
    Link: https://lore.kernel.org/r/20230717173934.1.If004a6e055a189c7f2d0724fa814422c26789839@changeid
    Tested-by: Fei Shao <fshao@chromium.org>
    Reviewed-by: Fei Shao <fshao@chromium.org>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Link: https://lore.kernel.org/r/20231206231733.4031901-3-sboyd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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 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>

 
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>

 
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: hub: Add quirk to decrease IN-ep poll interval for Microchip USB491x hub [+ + +]
Author: Hardik Gajjar <hgajjar@de.adit-jv.com>
Date:   Tue Dec 5 19:18:29 2023 +0100

    usb: hub: Add quirk to decrease IN-ep poll interval for Microchip USB491x hub
    
    [ Upstream commit 855d75cf8311fee156fabb5639bb53757ca83dd4 ]
    
    There is a potential delay in notifying Linux USB drivers of downstream
    USB bus activity when connecting a high-speed or superSpeed device via the
    Microchip USB491x hub. This delay is due to the fixed bInterval value of
    12 in the silicon of the Microchip USB491x hub.
    
    Microchip requested to ignore the device descriptor and decrease that
    value to 9 as it was too late to modify that in silicon.
    
    This patch speeds up the USB enummeration process that helps to pass
    Apple Carplay certifications and improve the User experience when utilizing
    the USB device via Microchip Multihost USB491x Hub.
    
    A new hub quirk HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL speeds up
    the notification process for Microchip USB491x hub by limiting
    the maximum bInterval value to 9.
    
    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-2-hgajjar@de.adit-jv.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
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>

 
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: ath11k: fix race due to setting ATH11K_FLAG_EXT_IRQ_ENABLED too early [+ + +]
Author: Baochen Qiang <quic_bqiang@quicinc.com>
Date:   Fri Nov 17 08:39:19 2023 +0800

    wifi: ath11k: fix race due to setting ATH11K_FLAG_EXT_IRQ_ENABLED too early
    
    [ Upstream commit 5082b3e3027eae393a4e86874bffb4ce3f83c26e ]
    
    We are seeing below error randomly in the case where only
    one MSI vector is configured:
    
    kernel: ath11k_pci 0000:03:00.0: wmi command 16387 timeout
    
    The reason is, currently, in ath11k_pcic_ext_irq_enable(),
    ATH11K_FLAG_EXT_IRQ_ENABLED is set before NAPI is enabled.
    This results in a race condition: after
    ATH11K_FLAG_EXT_IRQ_ENABLED is set but before NAPI enabled,
    CE interrupt breaks in. Since IRQ is shared by CE and data
    path, ath11k_pcic_ext_interrupt_handler() is also called
    where we call disable_irq_nosync() to disable IRQ. Then
    napi_schedule() is called but it does nothing because NAPI
    is not enabled at that time, meaning
    ath11k_pcic_ext_grp_napi_poll() will never run, so we have
    no chance to call enable_irq() to enable IRQ back. Finally
    we get above error.
    
    Fix it by setting ATH11K_FLAG_EXT_IRQ_ENABLED after all
    NAPI and IRQ work are done. With the fix, we are sure that
    by the time ATH11K_FLAG_EXT_IRQ_ENABLED is set, NAPI is
    enabled.
    
    Note that the fix above also introduce some side effects:
    if ath11k_pcic_ext_interrupt_handler() breaks in after NAPI
    enabled but before ATH11K_FLAG_EXT_IRQ_ENABLED set, nothing
    will be done by the handler this time, the work will be
    postponed till the next time the IRQ fires.
    
    Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
    
    Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
    Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20231117003919.26218-1-quic_bqiang@quicinc.com
    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: rt2x00: correct wrong BBP register in RxDCOC calibration [+ + +]
Author: Shiji Yang <yangshiji66@outlook.com>
Date:   Thu Nov 9 12:38:51 2023 +0800

    wifi: rt2x00: correct wrong BBP register in RxDCOC calibration
    
    [ Upstream commit 50da74e1e8b682853d1e07fc8bbe3a0774ae5e09 ]
    
    Refer to Mediatek vendor driver RxDCOC_Calibration() function, when
    performing gainfreeze calibration, we should write register 140
    instead of 141. This fix can reduce the total calibration time from
    6 seconds to 1 second.
    
    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/TYAP286MB0315B13B89DF57B6B27BB854BCAFA@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM
    Signed-off-by: Sasha Levin <sashal@kernel.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>

wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap() [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Mon Dec 4 20:11:28 2023 +0300

    wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()
    
    [ Upstream commit fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d ]
    
    Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()'
    should check the return value before examining skb data. So convert
    the latter to return an appropriate error code and propagate it to
    return from 'wfx_start_ap()' as well. Compile tested only.
    
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Tested-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
    Acked-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20231204171130.141394-1-dmantipov@yandex.ru
    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/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>

 
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>