Changelog in Linux kernel 6.6.33

 
ACPI: disable -Wstringop-truncation [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Apr 9 16:00:55 2024 +0200

    ACPI: disable -Wstringop-truncation
    
    [ Upstream commit a3403d304708f60565582d60af4316289d0316a0 ]
    
    gcc -Wstringop-truncation warns about copying a string that results in a
    missing nul termination:
    
    drivers/acpi/acpica/tbfind.c: In function 'acpi_tb_find_table':
    drivers/acpi/acpica/tbfind.c:60:9: error: 'strncpy' specified bound 6 equals destination size [-Werror=stringop-truncation]
       60 |         strncpy(header.oem_id, oem_id, ACPI_OEM_ID_SIZE);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/acpi/acpica/tbfind.c:61:9: error: 'strncpy' specified bound 8 equals destination size [-Werror=stringop-truncation]
       61 |         strncpy(header.oem_table_id, oem_table_id, ACPI_OEM_TABLE_ID_SIZE);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    The code works as intended, and the warning could be addressed by using
    a memcpy(), but turning the warning off for this file works equally well
    and may be easier to merge.
    
    Fixes: 47c08729bf1c ("ACPICA: Fix for LoadTable operator, input strings")
    Link: https://lore.kernel.org/lkml/CAJZ5v0hoUfv54KW7y4223Mn9E7D4xvR7whRFNLTBqCZMUxT50Q@mail.gmail.com/#t
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: Fix Generic Initiator Affinity _OSC bit [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Sat Mar 9 21:13:09 2024 +0100

    ACPI: Fix Generic Initiator Affinity _OSC bit
    
    [ Upstream commit d0d4f1474e36b195eaad477373127ae621334c01 ]
    
    The ACPI spec says bit 17 should be used to indicate support
    for Generic Initiator Affinity Structure in SRAT, but we currently
    set bit 13 ("Interrupt ResourceSource support").
    
    Fix this by actually setting bit 17 when evaluating _OSC.
    
    Fixes: 01aabca2fd54 ("ACPI: Let ACPI know we support Generic Initiator Affinity Structures")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: LPSS: Advertise number of chip selects via property [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Apr 4 15:06:58 2024 +0300

    ACPI: LPSS: Advertise number of chip selects via property
    
    [ Upstream commit 07b73ee599428b41d0240f2f7b31b524eba07dd0 ]
    
    Advertise number of chip selects via property for Intel Braswell.
    
    Fixes: 620c803f42de ("ACPI: LPSS: Provide an SSP type to the driver")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
af_packet: do not call packet_read_pending() from tpacket_destruct_skb() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed May 15 16:33:58 2024 +0000

    af_packet: do not call packet_read_pending() from tpacket_destruct_skb()
    
    [ Upstream commit 581073f626e387d3e7eed55c48c8495584ead7ba ]
    
    trafgen performance considerably sank on hosts with many cores
    after the blamed commit.
    
    packet_read_pending() is very expensive, and calling it
    in af_packet fast path defeats Daniel intent in commit
    b013840810c2 ("packet: use percpu mmap tx frame pending refcount")
    
    tpacket_destruct_skb() makes room for one packet, we can immediately
    wakeup a producer, no need to completely drain the tx ring.
    
    Fixes: 89ed5b519004 ("af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Neil Horman <nhorman@tuxdriver.com>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20240515163358.4105915-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
af_unix: Annotate data-race around unix_sk(sk)->addr. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu May 23 00:40:02 2024 +0900

    af_unix: Annotate data-race around unix_sk(sk)->addr.
    
    [ Upstream commit 97e1db06c7bb948da10ba85acad8030b56886593 ]
    
    Once unix_sk(sk)->addr is assigned under net->unx.table.locks and
    unix_sk(sk)->bindlock, *(unix_sk(sk)->addr) and unix_sk(sk)->path are
    fully set up, and unix_sk(sk)->addr is never changed.
    
    unix_getname() and unix_copy_addr() access the two fields locklessly,
    and commit ae3b564179bf ("missing barriers in some of unix_sock ->addr
    and ->path accesses") added smp_store_release() and smp_load_acquire()
    pairs.
    
    In other functions, we still read unix_sk(sk)->addr locklessly to check
    if the socket is bound, and KCSAN complains about it.  [0]
    
    Given these functions have no dependency for *(unix_sk(sk)->addr) and
    unix_sk(sk)->path, READ_ONCE() is enough to annotate the data-race.
    
    Note that it is safe to access unix_sk(sk)->addr locklessly if the socket
    is found in the hash table.  For example, the lockless read of otheru->addr
    in unix_stream_connect() is safe.
    
    Note also that newu->addr there is of the child socket that is still not
    accessible from userspace, and smp_store_release() publishes the address
    in case the socket is accept()ed and unix_getname() / unix_copy_addr()
    is called.
    
    [0]:
    BUG: KCSAN: data-race in unix_bind / unix_listen
    
    write (marked) to 0xffff88805f8d1840 of 8 bytes by task 13723 on cpu 0:
     __unix_set_addr_hash net/unix/af_unix.c:329 [inline]
     unix_bind_bsd net/unix/af_unix.c:1241 [inline]
     unix_bind+0x881/0x1000 net/unix/af_unix.c:1319
     __sys_bind+0x194/0x1e0 net/socket.c:1847
     __do_sys_bind net/socket.c:1858 [inline]
     __se_sys_bind net/socket.c:1856 [inline]
     __x64_sys_bind+0x40/0x50 net/socket.c:1856
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x46/0x4e
    
    read to 0xffff88805f8d1840 of 8 bytes by task 13724 on cpu 1:
     unix_listen+0x72/0x180 net/unix/af_unix.c:734
     __sys_listen+0xdc/0x160 net/socket.c:1881
     __do_sys_listen net/socket.c:1890 [inline]
     __se_sys_listen net/socket.c:1888 [inline]
     __x64_sys_listen+0x2e/0x40 net/socket.c:1888
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x46/0x4e
    
    value changed: 0x0000000000000000 -> 0xffff88807b5b1b40
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 13724 Comm: syz-executor.4 Not tainted 6.8.0-12822-gcd51db110a7e #12
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240522154002.77857-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Thu May 9 01:14:46 2024 -0700

    af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
    
    [ Upstream commit 540bf24fba16b88c1b3b9353927204b4f1074e25 ]
    
    A data-race condition has been identified in af_unix. In one data path,
    the write function unix_release_sock() atomically writes to
    sk->sk_shutdown using WRITE_ONCE. However, on the reader side,
    unix_stream_sendmsg() does not read it atomically. Consequently, this
    issue is causing the following KCSAN splat to occur:
    
            BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
    
            write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
            unix_release_sock (net/unix/af_unix.c:640)
            unix_release (net/unix/af_unix.c:1050)
            sock_close (net/socket.c:659 net/socket.c:1421)
            __fput (fs/file_table.c:422)
            __fput_sync (fs/file_table.c:508)
            __se_sys_close (fs/open.c:1559 fs/open.c:1541)
            __x64_sys_close (fs/open.c:1541)
            x64_sys_call (arch/x86/entry/syscall_64.c:33)
            do_syscall_64 (arch/x86/entry/common.c:?)
            entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
            read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
            unix_stream_sendmsg (net/unix/af_unix.c:2273)
            __sock_sendmsg (net/socket.c:730 net/socket.c:745)
            ____sys_sendmsg (net/socket.c:2584)
            __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
            __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
            x64_sys_call (arch/x86/entry/syscall_64.c:33)
            do_syscall_64 (arch/x86/entry/common.c:?)
            entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
            value changed: 0x01 -> 0x03
    
    The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").
    
    Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")
    addressed a comparable issue in the past regarding sk->sk_shutdown.
    However, it overlooked resolving this particular data path.
    This patch only offending unix_stream_sendmsg() function, since the
    other reads seem to be protected by unix_state_lock() as discussed in
    Link: https://lore.kernel.org/all/20240508173324.53565-1-kuniyu@amazon.com/
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240509081459.2807828-1-leitao@debian.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Read sk->sk_hash under bindlock during bind(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu May 23 00:42:18 2024 +0900

    af_unix: Read sk->sk_hash under bindlock during bind().
    
    [ Upstream commit 51d1b25a720982324871338b1a36b197ec9bd6f0 ]
    
    syzkaller reported data-race of sk->sk_hash in unix_autobind() [0],
    and the same ones exist in unix_bind_bsd() and unix_bind_abstract().
    
    The three bind() functions prefetch sk->sk_hash locklessly and
    use it later after validating that unix_sk(sk)->addr is NULL under
    unix_sk(sk)->bindlock.
    
    The prefetched sk->sk_hash is the hash value of unbound socket set
    in unix_create1() and does not change until bind() completes.
    
    There could be a chance that sk->sk_hash changes after the lockless
    read.  However, in such a case, non-NULL unix_sk(sk)->addr is visible
    under unix_sk(sk)->bindlock, and bind() returns -EINVAL without using
    the prefetched value.
    
    The KCSAN splat is false-positive, but let's silence it by reading
    sk->sk_hash under unix_sk(sk)->bindlock.
    
    [0]:
    BUG: KCSAN: data-race in unix_autobind / unix_autobind
    
    write to 0xffff888034a9fb88 of 4 bytes by task 4468 on cpu 0:
     __unix_set_addr_hash net/unix/af_unix.c:331 [inline]
     unix_autobind+0x47a/0x7d0 net/unix/af_unix.c:1185
     unix_dgram_connect+0x7e3/0x890 net/unix/af_unix.c:1373
     __sys_connect_file+0xd7/0xe0 net/socket.c:2048
     __sys_connect+0x114/0x140 net/socket.c:2065
     __do_sys_connect net/socket.c:2075 [inline]
     __se_sys_connect net/socket.c:2072 [inline]
     __x64_sys_connect+0x40/0x50 net/socket.c:2072
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x46/0x4e
    
    read to 0xffff888034a9fb88 of 4 bytes by task 4465 on cpu 1:
     unix_autobind+0x28/0x7d0 net/unix/af_unix.c:1134
     unix_dgram_connect+0x7e3/0x890 net/unix/af_unix.c:1373
     __sys_connect_file+0xd7/0xe0 net/socket.c:2048
     __sys_connect+0x114/0x140 net/socket.c:2065
     __do_sys_connect net/socket.c:2075 [inline]
     __se_sys_connect net/socket.c:2072 [inline]
     __x64_sys_connect+0x40/0x50 net/socket.c:2072
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x46/0x4e
    
    value changed: 0x000000e4 -> 0x000001e3
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 4465 Comm: syz-executor.0 Not tainted 6.8.0-12822-gcd51db110a7e #12
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    
    Fixes: afd20b9290e1 ("af_unix: Replace the big lock with small locks.")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240522154218.78088-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Update unix_sk(sk)->oob_skb under sk_receive_queue lock. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu May 16 22:48:35 2024 +0900

    af_unix: Update unix_sk(sk)->oob_skb under sk_receive_queue lock.
    
    [ Upstream commit 9841991a446c87f90f66f4b9fee6fe934c1336a2 ]
    
    Billy Jheng Bing-Jhong reported a race between __unix_gc() and
    queue_oob().
    
    __unix_gc() tries to garbage-collect close()d inflight sockets,
    and then if the socket has MSG_OOB in unix_sk(sk)->oob_skb, GC
    will drop the reference and set NULL to it locklessly.
    
    However, the peer socket still can send MSG_OOB message and
    queue_oob() can update unix_sk(sk)->oob_skb concurrently, leading
    NULL pointer dereference. [0]
    
    To fix the issue, let's update unix_sk(sk)->oob_skb under the
    sk_receive_queue's lock and take it everywhere we touch oob_skb.
    
    Note that we defer kfree_skb() in manage_oob() to silence lockdep
    false-positive (See [1]).
    
    [0]:
    BUG: kernel NULL pointer dereference, address: 0000000000000008
     PF: supervisor write access in kernel mode
     PF: error_code(0x0002) - not-present page
    PGD 8000000009f5e067 P4D 8000000009f5e067 PUD 9f5d067 PMD 0
    Oops: 0002 [#1] PREEMPT SMP PTI
    CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc5-00191-gd091e579b864 #110
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    Workqueue: events delayed_fput
    RIP: 0010:skb_dequeue (./include/linux/skbuff.h:2386 ./include/linux/skbuff.h:2402 net/core/skbuff.c:3847)
    Code: 39 e3 74 3e 8b 43 10 48 89 ef 83 e8 01 89 43 10 49 8b 44 24 08 49 c7 44 24 08 00 00 00 00 49 8b 14 24 49 c7 04 24 00 00 00 00 <48> 89 42 08 48 89 10 e8 e7 c5 42 00 4c 89 e0 5b 5d 41 5c c3 cc cc
    RSP: 0018:ffffc900001bfd48 EFLAGS: 00000002
    RAX: 0000000000000000 RBX: ffff8880088f5ae8 RCX: 00000000361289f9
    RDX: 0000000000000000 RSI: 0000000000000206 RDI: ffff8880088f5b00
    RBP: ffff8880088f5b00 R08: 0000000000080000 R09: 0000000000000001
    R10: 0000000000000003 R11: 0000000000000001 R12: ffff8880056b6a00
    R13: ffff8880088f5280 R14: 0000000000000001 R15: ffff8880088f5a80
    FS:  0000000000000000(0000) GS:ffff88807dd80000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000008 CR3: 0000000006314000 CR4: 00000000007506f0
    PKRU: 55555554
    Call Trace:
     <TASK>
     unix_release_sock (net/unix/af_unix.c:654)
     unix_release (net/unix/af_unix.c:1050)
     __sock_release (net/socket.c:660)
     sock_close (net/socket.c:1423)
     __fput (fs/file_table.c:423)
     delayed_fput (fs/file_table.c:444 (discriminator 3))
     process_one_work (kernel/workqueue.c:3259)
     worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416)
     kthread (kernel/kthread.c:388)
     ret_from_fork (arch/x86/kernel/process.c:153)
     ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
     </TASK>
    Modules linked in:
    CR2: 0000000000000008
    
    Link: https://lore.kernel.org/netdev/a00d3993-c461-43f2-be6d-07259c98509a@rbox.co/ [1]
    Fixes: 1279f9d9dec2 ("af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.")
    Reported-by: Billy Jheng Bing-Jhong <billy@starlabs.sg>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240516134835.8332-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: core: Fix NULL module pointer assignment at card init [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed May 22 09:04:39 2024 +0200

    ALSA: core: Fix NULL module pointer assignment at card init
    
    commit 39381fe7394e5eafac76e7e9367e7351138a29c1 upstream.
    
    The commit 81033c6b584b ("ALSA: core: Warn on empty module")
    introduced a WARN_ON() for a NULL module pointer passed at snd_card
    object creation, and it also wraps the code around it with '#ifdef
    MODULE'.  This works in most cases, but the devils are always in
    details.  "MODULE" is defined when the target code (i.e. the sound
    core) is built as a module; but this doesn't mean that the caller is
    also built-in or not.  Namely, when only the sound core is built-in
    (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),
    the passed module pointer is ignored even if it's non-NULL, and
    card->module remains as NULL.  This would result in the missing module
    reference up/down at the device open/close, leading to a race with the
    code execution after the module removal.
    
    For addressing the bug, move the assignment of card->module again out
    of ifdef.  The WARN_ON() is still wrapped with ifdef because the
    module can be really NULL when all sound drivers are built-in.
    
    Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would
    lead to a false-positive NULL module check.  Admittedly it won't catch
    perfectly, i.e. no check is performed when CONFIG_SND=y.  But, it's no
    real problem as it's only for debugging, and the condition is pretty
    rare.
    
    Fixes: 81033c6b584b ("ALSA: core: Warn on empty module")
    Reported-by: Xu Yang <xu.yang_2@nxp.com>
    Closes: https://lore.kernel.org/r/20240520170349.2417900-1-xu.yang_2@nxp.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Tested-by: Xu Yang <xu.yang_2@nxp.com>
    Link: https://lore.kernel.org/r/20240522070442.17786-1-tiwai@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: core: Remove debugfs at disconnection [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri May 24 17:11:46 2024 +0200

    ALSA: core: Remove debugfs at disconnection
    
    [ Upstream commit 495000a38634e640e2fd02f7e4f1512ccc92d770 ]
    
    The card-specific debugfs entries are removed at the last stage of
    card free phase, and it's performed after synchronization of the
    closes of all opened fds.  This works fine for most cases, but it can
    be potentially problematic for a hotplug device like USB-audio.  Due
    to the nature of snd_card_free_when_closed(), the card free isn't
    called immediately after the driver removal for a hotplug device, but
    it's left until the last fd is closed.  It implies that the card
    debugfs entries also remain.  Meanwhile, when a new device is inserted
    before the last close and the very same card slot is assigned, the
    driver tries to create the card debugfs root again on the very same
    path.  This conflicts with the remaining entry, and results in the
    kernel warning such as:
      debugfs: Directory 'card0' with parent 'sound' already present!
    with the missing debugfs entry afterwards.
    
    For avoiding such conflicts, remove debugfs entries at the device
    disconnection phase instead.  The jack kctl debugfs entries get
    removed in snd_jack_dev_disconnect() instead of each kctl
    private_free.
    
    Fixes: 2d670ea2bd53 ("ALSA: jack: implement software jack injection via debugfs")
    Link: https://lore.kernel.org/r/20240524151256.32521-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: emu10k1: make E-MU FPGA writes potentially more reliable [+ + +]
Author: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date:   Sun Apr 28 11:37:16 2024 +0200

    ALSA: emu10k1: make E-MU FPGA writes potentially more reliable
    
    [ Upstream commit 15c7e87aa88f0ab2d51c2e2123b127a6d693ca21 ]
    
    We did not delay after the second strobe signal, so another immediately
    following access could potentially corrupt the written value.
    
    This is a purely speculative fix with no supporting evidence, but after
    taking out the spinlocks around the writes, it seems plausible that a
    modern processor could be actually too fast. Also, it's just cleaner to
    be consistent.
    
    Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Message-ID: <20240428093716.3198666-7-oswald.buddenhagen@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: Fix deadlocks with kctl removals at disconnection [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri May 10 12:14:23 2024 +0200

    ALSA: Fix deadlocks with kctl removals at disconnection
    
    commit 87988a534d8e12f2e6fc01fe63e6c1925dc5307c upstream.
    
    In snd_card_disconnect(), we set card->shutdown flag at the beginning,
    call callbacks and do sync for card->power_ref_sleep waiters at the
    end.  The callback may delete a kctl element, and this can lead to a
    deadlock when the device was in the suspended state.  Namely:
    
    * A process waits for the power up at snd_power_ref_and_wait() in
      snd_ctl_info() or read/write() inside card->controls_rwsem.
    
    * The system gets disconnected meanwhile, and the driver tries to
      delete a kctl via snd_ctl_remove*(); it tries to take
      card->controls_rwsem again, but this is already locked by the
      above.  Since the sleeper isn't woken up, this deadlocks.
    
    An easy fix is to wake up sleepers before processing the driver
    disconnect callbacks but right after setting the card->shutdown flag.
    Then all sleepers will abort immediately, and the code flows again.
    
    So, basically this patch moves the wait_event() call at the right
    timing.  While we're at it, just to be sure, call wait_event_all()
    instead of wait_event(), although we don't use exclusive events on
    this queue for now.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218816
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Link: https://lore.kernel.org/r/20240510101424.6279-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Wed May 8 10:56:27 2024 +0100

    ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup
    
    [ Upstream commit 172811e3a557d8681a5e2d0f871dc04a2d17eb13 ]
    
    Use the control private_free callback to free the associated data
    block. This ensures that the memory won't leak, whatever way the
    control gets destroyed.
    
    The original implementation didn't actually remove the ALSA
    controls in hda_cs_dsp_control_remove(). It only freed the internal
    tracking structure. This meant it was possible to remove/unload the
    amp driver while leaving its ALSA controls still present in the
    soundcard. Obviously attempting to access them could cause segfaults
    or at least dereferencing stale pointers.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: 3233b978af23 ("ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls")
    Link: https://lore.kernel.org/r/20240508095627.44476-1-rf@opensource.cirrus.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/realtek: Adjust G814JZR to use SPI init for amp [+ + +]
Author: Luke D. Jones <luke@ljones.dev>
Date:   Sun May 26 21:10:32 2024 +1200

    ALSA: hda/realtek: Adjust G814JZR to use SPI init for amp
    
    [ Upstream commit 2be46155d792d629e8fe3188c2cde176833afe36 ]
    
    The 2024 ASUS ROG G814J model is much the same as the 2023 model
    and the 2023 16" version. We can use the same Cirrus Amp quirk.
    
    Fixes: 811dd426a9b1 ("ALSA: hda/realtek: Add quirks for Asus ROG 2024 laptops using CS35L41")
    Signed-off-by: Luke D. Jones <luke@ljones.dev>
    Link: https://lore.kernel.org/r/20240526091032.114545-1-luke@ljones.dev
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/realtek: fix mute/micmute LEDs don't work for ProBook 440/460 G11. [+ + +]
Author: Andy Chi <andy.chi@canonical.com>
Date:   Thu May 23 14:18:31 2024 +0800

    ALSA: hda/realtek: fix mute/micmute LEDs don't work for ProBook 440/460 G11.
    
    commit b3b6f125da2773cbc681316842afba63ca9869aa upstream.
    
    HP ProBook 440/460 G11 needs ALC236_FIXUP_HP_GPIO_LED quirk to
    make mic-mute/audio-mute working.
    
    Signed-off-by: Andy Chi <andy.chi@canonical.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240523061832.607500-1-andy.chi@canonical.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda: cs35l56: Exit cache-only after cs35l56_wait_for_firmware_boot() [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Mon Apr 8 11:18:01 2024 +0100

    ALSA: hda: cs35l56: Exit cache-only after cs35l56_wait_for_firmware_boot()
    
    [ Upstream commit 73580ec607dfe125b140ed30c7c0a074db78c558 ]
    
    Adds calls to disable regmap cache-only after a successful return from
    cs35l56_wait_for_firmware_boot().
    
    This is to prepare for a change in the shared ASoC module that will
    leave regmap in cache-only mode after cs35l56_system_reset(). This is
    to prevent register accesses going to the hardware while it is
    rebooting.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://msgid.link/r/20240408101803.43183-3-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: cs35l56: Fix lifetime of cs_dsp instance [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Wed May 8 11:08:11 2024 +0100

    ALSA: hda: cs35l56: Fix lifetime of cs_dsp instance
    
    [ Upstream commit d344873c4cbde249b7152d36a273bcc45864001e ]
    
    The cs_dsp instance is initialized in the driver probe() so it
    should be freed in the driver remove(). Also fix a missing call
    to cs_dsp_remove() in the error path of cs35l56_hda_common_probe().
    
    The call to cs_dsp_remove() was being done in the component unbind
    callback cs35l56_hda_unbind(). This meant that if the driver was
    unbound and then re-bound it would be using an uninitialized cs_dsp
    instance.
    
    It is best to initialize the cs_dsp instance in probe() so that it
    can return an error if it fails. The component binding API doesn't
    have any error handling so there's no way to handle a failure if
    cs_dsp was initialized in the bind.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: 73cfbfa9caea ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier")
    Link: https://lore.kernel.org/r/20240508100811.49514-1-rf@opensource.cirrus.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: cs35l56: Initialize all ASP1 registers [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Mon Jan 29 16:27:28 2024 +0000

    ALSA: hda: cs35l56: Initialize all ASP1 registers
    
    [ Upstream commit 856ce8982169acb31a25c5f2ecd2570ab8a6af46 ]
    
    Add ASP1_FRAME_CONTROL1, ASP1_FRAME_CONTROL5 and the ASP1_TX?_INPUT
    registers to the sequence used to initialize the ASP configuration.
    Write this sequence to the cache and directly to the registers to
    ensure that they match.
    
    A system-specific firmware can patch these registers to values that are
    not the silicon default, so that the CS35L56 boots already in the
    configuration used by Windows or by "driverless" Windows setups such
    as factory tuning.
    
    These may not match how Linux is configuring the HDA codec. And anyway
    on Linux the ALSA controls are used to configure routing options.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: 73cfbfa9caea ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier")
    Link: https://msgid.link/r/20240129162737.497-10-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: d344873c4cbd ("ALSA: hda: cs35l56: Fix lifetime of cs_dsp instance")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda: intel-dsp-config: harden I2C/I2S codec detection [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Fri Apr 26 10:28:18 2024 -0500

    ALSA: hda: intel-dsp-config: harden I2C/I2S codec detection
    
    [ Upstream commit 79ac4c1443eaec0d09355307043a9149287f23c1 ]
    
    The SOF driver is selected whenever specific I2C/I2S HIDs are reported
    as 'present' in the ACPI DSDT. In some cases, an HID is reported but
    the hardware does not actually rely on I2C/I2S.  This false positive
    leads to an invalid selection of the SOF driver and as a result an
    invalid topology is loaded.
    
    This patch hardens the detection with a check that the NHLT table is
    consistent with the report of an I2S-based codec in DSDT. This table
    should expose at least one SSP endpoint configured for an I2S-codec
    connection.
    
    Tested on Huawei Matebook D14 (NBLB-WAX9N) using an HDaudio codec with
    an invalid ES8336 ACPI HID reported:
    
    [    7.858249] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
    [    7.858312] snd_hda_intel 0000:00:1f.3: snd_intel_dsp_find_config: no valid SSP found for HID ESSX8336, skipped
    
    Reported-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Tested-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Closes: https://github.com/thesofproject/linux/issues/4934
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Message-ID: <20240426152818.38443-1-pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: jack: Use guard() for locking [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Feb 27 09:52:52 2024 +0100

    ALSA: jack: Use guard() for locking
    
    [ Upstream commit 7234795b59f7b0b14569ec46dce56300a4988067 ]
    
    We can simplify the code gracefully with new guard() macro and co for
    automatic cleanup of locks.
    
    Only the code refactoring, and no functional changes.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://lore.kernel.org/r/20240227085306.9764-11-tiwai@suse.de
    Stable-dep-of: 495000a38634 ("ALSA: core: Remove debugfs at disconnection")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: seq: Don't clear bank selection at event -> UMP MIDI2 conversion [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon May 27 17:18:50 2024 +0200

    ALSA: seq: Don't clear bank selection at event -> UMP MIDI2 conversion
    
    [ Upstream commit a200df7deb3186cd7b55abb77ab96dfefb8a4f09 ]
    
    The current code to convert from a legacy sequencer event to UMP MIDI2
    clears the bank selection at each time the program change is
    submitted.  This is confusing and may lead to incorrect bank values
    tranmitted to the destination in the end.
    
    Drop the line to clear the bank info and keep the provided values.
    
    Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events")
    Link: https://lore.kernel.org/r/20240527151852.29036-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: seq: Fix missing bank setup between MIDI1/MIDI2 UMP conversion [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon May 27 17:18:49 2024 +0200

    ALSA: seq: Fix missing bank setup between MIDI1/MIDI2 UMP conversion
    
    [ Upstream commit 8a42886cae307663f3f999846926bd6e64392000 ]
    
    When a UMP packet is converted between MIDI1 and MIDI2 protocols, the
    bank selection may be lost.  The conversion from MIDI1 to MIDI2 needs
    the encoding of the bank into UMP_MSG_STATUS_PROGRAM bits, while the
    conversion from MIDI2 to MIDI1 needs the extraction from that
    instead.
    
    This patch implements the missing bank selection mechanism in those
    conversions.
    
    Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events")
    Link: https://lore.kernel.org/r/20240527151852.29036-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: seq: Fix yet another spot for system message conversion [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu May 30 12:10:43 2024 +0200

    ALSA: seq: Fix yet another spot for system message conversion
    
    [ Upstream commit 700fe6fd093d08c6da2bda8efe00479b0e617327 ]
    
    We fixed the incorrect UMP type for system messages in the recent
    commit, but it missed one place in system_ev_to_ump_midi1().
    Fix it now.
    
    Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events")
    Fixes: c2bb79613fed ("ALSA: seq: Fix incorrect UMP type for system messages")
    Link: https://lore.kernel.org/r/20240530101044.17524-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: seq: ump: Fix swapped song position pointer data [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri May 31 09:51:07 2024 +0200

    ALSA: seq: ump: Fix swapped song position pointer data
    
    [ Upstream commit 310fa3ec2859f1c094e6e9b5d2e1ca51738c409a ]
    
    At converting between the legacy event and UMP, the parameters for
    MIDI Song Position Pointer are incorrectly stored.  It should have
    been LSB -> MSB order while it stored in MSB -> LSB order.
    This patch corrects the ordering.
    
    Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events")
    Link: https://lore.kernel.org/r/20240531075110.3250-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: timer: Set lower bound of start tick time [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue May 14 20:27:36 2024 +0200

    ALSA: timer: Set lower bound of start tick time
    
    commit 4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e upstream.
    
    Currently ALSA timer doesn't have the lower limit of the start tick
    time, and it allows a very small size, e.g. 1 tick with 1ns resolution
    for hrtimer.  Such a situation may lead to an unexpected RCU stall,
    where  the callback repeatedly queuing the expire update, as reported
    by fuzzer.
    
    This patch introduces a sanity check of the timer start tick time, so
    that the system returns an error when a too small start size is set.
    As of this patch, the lower limit is hard-coded to 100us, which is
    small enough but can still work somehow.
    
    Reported-by: syzbot+43120c2af6ca2938cc38@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/r/000000000000fa00a1061740ab6d@google.com
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240514182745.4015-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    [ backport note: the error handling is changed, as the original commit
      is based on the recent cleanup with guard() in commit beb45974dd49
      -- tiwai ]
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY [+ + +]
Author: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
Date:   Mon May 20 21:34:37 2024 +0800

    arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
    
    [ Upstream commit ffbf4fb9b5c12ff878a10ea17997147ea4ebea6f ]
    
    When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes
    to bug_table entries, and as a result the last entry in a bug table will
    be ignored, potentially leading to an unexpected panic(). All prior
    entries in the table will be handled correctly.
    
    The arm64 ABI requires that struct fields of up to 8 bytes are
    naturally-aligned, with padding added within a struct such that struct
    are suitably aligned within arrays.
    
    When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:
    
            struct bug_entry {
                    signed int      bug_addr_disp;  // 4 bytes
                    signed int      file_disp;      // 4 bytes
                    unsigned short  line;           // 2 bytes
                    unsigned short  flags;          // 2 bytes
            }
    
    ... with 12 bytes total, requiring 4-byte alignment.
    
    When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:
    
            struct bug_entry {
                    signed int      bug_addr_disp;  // 4 bytes
                    unsigned short  flags;          // 2 bytes
                    < implicit padding >            // 2 bytes
            }
    
    ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing
    padding, requiring 4-byte alginment.
    
    When we create a bug_entry in assembly, we align the start of the entry
    to 4 bytes, which implicitly handles padding for any prior entries.
    However, we do not align the end of the entry, and so when
    CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding
    bytes.
    
    For the main kernel image this is not a problem as find_bug() doesn't
    depend on the trailing padding bytes when searching for entries:
    
            for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
                    if (bugaddr == bug_addr(bug))
                            return bug;
    
    However for modules, module_bug_finalize() depends on the trailing
    bytes when calculating the number of entries:
    
            mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
    
    ... and as the last bug_entry lacks the necessary padding bytes, this entry
    will not be counted, e.g. in the case of a single entry:
    
            sechdrs[i].sh_size == 6
            sizeof(struct bug_entry) == 8;
    
            sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;
    
    Consequently module_find_bug() will miss the last bug_entry when it does:
    
            for (i = 0; i < mod->num_bugs; ++i, ++bug)
                    if (bugaddr == bug_addr(bug))
                            goto out;
    
    ... which can lead to a kenrel panic due to an unhandled bug.
    
    This can be demonstrated with the following module:
    
            static int __init buginit(void)
            {
                    WARN(1, "hello\n");
                    return 0;
            }
    
            static void __exit bugexit(void)
            {
            }
    
            module_init(buginit);
            module_exit(bugexit);
            MODULE_LICENSE("GPL");
    
    ... which will trigger a kernel panic when loaded:
    
            ------------[ cut here ]------------
            hello
            Unexpected kernel BRK exception at EL1
            Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
            Modules linked in: hello(O+)
            CPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8
            Hardware name: linux,dummy-virt (DT)
            pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
            pc : buginit+0x18/0x1000 [hello]
            lr : buginit+0x18/0x1000 [hello]
            sp : ffff800080533ae0
            x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
            x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
            x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
            x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
            x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
            x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
            x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
            x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
            x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
            x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
            Call trace:
             buginit+0x18/0x1000 [hello]
             do_one_initcall+0x80/0x1c8
             do_init_module+0x60/0x218
             load_module+0x1ba4/0x1d70
             __do_sys_init_module+0x198/0x1d0
             __arm64_sys_init_module+0x1c/0x28
             invoke_syscall+0x48/0x114
             el0_svc_common.constprop.0+0x40/0xe0
             do_el0_svc+0x1c/0x28
             el0_svc+0x34/0xd8
             el0t_64_sync_handler+0x120/0x12c
             el0t_64_sync+0x190/0x194
            Code: d0ffffe0 910003fd 91000000 9400000b (d4210000)
            ---[ end trace 0000000000000000 ]---
            Kernel panic - not syncing: BRK handler: Fatal exception
    
    Fix this by always aligning the end of a bug_entry to 4 bytes, which is
    correct regardless of CONFIG_DEBUG_BUGVERBOSE.
    
    Fixes: 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic BUG traps")
    
    Signed-off-by: Yuanbin Xie <xieyuanbin1@huawei.com>
    Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Link: https://lore.kernel.org/r/1716212077-43826-1-git-send-email-xiaojiangfeng@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: meson: fix S4 power-controller node [+ + +]
Author: Xianwei Zhao <xianwei.zhao@amlogic.com>
Date:   Fri Apr 12 16:42:30 2024 +0800

    arm64: dts: meson: fix S4 power-controller node
    
    [ Upstream commit 72907de9051dc2aa7b55c2a020e2872184ac17cd ]
    
    The power-controller module works well by adding its parent
    node secure-monitor.
    
    Fixes: 085f7a298a14 ("arm64: dts: add support for S4 power domain controller")
    Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20240412-fix-secpwr-s4-v2-1-3802fd936d77@amlogic.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: configs: sunxi: Enable DRM_DW_HDMI [+ + +]
Author: Maxime Ripard <mripard@kernel.org>
Date:   Wed Apr 3 12:56:23 2024 +0200

    ARM: configs: sunxi: Enable DRM_DW_HDMI
    
    [ Upstream commit deff401b14e2d832b25b55862ad6c73378fe034e ]
    
    Commit 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper
    module") turned the DRM_DW_HDMI dependency of DRM_SUN8I_DW_HDMI into a
    depends on which ended up disabling the driver in the defconfig. Make
    sure it's still enabled.
    
    Fixes: 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper module")
    Reported-by: Mark Brown <broonie@kernel.org>
    Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Link: https://lore.kernel.org/r/20240403-fix-dw-hdmi-kconfig-v1-5-afbc4a835c38@kernel.org
    Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: acp: Support microphone from device Acer 315-24p [+ + +]
Author: end.to.start <end.to.start@mail.ru>
Date:   Mon Apr 8 18:24:54 2024 +0300

    ASoC: acp: Support microphone from device Acer 315-24p
    
    [ Upstream commit 4b9a474c7c820391c0913d64431ae9e1f52a5143 ]
    
    This patch adds microphone detection for the Acer 315-24p, after which a microphone appears on the device and starts working
    
    Signed-off-by: end.to.start <end.to.start@mail.ru>
    Link: https://msgid.link/r/20240408152454.45532-1-end.to.start@mail.ru
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs35l41: Update DSP1RX5/6 Sources for DSP config [+ + +]
Author: Stefan Binding <sbinding@opensource.cirrus.com>
Date:   Thu Apr 11 15:26:48 2024 +0100

    ASoC: cs35l41: Update DSP1RX5/6 Sources for DSP config
    
    [ Upstream commit eefb831d2e4dd58d58002a2ef75ff989e073230d ]
    
    Currently, all ASoC systems are set to use VPMON for DSP1RX5_SRC,
    however, this is required only for internal boost systems.
    External boost systems require VBSTMON instead of VPMON to be the
    input to DSP1RX5_SRC.
    Shared Boost Active acts like Internal boost (requires VPMON).
    Shared Boost Passive acts like External boost (requires VBSTMON)
    All systems require DSP1RX6_SRC to be set to VBSTMON.
    
    Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
    Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://msgid.link/r/20240411142648.650921-1-sbinding@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs35l56: Fix to ensure ASP1 registers match cache [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Mon Jan 29 16:27:26 2024 +0000

    ASoC: cs35l56: Fix to ensure ASP1 registers match cache
    
    [ Upstream commit 72a77d7631c6e392677c0134343cf5edcd3a4572 ]
    
    Add a dummy SUPPLY widget connected to the ASP that forces the
    chip registers to match the regmap cache when the ASP is
    powered-up.
    
    On a SoundWire system the ASP is free for use as a chip-to-chip
    interconnect. This can be either for the firmware on multiple
    CS35L56 to share reference audio; or as a bridge to another
    device. If it is a firmware interconnect it is owned by the
    firmware and the Linux driver should avoid writing the registers.
    However. If it is a bridge then Linux may take over and handle
    it as a normal codec-to-codec link.
    
    CS35L56 is designed for SDCA and a generic SDCA driver would
    know nothing about these chip-specific registers. So if the
    ASP is being used on a SoundWire system the firmware sets up the
    ASP registers. This means that we can't assume the default
    state of the ASP registers. But we don't know the initial state
    that the firmware set them to until after the firmware has been
    downloaded and booted, which can take several seconds when
    downloading multiple amps.
    
    To avoid blocking probe() for several seconds waiting for the
    firmware, the silicon defaults are assumed. This allows the machine
    driver to setup the ASP configuration during probe() without being
    blocked. If the ASP is hooked up and used, the SUPPLY widget
    ensures that the chip registers match what was configured in the
    regmap cache.
    
    If the machine driver does not hook up the ASP, it is assumed that
    it won't call any functions to configure the ASP DAI. Therefore
    the regmap cache will be clean for these registers so a
    regcache_sync() will not overwrite the chip registers. If the
    DAI is not hooked up, the dummy SUPPLY widget will not be
    invoked so it will never force-overwrite the chip registers.
    
    Backport note:
    This won't apply cleanly to kernels older than v6.6.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56")
    Link: https://msgid.link/r/20240129162737.497-8-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: d344873c4cbd ("ALSA: hda: cs35l56: Fix lifetime of cs_dsp instance")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: cs42l43: Only restrict 44.1kHz for the ASP [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Mon May 27 11:08:40 2024 +0100

    ASoC: cs42l43: Only restrict 44.1kHz for the ASP
    
    [ Upstream commit 797c525e85d1e44cf0e6f338890e8e0c661f524a ]
    
    The SoundWire interface can always support 44.1kHz using flow controlled
    mode, and whether the ASP is in master mode should obviously only affect
    the ASP. Update cs42l43_startup() to only restrict the rates for the ASP
    DAI.
    
    Fixes: fc918cbe874e ("ASoC: cs42l43: Add support for the cs42l43")
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://msgid.link/r/20240527100840.439832-1-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: da7219-aad: fix usage of device_get_named_child_node() [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Fri Apr 26 10:30:33 2024 -0500

    ASoC: da7219-aad: fix usage of device_get_named_child_node()
    
    [ Upstream commit e8a6a5ad73acbafd98e8fd3f0cbf6e379771bb76 ]
    
    The documentation for device_get_named_child_node() mentions this
    important point:
    
    "
    The caller is responsible for calling fwnode_handle_put() on the
    returned fwnode pointer.
    "
    
    Add fwnode_handle_put() to avoid a leaked reference.
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20240426153033.38500-1-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: dt-bindings: rt5645: add cbj sleeve gpio property [+ + +]
Author: Derek Fang <derek.fang@realtek.com>
Date:   Mon Apr 8 17:10:57 2024 +0800

    ASoC: dt-bindings: rt5645: add cbj sleeve gpio property
    
    [ Upstream commit 306b38e3fa727d22454a148a364123709e356600 ]
    
    Add an optional gpio property to control external CBJ circuits
    to avoid some electric noise caused by sleeve/ring2 contacts floating.
    
    Signed-off-by: Derek Fang <derek.fang@realtek.com>
    
    Link: https://msgid.link/r/20240408091057.14165-2-derek.fang@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: avs: Fix ASRC module initialization [+ + +]
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Fri Apr 5 11:09:21 2024 +0200

    ASoC: Intel: avs: Fix ASRC module initialization
    
    [ Upstream commit 9d2e26f31c7cc3fa495c423af9b4902ec0dc7be3 ]
    
    The ASRC module configuration consists of several reserved fields. Zero
    them out when initializing the module to avoid sending invalid data.
    
    Fixes: 274d79e51875 ("ASoC: Intel: avs: Configure modules according to their type")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://msgid.link/r/20240405090929.1184068-6-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: avs: Fix potential integer overflow [+ + +]
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Fri Apr 5 11:09:23 2024 +0200

    ASoC: Intel: avs: Fix potential integer overflow
    
    [ Upstream commit c7e832cabe635df47c2bf6df7801e97bf3045b1e ]
    
    While stream_tag for CLDMA on SKL-based platforms is always 1, function
    hda_cldma_setup() uses AZX_SD_CTL_STRM() macro which does:
            stream_tag << 20
    
    what combined with stream_tag type of 'unsigned int' generates a
    potential overflow issue. Update the field type to fix that.
    
    Fixes: 45864e49a05a ("ASoC: Intel: avs: Implement CLDMA transfer")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://msgid.link/r/20240405090929.1184068-8-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: avs: ssm4567: Do not ignore route checks [+ + +]
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Fri Mar 8 10:05:00 2024 +0100

    ASoC: Intel: avs: ssm4567: Do not ignore route checks
    
    [ Upstream commit e6719d48ba6329536c459dcee5a571e535687094 ]
    
    A copy-paste from intel/boards/skl_nau88l25_ssm4567.c made the avs's
    equivalent disable route checks as well. Such behavior is not desired.
    
    Fixes: 69ea14efe99b ("ASoC: Intel: avs: Add ssm4567 machine board")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://msgid.link/r/20240308090502.2136760-4-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: avs: Test result of avs_get_module_entry() [+ + +]
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Fri Apr 5 11:09:24 2024 +0200

    ASoC: Intel: avs: Test result of avs_get_module_entry()
    
    [ Upstream commit 41bf4525fadb3d8df3860420d6ac9025c51a3bac ]
    
    While PROBE_MOD_UUID is always part of the base AudioDSP firmware
    manifest, from maintenance point of view it is better to check the
    result.
    
    Fixes: dab8d000e25c ("ASoC: Intel: avs: Add data probing requests")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://msgid.link/r/20240405090929.1184068-9-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: bytcr_rt5640: Apply Asus T100TA quirk to Asus T100TAM too [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sun Apr 7 21:15:59 2024 +0200

    ASoC: Intel: bytcr_rt5640: Apply Asus T100TA quirk to Asus T100TAM too
    
    [ Upstream commit e50729d742ec364895f1c389c32315984a987aa5 ]
    
    The Asus T100TA quirk has been using an exact match on a product-name of
    "T100TA" but there are also T100TAM variants with a slightly higher
    clocked CPU and a metal backside which need the same quirk.
    
    Sort the existing T100TA (stereo speakers) below the more specific
    T100TAF (mono speaker) quirk and switch from exact matching to
    substring matching so that the T100TA quirk will also match on
    the T100TAM models.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://msgid.link/r/20240407191559.21596-1-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: common: add ACPI matching tables for Arrow Lake [+ + +]
Author: Arun T <arun.t@intel.com>
Date:   Fri Sep 15 16:06:35 2023 +0800

    ASoC: Intel: common: add ACPI matching tables for Arrow Lake
    
    [ Upstream commit 24af0d7c0f9f49a243b77e607e3f4a4737386b59 ]
    
    Initial support for ARL w/ RT711
    
    Signed-off-by: Arun T <arun.t@intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Link: https://lore.kernel.org/r/20230915080635.1619942-1-yung-chuan.liao@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 1f1b820dc3c6 ("ASoC: SOF: Intel: mtl: Correct rom_status_reg")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: Disable route checks for Skylake boards [+ + +]
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Fri Mar 8 10:04:58 2024 +0100

    ASoC: Intel: Disable route checks for Skylake boards
    
    [ Upstream commit 0cb3b7fd530b8c107443218ce6db5cb6e7b5dbe1 ]
    
    Topology files that are propagated to the world and utilized by the
    skylake-driver carry shortcomings in their SectionGraphs.
    
    Since commit daa480bde6b3 ("ASoC: soc-core: tidyup for
    snd_soc_dapm_add_routes()") route checks are no longer permissive. Probe
    failures for Intel boards have been partially addressed by commit
    a22ae72b86a4 ("ASoC: soc-core: disable route checks for legacy devices")
    and its follow up but only skl_nau88l25_ssm4567.c is patched. Fix the
    problem for the rest of the boards.
    
    Link: https://lore.kernel.org/all/20200309192744.18380-1-pierre-louis.bossart@linux.intel.com/
    Fixes: daa480bde6b3 ("ASoC: soc-core: tidyup for snd_soc_dapm_add_routes()")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://msgid.link/r/20240308090502.2136760-2-cezary.rojewski@intel.com
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: kirkwood: Fix potential NULL dereference [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Thu Mar 28 20:33:37 2024 +0300

    ASoC: kirkwood: Fix potential NULL dereference
    
    [ Upstream commit ea60ab95723f5738e7737b56dda95e6feefa5b50 ]
    
    In kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if
    CONFIG_PLAT_ORION macro is not defined.
    Fix this bug by adding NULL check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: bb6a40fc5a83 ("ASoC: kirkwood: Fix reference to PCM buffer address")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Link: https://msgid.link/r/20240328173337.21406-1-amishin@t-argos.ru
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mediatek: Assign dummy when codec not specified for a DAI link [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Wed Mar 13 12:01:29 2024 +0100

    ASoC: mediatek: Assign dummy when codec not specified for a DAI link
    
    [ Upstream commit 5f39231888c63f0a7708abc86b51b847476379d8 ]
    
    MediaTek sound card drivers are checking whether a DAI link is present
    and used on a board to assign the correct parameters and this is done
    by checking the codec DAI names at probe time.
    
    If no real codec is present, assign the dummy codec to the DAI link
    to avoid NULL pointer during string comparison.
    
    Fixes: 4302187d955f ("ASoC: mediatek: common: add soundcard driver common code")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://msgid.link/r/20240313110147.1267793-5-angelogioacchino.delregno@collabora.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mediatek: mt8192: fix register configuration for tdm [+ + +]
Author: Hsin-Te Yuan <yuanhsinte@chromium.org>
Date:   Thu May 9 07:31:29 2024 +0000

    ASoC: mediatek: mt8192: fix register configuration for tdm
    
    [ Upstream commit a85ed162f0efcfdd664954414a05d1d560cc95dc ]
    
    For DSP_A, data is a BCK cycle behind LRCK trigger edge. For DSP_B, this
    delay doesn't exist. Fix the delay configuration to match the standard.
    
    Fixes: 52fcd65414abfc ("ASoC: mediatek: mt8192: support tdm in platform driver")
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
    Link: https://lore.kernel.org/r/20240509-8192-tdm-v1-1-530b54645763@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt5645: Fix the electric noise due to the CBJ contacts floating [+ + +]
Author: Derek Fang <derek.fang@realtek.com>
Date:   Mon Apr 8 17:10:56 2024 +0800

    ASoC: rt5645: Fix the electric noise due to the CBJ contacts floating
    
    [ Upstream commit 103abab975087e1f01b76fcb54c91dbb65dbc249 ]
    
    The codec leaves tie combo jack's sleeve/ring2 to floating status
    default. It would cause electric noise while connecting the active
    speaker jack during boot or shutdown.
    This patch requests a gpio to control the additional jack circuit
    to tie the contacts to the ground or floating.
    
    Signed-off-by: Derek Fang <derek.fang@realtek.com>
    
    Link: https://msgid.link/r/20240408091057.14165-1-derek.fang@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt715-sdca: volume step modification [+ + +]
Author: Jack Yu <jack.yu@realtek.com>
Date:   Tue Apr 23 06:59:35 2024 +0000

    ASoC: rt715-sdca: volume step modification
    
    [ Upstream commit bda16500dd0b05e2e047093b36cbe0873c95aeae ]
    
    Volume step (dB/step) modification to fix format error
    which shown in amixer control.
    
    Signed-off-by: Jack Yu <jack.yu@realtek.com>
    Link: https://lore.kernel.org/r/b1f546ad16dc4c7abb7daa7396e8345c@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt715: add vendor clear control register [+ + +]
Author: Jack Yu <jack.yu@realtek.com>
Date:   Mon Apr 15 06:27:23 2024 +0000

    ASoC: rt715: add vendor clear control register
    
    [ Upstream commit cebfbc89ae2552dbb58cd9b8206a5c8e0e6301e9 ]
    
    Add vendor clear control register in readable register's
    callback function. This prevents an access failure reported
    in Intel CI tests.
    
    Signed-off-by: Jack Yu <jack.yu@realtek.com>
    Closes: https://github.com/thesofproject/linux/issues/4860
    Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/6a103ce9134d49d8b3941172c87a7bd4@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt722-sdca: add headset microphone vrefo setting [+ + +]
Author: Jack Yu <jack.yu@realtek.com>
Date:   Tue Apr 9 06:47:34 2024 +0000

    ASoC: rt722-sdca: add headset microphone vrefo setting
    
    [ Upstream commit 140e0762ca055d1aa84b17847cde5d9e47f56f76 ]
    
    Add vrefo settings to fix jd and headset mic recording issue.
    
    Signed-off-by: Jack Yu <jack.yu@realtek.com>
    Link: https://msgid.link/r/727219ed45d3485ba8f4646700aaa8a8@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt722-sdca: modify channel number to support 4 channels [+ + +]
Author: Jack Yu <jack.yu@realtek.com>
Date:   Tue Apr 9 06:47:43 2024 +0000

    ASoC: rt722-sdca: modify channel number to support 4 channels
    
    [ Upstream commit cb9946971d7cb717b726710e1a9fa4ded00b9135 ]
    
    Channel numbers of dmic supports 4 channels, modify channels_max
    regarding to this issue.
    
    Signed-off-by: Jack Yu <jack.yu@realtek.com>
    Link: https://msgid.link/r/6a9b1d1fb2ea4f04b2157799f04053b1@realtek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: lnl: Correct rom_status_reg [+ + +]
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Wed Apr 3 13:52:06 2024 +0300

    ASoC: SOF: Intel: lnl: Correct rom_status_reg
    
    [ Upstream commit b852574c671a9983dd51c81582c8c5085f3dc382 ]
    
    ACE2 architecture changed the place where the ROM updates the status code
    from the shared SRAM window (and HFFLGP1QW0 in ACE1) to HFDSC register for
    the status and HFDEC (HFDSC + 4) for the error code.
    
    The rom_status_reg is not used on LNL because it was wrongly assigned based
    on older platform convention (SRAM window) and it was giving inconsistent
    readings.
    
    Add new header file for lnl specific register definitions.
    
    Fixes: 64a63d9914a5 ("ASoC: SOF: Intel: LNL: Add support for Lunarlake platform")
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
    Link: https://msgid.link/r/20240403105210.17949-4-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: mtl: call dsp dump when boot retry fails [+ + +]
Author: Yong Zhi <yong.zhi@intel.com>
Date:   Mon Nov 27 12:52:35 2023 +0200

    ASoC: SOF: Intel: mtl: call dsp dump when boot retry fails
    
    [ Upstream commit d5070d0c10326e09276c34568b9a19fb9a727b6e ]
    
    Call snd_sof_dsp_dbg_dump() with the same flags/dump_msg
    as used in function hda_loader.c/cl_dsp_init().
    
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Signed-off-by: Yong Zhi <yong.zhi@intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20231127105235.30071-1-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 26187f44aabd ("ASoC: SOF: Intel: mtl: Disable interrupts when firmware boot failed")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: mtl: Correct rom_status_reg [+ + +]
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Wed Apr 3 13:52:05 2024 +0300

    ASoC: SOF: Intel: mtl: Correct rom_status_reg
    
    [ Upstream commit 1f1b820dc3c65b6883da3130ba3b8624dcbf87db ]
    
    ACE1 architecture changed the place where the ROM updates the status code
    from the shared SRAM window to HFFLGP1QW0 register for the status and
    HFFLGP1QW0 + 4 for the error code.
    
    The rom_status_reg is not used on MTL because it was wrongly assigned based
    on older platform convention (SRAM window) and it was giving inconsistent
    readings.
    
    Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)")
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
    Link: https://msgid.link/r/20240403105210.17949-3-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: mtl: Disable interrupts when firmware boot failed [+ + +]
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Wed Apr 3 13:52:07 2024 +0300

    ASoC: SOF: Intel: mtl: Disable interrupts when firmware boot failed
    
    [ Upstream commit 26187f44aabdf3df7609b7c78724a059c230a2ad ]
    
    In case of error during the firmware boot we need to disable the interrupts
    which were enabled as part of the boot sequence.
    
    Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)")
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
    Link: https://msgid.link/r/20240403105210.17949-5-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: mtl: Implement firmware boot state check [+ + +]
Author: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Date:   Wed Apr 3 13:52:08 2024 +0300

    ASoC: SOF: Intel: mtl: Implement firmware boot state check
    
    [ Upstream commit 6b1c1c47e76f0161bda2b1ac2e86a219fe70244f ]
    
    With the corrected rom_status_reg values we can now add a check for target
    boot status for firmware booting.
    With the check now we can identify failed firmware boots (IMR boots) and
    we can use the fallback to purge boot the DSP.
    
    Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)")
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Rander Wang <rander.wang@intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
    Link: https://msgid.link/r/20240403105210.17949-6-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: pci-mtl: fix ARL-S definitions [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Dec 4 15:27:09 2023 -0600

    ASoC: SOF: Intel: pci-mtl: fix ARL-S definitions
    
    [ Upstream commit a00be6dc9bb80796244196033aa5eb258b6af47a ]
    
    The initial copy/paste from MTL was incorrect, the hardware is
    different and requires different descriptors along with a dedicated
    firmware binary.
    
    Fixes: 3851831f529e ("ASoC: SOF: Intel: pci-mtl: use ARL specific firmware definitions")
    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-5-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Stable-dep-of: 1f1b820dc3c6 ("ASoC: SOF: Intel: mtl: Correct rom_status_reg")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Intel: pci-mtl: use ARL specific firmware definitions [+ + +]
Author: Arun T <arun.t@intel.com>
Date:   Thu Oct 12 15:18:47 2023 -0400

    ASoC: SOF: Intel: pci-mtl: use ARL specific firmware definitions
    
    [ Upstream commit 3851831f529ec3d7b2c7708b2579bfc00d43733c ]
    
    Split out firmware definitions for Intel Arrow Lake platforms.
    
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Signed-off-by: Arun T <arun.t@intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20231012191850.147140-2-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 1f1b820dc3c6 ("ASoC: SOF: Intel: mtl: Correct rom_status_reg")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: pcm: Restrict DSP D0i3 during S0ix to IPC3 [+ + +]
Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Date:   Mon Apr 8 14:41:46 2024 -0500

    ASoC: SOF: pcm: Restrict DSP D0i3 during S0ix to IPC3
    
    [ Upstream commit 90a2353080eedec855d63f6aadfda14104ee9b06 ]
    
    Introduce a new field in struct sof_ipc_pcm_ops that can be used to
    restrict DSP D0i3 during S0ix suspend to IPC3. With IPC4, all streams
    must be stopped before S0ix suspend.
    
    Reviewed-by: Uday M Bhat <uday.m.bhat@intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://msgid.link/r/20240408194147.28919-3-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: tas2552: Add TX path for capturing AUDIO-OUT data [+ + +]
Author: Shenghao Ding <shenghao-ding@ti.com>
Date:   Sat May 18 11:35:15 2024 +0800

    ASoC: tas2552: Add TX path for capturing AUDIO-OUT data
    
    [ Upstream commit 7078ac4fd179a68d0bab448004fcd357e7a45f8d ]
    
    TAS2552 is a Smartamp with I/V sense data, add TX path
    to support capturing I/V data.
    
    Fixes: 38803ce7b53b ("ASoC: codecs: tas*: merge .digital_mute() into .mute_stream()")
    Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
    Link: https://msgid.link/r/20240518033515.866-1-shenghao-ding@ti.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: tas2781: Fix a warning reported by robot kernel test [+ + +]
Author: Shenghao Ding <shenghao-ding@ti.com>
Date:   Sun May 5 20:23:45 2024 +0800

    ASoC: tas2781: Fix a warning reported by robot kernel test
    
    [ Upstream commit 1ae14f3520b1a0ad144610a3f592c81a3e81cd1b ]
    
    Fix a warning reported by robot kernel test that 'fw_entry' in function
    'tas2781_load_calibration' is used uninitialized with compiler
    sh4-linux-gcc (GCC) 13.2.0, an update of copyright and a correction of the
    comments.
    
    Fixes: ef3bcde75d06 ("ASoc: tas2781: Add tas2781 driver")
    Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
    Link: https://lore.kernel.org/r/20240505122346.1326-1-shenghao-ding@ti.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: tas2781: Fix wrong loading calibrated data sequence [+ + +]
Author: Shenghao Ding <shenghao-ding@ti.com>
Date:   Sat May 18 22:15:46 2024 +0800

    ASoC: tas2781: Fix wrong loading calibrated data sequence
    
    [ Upstream commit b195acf5266d2dee4067f89345c3e6b88d925311 ]
    
    Calibrated data will be set to default after loading DSP config params,
    which will cause speaker protection work abnormally. Reload calibrated
    data after loading DSP config params. Remove declaration of unused API
    which load calibrated data in wrong sequence, changed the copyright year
    and correct file name in license
    header.
    
    Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver")
    Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
    Link: https://msgid.link/r/20240518141546.1742-1-shenghao-ding@ti.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: tracing: Export SND_SOC_DAPM_DIR_OUT to its value [+ + +]
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Tue Apr 16 00:03:03 2024 -0400

    ASoC: tracing: Export SND_SOC_DAPM_DIR_OUT to its value
    
    [ Upstream commit 58300f8d6a48e58d1843199be743f819e2791ea3 ]
    
    The string SND_SOC_DAPM_DIR_OUT is printed in the snd_soc_dapm_path trace
    event instead of its value:
    
       (((REC->path_dir) == SND_SOC_DAPM_DIR_OUT) ? "->" : "<-")
    
    User space cannot parse this, as it has no idea what SND_SOC_DAPM_DIR_OUT
    is. Use TRACE_DEFINE_ENUM() to convert it to its value:
    
       (((REC->path_dir) == 1) ? "->" : "<-")
    
    So that user space tools, such as perf and trace-cmd, can parse it
    correctly.
    
    Reported-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Fixes: 6e588a0d839b5 ("ASoC: dapm: Consolidate path trace events")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Link: https://lore.kernel.org/r/20240416000303.04670cdf@rorschach.local.home
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ax25: Fix reference count leak issue of net_device [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Thu May 9 17:37:02 2024 +0800

    ax25: Fix reference count leak issue of net_device
    
    [ Upstream commit 36e56b1b002bb26440403053f19f9e1a8bc075b2 ]
    
    There is a reference count leak issue of the object "net_device" in
    ax25_dev_device_down(). When the ax25 device is shutting down, the
    ax25_dev_device_down() drops the reference count of net_device one
    or zero times depending on if we goto unlock_put or not, which will
    cause memory leak.
    
    In order to solve the above issue, decrease the reference count of
    net_device after dev->ax25_ptr is set to null.
    
    Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs")
    Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/7ce3b23a40d9084657ba1125432f0ecc380cbc80.1715247018.git.duoming@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ax25: Fix reference count leak issues of ax25_dev [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Thu May 9 17:36:47 2024 +0800

    ax25: Fix reference count leak issues of ax25_dev
    
    [ Upstream commit b505e0319852b08a3a716b64620168eab21f4ced ]
    
    The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference
    count leak issue of the object "ax25_dev".
    
    Memory leak issue in ax25_addr_ax25dev():
    
    The reference count of the object "ax25_dev" can be increased multiple
    times in ax25_addr_ax25dev(). This will cause a memory leak.
    
    Memory leak issues in ax25_dev_device_down():
    
    The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and
    then increase the reference count when ax25_dev is added to ax25_dev_list.
    As a result, the reference count of ax25_dev is 2. But when the device is
    shutting down. The ax25_dev_device_down() drops the reference count once
    or twice depending on if we goto unlock_put or not, which will cause
    memory leak.
    
    As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer
    to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the
    issue of ax25_dev_device_down(), increase the reference count of ax25_dev
    once in ax25_dev_device_up() and decrease the reference count of ax25_dev
    after it is removed from the ax25_dev_list.
    
    Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs")
    Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/361bbf2a4b091e120006279ec3b382d73c4a0c17.1715247018.git.duoming@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ax25: Use kernel universal linked list to implement ax25_dev_list [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Thu May 9 17:36:33 2024 +0800

    ax25: Use kernel universal linked list to implement ax25_dev_list
    
    [ Upstream commit a7d6e36b9ad052926ba2ecba3a59d8bb67dabcb4 ]
    
    The origin ax25_dev_list implements its own single linked list,
    which is complicated and error-prone. For example, when deleting
    the node of ax25_dev_list in ax25_dev_device_down(), we have to
    operate on the head node and other nodes separately.
    
    This patch uses kernel universal linked list to replace original
    ax25_dev_list, which make the operation of ax25_dev_list easier.
    
    We should do "dev->ax25_ptr = ax25_dev;" and "dev->ax25_ptr = NULL;"
    while holding the spinlock, otherwise the ax25_dev_device_up() and
    ax25_dev_device_down() could race.
    
    Suggested-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/85bba3af651ca0e1a519da8d0d715b949891171c.1715247018.git.duoming@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: b505e0319852 ("ax25: Fix reference count leak issues of ax25_dev")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bitops: add missing prototype check [+ + +]
Author: Alexander Lobakin <aleksander.lobakin@intel.com>
Date:   Wed Mar 27 16:23:41 2024 +0100

    bitops: add missing prototype check
    
    [ Upstream commit 72cc1980a0ef3ccad0d539e7dace63d0d7d432a4 ]
    
    Commit 8238b4579866 ("wait_on_bit: add an acquire memory barrier") added
    a new bitop, test_bit_acquire(), with proper wrapping in order to try to
    optimize it at compile-time, but missed the list of bitops used for
    checking their prototypes a bit below.
    The functions added have consistent prototypes, so that no more changes
    are required and no functional changes take place.
    
    Fixes: 8238b4579866 ("wait_on_bit: add an acquire memory barrier")
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
blk-cgroup: fix list corruption from reorder of WRITE ->lqueued [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Wed May 15 09:31:57 2024 +0800

    blk-cgroup: fix list corruption from reorder of WRITE ->lqueued
    
    [ Upstream commit d0aac2363549e12cc79b8e285f13d5a9f42fd08e ]
    
    __blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start
    is being executed.
    
    If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in
    the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one
    stat instance being added in blk_cgroup_bio_start(), then the local
    list in __blkcg_rstat_flush() could be corrupted.
    
    Fix the issue by adding one barrier.
    
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Waiman Long <longman@redhat.com>
    Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20240515013157.443672-3-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

blk-cgroup: fix list corruption from resetting io stat [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Wed May 15 09:31:56 2024 +0800

    blk-cgroup: fix list corruption from resetting io stat
    
    [ Upstream commit 6da6680632792709cecf2b006f2fe3ca7857e791 ]
    
    Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"),
    each iostat instance is added to blkcg percpu list, so blkcg_reset_stats()
    can't reset the stat instance by memset(), otherwise the llist may be
    corrupted.
    
    Fix the issue by only resetting the counter part.
    
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Waiman Long <longman@redhat.com>
    Cc: Jay Shin <jaeshin@redhat.com>
    Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()")
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Waiman Long <longman@redhat.com>
    Link: https://lore.kernel.org/r/20240515013157.443672-2-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

blk-cgroup: Properly propagate the iostat update up the hierarchy [+ + +]
Author: Waiman Long <longman@redhat.com>
Date:   Wed May 15 10:30:59 2024 -0400

    blk-cgroup: Properly propagate the iostat update up the hierarchy
    
    [ Upstream commit 9d230c09964e6e18c8f6e4f0d41ee90eef45ec1c ]
    
    During a cgroup_rstat_flush() call, the lowest level of nodes are flushed
    first before their parents. Since commit 3b8cc6298724 ("blk-cgroup:
    Optimize blkcg_rstat_flush()"), iostat propagation was still done to
    the parent. Grandparent, however, may not get the iostat update if the
    parent has no blkg_iostat_set queued in its lhead lockless list.
    
    Fix this iostat propagation problem by queuing the parent's global
    blkg->iostat into one of its percpu lockless lists to make sure that
    the delta will always be propagated up to the grandparent and so on
    toward the root blkcg.
    
    Note that successive calls to __blkcg_rstat_flush() are serialized by
    the cgroup_rstat_lock. So no special barrier is used in the reading
    and writing of blkg->iostat.lqueued.
    
    Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()")
    Reported-by: Dan Schatzberg <schatzberg.dan@gmail.com>
    Closes: https://lore.kernel.org/lkml/ZkO6l%2FODzadSgdhC@dschatzberg-fedora-PF3DHTBV/
    Signed-off-by: Waiman Long <longman@redhat.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Link: https://lore.kernel.org/r/20240515143059.276677-1-longman@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: fix and simplify blkdevparts= cmdline parsing [+ + +]
Author: INAGAKI Hiroshi <musashino.open@gmail.com>
Date:   Sun Apr 21 16:39:52 2024 +0900

    block: fix and simplify blkdevparts= cmdline parsing
    
    [ Upstream commit bc2e07dfd2c49aaa4b52302cf7b55cf94e025f79 ]
    
    Fix the cmdline parsing of the "blkdevparts=" parameter using strsep(),
    which makes the code simpler.
    
    Before commit 146afeb235cc ("block: use strscpy() to instead of
    strncpy()"), we used a strncpy() to copy a block device name and partition
    names. The commit simply replaced a strncpy() and NULL termination with
    a strscpy(). It did not update calculations of length passed to strscpy().
    While the length passed to strncpy() is just a length of valid characters
    without NULL termination ('\0'), strscpy() takes it as a length of the
    destination buffer, including a NULL termination.
    
    Since the source buffer is not necessarily NULL terminated, the current
    code copies "length - 1" characters and puts a NULL character in the
    destination buffer. It replaces the last character with NULL and breaks
    the parsing.
    
    As an example, that buffer will be passed to parse_parts() and breaks
    parsing sub-partitions due to the missing ')' at the end, like the
    following.
    
    example (Check Point V-80 & OpenWrt):
    
    - Linux Kernel 6.6
    
      [    0.000000] Kernel command line: console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000 crashkernel=30M mvpp2x.queue_mode=1 blkdevparts=mmcblk1:48M@10M(kernel-1),1M(dtb-1),720M(rootfs-1),48M(kernel-2),1M(dtb-2),720M(rootfs-2),300M(default_sw),650M(logs),1M(preset_cfg),1M(adsl),-(storage) maxcpus=4
      ...
      [    0.884016] mmc1: new HS200 MMC card at address 0001
      [    0.889951] mmcblk1: mmc1:0001 004GA0 3.69 GiB
      [    0.895043] cmdline partition format is invalid.
      [    0.895704]  mmcblk1: p1
      [    0.903447] mmcblk1boot0: mmc1:0001 004GA0 2.00 MiB
      [    0.908667] mmcblk1boot1: mmc1:0001 004GA0 2.00 MiB
      [    0.913765] mmcblk1rpmb: mmc1:0001 004GA0 512 KiB, chardev (248:0)
    
      1. "48M@10M(kernel-1),..." is passed to strscpy() with length=17
         from parse_parts()
      2. strscpy() returns -E2BIG and the destination buffer has
         "48M@10M(kernel-1\0"
      3. "48M@10M(kernel-1\0" is passed to parse_subpart()
      4. parse_subpart() fails to find ')' when parsing a partition name,
         and returns error
    
    - Linux Kernel 6.1
    
      [    0.000000] Kernel command line: console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000 crashkernel=30M mvpp2x.queue_mode=1 blkdevparts=mmcblk1:48M@10M(kernel-1),1M(dtb-1),720M(rootfs-1),48M(kernel-2),1M(dtb-2),720M(rootfs-2),300M(default_sw),650M(logs),1M(preset_cfg),1M(adsl),-(storage) maxcpus=4
      ...
      [    0.953142] mmc1: new HS200 MMC card at address 0001
      [    0.959114] mmcblk1: mmc1:0001 004GA0 3.69 GiB
      [    0.964259]  mmcblk1: p1(kernel-1) p2(dtb-1) p3(rootfs-1) p4(kernel-2) p5(dtb-2) 6(rootfs-2) p7(default_sw) p8(logs) p9(preset_cfg) p10(adsl) p11(storage)
      [    0.979174] mmcblk1boot0: mmc1:0001 004GA0 2.00 MiB
      [    0.984674] mmcblk1boot1: mmc1:0001 004GA0 2.00 MiB
      [    0.989926] mmcblk1rpmb: mmc1:0001 004GA0 512 KiB, chardev (248:0
    
    By the way, strscpy() takes a length of destination buffer and it is
    often confusing when copying characters with a specified length. Using
    strsep() helps to separate the string by the specified character. Then,
    we can use strscpy() naturally with the size of the destination buffer.
    
    Separating the string on the fly is also useful to omit the redundant
    string copy, reducing memory usage and improve the code readability.
    
    Fixes: 146afeb235cc ("block: use strscpy() to instead of strncpy()")
    Suggested-by: Naohiro Aota <naota@elisp.net>
    Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
    Reviewed-by: Daniel Golle <daniel@makrotopia.org>
    Link: https://lore.kernel.org/r/20240421074005.565-1-musashino.open@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: refine the EOF check in blkdev_iomap_begin [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri May 3 10:10:42 2024 +0200

    block: refine the EOF check in blkdev_iomap_begin
    
    [ Upstream commit 0c12028aec837f5a002009bbf68d179d506510e8 ]
    
    blkdev_iomap_begin rounds down the offset to the logical block size
    before stashing it in iomap->offset and checking that it still is
    inside the inode size.
    
    Check the i_size check to the raw pos value so that we don't try a
    zero size write if iter->pos is unaligned.
    
    Fixes: 487c607df790 ("block: use iomap for writes to block devices")
    Reported-by: syzbot+0a3683a0a6fecf909244@syzkaller.appspotmail.com
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Tested-by: syzbot+0a3683a0a6fecf909244@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/r/20240503081042.2078062-1-hch@lst.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: support to account io_ticks precisely [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Thu May 9 20:37:16 2024 +0800

    block: support to account io_ticks precisely
    
    [ Upstream commit 99dc422335d8b2bd4d105797241d3e715bae90e9 ]
    
    Currently, io_ticks is accounted based on sampling, specifically
    update_io_ticks() will always account io_ticks by 1 jiffies from
    bdev_start_io_acct()/blk_account_io_start(), and the result can be
    inaccurate, for example(HZ is 250):
    
    Test script:
    fio -filename=/dev/sda -bs=4k -rw=write -direct=1 -name=test -thinktime=4ms
    
    Test result: util is about 90%, while the disk is really idle.
    
    This behaviour is introduced by commit 5b18b5a73760 ("block: delete
    part_round_stats and switch to less precise counting"), however, there
    was a key point that is missed that this patch also improve performance
    a lot:
    
    Before the commit:
    part_round_stats:
      if (part->stamp != now)
       stats |= 1;
    
      part_in_flight()
      -> there can be lots of task here in 1 jiffies.
      part_round_stats_single()
       __part_stat_add()
      part->stamp = now;
    
    After the commit:
    update_io_ticks:
      stamp = part->bd_stamp;
      if (time_after(now, stamp))
       if (try_cmpxchg())
        __part_stat_add()
        -> only one task can reach here in 1 jiffies.
    
    Hence in order to account io_ticks precisely, we only need to know if
    there are IO inflight at most once in one jiffies. Noted that for
    rq-based device, iterating tags should not be used here because
    'tags->lock' is grabbed in blk_mq_find_and_get_req(), hence
    part_stat_lock_inc/dec() and part_in_flight() is used to trace inflight.
    The additional overhead is quite little:
    
     - per cpu add/dec for each IO for rq-based device;
     - per cpu sum for each jiffies;
    
    And it's verified by null-blk that there are no performance degration
    under heavy IO pressure.
    
    Fixes: 5b18b5a73760 ("block: delete part_round_stats and switch to less precise counting")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20240509123717.3223892-2-yukuai1@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: compute LE flow credits based on recvbuf space [+ + +]
Author: Sebastian Urban <surban@surban.net>
Date:   Wed May 1 12:08:58 2024 +0200

    Bluetooth: compute LE flow credits based on recvbuf space
    
    [ Upstream commit ce60b9231b66710b6ee24042ded26efee120ecfc ]
    
    Previously LE flow credits were returned to the
    sender even if the socket's receive buffer was
    full. This meant that no back-pressure
    was applied to the sender, thus it continued to
    send data, resulting in data loss without any
    error being reported. Furthermore, the amount
    of credits was essentially fixed to a small
    amount, leading to reduced performance.
    
    This is fixed by computing the number of returned
    LE flow credits based on the estimated available
    space in the receive buffer of an L2CAP socket.
    Consequently, if the receive buffer is full, no
    credits are returned until the buffer is read and
    thus cleared by user-space.
    
    Since the computation of available receive buffer
    space can only be performed approximately (due to
    sk_buff overhead) and the receive buffer size may
    be changed by user-space after flow credits have
    been sent, superfluous received data is temporary
    stored within l2cap_pinfo. This is necessary
    because Bluetooth LE provides no retransmission
    mechanism once the data has been acked by the
    physical layer.
    
    If receive buffer space estimation is not possible
    at the moment, we fall back to providing credits
    for one full packet as before. This is currently
    the case during connection setup, when MPS is not
    yet available.
    
    Fixes: b1c325c23d75 ("Bluetooth: Implement returning of LE L2CAP credits")
    Signed-off-by: Sebastian Urban <surban@surban.net>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: HCI: Remove HCI_AMP support [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon May 6 18:33:52 2024 -0400

    Bluetooth: HCI: Remove HCI_AMP support
    
    [ Upstream commit 84a4bb6548a29326564f0e659fb8064503ecc1c7 ]
    
    Since BT_HS has been remove HCI_AMP controllers no longer has any use so
    remove it along with the capability of creating AMP controllers.
    
    Since we no longer need to differentiate between AMP and Primary
    controllers, as only HCI_PRIMARY is left, this also remove
    hdev->dev_type altogether.
    
    Fixes: e7b02296fb40 ("Bluetooth: Remove BT_HS")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_event: Remove code to removed CONFIG_BT_HS [+ + +]
Author: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Date:   Wed Feb 7 14:42:11 2024 +0100

    Bluetooth: hci_event: Remove code to removed CONFIG_BT_HS
    
    [ Upstream commit f4b0c2b4cd78b75acde56c2ee5aa732b6fb2a6a9 ]
    
    Commit cec9f3c5561d ("Bluetooth: Remove BT_HS") removes config BT_HS, but
    misses two "ifdef BT_HS" blocks in hci_event.c.
    
    Remove this dead code from this removed config option.
    
    Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 84a4bb6548a2 ("Bluetooth: HCI: Remove HCI_AMP support")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: Fix BIS cleanup [+ + +]
Author: Iulia Tanasescu <iulia.tanasescu@nxp.com>
Date:   Wed Sep 6 16:59:54 2023 +0300

    Bluetooth: ISO: Fix BIS cleanup
    
    [ Upstream commit a254b90c9aac3d3d938a07e019773e35a977451b ]
    
    This fixes the master BIS cleanup procedure - as opposed to CIS cleanup,
    no HCI disconnect command should be issued. A master BIS should only be
    terminated by disabling periodic and extended advertising, and terminating
    the BIG.
    
    In case of a Broadcast Receiver, all BIS and PA connections can be
    cleaned up by calling hci_conn_failed, since it contains all function
    calls that are necessary for successful cleanup.
    
    Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 84a4bb6548a2 ("Bluetooth: HCI: Remove HCI_AMP support")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: qca: Fix error code in qca_read_fw_build_info() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Sat May 4 14:25:43 2024 +0300

    Bluetooth: qca: Fix error code in qca_read_fw_build_info()
    
    [ Upstream commit a189f0ee6685457528db7a36ded3085e5d13ddc3 ]
    
    Return -ENOMEM on allocation failure.  Don't return success.
    
    Fixes: cda0d6a198e2 ("Bluetooth: qca: fix info leak when fetching fw build id")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: Remove usage of the deprecated ida_simple_xx() API [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Jan 15 21:12:19 2024 +0100

    Bluetooth: Remove usage of the deprecated ida_simple_xx() API
    
    [ Upstream commit 9c16d0c8d93e3d2a95c5ed927b061f244db75579 ]
    
    ida_alloc() and ida_free() should be preferred to the deprecated
    ida_simple_get() and ida_simple_remove().
    
    Note that the upper limit of ida_simple_get() is exclusive, but the one of
    ida_alloc_max() is inclusive. So a -1 has been added when needed.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 84a4bb6548a2 ("Bluetooth: HCI: Remove HCI_AMP support")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq [+ + +]
Author: Michal Schmidt <mschmidt@redhat.com>
Date:   Tue May 7 12:39:28 2024 +0200

    bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq
    
    [ Upstream commit 78cfd17142ef70599d6409cbd709d94b3da58659 ]
    
    Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called
    with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0.
    In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called.
    roundup_pow_of_two is documented as undefined for 0.
    
    Fix it in the one caller that had this combination.
    
    The undefined behavior was detected by UBSAN:
      UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
      shift exponent 64 is too large for 64-bit type 'long unsigned int'
      CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4
      Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023
      Call Trace:
       <TASK>
       dump_stack_lvl+0x5d/0x80
       ubsan_epilogue+0x5/0x30
       __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec
       __roundup_pow_of_two+0x25/0x35 [bnxt_re]
       bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]
       bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]
       bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __kmalloc+0x1b6/0x4f0
       ? create_qp.part.0+0x128/0x1c0 [ib_core]
       ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]
       create_qp.part.0+0x128/0x1c0 [ib_core]
       ib_create_qp_kernel+0x50/0xd0 [ib_core]
       create_mad_qp+0x8e/0xe0 [ib_core]
       ? __pfx_qp_event_handler+0x10/0x10 [ib_core]
       ib_mad_init_device+0x2be/0x680 [ib_core]
       add_client_context+0x10d/0x1a0 [ib_core]
       enable_device_and_get+0xe0/0x1d0 [ib_core]
       ib_register_device+0x53c/0x630 [ib_core]
       ? srso_alias_return_thunk+0x5/0xfbef5
       bnxt_re_probe+0xbd8/0xe50 [bnxt_re]
       ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]
       auxiliary_bus_probe+0x49/0x80
       ? driver_sysfs_add+0x57/0xc0
       really_probe+0xde/0x340
       ? pm_runtime_barrier+0x54/0x90
       ? __pfx___driver_attach+0x10/0x10
       __driver_probe_device+0x78/0x110
       driver_probe_device+0x1f/0xa0
       __driver_attach+0xba/0x1c0
       bus_for_each_dev+0x8f/0xe0
       bus_add_driver+0x146/0x220
       driver_register+0x72/0xd0
       __auxiliary_driver_register+0x6e/0xd0
       ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
       bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]
       ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
       do_one_initcall+0x5b/0x310
       do_init_module+0x90/0x250
       init_module_from_file+0x86/0xc0
       idempotent_init_module+0x121/0x2b0
       __x64_sys_finit_module+0x5e/0xb0
       do_syscall_64+0x82/0x160
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? syscall_exit_to_user_mode_prepare+0x149/0x170
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? syscall_exit_to_user_mode+0x75/0x230
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? do_syscall_64+0x8e/0x160
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? __count_memcg_events+0x69/0x100
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? count_memcg_events.constprop.0+0x1a/0x30
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? handle_mm_fault+0x1f0/0x300
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? do_user_addr_fault+0x34e/0x640
       ? srso_alias_return_thunk+0x5/0xfbef5
       ? srso_alias_return_thunk+0x5/0xfbef5
       entry_SYSCALL_64_after_hwframe+0x76/0x7e
      RIP: 0033:0x7f4e5132821d
      Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48
      RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d
      RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b
      RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0
      R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d
      R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60
       </TASK>
      ---[ end trace ]---
    
    Fixes: 0c4dcd602817 ("RDMA/bnxt_re: Refactor hardware queue memory allocation")
    Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
    Link: https://lore.kernel.org/r/20240507103929.30003-1-mschmidt@redhat.com
    Acked-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, x86: Fix PROBE_MEM runtime load check [+ + +]
Author: Puranjay Mohan <puranjay@kernel.org>
Date:   Wed Apr 24 10:02:09 2024 +0000

    bpf, x86: Fix PROBE_MEM runtime load check
    
    [ Upstream commit b599d7d26d6ad1fc9975218574bc2ca6d0293cfd ]
    
    When a load is marked PROBE_MEM - e.g. due to PTR_UNTRUSTED access - the
    address being loaded from is not necessarily valid. The BPF jit sets up
    exception handlers for each such load which catch page faults and 0 out
    the destination register.
    
    If the address for the load is outside kernel address space, the load
    will escape the exception handling and crash the kernel. To prevent this
    from happening, the emits some instruction to verify that addr is > end
    of userspace addresses.
    
    x86 has a legacy vsyscall ABI where a page at address 0xffffffffff600000
    is mapped with user accessible permissions. The addresses in this page
    are considered userspace addresses by the fault handler. Therefore, a
    BPF program accessing this page will crash the kernel.
    
    This patch fixes the runtime checks to also check that the PROBE_MEM
    address is below VSYSCALL_ADDR.
    
    Example BPF program:
    
     SEC("fentry/tcp_v4_connect")
     int BPF_PROG(fentry_tcp_v4_connect, struct sock *sk)
     {
            *(volatile unsigned long *)&sk->sk_tsq_flags;
            return 0;
     }
    
    BPF Assembly:
    
     0: (79) r1 = *(u64 *)(r1 +0)
     1: (79) r1 = *(u64 *)(r1 +344)
     2: (b7) r0 = 0
     3: (95) exit
    
                                   x86-64 JIT
                                   ==========
    
                BEFORE                                    AFTER
                ------                                    -----
    
     0:   nopl   0x0(%rax,%rax,1)             0:   nopl   0x0(%rax,%rax,1)
     5:   xchg   %ax,%ax                      5:   xchg   %ax,%ax
     7:   push   %rbp                         7:   push   %rbp
     8:   mov    %rsp,%rbp                    8:   mov    %rsp,%rbp
     b:   mov    0x0(%rdi),%rdi               b:   mov    0x0(%rdi),%rdi
    -------------------------------------------------------------------------------
     f:   movabs $0x100000000000000,%r11      f:   movabs $0xffffffffff600000,%r10
    19:   add    $0x2a0,%rdi                 19:   mov    %rdi,%r11
    20:   cmp    %r11,%rdi                   1c:   add    $0x2a0,%r11
    23:   jae    0x0000000000000029          23:   sub    %r10,%r11
    25:   xor    %edi,%edi                   26:   movabs $0x100000000a00000,%r10
    27:   jmp    0x000000000000002d          30:   cmp    %r10,%r11
    29:   mov    0x0(%rdi),%rdi              33:   ja     0x0000000000000039
    --------------------------------\        35:   xor    %edi,%edi
    2d:   xor    %eax,%eax           \       37:   jmp    0x0000000000000040
    2f:   leave                       \      39:   mov    0x2a0(%rdi),%rdi
    30:   ret                          \--------------------------------------------
                                             40:   xor    %eax,%eax
                                             42:   leave
                                             43:   ret
    
    Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
    Link: https://lore.kernel.org/r/20240424100210.11982-3-puranjay@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE [+ + +]
Author: Stanislav Fomichev <sdf@google.com>
Date:   Fri Apr 26 16:16:18 2024 -0700

    bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
    
    [ Upstream commit 543576ec15b17c0c93301ac8297333c7b6e84ac7 ]
    
    bpf_prog_attach uses attach_type_to_prog_type to enforce proper
    attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses
    bpf_prog_get and relies on bpf_prog_attach_check_attach_type
    to properly verify prog_type <> attach_type association.
    
    Add missing attach_type enforcement for the link_create case.
    Otherwise, it's currently possible to attach cgroup_skb prog
    types to other cgroup hooks.
    
    Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment")
    Link: https://lore.kernel.org/bpf/0000000000004792a90615a1dde0@google.com/
    Reported-by: syzbot+838346b979830606c854@syzkaller.appspotmail.com
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Acked-by: Eduard Zingerman <eddyz87@gmail.com>
    Link: https://lore.kernel.org/r/20240426231621.2716876-2-sdf@google.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Allow delete from sockmap/sockhash only if update is allowed [+ + +]
Author: Jakub Sitnicki <jakub@cloudflare.com>
Date:   Mon May 27 13:20:07 2024 +0200

    bpf: Allow delete from sockmap/sockhash only if update is allowed
    
    [ Upstream commit 98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d ]
    
    We have seen an influx of syzkaller reports where a BPF program attached to
    a tracepoint triggers a locking rule violation by performing a map_delete
    on a sockmap/sockhash.
    
    We don't intend to support this artificial use scenario. Extend the
    existing verifier allowed-program-type check for updating sockmap/sockhash
    to also cover deleting from a map.
    
    From now on only BPF programs which were previously allowed to update
    sockmap/sockhash can delete from these map types.
    
    Fixes: ff9105993240 ("bpf, sockmap: Prevent lock inversion deadlock in map delete elem")
    Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Reported-by: syzbot+ec941d6e24f633a59172@syzkaller.appspotmail.com
    Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: syzbot+ec941d6e24f633a59172@syzkaller.appspotmail.com
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=ec941d6e24f633a59172
    Link: https://lore.kernel.org/bpf/20240527-sockmap-verify-deletes-v1-1-944b372f2101@cloudflare.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix potential integer overflow in resolve_btfids [+ + +]
Author: Friedrich Vock <friedrich.vock@gmx.de>
Date:   Tue May 14 09:09:31 2024 +0200

    bpf: Fix potential integer overflow in resolve_btfids
    
    [ Upstream commit 44382b3ed6b2787710c8ade06c0e97f5970a47c8 ]
    
    err is a 32-bit integer, but elf_update returns an off_t, which is 64-bit
    at least on 64-bit platforms. If symbols_patch is called on a binary between
    2-4GB in size, the result will be negative when cast to a 32-bit integer,
    which the code assumes means an error occurred. This can wrongly trigger
    build failures when building very large kernel images.
    
    Fixes: fbbb68de80a4 ("bpf: Add resolve_btfids tool to resolve BTF IDs in ELF object")
    Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240514070931.199694-1-friedrich.vock@gmx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Fix verifier assumptions about socket->sk [+ + +]
Author: Alexei Starovoitov <ast@kernel.org>
Date:   Fri Apr 26 17:25:44 2024 -0700

    bpf: Fix verifier assumptions about socket->sk
    
    [ Upstream commit 0db63c0b86e981a1e97d2596d64ceceba1a5470e ]
    
    The verifier assumes that 'sk' field in 'struct socket' is valid
    and non-NULL when 'socket' pointer itself is trusted and non-NULL.
    That may not be the case when socket was just created and
    passed to LSM socket_accept hook.
    Fix this verifier assumption and adjust tests.
    
    Reported-by: Liam Wisehart <liamwisehart@meta.com>
    Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
    Fixes: 6fcd486b3a0a ("bpf: Refactor RCU enforcement in the verifier.")
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Link: https://lore.kernel.org/r/20240427002544.68803-1-alexei.starovoitov@gmail.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Pack struct bpf_fib_lookup [+ + +]
Author: Anton Protopopov <aspsk@isovalent.com>
Date:   Wed Apr 3 14:33:03 2024 +0200

    bpf: Pack struct bpf_fib_lookup
    
    [ Upstream commit f91717007217d975aa975ddabd91ae1a107b9bff ]
    
    The struct bpf_fib_lookup is supposed to be of size 64. A recent commit
    59b418c7063d ("bpf: Add a check for struct bpf_fib_lookup size") added
    a static assertion to check this property so that future changes to the
    structure will not accidentally break this assumption.
    
    As it immediately turned out, on some 32-bit arm systems, when AEABI=n,
    the total size of the structure was equal to 68, see [1]. This happened
    because the bpf_fib_lookup structure contains a union of two 16-bit
    fields:
    
        union {
                __u16 tot_len;
                __u16 mtu_result;
        };
    
    which was supposed to compile to a 16-bit-aligned 16-bit field. On the
    aforementioned setups it was instead both aligned and padded to 32-bits.
    
    Declare this inner union as __attribute__((packed, aligned(2))) such
    that it always is of size 2 and is aligned to 16 bits.
    
      [1] https://lore.kernel.org/all/CA+G9fYtsoP51f-oP_Sp5MOq-Ffv8La2RztNpwvE6+R1VtFiLrw@mail.gmail.com/#t
    
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Fixes: e1850ea9bd9e ("bpf: bpf_fib_lookup return MTU value as output when looked up")
    Signed-off-by: Anton Protopopov <aspsk@isovalent.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240403123303.1452184-1-aspsk@isovalent.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: prevent r10 register from being marked as precise [+ + +]
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Thu Apr 4 14:45:35 2024 -0700

    bpf: prevent r10 register from being marked as precise
    
    [ Upstream commit 1f2a74b41ea8b902687eb97c4e7e3f558801865b ]
    
    r10 is a special register that is not under BPF program's control and is
    always effectively precise. The rest of precision logic assumes that
    only r0-r9 SCALAR registers are marked as precise, so prevent r10 from
    being marked precise.
    
    This can happen due to signed cast instruction allowing to do something
    like `r0 = (s8)r10;`, which later, if r0 needs to be precise, would lead
    to an attempt to mark r10 as precise.
    
    Prevent this with an extra check during instruction backtracking.
    
    Fixes: 8100928c8814 ("bpf: Support new sign-extension mov insns")
    Reported-by: syzbot+148110ee7cf72f39f33e@syzkaller.appspotmail.com
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Acked-by: Yonghong Song <yonghong.song@linux.dev>
    Link: https://lore.kernel.org/r/20240404214536.3551295-1-andrii@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpftool: Fix missing pids during link show [+ + +]
Author: Yonghong Song <yonghong.song@linux.dev>
Date:   Mon Mar 11 19:32:49 2024 -0700

    bpftool: Fix missing pids during link show
    
    [ Upstream commit fe879bb42f8a6513ed18e9d22efb99cb35590201 ]
    
    Current 'bpftool link' command does not show pids, e.g.,
      $ tools/build/bpftool/bpftool link
      ...
      4: tracing  prog 23
            prog_type lsm  attach_type lsm_mac
            target_obj_id 1  target_btf_id 31320
    
    Hack the following change to enable normal libbpf debug output,
    #  --- a/tools/bpf/bpftool/pids.c
    #  +++ b/tools/bpf/bpftool/pids.c
    #  @@ -121,9 +121,9 @@ int build_obj_refs_table(struct hashmap **map, enum bpf_obj_type type)
    #          /* we don't want output polluted with libbpf errors if bpf_iter is not
    #           * supported
    #           */
    #  -       default_print = libbpf_set_print(libbpf_print_none);
    #  +       /* default_print = libbpf_set_print(libbpf_print_none); */
    #          err = pid_iter_bpf__load(skel);
    #  -       libbpf_set_print(default_print);
    #  +       /* libbpf_set_print(default_print); */
    
    Rerun the above bpftool command:
      $ tools/build/bpftool/bpftool link
      libbpf: prog 'iter': BPF program load failed: Permission denied
      libbpf: prog 'iter': -- BEGIN PROG LOAD LOG --
      0: R1=ctx() R10=fp0
      ; struct task_struct *task = ctx->task; @ pid_iter.bpf.c:69
      0: (79) r6 = *(u64 *)(r1 +8)          ; R1=ctx() R6_w=ptr_or_null_task_struct(id=1)
      ; struct file *file = ctx->file; @ pid_iter.bpf.c:68
      ...
      ; struct bpf_link *link = (struct bpf_link *) file->private_data; @ pid_iter.bpf.c:103
      80: (79) r3 = *(u64 *)(r8 +432)       ; R3_w=scalar() R8=ptr_file()
      ; if (link->type == bpf_core_enum_value(enum bpf_link_type___local, @ pid_iter.bpf.c:105
      81: (61) r1 = *(u32 *)(r3 +12)
      R3 invalid mem access 'scalar'
      processed 39 insns (limit 1000000) max_states_per_insn 0 total_states 3 peak_states 3 mark_read 2
      -- END PROG LOAD LOG --
      libbpf: prog 'iter': failed to load: -13
      ...
    
    The 'file->private_data' returns a 'void' type and this caused subsequent 'link->type'
    (insn #81) failed in verification.
    
    To fix the issue, restore the previous BPF_CORE_READ so old kernels can also work.
    With this patch, the 'bpftool link' runs successfully with 'pids'.
      $ tools/build/bpftool/bpftool link
      ...
      4: tracing  prog 23
            prog_type lsm  attach_type lsm_mac
            target_obj_id 1  target_btf_id 31320
            pids systemd(1)
    
    Fixes: 44ba7b30e84f ("bpftool: Use a local copy of BPF_LINK_TYPE_PERF_EVENT in pid_iter.bpf.c")
    Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Tested-by: Quentin Monnet <quentin@isovalent.com>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20240312023249.3776718-1-yonghong.song@linux.dev
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpftool: Mount bpffs on provided dir instead of parent dir [+ + +]
Author: Sahil Siddiq <icegambit91@gmail.com>
Date:   Fri Apr 5 00:52:19 2024 +0530

    bpftool: Mount bpffs on provided dir instead of parent dir
    
    [ Upstream commit 478a535ae54ad3831371904d93b5dfc403222e17 ]
    
    When pinning programs/objects under PATH (eg: during "bpftool prog
    loadall") the bpffs is mounted on the parent dir of PATH in the
    following situations:
    - the given dir exists but it is not bpffs.
    - the given dir doesn't exist and the parent dir is not bpffs.
    
    Mounting on the parent dir can also have the unintentional side-
    effect of hiding other files located under the parent dir.
    
    If the given dir exists but is not bpffs, then the bpffs should
    be mounted on the given dir and not its parent dir.
    
    Similarly, if the given dir doesn't exist and its parent dir is not
    bpffs, then the given dir should be created and the bpffs should be
    mounted on this new dir.
    
    Fixes: 2a36c26fe3b8 ("bpftool: Support bpffs mountpoint as pin path for prog loadall")
    Signed-off-by: Sahil Siddiq <icegambit91@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/2da44d24-74ae-a564-1764-afccf395eeec@isovalent.com/T/#t
    Link: https://lore.kernel.org/bpf/20240404192219.52373-1-icegambit91@gmail.com
    
    Closes: https://github.com/libbpf/bpftool/issues/100
    
    Changes since v1:
     - Split "mount_bpffs_for_pin" into two functions.
       This is done to improve maintainability and readability.
    
    Changes since v2:
    - mount_bpffs_for_pin: rename to "create_and_mount_bpffs_dir".
    - mount_bpffs_given_file: rename to "mount_bpffs_given_file".
    - create_and_mount_bpffs_dir:
      - introduce "dir_exists" boolean.
      - remove new dir if "mnt_fs" fails.
    - improve error handling and error messages.
    
    Changes since v3:
    - Rectify function name.
    - Improve error messages and formatting.
    - mount_bpffs_for_file:
      - Check if dir exists before block_mount check.
    
    Changes since v4:
    - Use strdup instead of strcpy.
    - create_and_mount_bpffs_dir:
      - Use S_IRWXU instead of 0700.
    - Improve error handling and formatting.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: mediatek: mt8365-mm: fix DPI0 parent [+ + +]
Author: Alexandre Mergnat <amergnat@baylibre.com>
Date:   Thu Apr 18 16:17:00 2024 +0200

    clk: mediatek: mt8365-mm: fix DPI0 parent
    
    [ Upstream commit 4c0c087772d7e29bc2489ddb068d5167140bfc38 ]
    
    To have a working display through DPI, a workaround has been
    implemented downstream to add "mm_dpi0_dpi0" and "dpi0_sel" to
    the DPI node. Shortly, that add an extra clock.
    
    It seems consistent to have the "dpi0_sel" as parent.
    Additionnaly, "vpll_dpix" isn't used/managed.
    
    Then, set the "mm_dpi0_dpi0" parent clock to "dpi0_sel".
    
    The new clock tree is:
    
    clk26m
      lvdspll
        lvdspll_X (2, 4, 8, 16)
          dpi0_sel
            mm_dpi0_dpi0
    
    Fixes: d46adccb7966 ("clk: mediatek: add driver for MT8365 SoC")
    Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
    Link: https://lore.kernel.org/r/20231023-display-support-v3-12-53388f3ed34b@baylibre.com
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: pllfh: Don't log error for missing fhctl node [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Fri Mar 8 15:29:56 2024 -0500

    clk: mediatek: pllfh: Don't log error for missing fhctl node
    
    [ Upstream commit bb7b3c8e7180f36de75cdea200ab7127f93f58cc ]
    
    Support for fhctl clocks in apmixedsys was introduced at a later point
    and to this moment only one mt6795 based platform has a fhctl DT node
    present. Therefore the fhctl support in apmixedsys should be seen as
    optional and not cause an error when it is missing.
    
    Change the message's log level to warning. The warning level is chosen
    so that it will still alert the fact that fhctl support might be
    unintentionally missing, but without implying that this is necessarily
    an issue.
    
    Even if the FHCTL DT nodes are added to all current platforms moving
    forward, since those changes won't be backported, this ensures stable
    kernel releases won't have live with this error.
    
    Fixes: d7964de8a8ea ("clk: mediatek: Add new clock driver to handle FHCTL hardware")
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Link: https://lore.kernel.org/r/20240308-mtk-fhctl-no-node-error-v1-1-51e446eb149a@collabora.com
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: clk-alpha-pll: remove invalid Stromer register offset [+ + +]
Author: Gabor Juhos <j4g8y7@gmail.com>
Date:   Mon Mar 11 19:45:19 2024 +0100

    clk: qcom: clk-alpha-pll: remove invalid Stromer register offset
    
    [ Upstream commit 4f2bc4acbb1916b8cd2ce4bb3ba7b1cd7cb705fa ]
    
    The offset of the CONFIG_CTL_U register defined for the Stromer
    PLL is wrong. It is not aligned on a 4 bytes boundary which might
    causes errors in regmap operations.
    
    Maybe the intention behind of using the 0xff value was to indicate
    that the register is not implemented in the PLL, but this is not
    verified anywhere in the code. Moreover, this value is not used
    even in other register offset arrays despite that those PLLs also
    have unimplemented registers.
    
    Additionally, on the Stromer PLLs the current code only touches
    the CONFIG_CTL_U register if the result of pll_has_64bit_config()
    is true which condition is not affected by the change.
    
    Due to the reasons above, simply remove the CONFIG_CTL_U entry
    from the Stromer specific array.
    
    Fixes: e47a4f55f240 ("clk: qcom: clk-alpha-pll: Add support for Stromer PLLs")
    Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20240311-alpha-pll-stromer-cleanup-v1-1-f7c0c5607cca@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: dispcc-sm6350: fix DisplayPort clocks [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Apr 24 04:39:30 2024 +0300

    clk: qcom: dispcc-sm6350: fix DisplayPort clocks
    
    [ Upstream commit 1113501cfb46d5c0eb960f0a8a9f6c0f91dc6fb6 ]
    
    On SM6350 DisplayPort link clocks use frequency tables inherited from
    the vendor kernel, it is not applicable in the upstream kernel. Drop
    frequency tables and use clk_byte2_ops for those clocks.
    
    This fixes frequency selection in the OPP core (which otherwise attempts
    to use invalid 810 KHz as DP link rate), also fixing the following
    message:
    msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22
    
    Fixes: 837519775f1d ("clk: qcom: Add display clock controller driver for SM6350")
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Tested-by: Luca Weiss <luca.weiss@fairphone.com>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-2-b44038f3fa96@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: dispcc-sm8450: fix DisplayPort clocks [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Apr 24 04:39:29 2024 +0300

    clk: qcom: dispcc-sm8450: fix DisplayPort clocks
    
    [ Upstream commit e801038a02ce1e8c652a0b668dd233a4ee48aeb7 ]
    
    On SM8450 DisplayPort link clocks use frequency tables inherited from
    the vendor kernel, it is not applicable in the upstream kernel. Drop
    frequency tables and use clk_byte2_ops for those clocks.
    
    This fixes frequency selection in the OPP core (which otherwise attempts
    to use invalid 810 KHz as DP link rate), also fixing the following
    message:
    msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22
    
    Fixes: 16fb89f92ec4 ("clk: qcom: Add support for Display Clock Controller on SM8450")
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-1-b44038f3fa96@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: dispcc-sm8550: fix DisplayPort clocks [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Apr 24 04:39:31 2024 +0300

    clk: qcom: dispcc-sm8550: fix DisplayPort clocks
    
    [ Upstream commit e90b5139da8465a15c3820b4b67ca9468dce93b4 ]
    
    On SM8550 DisplayPort link clocks use frequency tables inherited from
    the vendor kernel, it is not applicable in the upstream kernel. Drop
    frequency tables and use clk_byte2_ops for those clocks.
    
    This fixes frequency selection in the OPP core (which otherwise attempts
    to use invalid 810 KHz as DP link rate), also fixing the following
    message:
    msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22
    
    Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver")
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-HDK
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-3-b44038f3fa96@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: mmcc-msm8998: fix venus clock issue [+ + +]
Author: Marc Gonzalez <mgonzalez@freebox.fr>
Date:   Thu Apr 25 17:07:07 2024 +0200

    clk: qcom: mmcc-msm8998: fix venus clock issue
    
    [ Upstream commit e20ae5ae9f0c843aded4f06f3d1cab7384789e92 ]
    
    Right now, msm8998 video decoder (venus) is non-functional:
    
    $ time mpv --hwdec=v4l2m2m-copy --vd-lavc-software-fallback=no --vo=null --no-audio --untimed --length=30 --quiet demo-480.webm
     (+) Video --vid=1 (*) (vp9 854x480 29.970fps)
         Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
    [ffmpeg/video] vp9_v4l2m2m: output VIDIOC_REQBUFS failed: Connection timed out
    [ffmpeg/video] vp9_v4l2m2m: no v4l2 output context's buffers
    [ffmpeg/video] vp9_v4l2m2m: can't configure decoder
    Could not open codec.
    Software decoding fallback is disabled.
    Exiting... (Quit)
    
    Bryan O'Donoghue suggested the proper fix:
    - Set required register offsets in venus GDSC structs.
    - Set HW_CTRL flag.
    
    $ time mpv --hwdec=v4l2m2m-copy --vd-lavc-software-fallback=no --vo=null --no-audio --untimed --length=30 --quiet demo-480.webm
     (+) Video --vid=1 (*) (vp9 854x480 29.970fps)
         Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz)
    [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
    [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl
    ...
    Using hardware decoding (v4l2m2m-copy).
    VO: [null] 854x480 nv12
    Exiting... (End of file)
    real    0m3.315s
    user    0m1.277s
    sys     0m0.453s
    
    NOTES:
    
    GDSC = Globally Distributed Switch Controller
    
    Use same code as mmcc-msm8996 with:
    s/venus_gdsc/video_top_gdsc/
    s/venus_core0_gdsc/video_subcore0_gdsc/
    s/venus_core1_gdsc/video_subcore1_gdsc/
    
    https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/include/dt-bindings/clock/msm-clocks-hwio-8996.h
    https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/include/dt-bindings/clock/msm-clocks-hwio-8998.h
    
    0x1024 = MMSS_VIDEO GDSCR (undocumented)
    0x1028 = MMSS_VIDEO_CORE_CBCR
    0x1030 = MMSS_VIDEO_AHB_CBCR
    0x1034 = MMSS_VIDEO_AXI_CBCR
    0x1038 = MMSS_VIDEO_MAXI_CBCR
    0x1040 = MMSS_VIDEO_SUBCORE0 GDSCR (undocumented)
    0x1044 = MMSS_VIDEO_SUBCORE1 GDSCR (undocumented)
    0x1048 = MMSS_VIDEO_SUBCORE0_CBCR
    0x104c = MMSS_VIDEO_SUBCORE1_CBCR
    
    Fixes: d14b15b5931c2b ("clk: qcom: Add MSM8998 Multimedia Clock Controller (MMCC) driver")
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Link: https://lore.kernel.org/r/ff4e2e34-a677-4c39-8c29-83655c5512ae@freebox.fr
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: r8a779a0: Fix CANFD parent clock [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Tue Apr 16 17:00:51 2024 +0200

    clk: renesas: r8a779a0: Fix CANFD parent clock
    
    [ Upstream commit 3b23118bdbd898dc2f4de8f549d598d492c42ba8 ]
    
    According to Figure 52A.1 ("RS-CANFD Module Block Diagram (in classical
    CAN mode)") in the R-Car V3U Series User’s Manual Rev. 0.5, the parent
    clock for the CANFD peripheral module clock is the S3D2 clock.
    
    Fixes: 9b621b6adff53346 ("clk: renesas: r8a779a0: Add CANFD module clock")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/aef9300f44c9141b1465343f91c5cc7303249b6e.1713279523.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: r9a07g043: Add clock and reset entry for PLIC [+ + +]
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date:   Wed Apr 3 21:09:52 2024 +0100

    clk: renesas: r9a07g043: Add clock and reset entry for PLIC
    
    [ Upstream commit 44019387fce230beda35b83da3a2c9fc5787704e ]
    
    Add the missing clock and reset entry for PLIC. Also add
    R9A07G043_NCEPLIC_ACLK to the critical clocks list.
    
    Fixes: 95d48d270305ad2c ("clk: renesas: r9a07g043: Add support for RZ/Five SoC")
    Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20240403200952.633084-1-prabhakar.mahadev-lad.rj@bp.renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: rs9: fix wrong default value for clock amplitude [+ + +]
Author: Catalin Popescu <catalin.popescu@leica-geosystems.com>
Date:   Mon Apr 15 16:03:48 2024 +0200

    clk: rs9: fix wrong default value for clock amplitude
    
    [ Upstream commit 1758c68c81b8b881818fcebaaeb91055362a82f8 ]
    
    According to 9FGV0241, 9FGV0441 & 9FGV0841 datasheets, the default
    value for the clock amplitude is 0.8V, while the driver assumes 0.7V.
    
    Additionally, define constants for default values for both clock
    amplitude and spread spectrum and use them.
    
    Fixes: 892e0ddea1aa ("clk: rs9: Add Renesas 9-series PCIe clock generator driver")
    Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com>
    Reviewed-by: Marek Vasut <marex@denx.de>
    Link: https://lore.kernel.org/r/20240415140348.2887619-1-catalin.popescu@leica-geosystems.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: samsung: exynosautov9: fix wrong pll clock id value [+ + +]
Author: Jaewon Kim <jaewon02.kim@samsung.com>
Date:   Thu Mar 28 18:10:00 2024 +0900

    clk: samsung: exynosautov9: fix wrong pll clock id value
    
    [ Upstream commit 04ee3a0b44e3d18cf6b0c712d14b98624877fd26 ]
    
    All PLL id values of CMU_TOP were incorrectly set to FOUT_SHARED0_PLL.
    It modified to the correct PLL clock id value.
    
    Fixes: 6587c62f69dc ("clk: samsung: add top clock support for Exynos Auto v9 SoC")
    Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
    Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
    Link: https://lore.kernel.org/r/20240328091000.17660-1-jaewon02.kim@samsung.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
coresight: etm4x: Do not hardcode IOMEM access for register restore [+ + +]
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Fri Apr 12 15:26:59 2024 +0100

    coresight: etm4x: Do not hardcode IOMEM access for register restore
    
    [ Upstream commit 1e7ba33fa591de1cf60afffcabb45600b3607025 ]
    
    When we restore the register state for ETM4x, while coming back
    from CPU idle, we hardcode IOMEM access. This is wrong and could
    blow up for an ETM with system instructions access (and for ETE).
    
    Fixes: f5bd523690d2 ("coresight: etm4x: Convert all register accesses")
    Reported-by: Yabin Cui <yabinc@google.com>
    Reviewed-by: Mike Leach <mike.leach@linaro.org>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Tested-by: Yabin Cui <yabinc@google.com>
    Link: https://lore.kernel.org/r/20240412142702.2882478-2-suzuki.poulose@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

coresight: etm4x: Do not save/restore Data trace control registers [+ + +]
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Fri Apr 12 15:27:00 2024 +0100

    coresight: etm4x: Do not save/restore Data trace control registers
    
    [ Upstream commit 5eb3a0c2c52368cb9902e9a6ea04888e093c487d ]
    
    ETM4x doesn't support Data trace on A class CPUs. As such do not access the
    Data trace control registers during CPU idle. This could cause problems for
    ETE. While at it, remove all references to the Data trace control registers.
    
    Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states")
    Reported-by: Yabin Cui <yabinc@google.com>
    Reviewed-by: Mike Leach <mike.leach@linaro.org>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Tested-by: Yabin Cui <yabinc@google.com>
    Link: https://lore.kernel.org/r/20240412142702.2882478-3-suzuki.poulose@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

coresight: etm4x: Fix access to resource selector registers [+ + +]
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Fri Apr 12 15:27:02 2024 +0100

    coresight: etm4x: Fix access to resource selector registers
    
    [ Upstream commit d6fc00d0f640d6010b51054aa8b0fd191177dbc9 ]
    
    Resource selector pair 0 is always implemented and reserved. We must not
    touch it, even during save/restore for CPU Idle. Rest of the driver is
    well behaved. Fix the offending ones.
    
    Reported-by: Yabin Cui <yabinc@google.com>
    Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states")
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Tested-by: Yabin Cui <yabinc@google.com>
    Reviewed-by: Mike Leach <mike.leach@linaro.org>
    Link: https://lore.kernel.org/r/20240412142702.2882478-5-suzuki.poulose@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

coresight: etm4x: Fix unbalanced pm_runtime_enable() [+ + +]
Author: Anshuman Khandual <anshuman.khandual@arm.com>
Date:   Thu Mar 14 11:28:33 2024 +0530

    coresight: etm4x: Fix unbalanced pm_runtime_enable()
    
    [ Upstream commit caa41c47dab7e1054f587e592ab21296e3a6781c ]
    
    There is an unbalanced pm_runtime_enable() in etm4_probe_platform_dev()
    when etm4_probe() fails. This problem can be observed via the coresight
    etm4 module's (load -> unload -> load) sequence when etm4_probe() fails
    in etm4_probe_platform_dev().
    
    [   63.379943] coresight-etm4x 7040000.etm: Unbalanced pm_runtime_enable!
    [   63.393630] coresight-etm4x 7140000.etm: Unbalanced pm_runtime_enable!
    [   63.407455] coresight-etm4x 7240000.etm: Unbalanced pm_runtime_enable!
    [   63.420983] coresight-etm4x 7340000.etm: Unbalanced pm_runtime_enable!
    [   63.420999] coresight-etm4x 7440000.etm: Unbalanced pm_runtime_enable!
    [   63.441209] coresight-etm4x 7540000.etm: Unbalanced pm_runtime_enable!
    [   63.454689] coresight-etm4x 7640000.etm: Unbalanced pm_runtime_enable!
    [   63.474982] coresight-etm4x 7740000.etm: Unbalanced pm_runtime_enable!
    
    This fixes the above problem - with an explicit pm_runtime_disable() call
    when etm4_probe() fails during etm4_probe_platform_dev().
    
    Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
    Cc: Hanjun Guo <guohanjun@huawei.com>
    Cc: Sudeep Holla <sudeep.holla@arm.com>
    Cc: "Rafael J. Wysocki" <rafael@kernel.org>
    Cc: Len Brown <lenb@kernel.org>
    Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: James Clark <james.clark@arm.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: linux-acpi@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Cc: coresight@lists.linaro.org
    Fixes: 5214b563588e ("coresight: etm4x: Add support for sysreg only devices")
    Reviewed-by: James Clark <james.clark@arm.com>
    Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20240314055843.2625883-2-anshuman.khandual@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

coresight: etm4x: Safe access for TRCQCLTR [+ + +]
Author: Suzuki K Poulose <suzuki.poulose@arm.com>
Date:   Fri Apr 12 15:27:01 2024 +0100

    coresight: etm4x: Safe access for TRCQCLTR
    
    [ Upstream commit 46bf8d7cd8530eca607379033b9bc4ac5590a0cd ]
    
    ETM4x implements TRCQCLTR only when the Q elements are supported
    and the Q element filtering is supported (TRCIDR0.QFILT). Access
    to the register otherwise could be fatal. Fix this by tracking the
    availability, like the others.
    
    Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states")
    Reported-by: Yabin Cui <yabinc@google.com>
    Reviewed-by: Mike Leach <mike.leach@linaro.org>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Tested-by: Yabin Cui <yabinc@google.com>
    Link: https://lore.kernel.org/r/20240412142702.2882478-4-suzuki.poulose@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
counter: linux/counter.h: fix Excess kernel-doc description warning [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Dec 22 21:05:11 2023 -0800

    counter: linux/counter.h: fix Excess kernel-doc description warning
    
    [ Upstream commit 416bdb89605d960405178b9bf04df512d1ace1a3 ]
    
    Remove the @priv: line to prevent the kernel-doc warning:
    
    include/linux/counter.h:400: warning: Excess struct member 'priv' description in 'counter_device'
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Fixes: f2ee4759fb70 ("counter: remove old and now unused registration API")
    Link: https://lore.kernel.org/r/20231223050511.13849-1-rdunlap@infradead.org
    Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cppc_cpufreq: Fix possible null pointer dereference [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Mon Apr 8 12:35:36 2024 +0300

    cppc_cpufreq: Fix possible null pointer dereference
    
    [ Upstream commit cf7de25878a1f4508c69dc9f6819c21ba177dbfe ]
    
    cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from
    different places with various parameters. So cpufreq_cpu_get() can return
    null as 'policy' in some circumstances.
    Fix this bug by adding null return check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Apr 19 17:05:55 2024 -0700

    cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n
    
    [ Upstream commit ce0abef6a1d540acef85068e0e82bdf1fbeeb0e9 ]
    
    Explicitly disallow enabling mitigations at runtime for kernels that were
    built with CONFIG_CPU_MITIGATIONS=n, as some architectures may omit code
    entirely if mitigations are disabled at compile time.
    
    E.g. on x86, a large pile of Kconfigs are buried behind CPU_MITIGATIONS,
    and trying to provide sane behavior for retroactively enabling mitigations
    is extremely difficult, bordering on impossible.  E.g. page table isolation
    and call depth tracking require build-time support, BHI mitigations will
    still be off without additional kernel parameters, etc.
    
      [ bp: Touchups. ]
    
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/20240420000556.2645001-3-seanjc@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpufreq: brcmstb-avs-cpufreq: ISO C90 forbids mixed declarations [+ + +]
Author: Portia Stephens <portia.stephens@canonical.com>
Date:   Wed Apr 24 15:02:20 2024 +1000

    cpufreq: brcmstb-avs-cpufreq: ISO C90 forbids mixed declarations
    
    [ Upstream commit fa7bd98f3c8b33fb68c6b2bc69cff32b63db69f8 ]
    
    There is a compile warning because a NULL pointer check was added before
    a struct was declared. This moves the NULL pointer check to after the
    struct is declared and moves the struct assignment to after the NULL
    pointer check.
    
    Fixes: f661017e6d32 ("cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value")
    Signed-off-by: Portia Stephens <portia.stephens@canonical.com>
    Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: exit() callback is optional [+ + +]
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Fri Apr 12 11:19:20 2024 +0530

    cpufreq: exit() callback is optional
    
    [ Upstream commit b8f85833c05730d631576008daaa34096bc7f3ce ]
    
    The exit() callback is optional and shouldn't be called without checking
    a valid pointer first.
    
    Also, we must clear freq_table pointer even if the exit() callback isn't
    present.
    
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Fixes: 91a12e91dc39 ("cpufreq: Allow light-weight tear down and bring up of CPUs")
    Fixes: f339f3541701 ("cpufreq: Rearrange locking in cpufreq_remove_dev()")
    Reported-by: Lizhe <sensor1010@163.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: bcm - Fix pointer arithmetic [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Fri Mar 22 23:59:15 2024 +0300

    crypto: bcm - Fix pointer arithmetic
    
    [ Upstream commit 2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9 ]
    
    In spu2_dump_omd() value of ptr is increased by ciph_key_len
    instead of hash_iv_len which could lead to going beyond the
    buffer boundaries.
    Fix this bug by changing ciph_key_len to hash_iv_len.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: ccp - drop platform ifdef checks [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Apr 3 10:06:42 2024 +0200

    crypto: ccp - drop platform ifdef checks
    
    [ Upstream commit 42c2d7d02977ef09d434b1f5b354f5bc6c1027ab ]
    
    When both ACPI and OF are disabled, the dev_vdata variable is unused:
    
    drivers/crypto/ccp/sp-platform.c:33:34: error: unused variable 'dev_vdata' [-Werror,-Wunused-const-variable]
    
    This is not a useful configuration, and there is not much point in saving
    a few bytes when only one of the two is enabled, so just remove all
    these ifdef checks and rely on of_match_node() and acpi_match_device()
    returning NULL when these subsystems are disabled.
    
    Fixes: 6c5063434098 ("crypto: ccp - Add ACPI support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: qat - specify firmware files for 402xx [+ + +]
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Mon Apr 22 15:13:17 2024 +0100

    crypto: qat - specify firmware files for 402xx
    
    [ Upstream commit a3dc1f2b6b932a13f139d3be3c765155542c1070 ]
    
    The 4xxx driver can probe 4xxx and 402xx devices. However, the driver
    only specifies the firmware images required for 4xxx.
    This might result in external tools missing these binaries, if required,
    in the initramfs.
    
    Specify the firmware image used by 402xx with the MODULE_FIRMWARE()
    macros in the 4xxx driver.
    
    Fixes: a3e8c919b993 ("crypto: qat - add support for 402xx devices")
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Reviewed-by: Damian Muszynski <damian.muszynski@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: x86/nh-avx2 - add missing vzeroupper [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Fri Apr 5 20:26:08 2024 -0400

    crypto: x86/nh-avx2 - add missing vzeroupper
    
    [ Upstream commit 4ad096cca942959871d8ff73826d30f81f856f6e ]
    
    Since nh_avx2() uses ymm registers, execute vzeroupper before returning
    from it.  This is necessary to avoid reducing the performance of SSE
    code.
    
    Fixes: 0f961f9f670e ("crypto: x86/nhpoly1305 - add AVX2 accelerated NHPoly1305")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: x86/sha256-avx2 - add missing vzeroupper [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Fri Apr 5 20:26:09 2024 -0400

    crypto: x86/sha256-avx2 - add missing vzeroupper
    
    [ Upstream commit 57ce8a4e162599cf9adafef1f29763160a8e5564 ]
    
    Since sha256_transform_rorx() uses ymm registers, execute vzeroupper
    before returning from it.  This is necessary to avoid reducing the
    performance of SSE code.
    
    Fixes: d34a460092d8 ("crypto: sha256 - Optimized sha256 x86_64 routine using AVX2's RORX instructions")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: x86/sha512-avx2 - add missing vzeroupper [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Fri Apr 5 20:26:10 2024 -0400

    crypto: x86/sha512-avx2 - add missing vzeroupper
    
    [ Upstream commit 6a24fdfe1edbafacdacd53516654d99068f20eec ]
    
    Since sha512_transform_rorx() uses ymm registers, execute vzeroupper
    before returning from it.  This is necessary to avoid reducing the
    performance of SSE code.
    
    Fixes: e01d69cb0195 ("crypto: sha512 - Optimized SHA512 x86_64 assembly routine using AVX instructions.")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/region: Fix cxlr_pmem leaks [+ + +]
Author: Li Zhijian <lizhijian@fujitsu.com>
Date:   Sun Apr 28 11:07:48 2024 +0800

    cxl/region: Fix cxlr_pmem leaks
    
    [ Upstream commit 1c987cf22d6b65ade46145c03eef13f0e3e81d83 ]
    
    Before this error path, cxlr_pmem pointed to a kzalloc() memory, free
    it to avoid this memory leaking.
    
    Fixes: f17b558d6663 ("cxl/pmem: Refactor nvdimm device registration, delete the workqueue")
    Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20240428030748.318985-1-lizhijian@fujitsu.com
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/trace: Correct DPA field masks for general_media & dram events [+ + +]
Author: Alison Schofield <alison.schofield@intel.com>
Date:   Tue Apr 30 10:28:03 2024 -0700

    cxl/trace: Correct DPA field masks for general_media & dram events
    
    [ Upstream commit 2042d11cb57b7e0cbda7910e5ff80e9e8bf0ae17 ]
    
    The length of Physical Address in General Media and DRAM event
    records is 64-bit, so the field mask for extracting the DPA should
    be 64-bit also, otherwise the trace event reports DPA's with the
    upper 32 bits of a DPA address masked off. If users do DPA-to-HPA
    translations this could lead to incorrect page retirement decisions.
    
    Use GENMASK_ULL() for CXL_DPA_MASK to get all the DPA address bits.
    
    Tidy up CXL_DPA_FLAGS_MASK by using GENMASK() to only mask the exact
    flag bits.
    
    These bits are defined as part of the event record physical address
    descriptions of General Media and DRAM events in CXL Spec 3.1
    Section 8.2.9.2 Events.
    
    Fixes: d54a531a430b ("cxl/mem: Trace General Media Event Record")
    Co-developed-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
    Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
    Signed-off-by: Alison Schofield <alison.schofield@intel.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/2867fc43c57720a4a15a3179431829b8dbd2dc16.1714496730.git.alison.schofield@intel.com
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dev_printk: Add and use dev_no_printk() [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Feb 28 15:00:03 2024 +0100

    dev_printk: Add and use dev_no_printk()
    
    [ Upstream commit c26ec799042a3888935d59b599f33e41efedf5f8 ]
    
    When printk-indexing is enabled, each dev_printk() invocation emits a
    pi_entry structure.  This is even true when the dev_printk() is
    protected by an always-false check, as is typically the case for debug
    messages: while the actual code to print the message is optimized out by
    the compiler, the pi_entry structure is still emitted.
    
    Avoid emitting pi_entry structures for unavailable dev_printk() kernel
    messages by:
      1. Introducing a dev_no_printk() helper, mimicked after the existing
         no_printk() helper, which calls _dev_printk() instead of
         dev_printk(),
      2. Replacing all "if (0) dev_printk(...)" constructs by calls to the
         new helper.
    
    This reduces the size of an arm64 defconfig kernel with
    CONFIG_PRINTK_INDEX=y by 957 KiB.
    
    Fixes: ad7d61f159db7397 ("printk: index: Add indexing support to dev_printk")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Chris Down <chris@chrisdown.name>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/8583d54f1687c801c6cda8edddf2cf0344c6e883.1709127473.git.geert+renesas@glider.be
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dlm: fix user space lock decision to copy lvb [+ + +]
Author: Alexander Aring <aahringo@redhat.com>
Date:   Thu Mar 28 11:48:33 2024 -0400

    dlm: fix user space lock decision to copy lvb
    
    [ Upstream commit ad191e0eeebf64a60ca2d16ca01a223d2b1dd25e ]
    
    This patch fixes the copy lvb decision for user space lock requests.
    Checking dlm_lvb_operations is done earlier, where granted/requested
    lock modes are available to use in the matrix.
    
    The decision had been moved to the wrong location, where granted mode
    and requested mode where the same, which causes the dlm_lvb_operations
    matix to produce the wrong copy decision. For PW or EX requests, the
    caller could get invalid lvb data.
    
    Fixes: 61bed0baa4db ("fs: dlm: use a non-static queue for callbacks")
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dma-buf/sw-sync: don't enable IRQ from sync_print_obj() [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Sun May 5 23:08:31 2024 +0900

    dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
    
    [ Upstream commit b794918961516f667b0c745aebdfebbb8a98df39 ]
    
    Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
    known context") by error replaced spin_unlock_irqrestore() with
    spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite
    sync_print_obj() is called from sync_debugfs_show(), lockdep complains
    inconsistent lock state warning.
    
    Use plain spin_{lock,unlock}() for sync_print_obj(), for
    sync_debugfs_show() is already using spin_{lock,unlock}_irq().
    
    Reported-by: syzbot <syzbot+a225ee3df7e7f9372dbe@syzkaller.appspotmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=a225ee3df7e7f9372dbe
    Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context")
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/c2e46020-aaa6-4e06-bf73-f05823f913f0@I-love.SAKURA.ne.jp
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dma-mapping: benchmark: fix node id validation [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Sat May 4 14:47:03 2024 +0300

    dma-mapping: benchmark: fix node id validation
    
    [ Upstream commit 1ff05e723f7ca30644b8ec3fb093f16312e408ad ]
    
    While validating node ids in map_benchmark_ioctl(), node_possible() may
    be provided with invalid argument outside of [0,MAX_NUMNODES-1] range
    leading to:
    
    BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)
    Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971
    CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
    Call Trace:
     <TASK>
    dump_stack_lvl (lib/dump_stack.c:117)
    kasan_report (mm/kasan/report.c:603)
    kasan_check_range (mm/kasan/generic.c:189)
    variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]
    arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]
    _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]
    node_state (include/linux/nodemask.h:423) [inline]
    map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)
    full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)
    __x64_sys_ioctl (fs/ioctl.c:890)
    do_syscall_64 (arch/x86/entry/common.c:83)
    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
    Compare node ids with sane bounds first. NUMA_NO_NODE is considered a
    special valid case meaning that benchmarking kthreads won't be bound to a
    cpuset of a given node.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs")
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dma-mapping: benchmark: fix up kthread-related error handling [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Sat May 4 14:47:01 2024 +0300

    dma-mapping: benchmark: fix up kthread-related error handling
    
    [ Upstream commit bb9025f4432f8c158322cf2c04c2b492f23eb511 ]
    
    kthread creation failure is invalidly handled inside do_map_benchmark().
    The put_task_struct() calls on the error path are supposed to balance the
    get_task_struct() calls which only happen after all the kthreads are
    successfully created. Rollback using kthread_stop() for already created
    kthreads in case of such failure.
    
    In normal situation call kthread_stop_put() to gracefully stop kthreads
    and put their task refcounts. This should be done for all started
    kthreads.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs")
    Suggested-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dma-mapping: benchmark: handle NUMA_NO_NODE correctly [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Sat May 4 14:47:04 2024 +0300

    dma-mapping: benchmark: handle NUMA_NO_NODE correctly
    
    [ Upstream commit e64746e74f717961250a155e14c156616fcd981f ]
    
    cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark()
    resulting in the following sanitizer report:
    
    UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28
    index -1 is out of range for type 'cpumask [64][1]'
    CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
    Call Trace:
     <TASK>
    dump_stack_lvl (lib/dump_stack.c:117)
    ubsan_epilogue (lib/ubsan.c:232)
    __ubsan_handle_out_of_bounds (lib/ubsan.c:429)
    cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline]
    do_map_benchmark (kernel/dma/map_benchmark.c:104)
    map_benchmark_ioctl (kernel/dma/map_benchmark.c:246)
    full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)
    __x64_sys_ioctl (fs/ioctl.c:890)
    do_syscall_64 (arch/x86/entry/common.c:83)
    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
    Use cpumask_of_node() in place when binding a kernel thread to a cpuset
    of a particular node.
    
    Note that the provided node id is checked inside map_benchmark_ioctl().
    It's just a NUMA_NO_NODE case which is not handled properly later.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs")
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Acked-by: Barry Song <baohua@kernel.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: idma64: Add check for dma_set_max_seg_size [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Wed Apr 3 02:49:32 2024 +0000

    dmaengine: idma64: Add check for dma_set_max_seg_size
    
    [ Upstream commit 2b1c1cf08a0addb6df42f16b37133dc7a351de29 ]
    
    As the possible failure of the dma_set_max_seg_size(), it should be
    better to check the return value of the dma_set_max_seg_size().
    
    Fixes: e3fdb1894cfa ("dmaengine: idma64: set maximum allowed segment size for DMA")
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20240403024932.3342606-1-nichen@iscas.ac.cn
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: idxd: Avoid unnecessary destruction of file_ida [+ + +]
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Mon Jan 29 17:39:54 2024 -0800

    dmaengine: idxd: Avoid unnecessary destruction of file_ida
    
    [ Upstream commit 76e43fa6a456787bad31b8d0daeabda27351a480 ]
    
    file_ida is allocated during cdev open and is freed accordingly
    during cdev release. This sequence is guaranteed by driver file
    operations. Therefore, there is no need to destroy an already empty
    file_ida when the WQ cdev is removed.
    
    Worse, ida_free() in cdev release may happen after destruction of
    file_ida per WQ cdev. This can lead to accessing an id in file_ida
    after it has been destroyed, resulting in a kernel panic.
    
    Remove ida_destroy(&file_ida) to address these issues.
    
    Fixes: e6fd6d7e5f0f ("dmaengine: idxd: add a device to represent the file opened")
    Signed-off-by: Lijun Pan <lijun.pan@intel.com>
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20240130013954.2024231-1-fenghua.yu@intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset() [+ + +]
Author: Hao Chen <chenhao418@huawei.com>
Date:   Thu Apr 25 20:46:27 2024 +0800

    drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()
    
    [ Upstream commit 582c1aeee0a9e73010cf1c4cef338709860deeb0 ]
    
    pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()
    fails, the irq vector is not freed, which leads to a memory leak.
    
    Replace the devm_add_action with devm_add_action_or_reset to ensure
    the irq vector can be destroyed when it fails.
    
    Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU")
    Signed-off-by: Hao Chen <chenhao418@huawei.com>
    Signed-off-by: Junhao He <hejunhao3@huawei.com>
    Reviewed-by: Jijie Shao <shaojijie@huawei.com>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20240425124627.13764-4-hejunhao3@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group [+ + +]
Author: Junhao He <hejunhao3@huawei.com>
Date:   Thu Apr 25 20:46:26 2024 +0800

    drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group
    
    [ Upstream commit 81bdd60a3d1d3b05e6cc6674845afb1694dd3a0e ]
    
    The perf tool allows users to create event groups through following
    cmd [1], but the driver does not check whether the array index is out
    of bounds when writing data to the event_group array. If the number of
    events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the
    memory write overflow of event_group array occurs.
    
    Add array index check to fix the possible array out of bounds violation,
    and return directly when write new events are written to array bounds.
    
    There are 9 different events in an event_group.
    [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}
    
    Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU")
    Signed-off-by: Junhao He <hejunhao3@huawei.com>
    Signed-off-by: Hao Chen <chenhao418@huawei.com>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Jijie Shao <shaojijie@huawei.com>
    Link: https://lore.kernel.org/r/20240425124627.13764-3-hejunhao3@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group [+ + +]
Author: Junhao He <hejunhao3@huawei.com>
Date:   Thu Apr 25 20:46:25 2024 +0800

    drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group
    
    [ Upstream commit 77fce82678ea5fd51442e62febec2004f79e041b ]
    
    The perf tool allows users to create event groups through following
    cmd [1], but the driver does not check whether the array index is out of
    bounds when writing data to the event_group array. If the number of events
    in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write
    overflow of event_group array occurs.
    
    Add array index check to fix the possible array out of bounds violation,
    and return directly when write new events are written to array bounds.
    
    There are 9 different events in an event_group.
    [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'
    
    Fixes: 8404b0fbc7fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU")
    Signed-off-by: Junhao He <hejunhao3@huawei.com>
    Reviewed-by: Jijie Shao <shaojijie@huawei.com>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Link: https://lore.kernel.org/r/20240425124627.13764-2-hejunhao3@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Wed Apr 10 17:55:25 2024 +0200

    drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()
    
    [ Upstream commit 3d6586008f7b638f91f3332602592caa8b00b559 ]
    
    Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes".
    
    Patch #1 fixes a bunch of issues I spotted in the acrn driver.  It
    compiles, that's all I know.  I'll appreciate some review and testing from
    acrn folks.
    
    Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding
    more sanity checks, and improving the documentation.  Gave it a quick test
    on x86-64 using VM_PAT that ends up using follow_pte().
    
    This patch (of 3):
    
    We currently miss handling various cases, resulting in a dangerous
    follow_pte() (previously follow_pfn()) usage.
    
    (1) We're not checking PTE write permissions.
    
    Maybe we should simply always require pte_write() like we do for
    pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for
    ACRN_MEM_ACCESS_WRITE for now.
    
    (2) We're not rejecting refcounted pages.
    
    As we are not using MMU notifiers, messing with refcounted pages is
    dangerous and can result in use-after-free. Let's make sure to reject them.
    
    (3) We are only looking at the first PTE of a bigger range.
    
    We only lookup a single PTE, but memmap->len may span a larger area.
    Let's loop over all involved PTEs and make sure the PFN range is
    actually contiguous. Reject everything else: it couldn't have worked
    either way, and rather made use access PFNs we shouldn't be accessing.
    
    Link: https://lkml.kernel.org/r/20240410155527.474777-1-david@redhat.com
    Link: https://lkml.kernel.org/r/20240410155527.474777-2-david@redhat.com
    Fixes: 8a6e85f75a83 ("virt: acrn: obtain pa from VMA with PFNMAP flag")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Cc: Alex Williamson <alex.williamson@redhat.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Fei Li <fei1.li@intel.com>
    Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
    Cc: Heiko Carstens <hca@linux.ibm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Yonghua Huang <yonghua.huang@intel.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/xen: Improve the late XenStore init protocol [+ + +]
Author: Henry Wang <xin.wang2@amd.com>
Date:   Fri May 17 09:15:16 2024 +0800

    drivers/xen: Improve the late XenStore init protocol
    
    [ Upstream commit a3607581cd49c17128a486a526a36a97bafcb2bb ]
    
    Currently, the late XenStore init protocol is only triggered properly
    for the case that HVM_PARAM_STORE_PFN is ~0ULL (invalid). For the
    case that XenStore interface is allocated but not ready (the connection
    status is not XENSTORE_CONNECTED), Linux should also wait until the
    XenStore is set up properly.
    
    Introduce a macro to describe the XenStore interface is ready, use
    it in xenbus_probe_initcall() to select the code path of doing the
    late XenStore init protocol or not. Since now we have more than one
    condition for XenStore late init, rework the check in xenbus_probe()
    for the free_irq().
    
    Take the opportunity to enhance the check of the allocated XenStore
    interface can be properly mapped, and return error early if the
    memremap() fails.
    
    Fixes: 5b3353949e89 ("xen: add support for initializing xenstore later as HVM domain")
    Signed-off-by: Henry Wang <xin.wang2@amd.com>
    Signed-off-by: Michal Orzel <michal.orzel@amd.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Link: https://lore.kernel.org/r/20240517011516.1451087-1-xin.wang2@amd.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Add dtbclk access to dcn315 [+ + +]
Author: Swapnil Patel <swapnil.patel@amd.com>
Date:   Tue Apr 2 21:07:46 2024 -0400

    drm/amd/display: Add dtbclk access to dcn315
    
    [ Upstream commit a01b64f31d65bdc917d1afb4cec9915beb6931be ]
    
    [Why & How]
    
    Currently DCN315 clk manager is missing code to enable/disable dtbclk.
    Because of this, "optimized_required" flag is constantly set
    and this prevents FreeSync from engaging for certain high bandwidth
    display Modes which require DTBCLK.
    
    Reviewed-by: Dmytro Laktyushkin <dmytro.laktyushkin@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Swapnil Patel <swapnil.patel@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/display: Add VCO speed parameter for DCN31 FPU [+ + +]
Author: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Date:   Thu Apr 18 11:19:03 2024 -0600

    drm/amd/display: Add VCO speed parameter for DCN31 FPU
    
    [ Upstream commit 0e62103bdcbc88281e16add299a946fb3bd02fbe ]
    
    Add VCO speed parameters in the bounding box array.
    
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@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/display: Allocate zero bw after bw alloc enable [+ + +]
Author: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com>
Date:   Wed Apr 10 10:46:35 2024 -0400

    drm/amd/display: Allocate zero bw after bw alloc enable
    
    [ Upstream commit 46fe9cb1a9e62f4e6229f48ae303ef8e6c1fdc64 ]
    
    [Why]
    During DP tunnel creation, CM preallocates BW and reduces
    estimated BW of other DPIA. CM release preallocation only
    when allocation is complete. Display mode validation logic
    validates timings based on bw available per host router.
    In multi display setup, this causes bw allocation failure
    when allocation greater than estimated bw.
    
    [How]
    Do zero alloc to make the CM to release preallocation and
    update estimated BW correctly for all DPIAs per host router.
    
    Reviewed-by: PeiChen Huang <peichen.huang@amd.com>
    Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram@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/display: Disable seamless boot on 128b/132b encoding [+ + +]
Author: Sung Joon Kim <sungjoon.kim@amd.com>
Date:   Thu Apr 18 16:59:36 2024 -0400

    drm/amd/display: Disable seamless boot on 128b/132b encoding
    
    [ Upstream commit 6f0c228ed9184287031a66b46a79e5a3d2e73a86 ]
    
    [why]
    preOS will not support display mode programming and link training
    for UHBR rates.
    
    [how]
    If we detect a sink that's UHBR capable, disable seamless boot
    
    Reviewed-by: Anthony Koo <anthony.koo@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Sung Joon Kim <sungjoon.kim@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/display: Enable colorspace property for MST connectors [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed May 8 16:45:35 2024 -0500

    drm/amd/display: Enable colorspace property for MST connectors
    
    [ Upstream commit 8195979d2dd995d60c2663adf54c69c1bf4eadd1 ]
    
    MST colorspace property support was disabled due to a series of warnings
    that came up when the device was plugged in since the properties weren't
    made at device creation. Create the properties in advance instead.
    
    Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Fixes: 69a959610229 ("drm/amd/display: Temporary Disable MST DP Colorspace Property").
    Reported-and-tested-by: Tyler Schneider <tyler.schneider@amd.com>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix DC mode screen flickering on DCN321 [+ + +]
Author: Leo Ma <hanghong.ma@amd.com>
Date:   Thu Apr 11 17:17:04 2024 -0400

    drm/amd/display: Fix DC mode screen flickering on DCN321
    
    [ Upstream commit ce649bd2d834db83ecc2756a362c9a1ec61658a5 ]
    
    [Why && How]
    Screen flickering saw on 4K@60 eDP with high refresh rate external
    monitor when booting up in DC mode. DC Mode Capping is disabled
    which caused wrong UCLK being used.
    
    Reviewed-by: Alvin Lee <alvin.lee2@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Leo Ma <hanghong.ma@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/display: Fix potential index out of bounds in color transformation function [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Mon Feb 26 18:38:08 2024 +0530

    drm/amd/display: Fix potential index out of bounds in color transformation function
    
    [ Upstream commit 63ae548f1054a0b71678d0349c7dc9628ddd42ca ]
    
    Fixes index out of bounds issue in the color transformation function.
    The issue could occur when the index 'i' exceeds the number of transfer
    function points (TRANSFER_FUNC_POINTS).
    
    The fix adds a check to ensure 'i' is within bounds before accessing the
    transfer function points. If 'i' is out of bounds, an error message is
    logged and the function returns false to indicate an error.
    
    Reported by smatch:
    drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
    drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
    drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max
    
    Fixes: b629596072e5 ("drm/amd/display: Build unity lut for shaper")
    Cc: Vitaly Prosyak <vitaly.prosyak@amd.com>
    Cc: Charlene Liu <Charlene.Liu@amd.com>
    Cc: Harry Wentland <harry.wentland@amd.com>
    Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Cc: Roman Li <roman.li@amd.com>
    Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Cc: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Reviewed-by: Tom Chung <chiahsuan.chung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Remove pixle rate limit for subvp [+ + +]
Author: Alvin Lee <alvin.lee2@amd.com>
Date:   Fri Feb 9 10:40:36 2024 -0500

    drm/amd/display: Remove pixle rate limit for subvp
    
    [ Upstream commit 340383c734f8a4e1663d26356b35fd8050851168 ]
    
    Subvp bugs related to 8K60 have been fixed, so remove the limit that
    blocks 8K60 timings from enabling SubVP.
    
    Reviewed-by: Nevenko Stupar <nevenko.stupar@amd.com>
    Reviewed-by: Chaitanya Dhere <chaitanya.dhere@amd.com>
    Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alvin Lee <alvin.lee2@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: cf8c498694a4 ("drm/amd/display: Revert Remove pixle rate limit for subvp")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Revert Remove pixle rate limit for subvp [+ + +]
Author: Wenjing Liu <wenjing.liu@amd.com>
Date:   Mon Mar 4 11:20:27 2024 -0500

    drm/amd/display: Revert Remove pixle rate limit for subvp
    
    [ Upstream commit cf8c498694a443e28dc1222f3ab94677114a4724 ]
    
    This reverts commit 340383c734f8 ("drm/amd/display: Remove pixle rate
    limit for subvp")
    
    [why]
    The original commit causes a regression when subvp is applied
    on ODM required 8k60hz timing. The display shows black screen
    on boot. The issue can be recovered with hotplug. It also causes
    MPO to fail. We will temprarily revert this commit and investigate
    the root cause further.
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Chaitanya Dhere <chaitanya.dhere@amd.com>
    Reviewed-by: Martin Leung <martin.leung@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Wenjing Liu <wenjing.liu@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/display: Set color_mgmt_changed to true on unsuspend [+ + +]
Author: Joshua Ashton <joshua@froggi.es>
Date:   Thu Nov 2 04:21:55 2023 +0000

    drm/amd/display: Set color_mgmt_changed to true on unsuspend
    
    [ Upstream commit 2eb9dd497a698dc384c0dd3e0311d541eb2e13dd ]
    
    Otherwise we can end up with a frame on unsuspend where color management
    is not applied when userspace has not committed themselves.
    
    Fixes re-applying color management on Steam Deck/Gamescope on S3 resume.
    
    Signed-off-by: Joshua Ashton <joshua@froggi.es>
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/pm: Restore config space after reset [+ + +]
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Fri Apr 12 13:11:14 2024 +0530

    drm/amd/pm: Restore config space after reset
    
    [ Upstream commit 30d1cda8ce31ab49051ff7159280c542a738b23d ]
    
    During mode-2 reset, pci config space registers are affected at device
    side. However, certain platforms have switches which assign virtual BAR
    addresses and returns the same even after device is reset. This
    affects pci_restore_state() as it doesn't issue another config write, if
    the value read is same as the saved value.
    
    Add a workaround to write saved config space values from driver side.
    Presently, these switches are in platforms with SMU v13.0.6 SOCs, hence
    restrict the workaround only to those.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Asad Kamal <asad.kamal@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/mes: fix use-after-free issue [+ + +]
Author: Jack Xiao <Jack.Xiao@amd.com>
Date:   Mon Apr 22 16:22:54 2024 +0800

    drm/amdgpu/mes: fix use-after-free issue
    
    [ Upstream commit 948255282074d9367e01908b3f5dcf8c10fc9c3d ]
    
    Delete fence fallback timer to fix the ramdom
    use-after-free issue.
    
    v2: move to amdgpu_mes.c
    
    Signed-off-by: Jack Xiao <Jack.Xiao@amd.com>
    Acked-by: Lijo Lazar <lijo.lazar@amd.com>
    Acked-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 buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode() [+ + +]
Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Date:   Thu Apr 25 11:22:32 2024 +0530

    drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode()
    
    [ Upstream commit acce6479e30f73ab0872e93a75aed1fb791d04ec ]
    
    The function gfx_v9_4_3_init_microcode in gfx_v9_4_3.c was generating
    about potential truncation of output when using the snprintf function.
    The issue was due to the size of the buffer 'ucode_prefix' being too
    small to accommodate the maximum possible length of the string being
    written into it.
    
    The string being written is "amdgpu/%s_mec.bin" or "amdgpu/%s_rlc.bin",
    where %s is replaced by the value of 'chip_name'. The length of this
    string without the %s is 16 characters. The warning message indicated
    that 'chip_name' could be up to 29 characters long, resulting in a total
    of 45 characters, which exceeds the buffer size of 30 characters.
    
    To resolve this issue, the size of the 'ucode_prefix' buffer has been
    reduced from 30 to 15. This ensures that the maximum possible length of
    the string being written into the buffer will not exceed its size, thus
    preventing potential buffer overflow and truncation issues.
    
    Fixes the below with gcc W=1:
    drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c: In function ‘gfx_v9_4_3_early_init’:
    drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=]
      379 |         snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name);
          |                                                    ^~
    ......
      439 |         r = gfx_v9_4_3_init_rlc_microcode(adev, ucode_prefix);
          |                                                 ~~~~~~~~~~~~
    drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30
      379 |         snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=]
      413 |         snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name);
          |                                                    ^~
    ......
      443 |         r = gfx_v9_4_3_init_cp_compute_microcode(adev, ucode_prefix);
          |                                                        ~~~~~~~~~~~~
    drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30
      413 |         snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fixes: 86301129698b ("drm/amdgpu: split gc v9_4_3 functionality from gc v9_0")
    Cc: Hawking Zhang <Hawking.Zhang@amd.com>
    Cc: Christian König <christian.koenig@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    Suggested-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Fix the ring buffer size for queue VM flush [+ + +]
Author: Prike Liang <Prike.Liang@amd.com>
Date:   Mon Mar 25 15:33:34 2024 +0800

    drm/amdgpu: Fix the ring buffer size for queue VM flush
    
    [ Upstream commit fe93b0927bc58cb1d64230f45744e527d9d8482c ]
    
    Here are the corrections needed for the queue ring buffer size
    calculation for the following cases:
    - Remove the KIQ VM flush ring usage.
    - Add the invalidate TLBs packet for gfx10 and gfx11 queue.
    - There's no VM flush and PFP sync, so remove the gfx9 real
      ring and compute ring buffer usage.
    
    Signed-off-by: Prike Liang <Prike.Liang@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 VRAM memory accounting [+ + +]
Author: Mukul Joshi <mukul.joshi@amd.com>
Date:   Tue Apr 23 14:40:37 2024 -0400

    drm/amdgpu: Fix VRAM memory accounting
    
    [ Upstream commit f06446ef23216090d1ee8ede1a7d7ae430c22dcc ]
    
    Subtract the VRAM pinned memory when checking for available memory
    in amdgpu_amdkfd_reserve_mem_limit function since that memory is not
    available for use.
    
    Signed-off-by: Mukul Joshi <mukul.joshi@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: init microcode chip name from ip versions [+ + +]
Author: Le Ma <le.ma@amd.com>
Date:   Wed Apr 17 17:57:52 2024 +0800

    drm/amdgpu: init microcode chip name from ip versions
    
    [ Upstream commit 92ed1e9cd5f6cc4f8c9a9ba6c4d2d2bbc6221296 ]
    
    To adapt to different gc versions in gfx_v9_4_3.c file.
    
    Signed-off-by: Le Ma <le.ma@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
    Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: acce6479e30f ("drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdgpu: Update BO eviction priorities [+ + +]
Author: Felix Kuehling <felix.kuehling@amd.com>
Date:   Thu Apr 18 13:56:42 2024 -0400

    drm/amdgpu: Update BO eviction priorities
    
    [ Upstream commit b0b13d532105e0e682d95214933bb8483a063184 ]
    
    Make SVM BOs more likely to get evicted than other BOs. These BOs
    opportunistically use available VRAM, but can fall back relatively
    seamlessly to system memory. It also avoids SVM migrations evicting
    other, more important BOs as they will evict other SVM allocations
    first.
    
    Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
    Acked-by: Mukul Joshi <mukul.joshi@amd.com>
    Tested-by: Mukul Joshi <mukul.joshi@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/amdkfd: Add VRAM accounting for SVM migration [+ + +]
Author: Mukul Joshi <mukul.joshi@amd.com>
Date:   Thu Apr 18 15:13:58 2024 -0400

    drm/amdkfd: Add VRAM accounting for SVM migration
    
    [ Upstream commit 1e214f7faaf5d842754cd5cfcd76308bfedab3b5 ]
    
    Do VRAM accounting when doing migrations to vram to make sure
    there is enough available VRAM and migrating to VRAM doesn't evict
    other possible non-unified memory BOs. If migrating to VRAM fails,
    driver can fall back to using system memory seamlessly.
    
    Signed-off-by: Mukul Joshi <mukul.joshi@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: Flush the process wq before creating a kfd_process [+ + +]
Author: Lancelot SIX <lancelot.six@amd.com>
Date:   Wed Apr 10 14:14:13 2024 +0100

    drm/amdkfd: Flush the process wq before creating a kfd_process
    
    [ Upstream commit f5b9053398e70a0c10aa9cb4dd5910ab6bc457c5 ]
    
    There is a race condition when re-creating a kfd_process for a process.
    This has been observed when a process under the debugger executes
    exec(3).  In this scenario:
    - The process executes exec.
     - This will eventually release the process's mm, which will cause the
       kfd_process object associated with the process to be freed
       (kfd_process_free_notifier decrements the reference count to the
       kfd_process to 0).  This causes kfd_process_ref_release to enqueue
       kfd_process_wq_release to the kfd_process_wq.
    - The debugger receives the PTRACE_EVENT_EXEC notification, and tries to
      re-enable AMDGPU traps (KFD_IOC_DBG_TRAP_ENABLE).
     - When handling this request, KFD tries to re-create a kfd_process.
       This eventually calls kfd_create_process and kobject_init_and_add.
    
    At this point the call to kobject_init_and_add can fail because the
    old kfd_process.kobj has not been freed yet by kfd_process_wq_release.
    
    This patch proposes to avoid this race by making sure to drain
    kfd_process_wq before creating a new kfd_process object.  This way, we
    know that any cleanup task is done executing when we reach
    kobject_init_and_add.
    
    Signed-off-by: Lancelot SIX <lancelot.six@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/arm/malidp: fix a possible null pointer dereference [+ + +]
Author: Huai-Yuan Liu <qq810974084@gmail.com>
Date:   Sun Apr 7 14:30:53 2024 +0800

    drm/arm/malidp: fix a possible null pointer dereference
    
    [ Upstream commit a1f95aede6285dba6dd036d907196f35ae3a11ea ]
    
    In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
    no check is performed. In order to prevent null pointer dereferencing,
    ensure that mw_state is checked before calling
    __drm_atomic_helper_connector_reset.
    
    Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector")
    Signed-off-by: Huai-Yuan Liu <qq810974084@gmail.com>
    Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240407063053.5481-1-qq810974084@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/bridge: anx7625: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Mon Apr 15 17:49:29 2024 -0400

    drm/bridge: anx7625: Don't log an error when DSI host can't be found
    
    [ Upstream commit ef4a9204d594fe959cdbc7418273caf4001535c8 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 269332997a16 ("drm/bridge: anx7625: Return -EPROBE_DEFER if the dsi host was not found")
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-1-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: anx7625: Update audio status while detecting [+ + +]
Author: Hsin-Te Yuan <yuanhsinte@chromium.org>
Date:   Tue Apr 16 07:21:35 2024 +0000

    drm/bridge: anx7625: Update audio status while detecting
    
    [ Upstream commit a665b4e60369867cddf50f37f16169a3e2f434ad ]
    
    Previously, the audio status was not updated during detection, leading
    to a persistent audio despite hot plugging events. To resolve this
    issue, update the audio status during detection.
    
    Fixes: 566fef1226c1 ("drm/bridge: anx7625: add HDMI audio function")
    Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240416-anx7625-v3-1-f916ae31bdd7@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: dpc3433: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Mon Apr 15 17:49:35 2024 -0400

    drm/bridge: dpc3433: Don't log an error when DSI host can't be found
    
    [ Upstream commit 24f4f575214de776539d346b99b8717bffa8ebba ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Also move the "failed to attach" error message so that it's only printed
    when the devm_mipi_dsi_attach() call fails.
    
    Fixes: 6352cd451ddb ("drm: bridge: Add TI DLPC3433 DSI to DMD bridge")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-7-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: Fix improper bridge init order with pre_enable_prev_first [+ + +]
Author: Jagan Teki <jagan@amarulasolutions.com>
Date:   Tue Mar 28 22:37:51 2023 +0530

    drm/bridge: Fix improper bridge init order with pre_enable_prev_first
    
    [ Upstream commit e18aeeda0b6905c333df5a0566b99f5c84426098 ]
    
    For a given bridge pipeline if any bridge sets pre_enable_prev_first
    flag then the pre_enable for the previous bridge will be called before
    pre_enable of this bridge and opposite is done for post_disable.
    
    These are the potential bridge flags to alter bridge init order in order
    to satisfy the MIPI DSI host and downstream panel or bridge to function.
    However the existing pre_enable_prev_first logic with associated bridge
    ordering has broken for both pre_enable and post_disable calls.
    
    [pre_enable]
    
    The altered bridge ordering has failed if two consecutive bridges on a
    given pipeline enables the pre_enable_prev_first flag.
    
    Example:
    - Panel
    - Bridge 1
    - Bridge 2 pre_enable_prev_first
    - Bridge 3
    - Bridge 4 pre_enable_prev_first
    - Bridge 5 pre_enable_prev_first
    - Bridge 6
    - Encoder
    
    In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first.
    
    The logic looks for a bridge which enabled pre_enable_prev_first flag
    on each iteration and assigned the previou bridge to limit pointer
    if the bridge doesn't enable pre_enable_prev_first flags.
    
    If control found Bridge 2 is pre_enable_prev_first then the iteration
    looks for Bridge 3 and found it is not pre_enable_prev_first and assigns
    it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3
    and Bridge 2 and assign iter pointer with limit which is Bridge 4.
    
    Here is the actual problem, for the next iteration control look for
    Bridge 5 instead of Bridge 4 has iter pointer in previous iteration
    moved to Bridge 4 so this iteration skips the Bridge 4. The iteration
    found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned
    to Encoder. From next iteration Encoder skips as it is the last bridge
    for reverse order pipeline.
    
    So, the resulting pre_enable bridge order would be,
    - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5.
    
    This patch fixes this by assigning limit to next pointer instead of
    previous bridge since the iteration always looks for bridge that does
    NOT request prev so assigning next makes sure the last bridge on a
    given iteration what exactly the limit bridge is.
    
    So, the resulting pre_enable bridge order with fix would be,
    - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4,
      Encoder.
    
    [post_disable]
    
    The altered bridge ordering has failed if two consecutive bridges on a
    given pipeline enables the pre_enable_prev_first flag.
    
    Example:
    - Panel
    - Bridge 1
    - Bridge 2 pre_enable_prev_first
    - Bridge 3
    - Bridge 4 pre_enable_prev_first
    - Bridge 5 pre_enable_prev_first
    - Bridge 6
    - Encoder
    
    In this example Bridge 5 and Bridge 4 have pre_enable_prev_first.
    
    The logic looks for a bridge which enabled pre_enable_prev_first flags
    on each iteration and assigned the previou bridge to next and next to
    limit pointer if the bridge does enable pre_enable_prev_first flag.
    
    If control starts from Bridge 6 then it found next Bridge 5 is
    pre_enable_prev_first and immediately the next assigned to previous
    Bridge 6 and limit assignments to next Bridge 6 and call post_enable
    of Bridge 6 even though the next consecutive Bridge 5 is enabled with
    pre_enable_prev_first. This clearly misses the logic to find the state
    of next conducive bridge as everytime the next and limit assigns
    previous bridge if given bridge enabled pre_enable_prev_first.
    
    So, the resulting post_disable bridge order would be,
    - Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1,
      Panel.
    
    This patch fixes this by assigning next with previou bridge only if the
    bridge doesn't enable pre_enable_prev_first flag and the next further
    assign it to limit. This way we can find the bridge that NOT requested
    prev to disable last.
    
    So, the resulting pre_enable bridge order with fix would be,
    - Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1,
      Panel.
    
    Validated the bridge init ordering by incorporating dummy bridges in
    the sun6i-mipi-dsi pipeline
    
    Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order")
    Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
    Tested-by: Michael Trimarchi <michael@amarulasolutions.com>
    Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230328170752.1102347-1-jagan@amarulasolutions.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: icn6211: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Mon Apr 15 17:49:30 2024 -0400

    drm/bridge: icn6211: Don't log an error when DSI host can't be found
    
    [ Upstream commit 275fafe58faa7fdb10fa245412696ecef676aac5 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 8dde6f7452a1 ("drm: bridge: icn6211: Add I2C configuration support")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-2-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: lt8912b: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Mon Apr 15 17:49:31 2024 -0400

    drm/bridge: lt8912b: Don't log an error when DSI host can't be found
    
    [ Upstream commit b3b4695ff47c4964d4ccb930890c9ffd8e455e20 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-3-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: lt9611: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Mon Apr 15 17:49:32 2024 -0400

    drm/bridge: lt9611: Don't log an error when DSI host can't be found
    
    [ Upstream commit cd0a2c6a081ff67007323725b9ff07d9934b1ed8 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-4-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Mon Apr 15 17:49:33 2024 -0400

    drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found
    
    [ Upstream commit 6d9e877cde7e9b516a9a99751b8222c87557436d ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-5-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358775: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Mon Apr 15 17:49:34 2024 -0400

    drm/bridge: tc358775: Don't log an error when DSI host can't be found
    
    [ Upstream commit 272377aa0e3dddeec3f568c8bb9d12c7a79d8ef5 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-6-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/bridge: tc358775: fix support for jeida-18 and jeida-24 [+ + +]
Author: Michael Walle <mwalle@kernel.org>
Date:   Sun Feb 25 08:19:33 2024 +0200

    drm/bridge: tc358775: fix support for jeida-18 and jeida-24
    
    [ Upstream commit 30ea09a182cb37c4921b9d477ed18107befe6d78 ]
    
    The bridge always uses 24bpp internally. Therefore, for jeida-18
    mapping we need to discard the lowest two bits for each channel and thus
    starting with LV_[RGB]2. jeida-24 has the same mapping but uses four
    lanes instead of three, with the forth pair transmitting the lowest two
    bits of each channel. Thus, the mapping between jeida-18 and jeida-24
    is actually the same, except that one channel is turned off (by
    selecting the RGB666 format in VPCTRL).
    
    While at it, remove the bogus comment about the hardware default because
    the default is overwritten in any case.
    
    Tested with a jeida-18 display (Evervision VGG644804).
    
    Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
    Signed-off-by: Michael Walle <mwalle@kernel.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240225062008.33191-5-tony@atomide.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/ci: add subset-1-gfx to LAVA_TAGS and adjust shards [+ + +]
Author: Helen Koike <helen.koike@collabora.com>
Date:   Mon Oct 23 21:45:21 2023 -0300

    drm/ci: add subset-1-gfx to LAVA_TAGS and adjust shards
    
    [ Upstream commit 68a3f17732d1d72be958576b6ce0e6c29686a40b ]
    
    The Collabora Lava farm added a tag called `subset-1-gfx` to half of
    devices the graphics community use.
    
    Lets use this tag so we don't occupy all the resources.
    
    This is particular important because Mesa3D shares the resources with
    DRM-CI and use them to do pre-merge tests, so it can block developers
    from getting their patches merged.
    
    Signed-off-by: Helen Koike <helen.koike@collabora.com>
    Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
    Link: https://lore.kernel.org/r/20231024004525.169002-7-helen.koike@collabora.com
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Stable-dep-of: a2c71b711e7e ("drm/ci: update device type for volteer devices")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/ci: update device type for volteer devices [+ + +]
Author: Vignesh Raman <vignesh.raman@collabora.com>
Date:   Thu Mar 7 07:48:41 2024 +0530

    drm/ci: update device type for volteer devices
    
    [ Upstream commit a2c71b711e7efc6478976233768bdbc3386e6dce ]
    
    Volteer devices in the collabora lab are categorized under the
    asus-cx9400-volteer device type. The majority of these units
    has an Intel Core i5-1130G7 CPU, while some of them have a
    Intel Core i7-1160G7 CPU instead. So due to this difference,
    new device type template is added for the Intel Core i5-1130G7
    and i7-1160G7 variants of the Acer Chromebook Spin 514 (CP514-2H)
    volteer Chromebooks. So update the same in drm-ci.
    
    https://gitlab.collabora.com/lava/lava/-/merge_requests/149
    
    Fixes: 0119c894ab0d ("drm: Add initial ci/ subdirectory")
    Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
    Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
    Acked-by: Helen Koike <helen.koike@collabora.com>
    Signed-off-by: Helen Koike <helen.koike@collabora.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240307021841.100561-1-vignesh.raman@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/ci: uprev mesa version: fix container build & crosvm [+ + +]
Author: Helen Koike <helen.koike@collabora.com>
Date:   Mon Oct 23 21:45:16 2023 -0300

    drm/ci: uprev mesa version: fix container build & crosvm
    
    [ Upstream commit 1887de00867d7a700babefc9647ccb9e0d11ee56 ]
    
    When building containers, some rust packages were installed without
    locking the dependencies version, which got updated and started giving
    errors like:
    
    error: failed to compile `bindgen-cli v0.62.0`, intermediate artifacts can be found at `/tmp/cargo-installkNKRwf`
    Caused by:
      package `rustix v0.38.13` cannot be built because it requires rustc 1.63 or newer, while the currently active rustc version is 1.60.0
    
    A patch to Mesa was added fixing this error, so update it.
    
    Also, commit in linux kernel 6.6 rc3 broke booting in crosvm.
    Mesa has upreved crosvm to fix this issue.
    
    Signed-off-by: Helen Koike <helen.koike@collabora.com>
    [crosvm mesa update]
    Co-Developed-by: Vignesh Raman <vignesh.raman@collabora.com>
    Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
    [v1 container build uprev]
    Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
    Link: https://lore.kernel.org/r/20231024004525.169002-2-helen.koike@collabora.com
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Stable-dep-of: a2c71b711e7e ("drm/ci: update device type for volteer devices")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/dp: Don't attempt AUX transfers when eDP panels are not powered [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Fri Feb 2 14:11:16 2024 -0800

    drm/dp: Don't attempt AUX transfers when eDP panels are not powered
    
    [ Upstream commit 8df1ddb5bf11ab820ad991e164dab82c0960add9 ]
    
    If an eDP panel is not powered on then any attempts to talk to it over
    the DP AUX channel will timeout. Unfortunately these attempts may be
    quite slow. Userspace can initiate these attempts either via a
    /dev/drm_dp_auxN device or via the created i2c device.
    
    Making the DP AUX drivers timeout faster is a difficult proposition.
    In theory we could just poll the panel's HPD line in the AUX transfer
    function and immediately return an error there. However, this is
    easier said than done. For one thing, there's no hard requirement to
    hook the HPD line up for eDP panels and it's OK to just delay a fixed
    amount. For another thing, the HPD line may not be fast to probe. On
    parade-ps8640 we need to wait for the bridge chip's firmware to boot
    before we can get the HPD line and this is a slow process.
    
    The fact that the transfers are taking so long to timeout is causing
    real problems. The open source fwupd daemon sometimes scans DP busses
    looking for devices whose firmware need updating. If it happens to
    scan while a panel is turned off this scan can take a long time. The
    fwupd daemon could try to be smarter and only scan when eDP panels are
    turned on, but we can also improve the behavior in the kernel.
    
    Let's let eDP panels drivers specify that a panel is turned off and
    then modify the common AUX transfer code not to attempt a transfer in
    this case.
    
    Tested-by: Steev Klimaszewski <steev@kali.org>
    Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org>
    Tested-by: Eizan Miyamoto <eizan@chromium.org>
    Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240202141109.1.I24277520ac754ea538c9b14578edc94e1df11b48@changeid
    Stable-dep-of: 5e842d55bad7 ("drm/panel: atna33xc20: Fix unbalanced regulator in the case HPD doesn't assert")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/edid: Parse topology block for all DispID structure v1.x [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Apr 10 21:01:39 2024 +0300

    drm/edid: Parse topology block for all DispID structure v1.x
    
    [ Upstream commit e0a200ab4b72afd581bd6f82fc1ef510a4fb5478 ]
    
    DisplayID spec v1.3 revision history notes do claim that
    the toplogy block was added in v1.3 so requiring structure
    v1.2 would seem correct, but there is at least one EDID in
    edid.tv with a topology block and structure v1.0. And
    there are also EDIDs with DisplayID structure v1.3 which
    seems to be totally incorrect as DisplayID spec v1.3 lists
    structure v1.2 as the only legal value.
    
    Unfortunately I couldn't find copies of DisplayID spec
    v1.0-v1.2 anywhere (even on vesa.org), so I'll have to
    go on empirical evidence alone.
    
    We used to parse the topology block on all v1.x
    structures until the check for structure v2.0 was added.
    Let's go back to doing that as the evidence does suggest
    that there are DisplayIDs in the wild that would miss
    out on the topology stuff otherwise.
    
    Also toss out DISPLAY_ID_STRUCTURE_VER_12 entirely as
    it doesn't appear we can really use it for anything.
    
    I *think* we could technically skip all the structure
    version checks as the block tags shouldn't conflict
    between v2.0 and v1.x. But no harm in having a bit of
    extra sanity checks I guess.
    
    So far I'm not aware of any user reported regressions
    from overly strict check, but I do know that it broke
    igt/kms_tiled_display's fake DisplayID as that one
    gets generated with structure v1.0.
    
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Fixes: c5a486af9df7 ("drm/edid: parse Tiled Display Topology Data Block for DisplayID 2.0")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240410180139.21352-1-ville.syrjala@linux.intel.com
    Acked-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/etnaviv: fix tx clock gating on some GC7000 variants [+ + +]
Author: Derek Foreman <derek.foreman@collabora.com>
Date:   Mon Mar 18 07:32:07 2024 -0500

    drm/etnaviv: fix tx clock gating on some GC7000 variants
    
    [ Upstream commit d7a5c9de99b3a9a43dce49f2084eb69b5f6a9752 ]
    
    commit 4bce244272513 ("drm/etnaviv: disable tx clock gating for GC7000
    rev6203") accidentally applied the fix for i.MX8MN errata ERR050226 to
    GC2000 instead of GC7000, failing to disable tx clock gating for GC7000
    rev 0x6023 as intended.
    
    Additional clean-up further propagated this issue, partially breaking
    the clock gating fixes added for GC7000 rev 6202 in commit 432f51e7deeda
    ("drm/etnaviv: add clock gating workaround for GC7000 r6202").
    
    Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/gt: Fix CCS id's calculation for CCS mode setting [+ + +]
Author: Andi Shyti <andi.shyti@linux.intel.com>
Date:   Fri May 17 11:06:16 2024 +0200

    drm/i915/gt: Fix CCS id's calculation for CCS mode setting
    
    [ Upstream commit ee01b6a386eaf9984b58a2476e8f531149679da9 ]
    
    The whole point of the previous fixes has been to change the CCS
    hardware configuration to generate only one stream available to
    the compute users. We did this by changing the info.engine_mask
    that is set during device probe, reset during the detection of
    the fused engines, and finally reset again when choosing the CCS
    mode.
    
    We can't use the engine_mask variable anymore, as with the
    current configuration, it imposes only one CCS no matter what the
    hardware configuration is.
    
    Before changing the engine_mask for the third time, save it and
    use it for calculating the CCS mode.
    
    After the previous changes, the user reported a performance drop
    to around 1/4. We have tested that the compute operations, with
    the current patch, have improved by the same factor.
    
    Fixes: 6db31251bb26 ("drm/i915/gt: Enable only one CCS for compute workload")
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Cc: Chris Wilson <chris.p.wilson@linux.intel.com>
    Cc: Gnattu OC <gnattuoc@me.com>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: Matt Roper <matthew.d.roper@intel.com>
    Tested-by: Jian Ye <jian.ye@intel.com>
    Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
    Tested-by: Gnattu OC <gnattuoc@me.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240517090616.242529-1-andi.shyti@linux.intel.com
    (cherry picked from commit a09d2327a9ba8e3f5be238bc1b7ca2809255b464)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/guc: avoid FIELD_PREP warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Apr 30 09:48:09 2024 -0700

    drm/i915/guc: avoid FIELD_PREP warning
    
    [ Upstream commit d4f36db62396b73bed383c0b6e48d36278cafa78 ]
    
    With gcc-7 and earlier, there are lots of warnings like
    
    In file included from <command-line>:0:0:
    In function '__guc_context_policy_add_priority.isra.66',
        inlined from '__guc_context_set_prio.isra.67' at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3292:3,
        inlined from 'guc_context_set_prio' at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3320:2:
    include/linux/compiler_types.h:399:38: error: call to '__compiletime_assert_631' declared with attribute error: FIELD_PREP: mask is not constant
      _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
                                          ^
    ...
    drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2422:3: note: in expansion of macro 'FIELD_PREP'
       FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \
       ^~~~~~~~~~
    
    Make sure that GUC_KLV_0_KEY is an unsigned value to avoid the warning.
    
    Fixes: 77b6f79df66e ("drm/i915/guc: Update to GuC version 69.0.3")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
    Signed-off-by: Julia Filipchuk <julia.filipchuk@intel.com>
    Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240430164809.482131-1-julia.filipchuk@intel.com
    (cherry picked from commit 364e039827ef628c650c21c1afe1c54d9c3296d9)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/lcdif: Do not disable clocks on already suspended hardware [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Mon Feb 26 09:26:27 2024 +0100

    drm/lcdif: Do not disable clocks on already suspended hardware
    
    [ Upstream commit 172695f145fb4798ab605e8a73f6e87711930124 ]
    
    In case the LCDIF is enabled in DT but unused, the clocks used by the
    LCDIF are not enabled. Those clocks may even have a use count of 0 in
    case there are no other users of those clocks. This can happen e.g. in
    case the LCDIF drives HDMI bridge which has no panel plugged into the
    HDMI connector.
    
    Do not attempt to disable clocks in the suspend callback and re-enable
    clocks in the resume callback unless the LCDIF is enabled and was in
    use before the system entered suspend, otherwise the driver might end
    up trying to disable clocks which are already disabled with use count
    0, and would trigger a warning from clock core about this condition.
    
    Note that the lcdif_rpm_suspend() and lcdif_rpm_resume() functions
    internally perform the clocks disable and enable operations and act
    as runtime PM hooks too.
    
    Reviewed-by: Liu Ying <victor.liu@nxp.com>
    Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240226082644.32603-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/mediatek: Add 0 size check to mtk_drm_gem_obj [+ + +]
Author: Justin Green <greenjustin@chromium.org>
Date:   Thu Mar 7 13:00:51 2024 -0500

    drm/mediatek: Add 0 size check to mtk_drm_gem_obj
    
    [ Upstream commit 1e4350095e8ab2577ee05f8c3b044e661b5af9a0 ]
    
    Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
    of 0 bytes. Currently, no such check exists and the kernel will panic if
    a userspace application attempts to allocate a 0x0 GBM buffer.
    
    Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
    verifying that we now return EINVAL.
    
    Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
    Signed-off-by: Justin Green <greenjustin@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: CK Hu <ck.hu@mediatek.com>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20240307180051.4104425-1-greenjustin@chromium.org/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/mediatek: dp: Fix mtk_dp_aux_transfer return value [+ + +]
Author: Wojciech Macek <wmacek@chromium.org>
Date:   Wed Apr 17 10:38:19 2024 +0000

    drm/mediatek: dp: Fix mtk_dp_aux_transfer return value
    
    [ Upstream commit 8431fff9e0f3fc1c5844cf99a73b49b63ceed481 ]
    
    In case there is no DP device attached to the port the
    transfer function should return IO error, similar to what
    other drivers do.
    In case EAGAIN is returned then any read from /dev/drm_dp_aux
    device ends up in an infinite loop as the upper layers
    constantly repeats the transfer request.
    
    Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
    Signed-off-by: Wojciech Macek <wmacek@chromium.org>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: CK Hu <ck.hu@mediatek.com>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/20240417103819.990512-1-wmacek@chromium.org/
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/meson: gate px_clk when setting rate [+ + +]
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Wed Apr 3 09:46:35 2024 +0200

    drm/meson: gate px_clk when setting rate
    
    [ Upstream commit 5c9837374ecf55a1fa3b7622d365a0456960270f ]
    
    Disable the px_clk when setting the rate to recover a fully
    configured and correctly reset VCLK clock tree after the rate
    is set.
    
    Fixes: 77d9e1e6b846 ("drm/meson: add support for MIPI-DSI transceiver")
    Reviewed-by: Nicolas Belin <nbelin@baylibre.com>
    Link: https://lore.kernel.org/r/20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-4-99ecdfdc87fc@linaro.org
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-4-99ecdfdc87fc@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/meson: vclk: fix calculation of 59.94 fractional rates [+ + +]
Author: Christian Hewitt <christianshewitt@gmail.com>
Date:   Tue Jan 9 23:07:04 2024 +0000

    drm/meson: vclk: fix calculation of 59.94 fractional rates
    
    [ Upstream commit bfbc68e4d8695497f858a45a142665e22a512ea3 ]
    
    Playing 4K media with 59.94 fractional rate (typically VP9) causes the screen to lose
    sync with the following error reported in the system log:
    
    [   89.610280] Fatal Error, invalid HDMI vclk freq 593406
    
    Modetest shows the following:
    
    3840x2160 59.94 3840 4016 4104 4400 2160 2168 2178 2250 593407 flags: xxxx, xxxx,
    drm calculated value -------------------------------------^
    
    Change the fractional rate calculation to stop DIV_ROUND_CLOSEST rounding down which
    results in vclk freq failing to match correctly.
    
    Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup")
    Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20240109230704.4120561-1-christianshewitt@gmail.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240109230704.4120561-1-christianshewitt@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/mipi-dsi: use correct return type for the DSC functions [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Mon Apr 8 02:53:51 2024 +0300

    drm/mipi-dsi: use correct return type for the DSC functions
    
    [ Upstream commit de1c705c50326acaceaf1f02bc5bf6f267c572bd ]
    
    The functions mipi_dsi_compression_mode() and
    mipi_dsi_picture_parameter_set() return 0-or-error rather than a buffer
    size. Follow example of other similar MIPI DSI functions and use int
    return type instead of size_t.
    
    Fixes: f4dea1aaa9a1 ("drm/dsi: add helpers for DSI compression mode and PPS packets")
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240408-lg-sw43408-panel-v5-2-4e092da22991@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Fri Apr 12 10:53:25 2024 +0200

    drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails
    
    [ Upstream commit 46d4efcccc688cbacdd70a238bedca510acaa8e4 ]
    
    Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer
    dereference on:
    
    msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);
    
    as gpu->pdev is only assigned in:
    
    a6xx_gpu_init()
    |_ adreno_gpu_init
        |_ msm_gpu_init()
    
    Instead of relying on handwavy null checks down the cleanup chain,
    explicitly de-allocate the LLC data and free a6xx_gpu instead.
    
    Fixes: 76efc2453d0e ("drm/msm/gpu: Fix crash during system suspend after unbind")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/588919/
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dp: allow voltage swing / pre emphasis of 3 [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sat Feb 3 15:47:25 2024 +0200

    drm/msm/dp: allow voltage swing / pre emphasis of 3
    
    [ Upstream commit 22578178e5dd6d3aa4490879df8b6c2977d980be ]
    
    Both dp_link_adjust_levels() and dp_ctrl_update_vx_px() limit swing and
    pre-emphasis to 2, while the real maximum value for the sum of the
    voltage swing and pre-emphasis is 3. Fix the DP code to remove this
    limitation.
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/577006/
    Link: https://lore.kernel.org/r/20240203-dp-swing-3-v1-1-6545e1706196@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connected [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Fri Mar 15 14:36:29 2024 -0700

    drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connected
    
    [ Upstream commit 5d1a7493343cc00d9019880b686e4e0a0f649531 ]
    
    As documented in the description of the transfer() function of
    "struct drm_dp_aux", the transfer() function can be called at any time
    regardless of the state of the DP port. Specifically if the kernel has
    the DP AUX character device enabled and userspace accesses
    "/dev/drm_dp_auxN" directly then the AUX transfer function will be
    called regardless of whether a DP device is connected.
    
    For eDP panels we have a special rule where we wait (with a 5 second
    timeout) for HPD to go high. This rule was important before all panels
    drivers were converted to call wait_hpd_asserted() and actually can be
    removed in a future commit.
    
    For external DP devices we never checked for HPD. That means that
    trying to access the DP AUX character device (AKA `hexdump -C
    /dev/drm_dp_auxN`) would very, very slowly timeout. Specifically on my
    system:
      $ time hexdump -C /dev/drm_dp_aux0
      hexdump: /dev/drm_dp_aux0: Connection timed out
      real    0m8.200s
    We want access to the drm_dp_auxN character device to fail faster than
    8 seconds when no DP cable is plugged in.
    
    Let's add a test to make transfers fail right away if a device isn't
    plugged in. Rather than testing the HPD line directly, we have the
    dp_display module tell us when AUX transfers should be enabled so we
    can handle cases where HPD is signaled out of band like with Type C.
    
    Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/583127/
    Link: https://lore.kernel.org/r/20240315143621.v2.1.I16aff881c9fe82b5e0fc06ca312da017aa7b5b3e@changeid
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dpu: Add callback function pointer check before its call [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Mon Apr 8 11:55:23 2024 +0300

    drm/msm/dpu: Add callback function pointer check before its call
    
    [ Upstream commit 530f272053a5e72243a9cb07bb1296af6c346002 ]
    
    In dpu_core_irq_callback_handler() callback function pointer is compared to NULL,
    but then callback function is unconditionally called by this pointer.
    Fix this bug by adding conditional return.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: c929ac60b3ed ("drm/msm/dpu: allow just single IRQ callback")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/588237/
    Link: https://lore.kernel.org/r/20240408085523.12231-1-amishin@t-argos.ru
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: add helper to get IRQ-related data [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Aug 2 13:04:22 2023 +0300

    drm/msm/dpu: add helper to get IRQ-related data
    
    [ Upstream commit ea4842ed62f3556cf0a90f19d911ee03a4d0c844 ]
    
    In preparation to reworking IRQ indices, move irq_tbl access to
    a separate helper.
    
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/550931/
    Link: https://lore.kernel.org/r/20230802100426.4184892-5-dmitry.baryshkov@linaro.org
    Stable-dep-of: 530f272053a5 ("drm/msm/dpu: Add callback function pointer check before its call")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: Always flush the slave INTF on the CTL [+ + +]
Author: Marijn Suijten <marijn.suijten@somainline.org>
Date:   Wed Apr 17 01:57:43 2024 +0200

    drm/msm/dpu: Always flush the slave INTF on the CTL
    
    [ Upstream commit 2b938c3ab0a69ec6ea587bbf6fc2aec3db4a8736 ]
    
    As we can clearly see in a downstream kernel [1], flushing the slave INTF
    is skipped /only if/ the PPSPLIT topology is active.
    
    However, when DPU was originally submitted to mainline PPSPLIT was no
    longer part of it (seems to have been ripped out before submission), but
    this clause was incorrectly ported from the original SDE driver.  Given
    that there is no support for PPSPLIT (currently), flushing the slave
    INTF should /never/ be skipped (as the `if (ppsplit && !master) goto
    skip;` clause downstream never becomes true).
    
    [1]: https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/display-kernel.lnx.5.4.r1-rel/msm/sde/sde_encoder_phys_cmd.c?ref_type=heads#L1131-1139
    
    Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
    Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/589901/
    Link: https://lore.kernel.org/r/20240417-drm-msm-initial-dualpipe-dsc-fixes-v1-3-78ae3ee9a697@somainline.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: extract dpu_core_irq_is_valid() helper [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Aug 2 13:04:21 2023 +0300

    drm/msm/dpu: extract dpu_core_irq_is_valid() helper
    
    [ Upstream commit a65264833690d1280b901e3fe8e2825a44b3502c ]
    
    In preparation to reworking IRQ indices, move irq_idx validation to
    a separate helper.
    
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/550929/
    Link: https://lore.kernel.org/r/20230802100426.4184892-4-dmitry.baryshkov@linaro.org
    Stable-dep-of: 530f272053a5 ("drm/msm/dpu: Add callback function pointer check before its call")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: make error messages at dpu_core_irq_register_callback() more sensible [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Sat Mar 30 05:53:22 2024 +0200

    drm/msm/dpu: make error messages at dpu_core_irq_register_callback() more sensible
    
    commit 8844f467d6a58dc915f241e81c46e0c126f8c070 upstream.
    
    There is little point in using %ps to print a value known to be NULL. On
    the other hand it makes sense to print the callback symbol in the
    'invalid IRQ' message. Correct those two error messages to make more
    sense.
    
    Fixes: 6893199183f8 ("drm/msm/dpu: stop using raw IRQ indices in the kernel output")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/585565/
    Link: https://lore.kernel.org/r/20240330-dpu-irq-messages-v1-1-9ce782ae35f9@linaro.org
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/msm/dpu: make the irq table size static [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Aug 2 13:04:23 2023 +0300

    drm/msm/dpu: make the irq table size static
    
    [ Upstream commit 56acb1b620e263d3fed8f11f71bf2ab7ce1cae5b ]
    
    The size of the irq table is static, it has MDP_INTR_MAX * 32 interrupt
    entries. Provide the fixed length and drop struct_size() statement.
    
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/550927/
    Link: https://lore.kernel.org/r/20230802100426.4184892-6-dmitry.baryshkov@linaro.org
    Stable-dep-of: 530f272053a5 ("drm/msm/dpu: Add callback function pointer check before its call")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: remove irq_idx argument from IRQ callbacks [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Aug 2 13:04:20 2023 +0300

    drm/msm/dpu: remove irq_idx argument from IRQ callbacks
    
    [ Upstream commit e75e45c25b66ae9a78fa2476df0bf99ad80f33f9 ]
    
    There is no point in passing the IRQ index to IRQ callbacks, no function
    uses that. Drop it at last.
    
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/550925/
    Link: https://lore.kernel.org/r/20230802100426.4184892-3-dmitry.baryshkov@linaro.org
    Stable-dep-of: 530f272053a5 ("drm/msm/dpu: Add callback function pointer check before its call")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: stop using raw IRQ indices in the kernel output [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed Aug 2 13:04:24 2023 +0300

    drm/msm/dpu: stop using raw IRQ indices in the kernel output
    
    [ Upstream commit 6893199183f836e1ff452082f0f9d068364b2f17 ]
    
    In preparation to reworking IRQ indcies, stop using raw IRQ indices in
    kernel output (both printk and debugfs). Instead use a pair of register
    index and bit. This corresponds closer to the values in HW catalog.
    
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Patchwork: https://patchwork.freedesktop.org/patch/550933/
    Link: https://lore.kernel.org/r/20230802100426.4184892-7-dmitry.baryshkov@linaro.org
    Stable-dep-of: 530f272053a5 ("drm/msm/dpu: Add callback function pointer check before its call")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk [+ + +]
Author: Marijn Suijten <marijn.suijten@somainline.org>
Date:   Wed Apr 17 01:57:41 2024 +0200

    drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk
    
    [ Upstream commit f12e0e12524a34bf145f7b80122e653ffe3d130a ]
    
    When dual-DSI (bonded DSI) was added in commit ed9976a09b48
    ("drm/msm/dsi: adjust dsi timing for dual dsi mode") some DBG() prints
    were not updated, leading to print the original mode->clock rather
    than the adjusted (typically the mode clock divided by two, though more
    recently also adjusted for DSC compression) msm_host->pixel_clk_rate
    which is passed to clk_set_rate() just below.  Fix that by printing the
    actual pixel_clk_rate that is being set.
    
    Fixes: ed9976a09b48 ("drm/msm/dsi: adjust dsi timing for dual dsi mode")
    Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Patchwork: https://patchwork.freedesktop.org/patch/589896/
    Link: https://lore.kernel.org/r/20240417-drm-msm-initial-dualpipe-dsc-fixes-v1-1-78ae3ee9a697@somainline.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations [+ + +]
Author: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Date:   Thu May 9 23:43:52 2024 +0300

    drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
    
    [ Upstream commit aed9a1a4f7106ff99a882ad06318cebfa71016a2 ]
    
    Allow PTE kind and tile mode on BO create with VM_BIND, and add a
    GETPARAM to indicate this change. This is needed to support modifiers in
    NVK and ensure correctness when dealing with the nouveau GL driver.
    
    The userspace modifiers implementation this is for can be found here:
    https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795
    
    Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI")
    Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
    Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240509204352.7597-1-mohamedahmedegypt2001@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/omapdrm: Fix console by implementing fb_dirty [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Feb 28 08:35:31 2024 +0200

    drm/omapdrm: Fix console by implementing fb_dirty
    
    [ Upstream commit 632bac50544c0929ced9eed41e7d04c08adecbb0 ]
    
    The framebuffer console stopped updating with commit f231af498c29
    ("drm/fb-helper: Disconnect damage worker from update logic").
    
    Let's fix the issue by implementing fb_dirty similar to what was done
    with commit 039a72ce7e57 ("drm/i915/fbdev: Implement fb_dirty for intel
    custom fb helper").
    
    Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic")
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240228063540.4444-2-tony@atomide.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/omapdrm: Fix console with deferred ops [+ + +]
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Feb 28 08:35:32 2024 +0200

    drm/omapdrm: Fix console with deferred ops
    
    [ Upstream commit 01c0cce88c5480cc2505b79330246ef12eda938f ]
    
    Commit 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
    stopped console from updating for command mode displays because there is
    no damage handling in fb_sys_write() unlike we had earlier in
    drm_fb_helper_sys_write().
    
    Let's fix the issue by adding FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS and
    FB_DMAMEM_HELPERS_DEFERRED as suggested by Thomas. We cannot use the
    FB_DEFAULT_DEFERRED_OPS as fb_deferred_io_mmap() won't work properly
    for write-combine.
    
    Fixes: 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
    Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240228063540.4444-3-tony@atomide.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panel: atna33xc20: Fix unbalanced regulator in the case HPD doesn't assert [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Wed Mar 13 14:12:14 2024 -0700

    drm/panel: atna33xc20: Fix unbalanced regulator in the case HPD doesn't assert
    
    [ Upstream commit 5e842d55bad7794823a50f24fd645b58f2ef93ab ]
    
    When the atna33xc20 driver was first written the resume code never
    returned an error. If there was a problem waiting for HPD it just
    printed a warning and moved on. This changed in response to review
    feedback [1] on a future patch but I accidentally didn't account for
    rolling back the regulator enable in the error cases. Do so now.
    
    [1] https://lore.kernel.org/all/5f3cf3a6-1cc2-63e4-f76b-4ee686764705@linaro.org/
    
    Fixes: 3b5765df375c ("drm/panel: atna33xc20: Take advantage of wait_hpd_asserted() in struct drm_dp_aux")
    Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240313-homestarpanel-regulator-v1-1-b8e3a336da12@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Date:   Mon Apr 15 17:49:36 2024 -0400

    drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found
    
    [ Upstream commit 5ff5505b9a2d827cae3f95dceba258c963138175 ]
    
    Given that failing to find a DSI host causes the driver to defer probe,
    make use of dev_err_probe() to log the reason. This makes the defer
    probe reason available and avoids alerting userspace about something
    that is not necessarily an error.
    
    Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC panels")
    Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-8-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/panel: simple: Add missing Innolux G121X1-L03 format, flags, connector [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Thu Mar 28 11:27:36 2024 +0100

    drm/panel: simple: Add missing Innolux G121X1-L03 format, flags, connector
    
    [ Upstream commit 11ac72d033b9f577e8ba0c7a41d1c312bb232593 ]
    
    The .bpc = 6 implies .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG ,
    add the missing bus_format. Add missing connector type and bus_flags
    as well.
    
    Documentation [1] 1.4 GENERAL SPECIFICATI0NS indicates this panel is
    capable of both RGB 18bit/24bit panel, the current configuration uses
    18bit mode, .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG , .bpc = 6.
    
    Support for the 24bit mode would require another entry in panel-simple
    with .bus_format = MEDIA_BUS_FMT_RGB666_1X7X4_SPWG and .bpc = 8, which
    is out of scope of this fix.
    
    [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
    
    Fixes: f8fa17ba812b ("drm/panel: simple: Add support for Innolux G121X1-L03")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240328102746.17868-2-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/panel: sitronix-st7789v: fix display size for jt240mhqs_hwt_ek_e3 panel [+ + +]
Author: Gerald Loacker <gerald.loacker@wolfvision.net>
Date:   Wed May 29 16:42:47 2024 +0200

    drm/panel: sitronix-st7789v: fix display size for jt240mhqs_hwt_ek_e3 panel
    
    [ Upstream commit b62c150c3bae72ac1910dcc588f360159eb0744a ]
    
    This is a portrait mode display. Change the dimensions accordingly.
    
    Fixes: 0fbbe96bfa08 ("drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support")
    Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
    Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Link: https://lore.kernel.org/r/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-3-e4821802443d@wolfvision.net
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-3-e4821802443d@wolfvision.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/panel: sitronix-st7789v: fix timing for jt240mhqs_hwt_ek_e3 panel [+ + +]
Author: Gerald Loacker <gerald.loacker@wolfvision.net>
Date:   Wed May 29 16:42:45 2024 +0200

    drm/panel: sitronix-st7789v: fix timing for jt240mhqs_hwt_ek_e3 panel
    
    [ Upstream commit 0e5895ff7fab0fc05ec17daf9a568368828fa6ea ]
    
    Flickering was observed when using partial mode. Moving the vsync to the
    same position as used by the default sitronix-st7789v timing resolves this
    issue.
    
    Fixes: 0fbbe96bfa08 ("drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support")
    Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
    Link: https://lore.kernel.org/r/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-1-e4821802443d@wolfvision.net
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-1-e4821802443d@wolfvision.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/panel: sitronix-st7789v: tweak timing for jt240mhqs_hwt_ek_e3 panel [+ + +]
Author: Gerald Loacker <gerald.loacker@wolfvision.net>
Date:   Wed May 29 16:42:46 2024 +0200

    drm/panel: sitronix-st7789v: tweak timing for jt240mhqs_hwt_ek_e3 panel
    
    [ Upstream commit 2ba50582634d0bfe3a333ab7575a7f0122a7cde8 ]
    
    Use the default timing parameters to get a refresh rate of about 60 Hz for
    a clock of 6 MHz.
    
    Fixes: 0fbbe96bfa08 ("drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support")
    Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
    Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Link: https://lore.kernel.org/r/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-2-e4821802443d@wolfvision.net
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-2-e4821802443d@wolfvision.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/rockchip: vop2: Do not divide height twice for YUV [+ + +]
Author: Detlev Casanova <detlev.casanova@collabora.com>
Date:   Sun Apr 14 14:27:06 2024 -0400

    drm/rockchip: vop2: Do not divide height twice for YUV
    
    [ Upstream commit e80c219f52861e756181d7f88b0d341116daac2b ]
    
    For the cbcr format, gt2 and gt4 are computed again after src_h has been
    divided by vsub.
    
    As src_h as already been divided by 2 before, introduce cbcr_src_h and
    cbcr_src_w to keep a copy of those values to be used for cbcr gt2 and
    gt4 computation.
    
    This fixes yuv planes being unaligned vertically when down scaling to
    1080 pixels from 2160.
    
    Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
    Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
    Acked-by: Andy Yan <andy.yan@rock-chips.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240414182706.655270-1-detlev.casanova@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Mon Apr 8 15:58:10 2024 +0300

    drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
    
    [ Upstream commit 935a92a1c400285545198ca2800a4c6c519c650a ]
    
    In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
    assigned to mhdp_state->current_mode, and there is a dereference of it in
    drm_mode_set_name(), which will lead to a NULL pointer dereference on
    failure of drm_mode_duplicate().
    
    Fix this bug add a check of mhdp_state->current_mode.
    
    Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Reviewed-by: Robert Foss <rfoss@kernel.org>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240408125810.21899-1-amishin@t-argos.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: vc4: Fix possible null pointer dereference [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Tue Apr 9 10:56:22 2024 +0300

    drm: vc4: Fix possible null pointer dereference
    
    [ Upstream commit c534b63bede6cb987c2946ed4d0b0013a52c5ba7 ]
    
    In vc4_hdmi_audio_init() of_get_address() may return
    NULL which is later dereferenced. Fix this bug by adding NULL check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240409075622.11783-1-amishin@t-argos.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm: zynqmp_dpsub: Always register bridge [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Fri Mar 8 15:47:41 2024 -0500

    drm: zynqmp_dpsub: Always register bridge
    
    [ Upstream commit be3f3042391d061cfca2bd22630e0d101acea5fc ]
    
    We must always register the DRM bridge, since zynqmp_dp_hpd_work_func
    calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be
    initialized. We do this before zynqmp_dpsub_drm_init since that calls
    drm_bridge_attach. This fixes the following lockdep warning:
    
    [   19.217084] ------------[ cut here ]------------
    [   19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
    [   19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550
    [   19.241696] Modules linked in:
    [   19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96
    [   19.252046] Hardware name: xlnx,zynqmp (DT)
    [   19.256421] Workqueue: events zynqmp_dp_hpd_work_func
    [   19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [   19.269104] pc : __mutex_lock+0x4bc/0x550
    [   19.273364] lr : __mutex_lock+0x4bc/0x550
    [   19.277592] sp : ffffffc085c5bbe0
    [   19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8
    [   19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000
    [   19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000
    [   19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000
    [   19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720
    [   19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001
    [   19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888
    [   19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000
    [   19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000
    [   19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880
    [   19.356581] Call trace:
    [   19.359160]  __mutex_lock+0x4bc/0x550
    [   19.363032]  mutex_lock_nested+0x24/0x30
    [   19.367187]  drm_bridge_hpd_notify+0x2c/0x6c
    [   19.371698]  zynqmp_dp_hpd_work_func+0x44/0x54
    [   19.376364]  process_one_work+0x3ac/0x988
    [   19.380660]  worker_thread+0x398/0x694
    [   19.384736]  kthread+0x1bc/0x1c0
    [   19.388241]  ret_from_fork+0x10/0x20
    [   19.392031] irq event stamp: 183
    [   19.395450] hardirqs last  enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4
    [   19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04
    [   19.413612] softirqs last  enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c
    [   19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c
    [   19.432614] ---[ end trace 0000000000000000 ]---
    
    Fixes: eb2d64bfcc17 ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge")
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240308204741.3631919-1-sean.anderson@linux.dev
    (cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dt-bindings: adc: axi-adc: add clocks property [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Fri Apr 26 17:42:12 2024 +0200

    dt-bindings: adc: axi-adc: add clocks property
    
    [ Upstream commit 19fb11d7220b8abc016aa254dc7e6d9f2d49b178 ]
    
    Add a required clock property as we can't access the device registers if
    the AXI bus clock is not properly enabled.
    
    Note this clock is a very fundamental one that is typically enabled
    pretty early during boot. Independently of that, we should really rely on
    it to be enabled.
    
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Fixes: 96553a44e96d ("dt-bindings: iio: adc: add bindings doc for AXI ADC driver")
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-3-6361fc3ba1cc@analog.com
    Cc: <Stable@ver.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: adc: axi-adc: update bindings for backend framework [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Sat Feb 10 21:57:14 2024 +0100

    dt-bindings: adc: axi-adc: update bindings for backend framework
    
    [ Upstream commit a032b921bdeba2274866daafc8e791edd609eb13 ]
    
    'adi,adc-dev' is now deprecated and must not be used anymore. Hence,
    also remove it from being required.
    
    The reason why it's being deprecated is because the axi-adc CORE is now
    an IIO service provider hardware (IIO backends) for consumers to make use
    of. Before, the logic with 'adi,adc-dev' was the opposite (it was kind
    of consumer referencing other nodes/devices) and that proved to be wrong
    and to not scale.
    
    Now, IIO consumers of this hardware are expected to reference it using the
    io-backends property. Hence, the new '#io-backend-cells' is being added
    so the device is easily identified as a provider.
    
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240210-iio-backend-v11-2-f5242a5fb42a@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 19fb11d7220b ("dt-bindings: adc: axi-adc: add clocks property")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: PCI: rcar-pci-host: Add missing IOMMU properties [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Feb 1 16:52:01 2024 +0100

    dt-bindings: PCI: rcar-pci-host: Add missing IOMMU properties
    
    [ Upstream commit 78d212851f0e56b7d7083c4d5014aa7fa8b77e20 ]
    
    make dtbs_check:
    
        arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb: pcie@fe000000: Unevaluated properties are not allowed ('iommu-map', 'iommu-map-mask' were unexpected)
                from schema $id: http://devicetree.org/schemas/pci/rcar-pci-host.yaml#
    
    Fix this by adding the missing IOMMU-related properties.
    
    [kwilczynski: added missing Fixes: tag]
    Fixes: 0d69ce3c2c63 ("dt-bindings: PCI: rcar-pci-host: Convert bindings to json-schema")
    Link: https://lore.kernel.org/linux-pci/babc878a93cb6461a5d39331f8ecfa654dfda921.1706802597.git.geert+renesas@glider.be
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Acked-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: PCI: rcar-pci-host: Add optional regulators [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Sun Nov 5 10:29:07 2023 +0100

    dt-bindings: PCI: rcar-pci-host: Add optional regulators
    
    [ Upstream commit b952f96a57e6fb4528c1d6be19e941c3322f9905 ]
    
    Support regulators found on the KingFisher board for miniPCIe (1.5 and
    3.3v). For completeness, describe a 12v regulator while we are here.
    
    Link: https://lore.kernel.org/linux-pci/20231105092908.3792-2-wsa+renesas@sang-engineering.com
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Stable-dep-of: 78d212851f0e ("dt-bindings: PCI: rcar-pci-host: Add missing IOMMU properties")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: PCI: rockchip,rk3399-pcie: Add missing maxItems to ep-gpios [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Apr 1 12:00:58 2024 +0200

    dt-bindings: PCI: rockchip,rk3399-pcie: Add missing maxItems to ep-gpios
    
    [ Upstream commit 52d06636a4ae4db24ebfe23fae7a525f7e983604 ]
    
    Properties with GPIOs should define number of actual GPIOs, so add
    missing maxItems to ep-gpios.  Otherwise multiple GPIOs could be
    provided which is not a true hardware description.
    
    Fixes: aa222f9311e1 ("dt-bindings: PCI: Convert Rockchip RK3399 PCIe to DT schema")
    Link: https://lore.kernel.org/linux-pci/20240401100058.15749-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Acked-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: fix msm899[68] power-domains [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed May 1 19:19:28 2024 +0300

    dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: fix msm899[68] power-domains
    
    [ Upstream commit 59e377a124dc9039d9554d823b1cb4942bcee9a0 ]
    
    The Qualcomm MSM8996 and MSM8998 platforms don't have separate power
    domain for the UFS PHY. Replace required:power-domains with the
    conditional schema.
    
    Fixes: dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-2-f1fd15c33fb3@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: phy: qcom,usb-snps-femto-v2: use correct fallback for sc8180x [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Wed May 1 19:19:29 2024 +0300

    dt-bindings: phy: qcom,usb-snps-femto-v2: use correct fallback for sc8180x
    
    [ Upstream commit 960b3f023d3bda0efd6e573a0647227d1115d266 ]
    
    The qcom,sc8180x-usb-hs-phy device uses qcom,usb-snps-hs-7nm-phy
    fallback. Correct the schema for this platform.
    
    Fixes: 9160fb7c39a1 ("dt-bindings: phy: qcom,usb-snps-femto-v2: use fallback compatibles")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-3-f1fd15c33fb3@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: pinctrl: mediatek: mt7622: fix array properties [+ + +]
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Tue Apr 23 06:55:01 2024 +0200

    dt-bindings: pinctrl: mediatek: mt7622: fix array properties
    
    [ Upstream commit 61fcbbf3ca038c048c942ce31bb3d3c846c87581 ]
    
    Some properties (function groups & pins) are meant to be arrays and
    should allow multiple entries out of enum sets. Use "items" for those.
    
    Mistake was noticed during validation of in-kernel DTS files.
    
    Fixes: b9ffc18c6388 ("dt-bindings: mediatek: convert pinctrl to yaml")
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Acked-by: Rob Herring <robh@kernel.org>
    Message-ID: <20240423045502.7778-1-zajec5@gmail.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: rockchip: grf: Add missing type to 'pcie-phy' node [+ + +]
Author: Rob Herring <robh@kernel.org>
Date:   Mon Apr 1 15:49:58 2024 -0500

    dt-bindings: rockchip: grf: Add missing type to 'pcie-phy' node
    
    [ Upstream commit d41201c90f825f19a46afbfb502f22f612d8ccc4 ]
    
    'pcie-phy' is missing any type. Add 'type: object' to indicate it's a
    node.
    
    Signed-off-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Acked-by: Conor Dooley <conor.dooley@microchip.com>
    Link: https://lore.kernel.org/r/20240401204959.1698106-1-robh@kernel.org
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: spmi: hisilicon,hisi-spmi-controller: fix binding references [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Tue May 7 14:07:39 2024 -0700

    dt-bindings: spmi: hisilicon,hisi-spmi-controller: fix binding references
    
    [ Upstream commit c6c1b27f9a9a20ad2db663628fccaed72c6a0f1f ]
    
    Fix up the free text binding references which were not updated when
    moving the bindings out of staging and which had a leading current
    directory component, respectively.
    
    Fixes: 9bd9e0de1cf5 ("mfd: hi6421-spmi-pmic: move driver from staging")
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20231130173757.13011-2-johan+linaro@kernel.org
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Link: https://lore.kernel.org/r/20240507210809.3479953-3-sboyd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: thermal: loongson,ls2k-thermal: Add Loongson-2K0500 compatible [+ + +]
Author: Binbin Zhou <zhoubinbin@loongson.cn>
Date:   Tue Apr 23 09:59:01 2024 +0800

    dt-bindings: thermal: loongson,ls2k-thermal: Add Loongson-2K0500 compatible
    
    [ Upstream commit 25c7d8472f6e90390931e93f59135478af3e5d86 ]
    
    The thermal on the Loongson-2K0500 shares the design with the
    Loongson-2K1000. Define corresponding compatible string, having the
    loongson,ls2k1000-thermal as a fallback.
    
    Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
    Acked-by: Rob Herring <robh@kernel.org>
    Acked-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/26524a63abd2d032e4c45efe6ce3fedb46841768.1713837379.git.zhoubinbin@loongson.cn
    Stable-dep-of: c8c435368577 ("dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: thermal: loongson,ls2k-thermal: Fix binding check issues [+ + +]
Author: Binbin Zhou <zhoubinbin@loongson.cn>
Date:   Fri Nov 24 17:57:44 2023 +0800

    dt-bindings: thermal: loongson,ls2k-thermal: Fix binding check issues
    
    [ Upstream commit 88071e31e994ee23356674e0c5461b25e2a95cdc ]
    
    Add the missing 'thermal-sensor-cells' property which is required for
    every thermal sensor as it's used when using phandles.
    And add the thermal-sensor.yaml reference.
    
    In fact, it was a careless mistake when submitting the driver that
    caused it to not work properly. So the fix is necessary, although it
    will result in the ABI break.
    
    Fixes: 72684d99a854 ("thermal: dt-bindings: add loongson-2 thermal")
    Cc: Yinbo Zhu <zhuyinbo@loongson.cn>
    Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
    Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/6d69362632271ab0af9a5fbfa3bc46a0894f1d54.1700817227.git.zhoubinbin@loongson.cn
    Stable-dep-of: c8c435368577 ("dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition [+ + +]
Author: Binbin Zhou <zhoubinbin@loongson.cn>
Date:   Tue Apr 23 09:59:02 2024 +0800

    dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition
    
    [ Upstream commit c8c4353685778e75e186103411e9d01a4a3f2b90 ]
    
    The temperature output register of the Loongson-2K2000 is defined in the
    chip configuration domain, which is different from the Loongson-2K1000,
    so it can't be fallbacked.
    
    We need to use two groups of registers to describe it: the first group
    is the high and low temperature threshold setting register; the second
    group is the temperature output register.
    
    It is true that this fix will cause ABI corruption, but it is necessary
    otherwise the Loongson-2K2000 temperature sensor will not work properly.
    
    Fixes: 72684d99a854 ("thermal: dt-bindings: add loongson-2 thermal")
    Cc: Yinbo Zhu <zhuyinbo@loongson.cn>
    Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/5198999d679f1a1c3457385acb9fadfc85da1f1e.1713837379.git.zhoubinbin@loongson.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ecryptfs: Fix buffer size for tag 66 packet [+ + +]
Author: Brian Kubisiak <brian@kubisiak.com>
Date:   Sun Mar 17 07:46:00 2024 -0700

    ecryptfs: Fix buffer size for tag 66 packet
    
    [ Upstream commit 85a6a1aff08ec9f5b929d345d066e2830e8818e5 ]
    
    The 'TAG 66 Packet Format' description is missing the cipher code and
    checksum fields that are packed into the message packet. As a result,
    the buffer allocated for the packet is 3 bytes too small and
    write_tag_66_packet() will write up to 3 bytes past the end of the
    buffer.
    
    Fix this by increasing the size of the allocation so the whole packet
    will always fit in the buffer.
    
    This fixes the below kasan slab-out-of-bounds bug:
    
      BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
      Write of size 1 at addr ffff88800afbb2a5 by task touch/181
    
      CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x4c/0x70
       print_report+0xc5/0x610
       ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
       ? kasan_complete_mode_report_info+0x44/0x210
       ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
       kasan_report+0xc2/0x110
       ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
       __asan_store1+0x62/0x80
       ecryptfs_generate_key_packet_set+0x7d6/0xde0
       ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10
       ? __alloc_pages+0x2e2/0x540
       ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]
       ? dentry_open+0x8f/0xd0
       ecryptfs_write_metadata+0x30a/0x550
       ? __pfx_ecryptfs_write_metadata+0x10/0x10
       ? ecryptfs_get_lower_file+0x6b/0x190
       ecryptfs_initialize_file+0x77/0x150
       ecryptfs_create+0x1c2/0x2f0
       path_openat+0x17cf/0x1ba0
       ? __pfx_path_openat+0x10/0x10
       do_filp_open+0x15e/0x290
       ? __pfx_do_filp_open+0x10/0x10
       ? __kasan_check_write+0x18/0x30
       ? _raw_spin_lock+0x86/0xf0
       ? __pfx__raw_spin_lock+0x10/0x10
       ? __kasan_check_write+0x18/0x30
       ? alloc_fd+0xf4/0x330
       do_sys_openat2+0x122/0x160
       ? __pfx_do_sys_openat2+0x10/0x10
       __x64_sys_openat+0xef/0x170
       ? __pfx___x64_sys_openat+0x10/0x10
       do_syscall_64+0x60/0xd0
       entry_SYSCALL_64_after_hwframe+0x6e/0xd8
      RIP: 0033:0x7f00a703fd67
      Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f
      RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
      RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67
      RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c
      RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000
      R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941
      R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040
       </TASK>
    
      Allocated by task 181:
       kasan_save_stack+0x2f/0x60
       kasan_set_track+0x29/0x40
       kasan_save_alloc_info+0x25/0x40
       __kasan_kmalloc+0xc5/0xd0
       __kmalloc+0x66/0x160
       ecryptfs_generate_key_packet_set+0x6d2/0xde0
       ecryptfs_write_metadata+0x30a/0x550
       ecryptfs_initialize_file+0x77/0x150
       ecryptfs_create+0x1c2/0x2f0
       path_openat+0x17cf/0x1ba0
       do_filp_open+0x15e/0x290
       do_sys_openat2+0x122/0x160
       __x64_sys_openat+0xef/0x170
       do_syscall_64+0x60/0xd0
       entry_SYSCALL_64_after_hwframe+0x6e/0xd8
    
    Fixes: dddfa461fc89 ("[PATCH] eCryptfs: Public key; packet management")
    Signed-off-by: Brian Kubisiak <brian@kubisiak.com>
    Link: https://lore.kernel.org/r/5j2q56p6qkhezva6b2yuqfrsurmvrrqtxxzrnp3wqu7xrz22i7@hoecdztoplbl
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
efi: libstub: only free priv.runtime_map when allocated [+ + +]
Author: Hagar Hemdan <hagarhem@amazon.com>
Date:   Tue Apr 23 13:59:26 2024 +0000

    efi: libstub: only free priv.runtime_map when allocated
    
    commit 4b2543f7e1e6b91cfc8dd1696e3cdf01c3ac8974 upstream.
    
    priv.runtime_map is only allocated when efi_novamap is not set.
    Otherwise, it is an uninitialized value.  In the error path, it is freed
    unconditionally.  Avoid passing an uninitialized value to free_pool.
    Free priv.runtime_map only when it was allocated.
    
    This bug was discovered and resolved using Coverity Static Analysis
    Security Testing (SAST) by Synopsys, Inc.
    
    Fixes: f80d26043af9 ("efi: libstub: avoid efi_get_memory_map() for allocating the virt map")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Hagar Hemdan <hagarhem@amazon.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
enetc: avoid truncating error message [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 26 23:38:01 2024 +0100

    enetc: avoid truncating error message
    
    [ Upstream commit 9046d581ed586f3c715357638ca12c0e84402002 ]
    
    As clang points out, the error message in enetc_setup_xdp_prog()
    still does not fit in the buffer and will be truncated:
    
    drivers/net/ethernet/freescale/enetc/enetc.c:2771:3: error: 'snprintf' will always be truncated; specified size is 80, but format string expands to at least 87 [-Werror,-Wformat-truncation]
    
    Replace it with an even shorter message that should fit.
    
    Fixes: f968c56417f0 ("net: enetc: shorten enetc_setup_xdp_prog() error message to fit NETLINK_MAX_FMTMSG_LEN")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240326223825.4084412-3-arnd@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
enic: Validate length of nl attributes in enic_set_vf_port [+ + +]
Author: Roded Zats <rzats@paloaltonetworks.com>
Date:   Wed May 22 10:30:44 2024 +0300

    enic: Validate length of nl attributes in enic_set_vf_port
    
    [ Upstream commit e8021b94b0412c37bcc79027c2e382086b6ce449 ]
    
    enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE
    is of length PORT_PROFILE_MAX and that the nl attributes
    IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.
    These attributes are validated (in the function do_setlink in rtnetlink.c)
    using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE
    as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and
    IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation
    using the policy is for the max size of the attributes and not on exact
    size so the length of these attributes might be less than the sizes that
    enic_set_vf_port expects. This might cause an out of bands
    read access in the memcpys of the data of these
    attributes in enic_set_vf_port.
    
    Fixes: f8bd909183ac ("net: Add ndo_{set|get}_vf_port support for enic dynamic vnics")
    Signed-off-by: Roded Zats <rzats@paloaltonetworks.com>
    Link: https://lore.kernel.org/r/20240522073044.33519-1-rzats@paloaltonetworks.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
epoll: be better about file lifetimes [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri May 3 13:36:09 2024 -0700

    epoll: be better about file lifetimes
    
    [ Upstream commit 4efaa5acf0a1d2b5947f98abb3acf8bfd966422b ]
    
    epoll can call out to vfs_poll() with a file pointer that may race with
    the last 'fput()'. That would make f_count go down to zero, and while
    the ep->mtx locking means that the resulting file pointer tear-down will
    be blocked until the poll returns, it means that f_count is already
    dead, and any use of it won't actually get a reference to the file any
    more: it's dead regardless.
    
    Make sure we have a valid ref on the file pointer before we call down to
    vfs_poll() from the epoll routines.
    
    Link: https://lore.kernel.org/lkml/0000000000002d631f0615918f1e@google.com/
    Reported-by: syzbot+045b454ab35fd82a35fb@syzkaller.appspotmail.com
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
eth: sungem: remove .ndo_poll_controller to avoid deadlocks [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Wed May 8 06:45:04 2024 -0700

    eth: sungem: remove .ndo_poll_controller to avoid deadlocks
    
    [ Upstream commit ac0a230f719b02432d8c7eba7615ebd691da86f4 ]
    
    Erhard reports netpoll warnings from sungem:
    
      netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)
      WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
    
    gem_poll_controller() disables interrupts, which may sleep.
    We can't sleep in netpoll, it has interrupts disabled completely.
    Strangely, gem_poll_controller() doesn't even poll the completions,
    and instead acts as if an interrupt has fired so it just schedules
    NAPI and exits. None of this has been necessary for years, since
    netpoll invokes NAPI directly.
    
    Fixes: fe09bb619096 ("sungem: Spring cleaning and GRO support")
    Reported-and-tested-by: Erhard Furtner <erhard_f@mailbox.org>
    Link: https://lore.kernel.org/all/20240428125306.2c3080ef@legion
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240508134504.3560956-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
eventfs/tracing: Add callback for release of an eventfs_inode [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Thu May 2 09:03:15 2024 -0400

    eventfs/tracing: Add callback for release of an eventfs_inode
    
    [ Upstream commit b63db58e2fa5d6963db9c45df88e60060f0ff35f ]
    
    Synthetic events create and destroy tracefs files when they are created
    and removed. The tracing subsystem has its own file descriptor
    representing the state of the events attached to the tracefs files.
    There's a race between the eventfs files and this file descriptor of the
    tracing system where the following can cause an issue:
    
    With two scripts 'A' and 'B' doing:
    
      Script 'A':
        echo "hello int aaa" > /sys/kernel/tracing/synthetic_events
        while :
        do
          echo 0 > /sys/kernel/tracing/events/synthetic/hello/enable
        done
    
      Script 'B':
        echo > /sys/kernel/tracing/synthetic_events
    
    Script 'A' creates a synthetic event "hello" and then just writes zero
    into its enable file.
    
    Script 'B' removes all synthetic events (including the newly created
    "hello" event).
    
    What happens is that the opening of the "enable" file has:
    
     {
            struct trace_event_file *file = inode->i_private;
            int ret;
    
            ret = tracing_check_open_get_tr(file->tr);
     [..]
    
    But deleting the events frees the "file" descriptor, and a "use after
    free" happens with the dereference at "file->tr".
    
    The file descriptor does have a reference counter, but there needs to be a
    way to decrement it from the eventfs when the eventfs_inode is removed
    that represents this file descriptor.
    
    Add an optional "release" callback to the eventfs_entry array structure,
    that gets called when the eventfs file is about to be removed. This allows
    for the creating on the eventfs file to increment the tracing file
    descriptor ref counter. When the eventfs file is deleted, it can call the
    release function that will call the put function for the tracing file
    descriptor.
    
    This will protect the tracing file from being freed while a eventfs file
    that references it is being opened.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240426073410.17154-1-Tze-nan.Wu@mediatek.com/
    Link: https://lore.kernel.org/linux-trace-kernel/20240502090315.448cba46@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Fixes: 5790b1fb3d672 ("eventfs: Remove eventfs_file and just use eventfs_inode")
    Reported-by: Tze-nan wu <Tze-nan.Wu@mediatek.com>
    Tested-by: Tze-nan Wu (吳澤南) <Tze-nan.Wu@mediatek.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
eventfs: Create eventfs_root_inode to store dentry [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Thu Feb 1 10:34:52 2024 -0500

    eventfs: Create eventfs_root_inode to store dentry
    
    [ Upstream commit c3137ab6318d56370dd5541ebf027ddfc0c8557c ]
    
    Only the root "events" directory stores a dentry. There's no reason to
    hold a dentry pointer for every eventfs_inode as it is never set except
    for the root "events" eventfs_inode.
    
    Create a eventfs_root_inode structure that holds the events_dir dentry.
    The "events" eventfs_inode *is* special, let it have its own descriptor.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240201161617.658992558@goodmis.org
    
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: Ajay Kaher <ajay.kaher@broadcom.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Stable-dep-of: b63db58e2fa5 ("eventfs/tracing: Add callback for release of an eventfs_inode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

eventfs: Do not differentiate the toplevel events directory [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Thu May 2 16:08:25 2024 -0400

    eventfs: Do not differentiate the toplevel events directory
    
    [ Upstream commit d53891d348ac3eceaf48f4732a1f4f5c0e0a55ce ]
    
    The toplevel events directory is really no different than the events
    directory of instances. Having the two be different caused
    inconsistencies and made it harder to fix the permissions bugs.
    
    Make all events directories act the same.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240502200905.846448710@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Fixes: 8186fff7ab649 ("tracefs/eventfs: Use root and instance inodes as default ownership")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

eventfs: Free all of the eventfs_inode after RCU [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Thu May 2 16:08:22 2024 -0400

    eventfs: Free all of the eventfs_inode after RCU
    
    [ Upstream commit ee4e0379475e4fe723986ae96293e465014fa8d9 ]
    
    The freeing of eventfs_inode via a kfree_rcu() callback. But the content
    of the eventfs_inode was being freed after the last kref. This is
    dangerous, as changes are being made that can access the content of an
    eventfs_inode from an RCU loop.
    
    Instead of using kfree_rcu() use call_rcu() that calls a function to do
    all the freeing of the eventfs_inode after a RCU grace period has expired.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240502200905.370261163@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Fixes: 43aa6f97c2d03 ("eventfs: Get rid of dentry pointers without refcounts")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

eventfs: Have "events" directory get permissions from its parent [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Thu May 2 16:08:27 2024 -0400

    eventfs: Have "events" directory get permissions from its parent
    
    [ Upstream commit d57cf30c4c07837799edec949102b0adf58bae79 ]
    
    The events directory gets its permissions from the root inode. But this
    can cause an inconsistency if the instances directory changes its
    permissions, as the permissions of the created directories under it should
    inherit the permissions of the instances directory when directories under
    it are created.
    
    Currently the behavior is:
    
     # cd /sys/kernel/tracing
     # chgrp 1002 instances
     # mkdir instances/foo
     # ls -l instances/foo
    [..]
     -r--r-----  1 root lkp  0 May  1 18:55 buffer_total_size_kb
     -rw-r-----  1 root lkp  0 May  1 18:55 current_tracer
     -rw-r-----  1 root lkp  0 May  1 18:55 error_log
     drwxr-xr-x  1 root root 0 May  1 18:55 events
     --w-------  1 root lkp  0 May  1 18:55 free_buffer
     drwxr-x---  2 root lkp  0 May  1 18:55 options
     drwxr-x--- 10 root lkp  0 May  1 18:55 per_cpu
     -rw-r-----  1 root lkp  0 May  1 18:55 set_event
    
    All the files and directories under "foo" has the "lkp" group except the
    "events" directory. That's because its getting its default value from the
    mount point instead of its parent.
    
    Have the "events" directory make its default value based on its parent's
    permissions. That now gives:
    
     # ls -l instances/foo
    [..]
     -rw-r-----  1 root lkp 0 May  1 21:16 buffer_subbuf_size_kb
     -r--r-----  1 root lkp 0 May  1 21:16 buffer_total_size_kb
     -rw-r-----  1 root lkp 0 May  1 21:16 current_tracer
     -rw-r-----  1 root lkp 0 May  1 21:16 error_log
     drwxr-xr-x  1 root lkp 0 May  1 21:16 events
     --w-------  1 root lkp 0 May  1 21:16 free_buffer
     drwxr-x---  2 root lkp 0 May  1 21:16 options
     drwxr-x--- 10 root lkp 0 May  1 21:16 per_cpu
     -rw-r-----  1 root lkp 0 May  1 21:16 set_event
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240502200906.161887248@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Fixes: 8186fff7ab649 ("tracefs/eventfs: Use root and instance inodes as default ownership")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: avoid excessive credit estimate in ext4_tmpfile() [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Thu Mar 7 12:53:20 2024 +0100

    ext4: avoid excessive credit estimate in ext4_tmpfile()
    
    [ Upstream commit 35a1f12f0ca857fee1d7a04ef52cbd5f1f84de13 ]
    
    A user with minimum journal size (1024 blocks these days) complained
    about the following error triggered by generic/697 test in
    ext4_tmpfile():
    
    run fstests generic/697 at 2024-02-28 05:34:46
    JBD2: vfstest wants too many credits credits:260 rsv_credits:0 max:256
    EXT4-fs error (device loop0) in __ext4_new_inode:1083: error 28
    
    Indeed the credit estimate in ext4_tmpfile() is huge.
    EXT4_MAXQUOTAS_INIT_BLOCKS() is 219, then 10 credits from ext4_tmpfile()
    itself and then ext4_xattr_credits_for_new_inode() adds more credits
    needed for security attributes and ACLs. Now the
    EXT4_MAXQUOTAS_INIT_BLOCKS() is in fact unnecessary because we've
    already initialized quotas with dquot_init() shortly before and so
    EXT4_MAXQUOTAS_TRANS_BLOCKS() is enough (which boils down to 3 credits).
    
    Fixes: af51a2ac36d1 ("ext4: ->tmpfile() support")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Tested-by: Luis Henriques <lhenriques@suse.de>
    Tested-by: Disha Goel <disgoel@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240307115320.28949-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix potential unnitialized variable [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Apr 17 21:10:40 2024 +0300

    ext4: fix potential unnitialized variable
    
    [ Upstream commit 3f4830abd236d0428e50451e1ecb62e14c365e9b ]
    
    Smatch complains "err" can be uninitialized in the caller.
    
        fs/ext4/indirect.c:349 ext4_alloc_branch()
        error: uninitialized symbol 'err'.
    
    Set the error to zero on the success path.
    
    Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/363a4673-0fb8-4adf-b4fb-90a499077276@moroto.mountain
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: remove the redundant folio_wait_stable() [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Fri Apr 19 10:30:05 2024 +0800

    ext4: remove the redundant folio_wait_stable()
    
    [ Upstream commit df0b5afc62f3368d657a8fe4a8d393ac481474c2 ]
    
    __filemap_get_folio() with FGP_WRITEBEGIN parameter has already wait
    for stable folio, so remove the redundant folio_wait_stable() in
    ext4_da_write_begin(), it was left over from the commit cc883236b792
    ("ext4: drop unnecessary journal handle in delalloc write") that
    removed the retry getting page logic.
    
    Fixes: cc883236b792 ("ext4: drop unnecessary journal handle in delalloc write")
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240419023005.2719050-1-yi.zhang@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
extcon: max8997: select IRQ_DOMAIN instead of depending on it [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Feb 12 22:00:28 2024 -0800

    extcon: max8997: select IRQ_DOMAIN instead of depending on it
    
    [ Upstream commit b1781d0a1458070d40134e4f3412ec9d70099bec ]
    
    IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set
    it directly thru "make *config", so drivers should select it instead
    of depending on it if they need it.
    Relying on it being set for a dependency is risky.
    
    Consistently using "select" or "depends on" can also help reduce
    Kconfig circular dependency issues.
    
    Therefore, change EXTCON_MAX8997's use of "depends on" for
    IRQ_DOMAIN to "select".
    
    Link: https://lore.kernel.org/lkml/20240213060028.9744-1-rdunlap@infradead.org/
    Fixes: dca1a71e4108 ("extcon: Add support irq domain for MAX8997 muic")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
f2fs: Clean up errors in segment.h [+ + +]
Author: KaiLong Wang <wangkailong@jari.cn>
Date:   Fri Oct 13 14:45:42 2023 +0800

    f2fs: Clean up errors in segment.h
    
    [ Upstream commit 37768434b7a7d00ac5a08b2c1d31aa7aaa0846a0 ]
    
    Fix the following errors reported by checkpatch:
    
    ERROR: spaces required around that ':' (ctx:VxW)
    
    Signed-off-by: KaiLong Wang <wangkailong@jari.cn>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: aa4074e8fec4 ("f2fs: fix block migration when section is not aligned to pow2")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: compress: don't allow unaligned truncation on released compress inode [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Fri May 10 11:33:39 2024 +0800

    f2fs: compress: don't allow unaligned truncation on released compress inode
    
    [ Upstream commit 29ed2b5dd521ce7c5d8466cd70bf0cc9d07afeee ]
    
    f2fs image may be corrupted after below testcase:
    - mkfs.f2fs -O extra_attr,compression -f /dev/vdb
    - mount /dev/vdb /mnt/f2fs
    - touch /mnt/f2fs/file
    - f2fs_io setflags compression /mnt/f2fs/file
    - dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=4
    - f2fs_io release_cblocks /mnt/f2fs/file
    - truncate -s 8192 /mnt/f2fs/file
    - umount /mnt/f2fs
    - fsck.f2fs /dev/vdb
    
    [ASSERT] (fsck_chk_inode_blk:1256)  --> ino: 0x5 has i_blocks: 0x00000002, but has 0x3 blocks
    [FSCK] valid_block_count matching with CP             [Fail] [0x4, 0x5]
    [FSCK] other corrupted bugs                           [Fail]
    
    The reason is: partial truncation assume compressed inode has reserved
    blocks, after partial truncation, valid block count may change w/o
    .i_blocks and .total_valid_block_count update, result in corruption.
    
    This patch only allow cluster size aligned truncation on released
    compress inode for fixing.
    
    Fixes: c61404153eb6 ("f2fs: introduce FI_COMPRESS_RELEASED instead of using IMMUTABLE bit")
    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: compress: fix error path of inc_valid_block_count() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Mon May 6 18:41:37 2024 +0800

    f2fs: compress: fix error path of inc_valid_block_count()
    
    [ Upstream commit 043c832371cd9023fbd725138ddc6c7f288dc469 ]
    
    If inc_valid_block_count() can not allocate all requested blocks,
    it needs to release block count in .total_valid_block_count and
    resevation blocks in inode.
    
    Fixes: 54607494875e ("f2fs: compress: fix to avoid inconsistence bewteen i_blocks and dnode")
    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: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Mon May 6 18:41:39 2024 +0800

    f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
    
    [ Upstream commit 0a4ed2d97cb6d044196cc3e726b6699222b41019 ]
    
    It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
    to avoid racing with checkpoint, otherwise, filesystem metadata including
    blkaddr in dnode, inode fields and .total_valid_block_count may be
    corrupted after SPO case.
    
    Fixes: ef8d563f184e ("f2fs: introduce F2FS_IOC_RELEASE_COMPRESS_BLOCKS")
    Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS")
    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: compress: fix to relocate check condition in f2fs_ioc_{,de}compress_file() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Sun Apr 7 15:26:04 2024 +0800

    f2fs: compress: fix to relocate check condition in f2fs_ioc_{,de}compress_file()
    
    [ Upstream commit bd9ae4ae9e585061acfd4a169f2321706f900246 ]
    
    Compress flag should be checked after inode lock held to avoid
    racing w/ f2fs_setflags_common() , fix it.
    
    Fixes: 5fdb322ff2c2 ("f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE")
    Reported-by: Zhiguo Niu <zhiguo.niu@unisoc.com>
    Closes: https://lore.kernel.org/linux-f2fs-devel/CAHJ8P3LdZXLc2rqeYjvymgYHr2+YLuJ0sLG9DdsJZmwO7deuhw@mail.gmail.com
    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: compress: fix to relocate check condition in f2fs_{release,reserve}_compress_blocks() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Sun Apr 7 15:26:03 2024 +0800

    f2fs: compress: fix to relocate check condition in f2fs_{release,reserve}_compress_blocks()
    
    [ Upstream commit 7c5dffb3d90c5921b91981cc663e02757d90526e ]
    
    Compress flag should be checked after inode lock held to avoid
    racing w/ f2fs_setflags_common(), fix it.
    
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Reported-by: Zhiguo Niu <zhiguo.niu@unisoc.com>
    Closes: https://lore.kernel.org/linux-f2fs-devel/CAHJ8P3LdZXLc2rqeYjvymgYHr2+YLuJ0sLG9DdsJZmwO7deuhw@mail.gmail.com
    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: compress: fix to update i_compr_blocks correctly [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Mon May 6 18:41:36 2024 +0800

    f2fs: compress: fix to update i_compr_blocks correctly
    
    [ Upstream commit 186e7d71534df4589405925caca5597af7626c12 ]
    
    Previously, we account reserved blocks and compressed blocks into
    @compr_blocks, then, f2fs_i_compr_blocks_update(,compr_blocks) will
    update i_compr_blocks incorrectly, fix it.
    
    Meanwhile, for the case all blocks in cluster were reserved, fix to
    update dn->ofs_in_node correctly.
    
    Fixes: eb8fbaa53374 ("f2fs: compress: fix to check unreleased compressed cluster")
    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: deprecate io_bits [+ + +]
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Tue Feb 6 11:21:00 2024 -0800

    f2fs: deprecate io_bits
    
    [ Upstream commit 87161a2b0aed9e9b614bbf6fe8697ad560ceb0cb ]
    
    Let's deprecate an unused io_bits feature to save CPU cycles and memory.
    
    Reviewed-by: Daeho Jeong <daehojeong@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: 043c832371cd ("f2fs: compress: fix error path of inc_valid_block_count()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix block migration when section is not aligned to pow2 [+ + +]
Author: Wu Bo <bo.wu@vivo.com>
Date:   Sun Apr 28 21:51:42 2024 -0600

    f2fs: fix block migration when section is not aligned to pow2
    
    [ Upstream commit aa4074e8fec4d2e686daee627fcafb3503efe365 ]
    
    As for zoned-UFS, f2fs section size is forced to zone size. And zone
    size may not aligned to pow2.
    
    Fixes: 859fca6b706e ("f2fs: swap: support migrating swapfile in aligned write mode")
    Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
    Signed-off-by: Wu Bo <bo.wu@vivo.com>
    Reviewed-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 add missing iput() in gc_data_segment() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Fri May 10 11:43:33 2024 +0800

    f2fs: fix to add missing iput() in gc_data_segment()
    
    [ Upstream commit a798ff17cd2dabe47d5d4ed3d509631793c36e19 ]
    
    During gc_data_segment(), if inode state is abnormal, it missed to call
    iput(), fix it.
    
    Fixes: b73e52824c89 ("f2fs: reposition unlock_new_inode to prevent accessing invalid inode")
    Fixes: 9056d6489f5a ("f2fs: fix to do sanity check on inode type during garbage collection")
    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 check pinfile flag in f2fs_move_file_range() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Wed Apr 3 22:24:20 2024 +0800

    f2fs: fix to check pinfile flag in f2fs_move_file_range()
    
    [ Upstream commit e07230da0500e0919a765037c5e81583b519be2c ]
    
    ioctl(F2FS_IOC_MOVE_RANGE) can truncate or punch hole on pinned file,
    fix to disallow it.
    
    Fixes: 5fed0be8583f ("f2fs: do not allow partial truncation on pinned file")
    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 release node block count in error path of f2fs_new_node_page() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Tue May 7 11:31:00 2024 +0800

    f2fs: fix to release node block count in error path of f2fs_new_node_page()
    
    [ Upstream commit 0fa4e57c1db263effd72d2149d4e21da0055c316 ]
    
    It missed to call dec_valid_node_count() to release node block count
    in error path, fix it.
    
    Fixes: 141170b759e0 ("f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()")
    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 relocate check condition in f2fs_fallocate() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Wed Apr 3 22:24:19 2024 +0800

    f2fs: fix to relocate check condition in f2fs_fallocate()
    
    [ Upstream commit 278a6253a673611dbc8ab72a3b34b151a8e75822 ]
    
    compress and pinfile flag should be checked after inode lock held to
    avoid race condition, fix it.
    
    Fixes: 4c8ff7095bef ("f2fs: support data compression")
    Fixes: 5fed0be8583f ("f2fs: do not allow partial truncation on pinned file")
    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 wait on page writeback in __clone_blkaddrs() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Tue Mar 26 19:28:45 2024 +0800

    f2fs: fix to wait on page writeback in __clone_blkaddrs()
    
    [ Upstream commit d3876e34e7e789e2cbdd782360fef2a777391082 ]
    
    In below race condition, dst page may become writeback status
    in __clone_blkaddrs(), it needs to wait writeback before update,
    fix it.
    
    Thread A                                GC Thread
    - f2fs_move_file_range
      - filemap_write_and_wait_range(dst)
                                            - gc_data_segment
                                             - f2fs_down_write(dst)
                                             - move_data_page
                                              - set_page_writeback(dst_page)
                                              - f2fs_submit_page_write
                                             - f2fs_up_write(dst)
      - f2fs_down_write(dst)
      - __exchange_data_block
       - __clone_blkaddrs
        - f2fs_get_new_data_page
        - memcpy_page
    
    Fixes: 0a2aa8fbb969 ("f2fs: refactor __exchange_data_block for speed up")
    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: introduce get_available_block_count() for cleanup [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Tue Feb 20 11:15:15 2024 +0800

    f2fs: introduce get_available_block_count() for cleanup
    
    [ Upstream commit 0f1c6ede6da9f7c5dd7380b74a64850298279168 ]
    
    There are very similar codes in inc_valid_block_count() and
    inc_valid_node_count() which is used for available user block
    count calculation.
    
    This patch introduces a new helper get_available_block_count()
    to include those common codes, and used it to clean up codes.
    
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: 043c832371cd ("f2fs: compress: fix error path of inc_valid_block_count()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: kill heap-based allocation [+ + +]
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Tue Feb 20 12:48:44 2024 -0800

    f2fs: kill heap-based allocation
    
    [ Upstream commit 4e0197f9932f70cc7be8744aa0ed4dd9b5d97d85 ]
    
    No one uses this feature. Let's kill it.
    
    Reviewed-by: Daeho Jeong <daehojeong@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: aa4074e8fec4 ("f2fs: fix block migration when section is not aligned to pow2")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: multidev: fix to recognize valid zero block address [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Wed Mar 27 15:42:23 2024 +0800

    f2fs: multidev: fix to recognize valid zero block address
    
    [ Upstream commit 33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5 ]
    
    As reported by Yi Zhang in mailing list [1], kernel warning was catched
    during zbd/010 test as below:
    
    ./check zbd/010
    zbd/010 (test gap zone support with F2FS)                    [failed]
        runtime    ...  3.752s
        something found in dmesg:
        [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13
        [ 4378.192349] null_blk: module loaded
        [ 4378.209860] null_blk: disk nullb0 created
        [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim
    poll_queues to 0. poll_q/nr_hw = (0/1)
        [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]
                         dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0
        [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux
    scsi_debug       0191 PQ: 0 ANSI: 7
        [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred
        [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20
        [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device
        ...
        (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg'
    
    WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51
    CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1
    RIP: 0010:iomap_iter+0x32b/0x350
    Call Trace:
     <TASK>
     __iomap_dio_rw+0x1df/0x830
     f2fs_file_read_iter+0x156/0x3d0 [f2fs]
     aio_read+0x138/0x210
     io_submit_one+0x188/0x8c0
     __x64_sys_io_submit+0x8c/0x1a0
     do_syscall_64+0x86/0x170
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    Shinichiro Kawasaki helps to analyse this issue and proposes a potential
    fixing patch in [2].
    
    Quoted from reply of Shinichiro Kawasaki:
    
    "I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a
    look in the commit, but it looks fine to me. So I thought the cause is not
    in the commit diff.
    
    I found the WARN is printed when the f2fs is set up with multiple devices,
    and read requests are mapped to the very first block of the second device in the
    direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached()
    modify map->m_pblk as the physical block address from each block device. It
    becomes zero when it is mapped to the first block of the device. However,
    f2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the
    whole f2fs, across the all block devices. It compares map->m_pblk against
    NULL_ADDR == 0, then go into the unexpected branch and sets the invalid
    iomap->length. The WARN catches the invalid iomap->length.
    
    This WARN is printed even for non-zoned block devices, by following steps.
    
     - Create two (non-zoned) null_blk devices memory backed with 128MB size each:
       nullb0 and nullb1.
     # mkfs.f2fs /dev/nullb0 -c /dev/nullb1
     # mount -t f2fs /dev/nullb0 "${mount_dir}"
     # dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192
     # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct
    
    ..."
    
    So, the root cause of this issue is: when multi-devices feature is on,
    f2fs_map_blocks() may return zero blkaddr in non-primary device, which is
    a verified valid block address, however, f2fs_iomap_begin() treats it as
    an invalid block address, and then it triggers the warning in iomap
    framework code.
    
    Finally, as discussed, we decide to use a more simple and direct way that
    checking (map.m_flags & F2FS_MAP_MAPPED) condition instead of
    (map.m_pblk != NULL_ADDR) to fix this issue.
    
    Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this
    issue.
    
    [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/
    [2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/
    
    Reported-by: Yi Zhang <yi.zhang@redhat.com>
    Closes: https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/
    Tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Tested-by: Yi Zhang <yi.zhang@redhat.com>
    Fixes: 1517c1a7a445 ("f2fs: implement iomap operations")
    Fixes: 8d3c1fa3fa5e ("f2fs: don't rely on F2FS_MAP_* in f2fs_iomap_begin")
    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: separate f2fs_gc_range() to use GC for a range [+ + +]
Author: Daeho Jeong <daehojeong@google.com>
Date:   Tue Feb 6 14:32:55 2024 -0800

    f2fs: separate f2fs_gc_range() to use GC for a range
    
    [ Upstream commit 2f0209f579d12bd0ea43a01a8696e30a8eeec1da ]
    
    Make f2fs_gc_range() an extenal function to use it for GC for a range.
    
    Signed-off-by: Daeho Jeong <daehojeong@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: aa4074e8fec4 ("f2fs: fix block migration when section is not aligned to pow2")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: support file pinning for zoned devices [+ + +]
Author: Daeho Jeong <daehojeong@google.com>
Date:   Tue Feb 13 09:38:12 2024 -0800

    f2fs: support file pinning for zoned devices
    
    [ Upstream commit 9703d69d9d153bb230711d0d577454552aeb13d4 ]
    
    Support file pinning with conventional storage area for zoned devices
    
    Signed-off-by: Daeho Jeong <daehojeong@google.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: aa4074e8fec4 ("f2fs: fix block migration when section is not aligned to pow2")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: support printk_ratelimited() in f2fs_printk() [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Fri Jan 26 23:19:16 2024 +0800

    f2fs: support printk_ratelimited() in f2fs_printk()
    
    [ Upstream commit b1c9d3f833ba60a288db111d7fe38edfeb9b8fbb ]
    
    This patch supports using printk_ratelimited() in f2fs_printk(), and
    wrap ratelimited f2fs_printk() into f2fs_{err,warn,info}_ratelimited(),
    then, use these new helps to clean up codes.
    
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: aa4074e8fec4 ("f2fs: fix block migration when section is not aligned to pow2")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: use BLKS_PER_SEG, BLKS_PER_SEC, and SEGS_PER_SEC [+ + +]
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Tue Feb 6 13:56:27 2024 -0800

    f2fs: use BLKS_PER_SEG, BLKS_PER_SEC, and SEGS_PER_SEC
    
    [ Upstream commit a60108f7dfb5867da1ad9c777d2fbbe47e4dbdd7 ]
    
    No functional change.
    
    Reviewed-by: Daeho Jeong <daehojeong@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Stable-dep-of: aa4074e8fec4 ("f2fs: fix block migration when section is not aligned to pow2")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: use f2fs_{err,info}_ratelimited() for cleanup [+ + +]
Author: Chao Yu <chao@kernel.org>
Date:   Mon May 6 18:47:42 2024 +0800

    f2fs: use f2fs_{err,info}_ratelimited() for cleanup
    
    commit a78118406d52dde495311c0c4917613868b53169 upstream.
    
    Commit b1c9d3f833ba ("f2fs: support printk_ratelimited() in f2fs_printk()")
    missed some cases, cover all remains for cleanup.
    
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

f2fs: write missing last sum blk of file pinning section [+ + +]
Author: Daeho Jeong <daehojeong@google.com>
Date:   Tue Apr 9 16:34:11 2024 -0700

    f2fs: write missing last sum blk of file pinning section
    
    commit b084403cfc3295b59a1b6bcc94efaf870fc3c2c9 upstream.
    
    While do not allocating a new section in advance for file pinning area, I
    missed that we should write the sum block for the last segment of a file
    pinning section.
    
    Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices")
    Signed-off-by: Daeho Jeong <daehojeong@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fbdev: Provide I/O-memory helpers as module [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Wed Sep 27 09:26:34 2023 +0200

    fbdev: Provide I/O-memory helpers as module
    
    [ Upstream commit 6b180f66c0dd6266eeb2f74b59ee79a9f14fe430 ]
    
    Provide helpers for accessing I/O memory in a helper module. The fbdev
    core uses these helpers, so select the module unconditionally for fbdev.
    Drivers will later be able to select the module individually and the
    helpers will become optional.
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230927074722.6197-2-tzimmermann@suse.de
    Stable-dep-of: 01c0cce88c54 ("drm/omapdrm: Fix console with deferred ops")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: sh7760fb: allow modular build [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Feb 9 21:39:38 2024 -0800

    fbdev: sh7760fb: allow modular build
    
    [ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]
    
    There is no reason to prohibit sh7760fb from being built as a
    loadable module as suggested by Geert, so change the config symbol
    from bool to tristate to allow that and change the FB dependency as
    needed.
    
    Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
    Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Javier Martinez Canillas <javierm@redhat.com>
    Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: Helge Deller <deller@gmx.de>
    Cc: linux-fbdev@vger.kernel.org
    Cc: dri-devel@lists.freedesktop.org
    Acked-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Acked-by: Javier Martinez Canillas <javierm@redhat.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: shmobile: fix snprintf truncation [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 26 23:38:00 2024 +0100

    fbdev: shmobile: fix snprintf truncation
    
    [ Upstream commit 26c8cfb9d1e4b252336d23dd5127a8cbed414a32 ]
    
    The name of the overlay does not fit into the fixed-length field:
    
    drivers/video/fbdev/sh_mobile_lcdcfb.c:1577:2: error: 'snprintf' will always be truncated; specified size is 16, but format string expands to at least 25
    
    Make it short enough by changing the string.
    
    Fixes: c5deac3c9b22 ("fbdev: sh_mobile_lcdc: Implement overlays support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: sisfb: hide unused variables [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Apr 3 10:06:31 2024 +0200

    fbdev: sisfb: hide unused variables
    
    [ Upstream commit 688cf598665851b9e8cb5083ff1d208ce43d10ff ]
    
    Building with W=1 shows that a couple of variables in this driver are only
    used in certain configurations:
    
    drivers/video/fbdev/sis/init301.c:239:28: error: 'SiS_Part2CLVX_6' defined but not used [-Werror=unused-const-variable=]
      239 | static const unsigned char SiS_Part2CLVX_6[] = {   /* 1080i */
          |                            ^~~~~~~~~~~~~~~
    drivers/video/fbdev/sis/init301.c:230:28: error: 'SiS_Part2CLVX_5' defined but not used [-Werror=unused-const-variable=]
      230 | static const unsigned char SiS_Part2CLVX_5[] = {   /* 750p */
          |                            ^~~~~~~~~~~~~~~
    drivers/video/fbdev/sis/init301.c:211:28: error: 'SiS_Part2CLVX_4' defined but not used [-Werror=unused-const-variable=]
      211 | static const unsigned char SiS_Part2CLVX_4[] = {   /* PAL */
          |                            ^~~~~~~~~~~~~~~
    drivers/video/fbdev/sis/init301.c:192:28: error: 'SiS_Part2CLVX_3' defined but not used [-Werror=unused-const-variable=]
      192 | static const unsigned char SiS_Part2CLVX_3[] = {  /* NTSC, 525i, 525p */
          |                            ^~~~~~~~~~~~~~~
    drivers/video/fbdev/sis/init301.c:184:28: error: 'SiS_Part2CLVX_2' defined but not used [-Werror=unused-const-variable=]
      184 | static const unsigned char SiS_Part2CLVX_2[] = {
          |                            ^~~~~~~~~~~~~~~
    drivers/video/fbdev/sis/init301.c:176:28: error: 'SiS_Part2CLVX_1' defined but not used [-Werror=unused-const-variable=]
      176 | static const unsigned char SiS_Part2CLVX_1[] = {
          |                            ^~~~~~~~~~~~~~~
    
    This started showing up after the definitions were moved into the
    source file from the header, which was not flagged by the compiler.
    Move the definition into the appropriate #ifdef block that already
    exists next to them.
    
    Fixes: 5908986ef348 ("video: fbdev: sis: avoid mismatched prototypes")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firmware: dmi-id: add a release callback function [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Apr 8 09:34:24 2024 +0200

    firmware: dmi-id: add a release callback function
    
    [ Upstream commit cf770af5645a41a753c55a053fa1237105b0964a ]
    
    dmi_class uses kfree() as the .release function, but that now causes
    a warning with clang-16 as it violates control flow integrity (KCFI)
    rules:
    
    drivers/firmware/dmi-id.c:174:17: error: cast from 'void (*)(const void *)' to 'void (*)(struct device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
      174 |         .dev_release = (void(*)(struct device *)) kfree,
    
    Add an explicit function to call kfree() instead.
    
    Fixes: 4f5c791a850e ("DMI-based module autoloading")
    Link: https://lore.kernel.org/lkml/20240213100238.456912-1-arnd@kernel.org/
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: qcom: scm: Fix __scm and waitq completion variable initialization [+ + +]
Author: Mukesh Ojha <quic_mojha@quicinc.com>
Date:   Thu Mar 21 20:54:02 2024 +0530

    firmware: qcom: scm: Fix __scm and waitq completion variable initialization
    
    [ Upstream commit 2e4955167ec5c04534cebea9e8273a907e7a75e1 ]
    
    It is possible qcom_scm_is_available() gives wrong indication that
    if __scm is initialized while __scm->dev is not and similar issue
    is also possible with __scm->waitq_comp.
    
    Fix this appropriately by the use of release barrier and read barrier
    that will make sure if __scm is initialized so, is all of its field
    variable.
    
    Fixes: d0f6fa7ba2d6 ("firmware: qcom: scm: Convert SCM to platform driver")
    Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic")
    Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
    Link: https://lore.kernel.org/r/1711034642-22860-4-git-send-email-quic_mojha@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: raspberrypi: Use correct device for DMA mappings [+ + +]
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Tue Mar 26 21:58:06 2024 +0200

    firmware: raspberrypi: Use correct device for DMA mappings
    
    [ Upstream commit df518a0ae1b982a4dcf2235464016c0c4576a34d ]
    
    The buffer used to transfer data over the mailbox interface is mapped
    using the client's device. This is incorrect, as the device performing
    the DMA transfer is the mailbox itself. Fix it by using the mailbox
    controller device instead.
    
    This requires including the mailbox_controller.h header to dereference
    the mbox_chan and mbox_controller structures. The header is not meant to
    be included by clients. This could be fixed by extending the client API
    with a function to access the controller's device.
    
    Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver")
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
    Tested-by: Ivan T. Ivanov <iivanov@suse.de>
    Link: https://lore.kernel.org/r/20240326195807.15163-3-laurent.pinchart@ideasonboard.com
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fpga: bridge: add owner module and take its refcount [+ + +]
Author: Marco Pagani <marpagan@redhat.com>
Date:   Fri Mar 22 18:18:37 2024 +0100

    fpga: bridge: add owner module and take its refcount
    
    [ Upstream commit 1da11f822042eb6ef4b6064dc048f157a7852529 ]
    
    The current implementation of the fpga bridge assumes that the low-level
    module registers a driver for the parent device and uses its owner pointer
    to take the module's refcount. This approach is problematic since it can
    lead to a null pointer dereference while attempting to get the bridge if
    the parent device does not have a driver.
    
    To address this problem, add a module owner pointer to the fpga_bridge
    struct and use it to take the module's refcount. Modify the function for
    registering a bridge to take an additional owner module parameter and
    rename it to avoid conflicts. Use the old function name for a helper macro
    that automatically sets the module that registers the bridge as the owner.
    This ensures compatibility with existing low-level control modules and
    reduces the chances of registering a bridge without setting the owner.
    
    Also, update the documentation to keep it consistent with the new interface
    for registering an fpga bridge.
    
    Other changes: opportunistically move put_device() from __fpga_bridge_get()
    to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since
    the bridge device is taken in these functions.
    
    Fixes: 21aeda950c5f ("fpga: add fpga bridge framework")
    Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Suggested-by: Xu Yilun <yilun.xu@intel.com>
    Reviewed-by: Russ Weight <russ.weight@linux.dev>
    Signed-off-by: Marco Pagani <marpagan@redhat.com>
    Acked-by: Xu Yilun <yilun.xu@intel.com>
    Link: https://lore.kernel.org/r/20240322171839.233864-1-marpagan@redhat.com
    Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fpga: dfl-pci: add PCI subdevice ID for Intel D5005 card [+ + +]
Author: Peter Colberg <peter.colberg@intel.com>
Date:   Mon Apr 22 19:02:57 2024 -0400

    fpga: dfl-pci: add PCI subdevice ID for Intel D5005 card
    
    [ Upstream commit bb1dbeceb1c20cfd81271e1bd69892ebd1ee38e0 ]
    
    Add PCI subdevice ID for the Intel D5005 Stratix 10 FPGA card as
    used with the Open FPGA Stack (OFS) FPGA Interface Manager (FIM).
    
    Unlike the Intel D5005 PAC FIM which exposed a separate PCI device ID,
    the OFS FIM reuses the same device ID for all DFL-based FPGA cards
    and differentiates on the subdevice ID. The subdevice ID values were
    chosen as the numeric part of the FPGA card names in hexadecimal.
    
    Signed-off-by: Peter Colberg <peter.colberg@intel.com>
    Reviewed-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
    Acked-by: Xu Yilun <yilun.xu@intel.com>
    Link: https://lore.kernel.org/r/20240422230257.1959-1-peter.colberg@intel.com
    Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fpga: manager: add owner module and take its refcount [+ + +]
Author: Marco Pagani <marpagan@redhat.com>
Date:   Tue Mar 5 20:29:26 2024 +0100

    fpga: manager: add owner module and take its refcount
    
    [ Upstream commit 4d4d2d4346857bf778fafaa97d6f76bb1663e3c9 ]
    
    The current implementation of the fpga manager assumes that the low-level
    module registers a driver for the parent device and uses its owner pointer
    to take the module's refcount. This approach is problematic since it can
    lead to a null pointer dereference while attempting to get the manager if
    the parent device does not have a driver.
    
    To address this problem, add a module owner pointer to the fpga_manager
    struct and use it to take the module's refcount. Modify the functions for
    registering the manager to take an additional owner module parameter and
    rename them to avoid conflicts. Use the old function names for helper
    macros that automatically set the module that registers the manager as the
    owner. This ensures compatibility with existing low-level control modules
    and reduces the chances of registering a manager without setting the owner.
    
    Also, update the documentation to keep it consistent with the new interface
    for registering an fpga manager.
    
    Other changes: opportunistically move put_device() from __fpga_mgr_get() to
    fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the
    manager device is taken in these functions.
    
    Fixes: 654ba4cc0f3e ("fpga manager: ensure lifetime with of_fpga_mgr_get")
    Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Suggested-by: Xu Yilun <yilun.xu@intel.com>
    Signed-off-by: Marco Pagani <marpagan@redhat.com>
    Acked-by: Xu Yilun <yilun.xu@intel.com>
    Link: https://lore.kernel.org/r/20240305192926.84886-1-marpagan@redhat.com
    Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fpga: region: add owner module and take its refcount [+ + +]
Author: Marco Pagani <marpagan@redhat.com>
Date:   Fri Apr 19 10:35:59 2024 +0200

    fpga: region: add owner module and take its refcount
    
    [ Upstream commit b7c0e1ecee403a43abc89eb3e75672b01ff2ece9 ]
    
    The current implementation of the fpga region assumes that the low-level
    module registers a driver for the parent device and uses its owner pointer
    to take the module's refcount. This approach is problematic since it can
    lead to a null pointer dereference while attempting to get the region
    during programming if the parent device does not have a driver.
    
    To address this problem, add a module owner pointer to the fpga_region
    struct and use it to take the module's refcount. Modify the functions for
    registering a region to take an additional owner module parameter and
    rename them to avoid conflicts. Use the old function names for helper
    macros that automatically set the module that registers the region as the
    owner. This ensures compatibility with existing low-level control modules
    and reduces the chances of registering a region without setting the owner.
    
    Also, update the documentation to keep it consistent with the new interface
    for registering an fpga region.
    
    Fixes: 0fa20cdfcc1f ("fpga: fpga-region: device tree control for FPGA")
    Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Suggested-by: Xu Yilun <yilun.xu@intel.com>
    Reviewed-by: Russ Weight <russ.weight@linux.dev>
    Signed-off-by: Marco Pagani <marpagan@redhat.com>
    Acked-by: Xu Yilun <yilun.xu@intel.com>
    Link: https://lore.kernel.org/r/20240419083601.77403-1-marpagan@redhat.com
    Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/ntfs3: Break dir enumeration if directory contents error [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Tue Apr 23 17:21:58 2024 +0300

    fs/ntfs3: Break dir enumeration if directory contents error
    
    commit 302e9dca8428979c9c99f2dbb44dc1783f5011c3 upstream.
    
    If we somehow attempt to read beyond the directory size, an error
    is supposed to be returned.
    
    However, in some cases, read requests do not stop and instead enter
    into a loop.
    
    To avoid this, we set the position in the directory to the end.
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fs/ntfs3: Check 'folio' pointer for NULL [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Tue Apr 16 09:54:34 2024 +0300

    fs/ntfs3: Check 'folio' pointer for NULL
    
    [ Upstream commit 1cd6c96219c429ebcfa8e79a865277376c563803 ]
    
    It can be NULL if bmap is called.
    
    Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block")
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Fix case when index is reused during tree transformation [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Tue Apr 23 15:31:56 2024 +0300

    fs/ntfs3: Fix case when index is reused during tree transformation
    
    commit 05afeeebcac850a016ec4fb1f681ceda11963562 upstream.
    
    In most cases when adding a cluster to the directory index,
    they are placed at the end, and in the bitmap, this cluster corresponds
    to the last bit. The new directory size is calculated as follows:
    
            data_size = (u64)(bit + 1) << indx->index_bits;
    
    In the case of reusing a non-final cluster from the index,
    data_size is calculated incorrectly, resulting in the directory size
    differing from the actual size.
    
    A check for cluster reuse has been added, and the size update is skipped.
    
    Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block")
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fs/ntfs3: Remove max link count info display during driver init [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Wed Apr 3 10:08:04 2024 +0300

    fs/ntfs3: Remove max link count info display during driver init
    
    commit a8948b5450e7c65a3a34ebf4ccfcebc19335d4fb upstream.
    
    Removes the output of this purely informational message from the
    kernel buffer:
    
            "ntfs3: Max link count 4000"
    
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fs/ntfs3: Taking DOS names into account during link counting [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Wed Apr 17 10:33:06 2024 +0300

    fs/ntfs3: Taking DOS names into account during link counting
    
    commit 110b24eb1a749bea3440f3ca2ff890a26179050a upstream.
    
    When counting and checking hard links in an ntfs file record,
    
      struct MFT_REC {
        struct NTFS_RECORD_HEADER rhdr; // 'FILE'
        __le16 seq;             // 0x10: Sequence number for this record.
    >>  __le16 hard_links;  // 0x12: The number of hard links to record.
        __le16 attr_off;    // 0x14: Offset to attributes.
      ...
    
    the ntfs3 driver ignored short names (DOS names), causing the link count
    to be reduced by 1 and messages to be output to dmesg.
    
    For Windows, such a situation is a minor error, meaning chkdsk does not report
    errors on such a volume, and in the case of using the /f switch, it silently
    corrects them, reporting that no errors were found. This does not affect
    the consistency of the file system.
    
    Nevertheless, the behavior in the ntfs3 driver is incorrect and
    changes the content of the file system. This patch should fix that.
    
    PS: most likely, there has been a confusion of concepts
    MFT_REC::hard_links and inode::__i_nlink.
    
    Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block")
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Tue Apr 16 09:45:09 2024 +0300

    fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow
    
    [ Upstream commit e931f6b630ffb22d66caab202a52aa8cbb10c649 ]
    
    For example, in the expression:
            vbo = 2 * vbo + skip
    
    Fixes: b46acd6a6a627 ("fs/ntfs3: Add NTFS journal")
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs/ntfs3: Use variable length array instead of fixed size [+ + +]
Author: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Date:   Tue Apr 16 09:43:58 2024 +0300

    fs/ntfs3: Use variable length array instead of fixed size
    
    [ Upstream commit 1997cdc3e727526aa5d84b32f7cbb3f56459b7ef ]
    
    Should fix smatch warning:
            ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)
    
    Fixes: 4534a70b7056f ("fs/ntfs3: Add headers and misc files")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/r/202401091421.3RJ24Mn3-lkp@intel.com/
    Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ftrace: Fix possible use-after-free issue in ftrace_location() [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Fri May 10 03:28:59 2024 +0800

    ftrace: Fix possible use-after-free issue in ftrace_location()
    
    commit e60b613df8b6253def41215402f72986fee3fc8d upstream.
    
    KASAN reports a bug:
    
      BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
      Read of size 8 at addr ffff888141d40010 by task insmod/424
      CPU: 8 PID: 424 Comm: insmod Tainted: G        W          6.9.0-rc2+
      [...]
      Call Trace:
       <TASK>
       dump_stack_lvl+0x68/0xa0
       print_report+0xcf/0x610
       kasan_report+0xb5/0xe0
       ftrace_location+0x90/0x120
       register_kprobe+0x14b/0xa40
       kprobe_init+0x2d/0xff0 [kprobe_example]
       do_one_initcall+0x8f/0x2d0
       do_init_module+0x13a/0x3c0
       load_module+0x3082/0x33d0
       init_module_from_file+0xd2/0x130
       __x64_sys_finit_module+0x306/0x440
       do_syscall_64+0x68/0x140
       entry_SYSCALL_64_after_hwframe+0x71/0x79
    
    The root cause is that, in lookup_rec(), ftrace record of some address
    is being searched in ftrace pages of some module, but those ftrace pages
    at the same time is being freed in ftrace_release_mod() as the
    corresponding module is being deleted:
    
               CPU1                       |      CPU2
      register_kprobes() {                | delete_module() {
        check_kprobe_address_safe() {     |
          arch_check_ftrace_location() {  |
            ftrace_location() {           |
              lookup_rec() // USE!        |   ftrace_release_mod() // Free!
    
    To fix this issue:
      1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
      2. Use ftrace_location_range() instead of lookup_rec() in
         ftrace_location();
      3. Call synchronize_rcu() before freeing any ftrace pages both in
         ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240509192859.1273558-1-zhengyejian1@huawei.com
    
    Cc: stable@vger.kernel.org
    Cc: <mhiramat@kernel.org>
    Cc: <mark.rutland@arm.com>
    Cc: <mathieu.desnoyers@efficios.com>
    Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization")
    Suggested-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline [+ + +]
Author: Dongli Zhang <dongli.zhang@oracle.com>
Date:   Wed May 22 15:02:18 2024 -0700

    genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
    
    commit a6c11c0a5235fb144a65e0cb2ffd360ddc1f6c32 upstream.
    
    The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
    interrupt affinity reconfiguration via procfs. Instead, the change is
    deferred until the next instance of the interrupt being triggered on the
    original CPU.
    
    When the interrupt next triggers on the original CPU, the new affinity is
    enforced within __irq_move_irq(). A vector is allocated from the new CPU,
    but the old vector on the original CPU remains and is not immediately
    reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming
    process is delayed until the next trigger of the interrupt on the new CPU.
    
    Upon the subsequent triggering of the interrupt on the new CPU,
    irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
    remains online. Subsequently, the timer on the old CPU iterates over its
    vector_cleanup list, reclaiming old vectors.
    
    However, a rare scenario arises if the old CPU is outgoing before the
    interrupt triggers again on the new CPU.
    
    In that case irq_force_complete_move() is not invoked on the outgoing CPU
    to reclaim the old apicd->prev_vector because the interrupt isn't currently
    affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
    though __vector_schedule_cleanup() is later called on the new CPU, it
    doesn't reclaim apicd->prev_vector; instead, it simply resets both
    apicd->move_in_progress and apicd->prev_vector to 0.
    
    As a result, the vector remains unreclaimed in vector_matrix, leading to a
    CPU vector leak.
    
    To address this issue, move the invocation of irq_force_complete_move()
    before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the
    interrupt is currently or used to be affine to the outgoing CPU.
    
    Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
    following a warning message, although theoretically it should never see
    apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.
    
    Fixes: f0383c24b485 ("genirq/cpuhotplug: Add support for cleaning up move in progress")
    Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240522220218.162423-1-dongli.zhang@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gfs2: Convert gfs2_internal_read to folios [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Mon Jul 24 20:53:14 2023 +0200

    gfs2: Convert gfs2_internal_read to folios
    
    [ Upstream commit be7f6a6b0bca708999eef4f8e9f2b128c73b9e17 ]
    
    Change gfs2_internal_read() to use folios.  Convert sizes to size_t.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: do_xmote fixes [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Mon Apr 15 11:23:04 2024 +0200

    gfs2: do_xmote fixes
    
    [ Upstream commit 9947a06d29c0a30da88cdc6376ca5fd87083e130 ]
    
    Function do_xmote() is called with the glock spinlock held.  Commit
    86934198eefa added a 'goto skip_inval' statement at the beginning of the
    function to further below where the glock spinlock is expected not to be
    held anymore.  Then it added code there that requires the glock spinlock
    to be held.  This doesn't make sense; fix this up by dropping and
    retaking the spinlock where needed.
    
    In addition, when ->lm_lock() returned an error, do_xmote() didn't fail
    the locking operation, and simply left the glock hanging; fix that as
    well.  (This is a much older error.)
    
    Fixes: 86934198eefa ("gfs2: Clear flags when withdraw prevents xmote")
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: Don't forget to complete delayed withdraw [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Fri Jan 26 11:49:44 2024 +0100

    gfs2: Don't forget to complete delayed withdraw
    
    [ Upstream commit b01189333ee91c1ae6cd96dfd1e3a3c2e69202f0 ]
    
    Commit fffe9bee14b0 ("gfs2: Delay withdraw from atomic context")
    switched from gfs2_withdraw() to gfs2_withdraw_delayed() in
    gfs2_ail_error(), but failed to then check if a delayed withdraw had
    occurred.  Fix that by adding the missing check in __gfs2_ail_flush(),
    where the spin locks are already dropped and a withdraw is possible.
    
    Fixes: fffe9bee14b0 ("gfs2: Delay withdraw from atomic context")
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: finish_xmote cleanup [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Fri Apr 12 19:16:58 2024 +0200

    gfs2: finish_xmote cleanup
    
    [ Upstream commit 1cd28e15864054f3c48baee9eecda1c0441c48ac ]
    
    Currently, function finish_xmote() takes and releases the glock
    spinlock.  However, all of its callers immediately take that spinlock
    again, so it makes more sense to take the spin lock before calling
    finish_xmote() already.
    
    With that, thaw_glock() is the only place that sets the GLF_HAVE_REPLY
    flag outside of the glock spinlock, but it also takes that spinlock
    immediately thereafter.  Change that to set the bit when the spinlock is
    already held.  This allows to switch from test_and_clear_bit() to
    test_bit() and clear_bit() in glock_work_func().
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Stable-dep-of: 9947a06d29c0 ("gfs2: do_xmote fixes")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: Fix "ignore unlock failures after withdraw" [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Fri Apr 5 13:47:51 2024 +0200

    gfs2: Fix "ignore unlock failures after withdraw"
    
    [ Upstream commit 5d9231111966b6c5a65016d58dcbeab91055bc91 ]
    
    Commit 3e11e53041502 tries to suppress dlm_lock() lock conversion errors
    that occur when the lockspace has already been released.
    
    It does that by setting and checking the SDF_SKIP_DLM_UNLOCK flag.  This
    conflicts with the intended meaning of the SDF_SKIP_DLM_UNLOCK flag, so
    check whether the lockspace is still allocated instead.
    
    (Given the current DLM API, checking for this kind of error after the
    fact seems easier that than to make sure that the lockspace is still
    allocated before calling dlm_lock().  Changing the DLM API so that users
    maintain the lockspace references themselves would be an option.)
    
    Fixes: 3e11e53041502 ("GFS2: ignore unlock failures after withdraw")
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: Fix potential glock use-after-free on unmount [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Wed Apr 10 04:50:18 2024 +0200

    gfs2: Fix potential glock use-after-free on unmount
    
    [ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
    
    When a DLM lockspace is released and there ares still locks in that
    lockspace, DLM will unlock those locks automatically.  Commit
    fb6791d100d1b started exploiting this behavior to speed up filesystem
    unmount: gfs2 would simply free glocks it didn't want to unlock and then
    release the lockspace.  This didn't take the bast callbacks for
    asynchronous lock contention notifications into account, which remain
    active until until a lock is unlocked or its lockspace is released.
    
    To prevent those callbacks from accessing deallocated objects, put the
    glocks that should not be unlocked on the sd_dead_glocks list, release
    the lockspace, and only then free those glocks.
    
    As an additional measure, ignore unexpected ast and bast callbacks if
    the receiving glock is dead.
    
    Fixes: fb6791d100d1b ("GFS2: skip dlm_unlock calls in unmount")
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Cc: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: Get rid of gfs2_alloc_blocks generation parameter [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Sat Oct 21 00:40:07 2023 +0200

    gfs2: Get rid of gfs2_alloc_blocks generation parameter
    
    [ Upstream commit 4c7b3f7fb7c8c66d669d107e717f9de41ef81e92 ]
    
    Get rid of the generation parameter of gfs2_alloc_blocks(): we only ever
    set the generation of the current inode while creating it, so do so
    directly.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: Mark withdraws as unlikely [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Wed Dec 20 17:05:26 2023 +0100

    gfs2: Mark withdraws as unlikely
    
    [ Upstream commit 015af1af44003fff797f8632e940824c07d282bf ]
    
    Mark the gfs2_withdrawn(), gfs2_withdrawing(), and
    gfs2_withdraw_in_prog() inline functions as likely to return %false.
    This allows to get rid of likely() and unlikely() annotations at the
    call sites of those functions.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Stable-dep-of: 9947a06d29c0 ("gfs2: do_xmote fixes")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: No longer use 'extern' in function declarations [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Mon Oct 9 18:49:31 2023 +0200

    gfs2: No longer use 'extern' in function declarations
    
    [ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
    
    For non-static function declarations, external linkage is implied and
    the 'extern' keyword isn't needed.  Some static checkers complain about
    the overuse of 'extern', so clean up all the function declarations.
    
    In addition, remove 'extern' from the definition of
    free_local_statfs_inodes(); it isn't needed there, either.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: Remove ill-placed consistency check [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Wed Apr 10 04:24:56 2024 +0200

    gfs2: Remove ill-placed consistency check
    
    [ Upstream commit 59f60005797b4018d7b46620037e0c53d690795e ]
    
    This consistency check was originally added by commit 9287c6452d2b1
    ("gfs2: Fix occasional glock use-after-free").  It is ill-placed in
    gfs2_glock_free() because if it holds there, it must equally hold in
    __gfs2_glock_put() already.  Either way, the check doesn't seem
    necessary anymore.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: Rename gfs2_lookup_{ simple => meta } [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Wed Jul 26 22:23:43 2023 +0200

    gfs2: Rename gfs2_lookup_{ simple => meta }
    
    [ Upstream commit 062fb903895a035ed382a0d3f9b9d459b2718217 ]
    
    Function gfs2_lookup_simple() is used for looking up inodes in the
    metadata directory tree, so rename it to gfs2_lookup_meta() to closer
    match its purpose.  Clean the function up a little on the way.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gfs2: Rename gfs2_withdrawn to gfs2_withdrawing_or_withdrawn [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Wed Dec 20 17:16:29 2023 +0100

    gfs2: Rename gfs2_withdrawn to gfs2_withdrawing_or_withdrawn
    
    [ Upstream commit 4d927b03a68846e4e791ccde6b4c274df02f11e9 ]
    
    This function checks whether the filesystem has been been marked to be
    withdrawn eventually or has been withdrawn already.  Rename this
    function to avoid confusing code like checking for gfs2_withdrawing()
    when gfs2_withdrawn() has already returned true.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Stable-dep-of: 9947a06d29c0 ("gfs2: do_xmote fixes")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gpiolib: acpi: Fix failed in acpi_gpiochip_find() by adding parent node match [+ + +]
Author: Devyn Liu <liudingyuan@huawei.com>
Date:   Mon May 13 15:59:01 2024 +0800

    gpiolib: acpi: Fix failed in acpi_gpiochip_find() by adding parent node match
    
    [ Upstream commit adbc49a5a8c6fcf7be154c2e30213bbf472940da ]
    
    Previous patch modified the standard used by acpi_gpiochip_find()
    to match device nodes. Using the device node set in gc->gpiodev->d-
    ev instead of gc->parent.
    
    However, there is a situation in gpio-dwapb where the GPIO device
    driver will set gc->fwnode for each port corresponding to a child
    node under a GPIO device, so gc->gpiodev->dev will be assigned the
    value of each child node in gpiochip_add_data().
    
    gpio-dwapb.c:
    128,31 static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
                                   struct dwapb_port_property *pp,
                                   unsigned int offs);
    port->gc.fwnode = pp->fwnode;
    
    693,39 static int dwapb_gpio_probe;
    err = dwapb_gpio_add_port(gpio, &pdata->properties[i], i);
    
    When other drivers request GPIO pin resources through the GPIO device
    node provided by ACPI (corresponding to the parent node), the change
    of the matching object to gc->gpiodev->dev in acpi_gpiochip_find()
    only allows finding the value of each port (child node), resulting
    in a failed request.
    
    Reapply the condition of using gc->parent for match in acpi_gpio-
    chip_find() in the code can compatible with the problem of gpio-dwapb,
    and will not affect the two cases mentioned in the patch:
    1. There is no setting for gc->fwnode.
    2. The case that depends on using gc->fwnode for match.
    
    Fixes: 5062e4c14b75 ("gpiolib: acpi: use the fwnode in acpi_gpiochip_find()")
    Fixes: 067dbc1ea5ce ("gpiolib: acpi: Don't use GPIO chip fwnode in acpi_gpiochip_find()")
    Signed-off-by: Devyn Liu <liudingyuan@huawei.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Tested-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
greybus: arche-ctrl: move device table to its right location [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Apr 3 10:06:35 2024 +0200

    greybus: arche-ctrl: move device table to its right location
    
    [ Upstream commit 6a0b8c0da8d8d418cde6894a104cf74e6098ddfa ]
    
    The arche-ctrl has two platform drivers and three of_device_id tables,
    but one table is only used for the the module loader, while the other
    two seem to be associated with their drivers.
    
    This leads to a W=1 warning when the driver is built-in:
    
    drivers/staging/greybus/arche-platform.c:623:34: error: 'arche_combined_id' defined but not used [-Werror=unused-const-variable=]
      623 | static const struct of_device_id arche_combined_id[] = {
    
    Drop the extra table and register both tables that are actually
    used as the ones for the module loader instead.
    
    Fixes: 7b62b61c752a ("greybus: arche-ctrl: Don't expose driver internals to arche-platform driver")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240403080702.3509288-18-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

greybus: lights: check return of get_channel_from_mode [+ + +]
Author: Rui Miguel Silva <rmfrfs@gmail.com>
Date:   Mon Mar 25 22:09:55 2024 +0000

    greybus: lights: check return of get_channel_from_mode
    
    [ Upstream commit a1ba19a1ae7cd1e324685ded4ab563e78fe68648 ]
    
    If channel for the given node is not found we return null from
    get_channel_from_mode. Make sure we validate the return pointer
    before using it in two of the missing places.
    
    This was originally reported in [0]:
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru
    
    Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
    Reported-by: Mikhail Lobanov <m.lobanov@rosalinux.ru>
    Suggested-by: Mikhail Lobanov <m.lobanov@rosalinux.ru>
    Suggested-by: Alex Elder <elder@ieee.org>
    Signed-off-by: Rui Miguel Silva <rmfrfs@gmail.com>
    Link: https://lore.kernel.org/r/20240325221549.2185265-1-rmfrfs@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: amd_sfh: Handle "no sensors" in PM operations [+ + +]
Author: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Date:   Tue May 7 12:40:44 2024 +0530

    HID: amd_sfh: Handle "no sensors" in PM operations
    
    [ Upstream commit 077e3e3bc84a51891e732507bbbd9acf6e0e4c8b ]
    
    Resume or suspend each sensor device based on the num_hid_devices.
    Therefore, add a check to handle the special case where no sensors are
    present.
    
    Fixes: 93ce5e0231d7 ("HID: amd_sfh: Implement SFH1.1 functionality")
    Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: intel-ish-hid: ipc: Add check for pci_alloc_irq_vectors [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Mon Apr 29 16:54:22 2024 +0800

    HID: intel-ish-hid: ipc: Add check for pci_alloc_irq_vectors
    
    [ Upstream commit 6baa4524027fd64d7ca524e1717c88c91a354b93 ]
    
    Add a check for the return value of pci_alloc_irq_vectors() and return
    error if it fails.
    
    [jkosina@suse.com: reworded changelog based on Srinivas' suggestion]
    Fixes: 74fbc7d371d9 ("HID: intel-ish-hid: add MSI interrupt support")
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: mcp-2221: cancel delayed_work only when CONFIG_IIO is enabled [+ + +]
Author: Abdelrahman Morsy <abdelrahmanhesham94@gmail.com>
Date:   Tue Apr 2 14:14:06 2024 +0200

    HID: mcp-2221: cancel delayed_work only when CONFIG_IIO is enabled
    
    [ Upstream commit 3cba9cfcc1520a2307a29f6fab887bcfc121c417 ]
    
    If the device is unplugged and CONFIG_IIO is not supported, this will
    result in a warning message at kernel/workqueue.
    
    Only cancel delayed work in mcp2221_remove(), when CONFIG_IIO is enabled.
    
    Signed-off-by: Abdelrahman Morsy <abdelrahmanhesham94@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (intel-m10-bmc-hwmon) Fix multiplier for N6000 board power sensor [+ + +]
Author: Peter Colberg <peter.colberg@intel.com>
Date:   Tue May 21 14:12:46 2024 -0400

    hwmon: (intel-m10-bmc-hwmon) Fix multiplier for N6000 board power sensor
    
    [ Upstream commit 027a44fedd55fbdf1d45603894634acd960ad04b ]
    
    The Intel N6000 BMC outputs the board power value in milliwatt, whereas
    the hwmon sysfs interface must provide power values in microwatt.
    
    Fixes: e1983220ae14 ("hwmon: intel-m10-bmc-hwmon: Add N6000 sensors")
    Signed-off-by: Peter Colberg <peter.colberg@intel.com>
    Reviewed-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
    Link: https://lore.kernel.org/r/20240521181246.683833-1-peter.colberg@intel.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (shtc1) Fix property misspelling [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu May 30 08:20:14 2024 -0700

    hwmon: (shtc1) Fix property misspelling
    
    [ Upstream commit 52a2c70c3ec555e670a34dd1ab958986451d2dd2 ]
    
    The property name is "sensirion,low-precision", not
    "sensicon,low-precision".
    
    Cc: Chris Ruehl <chris.ruehl@gtsys.com.hk>
    Fixes: be7373b60df5 ("hwmon: shtc1: add support for device tree bindings")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: cadence: Avoid fifo clear after start [+ + +]
Author: Sai Pavan Boddu <sai.pavan.boddu@amd.com>
Date:   Fri May 3 15:12:08 2024 +0530

    i2c: cadence: Avoid fifo clear after start
    
    [ Upstream commit c2e55b449de7298a751ed0256251019d302af453 ]
    
    The Driver unintentionally programs ctrl reg to clear the fifo, which
    happens after the start of transaction. Previously, this was not an issue
    as it involved read-modified-write. However, this issue breaks i2c reads
    on QEMU, as i2c-read is executed before guest starts programming control
    register.
    
    Fixes: ff0cf7bca630 ("i2c: cadence: Remove unnecessary register reads")
    Signed-off-by: Sai Pavan Boddu <sai.pavan.boddu@amd.com>
    Acked-by: Michal Simek <michal.simek@amd.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: synquacer: Fix an error handling path in synquacer_i2c_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jan 6 13:48:24 2024 +0100

    i2c: synquacer: Fix an error handling path in synquacer_i2c_probe()
    
    [ Upstream commit 55750148e5595bb85605e8fbb40b2759c2c4c2d7 ]
    
    If an error occurs after the clk_prepare_enable() call, it should be undone
    by a corresponding clk_disable_unprepare() call, as already done in the
    remove() function.
    
    As devm_clk_get() is used, we can switch to devm_clk_get_enabled() to
    handle it automatically and fix the probe.
    
    Update the remove() function accordingly and remove the now useless
    clk_disable_unprepare() call.
    
    Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i3c: add actual_len in i3c_priv_xfer [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Dec 1 17:25:29 2023 -0500

    i3c: add actual_len in i3c_priv_xfer
    
    [ Upstream commit e5e3df06ac98d15cfb10bb5c12356709365e91b2 ]
    
    In MIPI I3C Specification:
    
    "Ninth Bit of SDR Target Returned (Read) Data as End-of-Data: In I2C, the
    ninth Data bit from Target to Controller is an ACK by the Controller. By
    contrast, in I3C this bit allows the Target to end a Read, and allows the
    Controller to Abort a Read. In SDR terms, the ninth bit of Read data is
    referred to as the T-Bit (for ‘Transition’)"
    
    I3C allow devices early terminate data transfer. So need "actual_len" field
    to indicate how much get by i3c_priv_xfer.
    
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20231201222532.2431484-4-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 7f3d633b460b ("i3c: master: svc: change ENXIO to EAGAIN when IBI occurs during start frame")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i3c: master: svc: change ENXIO to EAGAIN when IBI occurs during start frame [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon May 6 12:40:08 2024 -0400

    i3c: master: svc: change ENXIO to EAGAIN when IBI occurs during start frame
    
    [ Upstream commit 7f3d633b460be5553a65a247def5426d16805e72 ]
    
    svc_i3c_master_xfer() returns error ENXIO if an In-Band Interrupt (IBI)
    occurs when the host starts the frame.
    
    Change error code to EAGAIN to inform the client driver that this
    situation has occurred and to try again sometime later.
    
    Fixes: 5e5e3c92e748 ("i3c: master: svc: fix wrong data return when IBI happen during start frame")
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/r/20240506164009.21375-2-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i3c: master: svc: rename read_len as actual_len [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Dec 1 17:25:30 2023 -0500

    i3c: master: svc: rename read_len as actual_len
    
    [ Upstream commit 6fb61734a74eaa307a5b6a0bee770e736d8acf89 ]
    
    I3C transfer (SDR), target can early terminate read transfer.
    I3C transfer (HDR), target can end write transfer.
    I2C transfer, target can NACK write transfer.
    
    'actual_len' is better name than 'read_len'.
    
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20231201222532.2431484-5-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 7f3d633b460b ("i3c: master: svc: change ENXIO to EAGAIN when IBI occurs during start frame")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i3c: master: svc: return actual transfer data len [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Dec 1 17:25:31 2023 -0500

    i3c: master: svc: return actual transfer data len
    
    [ Upstream commit 6d1a19d34e2cc07ca9cdad8892da94e716e9d15f ]
    
    I3C allow devices early terminate data transfer. So set "actual_len" to
    indicate how much data get by i3c_priv_xfer.
    
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20231201222532.2431484-6-Frank.Li@nxp.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Stable-dep-of: 7f3d633b460b ("i3c: master: svc: change ENXIO to EAGAIN when IBI occurs during start frame")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i915: make inject_virtual_interrupt() void [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Wed Nov 22 13:48:22 2023 +0100

    i915: make inject_virtual_interrupt() void
    
    [ Upstream commit 85884871921000b9bca2184077b1159771e50047 ]
    
    The single caller of inject_virtual_interrupt() ignores the return value
    anyway. This allows us to simplify eventfd_signal() in follow-up
    patches.
    
    Link: https://lore.kernel.org/r/20231122-vfs-eventfd-signal-v2-1-bd549b14ce0c@kernel.org
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Stable-dep-of: 82b951e6fbd3 ("vfio/pci: fix potential memory leak in vfio_intx_enable()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/mlx5: Use __iowrite64_copy() for write combining stores [+ + +]
Author: Jason Gunthorpe <jgg@ziepe.ca>
Date:   Thu Apr 11 13:46:19 2024 -0300

    IB/mlx5: Use __iowrite64_copy() for write combining stores
    
    [ Upstream commit ef302283ddfceaba2657923af3f90fd58e6dff06 ]
    
    mlx5 has a built in self-test at driver startup to evaluate if the
    platform supports write combining to generate a 64 byte PCIe TLP or
    not. This has proven necessary because a lot of common scenarios end up
    with broken write combining (especially inside virtual machines) and there
    is other way to learn this information.
    
    This self test has been consistently failing on new ARM64 CPU
    designs (specifically with NVIDIA Grace's implementation of Neoverse
    V2). The C loop around writeq() generates some pretty terrible ARM64
    assembly, but historically this has worked on a lot of existing ARM64 CPUs
    till now.
    
    We see it succeed about 1 time in 10,000 on the worst effected
    systems. The CPU architects speculate that the load instructions
    interspersed with the stores makes the WC buffers statistically flush too
    often and thus the generation of large TLPs becomes infrequent. This makes
    the boot up test unreliable in that it indicates no write-combining,
    however userspace would be fine since it uses a ST4 instruction.
    
    Further, S390 has similar issues where only the special zpci_memcpy_toio()
    will actually generate large TLPs, and the open coded loop does not
    trigger it at all.
    
    Fix both ARM64 and S390 by switching to __iowrite64_copy() which now
    provides architecture specific variants that have a high change of
    generating a large TLP with write combining. x86 continues to use a
    similar writeq loop in the generate __iowrite64_copy().
    
    Fixes: 11f552e21755 ("IB/mlx5: Test write combining support")
    Link: https://lore.kernel.org/r/6-v3-1893cd8b9369+1925-mlx5_arm_wc_jgg@nvidia.com
    Tested-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Acked-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ice: fix accounting if a VLAN already exists [+ + +]
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Thu May 23 10:45:30 2024 -0700

    ice: fix accounting if a VLAN already exists
    
    [ Upstream commit 82617b9a04649e83ee8731918aeadbb6e6d7cbc7 ]
    
    The ice_vsi_add_vlan() function is used to add a VLAN filter for the target
    VSI. This function prepares a filter in the switch table for the given VSI.
    If it succeeds, the vsi->num_vlan counter is incremented.
    
    It is not considered an error to add a VLAN which already exists in the
    switch table, so the function explicitly checks and ignores -EEXIST. The
    vsi->num_vlan counter is still incremented.
    
    This seems incorrect, as it means we can double-count in the case where the
    same VLAN is added twice by the caller. The actual table will have one less
    filter than the count.
    
    The ice_vsi_del_vlan() function similarly checks and handles the -ENOENT
    condition for when deleting a filter that doesn't exist. This flow only
    decrements the vsi->num_vlan if it actually deleted a filter.
    
    The vsi->num_vlan counter is used only in a few places, primarily related
    to tracking the number of non-zero VLANs. If the vsi->num_vlans gets out of
    sync, then ice_vsi_num_non_zero_vlans() will incorrectly report more VLANs
    than are present, and ice_vsi_has_non_zero_vlans() could return true
    potentially in cases where there are only VLAN 0 filters left.
    
    Fix this by only incrementing the vsi->num_vlan in the case where we
    actually added an entry, and not in the case where the entry already
    existed.
    
    Fixes: a1ffafb0b4a4 ("ice: Support configuring the device to Double VLAN Mode")
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240523-net-2024-05-23-intel-net-fixes-v1-2-17a923e0bb5f@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ice: Interpret .set_channels() input differently [+ + +]
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date:   Tue May 21 12:39:53 2024 -0700

    ice: Interpret .set_channels() input differently
    
    [ Upstream commit 05d6f442f31f901d27dbc64fd504a8ec7d5013de ]
    
    A bug occurs because a safety check guarding AF_XDP-related queues in
    ethnl_set_channels(), does not trigger. This happens, because kernel and
    ice driver interpret the ethtool command differently.
    
    How the bug occurs:
    1. ethtool -l <IFNAME> -> combined: 40
    2. Attach AF_XDP to queue 30
    3. ethtool -L <IFNAME> rx 15 tx 15
       combined number is not specified, so command becomes {rx_count = 15,
       tx_count = 15, combined_count = 40}.
    4. ethnl_set_channels checks, if there are any AF_XDP of queues from the
       new (combined_count + rx_count) to the old one, so from 55 to 40, check
       does not trigger.
    5. ice interprets `rx 15 tx 15` as 15 combined channels and deletes the
       queue that AF_XDP is attached to.
    
    Interpret the command in a way that is more consistent with ethtool
    manual [0] (--show-channels and --set-channels).
    
    Considering that in the ice driver only the difference between RX and TX
    queues forms dedicated channels, change the correct way to set number of
    channels to:
    
    ethtool -L <IFNAME> combined 10 /* For symmetric queues */
    ethtool -L <IFNAME> combined 8 tx 2 rx 0 /* For asymmetric queues */
    
    [0] https://man7.org/linux/man-pages/man8/ethtool.8.html
    
    Fixes: 87324e747fde ("ice: Implement ethtool ops for channels")
    Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
    Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
    Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com>
    Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: accel: mxc4005: allow module autoloading via OF compatible [+ + +]
Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
Date:   Wed Oct 4 18:39:28 2023 +0200

    iio: accel: mxc4005: allow module autoloading via OF compatible
    
    [ Upstream commit 4d7c16d08d248952c116f2eb9b7b5abc43a19688 ]
    
    Add OF device table with compatible strings to allow automatic module
    loading.
    
    Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20231004-mxc4005-device-tree-support-v1-2-e7c0faea72e4@bootlin.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 6b8cffdc4a31 ("iio: accel: mxc4005: Reset chip on probe() and resume()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: accel: mxc4005: Reset chip on probe() and resume() [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Mar 26 12:37:00 2024 +0100

    iio: accel: mxc4005: Reset chip on probe() and resume()
    
    [ Upstream commit 6b8cffdc4a31e4a72f75ecd1bc13fbf0dafee390 ]
    
    On some designs the chip is not properly reset when powered up at boot or
    after a suspend/resume cycle.
    
    Use the sw-reset feature to ensure that the chip is in a clean state
    after probe() / resume() and in the case of resume() restore the settings
    (scale, trigger-enabled).
    
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218578
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20240326113700.56725-3-hdegoede@redhat.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: ad9467: convert to backend framework [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Sat Feb 10 21:57:18 2024 +0100

    iio: adc: ad9467: convert to backend framework
    
    [ Upstream commit bb42191f85c389bf816373d25c3e4c94045cf4ff ]
    
    Convert the driver to use the new IIO backend framework. The device
    functionality is expected to be the same (meaning no added or removed
    features).
    
    Also note this patch effectively breaks ABI and that's needed so we can
    properly support this device and add needed features making use of the
    new IIO framework.
    
    Given the lack of features (and devices supported) in the ad9467 driver
    compared with the ADI out of tree version, we don't expect any user of
    the upstream driver so no one should notice the ABI breakage. However,
    if someone is affected by this, ADI will happily support transitioning
    to the backend framework.
    
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240210-iio-backend-v11-6-f5242a5fb42a@analog.com
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: ad9467: use chip_info variables instead of array [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Thu Dec 7 13:39:29 2023 +0100

    iio: adc: ad9467: use chip_info variables instead of array
    
    [ Upstream commit 6dd3fa9fcc66cb71834dc2e0a222324af0d8b95d ]
    
    Instead of having an array and keeping IDs for each entry of the array,
    just have a chip_info struct per device.
    
    Reviewed-by: David Lechner <dlechner@baylibre.com>
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-6-a4a33bc4d70e@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: ad9467: use spi_get_device_match_data() [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Thu Dec 7 13:39:28 2023 +0100

    iio: adc: ad9467: use spi_get_device_match_data()
    
    [ Upstream commit b67cc85d45d5d2894d0e2812bba27d7b23befbe6 ]
    
    Make use of spi_get_device_match_data() to simplify things.
    
    Reviewed-by: David Lechner <dlechner@baylibre.com>
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-5-a4a33bc4d70e@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: adi-axi-adc: convert to regmap [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Thu Dec 7 13:39:31 2023 +0100

    iio: adc: adi-axi-adc: convert to regmap
    
    [ Upstream commit 21aa971d3e295c2c81d0887f8a3e85a95dd687c5 ]
    
    Use MMIO regmap interface. It makes things easier for manipulating bits.
    
    Reviewed-by: David Lechner <dlechner@baylibre.com>
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-8-a4a33bc4d70e@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: adi-axi-adc: move to backend framework [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Sat Feb 10 21:57:19 2024 +0100

    iio: adc: adi-axi-adc: move to backend framework
    
    [ Upstream commit 794ef0e57854d794173c8ab6bcce3285032dcd95 ]
    
    Move to the IIO backend framework. Devices supported by adi-axi-adc now
    register themselves as backend devices.
    
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240210-iio-backend-v11-7-f5242a5fb42a@analog.com
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: adi-axi-adc: only error out in major version mismatch [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Fri Apr 19 17:36:45 2024 +0200

    iio: adc: adi-axi-adc: only error out in major version mismatch
    
    [ Upstream commit cf1c833f89e7c8635a28c3db15c68ead150ea712 ]
    
    The IP core only has breaking changes when there major version changes.
    Hence, only match the major number. This is also in line with the other
    core ADI has upstream. The current check for erroring out
    'expected_version > current_version"' is then wrong as we could just
    increase the core major with breaking changes and that would go
    unnoticed.
    
    Fixes: ef04070692a2 ("iio: adc: adi-axi-adc: add support for AXI ADC IP core")
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240419-ad9467-new-features-v1-2-3e7628ff6d5e@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: adc: stm32: Fixing err code to not indicate success [+ + +]
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat Mar 30 18:53:00 2024 +0000

    iio: adc: stm32: Fixing err code to not indicate success
    
    [ Upstream commit 3735ca0b072656c3aa2cedc617a5e639b583a472 ]
    
    This path would result in returning 0 / success on an error path.
    
    Cc: Olivier Moysan <olivier.moysan@foss.st.com>
    Fixes: 95bc818404b2 ("iio: adc: stm32-adc: add support of generic channels binding")
    Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Link: https://lore.kernel.org/r/20240330185305.1319844-4-jic23@kernel.org
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: add the IIO backend framework [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Sat Feb 10 21:57:17 2024 +0100

    iio: add the IIO backend framework
    
    [ Upstream commit 1a97905d3e48ebe79a06d16143fbfa427c56ce5f ]
    
    This is a Framework to handle complex IIO aggregate devices.
    
    The typical architecture is to have one device as the frontend device which
    can be "linked" against one or multiple backend devices. All the IIO and
    userspace interface is expected to be registers/managed by the frontend
    device which will callback into the backends when needed (to get/set
    some configuration that it does not directly control).
    
    The basic framework interface is pretty simple:
     - Backends should register themselves with @devm_iio_backend_register()
     - Frontend devices should get backends with @devm_iio_backend_get()
    
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240210-iio-backend-v11-5-f5242a5fb42a@analog.com
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: buffer-dmaengine: export buffer alloc and free functions [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Sat Feb 10 21:57:16 2024 +0100

    iio: buffer-dmaengine: export buffer alloc and free functions
    
    [ Upstream commit 9c446288d7b31402adb454535cb2c3cbdb55bb88 ]
    
    Export iio_dmaengine_buffer_free() and iio_dmaengine_buffer_alloc().
    This is in preparation of introducing IIO backends support. This will
    allow us to allocate a buffer and control it's lifetime from a device
    different from the one holding the DMA firmware properties. Effectively,
    in this case the struct device holding the firmware information about
    the DMA channels is not the same as iio_dev->dev.parent (typical case).
    
    While at it, namespace the buffer-dmaengine exports and update the
    current user of these buffers.
    
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240210-iio-backend-v11-4-f5242a5fb42a@analog.com
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: cf1c833f89e7 ("iio: adc: adi-axi-adc: only error out in major version mismatch")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: core: Leave private pointer NULL when no private data supplied [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Mar 4 16:04:32 2024 +0200

    iio: core: Leave private pointer NULL when no private data supplied
    
    [ Upstream commit f0245ab389330cbc1d187e358a5b890d9f5383db ]
    
    In iio_device_alloc() when size of the private data is 0,
    the private pointer is calculated to point behind the valid data.
    Leave it NULL when no private data supplied.
    
    Fixes: 6d4ebd565d15 ("iio: core: wrap IIO device into an iio_dev_opaque object")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: David Lechner <dlechner@baylibre.com>
    Link: https://lore.kernel.org/r/20240304140650.977784-2-andriy.shevchenko@linux.intel.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iio: pressure: dps310: support negative temperature values [+ + +]
Author: Thomas Haemmerle <thomas.haemmerle@leica-geosystems.com>
Date:   Mon Apr 15 12:50:27 2024 +0200

    iio: pressure: dps310: support negative temperature values
    
    [ Upstream commit 9dd6b32e76ff714308964cd9ec91466a343dcb8b ]
    
    The current implementation interprets negative values returned from
    `dps310_calculate_temp` as error codes.
    This has a side effect that when negative temperature values are
    calculated, they are interpreted as error.
    
    Fix this by using the return value only for error handling and passing a
    pointer for the value.
    
    Fixes: ba6ec48e76bc ("iio: Add driver for Infineon DPS310")
    Signed-off-by: Thomas Haemmerle <thomas.haemmerle@leica-geosystems.com>
    Link: https://lore.kernel.org/r/20240415105030.1161770-2-thomas.haemmerle@leica-geosystems.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: cyapa - add missing input core locking to suspend/resume functions [+ + +]
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Mon Oct 9 14:10:18 2023 +0200

    Input: cyapa - add missing input core locking to suspend/resume functions
    
    [ Upstream commit 7b4e0b39182cf5e677c1fc092a3ec40e621c25b6 ]
    
    Grab input->mutex during suspend/resume functions like it is done in
    other input drivers. This fixes the following warning during system
    suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:
    
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c
    Modules linked in: ...
    CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G        W          6.6.0-rc5-next-20231009 #14109
    Hardware name: Samsung Exynos (Flattened Device Tree)
    Workqueue: events_unbound async_run_entry_fn
     unwind_backtrace from show_stack+0x10/0x14
     show_stack from dump_stack_lvl+0x58/0x70
     dump_stack_lvl from __warn+0x1a8/0x1cc
     __warn from warn_slowpath_fmt+0x18c/0x1b4
     warn_slowpath_fmt from input_device_enabled+0x68/0x6c
     input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc
     cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c
     cyapa_reinitialize from cyapa_resume+0x48/0x98
     cyapa_resume from dpm_run_callback+0x90/0x298
     dpm_run_callback from device_resume+0xb4/0x258
     device_resume from async_resume+0x20/0x64
     async_resume from async_run_entry_fn+0x40/0x15c
     async_run_entry_fn from process_scheduled_works+0xbc/0x6a8
     process_scheduled_works from worker_thread+0x188/0x454
     worker_thread from kthread+0x108/0x140
     kthread from ret_from_fork+0x14/0x28
    Exception stack(0xf1625fb0 to 0xf1625ff8)
    ...
    ---[ end trace 0000000000000000 ]---
    ...
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c
    Modules linked in: ...
    CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G        W          6.6.0-rc5-next-20231009 #14109
    Hardware name: Samsung Exynos (Flattened Device Tree)
    Workqueue: events_unbound async_run_entry_fn
     unwind_backtrace from show_stack+0x10/0x14
     show_stack from dump_stack_lvl+0x58/0x70
     dump_stack_lvl from __warn+0x1a8/0x1cc
     __warn from warn_slowpath_fmt+0x18c/0x1b4
     warn_slowpath_fmt from input_device_enabled+0x68/0x6c
     input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc
     cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c
     cyapa_reinitialize from cyapa_resume+0x48/0x98
     cyapa_resume from dpm_run_callback+0x90/0x298
     dpm_run_callback from device_resume+0xb4/0x258
     device_resume from async_resume+0x20/0x64
     async_resume from async_run_entry_fn+0x40/0x15c
     async_run_entry_fn from process_scheduled_works+0xbc/0x6a8
     process_scheduled_works from worker_thread+0x188/0x454
     worker_thread from kthread+0x108/0x140
     kthread from ret_from_fork+0x14/0x28
    Exception stack(0xf1625fb0 to 0xf1625ff8)
    ...
    ---[ end trace 0000000000000000 ]---
    
    Fixes: d69f0a43c677 ("Input: use input_device_enabled()")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
    Link: https://lore.kernel.org/r/20231009121018.1075318-1-m.szyprowski@samsung.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: ims-pcu - fix printf string overflow [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 28 13:28:56 2024 -0700

    Input: ims-pcu - fix printf string overflow
    
    [ Upstream commit bf32bceedd0453c70d9d022e2e29f98e446d7161 ]
    
    clang warns about a string overflow in this driver
    
    drivers/input/misc/ims-pcu.c:1802:2: error: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Werror,-Wformat-truncation]
    drivers/input/misc/ims-pcu.c:1814:2: error: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Werror,-Wformat-truncation]
    
    Make the buffer a little longer to ensure it always fits.
    
    Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240326223825.4084412-7-arnd@kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: pm8xxx-vibrator - correct VIB_MAX_LEVELS calculation [+ + +]
Author: Fenglin Wu <quic_fenglinw@quicinc.com>
Date:   Mon Apr 15 16:03:40 2024 -0700

    Input: pm8xxx-vibrator - correct VIB_MAX_LEVELS calculation
    
    [ Upstream commit 48c0687a322d54ac7e7a685c0b6db78d78f593af ]
    
    The output voltage is inclusive hence the max level calculation is
    off-by-one-step. Correct it.
    
    iWhile we are at it also add a define for the step size instead of
    using the magic value.
    
    Fixes: 11205bb63e5c ("Input: add support for pm8xxx based vibrator driver")
    Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20240412-pm8xxx-vibrator-new-design-v10-1-0ec0ad133866@quicinc.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Input: try trimming too long modalias strings [+ + +]
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Mon Apr 29 14:50:41 2024 -0700

    Input: try trimming too long modalias strings
    
    commit 0774d19038c496f0c3602fb505c43e1b2d8eed85 upstream.
    
    If an input device declares too many capability bits then modalias
    string for such device may become too long and not fit into uevent
    buffer, resulting in failure of sending said uevent. This, in turn,
    may prevent userspace from recognizing existence of such devices.
    
    This is typically not a concern for real hardware devices as they have
    limited number of keys, but happen with synthetic devices such as
    ones created by xen-kbdfront driver, which creates devices as being
    capable of delivering all possible keys, since it doesn't know what
    keys the backend may produce.
    
    To deal with such devices input core will attempt to trim key data,
    in the hope that the rest of modalias string will fit in the given
    buffer. When trimming key data it will indicate that it is not
    complete by placing "+," sign, resulting in conversions like this:
    
    old: k71,72,73,74,78,7A,7B,7C,7D,8E,9E,A4,AD,E0,E1,E4,F8,174,
    new: k71,72,73,74,78,7A,7B,7C,+,
    
    This should allow existing udev rules continue to work with existing
    devices, and will also allow writing more complex rules that would
    recognize trimmed modalias and check input device characteristics by
    other means (for example by parsing KEY= data in uevent or parsing
    input device sysfs attributes).
    
    Note that the driver core may try adding more uevent environment
    variables once input core is done adding its own, so when forming
    modalias we can not use the entire available buffer, so we reduce
    it by somewhat an arbitrary amount (96 bytes).
    
    Reported-by: Jason Andryuk <jandryuk@gmail.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    Tested-by: Jason Andryuk <jandryuk@gmail.com>
    Link: https://lore.kernel.org/r/ZjAWMQCJdrxZkvkB@google.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Input: xpad - add support for ASUS ROG RAIKIRI [+ + +]
Author: Vicki Pfau <vi@endrift.com>
Date:   Wed Apr 3 20:53:45 2024 -0700

    Input: xpad - add support for ASUS ROG RAIKIRI
    
    [ Upstream commit be81415a32ef6d8a8a85529fcfac03d05b3e757d ]
    
    Add the VID/PID for ASUS ROG RAIKIRI to xpad_device and the VID to xpad_table
    
    Signed-off-by: Vicki Pfau <vi@endrift.com>
    Link: https://lore.kernel.org/r/20240404035345.159643-1-vi@endrift.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
interconnect: qcom: qcm2290: Fix mas_snoc_bimc QoS port assignment [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Mar 26 20:42:33 2024 +0100

    interconnect: qcom: qcm2290: Fix mas_snoc_bimc QoS port assignment
    
    [ Upstream commit 230d05b1179f6ce6f8dc8a2b99eba92799ac22d7 ]
    
    The value was wrong, resulting in misprogramming of the hardware.
    Fix it.
    
    Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://lore.kernel.org/r/20240326-topic-rpm_icc_qos_cleanup-v1-2-357e736792be@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io-wq: write next_work before dropping acct_lock [+ + +]
Author: Gabriel Krisman Bertazi <krisman@suse.de>
Date:   Mon Apr 15 22:10:53 2024 -0400

    io-wq: write next_work before dropping acct_lock
    
    [ Upstream commit 068c27e32e51e94e4a9eb30ae85f4097a3602980 ]
    
    Commit 361aee450c6e ("io-wq: add intermediate work step between pending
    list and active work") closed a race between a cancellation and the work
    being removed from the wq for execution.  To ensure the request is
    always reachable by the cancellation, we need to move it within the wq
    lock, which also synchronizes the cancellation.  But commit
    42abc95f05bf ("io-wq: decouple work_list protection from the big
    wqe->lock") replaced the wq lock here and accidentally reintroduced the
    race by releasing the acct_lock too early.
    
    In other words:
    
            worker                |     cancellation
    work = io_get_next_work()     |
    raw_spin_unlock(&acct->lock); |
                                  |
                                  | io_acct_cancel_pending_work
                                  | io_wq_worker_cancel()
    worker->next_work = work
    
    Using acct_lock is still enough since we synchronize on it on
    io_acct_cancel_pending_work.
    
    Fixes: 42abc95f05bf ("io-wq: decouple work_list protection from the big wqe->lock")
    Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
    Link: https://lore.kernel.org/r/20240416021054.3940-2-krisman@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring: fail NOP if non-zero op flags is passed in [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Fri May 10 11:50:27 2024 +0800

    io_uring: fail NOP if non-zero op flags is passed in
    
    commit 3d8f874bd620ce03f75a5512847586828ab86544 upstream.
    
    The NOP op flags should have been checked from beginning like any other
    opcode, otherwise NOP may not be extended with the op flags.
    
    Given both liburing and Rust io-uring crate always zeros SQE op flags, just
    ignore users which play raw NOP uring interface without zeroing SQE, because
    NOP is just for test purpose. Then we can save one NOP2 opcode.
    
    Suggested-by: Jens Axboe <axboe@kernel.dk>
    Fixes: 2b188cc1bb85 ("Add io_uring IO interface")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20240510035031.78874-2-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

io_uring: use the right type for work_llist empty check [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Mon Mar 25 18:53:33 2024 -0600

    io_uring: use the right type for work_llist empty check
    
    [ Upstream commit 22537c9f79417fed70b352d54d01d2586fee9521 ]
    
    io_task_work_pending() uses wq_list_empty() on ctx->work_llist, but it's
    not an io_wq_work_list, it's a struct llist_head. They both have
    ->first as head-of-list, and it turns out the checks are identical. But
    be proper and use the right helper.
    
    Fixes: dac6a0eae793 ("io_uring: ensure iopoll runs local task work as well")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu: Undo pasid attachment only for the devices that have succeeded [+ + +]
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Thu Mar 28 05:29:57 2024 -0700

    iommu: Undo pasid attachment only for the devices that have succeeded
    
    [ Upstream commit b025dea63cded0d82bccd591fa105d39efc6435d ]
    
    There is no error handling now in __iommu_set_group_pasid(), it relies on
    its caller to loop all the devices to undo the pasid attachment. This is
    not self-contained and has drawbacks. It would result in unnecessary
    remove_dev_pasid() calls on the devices that have not been attached to the
    new domain. But the remove_dev_pasid() callback would get the new domain
    from the group->pasid_array. So for such devices, the iommu driver won't
    find the attachment under the domain, hence unable to do cleanup. This may
    not be a real problem today. But it depends on the implementation of the
    underlying iommu driver. e.g. the intel iommu driver would warn for such
    devices. Such warnings are unnecessary.
    
    To solve the above problem, it is necessary to handle the error within
    __iommu_set_group_pasid(). It only loops the devices that have attached
    to the new domain, and undo it.
    
    Fixes: 16603704559c ("iommu: Add attach/detach_dev_pasid iommu interfaces")
    Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Signed-off-by: Yi Liu <yi.l.liu@intel.com>
    Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
    Link: https://lore.kernel.org/r/20240328122958.83332-2-yi.l.liu@intel.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: sr: add missing seg6_local_exit [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu May 9 21:18:10 2024 +0800

    ipv6: sr: add missing seg6_local_exit
    
    [ Upstream commit 3321687e321307629c71b664225b861ebf3e5753 ]
    
    Currently, we only call seg6_local_exit() in seg6_init() if
    seg6_local_init() failed. But forgot to call it in seg6_exit().
    
    Fixes: d1df6fd8a1d2 ("ipv6: sr: define core operations for seg6local lightweight tunnel")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20240509131812.1662197-2-liuhangbin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: sr: fix incorrect unregister order [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu May 9 21:18:11 2024 +0800

    ipv6: sr: fix incorrect unregister order
    
    [ Upstream commit 6e370a771d2985107e82d0f6174381c1acb49c20 ]
    
    Commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and
    null-ptr-deref") changed the register order in seg6_init(). But the
    unregister order in seg6_exit() is not updated.
    
    Fixes: 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20240509131812.1662197-3-liuhangbin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: sr: fix invalid unregister error path [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu May 9 21:18:12 2024 +0800

    ipv6: sr: fix invalid unregister error path
    
    [ Upstream commit 160e9d2752181fcf18c662e74022d77d3164cd45 ]
    
    The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL
    is not defined. In that case if seg6_hmac_init() fails, the
    genl_unregister_family() isn't called.
    
    This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control
    lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible
    use-after-free and null-ptr-deref") replaced unregister_pernet_subsys()
    with genl_unregister_family() in this error path.
    
    Fixes: 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support")
    Reported-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20240509131812.1662197-4-liuhangbin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: sr: fix memleak in seg6_hmac_init_algo [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Fri May 17 08:54:35 2024 +0800

    ipv6: sr: fix memleak in seg6_hmac_init_algo
    
    [ Upstream commit efb9f4f19f8e37fde43dfecebc80292d179f56c6 ]
    
    seg6_hmac_init_algo returns without cleaning up the previous allocations
    if one fails, so it's going to leak all that memory and the crypto tfms.
    
    Update seg6_hmac_exit to only free the memory when allocated, so we can
    reuse the code directly.
    
    Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support")
    Reported-by: Sabrina Dubroca <sd@queasysnail.net>
    Closes: https://lore.kernel.org/netdev/Zj3bh-gE7eT6V6aH@hog/
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Link: https://lore.kernel.org/r/20240517005435.2600277-1-liuhangbin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: sr: fix missing sk_buff release in seg6_input_core [+ + +]
Author: Andrea Mayer <andrea.mayer@uniroma2.it>
Date:   Fri May 17 18:45:41 2024 +0200

    ipv6: sr: fix missing sk_buff release in seg6_input_core
    
    [ Upstream commit 5447f9708d9e4c17a647b16a9cb29e9e02820bd9 ]
    
    The seg6_input() function is responsible for adding the SRH into a
    packet, delegating the operation to the seg6_input_core(). This function
    uses the skb_cow_head() to ensure that there is sufficient headroom in
    the sk_buff for accommodating the link-layer header.
    In the event that the skb_cow_header() function fails, the
    seg6_input_core() catches the error but it does not release the sk_buff,
    which will result in a memory leak.
    
    This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due
    to headroom too small after SRH push") and persists even after commit
    7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"),
    where the entire seg6_input() code was refactored to deal with netfilter
    hooks.
    
    The proposed patch addresses the identified memory leak by requiring the
    seg6_input_core() function to release the sk_buff in the event that
    skb_cow_head() fails.
    
    Fixes: af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push")
    Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound [+ + +]
Author: Yue Haibing <yuehaibing@huawei.com>
Date:   Wed May 29 17:56:33 2024 +0800

    ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
    
    [ Upstream commit b3dc6e8003b500861fa307e9a3400c52e78e4d3a ]
    
    Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will
    hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.
    
    WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70
    Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper
    CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    RIP: 0010:sk_mc_loop+0x2d/0x70
    Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c
    RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212
    RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001
    RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000
    RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00
    R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000
    R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000
    FS:  0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <IRQ>
     ? __warn (kernel/panic.c:693)
     ? sk_mc_loop (net/core/sock.c:760)
     ? report_bug (lib/bug.c:201 lib/bug.c:219)
     ? handle_bug (arch/x86/kernel/traps.c:239)
     ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
     ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)
     ? sk_mc_loop (net/core/sock.c:760)
     ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))
     ? nf_hook_slow (net/netfilter/core.c:626)
     ip6_finish_output (net/ipv6/ip6_output.c:222)
     ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)
     ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan
     ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan
     dev_hard_start_xmit (net/core/dev.c:3594)
     sch_direct_xmit (net/sched/sch_generic.c:343)
     __qdisc_run (net/sched/sch_generic.c:416)
     net_tx_action (net/core/dev.c:5286)
     handle_softirqs (kernel/softirq.c:555)
     __irq_exit_rcu (kernel/softirq.c:589)
     sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)
    
    The warning triggers as this:
    packet_sendmsg
       packet_snd //skb->sk is packet sk
          __dev_queue_xmit
             __dev_xmit_skb //q->enqueue is not NULL
                 __qdisc_run
                   sch_direct_xmit
                     dev_hard_start_xmit
                       ipvlan_start_xmit
                          ipvlan_xmit_mode_l3 //l3 mode
                            ipvlan_process_outbound //vepa flag
                              ipvlan_process_v6_outbound
                                ip6_local_out
                                    __ip6_finish_output
                                      ip6_finish_output2 //multicast packet
                                        sk_mc_loop //sk->sk_family is AF_PACKET
    
    Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.
    
    Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240529095633.613103-1-yuehaibing@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/alpine-msi: Fix off-by-one in allocation error path [+ + +]
Author: Zenghui Yu <yuzenghui@huawei.com>
Date:   Wed Mar 27 22:23:05 2024 +0800

    irqchip/alpine-msi: Fix off-by-one in allocation error path
    
    [ Upstream commit ff3669a71afa06208de58d6bea1cc49d5e3fcbd1 ]
    
    When alpine_msix_gic_domain_alloc() fails, there is an off-by-one in the
    number of interrupts to be freed.
    
    Fix it by passing the number of successfully allocated interrupts, instead
    of the relative index of the last allocated one.
    
    Fixes: 3841245e8498 ("irqchip/alpine-msi: Fix freeing of interrupts on allocation error path")
    Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20240327142305.1048-1-yuzenghui@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/loongson-pch-msi: Fix off-by-one on allocation error path [+ + +]
Author: Zenghui Yu <yuzenghui@huawei.com>
Date:   Wed Mar 27 22:23:34 2024 +0800

    irqchip/loongson-pch-msi: Fix off-by-one on allocation error path
    
    [ Upstream commit b327708798809328f21da8dc14cc8883d1e8a4b3 ]
    
    When pch_msi_parent_domain_alloc() returns an error, there is an off-by-one
    in the number of interrupts to be freed.
    
    Fix it by passing the number of successfully allocated interrupts, instead of the
    relative index of the last allocated one.
    
    Fixes: 632dcc2c75ef ("irqchip: Add Loongson PCH MSI controller")
    Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Link: https://lore.kernel.org/r/20240327142334.1098-1-yuzenghui@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jffs2: prevent xattr node from overflowing the eraseblock [+ + +]
Author: Ilya Denisyev <dev@elkcl.ru>
Date:   Fri Apr 12 18:53:54 2024 +0300

    jffs2: prevent xattr node from overflowing the eraseblock
    
    [ Upstream commit c6854e5a267c28300ff045480b5a7ee7f6f1d913 ]
    
    Add a check to make sure that the requested xattr node size is no larger
    than the eraseblock minus the cleanmarker.
    
    Unlike the usual inode nodes, the xattr nodes aren't split into parts
    and spread across multiple eraseblocks, which means that a xattr node
    must not occupy more than one eraseblock. If the requested xattr value is
    too large, the xattr node can spill onto the next eraseblock, overwriting
    the nodes and causing errors such as:
    
    jffs2: argh. node added in wrong place at 0x0000b050(2)
    jffs2: nextblock 0x0000a000, expected at 0000b00c
    jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
    read=0xfc892c93, calc=0x000000
    jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
    at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
    jffs2: Node at 0x0000000c with length 0x00001044 would run over the
    end of the erase block
    jffs2: Perhaps the file system was created with the wrong erase size?
    jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
    at 0x00000010: 0x1044 instead
    
    This breaks the filesystem and can lead to KASAN crashes such as:
    
    BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
    Read of size 4 at addr ffff88802c31e914 by task repro/830
    CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS Arch Linux 1.16.3-1-1 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0xc6/0x120
     print_report+0xc4/0x620
     ? __virt_addr_valid+0x308/0x5b0
     kasan_report+0xc1/0xf0
     ? jffs2_sum_add_kvec+0x125e/0x15d0
     ? jffs2_sum_add_kvec+0x125e/0x15d0
     jffs2_sum_add_kvec+0x125e/0x15d0
     jffs2_flash_direct_writev+0xa8/0xd0
     jffs2_flash_writev+0x9c9/0xef0
     ? __x64_sys_setxattr+0xc4/0x160
     ? do_syscall_64+0x69/0x140
     ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
     [...]
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)")
    Signed-off-by: Ilya Denisyev <dev@elkcl.ru>
    Link: https://lore.kernel.org/r/20240412155357.237803-1-dev@elkcl.ru
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kasan, fortify: properly rename memintrinsics [+ + +]
Author: Andrey Konovalov <andreyknvl@gmail.com>
Date:   Fri May 17 15:01:18 2024 +0200

    kasan, fortify: properly rename memintrinsics
    
    [ Upstream commit 2e577732e8d28b9183df701fb90cb7943aa4ed16 ]
    
    After commit 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*()
    functions") and the follow-up fixes, with CONFIG_FORTIFY_SOURCE enabled,
    even though the compiler instruments meminstrinsics by generating calls to
    __asan/__hwasan_ prefixed functions, FORTIFY_SOURCE still uses
    uninstrumented memset/memmove/memcpy as the underlying functions.
    
    As a result, KASAN cannot detect bad accesses in memset/memmove/memcpy.
    This also makes KASAN tests corrupt kernel memory and cause crashes.
    
    To fix this, use __asan_/__hwasan_memset/memmove/memcpy as the underlying
    functions whenever appropriate.  Do this only for the instrumented code
    (as indicated by __SANITIZE_ADDRESS__).
    
    Link: https://lkml.kernel.org/r/20240517130118.759301-1-andrey.konovalov@linux.dev
    Fixes: 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions")
    Fixes: 51287dcb00cc ("kasan: emit different calls for instrumentable memintrinsics")
    Fixes: 36be5cba99f6 ("kasan: treat meminstrinsic as builtins in uninstrumented files")
    Signed-off-by: Andrey Konovalov <andreyknvl@gmail.com>
    Reported-by: Erhard Furtner <erhard_f@mailbox.org>
    Reported-by: Nico Pache <npache@redhat.com>
    Closes: https://lore.kernel.org/all/20240501144156.17e65021@outsider.home/
    Reviewed-by: Marco Elver <elver@google.com>
    Tested-by: Nico Pache <npache@redhat.com>
    Acked-by: Nico Pache <npache@redhat.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Daniel Axtens <dja@axtens.net>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kbuild: fix build ID symlinks to installed debug VDSO files [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Wed Dec 20 17:18:33 2023 +0900

    kbuild: fix build ID symlinks to installed debug VDSO files
    
    [ Upstream commit c1a8627164dbe8b92958aea10c7c0848105a3d7f ]
    
    Commit 56769ba4b297 ("kbuild: unify vdso_install rules") accidentally
    dropped the '.debug' suffix from the build ID symlinks.
    
    Fixes: 56769ba4b297 ("kbuild: unify vdso_install rules")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

kbuild: unify vdso_install rules [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Oct 14 19:54:35 2023 +0900

    kbuild: unify vdso_install rules
    
    [ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ]
    
    Currently, there is no standard implementation for vdso_install,
    leading to various issues:
    
     1. Code duplication
    
        Many architectures duplicate similar code just for copying files
        to the install destination.
    
        Some architectures (arm, sparc, x86) create build-id symlinks,
        introducing more code duplication.
    
     2. Unintended updates of in-tree build artifacts
    
        The vdso_install rule depends on the vdso files to install.
        It may update in-tree build artifacts. This can be problematic,
        as explained in commit 19514fc665ff ("arm, kbuild: make
        "make install" not depend on vmlinux").
    
     3. Broken code in some architectures
    
        Makefile code is often copied from one architecture to another
        without proper adaptation.
    
        'make vdso_install' for parisc does not work.
    
        'make vdso_install' for s390 installs vdso64, but not vdso32.
    
    To address these problems, this commit introduces a generic vdso_install
    rule.
    
    Architectures that support vdso_install need to define vdso-install-y
    in arch/*/Makefile. vdso-install-y lists the files to install.
    
    For example, arch/x86/Makefile looks like this:
    
      vdso-install-$(CONFIG_X86_64)           += arch/x86/entry/vdso/vdso64.so.dbg
      vdso-install-$(CONFIG_X86_X32_ABI)      += arch/x86/entry/vdso/vdsox32.so.dbg
      vdso-install-$(CONFIG_X86_32)           += arch/x86/entry/vdso/vdso32.so.dbg
      vdso-install-$(CONFIG_IA32_EMULATION)   += arch/x86/entry/vdso/vdso32.so.dbg
    
    These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
    if exists, stripped away.
    
    vdso-install-y can optionally take the second field after the colon
    separator. This is needed because some architectures install a vdso
    file as a different base name.
    
    The following is a snippet from arch/arm64/Makefile.
    
      vdso-install-$(CONFIG_COMPAT_VDSO)      += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
    
    This will rename vdso.so.dbg to vdso32.so during installation. If such
    architectures change their implementation so that the base names match,
    this workaround will go away.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
    Reviewed-by: Guo Ren <guoren@kernel.org>
    Acked-by: Helge Deller <deller@gmx.de>  # parisc
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kconfig: fix comparison to constant symbols, 'm', 'n' [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun May 19 18:22:27 2024 +0900

    kconfig: fix comparison to constant symbols, 'm', 'n'
    
    [ Upstream commit aabdc960a283ba78086b0bf66ee74326f49e218e ]
    
    Currently, comparisons to 'm' or 'n' result in incorrect output.
    
    [Test Code]
    
        config MODULES
                def_bool y
                modules
    
        config A
                def_tristate m
    
        config B
                def_bool A > n
    
    CONFIG_B is unset, while CONFIG_B=y is expected.
    
    The reason for the issue is because Kconfig compares the tristate values
    as strings.
    
    Currently, the .type fields in the constant symbol definitions,
    symbol_{yes,mod,no} are unspecified, i.e., S_UNKNOWN.
    
    When expr_calc_value() evaluates 'A > n', it checks the types of 'A' and
    'n' to determine how to compare them.
    
    The left-hand side, 'A', is a tristate symbol with a value of 'm', which
    corresponds to a numeric value of 1. (Internally, 'y', 'm', and 'n' are
    represented as 2, 1, and 0, respectively.)
    
    The right-hand side, 'n', has an unknown type, so it is treated as the
    string "n" during the comparison.
    
    expr_calc_value() compares two values numerically only when both can
    have numeric values. Otherwise, they are compared as strings.
    
        symbol    numeric value    ASCII code
        -------------------------------------
          y           2             0x79
          m           1             0x6d
          n           0             0x6e
    
    'm' is greater than 'n' if compared numerically (since 1 is greater
    than 0), but smaller than 'n' if compared as strings (since the ASCII
    code 0x6d is smaller than 0x6e).
    
    Specifying .type=S_TRISTATE for symbol_{yes,mod,no} fixes the above
    test code.
    
    Doing so, however, would cause a regression to the following test code.
    
    [Test Code 2]
    
        config MODULES
                def_bool n
                modules
    
        config A
                def_tristate n
    
        config B
                def_bool A = m
    
    You would get CONFIG_B=y, while CONFIG_B should not be set.
    
    The reason is because sym_get_string_value() turns 'm' into 'n' when the
    module feature is disabled. Consequently, expr_calc_value() evaluates
    'A = n' instead of 'A = m'. This oddity has been hidden because the type
    of 'm' was previously S_UNKNOWN instead of S_TRISTATE.
    
    sym_get_string_value() should not tweak the string because the tristate
    value has already been correctly calculated. There is no reason to
    return the string "n" where its tristate value is mod.
    
    Fixes: 31847b67bec0 ("kconfig: allow use of relations other than (in)equality")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kernel/numa.c: Move logging out of numa.h [+ + +]
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Mon Dec 11 13:27:00 2023 -0500

    kernel/numa.c: Move logging out of numa.h
    
    [ Upstream commit d7a73e3f089204aee3393687e23fd45a22657b08 ]
    
    Moving these stub functions to a .c file means we can kill a sched.h
    dependency on printk.h.
    
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Stable-dep-of: f9f67e5adc8d ("x86/numa: Fix SRAT lookup of CFMWS ranges with numa_fill_memblks()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KEYS: asymmetric: Add missing dependencies of FIPS_SIGNATURE_SELFTEST [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Apr 22 14:10:41 2024 -0700

    KEYS: asymmetric: Add missing dependencies of FIPS_SIGNATURE_SELFTEST
    
    commit 9d2fd8bdc12f403a5c35c971936a0e1d5cb5108e upstream.
    
    Since the signature self-test uses RSA and SHA-256, it must only be
    enabled when those algorithms are enabled.  Otherwise it fails and
    panics the kernel on boot-up.
    
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202404221528.51d75177-lkp@intel.com
    Fixes: 3cde3174eb91 ("certs: Add FIPS selftests")
    Cc: stable@vger.kernel.org
    Cc: Simo Sorce <simo@redhat.com>
    Cc: David Howells <dhowells@redhat.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KEYS: asymmetric: Add missing dependency on CRYPTO_SIG [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Apr 22 14:08:45 2024 -0700

    KEYS: asymmetric: Add missing dependency on CRYPTO_SIG
    
    commit dcaa86b904ea3761e62c849957dd0904e126bf4a upstream.
    
    Make ASYMMETRIC_PUBLIC_KEY_SUBTYPE select CRYPTO_SIG to avoid build
    errors like the following, which were possible with
    CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y && CONFIG_CRYPTO_SIG=n:
    
        ld: vmlinux.o: in function `public_key_verify_signature':
        (.text+0x306280): undefined reference to `crypto_alloc_sig'
        ld: (.text+0x306300): undefined reference to `crypto_sig_set_pubkey'
        ld: (.text+0x306324): undefined reference to `crypto_sig_verify'
        ld: (.text+0x30636c): undefined reference to `crypto_sig_set_privkey'
    
    Fixes: 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists")
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kheaders: use `command -v` to test for existence of `cpio` [+ + +]
Author: Miguel Ojeda <ojeda@kernel.org>
Date:   Tue May 28 18:31:50 2024 +0200

    kheaders: use `command -v` to test for existence of `cpio`
    
    [ Upstream commit 6e58e0173507e506a5627741358bc770f220e356 ]
    
    Commit 13e1df09284d ("kheaders: explicitly validate existence of cpio
    command") added an explicit check for `cpio` using `type`.
    
    However, `type` in `dash` (which is used in some popular distributions
    and base images as the shell script runner) prints the missing message
    to standard output, and thus no error is printed:
    
        $ bash -c 'type missing >/dev/null'
        bash: line 1: type: missing: not found
        $ dash -c 'type missing >/dev/null'
        $
    
    For instance, this issue may be seen by loongarch builders, given its
    defconfig enables CONFIG_IKHEADERS since commit 9cc1df421f00 ("LoongArch:
    Update Loongson-3 default config file").
    
    Therefore, use `command -v` instead to have consistent behavior, and
    take the chance to provide a more explicit error.
    
    Fixes: 13e1df09284d ("kheaders: explicitly validate existence of cpio command")
    Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: avoid to send duplicate oplock break notifications [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Thu May 9 15:25:39 2024 +0900

    ksmbd: avoid to send duplicate oplock break notifications
    
    commit c91ecba9e421e4f2c9219cf5042fa63a12025310 upstream.
    
    This patch fixes generic/011 when oplocks is enable.
    
    Avoid to send duplicate oplock break notifications like smb2 leases
    case.
    
    Fixes: 97c2ec64667b ("ksmbd: avoid to send duplicate lease break notifications")
    Cc: stable@vger.kernel.org
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: fix uninitialized symbol 'share' in smb2_tree_connect() [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Wed Apr 24 16:57:01 2024 +0900

    ksmbd: fix uninitialized symbol 'share' in smb2_tree_connect()
    
    [ Upstream commit bc642d7bfdac3bfd838a1cd6651955ae2eb8535a ]
    
    Fix uninitialized symbol 'share' in smb2_tree_connect().
    
    Fixes: e9d8c2f95ab8 ("ksmbd: add continuous availability share parameter")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ksmbd: ignore trailing slashes in share paths [+ + +]
Author: Nandor Kracser <bonifaido@gmail.com>
Date:   Tue May 21 22:56:17 2024 +0900

    ksmbd: ignore trailing slashes in share paths
    
    commit 405ee4097c4bc3e70556520aed5ba52a511c2266 upstream.
    
    Trailing slashes in share paths (like: /home/me/Share/) caused permission
    issues with shares for clients on iOS and on Android TV for me,
    but otherwise they work fine with plain old Samba.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Nandor Kracser <bonifaido@gmail.com>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kthread: add kthread_stop_put [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Fri Sep 8 01:40:48 2023 +0200

    kthread: add kthread_stop_put
    
    [ Upstream commit 6309727ef27162deabd5c095c11af24970fba5a2 ]
    
    Add a kthread_stop_put() helper that stops a thread and puts its task
    struct.  Use it to replace the various instances of kthread_stop()
    followed by put_task_struct().
    
    Remove the kthread_stop_put() macro in usbip that is similar but doesn't
    return the result of kthread_stop().
    
    [agruenba@redhat.com: fix kerneldoc comment]
      Link: https://lkml.kernel.org/r/20230911111730.2565537-1-agruenba@redhat.com
    [akpm@linux-foundation.org: document kthread_stop_put()'s argument]
    Link: https://lkml.kernel.org/r/20230907234048.2499820-1-agruenba@redhat.com
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: bb9025f4432f ("dma-mapping: benchmark: fix up kthread-related error handling")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kunit/fortify: Fix mismatched kvalloc()/vfree() usage [+ + +]
Author: Kees Cook <kees@kernel.org>
Date:   Thu Apr 25 16:06:22 2024 -0700

    kunit/fortify: Fix mismatched kvalloc()/vfree() usage
    
    [ Upstream commit 998b18072ceb0613629c256b409f4d299829c7ec ]
    
    The kv*() family of tests were accidentally freeing with vfree() instead
    of kvfree(). Use kvfree() instead.
    
    Fixes: 9124a2640148 ("kunit/fortify: Validate __alloc_size attribute results")
    Link: https://lore.kernel.org/r/20240425230619.work.299-kees@kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kunit: Fix kthread reference [+ + +]
Author: Mickaël Salaün <mic@digikod.net>
Date:   Mon Apr 8 09:46:20 2024 +0200

    kunit: Fix kthread reference
    
    [ Upstream commit f8aa1b98ce40184521ed95ec26cc115a255183b2 ]
    
    There is a race condition when a kthread finishes after the deadline and
    before the call to kthread_stop(), which may lead to use after free.
    
    Cc: Brendan Higgins <brendanhiggins@google.com>
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Fixes: adf505457032 ("kunit: fix UAF when run kfence test case test_gfpzero")
    Reviewed-by: David Gow <davidgow@google.com>
    Reviewed-by: Rae Moar <rmoar@google.com>
    Signed-off-by: Mickaël Salaün <mic@digikod.net>
    Link: https://lore.kernel.org/r/20240408074625.65017-3-mic@digikod.net
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: selftests: Add test for uaccesses to non-existent vgic-v2 CPUIF [+ + +]
Author: Oliver Upton <oliver.upton@linux.dev>
Date:   Wed Apr 24 17:39:59 2024 +0000

    KVM: selftests: Add test for uaccesses to non-existent vgic-v2 CPUIF
    
    [ Upstream commit 160933e330f4c5a13931d725a4d952a4b9aefa71 ]
    
    Assert that accesses to a non-existent vgic-v2 CPU interface
    consistently fail across the various KVM device attr ioctls. This also
    serves as a regression test for a bug wherein KVM hits a NULL
    dereference when the CPUID specified in the ioctl is invalid.
    
    Note that there is no need to print the observed errno, as TEST_ASSERT()
    will take care of it.
    
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20240424173959.3776798-3-oliver.upton@linux.dev
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86: Don't advertise guest.MAXPHYADDR as host.MAXPHYADDR in CPUID [+ + +]
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Wed Mar 13 13:58:42 2024 +0100

    KVM: x86: Don't advertise guest.MAXPHYADDR as host.MAXPHYADDR in CPUID
    
    commit 6f5c9600621b4efb5c61b482d767432eb1ad3a9c upstream.
    
    Drop KVM's propagation of GuestPhysBits (CPUID leaf 80000008, EAX[23:16])
    to HostPhysBits (same leaf, EAX[7:0]) when advertising the address widths
    to userspace via KVM_GET_SUPPORTED_CPUID.
    
    Per AMD, GuestPhysBits is intended for software use, and physical CPUs do
    not set that field.  I.e. GuestPhysBits will be non-zero if and only if
    KVM is running as a nested hypervisor, and in that case, GuestPhysBits is
    NOT guaranteed to capture the CPU's effective MAXPHYADDR when running with
    TDP enabled.
    
    E.g. KVM will soon use GuestPhysBits to communicate the CPU's maximum
    *addressable* guest physical address, which would result in KVM under-
    reporting PhysBits when running as an L1 on a CPU with MAXPHYADDR=52,
    but without 5-level paging.
    
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
    Link: https://lore.kernel.org/r/20240313125844.912415-2-kraxel@redhat.com
    [sean: rewrite changelog with --verbose, Cc stable@]
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
leds: pwm: Disable PWM when going to suspend [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Apr 17 17:38:47 2024 +0200

    leds: pwm: Disable PWM when going to suspend
    
    [ Upstream commit 974afccd37947a6951a052ef8118c961e57eaf7b ]
    
    On stm32mp1xx based machines (and others) a PWM consumer has to disable
    the PWM because an enabled PWM refuses to suspend. So check the
    LED_SUSPENDED flag and depending on that set the .enabled property.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218559
    Fixes: 76fe464c8e64 ("leds: pwm: Don't disable the PWM when the LED should be off")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20240417153846.271751-2-u.kleine-koenig@pengutronix.de
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Tue Mar 12 08:59:05 2024 +0800

    lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure
    
    [ Upstream commit c2af060d1c18beaec56351cf9c9bcbbc5af341a3 ]
    
    The kcalloc() in dmirror_device_evict_chunk() will return null if the
    physical memory has run out.  As a result, if src_pfns or dst_pfns is
    dereferenced, the null pointer dereference bug will happen.
    
    Moreover, the device is going away.  If the kcalloc() fails, the pages
    mapping a chunk could not be evicted.  So add a __GFP_NOFAIL flag in
    kcalloc().
    
    Finally, as there is no need to have physically contiguous memory, Switch
    kcalloc() to kvcalloc() in order to avoid failing allocations.
    
    Link: https://lkml.kernel.org/r/20240312005905.9939-1-duoming@zju.edu.cn
    Fixes: b2ef9f5a5cb3 ("mm/hmm/test: add selftest driver for HMM")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Cc: Jérôme Glisse <jglisse@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libbpf: Fix error message in attach_kprobe_multi [+ + +]
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Thu May 2 09:55:41 2024 +0200

    libbpf: Fix error message in attach_kprobe_multi
    
    [ Upstream commit 7c13ef16e87ac2e44d16c0468b1191bceb06f95c ]
    
    We just failed to retrieve pattern, so we need to print spec instead.
    
    Fixes: ddc6b04989eb ("libbpf: Add bpf_program__attach_kprobe_multi_opts function")
    Reported-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20240502075541.1425761-2-jolsa@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libsubcmd: Fix parse-options memory leak [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Wed May 8 22:20:15 2024 -0700

    libsubcmd: Fix parse-options memory leak
    
    [ Upstream commit 230a7a71f92212e723fa435d4ca5922de33ec88a ]
    
    If a usage string is built in parse_options_subcommand, also free it.
    
    Fixes: 901421a5bdf605d2 ("perf tools: Remove subcmd dependencies on strbuf")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Josh Poimboeuf <jpoimboe@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    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/20240509052015.1914670-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.6.33 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jun 12 11:13:03 2024 +0200

    Linux 6.6.33
    
    Link: https://lore.kernel.org/r/20240606131732.440653204@linuxfoundation.org
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Link: https://lore.kernel.org/r/20240609113903.732882729@linuxfoundation.org
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lkdtm: Disable CFI checking for perms functions [+ + +]
Author: Kees Cook <kees@kernel.org>
Date:   Tue Apr 30 16:49:57 2024 -0700

    lkdtm: Disable CFI checking for perms functions
    
    [ Upstream commit fb28a8862dc4b5bf8e44578338f35d9c6c68339d ]
    
    The EXEC_RODATA test plays a lot of tricks to live in the .rodata section,
    and once again ran into objtool's (completely reasonable) assumptions
    that executable code should live in an executable section. However, this
    manifested only under CONFIG_CFI_CLANG=y, as one of the .cfi_sites was
    pointing into the .rodata section.
    
    Since we're testing non-CFI execution properties in perms.c (and
    rodata.c), we can disable CFI for the involved functions, and remove the
    CFI arguments from rodata.c entirely.
    
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202308301532.d7acf63e-oliver.sang@intel.com
    Fixes: 6342a20efbd8 ("objtool: Add elf_create_section_pair()")
    Link: https://lore.kernel.org/r/20240430234953.work.760-kees@kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
locking/atomic/x86: Correct the definition of __arch_try_cmpxchg128() [+ + +]
Author: Uros Bizjak <ubizjak@gmail.com>
Date:   Mon Apr 8 11:13:56 2024 +0200

    locking/atomic/x86: Correct the definition of __arch_try_cmpxchg128()
    
    [ Upstream commit 929ad065ba2967be238dfdc0895b79fda62c7f16 ]
    
    Correct the definition of __arch_try_cmpxchg128(), introduced by:
    
      b23e139d0b66 ("arch: Introduce arch_{,try_}_cmpxchg128{,_local}()")
    
    Fixes: b23e139d0b66 ("arch: Introduce arch_{,try_}_cmpxchg128{,_local}()")
    Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Link: https://lore.kernel.org/r/20240408091547.90111-2-ubizjak@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
LoongArch: Fix callchain parse error with kernel tracepoint events again [+ + +]
Author: Huacai Chen <chenhuacai@kernel.org>
Date:   Tue May 14 12:24:18 2024 +0800

    LoongArch: Fix callchain parse error with kernel tracepoint events again
    
    [ Upstream commit d6af2c76399f98444a5b4de96baf4b362d9f102b ]
    
    With commit d3119bc985fb645 ("LoongArch: Fix callchain parse error with
    kernel tracepoint events"), perf can parse kernel callchain, but not
    complete and sometimes maybe error. The reason is LoongArch's unwinders
    (guess, prologue and orc) don't really need fp (i.e., regs[22]), and
    they use sp (i.e., regs[3]) as the frame address rather than the current
    stack pointer.
    
    Fix that by removing the assignment of regs[22], and instead assign the
    __builtin_frame_address(0) to regs[3].
    
    Without fix:
    
      Children      Self  Command        Shared Object      Symbol
      ........  ........  .............  .................  ................
      33.91%    33.91%    swapper        [kernel.vmlinux]   [k] __schedule
                |
                |--33.04%--__schedule
                |
                 --0.87%--__arch_cpu_idle
                           __schedule
    
    With this fix:
    
      Children      Self  Command        Shared Object      Symbol
      ........  ........  .............  .................  ................
      31.16%    31.16%    swapper        [kernel.vmlinux]   [k] __schedule
                |
                |--20.63%--smpboot_entry
                |          cpu_startup_entry
                |          schedule_idle
                |          __schedule
                |
                 --10.53%--start_kernel
                           cpu_startup_entry
                           schedule_idle
                           __schedule
    
    Fixes: d3119bc985fb645 ("LoongArch: Fix callchain parse error with kernel tracepoint events")
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

LoongArch: Lately init pmu after smp is online [+ + +]
Author: Bibo Mao <maobibo@loongson.cn>
Date:   Thu Apr 25 22:17:52 2024 +0800

    LoongArch: Lately init pmu after smp is online
    
    [ Upstream commit f3334ebb8a2a1841c2824594dd992e66de19deb2 ]
    
    There is an smp function call named reset_counters() to init PMU
    registers of every CPU in PMU initialization state. It requires that all
    CPUs are online. However there is an early_initcall() wrapper for the
    PMU init funciton init_hw_perf_events(), so that pmu init funciton is
    called in do_pre_smp_initcalls() which before function smp_init().
    Function reset_counters() cannot work on other CPUs since they haven't
    boot up still.
    
    Here replace the wrapper early_initcall() with pure_initcall(), so that
    the PMU init function is called after every cpu is online.
    
    Signed-off-by: Bibo Mao <maobibo@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
m68k: Fix spinlock race in kernel thread creation [+ + +]
Author: Michael Schmitz <schmitzmic@gmail.com>
Date:   Thu Apr 11 15:36:31 2024 +1200

    m68k: Fix spinlock race in kernel thread creation
    
    [ Upstream commit da89ce46f02470ef08f0f580755d14d547da59ed ]
    
    Context switching does take care to retain the correct lock owner across
    the switch from 'prev' to 'next' tasks.  This does rely on interrupts
    remaining disabled for the entire duration of the switch.
    
    This condition is guaranteed for normal process creation and context
    switching between already running processes, because both 'prev' and
    'next' already have interrupts disabled in their saved copies of the
    status register.
    
    The situation is different for newly created kernel threads.  The status
    register is set to PS_S in copy_thread(), which does leave the IPL at 0.
    Upon restoring the 'next' thread's status register in switch_to() aka
    resume(), interrupts then become enabled prematurely.  resume() then
    returns via ret_from_kernel_thread() and schedule_tail() where run queue
    lock is released (see finish_task_switch() and finish_lock_switch()).
    
    A timer interrupt calling scheduler_tick() before the lock is released
    in finish_task_switch() will find the lock already taken, with the
    current task as lock owner.  This causes a spinlock recursion warning as
    reported by Guenter Roeck.
    
    As far as I can ascertain, this race has been opened in commit
    533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")
    but I haven't done a detailed study of kernel history so it may well
    predate that commit.
    
    Interrupts cannot be disabled in the saved status register copy for
    kernel threads (init will complain about interrupts disabled when
    finally starting user space).  Disable interrupts temporarily when
    switching the tasks' register sets in resume().
    
    Note that a simple oriw 0x700,%sr after restoring sr is not enough here
    - this leaves enough of a race for the 'spinlock recursion' warning to
    still be observed.
    
    Tested on ARAnyM and qemu (Quadra 800 emulation).
    
    Fixes: 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()")
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Closes: https://lore.kernel.org/all/07811b26-677c-4d05-aeb4-996cd880b789@roeck-us.net
    Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Link: https://lore.kernel.org/r/20240411033631.16335-1-schmitzmic@gmail.com
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

m68k: mac: Fix reboot hang on Mac IIci [+ + +]
Author: Finn Thain <fthain@linux-m68k.org>
Date:   Sat May 4 14:31:12 2024 +1000

    m68k: mac: Fix reboot hang on Mac IIci
    
    [ Upstream commit 265a3b322df9a973ff1fc63da70af456ab6ae1d6 ]
    
    Calling mac_reset() on a Mac IIci does reset the system, but what
    follows is a POST failure that requires a manual reset to resolve.
    Avoid that by using the 68030 asm implementation instead of the C
    implementation.
    
    Apparently the SE/30 has a similar problem as it has used the asm
    implementation since before git. This patch extends that solution to
    other systems with a similar ROM.
    
    After this patch, the only systems still using the C implementation are
    68040 systems where adb_type is either MAC_ADB_IOP or MAC_ADB_II. This
    implies a 1 MiB Quadra ROM.
    
    This now includes the Quadra 900/950, which previously fell through to
    the "should never get here" catch-all.
    
    Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Finn Thain <fthain@linux-m68k.org>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Link: https://lore.kernel.org/r/480ebd1249d229c6dc1f3f1c6d599b8505483fd8.1714797072.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
macintosh/via-macii: Fix "BUG: sleeping function called from invalid context" [+ + +]
Author: Finn Thain <fthain@linux-m68k.org>
Date:   Wed Mar 13 13:53:41 2024 +1100

    macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
    
    [ Upstream commit d301a71c76ee4c384b4e03cdc320a55f5cf1df05 ]
    
    The via-macii ADB driver calls request_irq() after disabling hard
    interrupts. But disabling interrupts isn't necessary here because the
    VIA shift register interrupt was masked during VIA1 initialization.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Finn Thain <fthain@linux-m68k.org>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Link: https://lore.kernel.org/r/419fcc09d0e563b425c419053d02236b044d86b0.1710298421.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md: fix resync softlockup when bitmap size is less than array size [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Mon Apr 22 14:58:24 2024 +0800

    md: fix resync softlockup when bitmap size is less than array size
    
    [ Upstream commit f0e729af2eb6bee9eb58c4df1087f14ebaefe26b ]
    
    Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
    trigger following softlockup:
    
    kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
    CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
    RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
    Call Trace:
     <TASK>
     md_bitmap_start_sync+0x6b/0xf0
     raid10_sync_request+0x25c/0x1b40 [raid10]
     md_do_sync+0x64b/0x1020
     md_thread+0xa7/0x170
     kthread+0xcf/0x100
     ret_from_fork+0x30/0x50
     ret_from_fork_asm+0x1a/0x30
    
    And the detailed process is as follows:
    
    md_do_sync
     j = mddev->resync_min
     while (j < max_sectors)
      sectors = raid10_sync_request(mddev, j, &skipped)
       if (!md_bitmap_start_sync(..., &sync_blocks))
        // md_bitmap_start_sync set sync_blocks to 0
        return sync_blocks + sectors_skippe;
      // sectors = 0;
      j += sectors;
      // j never change
    
    Root cause is that commit 301867b1c168 ("md/raid10: check
    slab-out-of-bounds in md_bitmap_get_counter") return early from
    md_bitmap_get_counter(), without setting returned blocks.
    
    Fix this problem by always set returned blocks from
    md_bitmap_get_counter"(), as it used to be.
    
    Noted that this patch just fix the softlockup problem in kernel, the
    case that bitmap size doesn't match array size still need to be fixed.
    
    Fixes: 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter")
    Reported-and-tested-by: Nigel Croxon <ncroxon@redhat.com>
    Closes: https://lore.kernel.org/all/71ba5272-ab07-43ba-8232-d2da642acb4e@redhat.com/
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20240422065824.2516-1-yukuai1@huaweicloud.com
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries [+ + +]
Author: Zhipeng Lu <alexious@zju.edu.cn>
Date:   Thu Jan 18 16:13:00 2024 +0100

    media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
    
    [ Upstream commit 3b621e9e9e148c0928ab109ac3d4b81487469acb ]
    
    The allocation failure of mycs->yuv_scaler_binary in load_video_binaries()
    is followed with a dereference of mycs->yuv_scaler_binary after the
    following call chain:
    
    sh_css_pipe_load_binaries()
      |-> load_video_binaries(mycs->yuv_scaler_binary == NULL)
      |
      |-> sh_css_pipe_unload_binaries()
            |-> unload_video_binaries()
    
    In unload_video_binaries(), it calls to ia_css_binary_unload with argument
    &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the
    same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer
    dereference is triggered.
    
    Link: https://lore.kernel.org/r/20240118151303.3828292-1-alexious@zju.edu.cn
    
    Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
    Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cadence: csi2rx: configure DPHY before starting source stream [+ + +]
Author: Pratyush Yadav <p.yadav@ti.com>
Date:   Fri Feb 23 13:53:01 2024 +0530

    media: cadence: csi2rx: configure DPHY before starting source stream
    
    [ Upstream commit fd64dda48f7e3f67ada1e1fe47e784ab350da72e ]
    
    When the source device is operating above 1.5 Gbps per lane, it needs to
    send the Skew Calibration Sequence before sending any HS data. If the
    DPHY is initialized after the source stream is started, then it might
    miss the sequence and not be able to receive data properly. Move the
    start of source subdev to the end of the sequence to make sure
    everything is ready to receive data before the source starts streaming.
    
    Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
    Fixes: 3295cf1241d3 ("media: cadence: Add support for external dphy")
    Tested-by: Julien Massot <julien.massot@collabora.com>
    Tested-by: Changhuang Liang <Changhuang.liang@starfivetech.com>
    Reviewed-by: Julien Massot <julien.massot@collabora.com>
    Reviewed-by: Changhuang Liang <Changhuang.liang@starfivetech.com>
    Signed-off-by: Jai Luthra <j-luthra@ti.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: cec: cec-adap: always cancel work in cec_transmit_msg_fh [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri Feb 23 12:24:38 2024 +0000

    media: cec: cec-adap: always cancel work in cec_transmit_msg_fh
    
    [ Upstream commit 9fe2816816a3c765dff3b88af5b5c3d9bbb911ce ]
    
    Do not check for !data->completed, just always call
    cancel_delayed_work_sync(). This fixes a small race condition.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: Yang, Chenyuan <cy54@illinois.edu>
    Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/
    Fixes: 490d84f6d73c ("media: cec: forgot to cancel delayed work")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cec: cec-api: add locking in cec_release() [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri Feb 23 12:25:55 2024 +0000

    media: cec: cec-api: add locking in cec_release()
    
    [ Upstream commit 42bcaacae924bf18ae387c3f78c202df0b739292 ]
    
    When cec_release() uses fh->msgs it has to take fh->lock,
    otherwise the list can get corrupted.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: Yang, Chenyuan <cy54@illinois.edu>
    Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/
    Fixes: ca684386e6e2 ("[media] cec: add HDMI CEC framework (api)")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cec: core: avoid confusing "transmit timed out" message [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Tue Apr 30 11:13:47 2024 +0100

    media: cec: core: avoid confusing "transmit timed out" message
    
    [ Upstream commit cbe499977bc36fedae89f0a0d7deb4ccde9798fe ]
    
    If, when waiting for a transmit to finish, the wait is interrupted,
    then you might get a "transmit timed out" message, even though the
    transmit was interrupted and did not actually time out.
    
    Set transmit_in_progress_aborted to true if the
    wait_for_completion_killable() call was interrupted and ensure
    that the transmit is properly marked as ABORTED.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: Yang, Chenyuan <cy54@illinois.edu>
    Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/
    Fixes: 590a8e564c6e ("media: cec: abort if the current transmit was canceled")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: cec: core: avoid recursive cec_claim_log_addrs [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Thu Feb 22 16:17:33 2024 +0000

    media: cec: core: avoid recursive cec_claim_log_addrs
    
    [ Upstream commit 47c82aac10a6954d68f29f10d9758d016e8e5af1 ]
    
    Keep track if cec_claim_log_addrs() is running, and return -EBUSY
    if it is when calling CEC_ADAP_S_LOG_ADDRS.
    
    This prevents a case where cec_claim_log_addrs() could be called
    while it was still in progress.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: Yang, Chenyuan <cy54@illinois.edu>
    Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/
    Fixes: ca684386e6e2 ("[media] cec: add HDMI CEC framework (api)")
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dt-bindings: ovti,ov2680: Fix the power supply names [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Tue Apr 2 14:40:27 2024 -0300

    media: dt-bindings: ovti,ov2680: Fix the power supply names
    
    [ Upstream commit e2f6ea61b6f3e4ebbb7dff857eea6220c18cd17b ]
    
    The original .txt bindings had the OV2680 power supply names correct,
    but the transition from .txt to yaml spelled them incorrectly.
    
    Fix the OV2680 power supply names as the original .txt bindings
    as these are the names used by the OV2680 driver and in devicetree.
    
    Fixes: 57226cd8c8bf ("media: dt-bindings: ov2680: convert bindings to yaml")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Reviewed-by: Rob Herring <robh@kernel.org>
    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: flexcop-usb: fix sanity check of bNumEndpoints [+ + +]
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Thu Jun 2 06:50:24 2022 +0100

    media: flexcop-usb: fix sanity check of bNumEndpoints
    
    [ Upstream commit f62dc8f6bf82d1b307fc37d8d22cc79f67856c2f ]
    
    Commit d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint type
    ") adds a sanity check for endpoint[1], but fails to modify the sanity
    check of bNumEndpoints.
    
    Fix this by modifying the sanity check of bNumEndpoints to 2.
    
    Link: https://lore.kernel.org/linux-media/20220602055027.849014-1-dzm91@hust.edu.cn
    Fixes: d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint type")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: i2c: et8ek8: Don't strip remove function when driver is builtin [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sun Mar 24 17:00:44 2024 +0100

    media: i2c: et8ek8: Don't strip remove function when driver is builtin
    
    [ Upstream commit 545b215736c5c4b354e182d99c578a472ac9bfce ]
    
    Using __exit for the remove function results in the remove callback
    being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets
    unbound (e.g. using sysfs or hotplug), the driver is just removed
    without the cleanup being performed. This results in resource leaks. Fix
    it by compiling in the remove callback unconditionally.
    
    This also fixes a W=1 modpost warning:
    
            WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)
    
    Fixes: c5254e72b8ed ("[media] media: Driver for Toshiba et8ek8 5MP sensor")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    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: ipu3-cio2: Request IRQ earlier [+ + +]
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Tue Dec 20 16:01:20 2022 +0200

    media: ipu3-cio2: Request IRQ earlier
    
    [ Upstream commit a069f79bfa6ec1ea0744981ea8425c8a25322579 ]
    
    Call devm_request_irq() before registering the async notifier, as otherwise
    it would be possible to use the device before the interrupts could be
    delivered to the driver.
    
    Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
    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: mediatek: vcodec: add encoder power management helper functions [+ + +]
Author: Irui Wang <irui.wang@mediatek.com>
Date:   Mon Sep 25 12:02:00 2023 +0800

    media: mediatek: vcodec: add encoder power management helper functions
    
    [ Upstream commit 3568cb6556695af163e930a75b1ed8f6dfa848ba ]
    
    Remove PM functions at start/stop streaming, add PM helper functions
    to get PM before encoding frame start and put PM after encoding frame
    done. Meanwhile, remove unnecessary clock operations.
    
    Signed-off-by: Irui Wang <irui.wang@mediatek.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Stable-dep-of: c28d4921a1e3 ("media: mediatek: vcodec: fix possible unbalanced PM counter")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: mediatek: vcodec: fix possible unbalanced PM counter [+ + +]
Author: Eugen Hristev <eugen.hristev@collabora.com>
Date:   Thu Dec 28 13:32:40 2023 +0200

    media: mediatek: vcodec: fix possible unbalanced PM counter
    
    [ Upstream commit c28d4921a1e3ce0a0374b7e9d68593be8802c42a ]
    
    It is possible that mtk_vcodec_enc_pw_on fails, and in that scenario
    the PM counter is not incremented, and subsequent call to
    mtk_vcodec_enc_pw_off decrements the counter, leading to a PM imbalance.
    Fix by bailing out of venc_if_encode in the case when mtk_vcodec_enc_pw_on
    fails.
    
    Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver")
    Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
    Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ngene: Add dvb_ca_en50221_init return value check [+ + +]
Author: Aleksandr Burakov <a.burakov@rosalinux.ru>
Date:   Fri Mar 1 14:15:53 2024 +0300

    media: ngene: Add dvb_ca_en50221_init return value check
    
    [ Upstream commit 9bb1fd7eddcab2d28cfc11eb20f1029154dac718 ]
    
    The return value of dvb_ca_en50221_init() is not checked here that may
    cause undefined behavior in case of nonzero value return.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 25aee3debe04 ("[media] Rename media/dvb as media/pci")
    Signed-off-by: Aleksandr Burakov <a.burakov@rosalinux.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov2680: Allow probing if link-frequencies is absent [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Thu Mar 28 19:44:13 2024 -0300

    media: ov2680: Allow probing if link-frequencies is absent
    
    [ Upstream commit fd2e66abd729dae5809dbb41c6c52a6931cfa6bb ]
    
    Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint
    property verification") the ov2680 no longer probes on a imx7s-warp7:
    
    ov2680 1-0036: error -EINVAL: supported link freq 330000000 not found
    ov2680 1-0036: probe with driver ov2680 failed with error -22
    
    As the 'link-frequencies' property is not mandatory, allow the probe
    to succeed by skipping the link-frequency verification when the
    property is absent.
    
    Cc: stable@vger.kernel.org
    Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Stable-dep-of: 24034af644fc ("media: ov2680: Do not fail if data-lanes property is absent")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov2680: Clear the 'ret' variable on success [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Thu Mar 28 19:44:12 2024 -0300

    media: ov2680: Clear the 'ret' variable on success
    
    [ Upstream commit 49a9bad83b4ab5dac1d7aba2615c77978bcf3984 ]
    
    Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint
    property verification") even when the correct 'link-frequencies'
    property is passed in the devicetree, the driver fails to probe:
    
    ov2680 1-0036: probe with driver ov2680 failed with error -22
    
    The reason is that the variable 'ret' may contain the -EINVAL value
    from a previous assignment:
    
    ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
                                   &rate);
    
    Fix the problem by clearing 'ret' on the successful path.
    
    Tested on imx7s-warp board with the following devicetree:
    
    port {
            ov2680_to_mipi: endpoint {
                    remote-endpoint = <&mipi_from_sensor>;
                    clock-lanes = <0>;
                    data-lanes = <1>;
                    link-frequencies = /bits/ 64 <330000000>;
            };
    };
    
    Cc: stable@vger.kernel.org
    Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification")
    Suggested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Stable-dep-of: 24034af644fc ("media: ov2680: Do not fail if data-lanes property is absent")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: ov2680: Do not fail if data-lanes property is absent [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Sun Apr 14 18:09:06 2024 -0300

    media: ov2680: Do not fail if data-lanes property is absent
    
    [ Upstream commit 24034af644fc01126bec9850346a06ef1450181f ]
    
    Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint
    property verification") the ov2680 driver no longer probes when the
    'data-lanes' property is absent.
    
    The OV2680 sensor has only one data lane, so there is no need for
    describing it the devicetree.
    
    Remove the unnecessary data-lanes property check.
    
    Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.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: radio-shark2: Avoid led_names truncations [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Mon Mar 25 14:50:24 2024 +0000

    media: radio-shark2: Avoid led_names truncations
    
    [ Upstream commit 1820e16a3019b6258e6009d34432946a6ddd0a90 ]
    
    Increase the size of led_names so it can fit any valid v4l2 device name.
    
    Fixes:
    drivers/media/radio/radio-shark2.c:197:17: warning: ‘%s’ directive output may be truncated writing up to 35 bytes into a region of size 32 [-Wformat-truncation=]
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: rcar-vin: work around -Wenum-compare-conditional warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Mar 22 14:33:46 2024 +0100

    media: rcar-vin: work around -Wenum-compare-conditional warning
    
    [ Upstream commit 1a742c6010d136cb6c441a0f1dd2bfbfae3c4df2 ]
    
    clang-19 warns about mixing two enum types here:
    
    drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional]
    drivers/media/platform/renesas/rcar-vin/rcar-core.c:216:18: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional]
    drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional]
    drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional]
    
    This one is intentional, and there is already a cast to work around another
    warning, so address this by adding another cast.
    
    Fixes: 406bb586dec0 ("media: rcar-vin: Add r8a779a0 support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: stk1160: fix bounds checking in stk1160_copy_video() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Mon Apr 22 12:32:44 2024 +0300

    media: stk1160: fix bounds checking in stk1160_copy_video()
    
    [ Upstream commit faa4364bef2ec0060de381ff028d1d836600a381 ]
    
    The subtract in this condition is reversed.  The ->length is the length
    of the buffer.  The ->bytesused is how many bytes we have copied thus
    far.  When the condition is reversed that means the result of the
    subtraction is always negative but since it's unsigned then the result
    is a very high positive value.  That means the overflow check is never
    true.
    
    Additionally, the ->bytesused doesn't actually work for this purpose
    because we're not writing to "buf->mem + buf->bytesused".  Instead, the
    math to calculate the destination where we are writing is a bit
    involved.  You calculate the number of full lines already written,
    multiply by two, skip a line if necessary so that we start on an odd
    numbered line, and add the offset into the line.
    
    To fix this buffer overflow, just take the actual destination where we
    are writing, if the offset is already out of bounds print an error and
    return.  Otherwise, write up to buf->length bytes.
    
    Fixes: 9cb2173e6ea8 ("[media] media: Add stk1160 new driver (easycap replacement)")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: sunxi: a83-mips-csi2: also select GENERIC_PHY [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Wed Sep 27 05:04:38 2023 +0100

    media: sunxi: a83-mips-csi2: also select GENERIC_PHY
    
    [ Upstream commit 8237026159cb6760ad22e28d57b9a1c53b612d3a ]
    
    When selecting GENERIC_PHY_MIPI_DPHY, also select GENERIC_PHY to
    prevent kconfig warnings:
    
    WARNING: unmet direct dependencies detected for GENERIC_PHY_MIPI_DPHY
      Depends on [n]: GENERIC_PHY [=n]
      Selected by [y]:
      - VIDEO_SUN8I_A83T_MIPI_CSI2 [=y] && MEDIA_SUPPORT [=y] && MEDIA_PLATFORM_SUPPORT [=y] && MEDIA_PLATFORM_DRIVERS [=y] && V4L_PLATFORM_DRIVERS [=y] && VIDEO_DEV [=y] && (ARCH_SUNXI || COMPILE_TEST [=y]) && PM [=y] && COMMON_CLK [=y] && RESET_CONTROLLER [=y]
    
    Fixes: 94d7fd9692b5 ("media: sunxi: Depend on GENERIC_PHY_MIPI_DPHY")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/r/ZQ/WS8HC1A3F0Qn8@rli9-mobl
    Link: https://lore.kernel.org/linux-media/20230927040438.5589-1-rdunlap@infradead.org
    
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: uvcvideo: Add quirk for Logitech Rally Bar [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Thu Apr 4 18:00:49 2024 +0000

    media: uvcvideo: Add quirk for Logitech Rally Bar
    
    [ Upstream commit 07731053d11f7647d5d8bc23caac997a4d562dfe ]
    
    Logitech Rally Bar devices, despite behaving as UVC cameras, have a
    different power management system that the other cameras from Logitech.
    
    USB_QUIRK_RESET_RESUME is applied to all the UVC cameras from Logitech
    at the usb core. Unfortunately, USB_QUIRK_RESET_RESUME causes undesired
    USB disconnects in the Rally Bar that make them completely unusable.
    
    There is an open discussion about if we should fix this in the core or
    add a quirk in the UVC driver. In order to enable this hardware, let's
    land this patch first, and we can revert it later if there is a
    different conclusion.
    
    Fixes: e387ef5c47dd ("usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams")
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Devinder Khroad <dkhroad@logitech.com>
    Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Link: https://lore.kernel.org/r/20240404-rallybar-v6-1-6d67bb6b69af@chromium.org
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: v4l2-subdev: Document and enforce .s_stream() requirements [+ + +]
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Mon Sep 18 15:48:38 2023 +0300

    media: v4l2-subdev: Document and enforce .s_stream() requirements
    
    [ Upstream commit 009905ec50433259c05f474251000b040098564e ]
    
    The subdev .s_stream() operation must not be called to start an already
    started subdev, or stop an already stopped one. This requirement has
    never been formally documented. Fix it, and catch possible offenders
    with a WARN_ON() in the call_s_stream() wrapper.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Stable-dep-of: f2bf6cd8f447 ("media: v4l: Don't turn on privacy LED if streamon fails")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: v4l2-subdev: Fix stream handling for crop API [+ + +]
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Tue Apr 2 02:37:25 2024 +0300

    media: v4l2-subdev: Fix stream handling for crop API
    
    [ Upstream commit 34d7bf1c8e59f5fbf438ee32c96389ebe41ca2e8 ]
    
    When support for streams was added to the V4L2 subdev API, the
    v4l2_subdev_crop structure was extended with a stream field, but the
    field was not handled in the core code that translates the
    VIDIOC_SUBDEV_[GS]_CROP ioctls to the selection API. Fix it.
    
    Fixes: 2f91e10ee6fd ("media: subdev: add stream based configuration")
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen@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: v4l: Don't turn on privacy LED if streamon fails [+ + +]
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
Date:   Wed Apr 10 12:58:44 2024 +0300

    media: v4l: Don't turn on privacy LED if streamon fails
    
    [ Upstream commit f2bf6cd8f44781349620e30a0af8987fe9af008f ]
    
    Turn on the privacy LED only if streamon succeeds. This can be done after
    enabling streaming on the sensor.
    
    Fixes: b6e10ff6c23d ("media: v4l2-core: Make the v4l2-core code enable/disable the privacy LED if present")
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: vsp1: Remove unbalanced .s_stream(0) calls [+ + +]
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date:   Tue Oct 24 17:18:17 2023 +0300

    media: vsp1: Remove unbalanced .s_stream(0) calls
    
    commit 42d62b7e47d58273c64fc1540e5d81ccfdb60f77 upstream.
    
    The VSP1 driver uses the subdev .s_stream() operation to stop WPF
    instances, without a corresponding call to start them. The V4L2 subdev
    core started warning about unbalanced .s_stream() calls in commit
    009905ec5043 ("media: v4l2-subdev: Document and enforce .s_stream()
    requirements"), causing a regression with this driver.
    
    Fix the problem by replacing the .s_stream() operation with an explicit
    function call for WPF instances. This allows sharing an additional data
    structure between RPF and WPF instances.
    
    Fixes: 009905ec5043 ("media: v4l2-subdev: Document and enforce .s_stream() requirements")
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Closes: https://lore.kernel.org/linux-media/2221395-6a9b-9527-d697-e76aebc6af@linux-m68k.org/
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
microblaze: Remove early printk call from cpuinfo-static.c [+ + +]
Author: Michal Simek <michal.simek@amd.com>
Date:   Thu Apr 11 10:27:21 2024 +0200

    microblaze: Remove early printk call from cpuinfo-static.c
    
    [ Upstream commit 58d647506c92ccd3cfa0c453c68ddd14f40bf06f ]
    
    Early printk has been removed already that's why also remove calling it.
    Similar change has been done in cpuinfo-pvr-full.c by commit cfbd8d1979af
    ("microblaze: Remove early printk setup").
    
    Fixes: 96f0e6fcc9ad ("microblaze: remove redundant early_printk support")
    Signed-off-by: Michal Simek <michal.simek@amd.com>
    Link: https://lore.kernel.org/r/2f10db506be8188fa07b6ec331caca01af1b10f8.1712824039.git.michal.simek@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

microblaze: Remove gcc flag for non existing early_printk.c file [+ + +]
Author: Michal Simek <michal.simek@amd.com>
Date:   Thu Apr 11 10:21:44 2024 +0200

    microblaze: Remove gcc flag for non existing early_printk.c file
    
    [ Upstream commit edc66cf0c4164aa3daf6cc55e970bb94383a6a57 ]
    
    early_printk support for removed long time ago but compilation flag for
    ftrace still points to already removed file that's why remove that line
    too.
    
    Fixes: 96f0e6fcc9ad ("microblaze: remove redundant early_printk support")
    Signed-off-by: Michal Simek <michal.simek@amd.com>
    Link: https://lore.kernel.org/r/5493467419cd2510a32854e2807bcd263de981a0.1712823702.git.michal.simek@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc/pvpanic-pci: register attributes via pci_driver [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Thu Apr 11 23:33:51 2024 +0200

    misc/pvpanic-pci: register attributes via pci_driver
    
    [ Upstream commit ee59be35d7a8be7fcaa2d61fb89734ab5c25e4ee ]
    
    In __pci_register_driver(), the pci core overwrites the dev_groups field of
    the embedded struct device_driver with the dev_groups from the outer
    struct pci_driver unconditionally.
    
    Set dev_groups in the pci_driver to make sure it is used.
    
    This was broken since the introduction of pvpanic-pci.
    
    Fixes: db3a4f0abefd ("misc/pvpanic: add PCI driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Fixes: ded13b9cfd59 ("PCI: Add support for dev_groups to struct pci_driver")
    Link: https://lore.kernel.org/r/20240411-pvpanic-pci-dev-groups-v1-1-db8cb69f1b09@weissschuh.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc/pvpanic: deduplicate common code [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Wed Oct 11 09:18:27 2023 +0200

    misc/pvpanic: deduplicate common code
    
    [ Upstream commit c1426d392aebc51da4944d950d89e483e43f6f14 ]
    
    pvpanic-mmio.c and pvpanic-pci.c share a lot of code.
    Refactor it into pvpanic.c where it doesn't have to be kept in sync
    manually and where the core logic can be understood more easily.
    
    No functional change.
    
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Link: https://lore.kernel.org/r/20231011-pvpanic-cleanup-v2-1-4b21d56f779f@weissschuh.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: ee59be35d7a8 ("misc/pvpanic-pci: register attributes via pci_driver")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mlx5: avoid truncating error message [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 26 23:38:03 2024 +0100

    mlx5: avoid truncating error message
    
    [ Upstream commit b324a960354b872431d25959ad384ab66a7116ec ]
    
    clang warns that one error message is too long for its destination buffer:
    
    drivers/net/ethernet/mellanox/mlx5/core/esw/bridge.c:1876:4: error: 'snprintf' will always be truncated; specified size is 80, but format string expands to at least 94 [-Werror,-Wformat-truncation-non-kprintf]
    
    Reword it to be a bit shorter so it always fits.
    
    Fixes: 70f0302b3f20 ("net/mlx5: Bridge, implement mdb offload")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Link: https://lore.kernel.org/r/20240326223825.4084412-5-arnd@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlx5: stop warning for 64KB pages [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 28 15:30:46 2024 +0100

    mlx5: stop warning for 64KB pages
    
    [ Upstream commit a5535e5336943b33689f558199366102387b7bbf ]
    
    When building with 64KB pages, clang points out that xsk->chunk_size
    can never be PAGE_SIZE:
    
    drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:19:22: error: result of comparison of constant 65536 with expression of type 'u16' (aka 'unsigned short') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            if (xsk->chunk_size > PAGE_SIZE ||
                ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~
    
    In older versions of this code, using PAGE_SIZE was the only
    possibility, so this would have never worked on 64KB page kernels,
    but the patch apparently did not address this case completely.
    
    As Maxim Mikityanskiy suggested, 64KB chunks are really not all that
    useful, so just shut up the warning by adding a cast.
    
    Fixes: 282c0c798f8e ("net/mlx5e: Allow XSK frames smaller than a page")
    Link: https://lore.kernel.org/netdev/20211013150232.2942146-1-arnd@kernel.org/
    Link: https://lore.kernel.org/lkml/a7b27541-0ebb-4f2d-bd06-270a4d404613@app.fastmail.com/
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Maxim Mikityanskiy <maxtram95@gmail.com>
    Reviewed-by: Justin Stitt <justinstitt@google.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240328143051.1069575-9-arnd@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/slub, kunit: Use inverted data to corrupt kmem cache [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Apr 2 06:38:39 2024 -0700

    mm/slub, kunit: Use inverted data to corrupt kmem cache
    
    [ Upstream commit b1080c667b3b2c8c38a7fa83ca5567124887abae ]
    
    Two failure patterns are seen randomly when running slub_kunit tests with
    CONFIG_SLAB_FREELIST_RANDOM and CONFIG_SLAB_FREELIST_HARDENED enabled.
    
    Pattern 1:
         # test_clobber_zone: pass:1 fail:0 skip:0 total:1
         ok 1 test_clobber_zone
         # test_next_pointer: EXPECTATION FAILED at lib/slub_kunit.c:72
         Expected 3 == slab_errors, but
             slab_errors == 0 (0x0)
         # test_next_pointer: EXPECTATION FAILED at lib/slub_kunit.c:84
         Expected 2 == slab_errors, but
             slab_errors == 0 (0x0)
         # test_next_pointer: pass:0 fail:1 skip:0 total:1
         not ok 2 test_next_pointer
    
    In this case, test_next_pointer() overwrites p[s->offset], but the data
    at p[s->offset] is already 0x12.
    
    Pattern 2:
         ok 1 test_clobber_zone
         # test_next_pointer: EXPECTATION FAILED at lib/slub_kunit.c:72
         Expected 3 == slab_errors, but
             slab_errors == 2 (0x2)
         # test_next_pointer: pass:0 fail:1 skip:0 total:1
         not ok 2 test_next_pointer
    
    In this case, p[s->offset] has a value other than 0x12, but one of the
    expected failures is nevertheless missing.
    
    Invert data instead of writing a fixed value to corrupt the cache data
    structures to fix the problem.
    
    Fixes: 1f9f78b1b376 ("mm/slub, kunit: add a KUnit test for SLUB debugging functionality")
    Cc: Oliver Glitta <glittao@gmail.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    CC: Daniel Latypov <dlatypov@google.com>
    Cc: Marco Elver <elver@google.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/userfaultfd: Do not place zeropages when zeropages are disallowed [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Apr 11 18:14:40 2024 +0200

    mm/userfaultfd: Do not place zeropages when zeropages are disallowed
    
    [ Upstream commit 90a7592da14951bd21f74a53246ba30955a648aa ]
    
    s390x must disable shared zeropages for processes running VMs, because
    the VMs could end up making use of "storage keys" or protected
    virtualization, which are incompatible with shared zeropages.
    
    Yet, with userfaultfd it is possible to insert shared zeropages into
    such processes. Let's fallback to simply allocating a fresh zeroed
    anonymous folio and insert that instead.
    
    mm_forbids_zeropage() was introduced in commit 593befa6ab74 ("mm: introduce
    mm_forbids_zeropage function"), briefly before userfaultfd went
    upstream.
    
    Note that we don't want to fail the UFFDIO_ZEROPAGE request like we do
    for hugetlb, it would be rather unexpected. Further, we also
    cannot really indicated "not supported" to user space ahead of time: it
    could be that the MM disallows zeropages after userfaultfd was already
    registered.
    
    [ agordeev: Fixed checkpatch complaints ]
    
    Fixes: c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation")
    Reviewed-by: Peter Xu <peterx@redhat.com>
    Link: https://lore.kernel.org/r/20240411161441.910170-2-david@redhat.com
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mmc: sdhci_am654: Add ITAPDLYSEL in sdhci_j721e_4bit_set_clock [+ + +]
Author: Judith Mendez <jm@ti.com>
Date:   Wed Mar 20 17:38:36 2024 -0500

    mmc: sdhci_am654: Add ITAPDLYSEL in sdhci_j721e_4bit_set_clock
    
    [ Upstream commit 9dff65bb5e09903c27d9cff947dff4d22b6ea6a1 ]
    
    Add ITAPDLYSEL to sdhci_j721e_4bit_set_clock function.
    This allows to set the correct ITAPDLY for timings that
    do not carry out tuning.
    
    Fixes: 1accbced1c32 ("mmc: sdhci_am654: Add Support for 4 bit IP on J721E")
    Signed-off-by: Judith Mendez <jm@ti.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20240320223837.959900-7-jm@ti.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci_am654: Add OTAP/ITAP delay enable [+ + +]
Author: Judith Mendez <jm@ti.com>
Date:   Wed Mar 20 17:38:33 2024 -0500

    mmc: sdhci_am654: Add OTAP/ITAP delay enable
    
    [ Upstream commit 387c1bf7dce0dfea02080c8bdb066b5209e92155 ]
    
    Currently the OTAP/ITAP delay enable functionality is incorrect in
    the am654_set_clock function. The OTAP delay is not enabled when
    timing < SDR25 bus speed mode. The ITAP delay is not enabled for
    timings that do not carry out tuning.
    
    Add this OTAP/ITAP delay functionality according to the datasheet
    [1] OTAPDLYENA and ITAPDLYENA for MMC0.
    
    [1] https://www.ti.com/lit/ds/symlink/am62p.pdf
    
    Fixes: 8ee5fc0e0b3b ("mmc: sdhci_am654: Update OTAPDLY writes")
    Signed-off-by: Judith Mendez <jm@ti.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20240320223837.959900-4-jm@ti.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci_am654: Add tuning algorithm for delay chain [+ + +]
Author: Judith Mendez <jm@ti.com>
Date:   Wed Mar 20 17:38:31 2024 -0500

    mmc: sdhci_am654: Add tuning algorithm for delay chain
    
    [ Upstream commit 6231d99dd4119312ad41abf9383e18fec66cbe4b ]
    
    Currently the sdhci_am654 driver only supports one tuning
    algorithm which should be used only when DLL is enabled. The
    ITAPDLY is selected from the largest passing window and the
    buffer is viewed as a circular buffer.
    
    The new algorithm should be used when the delay chain
    is enabled. The ITAPDLY is selected from the largest passing
    window and the buffer is not viewed as a circular buffer.
    
    This implementation is based off of the following paper: [1].
    
    Also add support for multiple failing windows.
    
    [1] https://www.ti.com/lit/an/spract9/spract9.pdf
    
    Fixes: 13ebeae68ac9 ("mmc: sdhci_am654: Add support for software tuning")
    Signed-off-by: Judith Mendez <jm@ti.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20240320223837.959900-2-jm@ti.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci_am654: Drop lookup for deprecated ti,otap-del-sel [+ + +]
Author: Vignesh Raghavendra <vigneshr@ti.com>
Date:   Wed Nov 22 11:32:14 2023 +0530

    mmc: sdhci_am654: Drop lookup for deprecated ti,otap-del-sel
    
    [ Upstream commit 5cb2f9286a31f33dc732c57540838ad9339393ab ]
    
    ti,otap-del-sel has been deprecated since v5.7 and there are no users of
    this property and no documentation in the DT bindings either.
    Drop the fallback code looking for this property, this makes
    sdhci_am654_get_otap_delay() much easier to read as all the TAP values
    can be handled via a single iterator loop.
    
    Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20231122060215.2074799-1-vigneshr@ti.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Stable-dep-of: 387c1bf7dce0 ("mmc: sdhci_am654: Add OTAP/ITAP delay enable")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci_am654: Fix ITAPDLY for HS400 timing [+ + +]
Author: Judith Mendez <jm@ti.com>
Date:   Wed Mar 20 17:38:37 2024 -0500

    mmc: sdhci_am654: Fix ITAPDLY for HS400 timing
    
    [ Upstream commit d3182932bb070e7518411fd165e023f82afd7d25 ]
    
    While STRB is currently used for DATA and CRC responses, the CMD
    responses from the device to the host still require ITAPDLY for
    HS400 timing.
    
    Currently what is stored for HS400 is the ITAPDLY from High Speed
    mode which is incorrect. The ITAPDLY for HS400 speed mode should
    be the same as ITAPDLY as HS200 timing after tuning is executed.
    Add the functionality to save ITAPDLY from HS200 tuning and save
    as HS400 ITAPDLY.
    
    Fixes: a161c45f2979 ("mmc: sdhci_am654: Enable DLL only for some speed modes")
    Signed-off-by: Judith Mendez <jm@ti.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20240320223837.959900-8-jm@ti.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci_am654: Write ITAPDLY for DDR52 timing [+ + +]
Author: Judith Mendez <jm@ti.com>
Date:   Wed Mar 20 17:38:32 2024 -0500

    mmc: sdhci_am654: Write ITAPDLY for DDR52 timing
    
    [ Upstream commit d465234493bb6ad1b9c10a0c9ef9881b8d85081a ]
    
    For DDR52 timing, DLL is enabled but tuning is not carried
    out, therefore the ITAPDLY value in PHY CTRL 4 register is
    not correct. Fix this by writing ITAPDLY after enabling DLL.
    
    Fixes: a161c45f2979 ("mmc: sdhci_am654: Enable DLL only for some speed modes")
    Signed-off-by: Judith Mendez <jm@ti.com>
    Reviewed-by: Andrew Davis <afd@ti.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20240320223837.959900-3-jm@ti.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
module: don't ignore sysfs_create_link() failures [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Apr 8 10:05:58 2024 +0200

    module: don't ignore sysfs_create_link() failures
    
    [ Upstream commit 85d2b0aa170351380be39fe4ff7973df1427fe76 ]
    
    The sysfs_create_link() return code is marked as __must_check, but the
    module_add_driver() function tries hard to not care, by assigning the
    return code to a variable. When building with 'make W=1', gcc still
    warns because this variable is only assigned but not used:
    
    drivers/base/module.c: In function 'module_add_driver':
    drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used [-Wunused-but-set-variable]
    
    Rework the code to properly unwind and return the error code to the
    caller. My reading of the original code was that it tries to
    not fail when the links already exist, so keep ignoring -EEXIST
    errors.
    
    Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/")
    See-also: 4a7fb6363f2d ("add __must_check to device management code")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
    Link: https://lore.kernel.org/r/20240408080616.3911573-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
modules: Drop the .export_symbol section from the final modules [+ + +]
Author: Wang Yao <wangyao@lemote.com>
Date:   Wed Apr 17 13:35:30 2024 +0800

    modules: Drop the .export_symbol section from the final modules
    
    [ Upstream commit 8fe51b45c5645c259f759479c374648e9dfeaa03 ]
    
    Commit ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost")
    forget drop the .export_symbol section from the final modules.
    
    Fixes: ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost")
    Signed-off-by: Wang Yao <wangyao@lemote.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: SO_KEEPALIVE: fix getsockopt support [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Mon May 13 18:13:25 2024 -0700

    mptcp: SO_KEEPALIVE: fix getsockopt support
    
    [ Upstream commit a65198136eaa15b74ee0abf73f12ef83d469a334 ]
    
    SO_KEEPALIVE support has to be set on each subflow: on each TCP socket,
    where sk_prot->keepalive is defined. Technically, nothing has to be done
    on the MPTCP socket. That's why mptcp_sol_socket_sync_intval() was
    called instead of mptcp_sol_socket_intval().
    
    Except that when nothing is done on the MPTCP socket, the
    getsockopt(SO_KEEPALIVE), handled in net/core/sock.c:sk_getsockopt(),
    will not know if SO_KEEPALIVE has been set on the different subflows or
    not.
    
    The fix is simple: simply call mptcp_sol_socket_intval() which will end
    up calling net/core/sock.c:sk_setsockopt() where the SOCK_KEEPOPEN flag
    will be set, the one used in sk_getsockopt().
    
    So now, getsockopt(SO_KEEPALIVE) on an MPTCP socket will return the same
    value as the one previously set with setsockopt(SO_KEEPALIVE).
    
    Fixes: 1b3e7ede1365 ("mptcp: setsockopt: handle SO_KEEPALIVE and SO_PRIORITY")
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Mat Martineau <martineau@kernel.org>
    Link: https://lore.kernel.org/r/20240514011335.176158-2-martineau@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mtd: core: Report error if first mtd_otp_size() call fails in mtd_otp_nvmem_add() [+ + +]
Author: Aapo Vienamo <aapo.vienamo@linux.intel.com>
Date:   Wed Mar 13 19:34:24 2024 +0200

    mtd: core: Report error if first mtd_otp_size() call fails in mtd_otp_nvmem_add()
    
    [ Upstream commit d44f0bbbd8d182debcce88bda55b05269f3d33d6 ]
    
    Jump to the error reporting code in mtd_otp_nvmem_add() if the
    mtd_otp_size() call fails. Without this fix, the error is not logged.
    
    Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Reviewed-by: Michael Walle <mwalle@kernel.org>
    Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support")
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20240313173425.1325790-2-aapo.vienamo@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: rawnand: hynix: fixed typo [+ + +]
Author: Maxim Korotkov <korotkov.maxim.s@gmail.com>
Date:   Wed Mar 13 13:27:20 2024 +0300

    mtd: rawnand: hynix: fixed typo
    
    [ Upstream commit 6819db94e1cd3ce24a432f3616cd563ed0c4eaba ]
    
    The function hynix_nand_rr_init() should probably return an error code.
    Judging by the usage, it seems that the return code is passed up
    the call stack.
    Right now, it always returns 0 and the function hynix_nand_cleanup()
    in hynix_nand_init() has never been called.
    
    Found by RASU JSC and Linux Verification Center (linuxtesting.org)
    
    Fixes: 626994e07480 ("mtd: nand: hynix: Add read-retry support for 1x nm MLC NANDs")
    
    Signed-off-by: Maxim Korotkov <korotkov.maxim.s@gmail.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20240313102721.1991299-1-korotkov.maxim.s@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5: Add a timeout to acquire the command queue semaphore [+ + +]
Author: Akiva Goldberger <agoldberger@nvidia.com>
Date:   Thu May 9 14:29:50 2024 +0300

    net/mlx5: Add a timeout to acquire the command queue semaphore
    
    [ Upstream commit 485d65e1357123a697c591a5aeb773994b247ad7 ]
    
    Prevent forced completion handling on an entry that has not yet been
    assigned an index, causing an out of bounds access on idx = -22.
    Instead of waiting indefinitely for the sem, blocking flow now waits for
    index to be allocated or a sem acquisition timeout before beginning the
    timer for FW completion.
    
    Kernel log example:
    mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion
    
    Fixes: 8e715cd613a1 ("net/mlx5: Set command entry semaphore up once got index free")
    Signed-off-by: Akiva Goldberger <agoldberger@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240509112951.590184-5-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Discard command completions in internal error [+ + +]
Author: Akiva Goldberger <agoldberger@nvidia.com>
Date:   Thu May 9 14:29:51 2024 +0300

    net/mlx5: Discard command completions in internal error
    
    [ Upstream commit db9b31aa9bc56ff0d15b78f7e827d61c4a096e40 ]
    
    Fix use after free when FW completion arrives while device is in
    internal error state. Avoid calling completion handler in this case,
    since the device will flush the command interface and trigger all
    completions manually.
    
    Kernel log:
    ------------[ cut here ]------------
    refcount_t: underflow; use-after-free.
    ...
    RIP: 0010:refcount_warn_saturate+0xd8/0xe0
    ...
    Call Trace:
    <IRQ>
    ? __warn+0x79/0x120
    ? refcount_warn_saturate+0xd8/0xe0
    ? report_bug+0x17c/0x190
    ? handle_bug+0x3c/0x60
    ? exc_invalid_op+0x14/0x70
    ? asm_exc_invalid_op+0x16/0x20
    ? refcount_warn_saturate+0xd8/0xe0
    cmd_ent_put+0x13b/0x160 [mlx5_core]
    mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]
    cmd_comp_notifier+0x1f/0x30 [mlx5_core]
    notifier_call_chain+0x35/0xb0
    atomic_notifier_call_chain+0x16/0x20
    mlx5_eq_async_int+0xf6/0x290 [mlx5_core]
    notifier_call_chain+0x35/0xb0
    atomic_notifier_call_chain+0x16/0x20
    irq_int_handler+0x19/0x30 [mlx5_core]
    __handle_irq_event_percpu+0x4b/0x160
    handle_irq_event+0x2e/0x80
    handle_edge_irq+0x98/0x230
    __common_interrupt+0x3b/0xa0
    common_interrupt+0x7b/0xa0
    </IRQ>
    <TASK>
    asm_common_interrupt+0x22/0x40
    
    Fixes: 51d138c2610a ("net/mlx5: Fix health error state handling")
    Signed-off-by: Akiva Goldberger <agoldberger@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240509112951.590184-6-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Enable 4 ports multiport E-switch [+ + +]
Author: Shay Drory <shayd@nvidia.com>
Date:   Wed Jun 21 20:25:00 2023 +0300

    net/mlx5: Enable 4 ports multiport E-switch
    
    [ Upstream commit e738e355045237ee8802cb2b31a8ed6f4b7ac534 ]
    
    enable_mpesw() assumed only 2 ports are available, fix this by removing
    that assumption and looping through the existing lag ports to enable multi-port
    E-switch for cards with more than 2 ports.
    
    Signed-off-by: Shay Drory <shayd@nvidia.com>
    Reviewed-by: Mark Bloch <mbloch@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Stable-dep-of: 0f06228d4a2d ("net/mlx5: Reload only IB representors upon lag disable/enable")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Fix MTMP register capability offset in MCAM register [+ + +]
Author: Gal Pressman <gal@nvidia.com>
Date:   Wed May 22 22:26:54 2024 +0300

    net/mlx5: Fix MTMP register capability offset in MCAM register
    
    [ Upstream commit 1b9f86c6d53245dab087f1b2c05727b5982142ff ]
    
    The MTMP register (0x900a) capability offset is off-by-one, move it to
    the right place.
    
    Fixes: 1f507e80c700 ("net/mlx5: Expose NIC temperature via hardware monitoring kernel API")
    Signed-off-by: Gal Pressman <gal@nvidia.com>
    Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Lag, do bond only if slaves agree on roce state [+ + +]
Author: Maher Sanalla <msanalla@nvidia.com>
Date:   Wed May 22 22:26:52 2024 +0300

    net/mlx5: Lag, do bond only if slaves agree on roce state
    
    [ Upstream commit 51ef9305b8f40946d65c40368ffb4c14636d369a ]
    
    Currently, the driver does not enforce that lag bond slaves must have
    matching roce capabilities. Yet, in mlx5_do_bond(), the driver attempts
    to enable roce on all vports of the bond slaves, causing the following
    syndrome when one slave has no roce fw support:
    
    mlx5_cmd_out_err:809:(pid 25427): MODIFY_NIC_VPORT_CONTEXT(0×755) op_mod(0×0)
    failed, status bad parameter(0×3), syndrome (0xc1f678), err(-22)
    
    Thus, create HW lag only if bond's slaves agree on roce state,
    either all slaves have roce support resulting in a roce lag bond,
    or none do, resulting in a raw eth bond.
    
    Fixes: 7907f23adc18 ("net/mlx5: Implement RoCE LAG feature")
    Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Reload only IB representors upon lag disable/enable [+ + +]
Author: Maher Sanalla <msanalla@nvidia.com>
Date:   Thu May 9 14:29:49 2024 +0300

    net/mlx5: Reload only IB representors upon lag disable/enable
    
    [ Upstream commit 0f06228d4a2dcc1fca5b3ddb0eefa09c05b102c4 ]
    
    On lag disable, the bond IB device along with all of its
    representors are destroyed, and then the slaves' representors get reloaded.
    
    In case the slave IB representor load fails, the eswitch error flow
    unloads all representors, including ethernet representors, where the
    netdevs get detached and removed from lag bond. Such flow is inaccurate
    as the lag driver is not responsible for loading/unloading ethernet
    representors. Furthermore, the flow described above begins by holding
    lag lock to prevent bond changes during disable flow. However, when
    reaching the ethernet representors detachment from lag, the lag lock is
    required again, triggering the following deadlock:
    
    Call trace:
    __switch_to+0xf4/0x148
    __schedule+0x2c8/0x7d0
    schedule+0x50/0xe0
    schedule_preempt_disabled+0x18/0x28
    __mutex_lock.isra.13+0x2b8/0x570
    __mutex_lock_slowpath+0x1c/0x28
    mutex_lock+0x4c/0x68
    mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]
    mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]
    mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]
    mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]
    mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]
    mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]
    mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]
    mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]
    mlx5_disable_lag+0x130/0x138 [mlx5_core]
    mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lock
    mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]
    devlink_nl_cmd_eswitch_set_doit+0xdc/0x180
    genl_family_rcv_msg_doit.isra.17+0xe8/0x138
    genl_rcv_msg+0xe4/0x220
    netlink_rcv_skb+0x44/0x108
    genl_rcv+0x40/0x58
    netlink_unicast+0x198/0x268
    netlink_sendmsg+0x1d4/0x418
    sock_sendmsg+0x54/0x60
    __sys_sendto+0xf4/0x120
    __arm64_sys_sendto+0x30/0x40
    el0_svc_common+0x8c/0x120
    do_el0_svc+0x30/0xa0
    el0_svc+0x20/0x30
    el0_sync_handler+0x90/0xb8
    el0_sync+0x160/0x180
    
    Thus, upon lag enable/disable, load and unload only the IB representors
    of the slaves preventing the deadlock mentioned above.
    
    While at it, refactor the mlx5_esw_offloads_rep_load() function to have
    a static helper method for its internal logic, in symmetry with the
    representor unload design.
    
    Fixes: 598fe77df855 ("net/mlx5: Lag, Create shared FDB when in switchdev mode")
    Co-developed-by: Mark Bloch <mbloch@nvidia.com>
    Signed-off-by: Mark Bloch <mbloch@nvidia.com>
    Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240509112951.590184-4-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Wed May 22 22:26:55 2024 +0300

    net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules
    
    [ Upstream commit 16d66a4fa81da07bc4ed19f4e53b87263c2f8d38 ]
    
    rx_create no longer allocates a modify_hdr instance that needs to be
    cleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer
    dereference. A leak in the rules also previously occurred since there are
    now two rules populated related to status.
    
      BUG: kernel NULL pointer dereference, address: 0000000000000000
      #PF: supervisor read access in kernel mode
      #PF: error_code(0x0000) - not-present page
      PGD 109907067 P4D 109907067 PUD 116890067 PMD 0
      Oops: 0000 [#1] SMP
      CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014
      RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70
      <snip>
      Call Trace:
       <TASK>
       ? show_regs+0x60/0x70
       ? __die+0x24/0x70
       ? page_fault_oops+0x15f/0x430
       ? free_to_partial_list.constprop.0+0x79/0x150
       ? do_user_addr_fault+0x2c9/0x5c0
       ? exc_page_fault+0x63/0x110
       ? asm_exc_page_fault+0x27/0x30
       ? mlx5_modify_header_dealloc+0xd/0x70
       rx_create+0x374/0x590
       rx_add_rule+0x3ad/0x500
       ? rx_add_rule+0x3ad/0x500
       ? mlx5_cmd_exec+0x2c/0x40
       ? mlx5_create_ipsec_obj+0xd6/0x200
       mlx5e_accel_ipsec_fs_add_rule+0x31/0xf0
       mlx5e_xfrm_add_state+0x426/0xc00
      <snip>
    
    Fixes: 94af50c0a9bb ("net/mlx5e: Unify esw and normal IPsec status table creation/destruction")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: Fix IPsec tunnel mode offload feature check [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Wed May 22 22:26:56 2024 +0300

    net/mlx5e: Fix IPsec tunnel mode offload feature check
    
    [ Upstream commit 9a52f6d44f4521773b4699b4ed34b8e21d5a175c ]
    
    Remove faulty check disabling checksum offload and GSO for offload of
    simple IPsec tunnel L4 traffic. Comment previously describing the deleted
    code incorrectly claimed the check prevented double tunnel (or three layers
    of ip headers).
    
    Fixes: f1267798c980 ("net/mlx5: Fix checksum issue of VXLAN and IPsec crypto offload")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Fix UDP GSO for encapsulated packets [+ + +]
Author: Gal Pressman <gal@nvidia.com>
Date:   Wed May 22 22:26:59 2024 +0300

    net/mlx5e: Fix UDP GSO for encapsulated packets
    
    [ Upstream commit 83fea49f2711fc90c0d115b0ed04046b45155b65 ]
    
    When the skb is encapsulated, adjust the inner UDP header instead of the
    outer one, and account for UDP header (instead of TCP) in the inline
    header size calculation.
    
    Fixes: 689adf0d4892 ("net/mlx5e: Add UDP GSO support")
    Reported-by: Jason Baron <jbaron@akamai.com>
    Closes: https://lore.kernel.org/netdev/c42961cb-50b9-4a9a-bd43-87fe48d88d29@akamai.com/
    Signed-off-by: Gal Pressman <gal@nvidia.com>
    Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
    Reviewed-by: Boris Pismenny <borisp@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Use rx_missed_errors instead of rx_dropped for reporting buffer exhaustion [+ + +]
Author: Carolina Jubran <cjubran@nvidia.com>
Date:   Wed May 22 22:26:58 2024 +0300

    net/mlx5e: Use rx_missed_errors instead of rx_dropped for reporting buffer exhaustion
    
    [ Upstream commit 5c74195d5dd977e97556e6fa76909b831c241230 ]
    
    Previously, the driver incorrectly used rx_dropped to report device
    buffer exhaustion.
    
    According to the documentation, rx_dropped should not be used to count
    packets dropped due to buffer exhaustion, which is the purpose of
    rx_missed_errors.
    
    Use rx_missed_errors as intended for counting packets dropped due to
    buffer exhaustion.
    
    Fixes: 269e6b3af3bf ("net/mlx5e: Report additional error statistics in get stats ndo")
    Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: taprio: extend minimum interval restriction to entire cycle too [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Mon May 27 18:39:55 2024 +0300

    net/sched: taprio: extend minimum interval restriction to entire cycle too
    
    [ Upstream commit fb66df20a7201e60f2b13d7f95d031b31a8831d3 ]
    
    It is possible for syzbot to side-step the restriction imposed by the
    blamed commit in the Fixes: tag, because the taprio UAPI permits a
    cycle-time different from (and potentially shorter than) the sum of
    entry intervals.
    
    We need one more restriction, which is that the cycle time itself must
    be larger than N * ETH_ZLEN bit times, where N is the number of schedule
    entries. This restriction needs to apply regardless of whether the cycle
    time came from the user or was the implicit, auto-calculated value, so
    we move the existing "cycle == 0" check outside the "if "(!new->cycle_time)"
    branch. This way covers both conditions and scenarios.
    
    Add a selftest which illustrates the issue triggered by syzbot.
    
    Fixes: b5b73b26b3ca ("taprio: Fix allowing too small intervals")
    Reported-by: syzbot+a7d2b1d5d1af83035567@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/0000000000007d66bc06196e7c66@google.com/
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Link: https://lore.kernel.org/r/20240527153955.553333-2-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: taprio: make q->picos_per_byte available to fill_sched_entry() [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Mon May 27 18:39:54 2024 +0300

    net/sched: taprio: make q->picos_per_byte available to fill_sched_entry()
    
    [ Upstream commit e634134180885574d1fe7aa162777ba41e7fcd5b ]
    
    In commit b5b73b26b3ca ("taprio: Fix allowing too small intervals"), a
    comparison of user input against length_to_duration(q, ETH_ZLEN) was
    introduced, to avoid RCU stalls due to frequent hrtimers.
    
    The implementation of length_to_duration() depends on q->picos_per_byte
    being set for the link speed. The blamed commit in the Fixes: tag has
    moved this too late, so the checks introduced above are ineffective.
    The q->picos_per_byte is zero at parse_taprio_schedule() ->
    parse_sched_list() -> parse_sched_entry() -> fill_sched_entry() time.
    
    Move the taprio_set_picos_per_byte() call as one of the first things in
    taprio_change(), before the bulk of the netlink attribute parsing is
    done. That's because it is needed there.
    
    Add a selftest to make sure the issue doesn't get reintroduced.
    
    Fixes: 09dbdf28f9f9 ("net/sched: taprio: fix calculation of maximum gate durations")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240527153955.553333-1-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: Always descend into dsa/ folder with CONFIG_NET_DSA enabled [+ + +]
Author: Florian Fainelli <florian.fainelli@broadcom.com>
Date:   Thu May 16 09:56:30 2024 -0700

    net: Always descend into dsa/ folder with CONFIG_NET_DSA enabled
    
    [ Upstream commit b1fa60ec252fba39130107074becd12d0b3f83ec ]
    
    Stephen reported that he was unable to get the dsa_loop driver to get
    probed, and the reason ended up being because he had CONFIG_FIXED_PHY=y
    in his kernel configuration. As Masahiro explained it:
    
      "obj-m += dsa/" means everything under dsa/ must be modular.
    
      If there is a built-in object under dsa/ with CONFIG_NET_DSA=m,
      you cannot do  "obj-$(CONFIG_NET_DSA) += dsa/".
    
      You need to change it back to "obj-y += dsa/".
    
    This was the case here whereby CONFIG_NET_DSA=m, and so the
    obj-$(CONFIG_FIXED_PHY) += dsa_loop_bdinfo.o rule is not executed and
    the DSA loop mdio_board info structure is not registered with the
    kernel, and eventually the device is simply not found.
    
    To preserve the intention of the original commit of limiting the amount
    of folder descending, conditionally descend into drivers/net/dsa when
    CONFIG_NET_DSA is enabled.
    
    Fixes: 227d72063fcc ("dsa: simplify Kconfig symbols and dependencies")
    Reported-by: Stephen Langstaff <stephenlangstaff1@gmail.com>
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: mst: fix vlan use-after-free [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Mon May 13 14:06:27 2024 +0300

    net: bridge: mst: fix vlan use-after-free
    
    [ Upstream commit 3a7c1661ae1383364cd6092d851f5e5da64d476b ]
    
    syzbot reported a suspicious rcu usage[1] in bridge's mst code. While
    fixing it I noticed that nothing prevents a vlan to be freed while
    walking the list from the same path (br forward delay timer). Fix the rcu
    usage and also make sure we are not accessing freed memory by making
    br_mst_vlan_set_state use rcu read lock.
    
    [1]
     WARNING: suspicious RCU usage
     6.9.0-rc6-syzkaller #0 Not tainted
     -----------------------------
     net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage!
     ...
     stack backtrace:
     CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0
     Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
     Call Trace:
      <IRQ>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
      lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
      nbp_vlan_group net/bridge/br_private.h:1599 [inline]
      br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105
      br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47
      br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88
      call_timer_fn+0x18e/0x650 kernel/time/timer.c:1793
      expire_timers kernel/time/timer.c:1844 [inline]
      __run_timers kernel/time/timer.c:2418 [inline]
      __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429
      run_timer_base kernel/time/timer.c:2438 [inline]
      run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448
      __do_softirq+0x2c6/0x980 kernel/softirq.c:554
      invoke_softirq kernel/softirq.c:428 [inline]
      __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633
      irq_exit_rcu+0x9/0x30 kernel/softirq.c:645
      instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
      sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
      </IRQ>
      <TASK>
     asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
     RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758
     Code: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25
     RSP: 0018:ffffc90013657100 EFLAGS: 00000206
     RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001
     RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60
     RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0
     R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28
     R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246
    
    Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode")
    Reported-by: syzbot+fa04eb8a56fd923fc5d8@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=fa04eb8a56fd923fc5d8
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: bridge: xmit: make sure we have at least eth header len bytes [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Mon May 13 13:34:19 2024 +0300

    net: bridge: xmit: make sure we have at least eth header len bytes
    
    [ Upstream commit 8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc ]
    
    syzbot triggered an uninit value[1] error in bridge device's xmit path
    by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
    we can actually pull that amount instead of assuming.
    
    Tested with dropwatch:
     drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
     origin: software
     timestamp: Mon May 13 11:31:53 2024 778214037 nsec
     protocol: 0x88a8
     length: 2
     original length: 2
     drop reason: PKT_TOO_SMALL
    
    [1]
    BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
     br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
     __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
     netdev_start_xmit include/linux/netdevice.h:4917 [inline]
     xmit_one net/core/dev.c:3531 [inline]
     dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
     __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
     dev_queue_xmit include/linux/netdevice.h:3091 [inline]
     __bpf_tx_skb net/core/filter.c:2136 [inline]
     __bpf_redirect_common net/core/filter.c:2180 [inline]
     __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
     ____bpf_clone_redirect net/core/filter.c:2460 [inline]
     bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
     ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
     __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
     bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
     __bpf_prog_run include/linux/filter.h:657 [inline]
     bpf_prog_run include/linux/filter.h:664 [inline]
     bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
     bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
     bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
     __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
     __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
     __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
     __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
     x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot+a63a1f6a062033cf0f40@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=a63a1f6a062033cf0f40
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: microchip: fix RGMII error in KSZ DSA driver [+ + +]
Author: Tristram Ha <tristram.ha@microchip.com>
Date:   Tue May 28 14:34:26 2024 -0700

    net: dsa: microchip: fix RGMII error in KSZ DSA driver
    
    [ Upstream commit 278d65ccdadb5f0fa0ceaf7b9cc97b305cd72822 ]
    
    The driver should return RMII interface when XMII is running in RMII mode.
    
    Fixes: 0ab7f6bf1675 ("net: dsa: microchip: ksz9477: use common xmii function")
    Signed-off-by: Tristram Ha <tristram.ha@microchip.com>
    Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com>
    Acked-by: Jerry Ray <jerry.ray@microchip.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/1716932066-3342-1-git-send-email-Tristram.Ha@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mv88e6xxx: Add support for model-specific pre- and post-reset handlers [+ + +]
Author: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Date:   Tue Apr 23 09:47:48 2024 +0200

    net: dsa: mv88e6xxx: Add support for model-specific pre- and post-reset handlers
    
    [ Upstream commit 0fdd27b9d6d7c60bd319d3497ad797934bab13cb ]
    
    Instead of calling mv88e6xxx_g2_eeprom_wait() directly from
    mv88e6xxx_hardware_reset(), add configurable pre- and post-reset hard
    reset handlers. Initially, the handlers are set to
    mv88e6xxx_g2_eeprom_wait() for all families that have get/set_eeprom()
    to match the existing behavior. No functional change intended (except
    for additional error messages on failure).
    
    Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent")
    Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.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: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches [+ + +]
Author: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Date:   Tue Apr 23 09:47:49 2024 +0200

    net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches
    
    [ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ]
    
    88E6250-family switches have the quirk that the EEPROM Running flag can
    get stuck at 1 when no EEPROM is connected, causing
    mv88e6xxx_g2_eeprom_wait() to time out. We still want to wait for the
    EEPROM however, to avoid interrupting a transfer and leaving the EEPROM
    in an invalid state.
    
    The condition to wait for recommended by the hardware spec is the EEInt
    flag, however this flag is cleared on read, so before the hardware reset,
    is may have been cleared already even though the EEPROM has been read
    successfully.
    
    For this reason, we revive the mv88e6xxx_g1_wait_eeprom_done() function
    that was removed in commit 6ccf50d4d474
    ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") in a
    slightly refactored form, and introduce a new
    mv88e6xxx_g1_wait_eeprom_done_prereset() that additionally handles this
    case by triggering another EEPROM reload that can be waited on.
    
    On other switch models without this quirk, mv88e6xxx_g2_eeprom_wait() is
    kept, as it avoids the additional reload.
    
    Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent")
    Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.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: ena: Fix redundant device NUMA node override [+ + +]
Author: Shay Agroskin <shayagr@amazon.com>
Date:   Tue May 28 20:09:12 2024 +0300

    net: ena: Fix redundant device NUMA node override
    
    [ Upstream commit 2dc8b1e7177d4f49f492ce648440caf2de0c3616 ]
    
    The driver overrides the NUMA node id of the device regardless of
    whether it knows its correct value (often setting it to -1 even though
    the node id is advertised in 'struct device'). This can lead to
    suboptimal configurations.
    
    This patch fixes this behavior and makes the shared memory allocation
    functions use the NUMA node id advertised by the underlying device.
    
    Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
    Signed-off-by: Shay Agroskin <shayagr@amazon.com>
    Link: https://lore.kernel.org/r/20240528170912.1204417-1-shayagr@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ena: Reduce lines with longer column width boundary [+ + +]
Author: David Arinzon <darinzon@amazon.com>
Date:   Tue Jan 30 09:53:53 2024 +0000

    net: ena: Reduce lines with longer column width boundary
    
    [ Upstream commit 50613650c3d6255cef13a129ccaa919ca73a6743 ]
    
    This patch reduces some of the lines by removing newlines
    where more variables or print strings can be pushed back
    to the previous line while still adhering to the styling
    guidelines.
    
    Signed-off-by: David Arinzon <darinzon@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Stable-dep-of: 2dc8b1e7177d ("net: ena: Fix redundant device NUMA node override")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: cortina: Locking fixes [+ + +]
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Thu May 9 09:44:54 2024 +0200

    net: ethernet: cortina: Locking fixes
    
    [ Upstream commit 812552808f7ff71133fc59768cdc253c5b8ca1bf ]
    
    This fixes a probably long standing problem in the Cortina
    Gemini ethernet driver: there are some paths in the code
    where the IRQ registers are written without taking the proper
    locks.
    
    Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240509-gemini-ethernet-locking-v1-1-afd00a528b95@linaro.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: fec: avoid lock evasion when reading pps_enable [+ + +]
Author: Wei Fang <wei.fang@nxp.com>
Date:   Tue May 21 10:38:00 2024 +0800

    net: fec: avoid lock evasion when reading pps_enable
    
    [ Upstream commit 3b1c92f8e5371700fada307cc8fd2c51fa7bc8c1 ]
    
    The assignment of pps_enable is protected by tmreg_lock, but the read
    operation of pps_enable is not. So the Coverity tool reports a lock
    evasion warning which may cause data race to occur when running in a
    multithread environment. Although this issue is almost impossible to
    occur, we'd better fix it, at least it seems more logically reasonable,
    and it also prevents Coverity from continuing to issue warnings.
    
    Fixes: 278d24047891 ("net: fec: ptp: Enable PPS output based on ptp clock")
    Signed-off-by: Wei Fang <wei.fang@nxp.com>
    Link: https://lore.kernel.org/r/20240521023800.17102-1-wei.fang@nxp.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: fec: remove .ndo_poll_controller to avoid deadlocks [+ + +]
Author: Wei Fang <wei.fang@nxp.com>
Date:   Sat May 11 14:20:09 2024 +0800

    net: fec: remove .ndo_poll_controller to avoid deadlocks
    
    [ Upstream commit c2e0c58b25a0a0c37ec643255558c5af4450c9f5 ]
    
    There is a deadlock issue found in sungem driver, please refer to the
    commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
    deadlocks"). The root cause of the issue is that netpoll is in atomic
    context and disable_irq() is called by .ndo_poll_controller interface
    of sungem driver, however, disable_irq() might sleep. After analyzing
    the implementation of fec_poll_controller(), the fec driver should have
    the same issue. Due to the fec driver uses NAPI for TX completions, the
    .ndo_poll_controller is unnecessary to be implemented in the fec driver,
    so fec_poll_controller() can be safely removed.
    
    Fixes: 7f5c6addcdc0 ("net/fec: add poll controller function for fec nic")
    Signed-off-by: Wei Fang <wei.fang@nxp.com>
    Link: https://lore.kernel.org/r/20240511062009.652918-1-wei.fang@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: give more chances to rcu in netdev_wait_allrefs_any() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 26 06:42:22 2024 +0000

    net: give more chances to rcu in netdev_wait_allrefs_any()
    
    [ Upstream commit cd42ba1c8ac9deb9032add6adf491110e7442040 ]
    
    This came while reviewing commit c4e86b4363ac ("net: add two more
    call_rcu_hurry()").
    
    Paolo asked if adding one synchronize_rcu() would help.
    
    While synchronize_rcu() does not help, making sure to call
    rcu_barrier() before msleep(wait) is definitely helping
    to make sure lazy call_rcu() are completed.
    
    Instead of waiting ~100 seconds in my tests, the ref_tracker
    splats occurs one time only, and netdev_wait_allrefs_any()
    latency is reduced to the strict minimum.
    
    Ideally we should audit our call_rcu() users to make sure
    no refcount (or cascading call_rcu()) is held too long,
    because rcu_barrier() is quite expensive.
    
    Fixes: 0e4be9e57e8c ("net: use exponential backoff in netdev_wait_allrefs")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/all/28bbf698-befb-42f6-b561-851c67f464aa@kernel.org/T/#m76d73ed6b03cd930778ac4d20a777f22a08d6824
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ipv6: fix wrong start position when receive hop-by-hop fragment [+ + +]
Author: gaoxingwang <gaoxingwang1@huawei.com>
Date:   Mon Apr 22 17:19:17 2024 +0800

    net: ipv6: fix wrong start position when receive hop-by-hop fragment
    
    [ Upstream commit 1cd354fe1e4864eeaff62f66ee513080ec946f20 ]
    
    In IPv6, ipv6_rcv_core will parse the hop-by-hop type extension header and increase skb->transport_header by one extension header length.
    But if there are more other extension headers like fragment header at this time, the skb->transport_header points to the second extension header,
    not the transport layer header or the first extension header.
    
    This will result in the start and nexthdrp variable not pointing to the same position in ipv6frag_thdr_trunced,
    and ipv6_skip_exthdr returning incorrect offset and frag_off.Sometimes,the length of the last sharded packet is smaller than the calculated incorrect offset, resulting in packet loss.
    We can use network header to offset and calculate the correct position to solve this problem.
    
    Fixes: 9d9e937b1c8b (ipv6/netfilter: Discard first fragment not including all headers)
    Signed-off-by: Gao Xingwang <gaoxingwang1@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: lan966x: remove debugfs directory in probe() error path [+ + +]
Author: Herve Codina <herve.codina@bootlin.com>
Date:   Mon May 13 13:18:53 2024 +0200

    net: lan966x: remove debugfs directory in probe() error path
    
    commit 99975ad644c7836414183fa7be4f883a4fb2bf64 upstream.
    
    A debugfs directory entry is create early during probe(). This entry is
    not removed on error path leading to some "already present" issues in
    case of EPROBE_DEFER.
    
    Create this entry later in the probe() code to avoid the need to change
    many 'return' in 'goto' and add the removal in the already present error
    path.
    
    Fixes: 942814840127 ("net: lan966x: Add VCAP debugFS support")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Herve Codina <herve.codina@bootlin.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: lan966x: Remove ptp traps in case the ptp is not enabled. [+ + +]
Author: Horatiu Vultur <horatiu.vultur@microchip.com>
Date:   Fri May 17 15:58:08 2024 +0200

    net: lan966x: Remove ptp traps in case the ptp is not enabled.
    
    [ Upstream commit eda40be3a5ff3fdce513d2bcfeaca8cc16cf962a ]
    
    Lan966x is adding ptp traps to redirect the ptp frames to the CPU such
    that the HW will not forward these frames anywhere. The issue is that in
    case ptp is not enabled and the timestamping source is et to
    HWTSTAMP_SOURCE_NETDEV then these traps would not be removed on the
    error path.
    Fix this by removing the traps in this case as they are not needed.
    
    Fixes: 54e1ed69c40a ("net: lan966x: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()")
    Suggested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Link: https://lore.kernel.org/r/20240517135808.3025435-1-horatiu.vultur@microchip.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mana: Fix the extra HZ in mana_hwc_send_request [+ + +]
Author: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
Date:   Sun May 19 23:05:04 2024 -0700

    net: mana: Fix the extra HZ in mana_hwc_send_request
    
    commit 9c91c7fadb1771dcc2815c5271d14566366d05c5 upstream.
    
    Commit 62c1bff593b7 added an extra HZ along with msecs_to_jiffies.
    This patch fixes that.
    
    Cc: stable@vger.kernel.org
    Fixes: 62c1bff593b7 ("net: mana: Configure hwc timeout from hardware")
    Signed-off-by: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
    Reviewed-by: Brett Creeley <brett.creeley@amd.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Link: https://lore.kernel.org/r/1716185104-31658-1-git-send-email-schakrabarti@linux.microsoft.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: micrel: Fix lan8841_config_intr after getting out of sleep mode [+ + +]
Author: Horatiu Vultur <horatiu.vultur@microchip.com>
Date:   Fri May 24 10:53:50 2024 +0200

    net: micrel: Fix lan8841_config_intr after getting out of sleep mode
    
    [ Upstream commit 4fb679040d9f758eeb3b4d01bbde6405bf20e64e ]
    
    When the interrupt is enabled, the function lan8841_config_intr tries to
    clear any pending interrupts by reading the interrupt status, then
    checks the return value for errors and then continue to enable the
    interrupt. It has been seen that once the system gets out of sleep mode,
    the interrupt status has the value 0x400 meaning that the PHY detected
    that the link was in low power. That is correct value but the problem is
    that the check is wrong.  We try to check for errors but we return an
    error also in this case which is not an error. Therefore fix this by
    returning only when there is an error.
    
    Fixes: a8f1a19d27ef ("net: micrel: Add support for lan8841 PHY")
    Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Reviewed-by: Suman Ghosh <sumang@marvell.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Link: https://lore.kernel.org/r/20240524085350.359812-1-horatiu.vultur@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: micrel: Fix receiving the timestamp in the frame for lan8841 [+ + +]
Author: Horatiu Vultur <horatiu.vultur@microchip.com>
Date:   Mon May 13 21:21:57 2024 +0200

    net: micrel: Fix receiving the timestamp in the frame for lan8841
    
    [ Upstream commit aea27a92a41dae14843f92c79e9e42d8f570105c ]
    
    The blamed commit started to use the ptp workqueue to get the second
    part of the timestamp. And when the port was set down, then this
    workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING
    is not enabled, then the ptp_clock is not initialized so then it would
    crash when it would try to access the delayed work.
    So then basically by setting up and then down the port, it would crash.
    The fix consists in checking if the ptp_clock is initialized and only
    then cancel the delayed work.
    
    Fixes: cc7554954848 ("net: micrel: Change to receive timestamp in the frame for lan8841")
    Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: openvswitch: fix overwriting ct original tuple for ICMPv6 [+ + +]
Author: Ilya Maximets <i.maximets@ovn.org>
Date:   Thu May 9 11:38:05 2024 +0200

    net: openvswitch: fix overwriting ct original tuple for ICMPv6
    
    [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ]
    
    OVS_PACKET_CMD_EXECUTE has 3 main attributes:
     - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
     - OVS_PACKET_ATTR_PACKET - Binary packet content.
     - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
    
    OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
    with the metadata like conntrack state, input port, recirculation id,
    etc.  Then the packet itself gets parsed to populate the rest of the
    keys from the packet headers.
    
    Whenever the packet parsing code starts parsing the ICMPv6 header, it
    first zeroes out fields in the key corresponding to Neighbor Discovery
    information even if it is not an ND packet.
    
    It is an 'ipv6.nd' field.  However, the 'ipv6' is a union that shares
    the space between 'nd' and 'ct_orig' that holds the original tuple
    conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
    
    ND packets should not normally have conntrack state, so it's fine to
    share the space, but normal ICMPv6 Echo packets or maybe other types of
    ICMPv6 can have the state attached and it should not be overwritten.
    
    The issue results in all but the last 4 bytes of the destination
    address being wiped from the original conntrack tuple leading to
    incorrect packet matching and potentially executing wrong actions
    in case this packet recirculates within the datapath or goes back
    to userspace.
    
    ND fields should not be accessed in non-ND packets, so not clearing
    them should be fine.  Executing memset() only for actual ND packets to
    avoid the issue.
    
    Initializing the whole thing before parsing is needed because ND packet
    may not contain all the options.
    
    The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't
    affect packets entering OVS datapath from network interfaces, because
    in this case CT metadata is populated from skb after the packet is
    already parsed.
    
    Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.")
    Reported-by: Antonin Bas <antonin.bas@broadcom.com>
    Closes: https://github.com/openvswitch/ovs-issues/issues/327
    Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
    Acked-by: Aaron Conole <aconole@redhat.com>
    Acked-by: Eelco Chaudron <echaudro@redhat.com>
    Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ8061 [+ + +]
Author: Mathieu Othacehe <m.othacehe@gmail.com>
Date:   Tue May 21 08:54:06 2024 +0200

    net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ8061
    
    [ Upstream commit 128d54fbcb14b8717ecf596d3dbded327b9980b3 ]
    
    Following a similar reinstate for the KSZ8081 and KSZ9031.
    
    Older kernels would use the genphy_soft_reset if the PHY did not implement
    a .soft_reset.
    
    The KSZ8061 errata described here:
    https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8061-Errata-DS80000688B.pdf
    and worked around with 232ba3a51c ("net: phy: Micrel KSZ8061: link failure after cable connect")
    is back again without this soft reset.
    
    Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
    Tested-by: Karim Ben Houcine <karim.benhoucine@landisgyr.com>
    Signed-off-by: Mathieu Othacehe <othacehe@gnu.org>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    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: qrtr: ns: Fix module refcnt [+ + +]
Author: Chris Lew <quic_clew@quicinc.com>
Date:   Mon May 13 10:31:46 2024 -0700

    net: qrtr: ns: Fix module refcnt
    
    [ Upstream commit fd76e5ccc48f9f54eb44909dd7c0b924005f1582 ]
    
    The qrtr protocol core logic and the qrtr nameservice are combined into
    a single module. Neither the core logic or nameservice provide much
    functionality by themselves; combining the two into a single module also
    prevents any possible issues that may stem from client modules loading
    inbetween qrtr and the ns.
    
    Creating a socket takes two references to the module that owns the
    socket protocol. Since the ns needs to create the control socket, this
    creates a scenario where there are always two references to the qrtr
    module. This prevents the execution of 'rmmod' for qrtr.
    
    To resolve this, forcefully put the module refcount for the socket
    opened by the nameservice.
    
    Fixes: a365023a76f2 ("net: qrtr: combine nameservice into main module")
    Reported-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Signed-off-by: Chris Lew <quic_clew@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: relax socket state check at accept time. [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue May 21 16:01:00 2024 +0200

    net: relax socket state check at accept time.
    
    [ Upstream commit 26afda78cda3da974fd4c287962c169e9462c495 ]
    
    Christoph reported the following splat:
    
    WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0
    Modules linked in:
    CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
    RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759
    Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80
    RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293
    RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64
    R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000
    R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800
    FS:  000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786
     do_accept+0x435/0x620 net/socket.c:1929
     __sys_accept4_file net/socket.c:1969 [inline]
     __sys_accept4+0x9b/0x110 net/socket.c:1999
     __do_sys_accept net/socket.c:2016 [inline]
     __se_sys_accept net/socket.c:2013 [inline]
     __x64_sys_accept+0x7d/0x90 net/socket.c:2013
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    RIP: 0033:0x4315f9
    Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 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 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00
    RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
    RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
    RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300
    R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055
     </TASK>
    
    The reproducer invokes shutdown() before entering the listener status.
    After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for
    TCP_SYN_RECV sockets"), the above causes the child to reach the accept
    syscall in FIN_WAIT1 status.
    
    Eric noted we can relax the existing assertion in __inet_accept()
    
    Reported-by: Christoph Paasch <cpaasch@apple.com>
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/490
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Fixes: 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets")
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/23ab880a44d8cfd967e84de8b93dbf48848e3d8c.1716299669.git.pabeni@redhat.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: smc91x: Fix m68k kernel compilation for ColdFire CPU [+ + +]
Author: Thorsten Blum <thorsten.blum@toblux.com>
Date:   Fri May 10 13:30:55 2024 +0200

    net: smc91x: Fix m68k kernel compilation for ColdFire CPU
    
    commit 5eefb477d21a26183bc3499aeefa991198315a2d upstream.
    
    Compiling the m68k kernel with support for the ColdFire CPU family fails
    with the following error:
    
    In file included from drivers/net/ethernet/smsc/smc91x.c:80:
    drivers/net/ethernet/smsc/smc91x.c: In function ‘smc_reset’:
    drivers/net/ethernet/smsc/smc91x.h:160:40: error: implicit declaration of function ‘_swapw’; did you mean ‘swap’? [-Werror=implicit-function-declaration]
      160 | #define SMC_outw(lp, v, a, r)   writew(_swapw(v), (a) + (r))
          |                                        ^~~~~~
    drivers/net/ethernet/smsc/smc91x.h:904:25: note: in expansion of macro ‘SMC_outw’
      904 |                         SMC_outw(lp, x, ioaddr, BANK_SELECT);           \
          |                         ^~~~~~~~
    drivers/net/ethernet/smsc/smc91x.c:250:9: note: in expansion of macro ‘SMC_SELECT_BANK’
      250 |         SMC_SELECT_BANK(lp, 2);
          |         ^~~~~~~~~~~~~~~
    cc1: some warnings being treated as errors
    
    The function _swapw() was removed in commit d97cf70af097 ("m68k: use
    asm-generic/io.h for non-MMU io access functions"), but is still used in
    drivers/net/ethernet/smsc/smc91x.h.
    
    Use ioread16be() and iowrite16be() to resolve the error.
    
    Cc: stable@vger.kernel.org
    Fixes: d97cf70af097 ("m68k: use asm-generic/io.h for non-MMU io access functions")
    Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20240510113054.186648-2-thorsten.blum@toblux.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: ti: icssg-prueth: Fix start counter for ft1 filter [+ + +]
Author: MD Danish Anwar <danishanwar@ti.com>
Date:   Mon May 27 12:00:15 2024 +0530

    net: ti: icssg-prueth: Fix start counter for ft1 filter
    
    [ Upstream commit 56a5cf538c3f2d935b0d81040a8303b6e7fc5fd8 ]
    
    The start counter for FT1 filter is wrongly set to 0 in the driver.
    FT1 is used for source address violation (SAV) check and source address
    starts at Byte 6 not Byte 0. Fix this by changing start counter to
    ETH_ALEN in icssg_ft1_set_mac_addr().
    
    Fixes: e9b4ece7d74b ("net: ti: icssg-prueth: Add Firmware config and classification APIs.")
    Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
    Link: https://lore.kernel.org/r/20240527063015.263748-1-danishanwar@ti.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe() [+ + +]
Author: Romain Gantois <romain.gantois@bootlin.com>
Date:   Tue May 21 14:44:11 2024 +0200

    net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe()
    
    commit b31c7e78086127a7fcaa761e8d336ee855a920c6 upstream.
    
    In the prueth_probe() function, if one of the calls to emac_phy_connect()
    fails due to of_phy_connect() returning NULL, then the subsequent call to
    phy_attached_info() will dereference a NULL pointer.
    
    Check the return code of emac_phy_connect and fail cleanly if there is an
    error.
    
    Fixes: 128d5874c082 ("net: ti: icssg-prueth: Add ICSSG ethernet driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: MD Danish Anwar <danishanwar@ti.com>
    Link: https://lore.kernel.org/r/20240521-icssg-prueth-fix-v1-1-b4b17b1433e9@bootlin.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: qmi_wwan: add Telit FN920C04 compositions [+ + +]
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Thu Apr 18 13:12:07 2024 +0200

    net: usb: qmi_wwan: add Telit FN920C04 compositions
    
    [ Upstream commit 0b8fe5bd73249dc20be2e88a12041f8920797b59 ]
    
    Add the following Telit FN920C04 compositions:
    
    0x10a0: rmnet + tty (AT/NMEA) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#=  5 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a0 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x10a4: rmnet + tty (AT) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#=  8 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a4 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x10a9: rmnet + tty (AT) + tty (diag) + DPL (data packet logging) + adb
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#=  9 Spd=480  MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a9 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: smsc95xx: fix changing LED_SEL bit value updated from EEPROM [+ + +]
Author: Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
Date:   Thu May 23 14:23:14 2024 +0530

    net: usb: smsc95xx: fix changing LED_SEL bit value updated from EEPROM
    
    [ Upstream commit 52a2f0608366a629d43dacd3191039c95fef74ba ]
    
    LED Select (LED_SEL) bit in the LED General Purpose IO Configuration
    register is used to determine the functionality of external LED pins
    (Speed Indicator, Link and Activity Indicator, Full Duplex Link
    Indicator). The default value for this bit is 0 when no EEPROM is
    present. If a EEPROM is present, the default value is the value of the
    LED Select bit in the Configuration Flags of the EEPROM. A USB Reset or
    Lite Reset (LRST) will cause this bit to be restored to the image value
    last loaded from EEPROM, or to be set to 0 if no EEPROM is present.
    
    While configuring the dual purpose GPIO/LED pins to LED outputs in the
    LED General Purpose IO Configuration register, the LED_SEL bit is changed
    as 0 and resulting the configured value from the EEPROM is cleared. The
    issue is fixed by using read-modify-write approach.
    
    Fixes: f293501c61c5 ("smsc95xx: configure LED outputs")
    Signed-off-by: Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Woojung Huh <woojung.huh@microchip.com>
    Link: https://lore.kernel.org/r/20240523085314.167650-1-Parthiban.Veerasooran@microchip.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: smsc95xx: stop lying about skb->truesize [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu May 9 08:33:13 2024 +0000

    net: usb: smsc95xx: stop lying about skb->truesize
    
    [ Upstream commit d50729f1d60bca822ef6d9c1a5fb28d486bd7593 ]
    
    Some usb drivers try to set small skb->truesize and break
    core networking stacks.
    
    In this patch, I removed one of the skb->truesize override.
    
    I also replaced one skb_clone() by an allocation of a fresh
    and small skb, to get minimally sized skbs, like we did
    in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize
    in rx path") and 4ce62d5b2f7a ("net: usb: ax88179_178a:
    stop lying about skb->truesize")
    
    v3: also fix a sparse error ( https://lore.kernel.org/oe-kbuild-all/202405091310.KvncIecx-lkp@intel.com/ )
    v2: leave the skb_trim() game because smsc95xx_rx_csum_offload()
        needs the csum part. (Jakub)
        While we are it, use get_unaligned() in smsc95xx_rx_csum_offload().
    
    Fixes: 2f7ca802bdae ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Steve Glendinning <steve.glendinning@shawell.net>
    Cc: UNGLinuxDriver@microchip.com
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240509083313.2113832-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: sr9700: stop lying about skb->truesize [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 6 14:39:39 2024 +0000

    net: usb: sr9700: stop lying about skb->truesize
    
    [ Upstream commit 05417aa9c0c038da2464a0c504b9d4f99814a23b ]
    
    Some usb drivers set small skb->truesize and break
    core networking stacks.
    
    In this patch, I removed one of the skb->truesize override.
    
    I also replaced one skb_clone() by an allocation of a fresh
    and small skb, to get minimally sized skbs, like we did
    in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize
    in rx path") and 4ce62d5b2f7a ("net: usb: ax88179_178a:
    stop lying about skb->truesize")
    
    Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240506143939.3673865-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: wangxun: fix to change Rx features [+ + +]
Author: Jiawen Wu <jiawenwu@trustnetic.com>
Date:   Fri May 17 14:51:38 2024 +0800

    net: wangxun: fix to change Rx features
    
    [ Upstream commit 68067f065ee730c7c67b361c3c81808d25d5a90b ]
    
    Fix the issue where some Rx features cannot be changed.
    
    When using ethtool -K to turn off rx offload, it returns error and
    displays "Could not change any device features". And netdev->features
    is not assigned a new value to actually configure the hardware.
    
    Fixes: 6dbedcffcf54 ("net: libwx: Implement xx_set_features ops")
    Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: net:fec: Add fec_enet_deinit() [+ + +]
Author: Xiaolei Wang <xiaolei.wang@windriver.com>
Date:   Fri May 24 13:05:28 2024 +0800

    net:fec: Add fec_enet_deinit()
    
    [ Upstream commit bf0497f53c8535f99b72041529d3f7708a6e2c0d ]
    
    When fec_probe() fails or fec_drv_remove() needs to release the
    fec queue and remove a NAPI context, therefore add a function
    corresponding to fec_enet_init() and call fec_enet_deinit() which
    does the opposite to release memory and remove a NAPI context.
    
    Fixes: 59d0f7465644 ("net: fec: init multi queue date structure")
    Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
    Reviewed-by: Wei Fang <wei.fang@nxp.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20240524050528.4115581-1-xiaolei.wang@windriver.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: ipset: Add list flush to cancel_gc [+ + +]
Author: Alexander Maltsev <keltar.gw@gmail.com>
Date:   Wed Apr 17 18:51:41 2024 +0500

    netfilter: ipset: Add list flush to cancel_gc
    
    [ Upstream commit c1193d9bbbd379defe9be3c6de566de684de8a6f ]
    
    Flushing list in cancel_gc drops references to other lists right away,
    without waiting for RCU to destroy list. Fixes race when referenced
    ipsets can't be destroyed while referring list is scheduled for destroy.
    
    Fixes: 97f7cf1cd80e ("netfilter: ipset: fix performance regression in swap operation")
    Signed-off-by: Alexander Maltsev <keltar.gw@gmail.com>
    Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed May 15 13:23:39 2024 +0000

    netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
    
    [ Upstream commit dc21c6cc3d6986d938efbf95de62473982c98dec ]
    
    syzbot reported that nf_reinject() could be called without rcu_read_lock() :
    
    WARNING: suspicious RCU usage
    6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted
    
    net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 1
    2 locks held by syz-executor.4/13427:
      #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]
      #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]
      #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471
      #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
      #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]
      #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172
    
    stack backtrace:
    CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
    Call Trace:
     <IRQ>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
      lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
      nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]
      nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397
      nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]
      instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172
      rcu_do_batch kernel/rcu/tree.c:2196 [inline]
      rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471
      handle_softirqs+0x2d6/0x990 kernel/softirq.c:554
      __do_softirq kernel/softirq.c:588 [inline]
      invoke_softirq kernel/softirq.c:428 [inline]
      __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637
      irq_exit_rcu+0x9/0x30 kernel/softirq.c:649
      instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
      sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
     </IRQ>
     <TASK>
    
    Fixes: 9872bec773c2 ("[NETFILTER]: nfnetlink: use RCU for queue instances hash")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_fib: allow from forward/input without iif selector [+ + +]
Author: Eric Garver <eric@garver.life>
Date:   Tue May 21 10:25:05 2024 -0400

    netfilter: nft_fib: allow from forward/input without iif selector
    
    [ Upstream commit e8ded22ef0f4831279c363c264cd41cd9d59ca9e ]
    
    This removes the restriction of needing iif selector in the
    forward/input hooks for fib lookups when requested result is
    oif/oifname.
    
    Removing this restriction allows "loose" lookups from the forward hooks.
    
    Fixes: be8be04e5ddb ("netfilter: nft_fib: reverse path filter for policy-based routing on iif")
    Signed-off-by: Eric Garver <eric@garver.life>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_payload: restore vlan q-in-q match support [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu May 9 23:02:24 2024 +0200

    netfilter: nft_payload: restore vlan q-in-q match support
    
    [ Upstream commit aff5c01fa1284d606f8e7cbdaafeef2511bb46c1 ]
    
    Revert f6ae9f120dad ("netfilter: nft_payload: add C-VLAN support").
    
    f41f72d09ee1 ("netfilter: nft_payload: simplify vlan header handling")
    already allows to match on inner vlan tags by subtract the vlan header
    size to the payload offset which has been popped and stored in skbuff
    metadata fields.
    
    Fixes: f6ae9f120dad ("netfilter: nft_payload: add C-VLAN support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_payload: skbuff vlan metadata mangle support [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed May 8 22:50:34 2024 +0200

    netfilter: nft_payload: skbuff vlan metadata mangle support
    
    [ Upstream commit 33c563ebf8d3deed7d8addd20d77398ac737ef9a ]
    
    Userspace assumes vlan header is present at a given offset, but vlan
    offload allows to store this in metadata fields of the skbuff. Hence
    mangling vlan results in a garbled packet. Handle this transparently by
    adding a parser to the kernel.
    
    If vlan metadata is present and payload offset is over 12 bytes (source
    and destination mac address fields), then subtract vlan header present
    in vlan metadata, otherwise mangle vlan metadata based on offset and
    length, extracting data from the source register.
    
    This is similar to:
    
      8cfd23e67401 ("netfilter: nft_payload: work around vlan header stripping")
    
    to deal with vlan payload mangling.
    
    Fixes: 7ec3f7b47b8d ("netfilter: nft_payload: add packet mangling support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: tproxy: bail out if IP has been disabled on the device [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Mon May 13 12:27:15 2024 +0200

    netfilter: tproxy: bail out if IP has been disabled on the device
    
    [ Upstream commit 21a673bddc8fd4873c370caf9ae70ffc6d47e8d3 ]
    
    syzbot reports:
    general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI
    KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
    [..]
    RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62
    Call Trace:
     nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]
     nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168
    
    __in_dev_get_rcu() can return NULL, so check for this.
    
    Reported-and-tested-by: syzbot+b94a6818504ea90d7661@syzkaller.appspotmail.com
    Fixes: cc6eb4338569 ("tproxy: use the interface primary IP address as a default value for --on-ip")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netrom: fix possible dead-lock in nr_rt_ioctl() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed May 15 14:29:34 2024 +0000

    netrom: fix possible dead-lock in nr_rt_ioctl()
    
    [ Upstream commit e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6 ]
    
    syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]
    
    Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)
    
    [1]
    WARNING: possible circular locking dependency detected
    6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted
    ------------------------------------------------------
    syz-executor350/5129 is trying to acquire lock:
     ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
     ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]
     ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]
     ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
    
    but task is already holding lock:
     ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
     ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
     ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (nr_node_list_lock){+...}-{2:2}:
            lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
            __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
            _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
            spin_lock_bh include/linux/spinlock.h:356 [inline]
            nr_remove_node net/netrom/nr_route.c:299 [inline]
            nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355
            nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683
            sock_do_ioctl+0x158/0x460 net/socket.c:1222
            sock_ioctl+0x629/0x8e0 net/socket.c:1341
            vfs_ioctl fs/ioctl.c:51 [inline]
            __do_sys_ioctl fs/ioctl.c:904 [inline]
            __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
            do_syscall_x64 arch/x86/entry/common.c:52 [inline]
            do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
           entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    -> #0 (&nr_node->node_lock){+...}-{2:2}:
            check_prev_add kernel/locking/lockdep.c:3134 [inline]
            check_prevs_add kernel/locking/lockdep.c:3253 [inline]
            validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
            __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
            lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
            __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
            _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
            spin_lock_bh include/linux/spinlock.h:356 [inline]
            nr_node_lock include/net/netrom.h:152 [inline]
            nr_dec_obs net/netrom/nr_route.c:464 [inline]
            nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
            sock_do_ioctl+0x158/0x460 net/socket.c:1222
            sock_ioctl+0x629/0x8e0 net/socket.c:1341
            vfs_ioctl fs/ioctl.c:51 [inline]
            __do_sys_ioctl fs/ioctl.c:904 [inline]
            __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
            do_syscall_x64 arch/x86/entry/common.c:52 [inline]
            do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
           entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(nr_node_list_lock);
                                   lock(&nr_node->node_lock);
                                   lock(nr_node_list_lock);
      lock(&nr_node->node_lock);
    
     *** DEADLOCK ***
    
    1 lock held by syz-executor350/5129:
      #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
      #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
      #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697
    
    stack backtrace:
    CPU: 0 PID: 5129 Comm: syz-executor350 Not tainted 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
      check_noncircular+0x36a/0x4a0 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+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
      __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
      lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
      __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
      _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
      spin_lock_bh include/linux/spinlock.h:356 [inline]
      nr_node_lock include/net/netrom.h:152 [inline]
      nr_dec_obs net/netrom/nr_route.c:464 [inline]
      nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
      sock_do_ioctl+0x158/0x460 net/socket.c:1222
      sock_ioctl+0x629/0x8e0 net/socket.c:1341
      vfs_ioctl fs/ioctl.c:51 [inline]
      __do_sys_ioctl fs/ioctl.c:904 [inline]
      __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    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/20240515142934.3708038-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfc: nci: Fix handling of zero-length payload packets in nci_rx_work() [+ + +]
Author: Ryosuke Yasuoka <ryasuoka@redhat.com>
Date:   Wed May 22 00:34:42 2024 +0900

    nfc: nci: Fix handling of zero-length payload packets in nci_rx_work()
    
    [ Upstream commit 6671e352497ca4bb07a96c48e03907065ff77d8a ]
    
    When nci_rx_work() receives a zero-length payload packet, it should not
    discard the packet and exit the loop. Instead, it should continue
    processing subsequent packets.
    
    Fixes: d24b03535e5e ("nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet")
    Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20240521153444.535399-1-ryasuoka@redhat.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nfc: nci: Fix uninit-value in nci_rx_work [+ + +]
Author: Ryosuke Yasuoka <ryasuoka@redhat.com>
Date:   Sun May 19 18:43:03 2024 +0900

    nfc: nci: Fix uninit-value in nci_rx_work
    
    [ Upstream commit e4a87abf588536d1cdfb128595e6e680af5cf3ed ]
    
    syzbot reported the following uninit-value access issue [1]
    
    nci_rx_work() parses received packet from ndev->rx_q. It should be
    validated header size, payload size and total packet size before
    processing the packet. If an invalid packet is detected, it should be
    silently discarded.
    
    Fixes: d24b03535e5e ("nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet")
    Reported-and-tested-by: syzbot+d7b4dc6cd50410152534@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=d7b4dc6cd50410152534 [1]
    Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfs: keep server info for remounts [+ + +]
Author: Martin Kaiser <martin@kaiser.cx>
Date:   Sun Apr 14 19:01:09 2024 +0200

    nfs: keep server info for remounts
    
    [ Upstream commit b322bf9e983addedff0894c55e92d58f4d16d92a ]
    
    With newer kernels that use fs_context for nfs mounts, remounts fail with
    -EINVAL.
    
    $ mount -t nfs -o nolock 10.0.0.1:/tmp/test /mnt/test/
    $ mount -t nfs -o remount /mnt/test/
    mount: mounting 10.0.0.1:/tmp/test on /mnt/test failed: Invalid argument
    
    For remounts, the nfs server address and port are populated by
    nfs_init_fs_context and later overwritten with 0x00 bytes by
    nfs23_parse_monolithic. The remount then fails as the server address is
    invalid.
    
    Fix this by not overwriting nfs server info in nfs23_parse_monolithic if
    we're doing a remount.
    
    Fixes: f2aedb713c28 ("NFS: Add fs_context support.")
    Signed-off-by: Martin Kaiser <martin@kaiser.cx>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSv4: Fixup smatch warning for ambiguous return [+ + +]
Author: Benjamin Coddington <bcodding@redhat.com>
Date:   Wed Apr 17 14:49:29 2024 -0400

    NFSv4: Fixup smatch warning for ambiguous return
    
    [ Upstream commit 37ffe06537af3e3ec212e7cbe941046fce0a822f ]
    
    Dan Carpenter reports smatch warning for nfs4_try_migration() when a memory
    allocation failure results in a zero return value.  In this case, a
    transient allocation failure error will likely be retried the next time the
    server responds with NFS4ERR_MOVED.
    
    We can fixup the smatch warning with a small refactor: attempt all three
    allocations before testing and returning on a failure.
    
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Fixes: c3ed222745d9 ("NFSv4: Fix free of uninitialized nfs4_label on referral lookup.")
    Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nilfs2: fix out-of-range warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 28 15:30:44 2024 +0100

    nilfs2: fix out-of-range warning
    
    [ Upstream commit c473bcdd80d4ab2ae79a7a509a6712818366e32a ]
    
    clang-14 points out that v_size is always smaller than a 64KB
    page size if that is configured by the CPU architecture:
    
    fs/nilfs2/ioctl.c:63:19: error: result of comparison of constant 65536 with expression of type '__u16' (aka 'unsigned short') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
            if (argv->v_size > PAGE_SIZE)
                ~~~~~~~~~~~~ ^ ~~~~~~~~~
    
    This is ok, so just shut up that warning with a cast.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240328143051.1069575-7-arnd@kernel.org
    Fixes: 3358b4aaa84f ("nilfs2: fix problems of memory allocation in ioctl")
    Acked-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reviewed-by: Justin Stitt <justinstitt@google.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nilfs2: fix potential hang in nilfs_detach_log_writer() [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Mon May 20 22:26:21 2024 +0900

    nilfs2: fix potential hang in nilfs_detach_log_writer()
    
    commit eb85dace897c5986bc2f36b3c783c6abb8a4292e upstream.
    
    Syzbot has reported a potential hang in nilfs_detach_log_writer() called
    during nilfs2 unmount.
    
    Analysis revealed that this is because nilfs_segctor_sync(), which
    synchronizes with the log writer thread, can be called after
    nilfs_segctor_destroy() terminates that thread, as shown in the call trace
    below:
    
    nilfs_detach_log_writer
      nilfs_segctor_destroy
        nilfs_segctor_kill_thread  --> Shut down log writer thread
        flush_work
          nilfs_iput_work_func
            nilfs_dispose_list
              iput
                nilfs_evict_inode
                  nilfs_transaction_commit
                    nilfs_construct_segment (if inode needs sync)
                      nilfs_segctor_sync  --> Attempt to synchronize with
                                              log writer thread
                               *** DEADLOCK ***
    
    Fix this issue by changing nilfs_segctor_sync() so that the log writer
    thread returns normally without synchronizing after it terminates, and by
    forcing tasks that are already waiting to complete once after the thread
    terminates.
    
    The skipped inode metadata flushout will then be processed together in the
    subsequent cleanup work in nilfs_segctor_destroy().
    
    Link: https://lkml.kernel.org/r/20240520132621.4054-4-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+e3973c409251e136fdd0@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=e3973c409251e136fdd0
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Cc: "Bai, Shuangpeng" <sjb7183@psu.edu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: fix unexpected freezing of nilfs_segctor_sync() [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Mon May 20 22:26:20 2024 +0900

    nilfs2: fix unexpected freezing of nilfs_segctor_sync()
    
    commit 936184eadd82906992ff1f5ab3aada70cce44cee upstream.
    
    A potential and reproducible race issue has been identified where
    nilfs_segctor_sync() would block even after the log writer thread writes a
    checkpoint, unless there is an interrupt or other trigger to resume log
    writing.
    
    This turned out to be because, depending on the execution timing of the
    log writer thread running in parallel, the log writer thread may skip
    responding to nilfs_segctor_sync(), which causes a call to schedule()
    waiting for completion within nilfs_segctor_sync() to lose the opportunity
    to wake up.
    
    The reason why waking up the task waiting in nilfs_segctor_sync() may be
    skipped is that updating the request generation issued using a shared
    sequence counter and adding an wait queue entry to the request wait queue
    to the log writer, are not done atomically.  There is a possibility that
    log writing and request completion notification by nilfs_segctor_wakeup()
    may occur between the two operations, and in that case, the wait queue
    entry is not yet visible to nilfs_segctor_wakeup() and the wake-up of
    nilfs_segctor_sync() will be carried over until the next request occurs.
    
    Fix this issue by performing these two operations simultaneously within
    the lock section of sc_state_lock.  Also, following the memory barrier
    guidelines for event waiting loops, move the call to set_current_state()
    in the same location into the event waiting loop to ensure that a memory
    barrier is inserted just before the event condition determination.
    
    Link: https://lkml.kernel.org/r/20240520132621.4054-3-konishi.ryusuke@gmail.com
    Fixes: 9ff05123e3bf ("nilfs2: segment constructor")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Cc: "Bai, Shuangpeng" <sjb7183@psu.edu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: fix use-after-free of timer for log writer thread [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Mon May 20 22:26:19 2024 +0900

    nilfs2: fix use-after-free of timer for log writer thread
    
    commit f5d4e04634c9cf68bdf23de08ada0bb92e8befe7 upstream.
    
    Patch series "nilfs2: fix log writer related issues".
    
    This bug fix series covers three nilfs2 log writer-related issues,
    including a timer use-after-free issue and potential deadlock issue on
    unmount, and a potential freeze issue in event synchronization found
    during their analysis.  Details are described in each commit log.
    
    
    This patch (of 3):
    
    A use-after-free issue has been reported regarding the timer sc_timer on
    the nilfs_sc_info structure.
    
    The problem is that even though it is used to wake up a sleeping log
    writer thread, sc_timer is not shut down until the nilfs_sc_info structure
    is about to be freed, and is used regardless of the thread's lifetime.
    
    Fix this issue by limiting the use of sc_timer only while the log writer
    thread is alive.
    
    Link: https://lkml.kernel.org/r/20240520132621.4054-1-konishi.ryusuke@gmail.com
    Link: https://lkml.kernel.org/r/20240520132621.4054-2-konishi.ryusuke@gmail.com
    Fixes: fdce895ea5dd ("nilfs2: change sc_timer from a pointer to an embedded one in struct nilfs_sc_info")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: "Bai, Shuangpeng" <sjb7183@psu.edu>
    Closes: https://groups.google.com/g/syzkaller/c/MK_LYqtt8ko/m/8rgdWeseAwAJ
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nouveau: add an ioctl to report vram usage [+ + +]
Author: Dave Airlie <airlied@redhat.com>
Date:   Wed Jan 24 14:24:25 2024 +1000

    nouveau: add an ioctl to report vram usage
    
    [ Upstream commit 72fa02fdf83306c52bc1eede28359e3fa32a151a ]
    
    This reports the currently used vram allocations.
    
    userspace using this has been proposed for nvk, but
    it's a rather trivial uapi addition.
    
    Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Stable-dep-of: aed9a1a4f710 ("drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nouveau: add an ioctl to return vram bar size. [+ + +]
Author: Dave Airlie <airlied@redhat.com>
Date:   Wed Jan 24 13:50:58 2024 +1000

    nouveau: add an ioctl to return vram bar size.
    
    [ Upstream commit 3f4d8aac6e768c2215ce68275256971c2f54f0c8 ]
    
    This returns the BAR resources size so userspace can make
    decisions based on rebar support.
    
    userspace using this has been proposed for nvk, but
    it's a rather trivial uapi addition.
    
    Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Stable-dep-of: aed9a1a4f710 ("drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nouveau: report byte usage in VRAM usage. [+ + +]
Author: Dave Airlie <airlied@redhat.com>
Date:   Mon Feb 26 17:16:10 2024 +1000

    nouveau: report byte usage in VRAM usage.
    
    commit f7916c47f66d778817068d86e5c9b5e511e23c86 upstream.
    
    Turns out usage is always in bytes not shifted.
    
    Fixes: 72fa02fdf833 ("nouveau: add an ioctl to report vram usage")
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
null_blk: Fix missing mutex_destroy() at module removal [+ + +]
Author: Zhu Yanjun <yanjun.zhu@linux.dev>
Date:   Thu Apr 25 19:16:35 2024 +0200

    null_blk: Fix missing mutex_destroy() at module removal
    
    [ Upstream commit 07d1b99825f40f9c0d93e6b99d79a08d0717bac1 ]
    
    When a mutex lock is not used any more, the function mutex_destroy
    should be called to mark the mutex lock uninitialized.
    
    Fixes: f2298c0403b0 ("null_blk: multi queue aware block test driver")
    Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
    Link: https://lore.kernel.org/r/20240425171635.4227-1-yanjun.zhu@linux.dev
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

null_blk: Fix the WARNING: modpost: missing MODULE_DESCRIPTION() [+ + +]
Author: Zhu Yanjun <yanjun.zhu@linux.dev>
Date:   Mon May 6 09:55:38 2024 +0200

    null_blk: Fix the WARNING: modpost: missing MODULE_DESCRIPTION()
    
    [ Upstream commit 9e6727f824edcdb8fdd3e6e8a0862eb49546e1cd ]
    
    No functional changes intended.
    
    Fixes: f2298c0403b0 ("null_blk: multi queue aware block test driver")
    Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Link: https://lore.kernel.org/r/20240506075538.6064-1-yanjun.zhu@linux.dev
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-multipath: fix io accounting on failover [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Tue May 21 11:02:28 2024 -0700

    nvme-multipath: fix io accounting on failover
    
    [ Upstream commit a2e4c5f5f68dbd206f132bc709b98dea64afc3b8 ]
    
    There are io stats accounting that needs to be handled, so don't call
    blk_mq_end_request() directly. Use the existing nvme_end_req() helper
    that already handles everything.
    
    Fixes: d4d957b53d91ee ("nvme-multipath: support io stats on the mpath device")
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-tcp: add definitions for TLS cipher suites [+ + +]
Author: Hannes Reinecke <hare@suse.de>
Date:   Thu Aug 24 16:39:11 2023 +0200

    nvme-tcp: add definitions for TLS cipher suites
    
    [ Upstream commit a86062aac34d100a3117c0fff91ee1892ebfb460 ]
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Stable-dep-of: a2e4c5f5f68d ("nvme-multipath: fix io accounting on failover")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme: cancel pending I/O if nvme controller is in terminal state [+ + +]
Author: Nilay Shroff <nilay@linux.ibm.com>
Date:   Thu Apr 25 19:33:00 2024 +0530

    nvme: cancel pending I/O if nvme controller is in terminal state
    
    [ Upstream commit 25bb3534ee21e39eb9301c4edd7182eb83cb0d07 ]
    
    While I/O is running, if the pci bus error occurs then
    in-flight I/O can not complete. Worst, if at this time,
    user (logically) hot-unplug the nvme disk then the
    nvme_remove() code path can't forward progress until
    in-flight I/O is cancelled. So these sequence of events
    may potentially hang hot-unplug code path indefinitely.
    This patch helps cancel the pending/in-flight I/O from the
    nvme request timeout handler in case the nvme controller
    is in the terminal (DEAD/DELETING/DELETING_NOIO) state and
    that helps nvme_remove() code path forward progress and
    finish successfully.
    
    Link: https://lore.kernel.org/all/199be893-5dfa-41e5-b6f2-40ac90ebccc4@linux.ibm.com/
    Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvme: find numa distance only if controller has valid numa id [+ + +]
Author: Nilay Shroff <nilay@linux.ibm.com>
Date:   Tue Apr 16 13:49:23 2024 +0530

    nvme: find numa distance only if controller has valid numa id
    
    [ Upstream commit 863fe60ed27f2c85172654a63c5b827e72c8b2e6 ]
    
    On system where native nvme multipath is configured and iopolicy
    is set to numa but the nvme controller numa node id is undefined
    or -1 (NUMA_NO_NODE) then avoid calculating node distance for
    finding optimal io path. In such case we may access numa distance
    table with invalid index and that may potentially refer to incorrect
    memory. So this patch ensures that if the nvme controller numa node
    id is -1 then instead of calculating node distance for finding optimal
    io path, we set the numa node distance of such controller to default 10
    (LOCAL_DISTANCE).
    
    Link: https://lore.kernel.org/all/20240413090614.678353-1-nilay@linux.ibm.com/
    Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet-auth: replace pr_debug() with pr_err() to report an error. [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Wed Apr 10 11:48:42 2024 +0200

    nvmet-auth: replace pr_debug() with pr_err() to report an error.
    
    [ Upstream commit 445f9119e70368ccc964575c2a6d3176966a9d65 ]
    
    In nvmet_auth_host_hash(), if a mismatch is detected in the hash length
    the kernel should print an error.
    
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmet-auth: return the error code to the nvmet_auth_host_hash() callers [+ + +]
Author: Maurizio Lombardi <mlombard@redhat.com>
Date:   Wed Apr 10 11:48:41 2024 +0200

    nvmet-auth: return the error code to the nvmet_auth_host_hash() callers
    
    [ Upstream commit 46b8f9f74f6d500871985e22eb19560b21f3bc81 ]
    
    If the nvmet_auth_host_hash() function fails, the error code should
    be returned to its callers.
    
    Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet-tcp: fix possible memory leak when tearing down a controller [+ + +]
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Sun Apr 28 11:49:49 2024 +0300

    nvmet-tcp: fix possible memory leak when tearing down a controller
    
    [ Upstream commit 6825bdde44340c5a9121f6d6fa25cc885bd9e821 ]
    
    When we teardown the controller, we wait for pending I/Os to complete
    (sq->ref on all queues to drop to zero) and then we go over the commands,
    and free their command buffers in case they are still fetching data from
    the host (e.g. processing nvme writes) and have yet to take a reference
    on the sq.
    
    However, we may miss the case where commands have failed before executing
    and are queued for sending a response, but will never occur because the
    queue socket is already down. In this case we may miss deallocating command
    buffers.
    
    Solve this by freeing all commands buffers as nvmet_tcp_free_cmd_buffers is
    idempotent anyways.
    
    Reported-by: Yi Zhang <yi.zhang@redhat.com>
    Tested-by: Yi Zhang <yi.zhang@redhat.com>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet: fix ns enable/disable possible hang [+ + +]
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Tue May 21 23:20:28 2024 +0300

    nvmet: fix ns enable/disable possible hang
    
    [ Upstream commit f97914e35fd98b2b18fb8a092e0a0799f73afdfe ]
    
    When disabling an nvmet namespace, there is a period where the
    subsys->lock is released, as the ns disable waits for backend IO to
    complete, and the ns percpu ref to be properly killed. The original
    intent was to avoid taking the subsystem lock for a prolong period as
    other processes may need to acquire it (for example new incoming
    connections).
    
    However, it opens up a window where another process may come in and
    enable the ns, (re)intiailizing the ns percpu_ref, causing the disable
    sequence to hang.
    
    Solve this by taking the global nvmet_config_sem over the entire configfs
    enable/disable sequence.
    
    Fixes: a07b4970f464 ("nvmet: add a generic NVMe target")
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmet: fix nvme status code when namespace is disabled [+ + +]
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Sun Apr 28 12:25:40 2024 +0300

    nvmet: fix nvme status code when namespace is disabled
    
    [ Upstream commit 505363957fad35f7aed9a2b0d8dad73451a80fb5 ]
    
    If the user disabled a nvmet namespace, it is removed from the subsystem
    namespaces list. When nvmet processes a command directed to an nsid that
    was disabled, it cannot differentiate between a nsid that is disabled
    vs. a non-existent namespace, and resorts to return NVME_SC_INVALID_NS
    with the dnr bit set.
    
    This translates to a non-retryable status for the host, which translates
    to a user error. We should expect disabled namespaces to not cause an
    I/O error in a multipath environment.
    
    Address this by searching a configfs item for the namespace nvmet failed
    to find, and if we found one, conclude that the namespace is disabled
    (perhaps temporarily). Return NVME_SC_INTERNAL_PATH_ERROR in this case
    and keep DNR bit cleared.
    
    Reported-by: Jirong Feng <jirong.feng@easystack.cn>
    Tested-by: Jirong Feng <jirong.feng@easystack.cn>
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvmet: prevent sprintf() overflow in nvmet_subsys_nsid_exists() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed May 8 10:43:04 2024 +0300

    nvmet: prevent sprintf() overflow in nvmet_subsys_nsid_exists()
    
    [ Upstream commit d15dcd0f1a4753b57e66c64c8dc2a9779ff96aab ]
    
    The nsid value is a u32 that comes from nvmet_req_find_ns().  It's
    endian data and we're on an error path and both of those raise red
    flags.  So let's make this safer.
    
    1) Make the buffer large enough for any u32.
    2) Remove the unnecessary initialization.
    3) Use snprintf() instead of sprintf() for even more safety.
    4) The sprintf() function returns the number of bytes printed, not
       counting the NUL terminator. It is impossible for the return value to
       be <= 0 so delete that.
    
    Fixes: 505363957fad ("nvmet: fix nvme status code when namespace is disabled")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Octeontx2-pf: Free send queue buffers incase of leaf to inner [+ + +]
Author: Hariprasad Kelam <hkelam@marvell.com>
Date:   Thu May 23 13:06:26 2024 +0530

    Octeontx2-pf: Free send queue buffers incase of leaf to inner
    
    [ Upstream commit 1684842147677a1279bcff95f8adb6de9a656e30 ]
    
    There are two type of classes. "Leaf classes" that are  the
    bottom of the class hierarchy. "Inner classes" that are neither
    the root class nor leaf classes. QoS rules can only specify leaf
    classes as targets for traffic.
    
                             Root
                            /  \
                           /    \
                          1      2
                                 /\
                                /  \
                               4    5
                   classes 1,4 and 5 are leaf classes.
                   class 2 is a inner class.
    
    When a leaf class made as inner, or vice versa, resources associated
    with send queue (send queue buffers and transmit schedulers) are not
    getting freed.
    
    Fixes: 5e6808b4c68d ("octeontx2-pf: Add support for HTB offload")
    Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
    Link: https://lore.kernel.org/r/20240523073626.4114-1-hkelam@marvell.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
of: module: add buffer overflow check in of_modalias() [+ + +]
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Sun Apr 14 11:51:39 2024 +0300

    of: module: add buffer overflow check in of_modalias()
    
    [ Upstream commit cf7385cb26ac4f0ee6c7385960525ad534323252 ]
    
    In of_modalias(), if the buffer happens to be too small even for the 1st
    snprintf() call, the len parameter will become negative and str parameter
    (if not NULL initially) will point beyond the buffer's end. Add the buffer
    overflow check after the 1st snprintf() call and fix such check after the
    strlen() call (accounting for the terminating NUL char).
    
    Fixes: bc575064d688 ("of/device: use of_property_for_each_string to parse compatible strings")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/bbfc6be0-c687-62b6-d015-5141b93f313e@omp.ru
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
openpromfs: finish conversion to the new mount API [+ + +]
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Fri Mar 1 16:33:11 2024 -0600

    openpromfs: finish conversion to the new mount API
    
    [ Upstream commit 8f27829974b025d4df2e78894105d75e3bf349f0 ]
    
    The original mount API conversion inexplicably left out the change
    from ->remount_fs to ->reconfigure; do that now.
    
    Fixes: 7ab2fa7693c3 ("vfs: Convert openpromfs to use the new mount API")
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Link: https://lore.kernel.org/r/90b968aa-c979-420f-ba37-5acc3391b28f@redhat.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
openrisc: traps: Don't send signals to kernel mode threads [+ + +]
Author: Stafford Horne <shorne@gmail.com>
Date:   Sat Mar 30 14:42:49 2024 +0000

    openrisc: traps: Don't send signals to kernel mode threads
    
    [ Upstream commit c88cfb5cea5f8f9868ef02cc9ce9183a26dcf20f ]
    
    OpenRISC exception handling sends signals to user processes on floating
    point exceptions and trap instructions (for debugging) among others.
    There is a bug where the trap handling logic may send signals to kernel
    threads, we should not send these signals to kernel threads, if that
    happens we treat it as an error.
    
    This patch adds conditions to die if the kernel receives these
    exceptions in kernel mode code.
    
    Fixes: 27267655c531 ("openrisc: Support floating point user api")
    Signed-off-by: Stafford Horne <shorne@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
openvswitch: Set the skbuff pkt_type for proper pmtud support. [+ + +]
Author: Aaron Conole <aconole@redhat.com>
Date:   Thu May 16 16:09:41 2024 -0400

    openvswitch: Set the skbuff pkt_type for proper pmtud support.
    
    [ Upstream commit 30a92c9e3d6b073932762bef2ac66f4ee784c657 ]
    
    Open vSwitch is originally intended to switch at layer 2, only dealing with
    Ethernet frames.  With the introduction of l3 tunnels support, it crossed
    into the realm of needing to care a bit about some routing details when
    making forwarding decisions.  If an oversized packet would need to be
    fragmented during this forwarding decision, there is a chance for pmtu
    to get involved and generate a routing exception.  This is gated by the
    skbuff->pkt_type field.
    
    When a flow is already loaded into the openvswitch module this field is
    set up and transitioned properly as a packet moves from one port to
    another.  In the case that a packet execute is invoked after a flow is
    newly installed this field is not properly initialized.  This causes the
    pmtud mechanism to omit sending the required exception messages across
    the tunnel boundary and a second attempt needs to be made to make sure
    that the routing exception is properly setup.  To fix this, we set the
    outgoing packet's pkt_type to PACKET_OUTGOING, since it can only get
    to the openvswitch module via a port device or packet command.
    
    Even for bridge ports as users, the pkt_type needs to be reset when
    doing the transmit as the packet is truly outgoing and routing needs
    to get involved post packet transformations, in the case of
    VXLAN/GENEVE/udp-tunnel packets.  In general, the pkt_type on output
    gets ignored, since we go straight to the driver, but in the case of
    tunnel ports they go through IP routing layer.
    
    This issue is periodically encountered in complex setups, such as large
    openshift deployments, where multiple sets of tunnel traversal occurs.
    A way to recreate this is with the ovn-heater project that can setup
    a networking environment which mimics such large deployments.  We need
    larger environments for this because we need to ensure that flow
    misses occur.  In these environment, without this patch, we can see:
    
      ./ovn_cluster.sh start
      podman exec ovn-chassis-1 ip r a 170.168.0.5/32 dev eth1 mtu 1200
      podman exec ovn-chassis-1 ip netns exec sw01p1 ip r flush cache
      podman exec ovn-chassis-1 ip netns exec sw01p1 \
             ping 21.0.0.3 -M do -s 1300 -c2
      PING 21.0.0.3 (21.0.0.3) 1300(1328) bytes of data.
      From 21.0.0.3 icmp_seq=2 Frag needed and DF set (mtu = 1142)
    
      --- 21.0.0.3 ping statistics ---
      ...
    
    Using tcpdump, we can also see the expected ICMP FRAG_NEEDED message is not
    sent into the server.
    
    With this patch, setting the pkt_type, we see the following:
    
      podman exec ovn-chassis-1 ip netns exec sw01p1 \
             ping 21.0.0.3 -M do -s 1300 -c2
      PING 21.0.0.3 (21.0.0.3) 1300(1328) bytes of data.
      From 21.0.0.3 icmp_seq=1 Frag needed and DF set (mtu = 1222)
      ping: local error: message too long, mtu=1222
    
      --- 21.0.0.3 ping statistics ---
      ...
    
    In this case, the first ping request receives the FRAG_NEEDED message and
    a local routing exception is created.
    
    Tested-by: Jaime Caamano <jcaamano@redhat.com>
    Reported-at: https://issues.redhat.com/browse/FDP-164
    Fixes: 58264848a5a7 ("openvswitch: Add vxlan tunneling support.")
    Signed-off-by: Aaron Conole <aconole@redhat.com>
    Acked-by: Eelco Chaudron <echaudro@redhat.com>
    Link: https://lore.kernel.org/r/20240516200941.16152-1-aconole@redhat.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ovl: remove upper umask handling from ovl_create_upper() [+ + +]
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Thu May 2 20:35:57 2024 +0200

    ovl: remove upper umask handling from ovl_create_upper()
    
    [ Upstream commit 096802748ea1dea8b476938e0a8dc16f4bd2f1ad ]
    
    This is already done by vfs_prepare_mode() when creating the upper object
    by vfs_create(), vfs_mkdir() and vfs_mknod().
    
    No regressions have been observed in xfstests run with posix acls turned
    off for the upper filesystem.
    
    Fixes: 1639a49ccdce ("fs: move S_ISGID stripping into the vfs_*() helpers")
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
parisc: add missing export of __cmpxchg_u8() [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Mon Apr 1 22:35:54 2024 -0400

    parisc: add missing export of __cmpxchg_u8()
    
    [ Upstream commit c57e5dccb06decf3cb6c272ab138c033727149b5 ]
    
    __cmpxchg_u8() had been added (initially) for the sake of
    drivers/phy/ti/phy-tusb1210.c; the thing is, that drivers is
    modular, so we need an export
    
    Fixes: b344d6a83d01 "parisc: add support for cmpxchg on u8 pointers"
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/EDR: Align EDR_PORT_DPC_ENABLE_DSM with PCI Firmware r3.3 [+ + +]
Author: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Date:   Wed May 1 02:25:43 2024 +0000

    PCI/EDR: Align EDR_PORT_DPC_ENABLE_DSM with PCI Firmware r3.3
    
    [ Upstream commit f24ba846133d0edec785ac6430d4daf6e9c93a09 ]
    
    The "Downstream Port Containment related Enhancements" ECN of Jan 28, 2019
    (document 12888 below), defined the EDR_PORT_DPC_ENABLE_DSM function with
    Revision ID 5 with Arg3 being an integer.  But when the ECN was integrated
    into PCI Firmware r3.3, sec 4.6.12, it was defined as Revision ID 6 with
    Arg3 being a package containing an integer.
    
    The implementation in acpi_enable_dpc() supplies a package as Arg3 (arg4 in
    the code), but it previously specified Revision ID 5.  Align this with PCI
    Firmware r3.3 by using Revision ID 6.
    
    If firmware implemented per the ECN, its Revision 5 function would receive
    a package as Arg3 when it expects an integer, so acpi_enable_dpc() would
    likely fail.  If such firmware exists and lacks a Revision 6 function that
    expects a package, we may have to add support for Revision 5.
    
    Link: https://lore.kernel.org/r/20240501022543.1626025-1-sathyanarayanan.kuppuswamy@linux.intel.com
    Link: https://members.pcisig.com/wg/PCI-SIG/document/12888
    Fixes: ac1c8e35a326 ("PCI/DPC: Add Error Disconnect Recover (EDR) support")
    Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    [bhelgaas: split into two patches, update commit log]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Tested-by: Satish Thatchanamurthy <Satish.Thatchanamurt@Dell.com> # one platform
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI/EDR: Align EDR_PORT_LOCATE_DSM with PCI Firmware r3.3 [+ + +]
Author: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Date:   Wed May 8 14:31:38 2024 -0500

    PCI/EDR: Align EDR_PORT_LOCATE_DSM with PCI Firmware r3.3
    
    [ Upstream commit e2e78a294a8a863898b781dbcf90e087eda3155d ]
    
    The "Downstream Port Containment related Enhancements" ECN of Jan 28, 2019
    (document 12888 below), defined the EDR_PORT_LOCATE_DSM function with
    Revision ID 5 with a return value encoding (Bits 2:0 = Function, Bits 7:3 =
    Device, Bits 15:8 = Bus).  When the ECN was integrated into PCI Firmware
    r3.3, sec 4.6.13, Bit 31 was added to indicate success or failure.
    
    Check Bit 31 for failure in acpi_dpc_port_get().
    
    Link: https://lore.kernel.org/r/20240501022543.1626025-1-sathyanarayanan.kuppuswamy@linux.intel.com
    Link: https://members.pcisig.com/wg/PCI-SIG/document/12888
    Fixes: ac1c8e35a326 ("PCI/DPC: Add Error Disconnect Recover (EDR) support")
    Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    [bhelgaas: split into two patches, update commit log]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Tested-by: Satish Thatchanamurthy <Satish.Thatchanamurt@Dell.com> # one platform
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI: of_property: Return error for int_map allocation failure [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Sun Mar 3 18:57:29 2024 +0800

    PCI: of_property: Return error for int_map allocation failure
    
    [ Upstream commit e6f7d27df5d208b50cae817a91d128fb434bb12c ]
    
    Return -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a
    NULL pointer dereference in this case.
    
    Fixes: 407d1a51921e ("PCI: Create device tree node for bridge")
    Link: https://lore.kernel.org/r/20240303105729.78624-1-duoming@zju.edu.cn
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    [bhelgaas: commit log]
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: tegra194: Fix probe path for Endpoint mode [+ + +]
Author: Vidya Sagar <vidyas@nvidia.com>
Date:   Mon Apr 8 15:00:53 2024 +0530

    PCI: tegra194: Fix probe path for Endpoint mode
    
    [ Upstream commit 19326006a21da26532d982254677c892dae8f29b ]
    
    Tegra194 PCIe probe path is taking failure path in success case for
    Endpoint mode. Return success from the switch case instead of going
    into the failure path.
    
    Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194")
    Link: https://lore.kernel.org/linux-pci/20240408093053.3948634-1-vidyas@nvidia.com
    Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: Wait for Link Training==0 before starting Link retrain [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Tue Apr 23 16:08:19 2024 +0300

    PCI: Wait for Link Training==0 before starting Link retrain
    
    [ Upstream commit 73cb3a35f94db723c0211ad099bce55b2155e3f0 ]
    
    Two changes were made in link retraining logic independent of each other.
    
    The commit e7e39756363a ("PCI/ASPM: Avoid link retraining race") added a
    check to pcie_retrain_link() to ensure no Link Training is currently active
    to address the Implementation Note in PCIe r6.1 sec 7.5.3.7. At that time
    pcie_wait_for_retrain() only checked for the Link Training (LT) bit being
    cleared.
    
    The commit 680e9c47a229 ("PCI: Add support for polling DLLLA to
    pcie_retrain_link()") generalized pcie_wait_for_retrain() into
    pcie_wait_for_link_status() which can wait either for LT or the Data Link
    Layer Link Active (DLLLA) bit with 'use_lt' argument and supporting waiting
    for either cleared or set using 'active' argument.
    
    In the merge commit 1abb47390350 ("Merge branch 'pci/enumeration'"), those
    two divergent branches converged. The merge changed LT bit checking added
    in the commit e7e39756363a ("PCI/ASPM: Avoid link retraining race") to now
    wait for completion of any ongoing Link Training using DLLLA bit being set
    if 'use_lt' is false.
    
    When 'use_lt' is false, the pseudo-code steps of what occurs in
    pcie_retrain_link():
    
            1. Wait for DLLLA==1
            2. Trigger link to retrain
            3. Wait for DLLLA==1
    
    Step 3 waits for the link to come up from the retraining triggered by Step
    2. As Step 1 is supposed to wait for any ongoing retraining to end, using
    DLLLA also for it does not make sense because link training being active is
    still indicated using LT bit, not with DLLLA.
    
    Correct the pcie_wait_for_link_status() parameters in Step 1 to only wait
    for LT==0 to ensure there is no ongoing Link Training.
    
    This only impacts the Target Speed quirk, which is the only case where
    waiting for DLLLA bit is used. It currently works in the problematic case
    by means of link training getting initiated by hardware repeatedly and
    respecting the new link parameters set by the caller, which then make
    training succeed and bring the link up, setting DLLLA and causing
    pcie_wait_for_link_status() to return success. We are not supposed to rely
    on luck and need to make sure that LT transitioned through the inactive
    state though before we initiate link training by hand via RL (Retrain Link)
    bit.
    
    Fixes: 1abb47390350 ("Merge branch 'pci/enumeration'")
    Link: https://lore.kernel.org/r/20240423130820.43824-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>

 
perf annotate: Fix annotation_calc_lines() to pass correct address to get_srcline() [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Thu Apr 4 10:57:08 2024 -0700

    perf annotate: Fix annotation_calc_lines() to pass correct address to get_srcline()
    
    [ Upstream commit aaf494cf483a1a835c44e942861429b30a00cab0 ]
    
    It should pass a proper address (i.e. suitable for objdump or addr2line)
    to get_srcline() in order to work correctly.  It used to pass an address
    with map__rip_2objdump() as the second argument but later it's changed
    to use notes->start.  It's ok in normal cases but it can be changed when
    annotate_opts.full_addr is set.  So let's convert the address directly
    instead of using the notes->start.
    
    Also the last argument is an IP to print symbol offset if requested.  So
    it should pass symbol-relative address.
    
    Fixes: 7d18a824b5e57ddd ("perf annotate: Toggle full address <-> offset display")
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20240404175716.1225482-2-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf annotate: Get rid of duplicate --group option item [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Fri Mar 22 15:43:12 2024 -0700

    perf annotate: Get rid of duplicate --group option item
    
    [ Upstream commit 374af9f1f06b5e991c810d2e4983d6f58df32136 ]
    
    The options array in cmd_annotate() has duplicate --group options.  It
    only needs one and let's get rid of the other.
    
      $ perf annotate -h 2>&1 | grep group
            --group           Show event group information together
            --group           Show event group information together
    
    Fixes: 7ebaf4890f63eb90 ("perf annotate: Support '--group' option")
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jin Yao <yao.jin@linux.intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20240322224313.423181-1-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf annotate: Introduce global annotation_options [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Tue Nov 28 09:54:34 2023 -0800

    perf annotate: Introduce global annotation_options
    
    [ Upstream commit 9d03194a36345796d4f0f8d6b72eb770a45d614e ]
    
    The annotation options are to control the behavior of objdump and the
    output.  It's basically used by 'perf annotate' but 'perf report' and
    'perf top' can call it on TUI dynamically.
    
    But it doesn't need to have a copy of annotation options in many places.
    
    As most of the work is done in the util/annotate.c file, add a global
    variable and set/use it instead of having their own copies.
    
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20231128175441.721579-2-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: aaf494cf483a ("perf annotate: Fix annotation_calc_lines() to pass correct address to get_srcline()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf annotate: Split branch stack cycles information out of 'struct annotation_line' [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Fri Nov 3 12:19:03 2023 -0700

    perf annotate: Split branch stack cycles information out of 'struct annotation_line'
    
    [ Upstream commit de2c7eb59c342d1a61124caaf2993e325a9becb7 ]
    
    The cycles info is used only when branch stack is provided.  Separate
    them from 'struct annotation_line' into a separate struct and lazy
    allocate them to save some memory.
    
    Committer notes:
    
    Make annotation__compute_ipc() check if the lazy allocation works,
    bailing out if so, its callers already do error checking and
    propagation.
    
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20231103191907.54531-2-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: aaf494cf483a ("perf annotate: Fix annotation_calc_lines() to pass correct address to get_srcline()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf annotate: Use global annotation_options [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Tue Nov 28 09:54:37 2023 -0800

    perf annotate: Use global annotation_options
    
    [ Upstream commit 41fd3cacd29f47f6b9c6474b27c5b0513786c4e9 ]
    
    Now it can directly use the global options and no need to pass it as an
    argument.
    
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20231128175441.721579-5-namhyung@kernel.org
    [ Fixup build with GTK2=1 ]
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: aaf494cf483a ("perf annotate: Fix annotation_calc_lines() to pass correct address to get_srcline()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf bench internals inject-build-id: Fix trap divide when collecting just one DSO [+ + +]
Author: He Zhe <zhe.he@windriver.com>
Date:   Tue May 7 14:50:26 2024 +0800

    perf bench internals inject-build-id: Fix trap divide when collecting just one DSO
    
    [ Upstream commit d9180e23fbfa3875424d3a6b28b71b072862a52a ]
    
    'perf bench internals inject-build-id' suffers from the following error when
    only one DSO is collected.
    
      # perf bench internals inject-build-id -v
        Collected 1 DSOs
      traps: internals-injec[2305] trap divide error
      ip:557566ba6394 sp:7ffd4de97fe0 error:0 in perf[557566b2a000+23d000]
        Build-id injection benchmark
        Iteration #1
      Floating point exception
    
    This patch removes the unnecessary minus one from the divisor which also
    corrects the randomization range.
    
    Signed-off-by: He Zhe <zhe.he@windriver.com>
    Fixes: 0bf02a0d80427f26 ("perf bench: Add build-id injection benchmark")
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20240507065026.2652929-1-zhe.he@windriver.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf bench uprobe: Remove lib64 from libc.so.6 binary path [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Fri Apr 5 21:09:10 2024 -0700

    perf bench uprobe: Remove lib64 from libc.so.6 binary path
    
    [ Upstream commit 459fee7b508231cd4622b3bd94aaa85e8e16b888 ]
    
    bpf_program__attach_uprobe_opts will search LD_LIBRARY_PATH and so
    specifying `/lib64` is unnecessary and causes failures for libc.so.6
    paths like `/lib/x86_64-linux-gnu/libc.so.6`.
    
    Fixes: 7b47623b8cae8149 ("perf bench uprobe trace_printk: Add entry attaching an BPF program that does a trace_printk")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Acked-by: Jiri Olsa <jolsa@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andrei Vagin <avagin@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Kees Kook <keescook@chromium.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/20240406040911.1603801-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf daemon: Fix file leak in daemon_session__control [+ + +]
Author: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Date:   Thu May 9 17:34:24 2024 -0700

    perf daemon: Fix file leak in daemon_session__control
    
    [ Upstream commit 09541603462c399c7408d50295db99b4b8042eaa ]
    
    The open() function returns -1 on error.
    
    The 'control' and 'ack' file descriptors are both initialized with
    open() and further validated with 'if' statement.
    
    'if (!control)' would evaluate to 'true' if returned value on error were
    '0' but it is actually '-1'.
    
    Fixes: edcaa47958c7438b ("perf daemon: Add 'ping' command")
    Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    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/20240510003424.2016914-1-samasth.norway.ananda@oracle.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf docs: Document bpf event modifier [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue Apr 16 10:00:13 2024 -0700

    perf docs: Document bpf event modifier
    
    [ Upstream commit eb4d27cf9aef3e6c9bcaf8fa1a1cadc2433d847b ]
    
    Document that 'b' is used as a modifier to make an event use a BPF
    counter.
    
    Fixes: 01bd8efcec444468 ("perf stat: Introduce ':b' modifier")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Song Liu <song@kernel.org>
    Cc: Thomas Richter <tmricht@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240416170014.985191-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf evlist: Add evlist__findnew_tracking_event() helper [+ + +]
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Mon Sep 4 02:33:36 2023 +0000

    perf evlist: Add evlist__findnew_tracking_event() helper
    
    [ Upstream commit 9c95e4ef065723496442898614d09a9a916eab81 ]
    
    Currently, intel-bts, intel-pt, and arm-spe may add tracking event to the
    evlist. We may need to search for the tracking event for some settings.
    
    Therefore, add evlist__findnew_tracking_event() helper.
    
    If system_wide is true, evlist__findnew_tracking_event() set the cpu map
    of the evsel to all online CPUs.
    
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Richter <tmricht@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230904023340.12707-3-yangjihong1@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 792bc998baf9 ("perf record: Fix debug message placement for test consumption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf evlist: Add perf_evlist__go_system_wide() helper [+ + +]
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Mon Sep 4 02:33:35 2023 +0000

    perf evlist: Add perf_evlist__go_system_wide() helper
    
    commit f6ff1c760431be34e4daaa44f242be911becd998 upstream.
    
    For dummy events that keep tracking, we may need to modify its cpu_maps.
    
    For example, change the cpu_maps to record sideband events for all CPUS.
    
    Add perf_evlist__go_system_wide() helper to support this scenario.
    
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Richter <tmricht@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230904023340.12707-2-yangjihong1@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf intel-pt: Fix unassigned instruction op (discovered by MemorySanitizer) [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Mar 26 10:32:23 2024 +0200

    perf intel-pt: Fix unassigned instruction op (discovered by MemorySanitizer)
    
    [ Upstream commit e101a05f79fd4ee3e89d2f3fb716493c33a33708 ]
    
    MemorySanitizer discovered instances where the instruction op value was
    not assigned.:
    
      WARNING: MemorySanitizer: use-of-uninitialized-value
        #0 0x5581c00a76b3 in intel_pt_sample_flags tools/perf/util/intel-pt.c:1527:17
      Uninitialized value was stored to memory at
        #0 0x5581c005ddf8 in intel_pt_walk_insn tools/perf/util/intel-pt-decoder/intel-pt-decoder.c:1256:25
    
    The op value is used to set branch flags for branch instructions
    encountered when walking the code, so fix by setting op to
    INTEL_PT_OP_OTHER in other cases.
    
    Fixes: 4c761d805bb2d2ea ("perf intel-pt: Fix intel_pt_fup_event() assumptions about setting state type")
    Reported-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Tested-by: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Closes: https://lore.kernel.org/linux-perf-users/20240320162619.1272015-1-irogers@google.com/
    Link: https://lore.kernel.org/r/20240326083223.10883-1-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf machine thread: Remove exited threads by default [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu Nov 2 10:56:47 2023 -0700

    perf machine thread: Remove exited threads by default
    
    [ Upstream commit 9ffa6c7512ca7aaeb30e596e2c247cb1fae7123a ]
    
    'struct thread' values hold onto references to mmaps, DSOs, etc. When a
    thread exits it is necessary to clean all of this memory up by removing
    the thread from the machine's threads. Some tools require this doesn't
    happen, such as auxtrace events, 'perf report' if offcpu events exist or
    if a task list is being generated, so add a 'struct symbol_conf' member
    to make the behavior optional. When an exited thread is left in the
    machine's threads, mark it as exited.
    
    This change relates to commit 40826c45eb0b8856 ("perf thread: Remove
    notion of dead threads") . Dead threads were removed as they had a
    reference count of 0 and were difficult to reason about with the
    reference count checker. Here a thread is removed from threads when it
    exits, unless via symbol_conf the exited thread isn't remove and is
    marked as exited. Reference counting behaves as it normally does.
    
    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Athira Jajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Changbin Du <changbin.du@huawei.com>
    Cc: Colin Ian King <colin.i.king@gmail.com>
    Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
    Cc: German Gomez <german.gomez@arm.com>
    Cc: Huacai Chen <chenhuacai@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Li Dong <lidong@vivo.com>
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Miguel Ojeda <ojeda@kernel.org>
    Cc: Ming Wang <wangming01@loongson.cn>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Nick Terrell <terrelln@fb.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Sandipan Das <sandipan.das@amd.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Steinar H. Gunderson <sesse@google.com>
    Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Cc: Wenyu Liu <liuwenyu7@huawei.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Link: https://lore.kernel.org/r/20231102175735.2272696-6-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: aaf494cf483a ("perf annotate: Fix annotation_calc_lines() to pass correct address to get_srcline()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf maps: Move symbol maps functions to maps.c [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Mon Nov 27 14:08:25 2023 -0800

    perf maps: Move symbol maps functions to maps.c
    
    [ Upstream commit 0f6ab6a3fb7e380a1277f8288f315724ed517114 ]
    
    Move the find and certain other symbol maps__* functions to maps.c for
    better abstraction.
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Athira Jajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Changbin Du <changbin.du@huawei.com>
    Cc: Colin Ian King <colin.i.king@gmail.com>
    Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
    Cc: German Gomez <german.gomez@arm.com>
    Cc: Guilherme Amadio <amadio@gentoo.org>
    Cc: Huacai Chen <chenhuacai@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Li Dong <lidong@vivo.com>
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Cc: Miguel Ojeda <ojeda@kernel.org>
    Cc: Ming Wang <wangming01@loongson.cn>
    Cc: Nick Terrell <terrelln@fb.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Sandipan Das <sandipan.das@amd.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Steinar H. Gunderson <sesse@google.com>
    Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Cc: Wenyu Liu <liuwenyu7@huawei.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Link: https://lore.kernel.org/r/20231127220902.1315692-14-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 25626e19ae6d ("perf symbols: Fix ownership of string in dso__load_vmlinux()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf pmu: "Compat" supports regular expression matching identifiers [+ + +]
Author: Jing Zhang <renyu.zj@linux.alibaba.com>
Date:   Wed Sep 27 13:59:45 2023 +0800

    perf pmu: "Compat" supports regular expression matching identifiers
    
    [ Upstream commit 2879ff36f5ed80deec5f9d82a7a4107f2347630e ]
    
    The jevent "Compat" is used for uncore PMU alias or metric definitions.
    
    The same PMU driver has different PMU identifiers due to different
    hardware versions and types, but they may have some common PMU event.
    Since a Compat value can only match one identifier, when adding the
    same event alias to PMUs with different identifiers, each identifier
    needs to be defined once, which is not streamlined enough.
    
    So let "Compat" support using regular expression to match identifiers
    for uncore PMU alias. For example, if the "Compat" value is set to
    "43401|43c01", it would be able to match PMU identifiers such as "43401"
    or "43c01", which correspond to CMN600_r0p0 or CMN700_r0p0.
    
    Signed-off-by: Jing Zhang <renyu.zj@linux.alibaba.com>
    Reviewed-by: Ian Rogers <irogers@google.com>
    Tested-by: Ian Rogers <irogers@google.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Shuai Xue <xueshuai@linux.alibaba.com>
    Cc: Zhuo Song <zhuo.song@linux.alibaba.com>
    Cc: John Garry <john.g.garry@oracle.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-doc@vger.kernel.org
    Link: https://lore.kernel.org/r/1695794391-34817-2-git-send-email-renyu.zj@linux.alibaba.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Stable-dep-of: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf pmu: Assume sysfs events are always the same case [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu May 2 14:35:07 2024 -0700

    perf pmu: Assume sysfs events are always the same case
    
    [ Upstream commit 7b6dd7a923281a7ccb980a0f768d6926721eb3cc ]
    
    Perf event names aren't case sensitive. For sysfs events the entire
    directory of events is read then iterated comparing names in a case
    insensitive way, most often to see if an event is present.
    
    Consider:
    
      $ perf stat -e inst_retired.any true
    
    The event inst_retired.any may be present in any PMU, so every PMU's
    sysfs events are loaded and then searched with strcasecmp to see if
    any match. This event is only present on the cpu PMU as a JSON event
    so a lot of events were loaded from sysfs unnecessarily just to prove
    an event didn't exist there.
    
    This change avoids loading all the events by assuming sysfs event
    names are always either lower or uppercase. It uses file exists and
    only loads the events when the desired event is present.
    
    For the example above, the number of openat calls measured by 'perf
    trace' on a tigerlake laptop goes from 325 down to 255. The reduction
    will be larger for machines with many PMUs, particularly replicated
    uncore PMUs.
    
    Ensure pmu_aliases_parse() is called before all uses of the aliases
    list, but remove some "pmu->sysfs_aliases_loaded" tests as they are now
    part of the function.
    
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jing Zhang <renyu.zj@linux.alibaba.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Thomas Richter <tmricht@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240502213507.2339733-7-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf pmu: Count sys and cpuid JSON events separately [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Fri May 10 17:36:01 2024 -0700

    perf pmu: Count sys and cpuid JSON events separately
    
    [ Upstream commit d9c5f5f94c2d356fdf3503f7fcaf254512bc032d ]
    
    Sys events are eagerly loaded as each event has a compat option that may
    mean the event is or isn't associated with the PMU.
    
    These shouldn't be counted as loaded_json_events as that is used for
    JSON events matching the CPUID that may or may not have been loaded. The
    mismatch causes issues on ARM64 that uses sys events.
    
    Fixes: e6ff1eed3584362d ("perf pmu: Lazily add JSON events")
    Closes: https://lore.kernel.org/lkml/20240510024729.1075732-1-justin.he@arm.com/
    Reported-by: Jia He <justin.he@arm.com>
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: John Garry <john.g.garry@oracle.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    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/20240511003601.2666907-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf pmu: Move pmu__find_core_pmu() to pmus.c [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Wed Sep 13 16:33:48 2023 +0100

    perf pmu: Move pmu__find_core_pmu() to pmus.c
    
    [ Upstream commit 3d0f5f456a5786573ba6a3358178c8db580e4b85 ]
    
    pmu__find_core_pmu() more logically belongs in pmus.c because it
    iterates over all PMUs, so move it to pmus.c
    
    At the same time rename it to perf_pmus__find_core_pmu() to match the
    naming convention in this file.
    
    list_prepare_entry() can't be used in perf_pmus__scan_core() anymore now
    that it's called from the same compilation unit. This is with -O2
    (specifically -O1 -ftree-vrp -finline-functions
    -finline-small-functions) which allow the bounds of the array
    access to be determined at compile time. list_prepare_entry() subtracts
    the offset of the 'list' member in struct perf_pmu from &core_pmus,
    which isn't a struct perf_pmu. The compiler sees that pmu results in
    &core_pmus - 8 and refuses to compile. At runtime this works because
    list_for_each_entry_continue() always adds the offset back again before
    dereferencing ->next, but it's technically undefined behavior. With
    -fsanitize=undefined an additional warning is generated.
    
    Using list_first_entry_or_null() to get the first entry here avoids
    doing &core_pmus - 8 but has the same result and fixes both the compile
    warning and the undefined behavior warning. There are other uses of
    list_prepare_entry() in pmus.c, but the compiler doesn't seem to be
    able to see that they can also be called with &core_pmus, so I won't
    change any at this time.
    
    Signed-off-by: James Clark <james.clark@arm.com>
    Reviewed-by: Ian Rogers <irogers@google.com>
    Reviewed-by: John Garry <john.g.garry@oracle.com>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Eduard Zingerman <eddyz87@gmail.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Jing Zhang <renyu.zj@linux.alibaba.com>
    Cc: Haixin Yu <yuhaixin.yhx@linux.alibaba.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Link: https://lore.kernel.org/r/20230913153355.138331-2-james.clark@arm.com
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Stable-dep-of: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf probe: Add missing libgen.h header needed for using basename() [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Mar 21 11:13:30 2024 -0300

    perf probe: Add missing libgen.h header needed for using basename()
    
    [ Upstream commit 581037151910126a7934e369e4b6ac70eda9a703 ]
    
    This prototype is obtained indirectly, by luck, from some other header
    in probe-event.c in most systems, but recently exploded on alpine:edge:
    
       8    13.39 alpine:edge                   : FAIL gcc version 13.2.1 20240309 (Alpine 13.2.1_git20240309)
        util/probe-event.c: In function 'convert_exec_to_group':
        util/probe-event.c:225:16: error: implicit declaration of function 'basename' [-Werror=implicit-function-declaration]
          225 |         ptr1 = basename(exec_copy);
              |                ^~~~~~~~
        util/probe-event.c:225:14: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
          225 |         ptr1 = basename(exec_copy);
              |              ^
        cc1: all warnings being treated as errors
        make[3]: *** [/git/perf-6.8.0/tools/build/Makefile.build:158: util] Error 2
    
    Fix it by adding the libgen.h header where basename() is prototyped.
    
    Fixes: fb7345bbf7fad9bf ("perf probe: Support basic dwarf-based operations on uprobe events")
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/lkml/
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf record: Delete session after stopping sideband thread [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu Feb 29 23:46:36 2024 -0800

    perf record: Delete session after stopping sideband thread
    
    [ Upstream commit 88ce0106a1f603bf360cb397e8fe293f8298fabb ]
    
    The session has a header in it which contains a perf env with
    bpf_progs. The bpf_progs are accessed by the sideband thread and so
    the sideband thread must be stopped before the session is deleted, to
    avoid a use after free.  This error was detected by AddressSanitizer
    in the following:
    
      ==2054673==ERROR: AddressSanitizer: heap-use-after-free on address 0x61d000161e00 at pc 0x55769289de54 bp 0x7f9df36d4ab0 sp 0x7f9df36d4aa8
      READ of size 8 at 0x61d000161e00 thread T1
          #0 0x55769289de53 in __perf_env__insert_bpf_prog_info util/env.c:42
          #1 0x55769289dbb1 in perf_env__insert_bpf_prog_info util/env.c:29
          #2 0x557692bbae29 in perf_env__add_bpf_info util/bpf-event.c:483
          #3 0x557692bbb01a in bpf_event__sb_cb util/bpf-event.c:512
          #4 0x5576928b75f4 in perf_evlist__poll_thread util/sideband_evlist.c:68
          #5 0x7f9df96a63eb in start_thread nptl/pthread_create.c:444
          #6 0x7f9df9726a4b in clone3 ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    
      0x61d000161e00 is located 384 bytes inside of 2136-byte region [0x61d000161c80,0x61d0001624d8)
      freed by thread T0 here:
          #0 0x7f9dfa6d7288 in __interceptor_free libsanitizer/asan/asan_malloc_linux.cpp:52
          #1 0x557692978d50 in perf_session__delete util/session.c:319
          #2 0x557692673959 in __cmd_record tools/perf/builtin-record.c:2884
          #3 0x55769267a9f0 in cmd_record tools/perf/builtin-record.c:4259
          #4 0x55769286710c in run_builtin tools/perf/perf.c:349
          #5 0x557692867678 in handle_internal_command tools/perf/perf.c:402
          #6 0x557692867a40 in run_argv tools/perf/perf.c:446
          #7 0x557692867fae in main tools/perf/perf.c:562
          #8 0x7f9df96456c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    
    Fixes: 657ee5531903339b ("perf evlist: Introduce side band thread")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Disha Goel <disgoel@linux.ibm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Yicong Yang <yangyicong@hisilicon.com>
    Link: https://lore.kernel.org/r/20240301074639.2260708-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf record: Fix debug message placement for test consumption [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Thu Apr 11 10:54:47 2024 +0300

    perf record: Fix debug message placement for test consumption
    
    [ Upstream commit 792bc998baf9ae17297b1f93b1edc3ca34a0b7e2 ]
    
    evlist__config() might mess up the debug output consumed by test
    "Test per-thread recording" in "Miscellaneous Intel PT testing".
    
    Move it out from between the debug prints:
    
      "perf record opening and mmapping events" and
      "perf record done opening and mmapping events"
    
    Fixes: da4062021e0e6da5 ("perf tools: Add debug messages and comments for testing")
    Closes: https://lore.kernel.org/linux-perf-users/ZhVfc5jYLarnGzKa@x1/
    Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20240411075447.17306-1-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf record: Lazy load kernel symbols [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu Nov 2 10:56:44 2023 -0700

    perf record: Lazy load kernel symbols
    
    [ Upstream commit 1a27fc01700fbff2f205000edf0d1d315b5f85cc ]
    
    Commit 5b7ba82a75915e73 ("perf symbols: Load kernel maps before using")
    changed it so that loading a kernel DSO would cause the symbols for the
    DSO to be eagerly loaded.
    
    For 'perf record' this is overhead as the symbols won't be used. Add a
    field to 'struct symbol_conf' to control the behavior and disable it for
    'perf record' and 'perf inject'.
    
    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Ian Rogers <irogers@google.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Athira Jajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Changbin Du <changbin.du@huawei.com>
    Cc: Colin Ian King <colin.i.king@gmail.com>
    Cc: Dmitrii Dolgov <9erthalion6@gmail.com>
    Cc: German Gomez <german.gomez@arm.com>
    Cc: Huacai Chen <chenhuacai@kernel.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Li Dong <lidong@vivo.com>
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Miguel Ojeda <ojeda@kernel.org>
    Cc: Ming Wang <wangming01@loongson.cn>
    Cc: Nick Terrell <terrelln@fb.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Sandipan Das <sandipan.das@amd.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Steinar H. Gunderson <sesse@google.com>
    Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Cc: Wenyu Liu <liuwenyu7@huawei.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Link: https://lore.kernel.org/r/20231102175735.2272696-3-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: aaf494cf483a ("perf annotate: Fix annotation_calc_lines() to pass correct address to get_srcline()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf record: Move setting tracking events before record__init_thread_masks() [+ + +]
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Mon Sep 4 02:33:37 2023 +0000

    perf record: Move setting tracking events before record__init_thread_masks()
    
    [ Upstream commit 1285ab300d598ead593b190af65a16f4b0843c68 ]
    
    User space tasks can migrate between CPUs, so when tracing selected CPUs,
    sideband for all CPUs is needed. In this case set the cpu map of the evsel
    to all online CPUs. This may modify the original cpu map of the evlist.
    
    Therefore, need to check whether the preceding scenario exists before
    record__init_thread_masks().
    
    Dummy tracking has been set in record__open(), move it before
    record__init_thread_masks() and add a helper for unified processing.
    
    The sys_perf_event_open invoked is as follows:
    
      # perf --debug verbose=3 record -e cpu-clock -D 100 true
      <SNIP>
      Opening: cpu-clock
      ------------------------------------------------------------
      perf_event_attr:
        type                             1 (PERF_TYPE_SOFTWARE)
        size                             136
        config                           0 (PERF_COUNT_SW_CPU_CLOCK)
        { sample_period, sample_freq }   4000
        sample_type                      IP|TID|TIME|PERIOD|IDENTIFIER
        read_format                      ID|LOST
        disabled                         1
        inherit                          1
        freq                             1
        sample_id_all                    1
        exclude_guest                    1
      ------------------------------------------------------------
      sys_perf_event_open: pid 10318  cpu 0  group_fd -1  flags 0x8 = 5
      sys_perf_event_open: pid 10318  cpu 1  group_fd -1  flags 0x8 = 6
      sys_perf_event_open: pid 10318  cpu 2  group_fd -1  flags 0x8 = 7
      sys_perf_event_open: pid 10318  cpu 3  group_fd -1  flags 0x8 = 9
      sys_perf_event_open: pid 10318  cpu 4  group_fd -1  flags 0x8 = 10
      sys_perf_event_open: pid 10318  cpu 5  group_fd -1  flags 0x8 = 11
      sys_perf_event_open: pid 10318  cpu 6  group_fd -1  flags 0x8 = 12
      sys_perf_event_open: pid 10318  cpu 7  group_fd -1  flags 0x8 = 13
      Opening: dummy:u
      ------------------------------------------------------------
      perf_event_attr:
        type                             1 (PERF_TYPE_SOFTWARE)
        size                             136
        config                           0x9 (PERF_COUNT_SW_DUMMY)
        { sample_period, sample_freq }   1
        sample_type                      IP|TID|TIME|IDENTIFIER
        read_format                      ID|LOST
        disabled                         1
        inherit                          1
        exclude_kernel                   1
        exclude_hv                       1
        mmap                             1
        comm                             1
        enable_on_exec                   1
        task                             1
        sample_id_all                    1
        exclude_guest                    1
        mmap2                            1
        comm_exec                        1
        ksymbol                          1
        bpf_event                        1
      ------------------------------------------------------------
      sys_perf_event_open: pid 10318  cpu 0  group_fd -1  flags 0x8 = 14
      sys_perf_event_open: pid 10318  cpu 1  group_fd -1  flags 0x8 = 15
      sys_perf_event_open: pid 10318  cpu 2  group_fd -1  flags 0x8 = 16
      sys_perf_event_open: pid 10318  cpu 3  group_fd -1  flags 0x8 = 17
      sys_perf_event_open: pid 10318  cpu 4  group_fd -1  flags 0x8 = 18
      sys_perf_event_open: pid 10318  cpu 5  group_fd -1  flags 0x8 = 19
      sys_perf_event_open: pid 10318  cpu 6  group_fd -1  flags 0x8 = 20
      sys_perf_event_open: pid 10318  cpu 7  group_fd -1  flags 0x8 = 21
      <SNIP>
    
    'perf test' needs to update base-record & system-wide-dummy attr expected values
    for test-record-C0:
    
    1. Because a dummy sideband event is added to the sampling of specified
       CPUs. When evlist contains evsel of different sample_type,
       evlist__config() will change the default PERF_SAMPLE_ID bit to
       PERF_SAMPLE_IDENTIFICATION bit.
       The attr sample_type expected value of base-record and system-wide-dummy
       in test-record-C0 needs to be updated.
    
    2. The perf record uses evlist__add_aux_dummy() instead of
       evlist__add_dummy() to add a dummy event.
       The expected value of system-wide-dummy attr needs to be updated.
    
    The 'perf test' result is as follows:
    
      # ./perf test list  2>&1 | grep 'Setup struct perf_event_attr'
       17: Setup struct perf_event_attr
      # ./perf test 17
       17: Setup struct perf_event_attr                                    : Ok
    
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Richter <tmricht@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230904023340.12707-4-yangjihong1@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 792bc998baf9 ("perf record: Fix debug message placement for test consumption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf report: Avoid SEGV in report__setup_sample_type() [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue May 7 20:53:00 2024 -0700

    perf report: Avoid SEGV in report__setup_sample_type()
    
    [ Upstream commit 45b4f402a6b782352c4bafcff682bfb01da9ca05 ]
    
    In some cases evsel->name is lazily initialized in evsel__name(). If not
    initialized passing NULL to strstr() leads to a SEGV.
    
    Fixes: ccb17caecfbd542f ("perf report: Set PERF_SAMPLE_DATA_SRC bit for Arm SPE event")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linux.dev>
    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/20240508035301.1554434-4-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf report: Convert to the global annotation_options [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Tue Nov 28 09:54:35 2023 -0800

    perf report: Convert to the global annotation_options
    
    [ Upstream commit 14953f038d6b30e3dc9d1aa4d4584ac505e5a8ec ]
    
    Use the global option and drop the local copy.
    
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20231128175441.721579-3-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: aaf494cf483a ("perf annotate: Fix annotation_calc_lines() to pass correct address to get_srcline()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf sched timehist: Fix -g/--call-graph option failure [+ + +]
Author: Yang Jihong <yangjihong@bytedance.com>
Date:   Mon Apr 1 14:27:23 2024 +0800

    perf sched timehist: Fix -g/--call-graph option failure
    
    commit 6e4b398770d5023eb6383da9360a23bd537c155b upstream.
    
    When 'perf sched' enables the call-graph recording, sample_type of dummy
    event does not have PERF_SAMPLE_CALLCHAIN, timehist_check_attr() checks
    that the evsel does not have a callchain, and set show_callchain to 0.
    
    Currently 'perf sched timehist' only saves callchain when processing the
    'sched:sched_switch event', timehist_check_attr() only needs to determine
    whether the event has PERF_SAMPLE_CALLCHAIN.
    
    Before:
    
      # perf sched record -g true
      [ perf record: Woken up 0 times to write data ]
      [ perf record: Captured and wrote 4.153 MB perf.data (7536 samples) ]
      # perf sched timehist
      Samples do not have callchains.
                 time    cpu  task name                       wait time  sch delay   run time
                              [tid/pid]                          (msec)     (msec)     (msec)
      --------------- ------  ------------------------------  ---------  ---------  ---------
        147851.826019 [0000]  perf[285035]                        0.000      0.000      0.000
        147851.826029 [0000]  migration/0[15]                     0.000      0.003      0.009
        147851.826063 [0001]  perf[285035]                        0.000      0.000      0.000
        147851.826069 [0001]  migration/1[21]                     0.000      0.003      0.006
      <SNIP>
    
    After:
    
      # perf sched record -g true
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 2.572 MB perf.data (822 samples) ]
      # perf sched timehist
             time cpu task name        waittime  sch delay  runtime
                        [tid/pid]        (msec)  (msec)    (msec)
      ----------- --- ---------------  --------  --------  -----
      4193.035164 [0] perf[277062]        0.000     0.000   0.000 __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- preempt_schedule_common <- __cond_resched <- __wait_for_common <- wait_for_completion
      4193.035174 [0] migration/0[15]     0.000     0.003   0.009 __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- smpboot_thread_fn <- kthread <- ret_from_fork
      4193.035207 [1] perf[277062]        0.000     0.000   0.000 __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- preempt_schedule_common <- __cond_resched <- __wait_for_common <- wait_for_completion
      4193.035214 [1] migration/1[21]     0.000     0.003   0.007 __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- smpboot_thread_fn <- kthread <- ret_from_fork
      <SNIP>
    
    Fixes: 9c95e4ef06572349 ("perf evlist: Add evlist__findnew_tracking_event() helper")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Yang Jihong <yangjihong@bytedance.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Link: https://lore.kernel.org/r/20240401062724.1006010-2-yangjihong@bytedance.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf stat: Do not fail on metrics on s390 z/VM systems [+ + +]
Author: Thomas Richter <tmricht@linux.ibm.com>
Date:   Thu Apr 4 08:48:06 2024 +0200

    perf stat: Do not fail on metrics on s390 z/VM systems
    
    [ Upstream commit c2f3d7dfc7373d53286f2a5c882d3397a5070adc ]
    
    On s390 z/VM virtual machines command 'perf list' also displays metrics:
    
      # perf list | grep -A 20 'Metric Groups:'
      Metric Groups:
    
      No_group:
       cpi
            [Cycles per Instruction]
       est_cpi
            [Estimated Instruction Complexity CPI infinite Level 1]
       finite_cpi
            [Cycles per Instructions from Finite cache/memory]
       l1mp
            [Level One Miss per 100 Instructions]
       l2p
            [Percentage sourced from Level 2 cache]
       l3p
            [Percentage sourced from Level 3 on same chip cache]
       l4lp
            [Percentage sourced from Level 4 Local cache on same book]
       l4rp
            [Percentage sourced from Level 4 Remote cache on different book]
       memp
            [Percentage sourced from memory]
       ....
      #
    
    The command
    
      # perf stat -M cpi -- true
      event syntax error: '{CPU_CYCLES/metric-id=CPU_CYCLES/.....'
                            \___ Bad event or PMU
    
      Unable to find PMU or event on a PMU of 'CPU_CYCLES'
    
       event syntax error: '{CPU_CYCLES/metric-id=CPU_CYCLES/...'
                            \___ Cannot find PMU `CPU_CYCLES'.
                                 Missing kernel support?
     #
    
    fails. 'perf stat' should not fail on metrics when the referenced CPU
    Counter Measurement PMU is not available.
    
    Output after:
    
      # perf stat -M est_cpi -- sleep 1
    
      Performance counter stats for 'sleep 1':
    
         1,000,887,494 ns   duration_time   #     0.00 est_cpi
    
           1.000887494 seconds time elapsed
    
           0.000143000 seconds user
           0.000662000 seconds sys
    
     #
    
    Fixes: 7f76b31130680fb3 ("perf list: Add IBM z16 event description for s390")
    Suggested-by: Ian Rogers <irogers@google.com>
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
    Cc: Heiko Carstens <hca@linux.ibm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Sumanth Korikkar <sumanthk@linux.ibm.com>
    Cc: Sven Schnelle <svens@linux.ibm.com>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240404064806.1362876-2-tmricht@linux.ibm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf stat: Don't display metric header for non-leader uncore events [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu May 9 22:13:09 2024 -0700

    perf stat: Don't display metric header for non-leader uncore events
    
    [ Upstream commit 193a9e30207f54777ff42d0d8be8389edc522277 ]
    
    On an Intel tigerlake laptop a metric like:
    
        {
            "BriefDescription": "Test",
            "MetricExpr": "imc_free_running@data_read@ + imc_free_running@data_write@",
            "MetricGroup": "Test",
            "MetricName": "Test",
            "ScaleUnit": "6.103515625e-5MiB"
        },
    
    Will have 4 events:
    
      uncore_imc_free_running_0/data_read/
      uncore_imc_free_running_0/data_write/
      uncore_imc_free_running_1/data_read/
      uncore_imc_free_running_1/data_write/
    
    If aggregration is disabled with metric-only 2 column headers are
    needed:
    
      $ perf stat -M test --metric-only -A -a sleep 1
    
       Performance counter stats for 'system wide':
    
                        MiB  Test            MiB  Test
      CPU0                 1821.0               1820.5
    
    But when not, the counts aggregated in the metric leader and only 1
    column should be shown:
    
      $ perf stat -M test --metric-only -a sleep 1
       Performance counter stats for 'system wide':
    
                  MiB  Test
                    5909.4
    
             1.001258915 seconds time elapsed
    
    Achieve this by skipping events that aren't metric leaders when
    printing column headers and aggregation isn't disabled.
    
    The bug is long standing, the fixes tag is set to a refactor as that
    is as far back as is reasonable to backport.
    
    Fixes: 088519f318be3a41 ("perf stat: Move the display functions to stat-display.c")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kaige Ye <ye@kaige.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Yicong Yang <yangyicong@hisilicon.com>
    Link: https://lore.kernel.org/r/20240510051309.2452468-1-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf symbols: Fix ownership of string in dso__load_vmlinux() [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Tue May 7 15:12:08 2024 +0100

    perf symbols: Fix ownership of string in dso__load_vmlinux()
    
    [ Upstream commit 25626e19ae6df34f336f235b6b3dbd1b566d2738 ]
    
    The linked commit updated dso__load_vmlinux() to call
    dso__set_long_name() before loading the symbols. Loading the symbols may
    not succeed but dso__set_long_name() takes ownership of the string. The
    two callers of this function free the string themselves on failure
    cases, resulting in the following error:
    
      $ perf record -- ls
      $ perf report
    
      free(): double free detected in tcache 2
    
    Fix it by always taking ownership of the string, even on failure. This
    means the string is either freed at the very first early exit condition,
    or later when the dso is deleted or the long name is replaced. Now no
    special return value is needed to signify that the caller needs to
    free the string.
    
    Fixes: e59fea47f83e8a9a ("perf symbols: Fix DSO kernel load and symbol process to correctly map DSO to its long_name, type and adjust_symbols")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: James Clark <james.clark@arm.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    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/20240507141210.195939-5-james.clark@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf test shell arm_coresight: Increase buffer size for Coresight basic tests [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Tue Mar 26 11:37:49 2024 +0000

    perf test shell arm_coresight: Increase buffer size for Coresight basic tests
    
    [ Upstream commit 10b6ee3b597b1b1b4dc390aaf9d589664af31df9 ]
    
    These tests record in a mode that includes kernel trace but look for
    samples of a userspace process. This makes them sensitive to any kernel
    compilation options that increase the amount of time spent in the
    kernel. If the trace buffer is completely filled before userspace is
    reached then the test will fail. Double the buffer size to fix this.
    
    The other tests in the same file aren't sensitive to this for various
    reasons, for example the iterate devices test filters by userspace trace
    only. But in order to keep coverage of all the modes, increase the
    buffer size rather than filtering by userspace for the basic tests.
    
    Fixes: d1efa4a0a696e487 ("perf cs-etm: Add separate decode paths for timeless and per-thread modes")
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Signed-off-by: James Clark <james.clark@arm.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20240326113749.257250-1-james.clark@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf test: Add a test for strcmp_cpuid_str() expression [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Mon Sep 4 10:50:46 2023 +0100

    perf test: Add a test for strcmp_cpuid_str() expression
    
    [ Upstream commit a1ebf7718ee31501d2d2ee3af1716e0084c81926 ]
    
    Test that the new expression builtin returns a match when the current
    escaped CPU ID is given, and that it doesn't match when "0x0" is given.
    
    The CPU ID in test__expr() has to be changed to perf_pmu__getcpuid()
    which returns the CPU ID string, rather than the raw CPU ID that
    get_cpuid() returns because that can't be used with strcmp_cpuid_str().
    It doesn't affect the is_intel test because both versions contain
    "Intel".
    
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: James Clark <james.clark@arm.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Chen Zhongjin <chenzhongjin@huawei.com>
    Cc: Eduard Zingerman <eddyz87@gmail.com>
    Cc: Haixin Yu <yuhaixin.yhx@linux.alibaba.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jing Zhang <renyu.zj@linux.alibaba.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: John Garry <john.g.garry@oracle.com>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Link: https://lore.kernel.org/r/20230904095104.1162928-5-james.clark@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf tests: Apply attributes to all events in object code reading test [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Wed Apr 10 11:34:53 2024 +0100

    perf tests: Apply attributes to all events in object code reading test
    
    [ Upstream commit 2dade41a533f337447b945239b87ff31a8857890 ]
    
    PERF_PMU_CAP_EXTENDED_HW_TYPE results in multiple events being opened on
    heterogeneous systems. Currently this test only sets its required
    attributes on the first event. Not disabling enable_on_exec on the other
    events causes the test to fail because the forked objdump processes are
    sampled. No tracking event is opened so Perf only knows about its own
    mappings causing the objdump samples to give the following error:
    
      $ perf test -vvv "object code reading"
    
      Reading object code for memory address: 0xffff9aaa55ec
      thread__find_map failed
      ---- end(-1) ----
      24: Object code reading              : FAILED!
    
    Fixes: 251aa040244a3b17 ("perf parse-events: Wildcard most "numeric" events")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: James Clark <james.clark@arm.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linux.dev>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Spoorthy S <spoorts2@in.ibm.com>
    Link: https://lore.kernel.org/r/20240410103458.813656-3-james.clark@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf tests: Make "test data symbol" more robust on Neoverse N1 [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Wed Apr 10 11:34:52 2024 +0100

    perf tests: Make "test data symbol" more robust on Neoverse N1
    
    [ Upstream commit 256ef072b3842273ce703db18b603b051aca95fe ]
    
    To prevent anyone from seeing a test failure appear as a regression and
    thinking that it was caused by their code change, insert some noise into
    the loop which makes it immune to sampling bias issues (errata 1694299).
    
    The "test data symbol" test can fail with any unrelated change that
    shifts the loop into an unfortunate position in the Perf binary which is
    almost impossible to debug as the root cause of the test failure.
    Ultimately it's caused by the referenced errata.
    
    Fixes: 60abedb8aa902b06 ("perf test: Introduce script for data symbol testing")
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: James Clark <james.clark@arm.com>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linux.dev>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Spoorthy S <spoorts2@in.ibm.com>
    Link: https://lore.kernel.org/r/20240410103458.813656-2-james.clark@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf thread: Fixes to thread__new() related to initializing comm [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue May 7 20:53:01 2024 -0700

    perf thread: Fixes to thread__new() related to initializing comm
    
    [ Upstream commit 3536c2575e88a890cf696b4ccd3da36bc937853b ]
    
    Freeing the thread on failure won't work with reference count checking,
    use thread__delete().
    
    Don't allocate the comm_str, use a stack allocation instead.
    
    Fixes: f6005cafebab72f8 ("perf thread: Add reference count checking")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linux.dev>
    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/20240508035301.1554434-5-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf tools: Add/use PMU reverse lookup from config to name [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu Mar 7 16:19:15 2024 -0800

    perf tools: Add/use PMU reverse lookup from config to name
    
    [ Upstream commit 67ee8e71daabb8632931b7559e5c8a4b69a427f8 ]
    
    Add perf_pmu__name_from_config that does a reverse lookup from a
    config number to an alias name. The lookup is expensive as the config
    is computed for every alias by filling in a perf_event_attr, but this
    is only done when verbose output is enabled. The lookup also only
    considers config, and not config1, config2 or config3.
    
    An example of the output:
    
      $ perf stat -vv -e data_read true
      ...
      perf_event_attr:
        type                             24 (uncore_imc_free_running_0)
        size                             136
        config                           0x20ff (data_read)
        sample_type                      IDENTIFIER
        read_format                      TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
        disabled                         1
        inherit                          1
        exclude_guest                    1
      ...
    
    Committer notes:
    
    Fix the python binding build by adding dummies for not strictly
    needed perf_pmu__name_from_config() and perf_pmus__find_by_type().
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Tested-by: Kan Liang <kan.liang@linux.intel.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.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>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Link: https://lore.kernel.org/r/20240308001915.4060155-7-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf tools: Use pmus to describe type from attribute [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Thu Mar 7 16:19:14 2024 -0800

    perf tools: Use pmus to describe type from attribute
    
    [ Upstream commit 7093882067e2e2f88d3449c35c5f0f3f566c8a26 ]
    
    When dumping a perf_event_attr, use pmus to find the PMU and its name
    by the type number. This allows dynamically added PMUs to be described.
    
    Before:
    
      $ perf stat -vv -e data_read true
      ...
      perf_event_attr:
        type                             24
        size                             136
        config                           0x20ff
        sample_type                      IDENTIFIER
        read_format                      TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
        disabled                         1
        inherit                          1
        exclude_guest                    1
      ...
    
    After:
    
      $ perf stat -vv -e data_read true
      ...
      perf_event_attr:
        type                             24 (uncore_imc_free_running_0)
        size                             136
        config                           0x20ff
        sample_type                      IDENTIFIER
        read_format                      TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
        disabled                         1
        inherit                          1
        exclude_guest                    1
      ...
    
    However, it also means that when we have a PMU name we prefer it to a
    hard coded name:
    
    Before:
    
      $ perf stat -vv -e faults true
      ...
      perf_event_attr:
        type                             1 (PERF_TYPE_SOFTWARE)
        size                             136
        config                           0x2 (PERF_COUNT_SW_PAGE_FAULTS)
        sample_type                      IDENTIFIER
        read_format                      TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
        disabled                         1
        inherit                          1
        enable_on_exec                   1
        exclude_guest                    1
      ...
    
    After:
    
      $ perf stat -vv -e faults true
      ...
      perf_event_attr:
        type                             1 (software)
        size                             136
        config                           0x2 (PERF_COUNT_SW_PAGE_FAULTS)
        sample_type                      IDENTIFIER
        read_format                      TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
        disabled                         1
        inherit                          1
        enable_on_exec                   1
        exclude_guest                    1
      ...
    
    It feels more consistent to do this, rather than only prefer a PMU
    name when a hard coded name isn't available.
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Tested-by: Kan Liang <kan.liang@linux.intel.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.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>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Link: https://lore.kernel.org/r/20240308001915.4060155-6-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf top: Convert to the global annotation_options [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Tue Nov 28 09:54:36 2023 -0800

    perf top: Convert to the global annotation_options
    
    [ Upstream commit c9a21a872c69032cb9a94ebc171649c0c28141d7 ]
    
    Use the global option and drop the local copy.
    
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20231128175441.721579-4-namhyung@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: aaf494cf483a ("perf annotate: Fix annotation_calc_lines() to pass correct address to get_srcline()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf ui browser: Avoid SEGV on title [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue May 7 20:52:58 2024 -0700

    perf ui browser: Avoid SEGV on title
    
    [ Upstream commit 90f01afb0dfafbc9b094bb61e61a4ac297d9d0d2 ]
    
    If the title is NULL then it can lead to a SEGV.
    
    Fixes: 769e6a1e15bdbbaf ("perf ui browser: Don't save pointer to stack memory")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linux.dev>
    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/20240508035301.1554434-2-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf ui browser: Don't save pointer to stack memory [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Tue May 7 11:35:38 2024 -0700

    perf ui browser: Don't save pointer to stack memory
    
    [ Upstream commit 769e6a1e15bdbbaf2b0d2f37c24f2c53268bd21f ]
    
    ui_browser__show() is capturing the input title that is stack allocated
    memory in hist_browser__run().
    
    Avoid a use after return by strdup-ing the string.
    
    Committer notes:
    
    Further explanation from Ian Rogers:
    
    My command line using tui is:
    $ sudo bash -c 'rm /tmp/asan.log*; export
    ASAN_OPTIONS="log_path=/tmp/asan.log"; /tmp/perf/perf mem record -a
    sleep 1; /tmp/perf/perf mem report'
    I then go to the perf annotate view and quit. This triggers the asan
    error (from the log file):
    ```
    ==1254591==ERROR: AddressSanitizer: stack-use-after-return on address
    0x7f2813331920 at pc 0x7f28180
    65991 bp 0x7fff0a21c750 sp 0x7fff0a21bf10
    READ of size 80 at 0x7f2813331920 thread T0
        #0 0x7f2818065990 in __interceptor_strlen
    ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:461
        #1 0x7f2817698251 in SLsmg_write_wrapped_string
    (/lib/x86_64-linux-gnu/libslang.so.2+0x98251)
        #2 0x7f28176984b9 in SLsmg_write_nstring
    (/lib/x86_64-linux-gnu/libslang.so.2+0x984b9)
        #3 0x55c94045b365 in ui_browser__write_nstring ui/browser.c:60
        #4 0x55c94045c558 in __ui_browser__show_title ui/browser.c:266
        #5 0x55c94045c776 in ui_browser__show ui/browser.c:288
        #6 0x55c94045c06d in ui_browser__handle_resize ui/browser.c:206
        #7 0x55c94047979b in do_annotate ui/browsers/hists.c:2458
        #8 0x55c94047fb17 in evsel__hists_browse ui/browsers/hists.c:3412
        #9 0x55c940480a0c in perf_evsel_menu__run ui/browsers/hists.c:3527
        #10 0x55c940481108 in __evlist__tui_browse_hists ui/browsers/hists.c:3613
        #11 0x55c9404813f7 in evlist__tui_browse_hists ui/browsers/hists.c:3661
        #12 0x55c93ffa253f in report__browse_hists tools/perf/builtin-report.c:671
        #13 0x55c93ffa58ca in __cmd_report tools/perf/builtin-report.c:1141
        #14 0x55c93ffaf159 in cmd_report tools/perf/builtin-report.c:1805
        #15 0x55c94000c05c in report_events tools/perf/builtin-mem.c:374
        #16 0x55c94000d96d in cmd_mem tools/perf/builtin-mem.c:516
        #17 0x55c9400e44ee in run_builtin tools/perf/perf.c:350
        #18 0x55c9400e4a5a in handle_internal_command tools/perf/perf.c:403
        #19 0x55c9400e4e22 in run_argv tools/perf/perf.c:447
        #20 0x55c9400e53ad in main tools/perf/perf.c:561
        #21 0x7f28170456c9 in __libc_start_call_main
    ../sysdeps/nptl/libc_start_call_main.h:58
        #22 0x7f2817045784 in __libc_start_main_impl ../csu/libc-start.c:360
        #23 0x55c93ff544c0 in _start (/tmp/perf/perf+0x19a4c0) (BuildId:
    84899b0e8c7d3a3eaa67b2eb35e3d8b2f8cd4c93)
    
    Address 0x7f2813331920 is located in stack of thread T0 at offset 32 in frame
        #0 0x55c94046e85e in hist_browser__run ui/browsers/hists.c:746
    
      This frame has 1 object(s):
        [32, 192) 'title' (line 747) <== Memory access at offset 32 is
    inside this variable
    HINT: this may be a false positive if your program uses some custom
    stack unwind mechanism, swapcontext or vfork
    ```
    hist_browser__run isn't on the stack so the asan error looks legit.
    There's no clean init/exit on struct ui_browser so I may be trading a
    use-after-return for a memory leak, but that seems look a good trade
    anyway.
    
    Fixes: 05e8b0804ec4 ("perf ui browser: Stop using 'self'")
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Cc: Ben Gainey <ben.gainey@arm.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: James Clark <james.clark@arm.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: K Prateek Nayak <kprateek.nayak@amd.com>
    Cc: Li Dong <lidong@vivo.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Oliver Upton <oliver.upton@linux.dev>
    Cc: Paran Lee <p4ranlee@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Sun Haiyong <sunhaiyong@loongson.cn>
    Cc: Tim Chen <tim.c.chen@linux.intel.com>
    Cc: Yanteng Si <siyanteng@loongson.cn>
    Cc: Yicong Yang <yangyicong@hisilicon.com>
    Link: https://lore.kernel.org/r/20240507183545.1236093-2-irogers@google.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf util: Add a function for replacing characters in a string [+ + +]
Author: James Clark <james.clark@arm.com>
Date:   Mon Sep 4 10:50:45 2023 +0100

    perf util: Add a function for replacing characters in a string
    
    commit 8a55c1e2c9e123b399b272a7db23f09dbb74af21 upstream.
    
    It finds all occurrences of a single character and replaces them with
    a multi character string. This will be used in a test in a following
    commit.
    
    Reviewed-by: Ian Rogers <irogers@google.com>
    Signed-off-by: James Clark <james.clark@arm.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Chen Zhongjin <chenzhongjin@huawei.com>
    Cc: Eduard Zingerman <eddyz87@gmail.com>
    Cc: Haixin Yu <yuhaixin.yhx@linux.alibaba.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jing Zhang <renyu.zj@linux.alibaba.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: John Garry <john.g.garry@oracle.com>
    Cc: Kajol Jain <kjain@linux.ibm.com>
    Cc: Kan Liang <kan.liang@linux.intel.com>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Liam Howlett <liam.howlett@oracle.com>
    Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mike Leach <mike.leach@linaro.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ravi Bangoria <ravi.bangoria@amd.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Cc: linux-arm-kernel@lists.infradead.org
    Link: https://lore.kernel.org/r/20230904095104.1162928-4-james.clark@arm.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf/arm-dmc620: Fix lockdep assert in ->event_init() [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Tue May 14 11:00:50 2024 -0700

    perf/arm-dmc620: Fix lockdep assert in ->event_init()
    
    [ Upstream commit a4c5a457c6107dfe9dc65a104af1634811396bac ]
    
    for_each_sibling_event() checks leader's ctx but it doesn't have the ctx
    yet if it's the leader.  Like in perf_event_validate_size(), we should
    skip checking siblings in that case.
    
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Fixes: f3c0eba28704 ("perf: Add a few assertions")
    Reported-by: Greg Thelen <gthelen@google.com>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Tuan Phan <tuanphan@os.amperecomputing.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/20240514180050.182454-1-namhyung@kernel.org
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phy: qcom: qmp-combo: fix duplicate return in qmp_v4_configure_dp_phy [+ + +]
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Wed Feb 28 18:05:13 2024 +0100

    phy: qcom: qmp-combo: fix duplicate return in qmp_v4_configure_dp_phy
    
    [ Upstream commit e298ae7caafcc429e0fc4b3779f1738c0acc5dac ]
    
    Remove duplicate "return 0" in qmp_v4_configure_dp_phy()
    
    Fixes: 186ad90aa49f ("phy: qcom: qmp-combo: reuse register layouts for even more registers")
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Link: https://lore.kernel.org/r/20240228-topic-sm8x50-upstream-phy-combo-fix-duplicate-return-v1-1-60027a37cab1@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: qcom: pinctrl-sm7150: Fix sdc1 and ufs special pins regs [+ + +]
Author: Danila Tikhonov <danila@jiaxyga.com>
Date:   Tue Apr 23 23:32:45 2024 +0300

    pinctrl: qcom: pinctrl-sm7150: Fix sdc1 and ufs special pins regs
    
    [ Upstream commit 5ed79863fae5c06eb33f5cd6b6bdf22dd7089392 ]
    
    SDC1 and UFS_RESET special pins are located in the west memory bank.
    
    SDC1 have address 0x359a000:
    0x3500000 (TLMM BASE) + 0x0 (WEST) + 0x9a000 (SDC1_OFFSET) = 0x359a000
    
    UFS_RESET have address 0x359f000:
    0x3500000 (TLMM BASE) + 0x0 (WEST) + 0x9f000 (UFS_OFFSET) = 0x359a000
    
    Fixes: b915395c9e04 ("pinctrl: qcom: Add SM7150 pinctrl driver")
    Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
    Message-ID: <20240423203245.188480-1-danila@jiaxyga.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86/intel-uncore-freq: Don't present root domain on error [+ + +]
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Mon Apr 15 14:52:10 2024 -0700

    platform/x86/intel-uncore-freq: Don't present root domain on error
    
    commit db643cb7ebe524d17b4b13583dda03485d4a1bc0 upstream.
    
    If none of the clusters are added because of some error, fail to load
    driver without presenting root domain. In this case root domain will
    present invalid data.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Fixes: 01c10f88c9b7 ("platform/x86/intel-uncore-freq: tpmi: Provide cluster level control")
    Cc: <stable@vger.kernel.org> # 6.5+
    Link: https://lore.kernel.org/r/20240415215210.2824868-1-srinivas.pandruvada@linux.intel.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
platform/x86/intel/tpmi: Handle error from tpmi_process_info() [+ + +]
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Tue Apr 23 13:46:10 2024 -0700

    platform/x86/intel/tpmi: Handle error from tpmi_process_info()
    
    commit 2920141fc149f71bad22361946417bc43783ed7f upstream.
    
    When tpmi_process_info() returns error, fail to load the driver.
    This can happen if call to ioremap() returns error.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Cc: stable@vger.kernel.org # v6.3+
    Link: https://lore.kernel.org/r/20240423204619.3946901-2-srinivas.pandruvada@linux.intel.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
platform/x86: ISST: Add Grand Ridge to HPM CPU list [+ + +]
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Mon Apr 22 14:22:22 2024 -0700

    platform/x86: ISST: Add Grand Ridge to HPM CPU list
    
    [ Upstream commit 515a3c3a5489a890c7c3c1df3855eb4868a27598 ]
    
    Add Grand Ridge (ATOM_CRESTMONT) to hpm_cpu_ids, so that MSR 0x54 can be
    used.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Link: https://lore.kernel.org/r/20240422212222.3881606-1-srinivas.pandruvada@linux.intel.com
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: thinkpad_acpi: Take hotkey_mutex during hotkey_exit() [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Apr 24 14:28:11 2024 +0200

    platform/x86: thinkpad_acpi: Take hotkey_mutex during hotkey_exit()
    
    [ Upstream commit e397c564298c2e91aea3887990da8e8eddb65277 ]
    
    hotkey_exit() already takes the mutex around the hotkey_poll_stop_sync()
    call, but not around the other calls.
    
    commit 38831eaf7d4c ("platform/x86: thinkpad_acpi: use lockdep
    annotations") has added lockdep_assert_held() checks to various hotkey
    functions.
    
    These lockdep_assert_held() checks fail causing WARN() backtraces in
    dmesg due to missing locking in hotkey_exit(), fix this.
    
    Fixes: 38831eaf7d4c ("platform/x86: thinkpad_acpi: use lockdep annotations")
    Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20240424122834.19801-2-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pNFS/filelayout: fixup pNfs allocation modes [+ + +]
Author: Olga Kornievskaia <kolga@netapp.com>
Date:   Tue May 7 11:15:45 2024 -0400

    pNFS/filelayout: fixup pNfs allocation modes
    
    [ Upstream commit 3ebcb24646f8c5bfad2866892d3f3cff05514452 ]
    
    Change left over allocation flags.
    
    Fixes: a245832aaa99 ("pNFS/files: Ensure pNFS allocation modes are consistent with nfsiod")
    Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
    Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/fsl-soc: hide unused const variable [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Apr 3 10:06:19 2024 +0200

    powerpc/fsl-soc: hide unused const variable
    
    [ Upstream commit 01acaf3aa75e1641442cc23d8fe0a7bb4226efb1 ]
    
    vmpic_msi_feature is only used conditionally, which triggers a rare
    -Werror=unused-const-variable= warning with gcc:
    
    arch/powerpc/sysdev/fsl_msi.c:567:37: error: 'vmpic_msi_feature' defined but not used [-Werror=unused-const-variable=]
      567 | static const struct fsl_msi_feature vmpic_msi_feature =
    
    Hide this one in the same #ifdef as the reference so we can turn on
    the warning by default.
    
    Fixes: 305bcf26128e ("powerpc/fsl-soc: use CONFIG_EPAPR_PARAVIRT for hcalls")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240403080702.3509288-2-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries/lparcfg: drop error message from guest name lookup [+ + +]
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Fri May 24 14:29:54 2024 -0500

    powerpc/pseries/lparcfg: drop error message from guest name lookup
    
    [ Upstream commit 12870ae3818e39ea65bf710f645972277b634f72 ]
    
    It's not an error or exceptional situation when the hosting
    environment does not expose a name for the LP/guest via RTAS or the
    device tree. This happens with qemu when run without the '-name'
    option. The message also lacks a newline. Remove it.
    
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Fixes: eddaa9a40275 ("powerpc/pseries: read the lpar name from the firmware")
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240524-lparcfg-updates-v2-1-62e2e9d28724@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries: Add failure related checks for h_get_mpp and h_get_ppp [+ + +]
Author: Shrikanth Hegde <sshegde@linux.ibm.com>
Date:   Fri Apr 12 14:50:47 2024 +0530

    powerpc/pseries: Add failure related checks for h_get_mpp and h_get_ppp
    
    [ Upstream commit 6d4341638516bf97b9a34947e0bd95035a8230a5 ]
    
    Couple of Minor fixes:
    
    - hcall return values are long. Fix that for h_get_mpp, h_get_ppp and
    parse_ppp_data
    
    - If hcall fails, values set should be at-least zero. It shouldn't be
    uninitialized values. Fix that for h_get_mpp and h_get_ppp
    
    Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240412092047.455483-3-sshegde@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ppdev: Add an error check in register_device [+ + +]
Author: Huai-Yuan Liu <qq810974084@gmail.com>
Date:   Fri Apr 12 16:38:40 2024 +0800

    ppdev: Add an error check in register_device
    
    [ Upstream commit fbf740aeb86a4fe82ad158d26d711f2f3be79b3e ]
    
    In register_device, the return value of ida_simple_get is unchecked,
    in witch ida_simple_get will use an invalid index value.
    
    To address this issue, index should be checked after ida_simple_get. When
    the index value is abnormal, a warning message should be printed, the port
    should be dropped, and the value should be recorded.
    
    Fixes: 9a69645dde11 ("ppdev: fix registering same device name")
    Signed-off-by: Huai-Yuan Liu <qq810974084@gmail.com>
    Link: https://lore.kernel.org/r/20240412083840.234085-1-qq810974084@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ppdev: Remove usage of the deprecated ida_simple_xx() API [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue Dec 19 06:01:47 2023 +0100

    ppdev: Remove usage of the deprecated ida_simple_xx() API
    
    [ Upstream commit d8407f71ebeaeb6f50bd89791837873e44609708 ]
    
    ida_alloc() and ida_free() should be preferred to the deprecated
    ida_simple_get() and ida_simple_remove().
    
    This is less verbose.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/ba9da12fdd5cdb2c28180b7160af5042447d803f.1702962092.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: fbf740aeb86a ("ppdev: Add an error check in register_device")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
printk: Let no_printk() use _printk() [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Feb 28 15:00:02 2024 +0100

    printk: Let no_printk() use _printk()
    
    [ Upstream commit 8522f6b760ca588928eede740d5d69dd1e936b49 ]
    
    When printk-indexing is enabled, each printk() invocation emits a
    pi_entry structure, containing the format string and other information
    related to its location in the kernel sources.  This is even true for
    no_printk(): while the actual code to print the message is optimized out
    by the compiler due to the always-false check, the pi_entry structure is
    still emitted.
    
    As the main purpose of no_printk() is to provide a helper to maintain
    printf()-style format checking when debugging is disabled, this leads to
    the inclusion in the index of lots of printk formats that cannot be
    emitted by the current kernel.
    
    Fix this by switching no_printk() from printk() to _printk().
    
    This reduces the size of an arm64 defconfig kernel with
    CONFIG_PRINTK_INDEX=y by 576 KiB.
    
    Fixes: 337015573718b161 ("printk: Userspace format indexing support")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Xiubo Li <xiubli@redhat.com>
    Reviewed-by: Chris Down <chris@chrisdown.name>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/56cf92edccffea970e1f40a075334dd6cf5bb2a4.1709127473.git.geert+renesas@glider.be
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pwm: Rename pwm_apply_state() to pwm_apply_might_sleep() [+ + +]
Author: Sean Young <sean@mess.org>
Date:   Tue Dec 19 16:30:24 2023 +0000

    pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()
    
    [ Upstream commit c748a6d77c06a78651030e17da6beb278a1c9470 ]
    
    In order to introduce a pwm api which can be used from atomic context,
    we will need two functions for applying pwm changes:
    
            int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
            int pwm_apply_atomic(struct pwm *, struct pwm_state *);
    
    This commit just deals with renaming pwm_apply_state(), a following
    commit will introduce the pwm_apply_atomic() function.
    
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Mark Brown <broonie@kernel.org>
    Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Jani Nikula <jani.nikula@intel.com>
    Acked-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Stable-dep-of: 974afccd3794 ("leds: pwm: Disable PWM when going to suspend")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pwm: sti: Prepare removing pwm_chip from driver data [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Feb 14 10:32:38 2024 +0100

    pwm: sti: Prepare removing pwm_chip from driver data
    
    [ Upstream commit 54272761ce7c475fa30a31b59b0cb89f7652b39e ]
    
    This prepares the driver for further changes that will drop struct
    pwm_chip chip from struct sti_pwm_chip. Use the pwm_chip as driver data
    instead of the sti_pwm_chip to get access to the pwm_chip in
    sti_pwm_remove() without using pc->chip.
    
    Link: https://lore.kernel.org/r/56d53372aacff6871df4d6c6779c9dac94592696.1707900770.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Stable-dep-of: 5bb0b194aeee ("pwm: sti: Simplify probe function using devm functions")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pwm: sti: Simplify probe function using devm functions [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Sun Mar 10 12:00:54 2024 +0100

    pwm: sti: Simplify probe function using devm functions
    
    [ Upstream commit 5bb0b194aeee5d5da6881232f4e9989b35957c25 ]
    
    Instead of of_clk_get_by_name() use devm_clk_get_prepared() which has
    several advantages:
    
     - Combines getting the clock and a call to clk_prepare(). The latter
       can be dropped from sti_pwm_probe() accordingly.
     - Cares for calling clk_put() which is missing in both probe's error
       path and the remove function.
     - Cares for calling clk_unprepare() which can be dropped from the error
       paths and the remove function. (Note that not all error path got this
       right.)
    
    With additionally using devm_pwmchip_add() instead of pwmchip_add() the
    remove callback can be dropped completely. With it the last user of
    platform_get_drvdata() goes away and so platform_set_drvdata() can be
    dropped from the probe function, too.
    
    Fixes: 378fe115d19d ("pwm: sti: Add new driver for ST's PWM IP")
    Link: https://lore.kernel.org/r/81f0e1d173652f435afda6719adaed1922fe059a.1710068192.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
qed: avoid truncating work queue length [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 26 23:38:02 2024 +0100

    qed: avoid truncating work queue length
    
    [ Upstream commit 954fd908f177604d4cce77e2a88cc50b29bad5ff ]
    
    clang complains that the temporary string for the name passed into
    alloc_workqueue() is too short for its contents:
    
    drivers/net/ethernet/qlogic/qed/qed_main.c:1218:3: error: 'snprintf' will always be truncated; specified size is 16, but format string expands to at least 18 [-Werror,-Wformat-truncation]
    
    There is no need for a temporary buffer, and the actual name of a workqueue
    is 32 bytes (WQ_NAME_LEN), so just use the interface as intended to avoid
    the truncation.
    
    Fixes: 59ccf86fe69a ("qed: Add driver infrastucture for handling mfw requests.")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240326223825.4084412-4-arnd@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
r8169: Fix possible ring buffer corruption on fragmented Tx packets. [+ + +]
Author: Ken Milmore <ken.milmore@gmail.com>
Date:   Tue May 21 23:45:50 2024 +0100

    r8169: Fix possible ring buffer corruption on fragmented Tx packets.
    
    commit c71e3a5cffd5309d7f84444df03d5b72600cc417 upstream.
    
    An issue was found on the RTL8125b when transmitting small fragmented
    packets, whereby invalid entries were inserted into the transmit ring
    buffer, subsequently leading to calls to dma_unmap_single() with a null
    address.
    
    This was caused by rtl8169_start_xmit() not noticing changes to nr_frags
    which may occur when small packets are padded (to work around hardware
    quirks) in rtl8169_tso_csum_v2().
    
    To fix this, postpone inspecting nr_frags until after any padding has been
    applied.
    
    Fixes: 9020845fb5d6 ("r8169: improve rtl8169_start_xmit")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ken Milmore <ken.milmore@gmail.com>
    Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/27ead18b-c23d-4f49-a020-1fc482c5ac95@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow [+ + +]
Author: Nikita Kiryushin <kiryushin@ancud.ru>
Date:   Wed Mar 27 20:47:47 2024 +0300

    rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
    
    [ Upstream commit cc5645fddb0ce28492b15520306d092730dffa48 ]
    
    There is a possibility of buffer overflow in
    show_rcu_tasks_trace_gp_kthread() if counters, passed
    to sprintf() are huge. Counter numbers, needed for this
    are unrealistically high, but buffer overflow is still
    possible.
    
    Use snprintf() with buffer size instead of sprintf().
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: edf3775f0ad6 ("rcu-tasks: Add count for idle tasks on offline CPUs")
    Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
    Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rcu: Fix buffer overflow in print_cpu_stall_info() [+ + +]
Author: Nikita Kiryushin <kiryushin@ancud.ru>
Date:   Mon Apr 1 22:43:15 2024 +0300

    rcu: Fix buffer overflow in print_cpu_stall_info()
    
    [ Upstream commit 3758f7d9917bd7ef0482c4184c0ad673b4c4e069 ]
    
    The rcuc-starvation output from print_cpu_stall_info() might overflow the
    buffer if there is a huge difference in jiffies difference.  The situation
    might seem improbable, but computers sometimes get very confused about
    time, which can result in full-sized integers, and, in this case,
    buffer overflow.
    
    Also, the unsigned jiffies difference is printed using %ld, which is
    normally for signed integers.  This is intentional for debugging purposes,
    but it is not obvious from the code.
    
    This commit therefore changes sprintf() to snprintf() and adds a
    clarifying comment about intention of %ld format.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 245a62982502 ("rcu: Dump rcuc kthread status for CPUs not reporting quiescent state")
    Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
    Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/bnxt_re: Adds MSN table capability for Gen P7 adapters [+ + +]
Author: Selvin Xavier <selvin.xavier@broadcom.com>
Date:   Thu Dec 7 02:47:40 2023 -0800

    RDMA/bnxt_re: Adds MSN table capability for Gen P7 adapters
    
    [ Upstream commit 07f830ae4913d0b986c8c0ff88a7d597948b9bd8 ]
    
    GenP7 HW expects an MSN table instead of PSN table. Check
    for the HW retransmission capability and populate the MSN
    table if HW retansmission is supported.
    
    Signed-off-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://lore.kernel.org/r/1701946060-13931-7-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Stable-dep-of: 78cfd17142ef ("bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/bnxt_re: Fix the sparse warnings [+ + +]
Author: Selvin Xavier <selvin.xavier@broadcom.com>
Date:   Tue Dec 19 20:31:57 2023 -0800

    RDMA/bnxt_re: Fix the sparse warnings
    
    commit 82a8903a9f9f3ff31027b9a0b92f7505f981f09c upstream.
    
    Fix the following warnings reported
    
    drivers/infiniband/hw/bnxt_re/qplib_rcfw.c:909:27: warning: invalid assignment: |=
    drivers/infiniband/hw/bnxt_re/qplib_rcfw.c:909:27:    left side has type restricted __le16
    drivers/infiniband/hw/bnxt_re/qplib_rcfw.c:909:27:    right side has type unsigned long
    ...
    drivers/infiniband/hw/bnxt_re/qplib_fp.c:1620:44: warning: invalid assignment: |=
    drivers/infiniband/hw/bnxt_re/qplib_fp.c:1620:44:    left side has type restricted __le64
    drivers/infiniband/hw/bnxt_re/qplib_fp.c:1620:44:    right side has type unsigned long long
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202312200537.HoNqPL5L-lkp@intel.com/
    Fixes: 07f830ae4913 ("RDMA/bnxt_re: Adds MSN table capability for Gen P7 adapters")
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://lore.kernel.org/r/1703046717-8914-1-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

RDMA/bnxt_re: Refactor the queue index update [+ + +]
Author: Chandramohan Akula <chandramohan.akula@broadcom.com>
Date:   Mon Oct 23 07:03:22 2023 -0700

    RDMA/bnxt_re: Refactor the queue index update
    
    [ Upstream commit 3a4304d82695015d0703ee0c3331458d22e3ba7c ]
    
    The queue index wrap around logic is based on power of 2 size depth.
    All queues are created with power of 2 depth. This increases the
    memory usage by the driver. This change is required for the next
    patches that avoids the power of 2 depth requirement for each of
    the queues.
    
    Update the function that increments producer index and consumer
    index during wrap around. Also, changes the index handling across
    multiple functions.
    
    Signed-off-by: Chandramohan Akula <chandramohan.akula@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://lore.kernel.org/r/1698069803-1787-2-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Stable-dep-of: 78cfd17142ef ("bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/bnxt_re: Remove roundup_pow_of_two depth for all hardware queue resources [+ + +]
Author: Chandramohan Akula <chandramohan.akula@broadcom.com>
Date:   Mon Oct 23 07:03:23 2023 -0700

    RDMA/bnxt_re: Remove roundup_pow_of_two depth for all hardware queue resources
    
    [ Upstream commit 48f996d4adf15a0a0af8b8184d3ec6042a684ea4 ]
    
    Rounding up the queue depth to power of two is not a hardware requirement.
    In order to optimize the per connection memory usage, removing drivers
    implementation which round up to the queue depths to the power of 2.
    
    Implements a mask to maintain backward compatibility with older
    library.
    
    Signed-off-by: Chandramohan Akula <chandramohan.akula@broadcom.com>
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://lore.kernel.org/r/1698069803-1787-3-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Stable-dep-of: 78cfd17142ef ("bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/bnxt_re: Update the HW interface definitions [+ + +]
Author: Selvin Xavier <selvin.xavier@broadcom.com>
Date:   Thu Dec 7 02:47:37 2023 -0800

    RDMA/bnxt_re: Update the HW interface definitions
    
    [ Upstream commit 880a5dd1880a296575e92dec9816a7f35a7011d1 ]
    
    Adds HW interface definitions to support the new
    chip revision.
    
    Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
    Link: https://lore.kernel.org/r/1701946060-13931-4-git-send-email-selvin.xavier@broadcom.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Stable-dep-of: 78cfd17142ef ("bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw [+ + +]
Author: Zhu Yanjun <yanjun.zhu@linux.dev>
Date:   Fri May 10 23:12:47 2024 +0200

    RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw
    
    [ Upstream commit 9c0731832d3b7420cbadba6a7f334363bc8dfb15 ]
    
    When running blktests nvme/rdma, the following kmemleak issue will appear.
    
    kmemleak: Kernel memory leak detector initialized (mempool available:36041)
    kmemleak: Automatic memory scanning thread started
    kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    kmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    
    unreferenced object 0xffff88855da53400 (size 192):
      comm "rdma", pid 10630, jiffies 4296575922
      hex dump (first 32 bytes):
        37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00  7...............
        10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff  .4.].....4.]....
      backtrace (crc 47f66721):
        [<ffffffff911251bd>] kmalloc_trace+0x30d/0x3b0
        [<ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core]
        [<ffffffffc2642206>] add_modify_gid+0x166/0x930 [ib_core]
        [<ffffffffc2643468>] ib_cache_update.part.0+0x6d8/0x910 [ib_core]
        [<ffffffffc2644e1a>] ib_cache_setup_one+0x24a/0x350 [ib_core]
        [<ffffffffc263949e>] ib_register_device+0x9e/0x3a0 [ib_core]
        [<ffffffffc2a3d389>] 0xffffffffc2a3d389
        [<ffffffffc2688cd8>] nldev_newlink+0x2b8/0x520 [ib_core]
        [<ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core]
        [<ffffffffc264648c>]
    rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core]
        [<ffffffff9270e7b5>] netlink_unicast+0x445/0x710
        [<ffffffff9270f1f1>] netlink_sendmsg+0x761/0xc40
        [<ffffffff9249db29>] __sys_sendto+0x3a9/0x420
        [<ffffffff9249dc8c>] __x64_sys_sendto+0xdc/0x1b0
        [<ffffffff92db0ad3>] do_syscall_64+0x93/0x180
        [<ffffffff92e00126>] entry_SYSCALL_64_after_hwframe+0x71/0x79
    
    The root cause: rdma_put_gid_attr is not called when sgid_attr is set
    to ERR_PTR(-ENODEV).
    
    Reported-and-tested-by: Yi Zhang <yi.zhang@redhat.com>
    Closes: https://lore.kernel.org/all/19bf5745-1b3b-4b8a-81c2-20d945943aaf@linux.dev/T/
    Fixes: f8ef1be816bf ("RDMA/cma: Avoid GID lookups on iWARP devices")
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
    Link: https://lore.kernel.org/r/20240510211247.31345-1-yanjun.zhu@linux.dev
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/hns: Fix deadlock on SRQ async events. [+ + +]
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Fri Apr 12 17:16:10 2024 +0800

    RDMA/hns: Fix deadlock on SRQ async events.
    
    [ Upstream commit b46494b6f9c19f141114a57729e198698f40af37 ]
    
    xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/
    xa_erase_irq() to avoid deadlock.
    
    Fixes: 81fce6291d99 ("RDMA/hns: Add SRQ asynchronous event support")
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20240412091616.370789-5-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Fix GMV table pagesize [+ + +]
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Fri Apr 12 17:16:13 2024 +0800

    RDMA/hns: Fix GMV table pagesize
    
    [ Upstream commit ee045493283403969591087bd405fa280103282a ]
    
    GMV's BA table only supports 4K pages. Currently, PAGESIZE is used to
    calculate gmv_bt_num, which will cause an abnormal number of gmv_bt_num
    in a 64K OS.
    
    Fixes: d6d91e46210f ("RDMA/hns: Add support for configuring GMV table")
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20240412091616.370789-8-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Fix return value in hns_roce_map_mr_sg [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Thu Apr 11 11:38:51 2024 +0800

    RDMA/hns: Fix return value in hns_roce_map_mr_sg
    
    [ Upstream commit 203b70fda63425a4eb29f03f9074859afe821a39 ]
    
    As described in the ib_map_mr_sg function comment, it returns the number
    of sg elements that were mapped to the memory region. However,
    hns_roce_map_mr_sg returns the number of pages required for mapping the
    DMA area. Fix it.
    
    Fixes: 9b2cf76c9f05 ("RDMA/hns: Optimize PBL buffer allocation process")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Link: https://lore.kernel.org/r/20240411033851.2884771-1-shaozhengchao@huawei.com
    Reviewed-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Fix UAF for cq async event [+ + +]
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Fri Apr 12 17:16:11 2024 +0800

    RDMA/hns: Fix UAF for cq async event
    
    [ Upstream commit a942ec2745ca864cd8512142100e4027dc306a42 ]
    
    The refcount of CQ is not protected by locks. When CQ asynchronous
    events and CQ destruction are concurrent, CQ may have been released,
    which will cause UAF.
    
    Use the xa_lock() to protect the CQ refcount.
    
    Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20240412091616.370789-6-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Modify the print level of CQE error [+ + +]
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Fri Apr 12 17:16:16 2024 +0800

    RDMA/hns: Modify the print level of CQE error
    
    [ Upstream commit 349e859952285ab9689779fb46de163f13f18f43 ]
    
    Too much print may lead to a panic in kernel. Change ibdev_err() to
    ibdev_err_ratelimited(), and change the printing level of cqe dump
    to debug level.
    
    Fixes: 7c044adca272 ("RDMA/hns: Simplify the cqe code of poll cq")
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20240412091616.370789-11-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/hns: Use complete parentheses in macros [+ + +]
Author: Chengchang Tang <tangchengchang@huawei.com>
Date:   Fri Apr 12 17:16:15 2024 +0800

    RDMA/hns: Use complete parentheses in macros
    
    [ Upstream commit 4125269bb9b22e1d8cdf4412c81be8074dbc61ca ]
    
    Use complete parentheses to ensure that macro expansion does
    not produce unexpected results.
    
    Fixes: a25d13cbe816 ("RDMA/hns: Add the interfaces to support multi hop addressing for the contexts in hip08")
    Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
    Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com>
    Link: https://lore.kernel.org/r/20240412091616.370789-10-huangjunxian6@hisilicon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/IPoIB: Fix format truncation compilation errors [+ + +]
Author: Leon Romanovsky <leon@kernel.org>
Date:   Thu May 9 10:39:33 2024 +0300

    RDMA/IPoIB: Fix format truncation compilation errors
    
    [ Upstream commit 49ca2b2ef3d003402584c68ae7b3055ba72e750a ]
    
    Truncate the device name to store IPoIB VLAN name.
    
    [leonro@5b4e8fba4ddd kernel]$ make -s -j 20 allmodconfig
    [leonro@5b4e8fba4ddd kernel]$ make -s -j 20 W=1 drivers/infiniband/ulp/ipoib/
    drivers/infiniband/ulp/ipoib/ipoib_vlan.c: In function ‘ipoib_vlan_add’:
    drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:52: error: ‘%04x’
    directive output may be truncated writing 4 bytes into a region of size
    between 0 and 15 [-Werror=format-truncation=]
      187 |         snprintf(intf_name, sizeof(intf_name), "%s.%04x",
          |                                                    ^~~~
    drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:48: note: directive
    argument in the range [0, 65535]
      187 |         snprintf(intf_name, sizeof(intf_name), "%s.%04x",
          |                                                ^~~~~~~~~
    drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:9: note: ‘snprintf’ output
    between 6 and 21 bytes into a destination of size 16
      187 |         snprintf(intf_name, sizeof(intf_name), "%s.%04x",
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      188 |                  ppriv->dev->name, pkey);
          |                  ~~~~~~~~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors
    make[6]: *** [scripts/Makefile.build:244: drivers/infiniband/ulp/ipoib/ipoib_vlan.o] Error 1
    make[6]: *** Waiting for unfinished jobs....
    
    Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
    Link: https://lore.kernel.org/r/e9d3e1fef69df4c9beaf402cc3ac342bad680791.1715240029.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/mlx5: Adding remote atomic access flag to updatable flags [+ + +]
Author: Or Har-Toov <ohartoov@nvidia.com>
Date:   Wed Apr 3 13:36:01 2024 +0300

    RDMA/mlx5: Adding remote atomic access flag to updatable flags
    
    [ Upstream commit 2ca7e93bc963d9ec2f5c24d117176851454967af ]
    
    Currently IB_ACCESS_REMOTE_ATOMIC is blocked from being updated via UMR
    although in some cases it should be possible. These cases are checked in
    mlx5r_umr_can_reconfig function.
    
    Fixes: ef3642c4f54d ("RDMA/mlx5: Fix error unwinds for rereg_mr")
    Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
    Link: https://lore.kernel.org/r/24dac73e2fa48cb806f33a932d97f3e402a5ea2c.1712140377.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/mlx5: Uncacheable mkey has neither rb_key or cache_ent [+ + +]
Author: Or Har-Toov <ohartoov@nvidia.com>
Date:   Wed Apr 3 13:35:59 2024 +0300

    RDMA/mlx5: Uncacheable mkey has neither rb_key or cache_ent
    
    [ Upstream commit 0611a8e8b475fc5230b9a24d29c8397aaab20b63 ]
    
    As some mkeys can't be modified with UMR due to some UMR limitations,
    like the size of translation that can be updated, not all user mkeys can
    be cached.
    
    Fixes: dd1b913fb0d0 ("RDMA/mlx5: Cache all user cacheable mkeys on dereg MR flow")
    Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
    Link: https://lore.kernel.org/r/f2742dd934ed73b2d32c66afb8e91b823063880c.1712140377.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/rxe: Allow good work requests to be executed [+ + +]
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Fri Mar 29 09:55:05 2024 -0500

    RDMA/rxe: Allow good work requests to be executed
    
    [ Upstream commit b703374837a8f8422fa3f1edcf65505421a65a6a ]
    
    A previous commit incorrectly added an 'if(!err)' before scheduling the
    requester task in rxe_post_send_kernel(). But if there were send wrs
    successfully added to the send queue before a bad wr they might never get
    executed.
    
    This commit fixes this by scheduling the requester task if any wqes were
    successfully posted in rxe_post_send_kernel() in rxe_verbs.c.
    
    Link: https://lore.kernel.org/r/20240329145513.35381-5-rpearsonhpe@gmail.com
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Fixes: 5bf944f24129 ("RDMA/rxe: Add error messages")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: Fix incorrect rxe_put in error path [+ + +]
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Fri Mar 29 09:55:12 2024 -0500

    RDMA/rxe: Fix incorrect rxe_put in error path
    
    [ Upstream commit 8776618dbbd1b6f210b31509507e1aad461d6435 ]
    
    In rxe_send() a ref is taken on the qp to keep it alive until the
    kfree_skb() has a chance to call the skb destructor rxe_skb_tx_dtor()
    which drops the reference. If the packet has an incorrect protocol the
    error path just calls kfree_skb() which will call the destructor which
    will drop the ref. Currently the driver also calls rxe_put() which is
    incorrect. Additionally since the packets sent to rxe_send() are under the
    control of the driver and it only ever produces IPV4 or IPV6 packets the
    simplest fix is to remove all the code in this block.
    
    Link: https://lore.kernel.org/r/20240329145513.35381-12-rpearsonhpe@gmail.com
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Fixes: 9eb7f8e44d13 ("IB/rxe: Move refcounting earlier in rxe_send()")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt [+ + +]
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Fri Mar 29 09:55:04 2024 -0500

    RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
    
    [ Upstream commit 2b23b6097303ed0ba5f4bc036a1c07b6027af5c6 ]
    
    In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the
    resp_pkts queue and then a decision is made whether to run the completer
    task inline or schedule it. Finally the skb is dereferenced to bump a 'hw'
    performance counter. This is wrong because if the completer task is
    already running in a separate thread it may have already processed the skb
    and freed it which can cause a seg fault.  This has been observed
    infrequently in testing at high scale.
    
    This patch fixes this by changing the order of enqueuing the packet until
    after the counter is accessed.
    
    Link: https://lore.kernel.org/r/20240329145513.35381-4-rpearsonhpe@gmail.com
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Fixes: 0b1e5b99a48b ("IB/rxe: Add port protocol stats")
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regulator: bd71828: Don't overwrite runtime voltages [+ + +]
Author: Matti Vaittinen <mazziesaccount@gmail.com>
Date:   Thu May 16 11:54:41 2024 +0300

    regulator: bd71828: Don't overwrite runtime voltages
    
    [ Upstream commit 0f9f7c63c415e287cd57b5c98be61eb320dedcfc ]
    
    Some of the regulators on the BD71828 have common voltage setting for
    RUN/SUSPEND/IDLE/LPSR states. The enable control can be set for each
    state though.
    
    The driver allows setting the voltage values for these states via
    device-tree. As a side effect, setting the voltages for
    SUSPEND/IDLE/LPSR will also change the RUN level voltage which is not
    desired and can break the system.
    
    The comment in code reflects this behaviour, but it is likely to not
    make people any happier. The right thing to do is to allow setting the
    enable/disable state at SUSPEND/IDLE/LPSR via device-tree, but to
    disallow setting state specific voltages for those regulators.
    
    BUCK1 is a bit different. It only shares the SUSPEND and LPSR state
    voltages. The former behaviour of allowing to silently overwrite the
    SUSPEND state voltage by LPSR state voltage is also changed here so that
    the SUSPEND voltage is prioritized over LPSR voltage.
    
    Prevent setting PMIC state specific voltages for regulators which do not
    support it.
    
    Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
    Fixes: 522498f8cb8c ("regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators")
    Link: https://msgid.link/r/e1883ae1e3ae5668f1030455d4750923561f3d68.1715848512.git.mazziesaccount@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: irq_helpers: duplicate IRQ name [+ + +]
Author: Matti Vaittinen <mazziesaccount@gmail.com>
Date:   Sun Apr 7 10:35:21 2024 +0300

    regulator: irq_helpers: duplicate IRQ name
    
    [ Upstream commit 7ab681ddedd4b6dd2b047c74af95221c5f827e1d ]
    
    The regulator IRQ helper requires caller to provide pointer to IRQ name
    which is kept in memory by caller. All other data passed to the helper
    in the regulator_irq_desc structure is copied. This can cause some
    confusion and unnecessary complexity.
    
    Make the regulator_irq_helper() to copy also the provided IRQ name
    information so caller can discard the name after the call to
    regulator_irq_helper() completes.
    
    Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
    Link: https://msgid.link/r/ZhJMuUYwaZbBXFGP@drtxq0yyyyyyyyyyyyydy-3.rev.dnainternet.fi
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: pickable ranges: don't always cache vsel [+ + +]
Author: Matti Vaittinen <mazziesaccount@gmail.com>
Date:   Mon May 20 15:31:33 2024 +0300

    regulator: pickable ranges: don't always cache vsel
    
    [ Upstream commit f4f4276f985a5aac7b310a4ed040b47e275e7591 ]
    
    Some PMICs treat the vsel_reg same as apply-bit. Eg, when voltage range
    is changed, the new voltage setting is not taking effect until the vsel
    register is written.
    
    Add a flag 'range_applied_by_vsel' to the regulator desc to indicate this
    behaviour and to force the vsel value to be written to hardware if range
    was changed, even if the old selector was same as the new one.
    
    Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
    Link: https://msgid.link/r/ZktCpcGZdgHWuN_L@fedora
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Stable-dep-of: 1ace99d7c7c4 ("regulator: tps6287x: Force writing VSEL bit")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: qcom-refgen: fix module autoloading [+ + +]
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Wed Apr 10 19:26:14 2024 +0200

    regulator: qcom-refgen: fix module autoloading
    
    [ Upstream commit ddd3f34c10002e41ed3cd89c9bd8f1d05a22506a ]
    
    Add MODULE_DEVICE_TABLE(), so the module could be properly autoloaded
    based on the alias from of_device_id table.
    
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://msgid.link/r/20240410172615.255424-1-krzk@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: tps6287x: Force writing VSEL bit [+ + +]
Author: Matti Vaittinen <mazziesaccount@gmail.com>
Date:   Mon May 20 15:36:55 2024 +0300

    regulator: tps6287x: Force writing VSEL bit
    
    [ Upstream commit 1ace99d7c7c4c801c0660246f741ff846a9b8e3c ]
    
    The data-sheet for TPS6287x-Q1
    https://www.ti.com/lit/ds/symlink/tps62873-q1.pdf
    states at chapter 9.3.6.1 Output Voltage Range:
    
    "Note that every change to the VRANGE[1:0] bits must be followed by a
    write to the VSET register, even if the value of the VSET[7:0] bits does
    not change."
    
    The current implementation of the driver uses the
    regulator_set_voltage_sel_pickable_regmap() helper which further uses
    regmap_update_bits() to write the VSET-register. The
    regmap_update_bits() will not access the hardware if the new register
    value is same as old. It is worth noting that this is true also when the
    register is marked volatile, which I can't say is wrong because
    'read-mnodify-write'-cycle with a volatile register is in any case
    something user should carefully consider.
    
    The 'range_applied_by_vsel'-flag in regulator desc was added to force
    the vsel register upodates by using regmap_write_bits(). This variant
    will always unconditionally write the bits to the hardware.
    
    It is worth noting that the vsel is now forced to be written to the
    hardware, whether the range was changed or not. This may cause a
    performance drop if users are wrtiting same voltage value repeteadly.
    
    It would be possible to read the range register to determine if it was
    changed, but this would be a performance issue for users who don't use
    reg cache for vsel.
    
    Always write the VSET register to the hardware regardless the cache.
    
    Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
    Fixes: 7b0518fbf2be ("regulator: Add support for TI TPS6287x regulators")
    Link: https://msgid.link/r/ZktD50C5twF1EuKu@fedora
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: tps6594-regulator: Correct multi-phase configuration [+ + +]
Author: Neha Malcom Francis <n-francis@ti.com>
Date:   Tue May 21 15:17:58 2024 +0530

    regulator: tps6594-regulator: Correct multi-phase configuration
    
    [ Upstream commit 74b38cd77d3eb63c6d0ad9cf2ae59812ae54d3ee ]
    
    According to the TPS6594 PMIC Manual (linked) 8.3.2.1.4 Multi-Phase BUCK
    Regulator Configurations section, the PMIC ignores all the other bucks'
    except the primary buck's regulator registers. This is BUCK1 for
    configurations BUCK12, BUCK123 and BUCK1234 while it is BUCK3 for
    BUCK34. Correct the registers mapped for these configurations
    accordingly.
    
    Fixes: f17ccc5deb4d ("regulator: tps6594-regulator: Add driver for TI TPS6594 regulators")
    Link: https://www.ti.com/lit/gpn/tps6594-q1
    Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
    Link: https://msgid.link/r/20240521094758.2190331-1-n-francis@ti.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: vqmmc-ipq4019: fix module autoloading [+ + +]
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Wed Apr 10 19:26:15 2024 +0200

    regulator: vqmmc-ipq4019: fix module autoloading
    
    [ Upstream commit 68adb581a39ae63a0ed082c47f01fbbe515efa0e ]
    
    Add MODULE_DEVICE_TABLE(), so the module could be properly autoloaded
    based on the alias from of_device_id table.
    
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Link: https://msgid.link/r/20240410172615.255424-2-krzk@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "drm/bridge: ti-sn65dsi83: Fix enable error path" [+ + +]
Author: Luca Ceresoli <luca.ceresoli@bootlin.com>
Date:   Fri Apr 26 14:22:59 2024 +0200

    Revert "drm/bridge: ti-sn65dsi83: Fix enable error path"
    
    [ Upstream commit ad81feb5b6f1f5461641706376dcf7a9914ed2e7 ]
    
    This reverts commit 8a91b29f1f50ce7742cdbe5cf11d17f128511f3f.
    
    The regulator_disable() added by the original commit solves one kind of
    regulator imbalance but adds another one as it allows the regulator to be
    disabled one more time than it is enabled in the following scenario:
    
     1. Start video pipeline -> sn65dsi83_atomic_pre_enable -> regulator_enable
     2. PLL lock fails -> regulator_disable
     3. Stop video pipeline -> sn65dsi83_atomic_disable -> regulator_disable
    
    The reason is clear from the code flow, which looks like this (after
    removing unrelated code):
    
      static void sn65dsi83_atomic_pre_enable()
      {
          regulator_enable(ctx->vcc);
    
          if (PLL failed locking) {
              regulator_disable(ctx->vcc);  <---- added by patch being reverted
              return;
          }
      }
    
      static void sn65dsi83_atomic_disable()
      {
          regulator_disable(ctx->vcc);
      }
    
    The use case for introducing the additional regulator_disable() was
    removing the module for debugging (see link below for the discussion). If
    the module is removed after a .atomic_pre_enable, i.e. with an active
    pipeline from the DRM point of view, .atomic_disable is not called and thus
    the regulator would not be disabled.
    
    According to the discussion however there is no actual use case for
    removing the module with an active pipeline, except for
    debugging/development.
    
    On the other hand, the occurrence of a PLL lock failure is possible due to
    any physical reason (e.g. a temporary hardware failure for electrical
    reasons) so handling it gracefully should be supported. As there is no way
    for .atomic[_pre]_enable to report an error to the core, the only clean way
    to support it is calling regulator_disabled() only in .atomic_disable,
    unconditionally, as it was before.
    
    Link: https://lore.kernel.org/all/15244220.uLZWGnKmhe@steina-w/
    Fixes: 8a91b29f1f50 ("drm/bridge: ti-sn65dsi83: Fix enable error path")
    Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Signed-off-by: Robert Foss <rfoss@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240426122259.46808-1-luca.ceresoli@bootlin.com
    (cherry picked from commit 2940ee03b23281071620dda1d790cd644dabd394)
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "ixgbe: Manual AN-37 for troublesome link partners for X550 SFI" [+ + +]
Author: Jacob Keller <jacob.e.keller@intel.com>
Date:   Mon May 20 17:21:27 2024 -0700

    Revert "ixgbe: Manual AN-37 for troublesome link partners for X550 SFI"
    
    [ Upstream commit b35b1c0b4e166a427395deaf61e3140495dfcb89 ]
    
    This reverts commit 565736048bd5f9888990569993c6b6bfdf6dcb6d.
    
    According to the commit, it implements a manual AN-37 for some
    "troublesome" Juniper MX5 switches. This appears to be a workaround for a
    particular switch.
    
    It has been reported that this causes a severe breakage for other switches,
    including a Cisco 3560CX-12PD-S.
    
    The code appears to be a workaround for a specific switch which fails to
    link in SFI mode. It expects to see AN-37 auto negotiation in order to
    link. The Cisco switch is not expecting AN-37 auto negotiation. When the
    device starts the manual AN-37, the Cisco switch decides that the port is
    confused and stops attempting to link with it. This persists until a power
    cycle. A simple driver unload and reload does not resolve the issue, even
    if loading with a version of the driver which lacks this workaround.
    
    The authors of the workaround commit have not responded with
    clarifications, and the result of the workaround is complete failure to
    connect with other switches.
    
    This appears to be a case where the driver can either "correctly" link with
    the Juniper MX5 switch, at the cost of bricking the link with the Cisco
    switch, or it can behave properly for the Cisco switch, but fail to link
    with the Junipir MX5 switch. I do not know enough about the standards
    involved to clearly determine whether either switch is at fault or behaving
    incorrectly. Nor do I know whether there exists some alternative fix which
    corrects behavior with both switches.
    
    Revert the workaround for the Juniper switch.
    
    Fixes: 565736048bd5 ("ixgbe: Manual AN-37 for troublesome link partners for X550 SFI")
    Link: https://lore.kernel.org/netdev/cbe874db-9ac9-42b8-afa0-88ea910e1e99@intel.com/T/
    Link: https://forum.proxmox.com/threads/intel-x553-sfp-ixgbe-no-go-on-pve8.135129/#post-612291
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
    Cc: Jeff Daly <jeffd@silicom-usa.com>
    Cc: kernel.org-fo5k2w@ycharbi.fr
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240520-net-2024-05-20-revert-silicom-switch-workaround-v1-1-50f80f261c94@intel.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "net: txgbe: fix clk_name exceed MAX_DEV_ID limits" [+ + +]
Author: Duanqiang Wen <duanqiangwen@net-swift.com>
Date:   Mon Apr 22 16:41:09 2024 +0800

    Revert "net: txgbe: fix clk_name exceed MAX_DEV_ID limits"
    
    [ Upstream commit edd2d250fb3bb5d70419ae82c1f9dbb9684dffd3 ]
    
    This reverts commit e30cef001da259e8df354b813015d0e5acc08740.
    commit 99f4570cfba1 ("clkdev: Update clkdev id usage to allow
    for longer names") can fix clk_name exceed MAX_DEV_ID limits,
    so this commit is meaningless.
    
    Signed-off-by: Duanqiang Wen <duanqiangwen@net-swift.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Link: https://lore.kernel.org/r/20240422084109.3201-2-duanqiangwen@net-swift.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Revert "net: txgbe: fix i2c dev name cannot match clkdev" [+ + +]
Author: Duanqiang Wen <duanqiangwen@net-swift.com>
Date:   Mon Apr 22 16:41:08 2024 +0800

    Revert "net: txgbe: fix i2c dev name cannot match clkdev"
    
    [ Upstream commit 8d6bf83f6740ba52a59e25dad360e1e87ef47666 ]
    
    This reverts commit c644920ce9220d83e070f575a4df711741c07f07.
    when register i2c dev, txgbe shorten "i2c_designware" to "i2c_dw",
    will cause this i2c dev can't match platfom driver i2c_designware_platform.
    
    Signed-off-by: Duanqiang Wen <duanqiangwen@net-swift.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Link: https://lore.kernel.org/r/20240422084109.3201-1-duanqiangwen@net-swift.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "r8169: don't try to disable interrupts if NAPI is, scheduled already" [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed May 15 08:18:01 2024 +0200

    Revert "r8169: don't try to disable interrupts if NAPI is, scheduled already"
    
    commit eabb8a9be1e4a12f3bf37ceb7411083e3775672d upstream.
    
    This reverts commit 7274c4147afbf46f45b8501edbdad6da8cd013b9.
    
    Ken reported that RTL8125b can lock up if gro_flush_timeout has the
    default value of 20000 and napi_defer_hard_irqs is set to 0.
    In this scenario device interrupts aren't disabled, what seems to
    trigger some silicon bug under heavy load. I was able to reproduce this
    behavior on RTL8168h. Fix this by reverting 7274c4147afb.
    
    Fixes: 7274c4147afb ("r8169: don't try to disable interrupts if NAPI is scheduled already")
    Cc: stable@vger.kernel.org
    Reported-by: Ken Milmore <ken.milmore@gmail.com>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/9b5b6f4c-4f54-4b90-b0b3-8d8023c2e780@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "sh: Handle calling csum_partial with misaligned data" [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Mar 24 16:18:04 2024 -0700

    Revert "sh: Handle calling csum_partial with misaligned data"
    
    [ Upstream commit b5319c96292ff877f6b58d349acf0a9dc8d3b454 ]
    
    This reverts commit cadc4e1a2b4d20d0cc0e81f2c6ba0588775e54e5.
    
    Commit cadc4e1a2b4d ("sh: Handle calling csum_partial with misaligned
    data") causes bad checksum calculations on unaligned data. Reverting
    it fixes the problem.
    
        # Subtest: checksum
        # module: checksum_kunit
        1..5
        # test_csum_fixed_random_inputs: ASSERTION FAILED at lib/checksum_kunit.c:500
        Expected ( u64)result == ( u64)expec, but
            ( u64)result == 53378 (0xd082)
            ( u64)expec == 33488 (0x82d0)
        # test_csum_fixed_random_inputs: pass:0 fail:1 skip:0 total:1
        not ok 1 test_csum_fixed_random_inputs
        # test_csum_all_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:525
        Expected ( u64)result == ( u64)expec, but
            ( u64)result == 65281 (0xff01)
            ( u64)expec == 65280 (0xff00)
        # test_csum_all_carry_inputs: pass:0 fail:1 skip:0 total:1
        not ok 2 test_csum_all_carry_inputs
        # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:573
        Expected ( u64)result == ( u64)expec, but
            ( u64)result == 65535 (0xffff)
            ( u64)expec == 65534 (0xfffe)
        # test_csum_no_carry_inputs: pass:0 fail:1 skip:0 total:1
        not ok 3 test_csum_no_carry_inputs
        # test_ip_fast_csum: pass:1 fail:0 skip:0 total:1
        ok 4 test_ip_fast_csum
        # test_csum_ipv6_magic: pass:1 fail:0 skip:0 total:1
        ok 5 test_csum_ipv6_magic
     # checksum: pass:2 fail:3 skip:0 total:5
     # Totals: pass:2 fail:3 skip:0 total:5
    not ok 22 checksum
    
    Fixes: cadc4e1a2b4d ("sh: Handle calling csum_partial with misaligned data")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Link: https://lore.kernel.org/r/20240324231804.841099-1-linux@roeck-us.net
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ring-buffer: Fix a race between readers and resize checks [+ + +]
Author: Petr Pavlu <petr.pavlu@suse.com>
Date:   Fri May 17 15:40:08 2024 +0200

    ring-buffer: Fix a race between readers and resize checks
    
    commit c2274b908db05529980ec056359fae916939fdaa upstream.
    
    The reader code in rb_get_reader_page() swaps a new reader page into the
    ring buffer by doing cmpxchg on old->list.prev->next to point it to the
    new page. Following that, if the operation is successful,
    old->list.next->prev gets updated too. This means the underlying
    doubly-linked list is temporarily inconsistent, page->prev->next or
    page->next->prev might not be equal back to page for some page in the
    ring buffer.
    
    The resize operation in ring_buffer_resize() can be invoked in parallel.
    It calls rb_check_pages() which can detect the described inconsistency
    and stop further tracing:
    
    [  190.271762] ------------[ cut here ]------------
    [  190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
    [  190.271789] Modules linked in: [...]
    [  190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
    [  190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G            E      6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
    [  190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
    [  190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
    [  190.272023] Code: [...]
    [  190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
    [  190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
    [  190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
    [  190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
    [  190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
    [  190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
    [  190.272053] FS:  00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
    [  190.272057] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
    [  190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  190.272077] Call Trace:
    [  190.272098]  <TASK>
    [  190.272189]  ring_buffer_resize+0x2ab/0x460
    [  190.272199]  __tracing_resize_ring_buffer.part.0+0x23/0xa0
    [  190.272206]  tracing_resize_ring_buffer+0x65/0x90
    [  190.272216]  tracing_entries_write+0x74/0xc0
    [  190.272225]  vfs_write+0xf5/0x420
    [  190.272248]  ksys_write+0x67/0xe0
    [  190.272256]  do_syscall_64+0x82/0x170
    [  190.272363]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [  190.272373] RIP: 0033:0x7f1bd657d263
    [  190.272381] Code: [...]
    [  190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [  190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
    [  190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
    [  190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
    [  190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
    [  190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
    [  190.272412]  </TASK>
    [  190.272414] ---[ end trace 0000000000000000 ]---
    
    Note that ring_buffer_resize() calls rb_check_pages() only if the parent
    trace_buffer has recording disabled. Recent commit d78ab792705c
    ("tracing: Stop current tracer when resizing buffer") causes that it is
    now always the case which makes it more likely to experience this issue.
    
    The window to hit this race is nonetheless very small. To help
    reproducing it, one can add a delay loop in rb_get_reader_page():
    
     ret = rb_head_page_replace(reader, cpu_buffer->reader_page);
     if (!ret)
            goto spin;
     for (unsigned i = 0; i < 1U << 26; i++)  /* inserted delay loop */
            __asm__ __volatile__ ("" : : : "memory");
     rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;
    
    .. and then run the following commands on the target system:
    
     echo 1 > /sys/kernel/tracing/events/sched/sched_switch/enable
     while true; do
            echo 16 > /sys/kernel/tracing/buffer_size_kb; sleep 0.1
            echo 8 > /sys/kernel/tracing/buffer_size_kb; sleep 0.1
     done &
     while true; do
            for i in /sys/kernel/tracing/per_cpu/*; do
                    timeout 0.1 cat $i/trace_pipe; sleep 0.2
            done
     done
    
    To fix the problem, make sure ring_buffer_resize() doesn't invoke
    rb_check_pages() concurrently with a reader operating on the same
    ring_buffer_per_cpu by taking its cpu_buffer->reader_lock.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240517134008.24529-3-petr.pavlu@suse.com
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Fixes: 659f451ff213 ("ring-buffer: Add integrity check at end of iter read")
    Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
    [ Fixed whitespace ]
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
riscv, bpf: make some atomic operations fully ordered [+ + +]
Author: Puranjay Mohan <puranjay@kernel.org>
Date:   Sun May 5 20:16:33 2024 +0000

    riscv, bpf: make some atomic operations fully ordered
    
    [ Upstream commit 20a759df3bba35bf5c3ddec0c02ad69b603b584c ]
    
    The BPF atomic operations with the BPF_FETCH modifier along with
    BPF_XCHG and BPF_CMPXCHG are fully ordered but the RISC-V JIT implements
    all atomic operations except BPF_CMPXCHG with relaxed ordering.
    
    Section 8.1 of the "The RISC-V Instruction Set Manual Volume I:
    Unprivileged ISA" [1], titled, "Specifying Ordering of Atomic
    Instructions" says:
    
    | To provide more efficient support for release consistency [5], each
    | atomic instruction has two bits, aq and rl, used to specify additional
    | memory ordering constraints as viewed by other RISC-V harts.
    
    and
    
    | If only the aq bit is set, the atomic memory operation is treated as
    | an acquire access.
    | If only the rl bit is set, the atomic memory operation is treated as a
    | release access.
    |
    | If both the aq and rl bits are set, the atomic memory operation is
    | sequentially consistent.
    
    Fix this by setting both aq and rl bits as 1 for operations with
    BPF_FETCH and BPF_XCHG.
    
    [1] https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf
    
    Fixes: dd642ccb45ec ("riscv, bpf: Implement more atomic operations for RV64")
    Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
    Reviewed-by: Pu Lehui <pulehui@huawei.com>
    Link: https://lore.kernel.org/r/20240505201633.123115-1-puranjay@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
riscv: dts: starfive: visionfive 2: Remove non-existing TDM hardware [+ + +]
Author: Hannah Peuckmann <hannah.peuckmann@canonical.com>
Date:   Mon Apr 15 14:50:32 2024 +0200

    riscv: dts: starfive: visionfive 2: Remove non-existing TDM hardware
    
    [ Upstream commit dcde4e97b122ac318aaa71e8bcd2857dc28a0d12 ]
    
    This partially reverts
    commit e7c304c0346d ("riscv: dts: starfive: jh7110: add the node and pins configuration for tdm")
    
    This added device tree nodes for TDM hardware that is not actually on the
    VisionFive 2 board, but connected on the 40pin header. Many different extension
    boards could be added on those pins, so this should be handled by overlays
    instead.
    This also conflicts with the I2S node which also attempts to grab GPIO 44:
    
      starfive-jh7110-sys-pinctrl 13040000.pinctrl: pin GPIO44 already requested by 10090000.tdm; cannot claim for 120c0000.i2s
    
    Fixes: e7c304c0346d ("riscv: dts: starfive: jh7110: add the node and pins configuration for tdm")
    Signed-off-by: Hannah Peuckmann <hannah.peuckmann@canonical.com>
    Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Tested-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: prevent pt_regs corruption for secondary idle threads [+ + +]
Author: Sergey Matyukevich <sergey.matyukevich@syntacore.com>
Date:   Thu May 23 11:43:23 2024 +0300

    riscv: prevent pt_regs corruption for secondary idle threads
    
    commit a638b0461b58aa3205cd9d5f14d6f703d795b4af upstream.
    
    Top of the kernel thread stack should be reserved for pt_regs. However
    this is not the case for the idle threads of the secondary boot harts.
    Their stacks overlap with their pt_regs, so both may get corrupted.
    
    Similar issue has been fixed for the primary hart, see c7cdd96eca28
    ("riscv: prevent stack corruption by reserving task_pt_regs(p) early").
    However that fix was not propagated to the secondary harts. The problem
    has been noticed in some CPU hotplug tests with V enabled. The function
    smp_callin stored several registers on stack, corrupting top of pt_regs
    structure including status field. As a result, kernel attempted to save
    or restore inexistent V context.
    
    Fixes: 9a2451f18663 ("RISC-V: Avoid using per cpu array for ordered booting")
    Fixes: 2875fe056156 ("RISC-V: Add cpu_ops and modify default booting method")
    Signed-off-by: Sergey Matyukevich <sergey.matyukevich@syntacore.com>
    Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Link: https://lore.kernel.org/r/20240523084327.2013211-1-geomatsi@gmail.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

riscv: stacktrace: fixed walk_stackframe() [+ + +]
Author: Matthew Bystrin <dev.mbstr@gmail.com>
Date:   Tue May 21 22:13:13 2024 +0300

    riscv: stacktrace: fixed walk_stackframe()
    
    commit a2a4d4a6a0bf5eba66f8b0b32502cc20d82715a0 upstream.
    
    If the load access fault occures in a leaf function (with
    CONFIG_FRAME_POINTER=y), when wrong stack trace will be displayed:
    
    [<ffffffff804853c2>] regmap_mmio_read32le+0xe/0x1c
    ---[ end trace 0000000000000000 ]---
    
    Registers dump:
        ra     0xffffffff80485758 <regmap_mmio_read+36>
        sp     0xffffffc80200b9a0
        fp     0xffffffc80200b9b0
        pc     0xffffffff804853ba <regmap_mmio_read32le+6>
    
    Stack dump:
        0xffffffc80200b9a0:  0xffffffc80200b9e0  0xffffffc80200b9e0
        0xffffffc80200b9b0:  0xffffffff8116d7e8  0x0000000000000100
        0xffffffc80200b9c0:  0xffffffd8055b9400  0xffffffd8055b9400
        0xffffffc80200b9d0:  0xffffffc80200b9f0  0xffffffff8047c526
        0xffffffc80200b9e0:  0xffffffc80200ba30  0xffffffff8047fe9a
    
    The assembler dump of the function preambula:
        add     sp,sp,-16
        sd      s0,8(sp)
        add     s0,sp,16
    
    In the fist stack frame, where ra is not stored on the stack we can
    observe:
    
            0(sp)                  8(sp)
            .---------------------------------------------.
        sp->|       frame->fp      | frame->ra (saved fp) |
            |---------------------------------------------|
        fp->|         ....         |         ....         |
            |---------------------------------------------|
            |                      |                      |
    
    and in the code check is performed:
            if (regs && (regs->epc == pc) && (frame->fp & 0x7))
    
    I see no reason to check frame->fp value at all, because it is can be
    uninitialized value on the stack. A better way is to check frame->ra to
    be an address on the stack. After the stacktrace shows as expect:
    
    [<ffffffff804853c2>] regmap_mmio_read32le+0xe/0x1c
    [<ffffffff80485758>] regmap_mmio_read+0x24/0x52
    [<ffffffff8047c526>] _regmap_bus_reg_read+0x1a/0x22
    [<ffffffff8047fe9a>] _regmap_read+0x5c/0xea
    [<ffffffff80480376>] _regmap_update_bits+0x76/0xc0
    ...
    ---[ end trace 0000000000000000 ]---
    As pointed by Samuel Holland it is incorrect to remove check of the stackframe
    entirely.
    
    Changes since v2 [2]:
     - Add accidentally forgotten curly brace
    
    Changes since v1 [1]:
     - Instead of just dropping frame->fp check, replace it with validation of
       frame->ra, which should be a stack address.
     - Move frame pointer validation into the separate function.
    
    [1] https://lore.kernel.org/linux-riscv/20240426072701.6463-1-dev.mbstr@gmail.com/
    [2] https://lore.kernel.org/linux-riscv/20240521131314.48895-1-dev.mbstr@gmail.com/
    
    Fixes: f766f77a74f5 ("riscv/stacktrace: Fix stack output without ra on the stack top")
    Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
    Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
    Link: https://lore.kernel.org/r/20240521191727.62012-1-dev.mbstr@gmail.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rpcrdma: fix handling for RDMA_CM_EVENT_DEVICE_REMOVAL [+ + +]
Author: Dan Aloni <dan.aloni@vastdata.com>
Date:   Mon May 6 12:37:59 2024 +0300

    rpcrdma: fix handling for RDMA_CM_EVENT_DEVICE_REMOVAL
    
    [ Upstream commit 4836da219781ec510c4c0303df901aa643507a7a ]
    
    Under the scenario of IB device bonding, when bringing down one of the
    ports, or all ports, we saw xprtrdma entering a non-recoverable state
    where it is not even possible to complete the disconnect and shut it
    down the mount, requiring a reboot. Following debug, we saw that
    transport connect never ended after receiving the
    RDMA_CM_EVENT_DEVICE_REMOVAL callback.
    
    The DEVICE_REMOVAL callback is irrespective of whether the CM_ID is
    connected, and ESTABLISHED may not have happened. So need to work with
    each of these states accordingly.
    
    Fixes: 2acc5cae2923 ('xprtrdma: Prevent dereferencing r_xprt->rx_ep after it is freed')
    Cc: Sagi Grimberg <sagi.grimberg@vastdata.com>
    Signed-off-by: Dan Aloni <dan.aloni@vastdata.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rv: Update rv_en(dis)able_monitor doc to match kernel-doc [+ + +]
Author: Yang Li <yang.lee@linux.alibaba.com>
Date:   Mon May 20 13:42:39 2024 +0800

    rv: Update rv_en(dis)able_monitor doc to match kernel-doc
    
    [ Upstream commit 1e8b7b3dbb3103d577a586ca72bc329f7b67120b ]
    
    The patch updates the function documentation comment for
    rv_en(dis)able_monitor to adhere to the kernel-doc specification.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240520054239.61784-1-yang.lee@linux.alibaba.com
    
    Fixes: 102227b970a15 ("rv: Add Runtime Verification (RV) interface")
    Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/boot: Remove alt_stfle_fac_list from decompressor [+ + +]
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Wed May 15 09:20:27 2024 +0200

    s390/boot: Remove alt_stfle_fac_list from decompressor
    
    [ Upstream commit e7dec0b7926f3cd493c697c4c389df77e8e8a34c ]
    
    It is nowhere used in the decompressor, therefore remove it.
    
    Fixes: 17e89e1340a3 ("s390/facilities: move stfl information from lowcore to global data")
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/bpf: Emit a barrier for BPF_FETCH instructions [+ + +]
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date:   Tue May 7 02:02:49 2024 +0200

    s390/bpf: Emit a barrier for BPF_FETCH instructions
    
    [ Upstream commit 68378982f0b21de02ac3c6a11e2420badefcb4bc ]
    
    BPF_ATOMIC_OP() macro documentation states that "BPF_ADD | BPF_FETCH"
    should be the same as atomic_fetch_add(), which is currently not the
    case on s390x: the serialization instruction "bcr 14,0" is missing.
    This applies to "and", "or" and "xor" variants too.
    
    s390x is allowed to reorder stores with subsequent fetches from
    different addresses, so code relying on BPF_FETCH acting as a barrier,
    for example:
    
      stw [%r0], 1
      afadd [%r1], %r2
      ldxw %r3, [%r4]
    
    may be broken. Fix it by emitting "bcr 14,0".
    
    Note that a separate serialization instruction is not needed for
    BPF_XCHG and BPF_CMPXCHG, because COMPARE AND SWAP performs
    serialization itself.
    
    Fixes: ba3b86b9cef0 ("s390/bpf: Implement new atomic ops")
    Reported-by: Puranjay Mohan <puranjay12@gmail.com>
    Closes: https://lore.kernel.org/bpf/mb61p34qvq3wf.fsf@kernel.org/
    Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
    Reviewed-by: Puranjay Mohan <puranjay@kernel.org>
    Link: https://lore.kernel.org/r/20240507000557.12048-1-iii@linux.ibm.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/cio: fix tracepoint subchannel type field [+ + +]
Author: Peter Oberparleiter <oberpar@linux.ibm.com>
Date:   Tue Mar 26 17:04:56 2024 +0100

    s390/cio: fix tracepoint subchannel type field
    
    [ Upstream commit 8692a24d0fae19f674d51726d179ad04ba95d958 ]
    
    The subchannel-type field "st" of s390_cio_stsch and s390_cio_msch
    tracepoints is incorrectly filled with the subchannel-enabled SCHIB
    value "ena". Fix this by assigning the correct value.
    
    Fixes: d1de8633d96a ("s390 cio: Rewrite trace point class s390_class_schib")
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/ipl: Fix incorrect initialization of len fields in nvme reipl block [+ + +]
Author: Alexander Egorenkov <egorenar@linux.ibm.com>
Date:   Fri May 10 12:41:25 2024 +0200

    s390/ipl: Fix incorrect initialization of len fields in nvme reipl block
    
    [ Upstream commit 9c922b73acaf39f867668d9cbe5dc69c23511f84 ]
    
    Use correct symbolic constants IPL_BP_NVME_LEN and IPL_BP0_NVME_LEN
    to initialize nvme reipl block when 'scp_data' sysfs attribute is
    being updated. This bug had not been detected before because
    the corresponding fcp and nvme symbolic constants are equal.
    
    Fixes: 23a457b8d57d ("s390: nvme reipl")
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/ipl: Fix incorrect initialization of nvme dump block [+ + +]
Author: Alexander Egorenkov <egorenar@linux.ibm.com>
Date:   Fri May 10 12:41:26 2024 +0200

    s390/ipl: Fix incorrect initialization of nvme dump block
    
    [ Upstream commit 7faacaeaf6ce12fae78751de5ad869d8f1e1cd7a ]
    
    Initialize the correct fields of the nvme dump block.
    This bug had not been detected before because first, the fcp and nvme fields
    of struct ipl_parameter_block are part of the same union and, therefore,
    overlap in memory and second, they are identical in structure and size.
    
    Fixes: d70e38cb1dee ("s390: nvme dump support")
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/mm: Re-enable the shared zeropage for !PV and !skeys KVM guests [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Thu Apr 11 18:14:41 2024 +0200

    s390/mm: Re-enable the shared zeropage for !PV and !skeys KVM guests
    
    [ Upstream commit 06201e00ee3e4beacac48aab2b83eff64ebf0bc0 ]
    
    commit fa41ba0d08de ("s390/mm: avoid empty zero pages for KVM guests to
    avoid postcopy hangs") introduced an undesired side effect when combined
    with memory ballooning and VM migration: memory part of the inflated
    memory balloon will consume memory.
    
    Assuming we have a 100GiB VM and inflated the balloon to 40GiB. Our VM
    will consume ~60GiB of memory. If we now trigger a VM migration,
    hypervisors like QEMU will read all VM memory. As s390x does not support
    the shared zeropage, we'll end up allocating for all previously-inflated
    memory part of the memory balloon: 50 GiB. So we might easily
    (unexpectedly) crash the VM on the migration source.
    
    Even worse, hypervisors like QEMU optimize for zeropage migration to not
    consume memory on the migration destination: when migrating a
    "page full of zeroes", on the migration destination they check whether the
    target memory is already zero (by reading the destination memory) and avoid
    writing to the memory to not allocate memory: however, s390x will also
    allocate memory here, implying that also on the migration destination, we
    will end up allocating all previously-inflated memory part of the memory
    balloon.
    
    This is especially bad if actual memory overcommit was not desired, when
    memory ballooning is used for dynamic VM memory resizing, setting aside
    some memory during boot that can be added later on demand. Alternatives
    like virtio-mem that would avoid this issue are not yet available on
    s390x.
    
    There could be ways to optimize some cases in user space: before reading
    memory in an anonymous private mapping on the migration source, check via
    /proc/self/pagemap if anything is already populated. Similarly check on
    the migration destination before reading. While that would avoid
    populating tables full of shared zeropages on all architectures, it's
    harder to get right and performant, and requires user space changes.
    
    Further, with posctopy live migration we must place a page, so there,
    "avoid touching memory to avoid allocating memory" is not really
    possible. (Note that a previously we would have falsely inserted
    shared zeropages into processes using UFFDIO_ZEROPAGE where
    mm_forbids_zeropage() would have actually forbidden it)
    
    PV is currently incompatible with memory ballooning, and in the common
    case, KVM guests don't make use of storage keys. Instead of zapping
    zeropages when enabling storage keys / PV, that turned out to be
    problematic in the past, let's do exactly the same we do with KSM pages:
    trigger unsharing faults to replace the shared zeropages by proper
    anonymous folios.
    
    What about added latency when enabling storage kes? Having a lot of
    zeropages in applicable environments (PV, legacy guests, unittests) is
    unexpected. Further, KSM could today already unshare the zeropages
    and unmerging KSM pages when enabling storage kets would unshare the
    KSM-placed zeropages in the same way, resulting in the same latency.
    
    [ agordeev: Fixed sparse and checkpatch complaints and error handling ]
    
    Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Tested-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Fixes: fa41ba0d08de ("s390/mm: avoid empty zero pages for KVM guests to avoid postcopy hangs")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Link: https://lore.kernel.org/r/20240411161441.910170-3-david@redhat.com
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/vdso64: filter out munaligned-symbols flag for vdso [+ + +]
Author: Sumanth Korikkar <sumanthk@linux.ibm.com>
Date:   Mon Feb 19 14:27:31 2024 +0100

    s390/vdso64: filter out munaligned-symbols flag for vdso
    
    [ Upstream commit 8192a1b3807510d0ed5be1f8988c08f8d41cced9 ]
    
    Gcc recently implemented an optimization [1] for loading symbols without
    explicit alignment, aligning with the IBM Z ELF ABI. This ABI mandates
    symbols to reside on a 2-byte boundary, enabling the use of the larl
    instruction. However, kernel linker scripts may still generate unaligned
    symbols. To address this, a new -munaligned-symbols option has been
    introduced [2] in recent gcc versions.
    
    [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622872.html
    [2] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/625986.html
    
    However, when -munaligned-symbols  is used in vdso code, it leads to the
    following compilation error:
    `.data.rel.ro.local' referenced in section `.text' of
    arch/s390/kernel/vdso64/vdso64_generic.o: defined in discarded section
    `.data.rel.ro.local' of arch/s390/kernel/vdso64/vdso64_generic.o
    
    vdso linker script discards .data section to make it lightweight.
    However, -munaligned-symbols in vdso object files references literal
    pool and accesses _vdso_data. Hence, compile vdso code without
    -munaligned-symbols.  This means in the future, vdso code should deal
    with alignment of newly introduced unaligned linker symbols.
    
    Acked-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240219132734.22881-2-sumanthk@linux.ibm.com
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Stable-dep-of: 10f705253651 ("s390/vdso: Generate unwind information for C modules")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/vdso: Create .build-id links for unstripped vdso files [+ + +]
Author: Jens Remus <jremus@linux.ibm.com>
Date:   Mon Apr 29 17:02:53 2024 +0200

    s390/vdso: Create .build-id links for unstripped vdso files
    
    [ Upstream commit fc2f5f10f9bc5e58d38e9fda7dae107ac04a799f ]
    
    Citing Andy Lutomirski from commit dda1e95cee38 ("x86/vdso: Create
    .build-id links for unstripped vdso files"):
    
    "With this change, doing 'make vdso_install' and telling gdb:
    
    set debug-file-directory /lib/modules/KVER/vdso
    
    will enable vdso debugging with symbols.  This is useful for
    testing, but kernel RPM builds will probably want to manually delete
    these symlinks or otherwise do something sensible when they strip
    the vdso/*.so files."
    
    Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
    Signed-off-by: Jens Remus <jremus@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/vdso: Generate unwind information for C modules [+ + +]
Author: Jens Remus <jremus@linux.ibm.com>
Date:   Mon Apr 29 17:02:52 2024 +0200

    s390/vdso: Generate unwind information for C modules
    
    [ Upstream commit 10f70525365146046dddcc3d36bfaea2aee0376a ]
    
    GDB fails to unwind vDSO functions with error message "PC not saved",
    for instance when stepping through gettimeofday().
    
    Add -fasynchronous-unwind-tables to CFLAGS to generate .eh_frame
    DWARF unwind information for the vDSO C modules.
    
    Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
    Signed-off-by: Jens Remus <jremus@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

s390/vdso: Use standard stack frame layout [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Mon Apr 29 14:28:43 2024 +0200

    s390/vdso: Use standard stack frame layout
    
    [ Upstream commit 185445c7c137822ad856aae91a41e199370cb534 ]
    
    By default user space is compiled with standard stack frame layout and not
    with the packed stack layout. The vdso code however inherited the
    -mpacked-stack compiler option from the kernel. Remove this option to make
    sure the vdso is compiled with standard stack frame layout.
    
    This makes sure that the stack frame backchain location for vdso generated
    stack frames is the same like for calling code (if compiled with default
    options). This allows to manually walk stack frames without DWARF
    information, like the kernel is doing it e.g. with arch_stack_walk_user().
    
    Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
    Reviewed-by: Jens Remus <jremus@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>

 
sched/core: Fix incorrect initialization of the 'burst' parameter in cpu_max_write() [+ + +]
Author: Cheng Yu <serein.chengyu@huawei.com>
Date:   Wed Apr 24 21:24:38 2024 +0800

    sched/core: Fix incorrect initialization of the 'burst' parameter in cpu_max_write()
    
    [ Upstream commit 49217ea147df7647cb89161b805c797487783fc0 ]
    
    In the cgroup v2 CPU subsystem, assuming we have a
    cgroup named 'test', and we set cpu.max and cpu.max.burst:
    
        # echo 1000000 > /sys/fs/cgroup/test/cpu.max
        # echo 1000000 > /sys/fs/cgroup/test/cpu.max.burst
    
    then we check cpu.max and cpu.max.burst:
    
        # cat /sys/fs/cgroup/test/cpu.max
        1000000 100000
        # cat /sys/fs/cgroup/test/cpu.max.burst
        1000000
    
    Next we set cpu.max again and check cpu.max and
    cpu.max.burst:
    
        # echo 2000000 > /sys/fs/cgroup/test/cpu.max
        # cat /sys/fs/cgroup/test/cpu.max
        2000000 100000
    
        # cat /sys/fs/cgroup/test/cpu.max.burst
        1000
    
    ... we find that the cpu.max.burst value changed unexpectedly.
    
    In cpu_max_write(), the unit of the burst value returned
    by tg_get_cfs_burst() is microseconds, while in cpu_max_write(),
    the burst unit used for calculation should be nanoseconds,
    which leads to the bug.
    
    To fix it, get the burst value directly from tg->cfs_bandwidth.burst.
    
    Fixes: f4183717b370 ("sched/fair: Introduce the burstable CFS controller")
    Reported-by: Qixin Liao <liaoqixin@huawei.com>
    Signed-off-by: Cheng Yu <serein.chengyu@huawei.com>
    Signed-off-by: Zhang Qiao <zhangqiao22@huawei.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://lore.kernel.org/r/20240424132438.514720-1-serein.chengyu@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/fair: Add EAS checks before updating root_domain::overutilized [+ + +]
Author: Shrikanth Hegde <sshegde@linux.ibm.com>
Date:   Thu Mar 7 14:27:23 2024 +0530

    sched/fair: Add EAS checks before updating root_domain::overutilized
    
    [ Upstream commit be3a51e68f2f1b17250ce40d8872c7645b7a2991 ]
    
    root_domain::overutilized is only used for EAS(energy aware scheduler)
    to decide whether to do load balance or not. It is not used if EAS
    not possible.
    
    Currently enqueue_task_fair and task_tick_fair accesses, sometime updates
    this field. In update_sd_lb_stats it is updated often. This causes cache
    contention due to true sharing and burns a lot of cycles. ::overload and
    ::overutilized are part of the same cacheline. Updating it often invalidates
    the cacheline. That causes access to ::overload to slow down due to
    false sharing. Hence add EAS check before accessing/updating this field.
    EAS check is optimized at compile time or it is a static branch.
    Hence it shouldn't cost much.
    
    With the patch, both enqueue_task_fair and newidle_balance don't show
    up as hot routines in perf profile.
    
      6.8-rc4:
      7.18%  swapper          [kernel.vmlinux]              [k] enqueue_task_fair
      6.78%  s                [kernel.vmlinux]              [k] newidle_balance
    
      +patch:
      0.14%  swapper          [kernel.vmlinux]              [k] enqueue_task_fair
      0.00%  swapper          [kernel.vmlinux]              [k] newidle_balance
    
    While at it: trace_sched_overutilized_tp expect that second argument to
    be bool. So do a int to bool conversion for that.
    
    Fixes: 2802bf3cd936 ("sched/fair: Add over-utilization/tipping point indicator")
    Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Qais Yousef <qyousef@layalina.io>
    Reviewed-by: Srikar Dronamraju <srikar@linux.ibm.com>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://lore.kernel.org/r/20240307085725.444486-2-sshegde@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

sched/fair: Allow disabling sched_balance_newidle with sched_relax_domain_level [+ + +]
Author: Vitalii Bursov <vitaly@bursov.com>
Date:   Tue Apr 30 18:05:23 2024 +0300

    sched/fair: Allow disabling sched_balance_newidle with sched_relax_domain_level
    
    [ Upstream commit a1fd0b9d751f840df23ef0e75b691fc00cfd4743 ]
    
    Change relax_domain_level checks so that it would be possible
    to include or exclude all domains from newidle balancing.
    
    This matches the behavior described in the documentation:
    
      -1   no request. use system default or follow request of others.
       0   no search.
       1   search siblings (hyperthreads in a core).
    
    "2" enables levels 0 and 1, level_max excludes the last (level_max)
    level, and level_max+1 includes all levels.
    
    Fixes: 1d3504fcf560 ("sched, cpuset: customize sched domains, core")
    Signed-off-by: Vitalii Bursov <vitaly@bursov.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Reviewed-by: Valentin Schneider <vschneid@redhat.com>
    Link: https://lore.kernel.org/r/bd6de28e80073c79466ec6401cdeae78f0d4423d.1714488502.git.vitaly@bursov.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/isolation: Fix boot crash when maxcpus < first housekeeping CPU [+ + +]
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Sat Apr 13 16:17:46 2024 +0200

    sched/isolation: Fix boot crash when maxcpus < first housekeeping CPU
    
    [ Upstream commit 257bf89d84121280904800acd25cc2c444c717ae ]
    
    housekeeping_setup() checks cpumask_intersects(present, online) to ensure
    that the kernel will have at least one housekeeping CPU after smp_init(),
    but this doesn't work if the maxcpus= kernel parameter limits the number of
    processors available after bootup.
    
    For example, a kernel with "maxcpus=2 nohz_full=0-2" parameters crashes at
    boot time on a virtual machine with 4 CPUs.
    
    Change housekeeping_setup() to use cpumask_first_and() and check that the
    returned CPU number is valid and less than setup_max_cpus.
    
    Another corner case is "nohz_full=0" on a machine with a single CPU or with
    the maxcpus=1 kernel argument. In this case non_housekeeping_mask is empty
    and tick_nohz_full_setup() makes no sense. And indeed, the kernel hits the
    WARN_ON(tick_nohz_full_running) in tick_sched_do_timer().
    
    And how should the kernel interpret the "nohz_full=" parameter? It should
    be silently ignored, but currently cpulist_parse() happily returns the
    empty cpumask and this leads to the same problem.
    
    Change housekeeping_setup() to check cpumask_empty(non_housekeeping_mask)
    and do nothing in this case.
    
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Phil Auld <pauld@redhat.com>
    Acked-by: Frederic Weisbecker <frederic@kernel.org>
    Link: https://lore.kernel.org/r/20240413141746.GA10008@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: bfa: Ensure the copied buf is NUL terminated [+ + +]
Author: Bui Quang Minh <minhquangbui99@gmail.com>
Date:   Wed Apr 24 21:44:20 2024 +0700

    scsi: bfa: Ensure the copied buf is NUL terminated
    
    [ Upstream commit 13d0cecb4626fae67c00c84d3c7851f6b62f7df3 ]
    
    Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
    userspace to that buffer. Later, we use sscanf on this buffer but we don't
    ensure that the string is terminated inside the buffer, this can lead to
    OOB read when using sscanf. Fix this issue by using memdup_user_nul instead
    of memdup_user.
    
    Fixes: 9f30b674759b ("bfa: replace 2 kzalloc/copy_from_user by memdup_user")
    Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
    Link: https://lore.kernel.org/r/20240424-fix-oob-read-v2-3-f1f1b53a10f4@gmail.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: hpsa: Fix allocation size for Scsi_Host private data [+ + +]
Author: Yuri Karpov <YKarpov@ispras.ru>
Date:   Tue Mar 12 20:04:47 2024 +0300

    scsi: hpsa: Fix allocation size for Scsi_Host private data
    
    [ Upstream commit 504e2bed5d50610c1836046c0c195b0a6dba9c72 ]
    
    struct Scsi_Host private data contains pointer to struct ctlr_info.
    
    Restore allocation of only 8 bytes to store pointer in struct Scsi_Host
    private data area.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: bbbd25499100 ("scsi: hpsa: Fix allocation size for scsi_host_alloc()")
    Signed-off-by: Yuri Karpov <YKarpov@ispras.ru>
    Link: https://lore.kernel.org/r/20240312170447.743709-1-YKarpov@ispras.ru
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: libsas: Fix the failure of adding phy with zero-address to port [+ + +]
Author: Xingui Yang <yangxingui@huawei.com>
Date:   Tue Mar 12 14:11:03 2024 +0000

    scsi: libsas: Fix the failure of adding phy with zero-address to port
    
    [ Upstream commit 06036a0a5db34642c5dbe22021a767141f010b7a ]
    
    As of commit 7d1d86518118 ("[SCSI] libsas: fix false positive 'device
    attached' conditions"), reset the phy->entacted_sas_addr address to a
    zero-address when the link rate is less than 1.5G.
    
    Currently we find that when a new device is attached, and the link rate is
    less than 1.5G, but the device type is not NO_DEVICE, for example: the link
    rate is SAS_PHY_RESET_IN_PROGRESS and the device type is stp. After setting
    the phy->entacted_sas_addr address to the zero address, the port will
    continue to be created for the phy with the zero-address, and other phys
    with the zero-address will be tried to be added to the new port:
    
    [562240.051197] sas: ex 500e004aaaaaaa1f phy19:U:0 attached: 0000000000000000 (no device)
    // phy19 is deleted but still on the parent port's phy_list
    [562240.062536] sas: ex 500e004aaaaaaa1f phy0 new device attached
    [562240.062616] sas: ex 500e004aaaaaaa1f phy00:U:5 attached: 0000000000000000 (stp)
    [562240.062680] port-7:7:0: trying to add phy phy-7:7:19 fails: it's already part of another port
    
    Therefore, it should be the same as sas_get_phy_attached_dev(). Only when
    device_type is SAS_PHY_UNUSED, sas_address is set to the 0 address.
    
    Fixes: 7d1d86518118 ("[SCSI] libsas: fix false positive 'device attached' conditions")
    Signed-off-by: Xingui Yang <yangxingui@huawei.com>
    Link: https://lore.kernel.org/r/20240312141103.31358-5-yangxingui@huawei.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qedf: Ensure the copied buf is NUL terminated [+ + +]
Author: Bui Quang Minh <minhquangbui99@gmail.com>
Date:   Wed Apr 24 21:44:21 2024 +0700

    scsi: qedf: Ensure the copied buf is NUL terminated
    
    [ Upstream commit d0184a375ee797eb657d74861ba0935b6e405c62 ]
    
    Currently, we allocate a count-sized kernel buffer and copy count from
    userspace to that buffer. Later, we use kstrtouint on this buffer but we
    don't ensure that the string is terminated inside the buffer, this can
    lead to OOB read when using kstrtouint. Fix this issue by using
    memdup_user_nul instead of memdup_user.
    
    Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.")
    Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
    Link: https://lore.kernel.org/r/20240424-fix-oob-read-v2-4-f1f1b53a10f4@gmail.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: Fix debugfs output for fw_resource_count [+ + +]
Author: Himanshu Madhani <himanshu.madhani@oracle.com>
Date:   Fri Apr 26 02:00:56 2024 +0000

    scsi: qla2xxx: Fix debugfs output for fw_resource_count
    
    [ Upstream commit 998d09c5ef6183bd8137d1a892ba255b15978bb4 ]
    
    DebugFS output for fw_resource_count shows:
    
    estimate exchange used[0] high water limit [1945] n        estimate iocb2 used [0] high water limit [5141]
            estimate exchange2 used[0] high water limit [1945]
    
    Which shows incorrect display due to missing newline in seq_print().
    
    [mkp: fix checkpatch warning about space before newline]
    
    Fixes: 5f63a163ed2f ("scsi: qla2xxx: Fix exchange oversubscription for management commands")
    Signed-off-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Link: https://lore.kernel.org/r/20240426020056.3639406-1-himanshu.madhani@oracle.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: cdns-pltfrm: Perform read back after writing HCLKDIV [+ + +]
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Fri Mar 29 15:46:48 2024 -0500

    scsi: ufs: cdns-pltfrm: Perform read back after writing HCLKDIV
    
    [ Upstream commit b715c55daf598aac8fa339048e4ca8a0916b332e ]
    
    Currently, HCLKDIV is written to and then completed with an mb().
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring this
    bit has taken effect on the device is to perform a read back to force it to
    make it all the way to the device. This is documented in device-io.rst and
    a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bit hits the device. Because the mb()'s purpose
    wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Fixes: d90996dae8e4 ("scsi: ufs: Add UFS platform driver for Cadence UFS")
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-6-181252004586@redhat.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: core: mcq: Fix ufshcd_mcq_sqe_search() [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Tue Apr 9 17:07:45 2024 -0700

    scsi: ufs: core: mcq: Fix ufshcd_mcq_sqe_search()
    
    [ Upstream commit 3c5d0dce8ce0a2781ac306b9ad1492b005ecbab5 ]
    
    Fix the calculation of the utrd pointer. This patch addresses the following
    Coverity complaint:
    
    CID 1538170: (#1 of 1): Extra sizeof expression (SIZEOF_MISMATCH)
    suspicious_pointer_arithmetic: Adding sq_head_slot * 32UL /* sizeof (struct
    utp_transfer_req_desc) */ to pointer hwq->sqe_base_addr of type struct
    utp_transfer_req_desc * is suspicious because adding an integral value to
    this pointer automatically scales that value by the size, 32 bytes, of the
    pointed-to type, struct utp_transfer_req_desc. Most likely, the
    multiplication by sizeof (struct utp_transfer_req_desc) in this expression
    is extraneous and should be eliminated.
    
    Cc: Bao D. Nguyen <quic_nguyenb@quicinc.com>
    Cc: Stanley Chu <stanley.chu@mediatek.com>
    Cc: Can Guo <quic_cang@quicinc.com>
    Fixes: 8d7290348992 ("scsi: ufs: mcq: Add supporting functions for MCQ abort")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20240410000751.1047758-1-bvanassche@acm.org
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: core: Perform read back after disabling interrupts [+ + +]
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Fri Mar 29 15:46:50 2024 -0500

    scsi: ufs: core: Perform read back after disabling interrupts
    
    [ Upstream commit e4a628877119bd40164a651d20321247b6f94a8b ]
    
    Currently, interrupts are cleared and disabled prior to registering the
    interrupt. An mb() is used to complete the clear/disable writes before the
    interrupt is registered.
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring these
    bits have taken effect on the device is to perform a read back to force it
    to make it all the way to the device. This is documented in device-io.rst
    and a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure these bits hit the device. Because the mb()'s
    purpose wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Fixes: 199ef13cac7d ("scsi: ufs: avoid spurious UFS host controller interrupts")
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-8-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: core: Perform read back after disabling UIC_COMMAND_COMPL [+ + +]
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Fri Mar 29 15:46:51 2024 -0500

    scsi: ufs: core: Perform read back after disabling UIC_COMMAND_COMPL
    
    [ Upstream commit 4bf3855497b60765ca03b983d064b25e99b97657 ]
    
    Currently, the UIC_COMMAND_COMPL interrupt is disabled and a wmb() is used
    to complete the register write before any following writes.
    
    wmb() ensures the writes complete in that order, but completion doesn't
    mean that it isn't stored in a buffer somewhere. The recommendation for
    ensuring this bit has taken effect on the device is to perform a read back
    to force it to make it all the way to the device. This is documented in
    device-io.rst and a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bit hits the device. Because the wmb()'s
    purpose wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Fixes: d75f7fe495cf ("scsi: ufs: reduce the interrupts for power mode change requests")
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-9-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: core: Perform read back after writing UTP_TASK_REQ_LIST_BASE_H [+ + +]
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Fri Mar 29 15:46:49 2024 -0500

    scsi: ufs: core: Perform read back after writing UTP_TASK_REQ_LIST_BASE_H
    
    [ Upstream commit 408e28086f1c7a6423efc79926a43d7001902fae ]
    
    Currently, the UTP_TASK_REQ_LIST_BASE_L/UTP_TASK_REQ_LIST_BASE_H regs are
    written to and then completed with an mb().
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring these
    bits have taken effect on the device is to perform a read back to force it
    to make it all the way to the device. This is documented in device-io.rst
    and a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bits hit the device. Because the mb()'s purpose
    wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Fixes: 88441a8d355d ("scsi: ufs: core: Add hibernation callbacks")
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-7-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: qcom: Perform read back after writing CGC enable [+ + +]
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Fri Mar 29 15:46:47 2024 -0500

    scsi: ufs: qcom: Perform read back after writing CGC enable
    
    [ Upstream commit d9488511b3ac7eb48a91bc5eded7027525525e03 ]
    
    Currently, the CGC enable bit is written and then an mb() is used to ensure
    that completes before continuing.
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring this
    bit has taken effect on the device is to perform a read back to force it to
    make it all the way to the device. This is documented in device-io.rst and
    a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bit hits the device. Because the mb()'s purpose
    wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Fixes: 81c0fc51b7a7 ("ufs-qcom: add support for Qualcomm Technologies Inc platforms")
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-5-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: qcom: Perform read back after writing REG_UFS_SYS1CLK_1US [+ + +]
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Fri Mar 29 15:46:44 2024 -0500

    scsi: ufs: qcom: Perform read back after writing REG_UFS_SYS1CLK_1US
    
    [ Upstream commit a862fafa263aea0f427d51aca6ff7fd9eeaaa8bd ]
    
    Currently after writing to REG_UFS_SYS1CLK_1US a mb() is used to ensure
    that write has gone through to the device.
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring this
    bit has taken effect on the device is to perform a read back to force it to
    make it all the way to the device. This is documented in device-io.rst and
    a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bit hits the device. Because the mb()'s purpose
    wasn't to add extra ordering (on top of the ordering guaranteed by
    writel()/readl()), it can safely be removed.
    
    Fixes: f06fcc7155dc ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations")
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-2-181252004586@redhat.com
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: qcom: Perform read back after writing reset bit [+ + +]
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Fri Mar 29 15:46:43 2024 -0500

    scsi: ufs: qcom: Perform read back after writing reset bit
    
    [ Upstream commit c4d28e06b0c94636f6e35d003fa9ebac0a94e1ae ]
    
    Currently, the reset bit for the UFS provided reset controller (used by its
    phy) is written to, and then a mb() happens to try and ensure that hit the
    device. Immediately afterwards a usleep_range() occurs.
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring this
    bit has taken effect on the device is to perform a read back to force it to
    make it all the way to the device. This is documented in device-io.rst and
    a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    Let's do that to ensure the bit hits the device. By doing so and
    guaranteeing the ordering against the immediately following usleep_range(),
    the mb() can safely be removed.
    
    Fixes: 81c0fc51b7a7 ("ufs-qcom: add support for Qualcomm Technologies Inc platforms")
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Reviewed-by: Can Guo <quic_cang@quicinc.com>
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-1-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: qcom: Perform read back after writing unipro mode [+ + +]
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Fri Mar 29 15:46:46 2024 -0500

    scsi: ufs: qcom: Perform read back after writing unipro mode
    
    [ Upstream commit 823150ecf04f958213cf3bf162187cd1a91c885c ]
    
    Currently, the QUNIPRO_SEL bit is written to and then an mb() is used to
    ensure that completes before continuing.
    
    mb() ensures that the write completes, but completion doesn't mean that it
    isn't stored in a buffer somewhere. The recommendation for ensuring this
    bit has taken effect on the device is to perform a read back to force it to
    make it all the way to the device. This is documented in device-io.rst and
    a talk by Will Deacon on this can be seen over here:
    
        https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678
    
    But, there's really no reason to even ensure completion before
    continuing. The only requirement here is that this write is ordered to this
    endpoint (which readl()/writel() guarantees already). For that reason the
    mb() can be dropped altogether without anything forcing completion.
    
    Fixes: f06fcc7155dc ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations")
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-4-181252004586@redhat.com
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/binderfs: use the Makefile's rules, not Make's implicit rules [+ + +]
Author: John Hubbard <jhubbard@nvidia.com>
Date:   Thu May 2 18:58:20 2024 -0700

    selftests/binderfs: use the Makefile's rules, not Make's implicit rules
    
    [ Upstream commit 019baf635eb6ffe8d6c1343f81788f02a7e0ed98 ]
    
    First of all, in order to build with clang at all, one must first apply
    Valentin Obst's build fix for LLVM [1]. Once that is done, then when
    building with clang, via:
    
        make LLVM=1 -C tools/testing/selftests
    
    ...the following error occurs:
    
       clang: error: cannot specify -o when generating multiple output files
    
    This is because clang, unlike gcc, won't accept invocations of this
    form:
    
        clang file1.c header2.h
    
    While trying to fix this, I noticed that:
    
    a) selftests/lib.mk already avoids the problem, and
    
    b) The binderfs Makefile indavertently bypasses the selftests/lib.mk
    build system, and quitely uses Make's implicit build rules for .c files
    instead.
    
    The Makefile attempts to set up both a dependency and a source file,
    neither of which was needed, because lib.mk is able to automatically
    handle both. This line:
    
        binderfs_test: binderfs_test.c
    
    ...causes Make's implicit rules to run, which builds binderfs_test
    without ever looking at lib.mk.
    
    Fix this by simply deleting the "binderfs_test:" Makefile target and
    letting lib.mk handle it instead.
    
    [1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/
    
    Fixes: 6e29225af902 ("binderfs: port tests to test harness infrastructure")
    Cc: Christian Brauner <brauner@kernel.org>
    Signed-off-by: John Hubbard <jhubbard@nvidia.com>
    Reviewed-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/bpf: Fix a fd leak in error paths in open_netns [+ + +]
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Tue Apr 23 18:35:27 2024 +0800

    selftests/bpf: Fix a fd leak in error paths in open_netns
    
    [ Upstream commit 151f7442436658ee84076681d8f52e987fe147ea ]
    
    As Martin mentioned in review comment, there is an existing bug that
    orig_netns_fd will be leaked in the later "goto fail;" case after
    open("/proc/self/ns/net") in open_netns() in network_helpers.c. This
    patch adds "close(token->orig_netns_fd);" before "free(token);" to
    fix it.
    
    Fixes: a30338840fa5 ("selftests/bpf: Move open_netns() and close_netns() into network_helpers.c")
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Link: https://lore.kernel.org/r/a104040b47c3c34c67f3f125cdfdde244a870d3c.1713868264.git.tanggeliang@kylinos.cn
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/bpf: Fix pointer arithmetic in test_xdp_do_redirect [+ + +]
Author: Michal Schmidt <mschmidt@redhat.com>
Date:   Mon May 6 16:50:22 2024 +0200

    selftests/bpf: Fix pointer arithmetic in test_xdp_do_redirect
    
    [ Upstream commit e549b39a0ab8880d7ae6c6495b00fc1cb8f36174 ]
    
    Cast operation has a higher precedence than addition. The code here
    wants to zero the 2nd half of the 64-bit metadata, but due to a pointer
    arithmetic mistake, it writes the zero at offset 16 instead.
    
    Just adding parentheses around "data + 4" would fix this, but I think
    this will be slightly better readable with array syntax.
    
    I was unable to test this with tools/testing/selftests/bpf/vmtest.sh,
    because my glibc is newer than glibc in the provided VM image.
    So I just checked the difference in the compiled code.
    objdump -S tools/testing/selftests/bpf/xdp_do_redirect.test.o:
      -     *((__u32 *)data) = 0x42; /* metadata test value */
      +     ((__u32 *)data)[0] = 0x42; /* metadata test value */
            be7:    48 8d 85 30 fc ff ff    lea    -0x3d0(%rbp),%rax
            bee:    c7 00 42 00 00 00       movl   $0x42,(%rax)
      -     *((__u32 *)data + 4) = 0;
      +     ((__u32 *)data)[1] = 0;
            bf4:    48 8d 85 30 fc ff ff    lea    -0x3d0(%rbp),%rax
      -     bfb:    48 83 c0 10             add    $0x10,%rax
      +     bfb:    48 83 c0 04             add    $0x4,%rax
            bff:    c7 00 00 00 00 00       movl   $0x0,(%rax)
    
    Fixes: 5640b6d89434 ("selftests/bpf: fix "metadata marker" getting overwritten by the netstack")
    Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
    Link: https://lore.kernel.org/bpf/20240506145023.214248-1-mschmidt@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/bpf: Fix umount cgroup2 error in test_sockmap [+ + +]
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Tue Apr 9 13:18:40 2024 +0800

    selftests/bpf: Fix umount cgroup2 error in test_sockmap
    
    [ Upstream commit d75142dbeb2bd1587b9cc19f841578f541275a64 ]
    
    This patch fixes the following "umount cgroup2" error in test_sockmap.c:
    
     (cgroup_helpers.c:353: errno: Device or resource busy) umount cgroup2
    
    Cgroup fd cg_fd should be closed before cleanup_cgroup_environment().
    
    Fixes: 13a5f3ffd202 ("bpf: Selftests, sockmap test prog run without setting cgroup")
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Acked-by: Yonghong Song <yonghong.song@linux.dev>
    Link: https://lore.kernel.org/r/0399983bde729708773416b8488bac2cd5e022b8.1712639568.git.tanggeliang@kylinos.cn
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/ftrace: Fix BTFARG testcase to check fprobe is enabled correctly [+ + +]
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Sat May 4 09:33:10 2024 +0900

    selftests/ftrace: Fix BTFARG testcase to check fprobe is enabled correctly
    
    commit 2fd3ef1b9265eda7f53b9506f1ebfb67eb6435a2 upstream.
    
    Since the dynevent/add_remove_btfarg.tc test case forgets to ensure that
    fprobe is enabled for some structure field access tests which uses the
    fprobe, it fails if CONFIG_FPROBE=n or CONFIG_FPROBE_EVENTS=n.
    Fixes it to ensure the fprobe events are supported.
    
    Fixes: d892d3d3d885 ("selftests/ftrace: Add BTF fields access testcases")
    Cc: stable@vger.kernel.org
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests/kcmp: remove unused open mode [+ + +]
Author: Edward Liaw <edliaw@google.com>
Date:   Mon Apr 29 23:46:09 2024 +0000

    selftests/kcmp: remove unused open mode
    
    [ Upstream commit eb59a58113717df04b8a8229befd8ab1e5dbf86e ]
    
    Android bionic warns that open modes are ignored if O_CREAT or O_TMPFILE
    aren't specified.  The permissions for the file are set above:
    
            fd1 = open(kpath, O_RDWR | O_CREAT | O_TRUNC, 0644);
    
    Link: https://lkml.kernel.org/r/20240429234610.191144-1-edliaw@google.com
    Fixes: d97b46a64674 ("syscalls, x86: add __NR_kcmp syscall")
    Signed-off-by: Edward Liaw <edliaw@google.com>
    Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com>
    Cc: Eric Biederman <ebiederm@xmission.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/powerpc/dexcr: Add -no-pie to hashchk tests [+ + +]
Author: Benjamin Gray <bgray@linux.ibm.com>
Date:   Wed Apr 17 21:23:17 2024 +1000

    selftests/powerpc/dexcr: Add -no-pie to hashchk tests
    
    [ Upstream commit d7228a58d9438d6f219dc7f33eab0d1980b3bd2f ]
    
    The hashchk tests want to verify that the hash key is changed over exec.
    It does so by calculating hashes at the same address across an exec.
    This is made simpler by disabling PIE functionality, so we can
    re-execute ourselves and be using the same addresses in the child.
    
    While -fno-pie is already added, -no-pie is also required.
    
    Fixes: bdb07f35a52f ("selftests/powerpc/dexcr: Add hashst/hashchk test")
    Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240417112325.728010-2-bgray@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/resctrl: fix clang build failure: use LOCAL_HDRS [+ + +]
Author: John Hubbard <jhubbard@nvidia.com>
Date:   Thu May 2 19:17:12 2024 -0700

    selftests/resctrl: fix clang build failure: use LOCAL_HDRS
    
    [ Upstream commit d8171aa4ca72f1a67bf3c14c59441d63c1d2585f ]
    
    First of all, in order to build with clang at all, one must first apply
    Valentin Obst's build fix for LLVM [1]. Once that is done, then when
    building with clang, via:
    
        make LLVM=1 -C tools/testing/selftests
    
    ...the following error occurs:
    
       clang: error: cannot specify -o when generating multiple output files
    
    This is because clang, unlike gcc, won't accept invocations of this
    form:
    
        clang file1.c header2.h
    
    Fix this by using selftests/lib.mk facilities for tracking local header
    file dependencies: add them to LOCAL_HDRS, leaving only the .c files to
    be passed to the compiler.
    
    [1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/
    
    Fixes: 8e289f454289 ("selftests/resctrl: Add resctrl.h into build deps")
    Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: John Hubbard <jhubbard@nvidia.com>
    Acked-by: Reinette Chatre <reinette.chatre@intel.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: cgroup: skip test_cgcore_lesser_ns_open when cgroup2 mounted without nsdelegate [+ + +]
Author: Tianchen Ding <dtcccc@linux.alibaba.com>
Date:   Wed Mar 27 10:44:37 2024 +0800

    selftests: cgroup: skip test_cgcore_lesser_ns_open when cgroup2 mounted without nsdelegate
    
    [ Upstream commit 4793cb599b1bdc3d356f0374c2c99ffe890ae876 ]
    
    The test case test_cgcore_lesser_ns_open only tasks effect when cgroup2
    is mounted with "nsdelegate" mount option. If it misses this option, or
    is remounted without "nsdelegate", the test case will fail. For example,
    running bpf/test_cgroup_storage first, and then run cgroup/test_core will
    fail on test_cgcore_lesser_ns_open. Skip it if "nsdelegate" is not
    detected in cgroup2 mount options.
    
    Fixes: bf35a7879f1d ("selftests: cgroup: Test open-time cgroup namespace usage for migration checks")
    Signed-off-by: Tianchen Ding <dtcccc@linux.alibaba.com>
    Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: default to host arch for LLVM builds [+ + +]
Author: Valentin Obst <kernel@valentinobst.de>
Date:   Fri Mar 29 11:49:43 2024 +0100

    selftests: default to host arch for LLVM builds
    
    [ Upstream commit d4e6fbd245c48b272cc591d1c5e7c07aedd7f071 ]
    
    Align the behavior for gcc and clang builds by interpreting unset
    `ARCH` and `CROSS_COMPILE` variables in `LLVM` builds as a sign that the
    user wants to build for the host architecture.
    
    This patch preserves the properties that setting the `ARCH` variable to an
    unknown value will trigger an error that complains about insufficient
    information, and that a set `CROSS_COMPILE` variable will override the
    target triple that is determined based on presence/absence of `ARCH`.
    
    When compiling with clang, i.e., `LLVM` is set, an unset `ARCH` variable in
    combination with an unset `CROSS_COMPILE` variable, i.e., compiling for
    the host architecture, leads to compilation failures since `lib.mk` can
    not determine the clang target triple. In this case, the following error
    message is displayed for each subsystem that does not set `ARCH` in its
    own Makefile before including `lib.mk` (lines wrapped at 75 chrs):
    
      make[1]: Entering directory '/mnt/build/linux/tools/testing/selftests/
       sysctl'
      ../lib.mk:33: *** Specify CROSS_COMPILE or add '--target=' option to
       lib.mk.  Stop.
      make[1]: Leaving directory '/mnt/build/linux/tools/testing/selftests/
       sysctl'
    
    In the same scenario a gcc build would default to the host architecture,
    i.e., it would use plain `gcc`.
    
    Fixes: 795285ef2425 ("selftests: Fix clang cross compilation")
    Reviewed-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Valentin Obst <kernel@valentinobst.de>
    Reviewed-by: John Hubbard <jhubbard@nvidia.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: mptcp: add ms units for tc-netem delay [+ + +]
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Fri Apr 5 12:52:06 2024 +0200

    selftests: mptcp: add ms units for tc-netem delay
    
    [ Upstream commit 9109853a388b7b2b934f56f4ddb250d72e486555 ]
    
    'delay 1' in tc-netem is confusing, not sure if it's a delay of 1 second or
    1 millisecond. This patch explicitly adds millisecond units to make these
    commands clearer.
    
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 38af56e6668b ("selftests: mptcp: join: mark 'fail' tests as flaky")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: mptcp: join: mark 'fail' tests as flaky [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri May 24 18:30:59 2024 +0200

    selftests: mptcp: join: mark 'fail' tests as flaky
    
    [ Upstream commit 38af56e6668b455f7dd0a8e2d9afe74100068e17 ]
    
    These tests are rarely unstable. It depends on the CI running the tests,
    especially if it is also busy doing other tasks in parallel, and if a
    debug kernel config is being used.
    
    It looks like this issue is sometimes present with the NetDev CI. While
    this is being investigated, the tests are marked as flaky not to create
    noises on such CIs.
    
    Fixes: b6e074e171bc ("selftests: mptcp: add infinite map testcase")
    Link: https://github.com/multipath-tcp/mptcp_net-next/issues/491
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240524-upstream-net-20240524-selftests-mptcp-flaky-v1-4-a352362f3f8e@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: mptcp: simult flows: mark 'unbalanced' tests as flaky [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Fri May 24 18:30:57 2024 +0200

    selftests: mptcp: simult flows: mark 'unbalanced' tests as flaky
    
    [ Upstream commit cc73a6577ae64247898269d138dee6b73ff710cc ]
    
    These tests are flaky since their introduction. This might be less or
    not visible depending on the CI running the tests, especially if it is
    also busy doing other tasks in parallel.
    
    A first analysis shown that the transfer can be slowed down when there
    are some re-injections at the MPTCP level. Such re-injections can of
    course happen, and disturb the transfer, but it looks strange to have
    them in this lab. That could be caused by the kernel having access to
    less CPU cycles -- e.g. when other activities are executed in parallel
    -- or by a misinterpretation on the MPTCP packet scheduler side.
    
    While this is being investigated, the tests are marked as flaky not to
    create noises in other CIs.
    
    Fixes: 219d04992b68 ("mptcp: push pending frames when subflow has free space")
    Link: https://github.com/multipath-tcp/mptcp_net-next/issues/475
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240524-upstream-net-20240524-selftests-mptcp-flaky-v1-2-a352362f3f8e@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: add missing config for amt.sh [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu May 9 09:19:19 2024 -0700

    selftests: net: add missing config for amt.sh
    
    [ Upstream commit c499fe96d3f75a5cf50de6089dd8f1cddd1301a9 ]
    
    Test needs IPv6 multicast. smcroute currently crashes when trying
    to install a route in a kernel without IPv6 multicast.
    
    Fixes: c08e8baea78e ("selftests: add amt interface selftest script")
    Link: https://lore.kernel.org/r/20240509161919.3939966-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: add more missing kernel config [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Wed Feb 7 18:31:10 2024 +0100

    selftests: net: add more missing kernel config
    
    [ Upstream commit 02d9009f4e8c27dcf10c3e39bc0666436686a219 ]
    
    The reuseport_addr_any.sh is currently skipping DCCP tests and
    pmtu.sh is skipping all the FOU/GUE related cases: add the missing
    options.
    
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/38d3ca7f909736c1aef56e6244d67c82a9bba6ff.1707326987.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: c499fe96d3f7 ("selftests: net: add missing config for amt.sh")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: bridge: increase IGMP/MLD exclude timeout membership interval [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Mon May 13 13:52:57 2024 +0300

    selftests: net: bridge: increase IGMP/MLD exclude timeout membership interval
    
    [ Upstream commit 06080ea23095afe04a2cb7a8d05fab4311782623 ]
    
    When running the bridge IGMP/MLD selftests on debug kernels we can get
    spurious errors when setting up the IGMP/MLD exclude timeout tests
    because the membership interval is just 3 seconds and the setup has 2
    seconds of sleep plus various validations, the one second that is left
    is not enough. Increase the membership interval from 3 to 5 seconds to
    make room for the setup validation and 2 seconds of sleep.
    
    Fixes: 34d7ecb3d4f7 ("selftests: net: bridge: update IGMP/MLD membership interval value")
    Reported-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: kill smcrouted in the cleanup logic in amt.sh [+ + +]
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Sat May 18 13:20:52 2024 +0000

    selftests: net: kill smcrouted in the cleanup logic in amt.sh
    
    [ Upstream commit cc563e749810f5636451d4b833fbd689899ecdb9 ]
    
    The amt.sh requires smcrouted for multicasting routing.
    So, it starts smcrouted before forwarding tests.
    It must be stopped after all tests, but it isn't.
    
    To fix this issue, it kills smcrouted in the cleanup logic.
    
    Fixes: c08e8baea78e ("selftests: add amt interface selftest script")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: net: move amt to socat for better compatibility [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu May 9 09:19:52 2024 -0700

    selftests: net: move amt to socat for better compatibility
    
    [ Upstream commit 4c639b6a7b9db236c0907aca8e92d1537076f2cd ]
    
    The test seems to expect that nc will exit after the first
    received message. This is not the case with Ncat 7.94.
    There are multiple versions of nc out there, switch
    to socat for better compatibility.
    
    Tell socat to exit after 128 bytes and pad the message.
    
    Since the test sets -e make sure we don't set exit code
    (|| true) and print the pass / fail rather then silently
    moving over the test and just setting non-zero exit code
    with no output indicating what failed.
    
    Fixes: c08e8baea78e ("selftests: add amt interface selftest script")
    Acked-by: Paolo Abeni<pabeni@redhat.com>
    Tested-by: Taehee Yoo <ap420073@gmail.com>
    Link: https://lore.kernel.org/r/20240509161952.3940476-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests: sud_test: return correct emulated syscall value on RISC-V [+ + +]
Author: Clément Léger <cleger@rivosinc.com>
Date:   Wed Dec 6 14:44:37 2023 +0100

    selftests: sud_test: return correct emulated syscall value on RISC-V
    
    [ Upstream commit 17c67ed752d6a456602b3dbb25c5ae4d3de5deab ]
    
    Currently, the sud_test expects the emulated syscall to return the
    emulated syscall number. This assumption only works on architectures
    were the syscall calling convention use the same register for syscall
    number/syscall return value. This is not the case for RISC-V and thus
    the return value must be also emulated using the provided ucontext.
    
    Signed-off-by: Clément Léger <cleger@rivosinc.com>
    Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
    Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
    Link: https://lore.kernel.org/r/20231206134438.473166-1-cleger@rivosinc.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: 8250_bcm7271: use default_mux_rate if possible [+ + +]
Author: Doug Berger <opendmb@gmail.com>
Date:   Wed Apr 24 15:25:59 2024 -0700

    serial: 8250_bcm7271: use default_mux_rate if possible
    
    commit 614a19b89ca43449196a8af1afac7d55c6781687 upstream.
    
    There is a scenario when resuming from some power saving states
    with no_console_suspend where console output can be generated
    before the 8250_bcm7271 driver gets the opportunity to restore
    the baud_mux_clk frequency. Since the baud_mux_clk is at its
    default frequency at this time the output can be garbled until
    the driver gets the opportunity to resume.
    
    Since this is only an issue with console use of the serial port
    during that window and the console isn't likely to use baud
    rates that require alternate baud_mux_clk frequencies, allow the
    driver to select the default_mux_rate if it is accurate enough.
    
    Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver")
    Cc: stable@vger.kernel.org
    Signed-off-by: Doug Berger <opendmb@gmail.com>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Link: https://lore.kernel.org/r/20240424222559.1844045-1-opendmb@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8520_mtk: Set RTS on shutdown for Rx in-band wakeup [+ + +]
Author: Pin-yen Lin <treapking@chromium.org>
Date:   Wed Apr 24 20:58:08 2024 +0800

    serial: 8520_mtk: Set RTS on shutdown for Rx in-band wakeup
    
    commit 4244f830a56058ee0670d80e7ac9fd7c982eb480 upstream.
    
    When Rx in-band wakeup is enabled, set RTS to true in mtk8250_shutdown()
    so the connected device can still send message and trigger IRQ when the
    system is suspended.
    
    Fixes: 18c9d4a3c249 ("serial: When UART is suspended, set RTS to false")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Pin-yen Lin <treapking@chromium.org>
    Link: https://lore.kernel.org/r/20240424130619.2924456-1-treapking@chromium.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: max3100: Fix bitwise types [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Apr 2 22:50:30 2024 +0300

    serial: max3100: Fix bitwise types
    
    [ Upstream commit e60955dbecb97f080848a57524827e2db29c70fd ]
    
    Sparse is not happy about misuse of bitwise types:
    
      .../max3100.c:194:13: warning: incorrect type in assignment (different base types)
      .../max3100.c:194:13:    expected unsigned short [addressable] [usertype] etx
      .../max3100.c:194:13:    got restricted __be16 [usertype]
      .../max3100.c:202:15: warning: cast to restricted __be16
    
    Fix this by choosing proper