Changelog in Linux kernel 5.15.161

 
ACPI: disable -Wstringop-truncation [+ + +]
Author: Arnd Bergmann <[email protected]>
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 <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: resource: Do IRQ override on TongFang GXxHRXx and GMxHGxx [+ + +]
Author: Christoffer Sandberg <[email protected]>
Date:   Mon Apr 22 10:04:36 2024 +0200

    ACPI: resource: Do IRQ override on TongFang GXxHRXx and GMxHGxx
    
    commit c81bf14f9db68311c2e75428eea070d97d603975 upstream.
    
    Listed devices need the override for the keyboard to work.
    
    Signed-off-by: Christoffer Sandberg <[email protected]>
    Signed-off-by: Werner Sembach <[email protected]>
    Cc: All applicable <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
af_packet: do not call packet_read_pending() from tpacket_destruct_skb() [+ + +]
Author: Eric Dumazet <[email protected]>
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 <[email protected]>
    Cc: Neil Horman <[email protected]>
    Cc: Daniel Borkmann <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg [+ + +]
Author: Breno Leitao <[email protected]>
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/[email protected]/
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Breno Leitao <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

af_unix: Update unix_sk(sk)->oob_skb under sk_receive_queue lock. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
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/[email protected]/ [1]
    Fixes: 1279f9d9dec2 ("af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.")
    Reported-by: Billy Jheng Bing-Jhong <[email protected]>
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
afs: Don't cross .backup mountpoint from backup volume [+ + +]
Author: Marc Dionne <[email protected]>
Date:   Fri May 24 17:17:55 2024 +0100

    afs: Don't cross .backup mountpoint from backup volume
    
    commit 29be9100aca2915fab54b5693309bc42956542e5 upstream.
    
    Don't cross a mountpoint that explicitly specifies a backup volume
    (target is <vol>.backup) when starting from a backup volume.
    
    It it not uncommon to mount a volume's backup directly in the volume
    itself.  This can cause tools that are not paying attention to get
    into a loop mounting the volume onto itself as they attempt to
    traverse the tree, leading to a variety of problems.
    
    This doesn't prevent the general case of loops in a sequence of
    mountpoints, but addresses a common special case in the same way
    as other afs clients.
    
    Reported-by: Jan Henrik Sylvester <[email protected]>
    Link: http://lists.infradead.org/pipermail/linux-afs/2024-May/008454.html
    Reported-by: Markus Suvanto <[email protected]>
    Link: http://lists.infradead.org/pipermail/linux-afs/2024-February/008074.html
    Signed-off-by: Marc Dionne <[email protected]>
    Signed-off-by: David Howells <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Jeffrey Altman <[email protected]>
    cc: [email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ALSA: core: Fix NULL module pointer assignment at card init [+ + +]
Author: Takashi Iwai <[email protected]>
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 <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Tested-by: Xu Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: Fix deadlocks with kctl removals at disconnection [+ + +]
Author: Takashi Iwai <[email protected]>
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: <[email protected]>
    Reviewed-by: Jaroslav Kysela <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ALSA: timer: Set lower bound of start tick time [+ + +]
Author: Takashi Iwai <[email protected]>
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: [email protected]
    Closes: https://lore.kernel.org/r/[email protected]
    Cc: <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    [ 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 <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY [+ + +]
Author: Jiangfeng Xiao <[email protected]>
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 <[email protected]>
    Signed-off-by: Jiangfeng Xiao <[email protected]>
    Reviewed-by: Mark Rutland <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: hi3798cv200: fix the size of GICR [+ + +]
Author: Yang Xiwen <[email protected]>
Date:   Mon Feb 19 23:05:26 2024 +0800

    arm64: dts: hi3798cv200: fix the size of GICR
    
    commit 428a575dc9038846ad259466d5ba109858c0a023 upstream.
    
    During boot, Linux kernel complains:
    
    [    0.000000] GIC: GICv2 detected, but range too small and irqchip.gicv2_force_probe not set
    
    This SoC is using a regular GIC-400 and the GICR space size should be
    8KB rather than 256B.
    
    With this patch:
    
    [    0.000000] GIC: Using split EOI/Deactivate mode
    
    So this should be the correct fix.
    
    Fixes: 2f20182ed670 ("arm64: dts: hisilicon: add dts files for hi3798cv200-poplar board")
    Signed-off-by: Yang Xiwen <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: qcom: qcs404: fix bluetooth device address [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Wed May 1 09:52:01 2024 +0200

    arm64: dts: qcom: qcs404: fix bluetooth device address
    
    commit f5f390a77f18eaeb2c93211a1b7c5e66b5acd423 upstream.
    
    The 'local-bd-address' property is used to pass a unique Bluetooth
    device address from the boot firmware to the kernel and should otherwise
    be left unset so that the OS can prevent the controller from being used
    until a valid address has been provided through some other means (e.g.
    using btmgmt).
    
    Fixes: 60f77ae7d1c1 ("arm64: dts: qcom: qcs404-evb: Enable uart3 and add Bluetooth")
    Cc: [email protected]      # 5.10
    Signed-off-by: Johan Hovold <[email protected]>
    Reviewed-by: Bryan O'Donoghue <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: tegra: Correct Tegra132 I2C alias [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Apr 1 16:08:54 2024 +0200

    arm64: tegra: Correct Tegra132 I2C alias
    
    commit 2633c58e1354d7de2c8e7be8bdb6f68a0a01bad7 upstream.
    
    There is no such device as "as3722@40", because its name is "pmic".  Use
    phandles for aliases to fix relying on full node path.  This corrects
    aliases for RTC devices and also fixes dtc W=1 warning:
    
      tegra132-norrin.dts:12.3-36: Warning (alias_paths): /aliases:rtc0: aliases property is not a valid node (/i2c@7000d000/as3722@40)
    
    Fixes: 0f279ebdf3ce ("arm64: tegra: Add NVIDIA Tegra132 Norrin support")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Jon Hunter <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ASoC: da7219-aad: fix usage of device_get_named_child_node() [+ + +]
Author: Pierre-Louis Bossart <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: dt-bindings: rt5645: add cbj sleeve gpio property [+ + +]
Author: Derek Fang <[email protected]>
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 <[email protected]>
    
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: Intel: Disable route checks for Skylake boards [+ + +]
Author: Cezary Rojewski <[email protected]>
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/[email protected]/
    Fixes: daa480bde6b3 ("ASoC: soc-core: tidyup for snd_soc_dapm_add_routes()")
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Reviewed-by: Pierre-Louis Bossart <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: kirkwood: Fix potential NULL dereference [+ + +]
Author: Aleksandr Mishin <[email protected]>
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 <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: mediatek: mt8192: fix register configuration for tdm [+ + +]
Author: Hsin-Te Yuan <[email protected]>
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 <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Chen-Yu Tsai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt5645: Fix the electric noise due to the CBJ contacts floating [+ + +]
Author: Derek Fang <[email protected]>
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 <[email protected]>
    
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt715-sdca: volume step modification [+ + +]
Author: Jack Yu <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt715: add vendor clear control register [+ + +]
Author: Jack Yu <[email protected]>
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 <[email protected]>
    Closes: https://github.com/thesofproject/linux/issues/4860
    Tested-by: Pierre-Louis Bossart <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: tas2552: Add TX path for capturing AUDIO-OUT data [+ + +]
Author: Shenghao Ding <[email protected]>
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 <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: tracing: Export SND_SOC_DAPM_DIR_OUT to its value [+ + +]
Author: Steven Rostedt <[email protected]>
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 <[email protected]>
    Fixes: 6e588a0d839b5 ("ASoC: dapm: Consolidate path trace events")
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ata: pata_legacy: make legacy_exit() work again [+ + +]
Author: Sergey Shtylyov <[email protected]>
Date:   Sat May 4 23:27:25 2024 +0300

    ata: pata_legacy: make legacy_exit() work again
    
    commit d4a89339f17c87c4990070e9116462d16e75894f upstream.
    
    Commit defc9cd826e4 ("pata_legacy: resychronize with upstream changes and
    resubmit") missed to update legacy_exit(), so that it now fails to do any
    cleanup -- the loop body there can never be entered.  Fix that and finally
    remove now useless nr_legacy_host variable...
    
    Found by Linux Verification Center (linuxtesting.org) with the Svace static
    analysis tool.
    
    Fixes: defc9cd826e4 ("pata_legacy: resychronize with upstream changes and resubmit")
    Cc: [email protected]
    Signed-off-by: Sergey Shtylyov <[email protected]>
    Reviewed-by: Niklas Cassel <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
bpf: Allow delete from sockmap/sockhash only if update is allowed [+ + +]
Author: Jakub Sitnicki <[email protected]>
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 <[email protected]>
    Reported-by: [email protected]
    Signed-off-by: Jakub Sitnicki <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Tested-by: [email protected]
    Acked-by: John Fastabend <[email protected]>
    Closes: https://syzkaller.appspot.com/bug?extid=ec941d6e24f633a59172
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix potential integer overflow in resolve_btfids [+ + +]
Author: Friedrich Vock <[email protected]>
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 <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Pack struct bpf_fib_lookup [+ + +]
Author: Anton Protopopov <[email protected]>
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 <[email protected]>
    Fixes: e1850ea9bd9e ("bpf: bpf_fib_lookup return MTU value as output when looked up")
    Signed-off-by: Anton Protopopov <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Reviewed-by: Alexander Lobakin <[email protected]>
    Acked-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
clk: qcom: mmcc-msm8998: fix venus clock issue [+ + +]
Author: Marc Gonzalez <[email protected]>
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 <[email protected]>
    Signed-off-by: Marc Gonzalez <[email protected]>
    Reviewed-by: Jeffrey Hugo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight: etm4x: Cleanup TRCIDR0 register accesses [+ + +]
Author: James Clark <[email protected]>
Date:   Fri Mar 4 17:18:58 2022 +0000

    coresight: etm4x: Cleanup TRCIDR0 register accesses
    
    [ Upstream commit e601cc9a3a9b94b48de7f120b583d94c2d9fe3b5 ]
    
    This is a no-op change for style and consistency and has no effect on
    the binary output by the compiler. In sysreg.h fields are defined as
    the register name followed by the field name and then _MASK. This
    allows for grepping for fields by name rather than using magic numbers.
    
    Signed-off-by: James Clark <[email protected]>
    Reviewed-by: Mike Leach <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Stable-dep-of: 46bf8d7cd853 ("coresight: etm4x: Safe access for TRCQCLTR")
    Signed-off-by: Sasha Levin <[email protected]>

coresight: etm4x: Do not hardcode IOMEM access for register restore [+ + +]
Author: Suzuki K Poulose <[email protected]>
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 <[email protected]>
    Reviewed-by: Mike Leach <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Tested-by: Yabin Cui <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: etm4x: Do not save/restore Data trace control registers [+ + +]
Author: Suzuki K Poulose <[email protected]>
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 <[email protected]>
    Reviewed-by: Mike Leach <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Tested-by: Yabin Cui <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: etm4x: Fix access to resource selector registers [+ + +]
Author: Suzuki K Poulose <[email protected]>
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 <[email protected]>
    Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states")
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Tested-by: Yabin Cui <[email protected]>
    Reviewed-by: Mike Leach <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: etm4x: Fix unbalanced pm_runtime_enable() [+ + +]
Author: Anshuman Khandual <[email protected]>
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 <[email protected]>
    Cc: Hanjun Guo <[email protected]>
    Cc: Sudeep Holla <[email protected]>
    Cc: "Rafael J. Wysocki" <[email protected]>
    Cc: Len Brown <[email protected]>
    Cc: Suzuki K Poulose <[email protected]>
    Cc: Mike Leach <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Leo Yan <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Fixes: 5214b563588e ("coresight: etm4x: Add support for sysreg only devices")
    Reviewed-by: James Clark <[email protected]>
    Signed-off-by: Anshuman Khandual <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: etm4x: Safe access for TRCQCLTR [+ + +]
Author: Suzuki K Poulose <[email protected]>
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 <[email protected]>
    Reviewed-by: Mike Leach <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Tested-by: Yabin Cui <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

coresight: no-op refactor to make INSTP0 check more idiomatic [+ + +]
Author: James Clark <[email protected]>
Date:   Thu Feb 3 11:53:35 2022 +0000

    coresight: no-op refactor to make INSTP0 check more idiomatic
    
    [ Upstream commit d05bbad0130ff86b802e5cd6acbb6cac23b841b8 ]
    
    The spec says this:
    
      P0 tracing support field. The permitted values are:
          0b00  Tracing of load and store instructions as P0 elements is not
                supported.
          0b11  Tracing of load and store instructions as P0 elements is
                supported, so TRCCONFIGR.INSTP0 is supported.
    
                All other values are reserved.
    
    The value we are looking for is 0b11 so simplify this. The double read
    and && was a bit obfuscated.
    
    Suggested-by: Suzuki Poulose <[email protected]>
    Signed-off-by: James Clark <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Stable-dep-of: 46bf8d7cd853 ("coresight: etm4x: Safe access for TRCQCLTR")
    Signed-off-by: Sasha Levin <[email protected]>

 
cppc_cpufreq: Fix possible null pointer dereference [+ + +]
Author: Aleksandr Mishin <[email protected]>
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 <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cpufreq: exit() callback is optional [+ + +]
Author: Viresh Kumar <[email protected]>
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 <[email protected]>
    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 <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: Rearrange locking in cpufreq_remove_dev() [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Wed May 11 17:51:39 2022 +0200

    cpufreq: Rearrange locking in cpufreq_remove_dev()
    
    [ Upstream commit f339f3541701d824a0256ad4bf14c26ceb6d79c3 ]
    
    Currently, cpufreq_remove_dev() invokes the ->exit() driver callback
    without holding the policy rwsem which is inconsistent with what
    happens if ->exit() is invoked directly from cpufreq_offline().
    
    It also manipulates the real_cpus mask and removes the CPU device
    symlink without holding the policy rwsem, but cpufreq_offline() holds
    the rwsem around the modifications thereof.
    
    For consistency, modify cpufreq_remove_dev() to hold the policy rwsem
    until the ->exit() callback has been called (or it has been determined
    that it is not necessary to call it).
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Stable-dep-of: b8f85833c057 ("cpufreq: exit() callback is optional")
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: Reorganize checks in cpufreq_offline() [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Wed May 11 17:48:41 2022 +0200

    cpufreq: Reorganize checks in cpufreq_offline()
    
    [ Upstream commit e1e962c5b9edbc628a335bcdbd010331a12d3e5b ]
    
    Notice that cpufreq_offline() only needs to check policy_is_inactive()
    once and rearrange the code in there to make that happen.
    
    No expected functional impact.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Stable-dep-of: b8f85833c057 ("cpufreq: exit() callback is optional")
    Signed-off-by: Sasha Levin <[email protected]>

cpufreq: Split cpufreq_offline() [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Wed May 11 17:50:09 2022 +0200

    cpufreq: Split cpufreq_offline()
    
    [ Upstream commit fddd8f86dff4a24742a7f0322ccbb34c6c1c9850 ]
    
    Split the "core" part running under the policy rwsem out of
    cpufreq_offline() to allow the locking in cpufreq_remove_dev() to be
    rearranged more easily.
    
    As a side-effect this eliminates the unlock label that's not needed
    any more.
    
    No expected functional impact.
    
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Acked-by: Viresh Kumar <[email protected]>
    Stable-dep-of: b8f85833c057 ("cpufreq: exit() callback is optional")
    Signed-off-by: Sasha Levin <[email protected]>

 
crypto: bcm - Fix pointer arithmetic [+ + +]
Author: Aleksandr Mishin <[email protected]>
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 <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: ccp - drop platform ifdef checks [+ + +]
Author: Arnd Bergmann <[email protected]>
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 <[email protected]>
    Acked-by: Tom Lendacky <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: ecdsa - Fix module auto-load on add-key [+ + +]
Author: Stefan Berger <[email protected]>
Date:   Thu Mar 21 10:44:33 2024 -0400

    crypto: ecdsa - Fix module auto-load on add-key
    
    commit 48e4fd6d54f54d0ceab5a952d73e47a9454a6ccb upstream.
    
    Add module alias with the algorithm cra_name similar to what we have for
    RSA-related and other algorithms.
    
    The kernel attempts to modprobe asymmetric algorithms using the names
    "crypto-$cra_name" and "crypto-$cra_name-all." However, since these
    aliases are currently missing, the modules are not loaded. For instance,
    when using the `add_key` function, the hash algorithm is typically
    loaded automatically, but the asymmetric algorithm is not.
    
    Steps to test:
    
    1. Create certificate
    
      openssl req -x509 -sha256 -newkey ec \
      -pkeyopt "ec_paramgen_curve:secp384r1" -keyout key.pem -days 365 \
      -subj '/CN=test' -nodes -outform der -out nist-p384.der
    
    2. Optionally, trace module requests with: trace-cmd stream -e module &
    
    3. Trigger add_key call for the cert:
    
       # keyctl padd asymmetric "" @u < nist-p384.der
       641069229
       # lsmod | head -2
       Module                  Size  Used by
       ecdsa_generic          16384  0
    
    Fixes: c12d448ba939 ("crypto: ecdsa - Register NIST P384 and extend test suite")
    Cc: [email protected]
    Signed-off-by: Stefan Berger <[email protected]>
    Reviewed-by: Vitaly Chikunov <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

crypto: ecrdsa - Fix module auto-load on add_key [+ + +]
Author: Vitaly Chikunov <[email protected]>
Date:   Mon Mar 18 03:42:40 2024 +0300

    crypto: ecrdsa - Fix module auto-load on add_key
    
    commit eb5739a1efbc9ff216271aeea0ebe1c92e5383e5 upstream.
    
    Add module alias with the algorithm cra_name similar to what we have for
    RSA-related and other algorithms.
    
    The kernel attempts to modprobe asymmetric algorithms using the names
    "crypto-$cra_name" and "crypto-$cra_name-all." However, since these
    aliases are currently missing, the modules are not loaded. For instance,
    when using the `add_key` function, the hash algorithm is typically
    loaded automatically, but the asymmetric algorithm is not.
    
    Steps to test:
    
    1. Cert is generated usings ima-evm-utils test suite with
       `gen-keys.sh`, example cert is provided below:
    
      $ base64 -d >test-gost2012_512-A.cer <<EOF
      MIIB/DCCAWagAwIBAgIUK8+whWevr3FFkSdU9GLDAM7ure8wDAYIKoUDBwEBAwMFADARMQ8wDQYD
      VQQDDAZDQSBLZXkwIBcNMjIwMjAxMjIwOTQxWhgPMjA4MjEyMDUyMjA5NDFaMBExDzANBgNVBAMM
      BkNBIEtleTCBoDAXBggqhQMHAQEBAjALBgkqhQMHAQIBAgEDgYQABIGALXNrTJGgeErBUOov3Cfo
      IrHF9fcj8UjzwGeKCkbCcINzVUbdPmCopeJRHDJEvQBX1CQUPtlwDv6ANjTTRoq5nCk9L5PPFP1H
      z73JIXHT0eRBDVoWy0cWDRz1mmQlCnN2HThMtEloaQI81nTlKZOcEYDtDpi5WODmjEeRNQJMdqCj
      UDBOMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYEFCwfOITMbE9VisW1i2TYeu1tAo5QMB8GA1UdIwQY
      MBaAFCwfOITMbE9VisW1i2TYeu1tAo5QMAwGCCqFAwcBAQMDBQADgYEAmBfJCMTdC0/NSjz4BBiQ
      qDIEjomO7FEHYlkX5NGulcF8FaJW2jeyyXXtbpnub1IQ8af1KFIpwoS2e93LaaofxpWlpQLlju6m
      KYLOcO4xK3Whwa2hBAz9YbpUSFjvxnkS2/jpH2MsOSXuUEeCruG/RkHHB3ACef9umG6HCNQuAPY=
      EOF
    
    2. Optionally, trace module requests with: trace-cmd stream -e module &
    
    3. Trigger add_key call for the cert:
    
      # keyctl padd asymmetric "" @u <test-gost2012_512-A.cer
      939910969
      # lsmod | head -3
      Module                  Size  Used by
      ecrdsa_generic         16384  0
      streebog_generic       28672  0
    
    Repored-by: Paul Wolneykien <[email protected]>
    Cc: [email protected]
    Signed-off-by: Vitaly Chikunov <[email protected]>
    Tested-by: Stefan Berger <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak [+ + +]
Author: Herbert Xu <[email protected]>
Date:   Wed May 8 16:39:51 2024 +0800

    crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak
    
    commit d3b17c6d9dddc2db3670bc9be628b122416a3d26 upstream.
    
    Using completion_done to determine whether the caller has gone
    away only works after a complete call.  Furthermore it's still
    possible that the caller has not yet called wait_for_completion,
    resulting in another potential UAF.
    
    Fix this by making the caller use cancel_work_sync and then freeing
    the memory safely.
    
    Fixes: 7d42e097607c ("crypto: qat - resolve race condition during AER recovery")
    Cc: <[email protected]> #6.8+
    Signed-off-by: Herbert Xu <[email protected]>
    Reviewed-by: Giovanni Cabiddu <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

crypto: x86/nh-avx2 - add missing vzeroupper [+ + +]
Author: Eric Biggers <[email protected]>
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 <[email protected]>
    Acked-by: Tim Chen <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: x86/sha256-avx2 - add missing vzeroupper [+ + +]
Author: Eric Biggers <[email protected]>
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 <[email protected]>
    Acked-by: Tim Chen <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: x86/sha512-avx2 - add missing vzeroupper [+ + +]
Author: Eric Biggers <[email protected]>
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 <[email protected]>
    Acked-by: Tim Chen <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dev_printk: Add and use dev_no_printk() [+ + +]
Author: Geert Uytterhoeven <[email protected]>
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 <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Xiubo Li <[email protected]>
    Reviewed-by: Chris Down <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/8583d54f1687c801c6cda8edddf2cf0344c6e883.1709127473.git.geert+renesas@glider.be
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dma-buf/sw-sync: don't enable IRQ from sync_print_obj() [+ + +]
Author: Tetsuo Handa <[email protected]>
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 <[email protected]>
    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 <[email protected]>
    Reviewed-by: Christian König <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Christian König <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dma-mapping: benchmark: fix node id validation [+ + +]
Author: Fedor Pchelkin <[email protected]>
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 <[email protected]>
    Reviewed-by: Robin Murphy <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dma-mapping: benchmark: handle NUMA_NO_NODE correctly [+ + +]
Author: Fedor Pchelkin <[email protected]>
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 <[email protected]>
    Acked-by: Barry Song <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dmaengine: idma64: Add check for dma_set_max_seg_size [+ + +]
Author: Chen Ni <[email protected]>
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 <[email protected]>
    Acked-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() [+ + +]
Author: David Hildenbrand <[email protected]>
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/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 8a6e85f75a83 ("virt: acrn: obtain pa from VMA with PFNMAP flag")
    Signed-off-by: David Hildenbrand <[email protected]>
    Cc: Alex Williamson <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Fei Li <[email protected]>
    Cc: Gerald Schaefer <[email protected]>
    Cc: Heiko Carstens <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Paolo Bonzini <[email protected]>
    Cc: Yonghua Huang <[email protected]>
    Cc: Sean Christopherson <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: Fix potential index out of bounds in color transformation function [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
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 <[email protected]>
    Cc: Charlene Liu <[email protected]>
    Cc: Harry Wentland <[email protected]>
    Cc: Rodrigo Siqueira <[email protected]>
    Cc: Roman Li <[email protected]>
    Cc: Aurabindo Pillai <[email protected]>
    Cc: Tom Chung <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Tom Chung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Set color_mgmt_changed to true on unsuspend [+ + +]
Author: Joshua Ashton <[email protected]>
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 <[email protected]>
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amdgpu/atomfirmware: add intergrated info v2.3 table [+ + +]
Author: Li Ma <[email protected]>
Date:   Mon May 20 18:43:55 2024 +0800

    drm/amdgpu/atomfirmware: add intergrated info v2.3 table
    
    commit e64e8f7c178e5228e0b2dbb504b9dc75953a319f upstream.
    
    [Why]
    The vram width value is 0.
    Because the integratedsysteminfo table in VBIOS has updated to 2.3.
    
    [How]
    Driver needs a new intergrated info v2.3 table too.
    Then the vram width value will be correct.
    
    Signed-off-by: Li Ma <[email protected]>
    Reviewed-by: Yifan Zhang <[email protected]>
    Acked-by: Alex Deucher <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu: add error handle to avoid out-of-bounds [+ + +]
Author: Bob Zhou <[email protected]>
Date:   Tue Apr 23 16:58:11 2024 +0800

    drm/amdgpu: add error handle to avoid out-of-bounds
    
    commit 8b2faf1a4f3b6c748c0da36cda865a226534d520 upstream.
    
    if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should
    be stop to avoid out-of-bounds read, so directly return -EINVAL.
    
    Signed-off-by: Bob Zhou <[email protected]>
    Acked-by: Christian König <[email protected]>
    Reviewed-by: Le Ma <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdkfd: Flush the process wq before creating a kfd_process [+ + +]
Author: Lancelot SIX <[email protected]>
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 <[email protected]>
    Reviewed-by: Felix Kuehling <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/arm/malidp: fix a possible null pointer dereference [+ + +]
Author: Huai-Yuan Liu <[email protected]>
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 <[email protected]>
    Signed-off-by: Liviu Dudau <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/bridge: lt8912b: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
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 <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-3-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: lt9611: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
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 <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-4-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: tc358775: Don't log an error when DSI host can't be found [+ + +]
Author: Nícolas F. R. A. Prado <[email protected]>
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 <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-6-619a28148e5c@collabora.com
    Signed-off-by: Sasha Levin <[email protected]>

drm/bridge: tc358775: fix support for jeida-18 and jeida-24 [+ + +]
Author: Michael Walle <[email protected]>
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 <[email protected]>
    Signed-off-by: Tony Lindgren <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/mediatek: Add 0 size check to mtk_drm_gem_obj [+ + +]
Author: Justin Green <[email protected]>
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 <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Reviewed-by: CK Hu <[email protected]>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/
    Signed-off-by: Chun-Kuang Hu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/meson: vclk: fix calculation of 59.94 fractional rates [+ + +]
Author: Christian Hewitt <[email protected]>
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 <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/mipi-dsi: use correct return type for the DSC functions [+ + +]
Author: Dmitry Baryshkov <[email protected]>
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 <[email protected]>
    Reviewed-by: Jessica Zhang <[email protected]>
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dpu: Always flush the slave INTF on the CTL [+ + +]
Author: Marijn Suijten <[email protected]>
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 <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk [+ + +]
Author: Marijn Suijten <[email protected]>
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 <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/panel: simple: Add missing Innolux G121X1-L03 format, flags, connector [+ + +]
Author: Marek Vasut <[email protected]>
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 <[email protected]>
    Acked-by: Jessica Zhang <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference [+ + +]
Author: Aleksandr Mishin <[email protected]>
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 <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm: Check output polling initialized before disabling [+ + +]
Author: Shradha Gupta <[email protected]>
Date:   Thu Feb 1 22:43:28 2024 -0800

    drm: Check output polling initialized before disabling
    
    commit 5abffb66d12bcac84bf7b66389c571b8bb6e82bd upstream.
    
    In drm_kms_helper_poll_disable() check if output polling
    support is initialized before disabling polling. If not flag
    this as a warning.
    Additionally in drm_mode_config_helper_suspend() and
    drm_mode_config_helper_resume() calls, that re the callers of these
    functions, avoid invoking them if polling is not initialized.
    For drivers like hyperv-drm, that do not initialize connector
    polling, if suspend is called without this check, it leads to
    suspend failure with following stack
    [  770.719392] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
    [  770.720592] printk: Suspending console(s) (use no_console_suspend to debug)
    [  770.948823] ------------[ cut here ]------------
    [  770.948824] WARNING: CPU: 1 PID: 17197 at kernel/workqueue.c:3162 __flush_work.isra.0+0x212/0x230
    [  770.948831] Modules linked in: rfkill nft_counter xt_conntrack xt_owner udf nft_compat crc_itu_t nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink vfat fat mlx5_ib ib_uverbs ib_core mlx5_core intel_rapl_msr intel_rapl_common kvm_amd ccp mlxfw kvm psample hyperv_drm tls drm_shmem_helper drm_kms_helper irqbypass pcspkr syscopyarea sysfillrect sysimgblt hv_balloon hv_utils joydev drm fuse xfs libcrc32c pci_hyperv pci_hyperv_intf sr_mod sd_mod cdrom t10_pi sg hv_storvsc scsi_transport_fc hv_netvsc serio_raw hyperv_keyboard hid_hyperv crct10dif_pclmul crc32_pclmul crc32c_intel hv_vmbus ghash_clmulni_intel dm_mirror dm_region_hash dm_log dm_mod
    [  770.948863] CPU: 1 PID: 17197 Comm: systemd-sleep Not tainted 5.14.0-362.2.1.el9_3.x86_64 #1
    [  770.948865] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
    [  770.948866] RIP: 0010:__flush_work.isra.0+0x212/0x230
    [  770.948869] Code: 8b 4d 00 4c 8b 45 08 89 ca 48 c1 e9 04 83 e2 08 83 e1 0f 83 ca 02 89 c8 48 0f ba 6d 00 03 e9 25 ff ff ff 0f 0b e9 4e ff ff ff <0f> 0b 45 31 ed e9 44 ff ff ff e8 8f 89 b2 00 66 66 2e 0f 1f 84 00
    [  770.948870] RSP: 0018:ffffaf4ac213fb10 EFLAGS: 00010246
    [  770.948871] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8c992857
    [  770.948872] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff9aad82b00330
    [  770.948873] RBP: ffff9aad82b00330 R08: 0000000000000000 R09: ffff9aad87ee3d10
    [  770.948874] R10: 0000000000000200 R11: 0000000000000000 R12: ffff9aad82b00330
    [  770.948874] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
    [  770.948875] FS:  00007ff1b2f6bb40(0000) GS:ffff9aaf37d00000(0000) knlGS:0000000000000000
    [  770.948878] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  770.948878] CR2: 0000555f345cb666 CR3: 00000001462dc005 CR4: 0000000000370ee0
    [  770.948879] Call Trace:
    [  770.948880]  <TASK>
    [  770.948881]  ? show_trace_log_lvl+0x1c4/0x2df
    [  770.948884]  ? show_trace_log_lvl+0x1c4/0x2df
    [  770.948886]  ? __cancel_work_timer+0x103/0x190
    [  770.948887]  ? __flush_work.isra.0+0x212/0x230
    [  770.948889]  ? __warn+0x81/0x110
    [  770.948891]  ? __flush_work.isra.0+0x212/0x230
    [  770.948892]  ? report_bug+0x10a/0x140
    [  770.948895]  ? handle_bug+0x3c/0x70
    [  770.948898]  ? exc_invalid_op+0x14/0x70
    [  770.948899]  ? asm_exc_invalid_op+0x16/0x20
    [  770.948903]  ? __flush_work.isra.0+0x212/0x230
    [  770.948905]  __cancel_work_timer+0x103/0x190
    [  770.948907]  ? _raw_spin_unlock_irqrestore+0xa/0x30
    [  770.948910]  drm_kms_helper_poll_disable+0x1e/0x40 [drm_kms_helper]
    [  770.948923]  drm_mode_config_helper_suspend+0x1c/0x80 [drm_kms_helper]
    [  770.948933]  ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus]
    [  770.948942]  hyperv_vmbus_suspend+0x17/0x40 [hyperv_drm]
    [  770.948944]  ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus]
    [  770.948951]  dpm_run_callback+0x4c/0x140
    [  770.948954]  __device_suspend_noirq+0x74/0x220
    [  770.948956]  dpm_noirq_suspend_devices+0x148/0x2a0
    [  770.948958]  dpm_suspend_end+0x54/0xe0
    [  770.948960]  create_image+0x14/0x290
    [  770.948963]  hibernation_snapshot+0xd6/0x200
    [  770.948964]  hibernate.cold+0x8b/0x1fb
    [  770.948967]  state_store+0xcd/0xd0
    [  770.948969]  kernfs_fop_write_iter+0x124/0x1b0
    [  770.948973]  new_sync_write+0xff/0x190
    [  770.948976]  vfs_write+0x1ef/0x280
    [  770.948978]  ksys_write+0x5f/0xe0
    [  770.948979]  do_syscall_64+0x5c/0x90
    [  770.948981]  ? syscall_exit_work+0x103/0x130
    [  770.948983]  ? syscall_exit_to_user_mode+0x12/0x30
    [  770.948985]  ? do_syscall_64+0x69/0x90
    [  770.948986]  ? do_syscall_64+0x69/0x90
    [  770.948987]  ? do_user_addr_fault+0x1d6/0x6a0
    [  770.948989]  ? do_syscall_64+0x69/0x90
    [  770.948990]  ? exc_page_fault+0x62/0x150
    [  770.948992]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
    [  770.948995] RIP: 0033:0x7ff1b293eba7
    [  770.949010] Code: 0b 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
    [  770.949011] RSP: 002b:00007ffde3912128 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [  770.949012] RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007ff1b293eba7
    [  770.949013] RDX: 0000000000000005 RSI: 00007ffde3912210 RDI: 0000000000000004
    [  770.949014] RBP: 00007ffde3912210 R08: 000055d7dd4c9510 R09: 00007ff1b29b14e0
    [  770.949014] R10: 00007ff1b29b13e0 R11: 0000000000000246 R12: 0000000000000005
    [  770.949015] R13: 000055d7dd4c53e0 R14: 0000000000000005 R15: 00007ff1b29f69e0
    [  770.949016]  </TASK>
    [  770.949017] ---[ end trace e6fa0618bfa2f31d ]---
    
    Built-on: Rhel9, Ubuntu22
    Signed-off-by: Shradha Gupta <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/1706856208-9617-1-git-send-email-shradhagupta@linux.microsoft.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm: Check polling initialized before enabling in drm_helper_probe_single_connector_modes [+ + +]
Author: Shradha Gupta <[email protected]>
Date:   Thu Feb 1 22:43:44 2024 -0800

    drm: Check polling initialized before enabling in drm_helper_probe_single_connector_modes
    
    commit 048a36d8a6085bbd8ab9e5794b713b92ac986450 upstream.
    
    In function drm_helper_probe_single_connector_modes() when we enable
    polling again, if it is already uninitialized, a warning is reported.
    This patch fixes the warning message by checking if poll is initialized
    before enabling it.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-lkp/[email protected]
    Signed-off-by: Shradha Gupta <[email protected]>
    Signed-off-by: Daniel Vetter <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/1706856224-9725-1-git-send-email-shradhagupta@linux.microsoft.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm: vc4: Fix possible null pointer dereference [+ + +]
Author: Aleksandr Mishin <[email protected]>
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 <[email protected]>
    Signed-off-by: Maxime Ripard <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
dt-bindings: PCI: rcar-pci-host: Add missing IOMMU properties [+ + +]
Author: Geert Uytterhoeven <[email protected]>
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 <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Acked-by: Conor Dooley <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: PCI: rcar-pci-host: Add optional regulators [+ + +]
Author: Wolfram Sang <[email protected]>
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/[email protected]
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Acked-by: Krzysztof Kozlowski <[email protected]>
    Stable-dep-of: 78d212851f0e ("dt-bindings: PCI: rcar-pci-host: Add missing IOMMU properties")
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: pinctrl: mediatek: mt7622: fix array properties [+ + +]
Author: Rafał Miłecki <[email protected]>
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 <[email protected]>
    Acked-by: Rob Herring <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: rockchip: grf: Add missing type to 'pcie-phy' node [+ + +]
Author: Rob Herring <[email protected]>
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 <[email protected]>
    Reviewed-by: Heiko Stuebner <[email protected]>
    Acked-by: Conor Dooley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ecryptfs: Fix buffer size for tag 66 packet [+ + +]
Author: Brian Kubisiak <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/5j2q56p6qkhezva6b2yuqfrsurmvrrqtxxzrnp3wqu7xrz22i7@hoecdztoplbl
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
EDAC/igen6: Convert PCIBIOS_* return codes to errnos [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Mon May 27 16:22:35 2024 +0300

    EDAC/igen6: Convert PCIBIOS_* return codes to errnos
    
    commit f8367a74aebf88dc8b58a0db6a6c90b4cb8fc9d3 upstream.
    
    errcmd_enable_error_reporting() uses pci_{read,write}_config_word()
    that return PCIBIOS_* codes. The return code is then returned all the
    way into the probe function igen6_probe() that returns it as is. The
    probe functions, however, should return normal errnos.
    
    Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal
    errno before returning it from errcmd_enable_error_reporting().
    
    Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC")
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Qiuxu Zhuo <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
enic: Validate length of nl attributes in enic_set_vf_port [+ + +]
Author: Roded Zats <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
epoll: be better about file lifetimes [+ + +]
Author: Linus Torvalds <[email protected]>
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/[email protected]/
    Reported-by: [email protected]
    Reviewed-by: Jens Axboe <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
eth: sungem: remove .ndo_poll_controller to avoid deadlocks [+ + +]
Author: Jakub Kicinski <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/all/20240428125306.2c3080ef@legion
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ext4: avoid excessive credit estimate in ext4_tmpfile() [+ + +]
Author: Jan Kara <[email protected]>
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 <[email protected]>
    Tested-by: Luis Henriques <[email protected]>
    Tested-by: Disha Goel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find() [+ + +]
Author: Baokun Li <[email protected]>
Date:   Sat May 4 15:55:25 2024 +0800

    ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
    
    commit 0c0b4a49d3e7f49690a6827a41faeffad5df7e21 upstream.
    
    Syzbot reports a warning as follows:
    
    ============================================
    WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290
    Modules linked in:
    CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7
    RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419
    Call Trace:
     <TASK>
     ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375
     generic_shutdown_super+0x136/0x2d0 fs/super.c:641
     kill_block_super+0x44/0x90 fs/super.c:1675
     ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327
    [...]
    ============================================
    
    This is because when finding an entry in ext4_xattr_block_cache_find(), if
    ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown
    in the __entry_find(), won't be put away, and eventually trigger the above
    issue in mb_cache_destroy() due to reference count leakage.
    
    So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=dd43bd0f7474512edc47
    Fixes: fb265c9cb49e ("ext4: add ext4_sb_bread() to disambiguate ENOMEM cases")
    Cc: [email protected]
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: fix potential unnitialized variable [+ + +]
Author: Dan Carpenter <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: fix unit mismatch in ext4_mb_new_blocks_simple [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Sat Jun 3 23:03:10 2023 +0800

    ext4: fix unit mismatch in ext4_mb_new_blocks_simple
    
    [ Upstream commit 497885f72d930305d8e61b6b616b22b4da1adf90 ]
    
    The "i" returned from mb_find_next_zero_bit is in cluster unit and we
    need offset "block" corresponding to "i" in block unit. Convert "i" to
    block unit to fix the unit mismatch.
    
    Signed-off-by: Kemeng Shi <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 3f4830abd236 ("ext4: fix potential unnitialized variable")
    Signed-off-by: Sasha Levin <[email protected]>

ext4: remove unused parameter from ext4_mb_new_blocks_simple() [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Sat Jun 3 23:03:17 2023 +0800

    ext4: remove unused parameter from ext4_mb_new_blocks_simple()
    
    [ Upstream commit ad78b5efe4246e5deba8d44a6ed172b8a00d3113 ]
    
    Two cleanups for ext4_mb_new_blocks_simple:
    Remove unused parameter handle of ext4_mb_new_blocks_simple.
    Move ext4_mb_new_blocks_simple definition before ext4_mb_new_blocks to
    remove unnecessary forward declaration of ext4_mb_new_blocks_simple.
    
    Signed-off-by: Kemeng Shi <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 3f4830abd236 ("ext4: fix potential unnitialized variable")
    Signed-off-by: Sasha Levin <[email protected]>

ext4: set type of ac_groups_linear_remaining to __u32 to avoid overflow [+ + +]
Author: Baokun Li <[email protected]>
Date:   Tue Mar 19 19:33:23 2024 +0800

    ext4: set type of ac_groups_linear_remaining to __u32 to avoid overflow
    
    commit 9a9f3a9842927e4af7ca10c19c94dad83bebd713 upstream.
    
    Now ac_groups_linear_remaining is of type __u16 and s_mb_max_linear_groups
    is of type unsigned int, so an overflow occurs when setting a value above
    65535 through the mb_max_linear_groups sysfs interface. Therefore, the
    type of ac_groups_linear_remaining is set to __u32 to avoid overflow.
    
    Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning")
    CC: [email protected]
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Zhang Yi <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ext4: simplify calculation of blkoff in ext4_mb_new_blocks_simple [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Sat Mar 4 01:21:20 2023 +0800

    ext4: simplify calculation of blkoff in ext4_mb_new_blocks_simple
    
    [ Upstream commit 253cacb0de89235673ad5889d61f275a73dbee79 ]
    
    We try to allocate a block from goal in ext4_mb_new_blocks_simple. We
    only need get blkoff in first group with goal and set blkoff to 0 for
    the rest groups.
    
    Signed-off-by: Kemeng Shi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 3f4830abd236 ("ext4: fix potential unnitialized variable")
    Signed-off-by: Sasha Levin <[email protected]>

ext4: try all groups in ext4_mb_new_blocks_simple [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Sat Jun 3 23:03:15 2023 +0800

    ext4: try all groups in ext4_mb_new_blocks_simple
    
    [ Upstream commit 19a043bb1fd1b5cb2652ca33536c55e6c0a70df0 ]
    
    ext4_mb_new_blocks_simple ignores the group before goal, so it will fail
    if free blocks reside in group before goal. Try all groups to avoid
    unexpected failure.
    Search finishes either if any free block is found or if no available
    blocks are found. Simpliy check "i >= max" to distinguish the above
    cases.
    
    Signed-off-by: Kemeng Shi <[email protected]>
    Suggested-by: Theodore Ts'o <[email protected]>
    Reviewed-by: Ojaswin Mujoo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: 3f4830abd236 ("ext4: fix potential unnitialized variable")
    Signed-off-by: Sasha Levin <[email protected]>

 
extcon: max8997: select IRQ_DOMAIN instead of depending on it [+ + +]
Author: Randy Dunlap <[email protected]>
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/[email protected]/
    Fixes: dca1a71e4108 ("extcon: Add support irq domain for MAX8997 muic")
    Signed-off-by: Randy Dunlap <[email protected]>
    Acked-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Chanwoo Choi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
f2fs: compress: don't allow unaligned truncation on released compress inode [+ + +]
Author: Chao Yu <[email protected]>
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 <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock [+ + +]
Author: Chao Yu <[email protected]>
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 <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to relocate check condition in f2fs_ioc_{,de}compress_file() [+ + +]
Author: Chao Yu <[email protected]>
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 <[email protected]>
    Closes: https://lore.kernel.org/linux-f2fs-devel/CAHJ8P3LdZXLc2rqeYjvymgYHr2+YLuJ0sLG9DdsJZmwO7deuhw@mail.gmail.com
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: fix to relocate check condition in f2fs_{release,reserve}_compress_blocks() [+ + +]
Author: Chao Yu <[email protected]>
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 <[email protected]>
    Closes: https://lore.kernel.org/linux-f2fs-devel/CAHJ8P3LdZXLc2rqeYjvymgYHr2+YLuJ0sLG9DdsJZmwO7deuhw@mail.gmail.com
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: convert to use sbi directly [+ + +]
Author: Yangtao Li <[email protected]>
Date:   Tue Jun 13 15:51:57 2023 +0800

    f2fs: convert to use sbi directly
    
    [ Upstream commit c3355ea9d82fe6b1a4226c9a7d311f9c5715b456 ]
    
    F2FS_I_SB(inode) is redundant.
    
    Signed-off-by: Yangtao Li <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: bd9ae4ae9e58 ("f2fs: compress: fix to relocate check condition in f2fs_ioc_{,de}compress_file()")
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: Delete f2fs_copy_page() and replace with memcpy_page() [+ + +]
Author: Fabio M. De Francesco <[email protected]>
Date:   Sun Jul 17 10:36:13 2022 +0200

    f2fs: Delete f2fs_copy_page() and replace with memcpy_page()
    
    [ Upstream commit 1dd55358efc4f74e49fa9e1e97a03804852a4c20 ]
    
    f2fs_copy_page() is a wrapper around two kmap() + one memcpy() from/to
    the mapped pages. It unnecessarily duplicates a kernel API and it makes
    use of kmap(), which is being deprecated in favor of kmap_local_page().
    
    Two main problems with kmap(): (1) It comes with an overhead as mapping
    space is restricted and protected by a global lock for synchronization and
    (2) it also requires global TLB invalidation when the kmap’s pool wraps
    and it might block when the mapping space is fully utilized until a slot
    becomes available.
    
    With kmap_local_page() the mappings are per thread, CPU local, can take
    page faults, and can be called from any context (including interrupts).
    It is faster than kmap() in kernels with HIGHMEM enabled. Therefore, its
    use in __clone_blkaddrs() is safe and should be preferred.
    
    Delete f2fs_copy_page() and use a plain memcpy_page() in the only one
    site calling the removed function. memcpy_page() avoids open coding two
    kmap_local_page() + one memcpy() between the two kernel virtual addresses.
    
    Suggested-by: Christoph Hellwig <[email protected]>
    Suggested-by: Ira Weiny <[email protected]>
    Signed-off-by: Fabio M. De Francesco <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: d3876e34e7e7 ("f2fs: fix to wait on page writeback in __clone_blkaddrs()")
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: do not allow partial truncation on pinned file [+ + +]
Author: Jaegeuk Kim <[email protected]>
Date:   Fri Jan 7 20:08:45 2022 -0800

    f2fs: do not allow partial truncation on pinned file
    
    [ Upstream commit 5fed0be8583f08c1548b4dcd9e5ee0d1133d0730 ]
    
    If the pinned file has a hole by partial truncation, application that has
    the block map will be broken.
    
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: 278a6253a673 ("f2fs: fix to relocate check condition in f2fs_fallocate()")
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to check pinfile flag in f2fs_move_file_range() [+ + +]
Author: Chao Yu <[email protected]>
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 <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Apr 25 16:58:38 2024 +0800

    f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()
    
    commit 20faaf30e55522bba2b56d9c46689233205d7717 upstream.
    
    syzbot reports a kernel bug as below:
    
    F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
    BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]
    BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
    Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076
    
    CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
     print_address_description mm/kasan/report.c:377 [inline]
     print_report+0x169/0x550 mm/kasan/report.c:488
     kasan_report+0x143/0x180 mm/kasan/report.c:601
     f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
     current_nat_addr fs/f2fs/node.h:213 [inline]
     f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
     f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]
     f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925
     ioctl_fiemap fs/ioctl.c:220 [inline]
     do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838
     __do_sys_ioctl fs/ioctl.c:902 [inline]
     __se_sys_ioctl+0x81/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
    
    The root cause is we missed to do sanity check on i_xattr_nid during
    f2fs_iget(), so that in fiemap() path, current_nat_addr() will access
    nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering
    kasan bug report, fix it.
    
    Reported-and-tested-by: [email protected]
    Closes: https://lore.kernel.org/linux-f2fs-devel/[email protected]
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

f2fs: fix to release node block count in error path of f2fs_new_node_page() [+ + +]
Author: Chao Yu <[email protected]>
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 <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to relocate check condition in f2fs_fallocate() [+ + +]
Author: Chao Yu <[email protected]>
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 <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to wait on page writeback in __clone_blkaddrs() [+ + +]
Author: Chao Yu <[email protected]>
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 <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix typos in comments [+ + +]
Author: Jinyoung CHOI <[email protected]>
Date:   Mon Feb 6 20:56:00 2023 +0900

    f2fs: fix typos in comments
    
    [ Upstream commit 146949defda868378992171b9e42318b06fcd482 ]
    
    This patch is to fix typos in f2fs files.
    
    Signed-off-by: Jinyoung Choi <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: 278a6253a673 ("f2fs: fix to relocate check condition in f2fs_fallocate()")
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev: savage: Handle err return when savagefb_check_var failed [+ + +]
Author: Cai Xinchen <[email protected]>
Date:   Tue Apr 16 06:51:37 2024 +0000

    fbdev: savage: Handle err return when savagefb_check_var failed
    
    commit 6ad959b6703e2c4c5d7af03b4cfd5ff608036339 upstream.
    
    The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")
    checks the value of pixclock to avoid divide-by-zero error. However
    the function savagefb_probe doesn't handle the error return of
    savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.
    
    Fixes: 04e5eac8f3ab ("fbdev: savage: Error out if pixclock equals zero")
    Signed-off-by: Cai Xinchen <[email protected]>
    Cc: [email protected]
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fbdev: sh7760fb: allow modular build [+ + +]
Author: Randy Dunlap <[email protected]>
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 <[email protected]>
    Signed-off-by: Randy Dunlap <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Javier Martinez Canillas <[email protected]>
    Cc: John Paul Adrian Glaubitz <[email protected]>
    Cc: Sam Ravnborg <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Acked-by: John Paul Adrian Glaubitz <[email protected]>
    Acked-by: Javier Martinez Canillas <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fbdev: shmobile: fix snprintf truncation [+ + +]
Author: Arnd Bergmann <[email protected]>
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 <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fbdev: sisfb: hide unused variables [+ + +]
Author: Arnd Bergmann <[email protected]>
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 <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware: dmi-id: add a release callback function [+ + +]
Author: Arnd Bergmann <[email protected]>
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/[email protected]/
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Jean Delvare <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

firmware: raspberrypi: Use correct device for DMA mappings [+ + +]
Author: Laurent Pinchart <[email protected]>
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 <[email protected]>
    Reviewed-by: Stefan Wahren <[email protected]>
    Tested-by: Ivan T. Ivanov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fpga: region: add owner module and take its refcount [+ + +]
Author: Marco Pagani <[email protected]>
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 <[email protected]>
    Suggested-by: Xu Yilun <[email protected]>
    Reviewed-by: Russ Weight <[email protected]>
    Signed-off-by: Marco Pagani <[email protected]>
    Acked-by: Xu Yilun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Xu Yilun <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fpga: region: Use standard dev_release for class driver [+ + +]
Author: Russ Weight <[email protected]>
Date:   Thu Nov 18 17:55:53 2021 -0800

    fpga: region: Use standard dev_release for class driver
    
    [ Upstream commit 8886a579744fbfa53e69aa453ed10ae3b1f9abac ]
    
    The FPGA region class driver data structure is being treated as a
    managed resource instead of using the standard dev_release call-back
    function to release the class data structure. This change removes the
    managed resource code and combines the create() and register()
    functions into a single register() or register_full() function.
    
    The register_full() function accepts an info data structure to provide
    flexibility in passing optional parameters. The register() function
    supports the current parameter list for users that don't require the
    use of optional parameters.
    
    Signed-off-by: Russ Weight <[email protected]>
    Reviewed-by: Xu Yilun <[email protected]>
    Acked-by: Xu Yilun <[email protected]>
    Signed-off-by: Moritz Fischer <[email protected]>
    Stable-dep-of: b7c0e1ecee40 ("fpga: region: add owner module and take its refcount")
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/ntfs3: Break dir enumeration if directory contents error [+ + +]
Author: Konstantin Komarov <[email protected]>
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 <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fs/ntfs3: Fix case when index is reused during tree transformation [+ + +]
Author: Konstantin Komarov <[email protected]>
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 <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fs/ntfs3: Remove max link count info display during driver init [+ + +]
Author: Konstantin Komarov <[email protected]>
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 <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fs/ntfs3: Taking DOS names into account during link counting [+ + +]
Author: Konstantin Komarov <[email protected]>
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 <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow [+ + +]
Author: Konstantin Komarov <[email protected]>
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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

fs/ntfs3: Use variable length array instead of fixed size [+ + +]
Author: Konstantin Komarov <[email protected]>
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 <[email protected]>
    Reported-by: Dan Carpenter <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Konstantin Komarov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline [+ + +]
Author: Dongli Zhang <[email protected]>
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 <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
gfs2: Don't forget to complete delayed withdraw [+ + +]
Author: Andreas Gruenbacher <[email protected]>
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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

gfs2: Fix "ignore unlock failures after withdraw" [+ + +]
Author: Andreas Gruenbacher <[email protected]>
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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
greybus: arche-ctrl: move device table to its right location [+ + +]
Author: Arnd Bergmann <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

greybus: lights: check return of get_channel_from_mode [+ + +]
Author: Rui Miguel Silva <[email protected]>
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/[email protected]
    
    Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
    Reported-by: Mikhail Lobanov <[email protected]>
    Suggested-by: Mikhail Lobanov <[email protected]>
    Suggested-by: Alex Elder <[email protected]>
    Signed-off-by: Rui Miguel Silva <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
HID: intel-ish-hid: ipc: Add check for pci_alloc_irq_vectors [+ + +]
Author: Chen Ni <[email protected]>
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.
    
    [[email protected]: reworded changelog based on Srinivas' suggestion]
    Fixes: 74fbc7d371d9 ("HID: intel-ish-hid: add MSI interrupt support")
    Signed-off-by: Chen Ni <[email protected]>
    Acked-by: Srinivas Pandruvada <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hwmon: (shtc1) Fix property misspelling [+ + +]
Author: Guenter Roeck <[email protected]>
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 <[email protected]>
    Fixes: be7373b60df5 ("hwmon: shtc1: add support for device tree bindings")
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
i3c: master: svc: fix invalidate IBI type and miss call client IBI handler [+ + +]
Author: Frank Li <[email protected]>
Date:   Mon May 6 12:40:09 2024 -0400

    i3c: master: svc: fix invalidate IBI type and miss call client IBI handler
    
    commit 38baed9b8600008e5d7bc8cb9ceccc1af3dd54b7 upstream.
    
    In an In-Band Interrupt (IBI) handle, the code logic is as follows:
    
    1: writel(SVC_I3C_MCTRL_REQUEST_AUTO_IBI | SVC_I3C_MCTRL_IBIRESP_AUTO,
              master->regs + SVC_I3C_MCTRL);
    
    2: ret = readl_relaxed_poll_timeout(master->regs + SVC_I3C_MSTATUS, val,
                                        SVC_I3C_MSTATUS_IBIWON(val), 0, 1000);
            ...
    3: ibitype = SVC_I3C_MSTATUS_IBITYPE(status);
       ibiaddr = SVC_I3C_MSTATUS_IBIADDR(status);
    
    SVC_I3C_MSTATUS_IBIWON may be set before step 1. Thus, step 2 will return
    immediately, and the I3C controller has not sent out the 9th SCL yet.
    Consequently, ibitype and ibiaddr are 0, resulting in an unknown IBI type
    occurrence and missing call I3C client driver's IBI handler.
    
    A typical case is that SVC_I3C_MSTATUS_IBIWON is set when an IBI occurs
    during the controller send start frame in svc_i3c_master_xfer().
    
    Clear SVC_I3C_MSTATUS_IBIWON before issue SVC_I3C_MCTRL_REQUEST_AUTO_IBI
    to fix this issue.
    
    Cc: [email protected]
    Fixes: 5e5e3c92e748 ("i3c: master: svc: fix wrong data return when IBI happen during start frame")
    Signed-off-by: Frank Li <[email protected]>
    Reviewed-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ice: Interpret .set_channels() input differently [+ + +]
Author: Larysa Zaremba <[email protected]>
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 <[email protected]>
    Signed-off-by: Larysa Zaremba <[email protected]>
    Tested-by: Chandan Kumar Rout <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]>
    Acked-by: Maciej Fijalkowski <[email protected]>
    Signed-off-by: Jacob Keller <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iio: pressure: dps310: support negative temperature values [+ + +]
Author: Thomas Haemmerle <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Input: cyapa - add missing input core locking to suspend/resume functions [+ + +]
Author: Marek Szyprowski <[email protected]>
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 <[email protected]>
    Reviewed-by: Andrzej Pietrasiewicz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Input: ims-pcu - fix printf string overflow [+ + +]
Author: Arnd Bergmann <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Input: ioc3kbd - add device table [+ + +]
Author: Karel Balej <[email protected]>
Date:   Fri Mar 15 12:46:14 2024 -0700

    Input: ioc3kbd - add device table
    
    [ Upstream commit d40e9edcf3eb925c259df9f9dd7319a4fcbc675b ]
    
    Without the device table the driver will not auto-load when compiled as
    a module.
    
    Fixes: 273db8f03509 ("Input: add IOC3 serio driver")
    Signed-off-by: Karel Balej <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Input: ioc3kbd - convert to platform remove callback returning void [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Wed Sep 20 14:58:13 2023 +0200

    Input: ioc3kbd - convert to platform remove callback returning void
    
    [ Upstream commit 150e792dee9ca8416f3d375e48f2f4d7f701fc6b ]
    
    The .remove() callback for a platform driver returns an int which makes
    many driver authors wrongly assume it's possible to do error handling by
    returning an error code. However the value returned is ignored (apart
    from emitting a warning) and this typically results in resource leaks.
    To improve here there is a quest to make the remove callback return
    void. In the first step of this quest all drivers are converted to
    .remove_new() which already returns void. Eventually after all drivers
    are converted, .remove_new() will be renamed to .remove().
    
    Trivially convert this driver from always returning zero in the remove
    callback to the void returning variant.
    
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Stable-dep-of: d40e9edcf3eb ("Input: ioc3kbd - add device table")
    Signed-off-by: Sasha Levin <[email protected]>

Input: pm8xxx-vibrator - correct VIB_MAX_LEVELS calculation [+ + +]
Author: Fenglin Wu <[email protected]>
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 <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/20240412-pm8xxx-vibrator-new-design-v10-1-0ec0ad133866@quicinc.com
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
intel_th: pci: Add Meteor Lake-S CPU support [+ + +]
Author: Alexander Shishkin <[email protected]>
Date:   Mon Apr 29 16:01:18 2024 +0300

    intel_th: pci: Add Meteor Lake-S CPU support
    
    commit a4f813c3ec9d1c32bc402becd1f011b3904dd699 upstream.
    
    Add support for the Trace Hub in Meteor Lake-S CPU.
    
    Signed-off-by: Alexander Shishkin <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
io_uring: fail NOP if non-zero op flags is passed in [+ + +]
Author: Ming Lei <[email protected]>
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 <[email protected]>
    Fixes: 2b188cc1bb85 ("Add io_uring IO interface")
    Cc: [email protected]
    Signed-off-by: Ming Lei <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ipv6: sr: add missing seg6_local_exit [+ + +]
Author: Hangbin Liu <[email protected]>
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 <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: sr: fix incorrect unregister order [+ + +]
Author: Hangbin Liu <[email protected]>
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 <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: sr: fix invalid unregister error path [+ + +]
Author: Hangbin Liu <[email protected]>
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 <[email protected]>
    Signed-off-by: Hangbin Liu <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: sr: fix memleak in seg6_hmac_init_algo [+ + +]
Author: Hangbin Liu <[email protected]>
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 <[email protected]>
    Closes: https://lore.kernel.org/netdev/Zj3bh-gE7eT6V6aH@hog/
    Signed-off-by: Hangbin Liu <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Sabrina Dubroca <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ipv6: sr: fix missing sk_buff release in seg6_input_core [+ + +]
Author: Andrea Mayer <[email protected]>
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 <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound [+ + +]
Author: Yue Haibing <[email protected]>
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 <[email protected]>
    Signed-off-by: Yue Haibing <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip/alpine-msi: Fix off-by-one in allocation error path [+ + +]
Author: Zenghui Yu <[email protected]>
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 <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
irqchip/loongson-pch-msi: Fix off-by-one on allocation error path [+ + +]
Author: Zenghui Yu <[email protected]>
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 <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Jiaxun Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
jffs2: prevent xattr node from overflowing the eraseblock [+ + +]
Author: Ilya Denisyev <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kconfig: fix comparison to constant symbols, 'm', 'n' [+ + +]
Author: Masahiro Yamada <[email protected]>
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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kdb: Fix buffer overflow during tab-complete [+ + +]
Author: Daniel Thompson <[email protected]>
Date:   Wed Apr 24 15:03:34 2024 +0100

    kdb: Fix buffer overflow during tab-complete
    
    commit e9730744bf3af04cda23799029342aa3cddbc454 upstream.
    
    Currently, when the user attempts symbol completion with the Tab key, kdb
    will use strncpy() to insert the completed symbol into the command buffer.
    Unfortunately it passes the size of the source buffer rather than the
    destination to strncpy() with predictably horrible results. Most obviously
    if the command buffer is already full but cp, the cursor position, is in
    the middle of the buffer, then we will write past the end of the supplied
    buffer.
    
    Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()
    calls plus explicit boundary checks to make sure we have enough space
    before we start moving characters around.
    
    Reported-by: Justin Stitt <[email protected]>
    Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziUJLpw@mail.gmail.com/
    Cc: [email protected]
    Reviewed-by: Douglas Anderson <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Tested-by: Justin Stitt <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Daniel Thompson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

kdb: Fix console handling when editing and tab-completing commands [+ + +]
Author: Daniel Thompson <[email protected]>
Date:   Wed Apr 24 15:03:36 2024 +0100

    kdb: Fix console handling when editing and tab-completing commands
    
    commit db2f9c7dc29114f531df4a425d0867d01e1f1e28 upstream.
    
    Currently, if the cursor position is not at the end of the command buffer
    and the user uses the Tab-complete functions, then the console does not
    leave the cursor in the correct position.
    
    For example consider the following buffer with the cursor positioned
    at the ^:
    
    md kdb_pro 10
              ^
    
    Pressing tab should result in:
    
    md kdb_prompt_str 10
                     ^
    
    However this does not happen. Instead the cursor is placed at the end
    (after then 10) and further cursor movement redraws incorrectly. The
    same problem exists when we double-Tab but in a different part of the
    code.
    
    Fix this by sending a carriage return and then redisplaying the text to
    the left of the cursor.
    
    Cc: [email protected]
    Reviewed-by: Douglas Anderson <[email protected]>
    Tested-by: Justin Stitt <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Daniel Thompson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

kdb: Merge identical case statements in kdb_read() [+ + +]
Author: Daniel Thompson <[email protected]>
Date:   Wed Apr 24 15:03:37 2024 +0100

    kdb: Merge identical case statements in kdb_read()
    
    commit 6244917f377bf64719551b58592a02a0336a7439 upstream.
    
    The code that handles case 14 (down) and case 16 (up) has been copy and
    pasted despite being byte-for-byte identical. Combine them.
    
    Cc: [email protected] # Not a bug fix but it is needed for later bug fixes
    Reviewed-by: Douglas Anderson <[email protected]>
    Tested-by: Justin Stitt <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Daniel Thompson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

kdb: Use format-specifiers rather than memset() for padding in kdb_read() [+ + +]
Author: Daniel Thompson <[email protected]>
Date:   Wed Apr 24 15:03:38 2024 +0100

    kdb: Use format-specifiers rather than memset() for padding in kdb_read()
    
    commit c9b51ddb66b1d96e4d364c088da0f1dfb004c574 upstream.
    
    Currently when the current line should be removed from the display
    kdb_read() uses memset() to fill a temporary buffer with spaces.
    The problem is not that this could be trivially implemented using a
    format string rather than open coding it. The real problem is that
    it is possible, on systems with a long kdb_prompt_str, to write past
    the end of the tmpbuffer.
    
    Happily, as mentioned above, this can be trivially implemented using a
    format string. Make it so!
    
    Cc: [email protected]
    Reviewed-by: Douglas Anderson <[email protected]>
    Tested-by: Justin Stitt <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Daniel Thompson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

kdb: Use format-strings rather than '\0' injection in kdb_read() [+ + +]
Author: Daniel Thompson <[email protected]>
Date:   Wed Apr 24 15:03:35 2024 +0100

    kdb: Use format-strings rather than '\0' injection in kdb_read()
    
    commit 09b35989421dfd5573f0b4683c7700a7483c71f9 upstream.
    
    Currently when kdb_read() needs to reposition the cursor it uses copy and
    paste code that works by injecting an '\0' at the cursor position before
    delivering a carriage-return and reprinting the line (which stops at the
    '\0').
    
    Tidy up the code by hoisting the copy and paste code into an appropriately
    named function. Additionally let's replace the '\0' injection with a
    proper field width parameter so that the string will be abridged during
    formatting instead.
    
    Cc: [email protected] # Not a bug fix but it is needed for later bug fixes
    Tested-by: Justin Stitt <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Daniel Thompson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
KVM: arm64: Allow AArch32 PSTATE.M to be restored as System mode [+ + +]
Author: Marc Zyngier <[email protected]>
Date:   Fri May 24 15:19:55 2024 +0100

    KVM: arm64: Allow AArch32 PSTATE.M to be restored as System mode
    
    commit dfe6d190f38fc5df5ff2614b463a5195a399c885 upstream.
    
    It appears that we don't allow a vcpu to be restored in AArch32
    System mode, as we *never* included it in the list of valid modes.
    
    Just add it to the list of allowed modes.
    
    Fixes: 0d854a60b1d7 ("arm64: KVM: enable initialization of a 32bit vcpu")
    Cc: [email protected]
    Acked-by: Oliver Upton <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Marc Zyngier <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: arm64: Fix AArch32 register narrowing on userspace write [+ + +]
Author: Marc Zyngier <[email protected]>
Date:   Fri May 24 15:19:54 2024 +0100

    KVM: arm64: Fix AArch32 register narrowing on userspace write
    
    commit 947051e361d551e0590777080ffc4926190f62f2 upstream.
    
    When userspace writes to one of the core registers, we make
    sure to narrow the corresponding GPRs if PSTATE indicates
    an AArch32 context.
    
    The code tries to check whether the context is EL0 or EL1 so
    that it narrows the correct registers. But it does so by checking
    the full PSTATE instead of PSTATE.M.
    
    As a consequence, and if we are restoring an AArch32 EL0 context
    in a 64bit guest, and that PSTATE has *any* bit set outside of
    PSTATE.M, we narrow *all* registers instead of only the first 15,
    destroying the 64bit state.
    
    Obviously, this is not something the guest is likely to enjoy.
    
    Correctly masking PSTATE to only evaluate PSTATE.M fixes it.
    
    Fixes: 90c1f934ed71 ("KVM: arm64: Get rid of the AArch32 register mapping code")
    Reported-by: Nina Schoetterl-Glausch <[email protected]>
    Cc: [email protected]
    Reviewed-by: Nina Schoetterl-Glausch <[email protected]>
    Acked-by: Oliver Upton <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Marc Zyngier <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Don't advertise guest.MAXPHYADDR as host.MAXPHYADDR in CPUID [+ + +]
Author: Gerd Hoffmann <[email protected]>
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 <[email protected]>
    Cc: [email protected]
    Reviewed-by: Xiaoyao Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [sean: rewrite changelog with --verbose, Cc stable@]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
libsubcmd: Fix parse-options memory leak [+ + +]
Author: Ian Rogers <[email protected]>
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 <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Josh Poimboeuf <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 5.15.161 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Sun Jun 16 13:40:01 2024 +0200

    Linux 5.15.161
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: SeongJae Park <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
m68k: Fix spinlock race in kernel thread creation [+ + +]
Author: Michael Schmitz <[email protected]>
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 <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Michael Schmitz <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

m68k: mac: Fix reboot hang on Mac IIci [+ + +]
Author: Finn Thain <[email protected]>
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 <[email protected]>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Finn Thain <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/480ebd1249d229c6dc1f3f1c6d599b8505483fd8.1714797072.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
macintosh/via-macii: Fix "BUG: sleeping function called from invalid context" [+ + +]
Author: Finn Thain <[email protected]>
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 <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/419fcc09d0e563b425c419053d02236b044d86b0.1710298421.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Fri Mar 22 16:10:05 2024 +0800

    md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
    
    commit 151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa upstream.
    
    Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
    small possibility, the root cause is exactly the same as commit
    bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
    
    However, Dan reported another hang after that, and junxiao investigated
    the problem and found out that this is caused by plugged bio can't issue
    from raid5d().
    
    Current implementation in raid5d() has a weird dependence:
    
    1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
       MD_SB_CHANGE_PENDING;
    2) raid5d() handles IO in a deadloop, until all IO are issued;
    3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;
    
    This behaviour is introduce before v2.6, and for consequence, if other
    context hold 'reconfig_mutex', and md_check_recovery() can't update
    super_block, then raid5d() will waste one cpu 100% by the deadloop, until
    'reconfig_mutex' is released.
    
    Refer to the implementation from raid1 and raid10, fix this problem by
    skipping issue IO if MD_SB_CHANGE_PENDING is still set after
    md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
    is released. Meanwhile, the hang problem will be fixed as well.
    
    Fixes: 5e2cf333b7bd ("md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d")
    Cc: [email protected] # v5.19+
    Reported-and-tested-by: Dan Moulding <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Investigated-by: Junxiao Bi <[email protected]>
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Song Liu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
md: fix resync softlockup when bitmap size is less than array size [+ + +]
Author: Yu Kuai <[email protected]>
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 <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Song Liu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries [+ + +]
Author: Zhipeng Lu <[email protected]>
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/[email protected]
    
    Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
    Signed-off-by: Zhipeng Lu <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: cec-adap.c: drop activate_cnt, use state info instead [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Tue May 10 10:53:05 2022 +0200

    media: cec-adap.c: drop activate_cnt, use state info instead
    
    [ Upstream commit f9222f8ca18bcb1d55dd749b493b29fd8092fb82 ]
    
    Using an activation counter to decide when the enable or disable the
    cec adapter is not the best approach and can lead to race conditions.
    
    Change this to determining the current status of the adapter, and
    enable or disable the adapter accordingly.
    
    It now only needs to be called whenever there is a chance that the
    state changes, and it can handle enabling/disabling monitoring as
    well if needed.
    
    This simplifies the code and it should be a more robust approach as well.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: 47c82aac10a6 ("media: cec: core: avoid recursive cec_claim_log_addrs")
    Signed-off-by: Sasha Levin <[email protected]>

media: cec: abort if the current transmit was canceled [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Thu Mar 3 14:01:44 2022 +0000

    media: cec: abort if the current transmit was canceled
    
    [ Upstream commit 590a8e564c6eff7e77a84e728612f1269e3c0685 ]
    
    If a transmit-in-progress was canceled, then, once the transmit
    is done, mark it as aborted and refrain from retrying the transmit.
    
    To signal this situation the new transmit_in_progress_aborted field is
    set to true.
    
    The old implementation would just set adap->transmitting to NULL and
    set adap->transmit_in_progress to false, but on the hardware level
    the transmit was still ongoing. However, the framework would think
    the transmit was aborted, and if a new transmit was issued, then
    it could overwrite the HW buffer containing the old transmit with the
    new transmit, leading to garbled data on the CEC bus.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: 47c82aac10a6 ("media: cec: core: avoid recursive cec_claim_log_addrs")
    Signed-off-by: Sasha Levin <[email protected]>

media: cec: call enable_adap on s_log_addrs [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Thu Mar 3 13:55:08 2022 +0000

    media: cec: call enable_adap on s_log_addrs
    
    [ Upstream commit 3813c932ed970dd4f413498ccecb03c73c4f1784 ]
    
    Don't enable/disable the adapter if the first fh is opened or the
    last fh is closed, instead do this when the adapter is configured
    or unconfigured, and also when we enter Monitor All or Monitor Pin
    mode for the first time or we exit the Monitor All/Pin mode for the
    last time.
    
    However, if needs_hpd is true, then do this when the physical
    address is set or cleared: in that case the adapter typically is
    powered by the HPD, so it really is disabled when the HPD is low.
    This case (needs_hpd is true) was already handled in this way, so
    this wasn't changed.
    
    The problem with the old behavior was that if the HPD goes low when
    no fh is open, and a transmit was in progress, then the adapter would
    be disabled, typically stopping the transmit immediately which
    leaves a partial message on the bus, which isn't nice and can confuse
    some adapters.
    
    It makes much more sense to disable it only when the adapter is
    unconfigured and we're not monitoring the bus, since then you really
    won't be using it anymore.
    
    To keep track of this store a CEC activation count and call adap_enable
    only when it goes from 0 to 1 or back to 0.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: 47c82aac10a6 ("media: cec: core: avoid recursive cec_claim_log_addrs")
    Signed-off-by: Sasha Levin <[email protected]>

media: cec: cec-adap: always cancel work in cec_transmit_msg_fh [+ + +]
Author: Hans Verkuil <[email protected]>
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 <[email protected]>
    Reported-by: Yang, Chenyuan <[email protected]>
    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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: cec: cec-api: add locking in cec_release() [+ + +]
Author: Hans Verkuil <[email protected]>
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 <[email protected]>
    Reported-by: Yang, Chenyuan <[email protected]>
    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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: cec: core: add adap_nb_transmit_canceled() callback [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Mon Jun 12 15:58:37 2023 +0200

    media: cec: core: add adap_nb_transmit_canceled() callback
    
    commit da53c36ddd3f118a525a04faa8c47ca471e6c467 upstream.
    
    A potential deadlock was found by Zheng Zhang with a local syzkaller
    instance.
    
    The problem is that when a non-blocking CEC transmit is canceled by calling
    cec_data_cancel, that in turn can call the high-level received() driver
    callback, which can call cec_transmit_msg() to transmit a new message.
    
    The cec_data_cancel() function is called with the adap->lock mutex held,
    and cec_transmit_msg() tries to take that same lock.
    
    The root cause is that the received() callback can either be used to pass
    on a received message (and then adap->lock is not held), or to report a
    canceled transmit (and then adap->lock is held).
    
    This is confusing, so create a new low-level adap_nb_transmit_canceled
    callback that reports back that a non-blocking transmit was canceled.
    
    And the received() callback is only called when a message is received,
    as was the case before commit f9d0ecbf56f4 ("media: cec: correctly pass
    on reply results") complicated matters.
    
    Reported-by: Zheng Zhang <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Fixes: f9d0ecbf56f4 ("media: cec: correctly pass on reply results")
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

media: cec: core: avoid confusing "transmit timed out" message [+ + +]
Author: Hans Verkuil <[email protected]>
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 <[email protected]>
    Reported-by: Yang, Chenyuan <[email protected]>
    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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: cec: core: avoid recursive cec_claim_log_addrs [+ + +]
Author: Hans Verkuil <[email protected]>
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 <[email protected]>
    Reported-by: Yang, Chenyuan <[email protected]>
    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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: cec: correctly pass on reply results [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Sat Nov 13 11:02:36 2021 +0000

    media: cec: correctly pass on reply results
    
    [ Upstream commit f9d0ecbf56f4b90745a6adc5b59281ad8f70ab54 ]
    
    The results of non-blocking transmits were not correctly communicated
    to userspace.
    
    Specifically:
    
    1) if a non-blocking transmit was canceled, then rx_status wasn't set to 0
       as it should.
    2) if the non-blocking transmit succeeded, but the corresponding reply
       never arrived (aborted or timed out), then tx_status wasn't set to 0
       as it should, and rx_status was hardcoded to ABORTED instead of the
       actual reason, such as TIMEOUT. In addition, adap->ops->received() was
       never called, so drivers that want to do message processing themselves
       would not be informed of the failed reply.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: 47c82aac10a6 ("media: cec: core: avoid recursive cec_claim_log_addrs")
    Signed-off-by: Sasha Levin <[email protected]>

media: cec: use call_op and check for !unregistered [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Thu Mar 17 08:51:20 2022 +0000

    media: cec: use call_op and check for !unregistered
    
    [ Upstream commit e2ed5024ac2bc27d4bfc99fd58f5ab54de8fa965 ]
    
    Use call_(void_)op consistently in the CEC core framework. Ditto
    for the cec pin ops. And check if !adap->devnode.unregistered before
    calling each op. This avoids calls to ops when the device has been
    unregistered and the underlying hardware may be gone.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: 47c82aac10a6 ("media: cec: core: avoid recursive cec_claim_log_addrs")
    Signed-off-by: Sasha Levin <[email protected]>

media: dt-bindings: ovti,ov2680: Fix the power supply names [+ + +]
Author: Fabio Estevam <[email protected]>
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 <[email protected]>
    Reviewed-by: Rob Herring <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: flexcop-usb: clean up endpoint sanity checks [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Mon Aug 22 17:14:54 2022 +0200

    media: flexcop-usb: clean up endpoint sanity checks
    
    [ Upstream commit 3de50478b5cc2e0c2479a5f2b967f331f7597d23 ]
    
    Add a temporary variable to make the endpoint sanity checks a bit more
    readable.
    
    While at it, fix a typo in the usb_set_interface() comment.
    
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: f62dc8f6bf82 ("media: flexcop-usb: fix sanity check of bNumEndpoints")
    Signed-off-by: Sasha Levin <[email protected]>

media: flexcop-usb: fix sanity check of bNumEndpoints [+ + +]
Author: Dongliang Mu <[email protected]>
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/[email protected]
    Fixes: d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint type")
    Signed-off-by: Dongliang Mu <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: ipu3-cio2: Request IRQ earlier [+ + +]
Author: Sakari Ailus <[email protected]>
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 <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: ipu3-cio2: Use temporary storage for struct device pointer [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Tue Jul 13 22:21:27 2021 +0200

    media: ipu3-cio2: Use temporary storage for struct device pointer
    
    [ Upstream commit cfd13612a5a70715299d2468f967334048ce52a7 ]
    
    Use temporary storage for struct device pointer to simplify the code.
    
    Signed-off-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Stable-dep-of: a069f79bfa6e ("media: ipu3-cio2: Request IRQ earlier")
    Signed-off-by: Sasha Levin <[email protected]>

media: lgdt3306a: Add a check against null-pointer-def [+ + +]
Author: Zheyu Ma <[email protected]>
Date:   Tue Apr 5 10:50:18 2022 +0100

    media: lgdt3306a: Add a check against null-pointer-def
    
    commit c1115ddbda9c930fba0fdd062e7a8873ebaf898d upstream.
    
    The driver should check whether the client provides the platform_data.
    
    The following log reveals it:
    
    [   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
    [   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
    [   29.612820] Call Trace:
    [   29.613030]  <TASK>
    [   29.613201]  dump_stack_lvl+0x56/0x6f
    [   29.613496]  ? kmemdup+0x30/0x40
    [   29.613754]  print_report.cold+0x494/0x6b7
    [   29.614082]  ? kmemdup+0x30/0x40
    [   29.614340]  kasan_report+0x8a/0x190
    [   29.614628]  ? kmemdup+0x30/0x40
    [   29.614888]  kasan_check_range+0x14d/0x1d0
    [   29.615213]  memcpy+0x20/0x60
    [   29.615454]  kmemdup+0x30/0x40
    [   29.615700]  lgdt3306a_probe+0x52/0x310
    [   29.616339]  i2c_device_probe+0x951/0xa90
    
    Link: https://lore.kernel.org/linux-media/[email protected]
    Signed-off-by: Zheyu Ma <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

media: mc: mark the media devnode as registered from the, start [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Fri Feb 23 09:46:19 2024 +0100

    media: mc: mark the media devnode as registered from the, start
    
    commit 4bc60736154bc9e0e39d3b88918f5d3762ebe5e0 upstream.
    
    First the media device node was created, and if successful it was
    marked as 'registered'. This leaves a small race condition where
    an application can open the device node and get an error back
    because the 'registered' flag was not yet set.
    
    Change the order: first set the 'registered' flag, then actually
    register the media device node. If that fails, then clear the flag.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Acked-by: Sakari Ailus <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Fixes: cf4b9211b568 ("[media] media: Media device node support")
    Cc: [email protected]
    Signed-off-by: Sakari Ailus <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

media: mxl5xx: Move xpt structures off stack [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Fri Jan 12 00:40:36 2024 +0000

    media: mxl5xx: Move xpt structures off stack
    
    commit 526f4527545b2d4ce0733733929fac7b6da09ac6 upstream.
    
    When building for LoongArch with clang 18.0.0, the stack usage of
    probe() is larger than the allowed 2048 bytes:
    
      drivers/media/dvb-frontends/mxl5xx.c:1698:12: warning: stack frame size (2368) exceeds limit (2048) in 'probe' [-Wframe-larger-than]
       1698 | static int probe(struct mxl *state, struct mxl5xx_cfg *cfg)
            |            ^
      1 warning generated.
    
    This is the result of the linked LLVM commit, which changes how the
    arrays of structures in config_ts() get handled with
    CONFIG_INIT_STACK_ZERO and CONFIG_INIT_STACK_PATTERN, which causes the
    above warning in combination with inlining, as config_ts() gets inlined
    into probe().
    
    This warning can be easily fixed by moving the array of structures off
    of the stackvia 'static const', which is a better location for these
    variables anyways because they are static data that is only ever read
    from, never modified, so allocating the stack space is wasteful.
    
    This drops the stack usage from 2368 bytes to 256 bytes with the same
    compiler and configuration.
    
    Link: https://lore.kernel.org/linux-media/20240111-dvb-mxl5xx-move-structs-off-stack-v1-1-ca4230e67c11@kernel.org
    Cc: [email protected]
    Closes: https://github.com/ClangBuiltLinux/linux/issues/1977
    Link: https://github.com/llvm/llvm-project/commit/afe8b93ffdfef5d8879e1894b9d7dda40dee2b8d
    Signed-off-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Miguel Ojeda <[email protected]>
    Tested-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

media: ngene: Add dvb_ca_en50221_init return value check [+ + +]
Author: Aleksandr Burakov <[email protected]>
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 <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: radio-shark2: Avoid led_names truncations [+ + +]
Author: Ricardo Ribalda <[email protected]>
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 <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: stk1160: fix bounds checking in stk1160_copy_video() [+ + +]
Author: Dan Carpenter <[email protected]>
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 <[email protected]>
    Reviewed-by: Ricardo Ribalda <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: v4l2-core: hold videodev_lock until dev reg, finishes [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Fri Feb 23 09:45:36 2024 +0100

    media: v4l2-core: hold videodev_lock until dev reg, finishes
    
    commit 1ed4477f2ea4743e7c5e1f9f3722152d14e6eeb1 upstream.
    
    After the new V4L2 device node was registered, some additional
    initialization was done before the device node was marked as
    'registered'. During the time between creating the device node
    and marking it as 'registered' it was possible to open the
    device node, which would return -ENODEV since the 'registered'
    flag was not yet set.
    
    Hold the videodev_lock mutex from just before the device node
    is registered until the 'registered' flag is set. Since v4l2_open
    will take the same lock, it will wait until this registration
    process is finished. This resolves this race condition.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Reviewed-by: Sakari Ailus <[email protected]>
    Cc: <[email protected]>      # for vi4.18 and up
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
microblaze: Remove early printk call from cpuinfo-static.c [+ + +]
Author: Michal Simek <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/2f10db506be8188fa07b6ec331caca01af1b10f8.1712824039.git.michal.simek@amd.com
    Signed-off-by: Sasha Levin <[email protected]>

microblaze: Remove gcc flag for non existing early_printk.c file [+ + +]
Author: Michal Simek <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/5493467419cd2510a32854e2807bcd263de981a0.1712823702.git.michal.simek@amd.com
    Signed-off-by: Sasha Levin <[email protected]>

 
mm/slub, kunit: Use inverted data to corrupt kmem cache [+ + +]
Author: Guenter Roeck <[email protected]>
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 <[email protected]>
    Cc: Vlastimil Babka <[email protected]>
    CC: Daniel Latypov <[email protected]>
    Cc: Marco Elver <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Vlastimil Babka <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mmc: core: Add mmc_gpiod_set_cd_config() function [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Wed Apr 10 21:16:34 2024 +0200

    mmc: core: Add mmc_gpiod_set_cd_config() function
    
    commit 63a7cd660246aa36af263b85c33ecc6601bf04be upstream.
    
    Some mmc host drivers may need to fixup a card-detection GPIO's config
    to e.g. enable the GPIO controllers builtin pull-up resistor on devices
    where the firmware description of the GPIO is broken (e.g. GpioInt with
    PullNone instead of PullUp in ACPI DSDT).
    
    Since this is the exception rather then the rule adding a config
    parameter to mmc_gpiod_request_cd() seems undesirable, so instead
    add a new mmc_gpiod_set_cd_config() function. This is simply a wrapper
    to call gpiod_set_config() on the card-detect GPIO acquired through
    mmc_gpiod_request_cd().
    
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: core: Do not force a retune before RPMB switch [+ + +]
Author: Jorge Ramirez-Ortiz <[email protected]>
Date:   Wed Jan 3 12:29:11 2024 +0100

    mmc: core: Do not force a retune before RPMB switch
    
    commit 67380251e8bbd3302c64fea07f95c31971b91c22 upstream.
    
    Requesting a retune before switching to the RPMB partition has been
    observed to cause CRC errors on the RPMB reads (-EILSEQ).
    
    Since RPMB reads can not be retried, the clients would be directly
    affected by the errors.
    
    This commit disables the retune request prior to switching to the RPMB
    partition: mmc_retune_pause() no longer triggers a retune before the
    pause period begins.
    
    This was verified with the sdhci-of-arasan driver (ZynqMP) configured
    for HS200 using two separate eMMC cards (DG4064 and 064GB2). In both
    cases, the error was easy to reproduce triggering every few tenths of
    reads.
    
    With this commit, systems that were utilizing OP-TEE to access RPMB
    variables will experience an enhanced performance. Specifically, when
    OP-TEE is configured to employ RPMB as a secure storage solution, it not
    only writes the data but also the secure filesystem within the
    partition. As a result, retrieving any variable involves multiple RPMB
    reads, typically around five.
    
    For context, on ZynqMP, each retune request consumed approximately
    8ms. Consequently, reading any RPMB variable used to take at the very
    minimum 40ms.
    
    After droping the need to retune before switching to the RPMB partition,
    this is no longer the case.
    
    Signed-off-by: Jorge Ramirez-Ortiz <[email protected]>
    Acked-by: Avri Altman <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci-acpi: Disable write protect detection on Toshiba WT10-A [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Wed Apr 10 21:16:38 2024 +0200

    mmc: sdhci-acpi: Disable write protect detection on Toshiba WT10-A
    
    commit ef3eab75e17191e5665f52e64e85bc29d5705a7b upstream.
    
    On the Toshiba WT10-A the microSD slot always reports the card being
    write-protected, just like on the Toshiba WT8-B.
    
    Add a DMI quirk to work around this.
    
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci-acpi: Fix Lenovo Yoga Tablet 2 Pro 1380 sdcard slot not working [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Wed Apr 10 21:16:37 2024 +0200

    mmc: sdhci-acpi: Fix Lenovo Yoga Tablet 2 Pro 1380 sdcard slot not working
    
    commit f3521d7cbaefff19cc656325787ed797e5f6a955 upstream.
    
    The Lenovo Yoga Tablet 2 Pro 1380 sdcard slot has an active high cd pin
    and a broken wp pin which always reports the card being write-protected.
    
    Add a DMI quirk to address both issues.
    
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci-acpi: Sort DMI quirks alphabetically [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Wed Apr 10 21:16:36 2024 +0200

    mmc: sdhci-acpi: Sort DMI quirks alphabetically
    
    commit a92a73b1d9249d155412d8ac237142fa716803ea upstream.
    
    Sort the DMI quirks alphabetically.
    
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mmc: sdhci_am654: Add ITAPDLYSEL in sdhci_j721e_4bit_set_clock [+ + +]
Author: Judith Mendez <[email protected]>
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 <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mmc: sdhci_am654: Add OTAP/ITAP delay enable [+ + +]
Author: Judith Mendez <[email protected]>
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 <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mmc: sdhci_am654: Add tuning algorithm for delay chain [+ + +]
Author: Judith Mendez <[email protected]>
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 <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mmc: sdhci_am654: Drop lookup for deprecated ti,otap-del-sel [+ + +]
Author: Vignesh Raghavendra <[email protected]>
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 <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Stable-dep-of: 387c1bf7dce0 ("mmc: sdhci_am654: Add OTAP/ITAP delay enable")
    Signed-off-by: Sasha Levin <[email protected]>

mmc: sdhci_am654: Fix ITAPDLY for HS400 timing [+ + +]
Author: Judith Mendez <[email protected]>
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 <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mmc: sdhci_am654: Write ITAPDLY for DDR52 timing [+ + +]
Author: Judith Mendez <[email protected]>
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 <[email protected]>
    Reviewed-by: Andrew Davis <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mptcp: fix full TCP keep-alive support [+ + +]
Author: Matthieu Baerts (NGI0) <[email protected]>
Date:   Mon May 13 18:13:26 2024 -0700

    mptcp: fix full TCP keep-alive support
    
    commit bd11dc4fb969ec148e50cd87f88a78246dbc4d0b upstream.
    
    SO_KEEPALIVE support has been added a while ago, as part of a series
    "adding SOL_SOCKET" support. To have a full control of this keep-alive
    feature, it is important to also support TCP_KEEP* socket options at the
    SOL_TCP level.
    
    Supporting them on the setsockopt() part is easy, it is just a matter of
    remembering each value in the MPTCP sock structure, and calling
    tcp_sock_set_keep*() helpers on each subflow. If the value is not
    modified (0), calling these helpers will not do anything. For the
    getsockopt() part, the corresponding value from the MPTCP sock structure
    or the default one is simply returned. All of this is very similar to
    other TCP_* socket options supported by MPTCP.
    
    It looks important for kernels supporting SO_KEEPALIVE, to also support
    TCP_KEEP* options as well: some apps seem to (wrongly) consider that if
    the former is supported, the latter ones will be supported as well. But
    also, not having this simple and isolated change is preventing MPTCP
    support in some apps, and libraries like GoLang [1]. This is why this
    patch is seen as a fix.
    
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/383
    Fixes: 1b3e7ede1365 ("mptcp: setsockopt: handle SO_KEEPALIVE and SO_PRIORITY")
    Link: https://github.com/golang/go/issues/56539 [1]
    Acked-by: Paolo Abeni <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Mat Martineau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    [ Conflicts in the same context, because commit 29b5e5ef8739 ("mptcp:
      implement TCP_NOTSENT_LOWAT support") (new feature), commit
      013e3179dbd2 ("mptcp: fix rcv space initialization") (not backported
      because of the various conflicts, and because the race fixed by this
      commit "does not produce ill effects in practice"), and commit
      4f6e14bd19d6 ("mptcp: support TCP_CORK and TCP_NODELAY") are not in
      this version. The adaptations done by 7f71a337b515 ("mptcp: cleanup
      SOL_TCP handling") have been adapted to this case here. Also,
      TCP_KEEPINTVL and TCP_KEEPCNT value had to be set without lock, the
      same way it was done on TCP side prior commit 6fd70a6b4e6f ("tcp: set
      TCP_KEEPINTVL locklessly") and commit 84485080cbc1 ("tcp: set
      TCP_KEEPCNT locklessly"). ]
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mptcp: SO_KEEPALIVE: fix getsockopt support [+ + +]
Author: Matthieu Baerts (NGI0) <[email protected]>
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 <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Mat Martineau <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mtd: core: Report error if first mtd_otp_size() call fails in mtd_otp_nvmem_add() [+ + +]
Author: Aapo Vienamo <[email protected]>
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 <[email protected]>
    Reviewed-by: Mika Westerberg <[email protected]>
    Reviewed-by: Michael Walle <[email protected]>
    Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support")
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: hynix: fixed typo [+ + +]
Author: Maxim Korotkov <[email protected]>
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 <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
net/9p: fix uninit-value in p9_client_rpc() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Mon Apr 8 07:10:39 2024 -0700

    net/9p: fix uninit-value in p9_client_rpc()
    
    commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a upstream.
    
    Syzbot with the help of KMSAN reported the following error:
    
    BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
    BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
     trace_9p_client_res include/trace/events/9p.h:146 [inline]
     p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
     p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
     v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
     v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
     legacy_get_tree+0x114/0x290 fs/fs_context.c:662
     vfs_get_tree+0xa7/0x570 fs/super.c:1797
     do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
     path_mount+0x742/0x1f20 fs/namespace.c:3679
     do_mount fs/namespace.c:3692 [inline]
     __do_sys_mount fs/namespace.c:3898 [inline]
     __se_sys_mount+0x725/0x810 fs/namespace.c:3875
     __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    Uninit was created at:
     __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
     __alloc_pages_node include/linux/gfp.h:238 [inline]
     alloc_pages_node include/linux/gfp.h:261 [inline]
     alloc_slab_page mm/slub.c:2175 [inline]
     allocate_slab mm/slub.c:2338 [inline]
     new_slab+0x2de/0x1400 mm/slub.c:2391
     ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
     __slab_alloc mm/slub.c:3610 [inline]
     __slab_alloc_node mm/slub.c:3663 [inline]
     slab_alloc_node mm/slub.c:3835 [inline]
     kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
     p9_tag_alloc net/9p/client.c:278 [inline]
     p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
     p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
     p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
     v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
     v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
     legacy_get_tree+0x114/0x290 fs/fs_context.c:662
     vfs_get_tree+0xa7/0x570 fs/super.c:1797
     do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
     path_mount+0x742/0x1f20 fs/namespace.c:3679
     do_mount fs/namespace.c:3692 [inline]
     __do_sys_mount fs/namespace.c:3898 [inline]
     __se_sys_mount+0x725/0x810 fs/namespace.c:3875
     __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag
    will not be properly initialized. However, trace_9p_client_res()
    ends up trying to print it out anyway before p9_client_rpc()
    finishes.
    
    Fix this issue by assigning default values to p9_fcall fields
    such as 'tag' and (just in case KMSAN unearths something new) 'id'
    during the tag allocation stage.
    
    Reported-and-tested-by: [email protected]
    Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Reviewed-by: Christian Schoenebeck <[email protected]>
    Cc: [email protected]
    Message-ID: <[email protected]>
    Signed-off-by: Dominique Martinet <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net/ipv6: Fix route deleting failure when metric equals 0 [+ + +]
Author: xu xin <[email protected]>
Date:   Tue May 14 20:11:02 2024 +0800

    net/ipv6: Fix route deleting failure when metric equals 0
    
    commit bb487272380d120295e955ad8acfcbb281b57642 upstream.
    
    Problem
    =========
    After commit 67f695134703 ("ipv6: Move setting default metric for routes"),
    we noticed that the logic of assigning the default value of fc_metirc
    changed in the ioctl process. That is, when users use ioctl(fd, SIOCADDRT,
    rt) with a non-zero metric to add a route,  then they may fail to delete a
    route with passing in a metric value of 0 to the kernel by ioctl(fd,
    SIOCDELRT, rt). But iproute can succeed in deleting it.
    
    As a reference, when using iproute tools by netlink to delete routes with
    a metric parameter equals 0, like the command as follows:
    
            ip -6 route del fe80::/64 via fe81::5054:ff:fe11:3451 dev eth0 metric 0
    
    the user can still succeed in deleting the route entry with the smallest
    metric.
    
    Root Reason
    ===========
    After commit 67f695134703 ("ipv6: Move setting default metric for routes"),
    When ioctl() pass in SIOCDELRT with a zero metric, rtmsg_to_fib6_config()
    will set a defalut value (1024) to cfg->fc_metric in kernel, and in
    ip6_route_del() and the line 4074 at net/ipv3/route.c, it will check by
    
            if (cfg->fc_metric && cfg->fc_metric != rt->fib6_metric)
                    continue;
    
    and the condition is true and skip the later procedure (deleting route)
    because cfg->fc_metric != rt->fib6_metric. But before that commit,
    cfg->fc_metric is still zero there, so the condition is false and it
    will do the following procedure (deleting).
    
    Solution
    ========
    In order to keep a consistent behaviour across netlink() and ioctl(), we
    should allow to delete a route with a metric value of 0. So we only do
    the default setting of fc_metric in route adding.
    
    CC: [email protected] # 5.4+
    Fixes: 67f695134703 ("ipv6: Move setting default metric for routes")
    Co-developed-by: Fan Yu <[email protected]>
    Signed-off-by: Fan Yu <[email protected]>
    Signed-off-by: xu xin <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net/mlx5: Discard command completions in internal error [+ + +]
Author: Akiva Goldberger <[email protected]>
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 <[email protected]>
    Reviewed-by: Moshe Shemesh <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/mlx5e: Fix IPsec tunnel mode offload feature check [+ + +]
Author: Rahul Rameshbabu <[email protected]>
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 <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net/mlx5e: Use rx_missed_errors instead of rx_dropped for reporting buffer exhaustion [+ + +]
Author: Carolina Jubran <[email protected]>
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 <[email protected]>
    Signed-off-by: Tariq Toukan <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: Always descend into dsa/ folder with CONFIG_NET_DSA enabled [+ + +]
Author: Florian Fainelli <[email protected]>
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 <[email protected]>
    Signed-off-by: Florian Fainelli <[email protected]>
    Reviewed-by: Vladimir Oltean <[email protected]>
    Reviewed-by: Alexander Lobakin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mv88e6xxx: Add support for model-specific pre- and post-reset handlers [+ + +]
Author: Matthias Schiffer <[email protected]>
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 <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches [+ + +]
Author: Matthias Schiffer <[email protected]>
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 <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: sja1105: always enable the INCL_SRCPT option [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Tue Jun 27 12:42:06 2023 +0300

    net: dsa: sja1105: always enable the INCL_SRCPT option
    
    commit b4638af8885af93cd70351081da1909c59342440 upstream.
    
    Link-local traffic on bridged SJA1105 ports is sometimes tagged by the
    hardware with source port information (when the port is under a VLAN
    aware bridge).
    
    The tag_8021q source port identification has become more loose
    ("imprecise") and will report a plausible rather than exact bridge port,
    when under a bridge (be it VLAN-aware or VLAN-unaware). But link-local
    traffic always needs to know the precise source port.
    
    Modify the driver logic (and therefore: the tagging protocol itself) to
    always include the source port information with link-local packets,
    regardless of whether the port is standalone, under a VLAN-aware or
    VLAN-unaware bridge. This makes it possible for the tagging driver to
    give priority to that information over the tag_8021q VLAN header.
    
    The big drawback with INCL_SRCPT is that it makes it impossible to
    distinguish between an original MAC DA of 01:80:C2:XX:YY:ZZ and
    01:80:C2:AA:BB:ZZ, because the tagger just patches MAC DA bytes 3 and 4
    with zeroes. Only if PTP RX timestamping is enabled, the switch will
    generate a META follow-up frame containing the RX timestamp and the
    original bytes 3 and 4 of the MAC DA. Those will be used to patch up the
    original packet. Nonetheless, in the absence of PTP RX timestamping, we
    have to live with this limitation, since it is more important to have
    the more precise source port information for link-local traffic.
    
    Fixes: d7f9787a763f ("net: dsa: tag_8021q: add support for imprecise RX based on the VBID")
    Fixes: 91495f21fcec ("net: dsa: tag_8021q: replace the SVL bridging with VLAN-unaware IVL bridging")
    Signed-off-by: Vladimir Oltean <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Stable-dep-of: c1ae02d87689 ("net: dsa: tag_sja1105: always prefer source port information from INCL_SRCPT")
    Signed-off-by: Vladimir Oltean <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: dsa: tag_sja1105: always prefer source port information from INCL_SRCPT [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Tue Jun 27 12:42:07 2023 +0300

    net: dsa: tag_sja1105: always prefer source port information from INCL_SRCPT
    
    commit c1ae02d876898b1b8ca1e12c6f84d7b406263800 upstream.
    
    Currently the sja1105 tagging protocol prefers using the source port
    information from the VLAN header if that is available, falling back to
    the INCL_SRCPT option if it isn't. The VLAN header is available for all
    frames except for META frames initiated by the switch (containing RX
    timestamps), and thus, the "if (is_link_local)" branch is practically
    dead.
    
    The tag_8021q source port identification has become more loose
    ("imprecise") and will report a plausible rather than exact bridge port,
    when under a bridge (be it VLAN-aware or VLAN-unaware). But link-local
    traffic always needs to know the precise source port. With incorrect
    source port reporting, for example PTP traffic over 2 bridged ports will
    all be seen on sockets opened on the first such port, which is incorrect.
    
    Now that the tagging protocol has been changed to make link-local frames
    always contain source port information, we can reverse the order of the
    checks so that we always give precedence to that information (which is
    always precise) in lieu of the tag_8021q VID which is only precise for a
    standalone port.
    
    Fixes: d7f9787a763f ("net: dsa: tag_8021q: add support for imprecise RX based on the VBID")
    Fixes: 91495f21fcec ("net: dsa: tag_8021q: replace the SVL bridging with VLAN-unaware IVL bridging")
    Signed-off-by: Vladimir Oltean <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    [ Replaced the 2 original Fixes: tags with the correct one.
      Respun the change around the lack of a "vbid", corresponding to DSA
      FDB isolation, which appeared only in v5.18. ]
    Signed-off-by: Vladimir Oltean <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: ena: Add capabilities field with support for ENI stats capability [+ + +]
Author: Arthur Kiyanovski <[email protected]>
Date:   Fri Jan 7 20:23:38 2022 +0000

    net: ena: Add capabilities field with support for ENI stats capability
    
    [ Upstream commit a2d5d6a70fa5211e071747876fa6a7621c7257fd ]
    
    This bitmask field indicates what capabilities are supported by the
    device.
    
    The capabilities field differs from the 'supported_features' field which
    indicates what sub-commands for the set/get feature commands are
    supported. The sub-commands are specified in the 'feature_id' field of
    the 'ena_admin_set_feat_cmd' struct in the following way:
    
            struct ena_admin_set_feat_cmd cmd;
    
            cmd.aq_common_descriptor.opcode = ENA_ADMIN_SET_FEATURE;
            cmd.feat_common.feature_
    
    The 'capabilities' field, on the other hand, specifies different
    capabilities of the device. For example, whether the device supports
    querying of ENI stats.
    
    Also add an enumerator which contains all the capabilities. The
    first added capability macro is for ENI stats feature.
    
    Capabilities are queried along with the other device attributes (in
    ena_com_get_dev_attr_feat()) during device initialization and are stored
    in the ena_com_dev struct. They can be later queried using the
    ena_com_get_cap() helper function.
    
    Signed-off-by: Shay Agroskin <[email protected]>
    Signed-off-by: Arthur Kiyanovski <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 2dc8b1e7177d ("net: ena: Fix redundant device NUMA node override")
    Signed-off-by: Sasha Levin <[email protected]>

net: ena: Add dynamic recycling mechanism for rx buffers [+ + +]
Author: David Arinzon <[email protected]>
Date:   Mon Jun 12 12:14:48 2023 +0000

    net: ena: Add dynamic recycling mechanism for rx buffers
    
    [ Upstream commit f7d625adeb7bc6a9ec83d32d9615889969d64484 ]
    
    The current implementation allocates page-sized rx buffers.
    As traffic may consist of different types and sizes of packets,
    in various cases, buffers are not fully used.
    
    This change (Dynamic RX Buffers - DRB) uses part of the allocated rx
    page needed for the incoming packet, and returns the rest of the
    unused page to be used again as an rx buffer for future packets.
    A threshold of 2K for unused space has been set in order to declare
    whether the remainder of the page can be reused again as an rx buffer.
    
    As a page may be reused, dma_sync_single_for_cpu() is added in order
    to sync the memory to the CPU side after it was owned by the HW.
    In addition, when the rx page can no longer be reused, it is being
    unmapped using dma_page_unmap(), which implicitly syncs and then
    unmaps the entire page. In case the kernel still handles the skbs
    pointing to the previous buffers from that rx page, it may access
    garbage pointers, caused by the implicit sync overwriting them.
    The implicit dma sync is removed by replacing dma_page_unmap() with
    dma_unmap_page_attrs() with DMA_ATTR_SKIP_CPU_SYNC flag.
    
    The functionality is disabled for XDP traffic to avoid handling
    several descriptors per packet.
    
    Signed-off-by: Arthur Kiyanovski <[email protected]>
    Signed-off-by: Shay Agroskin <[email protected]>
    Signed-off-by: David Arinzon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 2dc8b1e7177d ("net: ena: Fix redundant device NUMA node override")
    Signed-off-by: Sasha Levin <[email protected]>

net: ena: Do not waste napi skb cache [+ + +]
Author: Hyeonggon Yoo <[email protected]>
Date:   Sat Jan 29 08:53:36 2022 +0000

    net: ena: Do not waste napi skb cache
    
    [ Upstream commit 7354a426e063e108c0a3590f13abc77573172576 ]
    
    By profiling, discovered that ena device driver allocates skb by
    build_skb() and frees by napi_skb_cache_put(). Because the driver
    does not use napi skb cache in allocation path, napi skb cache is
    periodically filled and flushed. This is waste of napi skb cache.
    
    As ena_alloc_skb() is called only in napi, Use napi_build_skb()
    and napi_alloc_skb() when allocating skb.
    
    This patch was tested on aws a1.metal instance.
    
    [ [email protected]: Use napi_alloc_skb() instead of
      netdev_alloc_skb_ip_align() to keep things consistent. ]
    
    Signed-off-by: Hyeonggon Yoo <[email protected]>
    Acked-by: Shay Agroskin <[email protected]>
    Link: https://lore.kernel.org/r/YfUAkA9BhyOJRT4B@ip-172-31-19-208.ap-northeast-1.compute.internal
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 2dc8b1e7177d ("net: ena: Fix redundant device NUMA node override")
    Signed-off-by: Sasha Levin <[email protected]>

net: ena: Extract recurring driver reset code into a function [+ + +]
Author: Arthur Kiyanovski <[email protected]>
Date:   Fri Jan 7 20:23:46 2022 +0000

    net: ena: Extract recurring driver reset code into a function
    
    [ Upstream commit 9fe890cc5bb84d6859d9a2422830b7fd6fd20521 ]
    
    Create an inline function for resetting the driver
    to reduce code duplication.
    
    Signed-off-by: Nati Koler <[email protected]>
    Signed-off-by: Arthur Kiyanovski <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 2dc8b1e7177d ("net: ena: Fix redundant device NUMA node override")
    Signed-off-by: Sasha Levin <[email protected]>

net: ena: Fix DMA syncing in XDP path when SWIOTLB is on [+ + +]
Author: David Arinzon <[email protected]>
Date:   Mon Dec 11 06:28:00 2023 +0000

    net: ena: Fix DMA syncing in XDP path when SWIOTLB is on
    
    commit d760117060cf2e90b5c59c5492cab179a4dbce01 upstream.
    
    This patch fixes two issues:
    
    Issue 1
    -------
    Description
    ```````````
    Current code does not call dma_sync_single_for_cpu() to sync data from
    the device side memory to the CPU side memory before the XDP code path
    uses the CPU side data.
    This causes the XDP code path to read the unset garbage data in the CPU
    side memory, resulting in incorrect handling of the packet by XDP.
    
    Solution
    ````````
    1. Add a call to dma_sync_single_for_cpu() before the XDP code starts to
       use the data in the CPU side memory.
    2. The XDP code verdict can be XDP_PASS, in which case there is a
       fallback to the non-XDP code, which also calls
       dma_sync_single_for_cpu().
       To avoid calling dma_sync_single_for_cpu() twice:
    2.1. Put the dma_sync_single_for_cpu() in the code in such a place where
         it happens before XDP and non-XDP code.
    2.2. Remove the calls to dma_sync_single_for_cpu() in the non-XDP code
         for the first buffer only (rx_copybreak and non-rx_copybreak
         cases), since the new call that was added covers these cases.
         The call to dma_sync_single_for_cpu() for the second buffer and on
         stays because only the first buffer is handled by the newly added
         dma_sync_single_for_cpu(). And there is no need for special
         handling of the second buffer and on for the XDP path since
         currently the driver supports only single buffer packets.
    
    Issue 2
    -------
    Description
    ```````````
    In case the XDP code forwarded the packet (ENA_XDP_FORWARDED),
    ena_unmap_rx_buff_attrs() is called with attrs set to 0.
    This means that before unmapping the buffer, the internal function
    dma_unmap_page_attrs() will also call dma_sync_single_for_cpu() on
    the whole buffer (not only on the data part of it).
    This sync is both wasteful (since a sync was already explicitly
    called before) and also causes a bug, which will be explained
    using the below diagram.
    
    The following diagram shows the flow of events causing the bug.
    The order of events is (1)-(4) as shown in the diagram.
    
    CPU side memory area
    
         (3)convert_to_xdp_frame() initializes the
            headroom with xdpf metadata
                          ||
                          \/
              ___________________________________
             |                                   |
     0       |                                   V                       4K
     ---------------------------------------------------------------------
     | xdpf->data      | other xdpf       |   < data >   | tailroom ||...|
     |                 | fields           |              | GARBAGE  ||   |
     ---------------------------------------------------------------------
    
                       /\                        /\
                       ||                        ||
       (4)ena_unmap_rx_buff_attrs() calls     (2)dma_sync_single_for_cpu()
          dma_sync_single_for_cpu() on the       copies data from device
          whole buffer page, overwriting         side to CPU side memory
          the xdpf->data with GARBAGE.           ||
     0                                                                   4K
     ---------------------------------------------------------------------
     | headroom                           |   < data >   | tailroom ||...|
     | GARBAGE                            |              | GARBAGE  ||   |
     ---------------------------------------------------------------------
    
    Device side memory area                      /\
                                                 ||
                                   (1) device writes RX packet data
    
    After the call to ena_unmap_rx_buff_attrs() in (4), the xdpf->data
    becomes corrupted, and so when it is later accessed in
    ena_clean_xdp_irq()->xdp_return_frame(), it causes a page fault,
    crashing the kernel.
    
    Solution
    ````````
    Explicitly tell ena_unmap_rx_buff_attrs() not to call
    dma_sync_single_for_cpu() by passing it the ENA_DMA_ATTR_SKIP_CPU_SYNC
    flag.
    
    Fixes: f7d625adeb7b ("net: ena: Add dynamic recycling mechanism for rx buffers")
    Signed-off-by: Arthur Kiyanovski <[email protected]>
    Signed-off-by: David Arinzon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: ena: Fix redundant device NUMA node override [+ + +]
Author: Shay Agroskin <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ena: Reduce lines with longer column width boundary [+ + +]
Author: David Arinzon <[email protected]>
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 <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Stable-dep-of: 2dc8b1e7177d ("net: ena: Fix redundant device NUMA node override")
    Signed-off-by: Sasha Levin <[email protected]>

net: ethernet: cortina: Locking fixes [+ + +]
Author: Linus Walleij <[email protected]>
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 <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: export inet_lookup_reuseport and inet6_lookup_reuseport [+ + +]
Author: Lorenz Bauer <[email protected]>
Date:   Thu Jul 20 17:30:07 2023 +0200

    net: export inet_lookup_reuseport and inet6_lookup_reuseport
    
    [ Upstream commit ce796e60b3b196b61fcc565df195443cbb846ef0 ]
    
    Rename the existing reuseport helpers for IPv4 and IPv6 so that they
    can be invoked in the follow up commit. Export them so that building
    DCCP and IPv6 as a module works.
    
    No change in functionality.
    
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Signed-off-by: Lorenz Bauer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Stable-dep-of: 50aee97d1511 ("udp: Avoid call to compute_score on multiple sites")
    Signed-off-by: Sasha Levin <[email protected]>

net: fec: avoid lock evasion when reading pps_enable [+ + +]
Author: Wei Fang <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: fix __dst_negative_advice() race [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue May 28 11:43:53 2024 +0000

    net: fix __dst_negative_advice() race
    
    commit 92f1655aa2b2294d0b49925f3b875a634bd3b59e upstream.
    
    __dst_negative_advice() does not enforce proper RCU rules when
    sk->dst_cache must be cleared, leading to possible UAF.
    
    RCU rules are that we must first clear sk->sk_dst_cache,
    then call dst_release(old_dst).
    
    Note that sk_dst_reset(sk) is implementing this protocol correctly,
    while __dst_negative_advice() uses the wrong order.
    
    Given that ip6_negative_advice() has special logic
    against RTF_CACHE, this means each of the three ->negative_advice()
    existing methods must perform the sk_dst_reset() themselves.
    
    Note the check against NULL dst is centralized in
    __dst_negative_advice(), there is no need to duplicate
    it in various callbacks.
    
    Many thanks to Clement Lecigne for tracking this issue.
    
    This old bug became visible after the blamed commit, using UDP sockets.
    
    Fixes: a87cb3e48ee8 ("net: Facility to report route quality of connected sockets")
    Reported-by: Clement Lecigne <[email protected]>
    Diagnosed-by: Clement Lecigne <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Tom Herbert <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    [Lee: Stable backport]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: give more chances to rcu in netdev_wait_allrefs_any() [+ + +]
Author: Eric Dumazet <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/T/#m76d73ed6b03cd930778ac4d20a777f22a08d6824
    Reviewed-by: Jiri Pirko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ipv6: fix wrong start position when receive hop-by-hop fragment [+ + +]
Author: gaoxingwang <[email protected]>
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 <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: openvswitch: fix overwriting ct original tuple for ICMPv6 [+ + +]
Author: Ilya Maximets <[email protected]>
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 <[email protected]>
    Closes: https://github.com/openvswitch/ovs-issues/issues/327
    Signed-off-by: Ilya Maximets <[email protected]>
    Acked-by: Aaron Conole <[email protected]>
    Acked-by: Eelco Chaudron <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ8061 [+ + +]
Author: Mathieu Othacehe <[email protected]>
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 <[email protected]>
    Signed-off-by: Mathieu Othacehe <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: qrtr: ns: Fix module refcnt [+ + +]
Author: Chris Lew <[email protected]>
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 <[email protected]>
    Tested-by: Jeffrey Hugo <[email protected]>
    Signed-off-by: Chris Lew <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Jeffrey Hugo <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: remove duplicate reuseport_lookup functions [+ + +]
Author: Lorenz Bauer <[email protected]>
Date:   Thu Jul 20 17:30:08 2023 +0200

    net: remove duplicate reuseport_lookup functions
    
    [ Upstream commit 0f495f7617229772403e683033abc473f0f0553c ]
    
    There are currently four copies of reuseport_lookup: one each for
    (TCP, UDP)x(IPv4, IPv6). This forces us to duplicate all callers of
    those functions as well. This is already the case for sk_lookup
    helpers (inet,inet6,udp4,udp6)_lookup_run_bpf.
    
    There are two differences between the reuseport_lookup helpers:
    
    1. They call different hash functions depending on protocol
    2. UDP reuseport_lookup checks that sk_state != TCP_ESTABLISHED
    
    Move the check for sk_state into the caller and use the INDIRECT_CALL
    infrastructure to cut down the helpers to one per IP version.
    
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Signed-off-by: Lorenz Bauer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Stable-dep-of: 50aee97d1511 ("udp: Avoid call to compute_score on multiple sites")
    Signed-off-by: Sasha Levin <[email protected]>

net: smc91x: Fix m68k kernel compilation for ColdFire CPU [+ + +]
Author: Thorsten Blum <[email protected]>
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: [email protected]
    Fixes: d97cf70af097 ("m68k: use asm-generic/io.h for non-MMU io access functions")
    Signed-off-by: Thorsten Blum <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: usb: qmi_wwan: add Telit FN920C04 compositions [+ + +]
Author: Daniele Palmas <[email protected]>
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 <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: smsc95xx: fix changing LED_SEL bit value updated from EEPROM [+ + +]
Author: Parthiban Veerasooran <[email protected]>
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 <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Woojung Huh <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: smsc95xx: stop lying about skb->truesize [+ + +]
Author: Eric Dumazet <[email protected]>
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/[email protected]/ )
    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 <[email protected]>
    Cc: Steve Glendinning <[email protected]>
    Cc: [email protected]
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: sr9700: stop lying about skb->truesize [+ + +]
Author: Eric Dumazet <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: net:fec: Add fec_enet_deinit() [+ + +]
Author: Xiaolei Wang <[email protected]>
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 <[email protected]>
    Reviewed-by: Wei Fang <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() [+ + +]
Author: Eric Dumazet <[email protected]>
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 <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Acked-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nft_payload: move struct nft_payload_set definition where it belongs [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Wed Sep 28 23:55:06 2022 +0200

    netfilter: nft_payload: move struct nft_payload_set definition where it belongs
    
    [ Upstream commit ac1f8c049319847b1b4c6b387fdb2e3f7fb84ffc ]
    
    Not required to expose this header in nf_tables_core.h, move it to where
    it is used, ie. nft_payload.
    
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Stable-dep-of: 33c563ebf8d3 ("netfilter: nft_payload: skbuff vlan metadata mangle support")
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nft_payload: rebuild vlan header on h_proto access [+ + +]
Author: Florian Westphal <[email protected]>
Date:   Fri Sep 29 10:42:10 2023 +0200

    netfilter: nft_payload: rebuild vlan header on h_proto access
    
    [ Upstream commit af84f9e447a65b4b9f79e7e5d69e19039b431c56 ]
    
    nft can perform merging of adjacent payload requests.
    This means that:
    
    ether saddr 00:11 ... ether type 8021ad ...
    
    is a single payload expression, for 8 bytes, starting at the
    ethernet source offset.
    
    Check that offset+length is fully within the source/destination mac
    addersses.
    
    This bug prevents 'ether type' from matching the correct h_proto in case
    vlan tag got stripped.
    
    Fixes: de6843be3082 ("netfilter: nft_payload: rebuild vlan header when needed")
    Reported-by: David Ward <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Stable-dep-of: 33c563ebf8d3 ("netfilter: nft_payload: skbuff vlan metadata mangle support")
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nft_payload: rebuild vlan header when needed [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue Jun 6 09:38:42 2023 +0200

    netfilter: nft_payload: rebuild vlan header when needed
    
    [ Upstream commit de6843be3082d416eaf2a00b72dad95c784ca980 ]
    
    Skip rebuilding the vlan header when accessing destination and source
    mac address.
    
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Stable-dep-of: 33c563ebf8d3 ("netfilter: nft_payload: skbuff vlan metadata mangle support")
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nft_payload: restore vlan q-in-q match support [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nft_payload: skbuff vlan metadata mangle support [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: tproxy: bail out if IP has been disabled on the device [+ + +]
Author: Florian Westphal <[email protected]>
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: [email protected]
    Fixes: cc6eb4338569 ("tproxy: use the interface primary IP address as a default value for --on-ip")
    Signed-off-by: Florian Westphal <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netrom: fix possible dead-lock in nr_rt_ioctl() [+ + +]
Author: Eric Dumazet <[email protected]>
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 <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfc: nci: Fix handling of zero-length payload packets in nci_rx_work() [+ + +]
Author: Ryosuke Yasuoka <[email protected]>
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 <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nfc: nci: Fix kcov check in nci_rx_work() [+ + +]
Author: Tetsuo Handa <[email protected]>
Date:   Sun May 5 19:36:49 2024 +0900

    nfc: nci: Fix kcov check in nci_rx_work()
    
    [ Upstream commit 19e35f24750ddf860c51e51c68cf07ea181b4881 ]
    
    Commit 7e8cdc97148c ("nfc: Add KCOV annotations") added
    kcov_remote_start_common()/kcov_remote_stop() pair into nci_rx_work(),
    with an assumption that kcov_remote_stop() is called upon continue of
    the for loop. But commit d24b03535e5e ("nfc: nci: Fix uninit-value in
    nci_dev_up and nci_ntf_packet") forgot to call kcov_remote_stop() before
    break of the for loop.
    
    Reported-by: syzbot <[email protected]>
    Closes: https://syzkaller.appspot.com/bug?extid=0438378d6f157baae1a2
    Fixes: d24b03535e5e ("nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet")
    Suggested-by: Andrey Konovalov <[email protected]>
    Signed-off-by: Tetsuo Handa <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 6671e352497c ("nfc: nci: Fix handling of zero-length payload packets in nci_rx_work()")
    Signed-off-by: Sasha Levin <[email protected]>

nfc: nci: Fix uninit-value in nci_rx_work [+ + +]
Author: Ryosuke Yasuoka <[email protected]>
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: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=d7b4dc6cd50410152534 [1]
    Signed-off-by: Ryosuke Yasuoka <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFS: Fix READ_PLUS when server doesn't support OP_READ_PLUS [+ + +]
Author: Anna Schumaker <[email protected]>
Date:   Thu Apr 25 16:24:29 2024 -0400

    NFS: Fix READ_PLUS when server doesn't support OP_READ_PLUS
    
    commit f06d1b10cb016d5aaecdb1804fefca025387bd10 upstream.
    
    Olga showed me a case where the client was sending multiple READ_PLUS
    calls to the server in parallel, and the server replied
    NFS4ERR_OPNOTSUPP to each. The client would fall back to READ for the
    first reply, but fail to retry the other calls.
    
    I fix this by removing the test for NFS_CAP_READ_PLUS in
    nfs4_read_plus_not_supported(). This allows us to reschedule any
    READ_PLUS call that has a NFS4ERR_OPNOTSUPP return value, even after the
    capability has been cleared.
    
    Reported-by: Olga Kornievskaia <[email protected]>
    Fixes: c567552612ec ("NFS: Add READ_PLUS data segment support")
    Cc: [email protected] # v5.10+
    Signed-off-by: Anna Schumaker <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nfs: fix undefined behavior in nfs_block_bits() [+ + +]
Author: Sergey Shtylyov <[email protected]>
Date:   Fri May 10 23:24:04 2024 +0300

    nfs: fix undefined behavior in nfs_block_bits()
    
    commit 3c0a2e0b0ae661457c8505fecc7be5501aa7a715 upstream.
    
    Shifting *signed int* typed constant 1 left by 31 bits causes undefined
    behavior. Specify the correct *unsigned long* type by using 1UL instead.
    
    Found by Linux Verification Center (linuxtesting.org) with the Svace static
    analysis tool.
    
    Cc: [email protected]
    Signed-off-by: Sergey Shtylyov <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
NFSv4: Fixup smatch warning for ambiguous return [+ + +]
Author: Benjamin Coddington <[email protected]>
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 <[email protected]>
    Fixes: c3ed222745d9 ("NFSv4: Fix free of uninitialized nfs4_label on referral lookup.")
    Signed-off-by: Benjamin Coddington <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Reviewed-by: Chuck Lever <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nilfs2: fix out-of-range warning [+ + +]
Author: Arnd Bergmann <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 3358b4aaa84f ("nilfs2: fix problems of memory allocation in ioctl")
    Acked-by: Ryusuke Konishi <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nilfs2: fix potential hang in nilfs_detach_log_writer() [+ + +]
Author: Ryusuke Konishi <[email protected]>
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/[email protected]
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=e3973c409251e136fdd0
    Tested-by: Ryusuke Konishi <[email protected]>
    Cc: <[email protected]>
    Cc: "Bai, Shuangpeng" <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nilfs2: fix unexpected freezing of nilfs_segctor_sync() [+ + +]
Author: Ryusuke Konishi <[email protected]>
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/[email protected]
    Fixes: 9ff05123e3bf ("nilfs2: segment constructor")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Tested-by: Ryusuke Konishi <[email protected]>
    Cc: <[email protected]>
    Cc: "Bai, Shuangpeng" <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

nilfs2: fix use-after-free of timer for log writer thread [+ + +]
Author: Ryusuke Konishi <[email protected]>
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/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: fdce895ea5dd ("nilfs2: change sc_timer from a pointer to an embedded one in struct nilfs_sc_info")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: "Bai, Shuangpeng" <[email protected]>
    Closes: https://groups.google.com/g/syzkaller/c/MK_LYqtt8ko/m/8rgdWeseAwAJ
    Tested-by: Ryusuke Konishi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
null_blk: Fix missing mutex_destroy() at module removal [+ + +]
Author: Zhu Yanjun <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

null_blk: Fix the WARNING: modpost: missing MODULE_DESCRIPTION() [+ + +]
Author: Zhu Yanjun <[email protected]>
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 <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme: find numa distance only if controller has valid numa id [+ + +]
Author: Nilay Shroff <[email protected]>
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/[email protected]/
    Signed-off-by: Nilay Shroff <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvmet: fix ns enable/disable possible hang [+ + +]
Author: Sagi Grimberg <[email protected]>
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 <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
openpromfs: finish conversion to the new mount API [+ + +]
Author: Eric Sandeen <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
openvswitch: Set the skbuff pkt_type for proper pmtud support. [+ + +]
Author: Aaron Conole <[email protected]>
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 <[email protected]>
    Reported-at: https://issues.redhat.com/browse/FDP-164
    Fixes: 58264848a5a7 ("openvswitch: Add vxlan tunneling support.")
    Signed-off-by: Aaron Conole <[email protected]>
    Acked-by: Eelco Chaudron <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
parisc: add missing export of __cmpxchg_u8() [+ + +]
Author: Al Viro <[email protected]>
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 <[email protected]>
    Signed-off-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI/EDR: Align EDR_PORT_DPC_ENABLE_DSM with PCI Firmware r3.3 [+ + +]
Author: Kuppuswamy Sathyanarayanan <[email protected]>
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 <[email protected]>
    [bhelgaas: split into two patches, update commit log]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Tested-by: Satish Thatchanamurthy <[email protected]> # one platform
    Signed-off-by: Sasha Levin <[email protected]>

PCI/EDR: Align EDR_PORT_LOCATE_DSM with PCI Firmware r3.3 [+ + +]
Author: Kuppuswamy Sathyanarayanan <[email protected]>
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 <[email protected]>
    [bhelgaas: split into two patches, update commit log]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Tested-by: Satish Thatchanamurthy <[email protected]> # one platform
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI: tegra194: Fix probe path for Endpoint mode [+ + +]
Author: Vidya Sagar <[email protected]>
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/[email protected]
    Signed-off-by: Vidya Sagar <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Reviewed-by: Jon Hunter <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/fsl-soc: hide unused const variable [+ + +]
Author: Arnd Bergmann <[email protected]>
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 <[email protected]>
    Reviewed-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/pseries: Add failure related checks for h_get_mpp and h_get_ppp [+ + +]
Author: Shrikanth Hegde <[email protected]>
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 <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
ppdev: Add an error check in register_device [+ + +]
Author: Huai-Yuan Liu <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ppdev: Remove usage of the deprecated ida_simple_xx() API [+ + +]
Author: Christophe JAILLET <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/ba9da12fdd5cdb2c28180b7160af5042447d803f.1702962092.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: fbf740aeb86a ("ppdev: Add an error check in register_device")
    Signed-off-by: Sasha Levin <[email protected]>

 
printk: Let no_printk() use _printk() [+ + +]
Author: Geert Uytterhoeven <[email protected]>
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 <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Xiubo Li <[email protected]>
    Reviewed-by: Chris Down <[email protected]>
    Reviewed-by: Petr Mladek <[email protected]>
    Link: https://lore.kernel.org/r/56cf92edccffea970e1f40a075334dd6cf5bb2a4.1709127473.git.geert+renesas@glider.be
    Signed-off-by: Petr Mladek <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pwm: sti: Convert to platform remove callback returning void [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Fri Mar 3 19:54:38 2023 +0100

    pwm: sti: Convert to platform remove callback returning void
    
    [ Upstream commit e13cec3617c6ace4fc389b60d2a7d5b305b62683 ]
    
    The .remove() callback for a platform driver returns an int which makes
    many driver authors wrongly assume it's possible to do error handling by
    returning an error code. However the value returned is (mostly) ignored
    and this typically results in resource leaks. To improve here there is a
    quest to make the remove callback return void. In the first step of this
    quest all drivers are converted to .remove_new() which already returns
    void.
    
    Trivially convert this driver from always returning zero in the remove
    callback to the void returning variant.
    
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Stable-dep-of: 5bb0b194aeee ("pwm: sti: Simplify probe function using devm functions")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: sti: Prepare removing pwm_chip from driver data [+ + +]
Author: Uwe Kleine-König <[email protected]>
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 <[email protected]>
    Stable-dep-of: 5bb0b194aeee ("pwm: sti: Simplify probe function using devm functions")
    Signed-off-by: Sasha Levin <[email protected]>

pwm: sti: Simplify probe function using devm functions [+ + +]
Author: Uwe Kleine-König <[email protected]>
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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
qed: avoid truncating work queue length [+ + +]
Author: Arnd Bergmann <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
r8169: Fix possible ring buffer corruption on fragmented Tx packets. [+ + +]
Author: Ken Milmore <[email protected]>
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: [email protected]
    Signed-off-by: Ken Milmore <[email protected]>
    Reviewed-by: Heiner Kallweit <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
RDMA/hns: Fix deadlock on SRQ async events. [+ + +]
Author: Chengchang Tang <[email protected]>
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 <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix GMV table pagesize [+ + +]
Author: Chengchang Tang <[email protected]>
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 <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix return value in hns_roce_map_mr_sg [+ + +]
Author: Zhengchao Shao <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Junxian Huang <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Modify the print level of CQE error [+ + +]
Author: Chengchang Tang <[email protected]>
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 <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Use complete parentheses in macros [+ + +]
Author: Chengchang Tang <[email protected]>
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 <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/IPoIB: Fix format truncation compilation errors [+ + +]
Author: Leon Romanovsky <[email protected]>
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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/mlx5: Adding remote atomic access flag to updatable flags [+ + +]
Author: Or Har-Toov <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/24dac73e2fa48cb806f33a932d97f3e402a5ea2c.1712140377.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
regulator: bd71828: Don't overwrite runtime voltages [+ + +]
Author: Matti Vaittinen <[email protected]>
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 <[email protected]>
    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 <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

regulator: irq_helpers: duplicate IRQ name [+ + +]
Author: Matti Vaittinen <[email protected]>
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 <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

regulator: vqmmc-ipq4019: fix module autoloading [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
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 <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "drm/amdgpu: init iommu after amdkfd device init" [+ + +]
Author: Armin Wolf <[email protected]>
Date:   Thu May 23 19:30:31 2024 +0200

    Revert "drm/amdgpu: init iommu after amdkfd device init"
    
    This reverts commit 56b522f4668167096a50c39446d6263c96219f5f.
    
    A user reported that this commit breaks the integrated gpu of his
    notebook, causing a black screen. He was able to bisect the problematic
    commit and verified that by reverting it the notebook works again.
    He also confirmed that kernel 6.8.1 also works on his device, so the
    upstream commit itself seems to be ok.
    
    An amdgpu developer (Alex Deucher) confirmed that this patch should
    have never been ported to 5.15 in the first place, so revert this
    commit from the 5.15 stable series.
    
    Reported-by: Barry Kauler <[email protected]>
    Signed-off-by: Armin Wolf <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "r8169: don't try to disable interrupts if NAPI is, scheduled already" [+ + +]
Author: Heiner Kallweit <[email protected]>
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: [email protected]
    Reported-by: Ken Milmore <[email protected]>
    Signed-off-by: Heiner Kallweit <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "sh: Handle calling csum_partial with misaligned data" [+ + +]
Author: Guenter Roeck <[email protected]>
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 <[email protected]>
    Tested-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ring-buffer: Fix a race between readers and resize checks [+ + +]
Author: Petr Pavlu <[email protected]>
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/[email protected]
    
    Cc: [email protected]
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Mathieu Desnoyers <[email protected]>
    Fixes: 659f451ff213 ("ring-buffer: Add integrity check at end of iter read")
    Signed-off-by: Petr Pavlu <[email protected]>
    [ Fixed whitespace ]
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
riscv: stacktrace: fixed walk_stackframe() [+ + +]
Author: Matthew Bystrin <[email protected]>
Date:   Tue May 21 22:13:13 2024 +0300

    riscv: stacktrace: fixed walk_stackframe()
    
    [ Upstream commit a2a4d4a6a0bf5eba66f8b0b32502cc20d82715a0 ]
    
    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/[email protected]/
    [2] https://lore.kernel.org/linux-riscv/[email protected]/
    
    Fixes: f766f77a74f5 ("riscv/stacktrace: Fix stack output without ra on the stack top")
    Signed-off-by: Matthew Bystrin <[email protected]>
    Reviewed-by: Samuel Holland <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

riscv: stacktrace: Make walk_stackframe cross pt_regs frame [+ + +]
Author: Guo Ren <[email protected]>
Date:   Wed Nov 9 01:49:37 2022 -0500

    riscv: stacktrace: Make walk_stackframe cross pt_regs frame
    
    [ Upstream commit 7ecdadf7f8c659524f6b2aebf6be7bf619764d90 ]
    
    The current walk_stackframe with FRAME_POINTER would stop unwinding at
    ret_from_exception:
      BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1518
      in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: init
      CPU: 0 PID: 1 Comm: init Not tainted 5.10.113-00021-g15c15974895c-dirty #192
      Call Trace:
      [<ffffffe0002038c8>] walk_stackframe+0x0/0xee
      [<ffffffe000aecf48>] show_stack+0x32/0x4a
      [<ffffffe000af1618>] dump_stack_lvl+0x72/0x8e
      [<ffffffe000af1648>] dump_stack+0x14/0x1c
      [<ffffffe000239ad2>] ___might_sleep+0x12e/0x138
      [<ffffffe000239aec>] __might_sleep+0x10/0x18
      [<ffffffe000afe3fe>] down_read+0x22/0xa4
      [<ffffffe000207588>] do_page_fault+0xb0/0x2fe
      [<ffffffe000201b80>] ret_from_exception+0x0/0xc
    
    The optimization would help walk_stackframe cross the pt_regs frame and
    get more backtrace of debug info:
      BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1518
      in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: init
      CPU: 0 PID: 1 Comm: init Not tainted 5.10.113-00021-g15c15974895c-dirty #192
      Call Trace:
      [<ffffffe0002038c8>] walk_stackframe+0x0/0xee
      [<ffffffe000aecf48>] show_stack+0x32/0x4a
      [<ffffffe000af1618>] dump_stack_lvl+0x72/0x8e
      [<ffffffe000af1648>] dump_stack+0x14/0x1c
      [<ffffffe000239ad2>] ___might_sleep+0x12e/0x138
      [<ffffffe000239aec>] __might_sleep+0x10/0x18
      [<ffffffe000afe3fe>] down_read+0x22/0xa4
      [<ffffffe000207588>] do_page_fault+0xb0/0x2fe
      [<ffffffe000201b80>] ret_from_exception+0x0/0xc
      [<ffffffe000613c06>] riscv_intc_irq+0x1a/0x72
      [<ffffffe000201b80>] ret_from_exception+0x0/0xc
      [<ffffffe00033f44a>] vma_link+0x54/0x160
      [<ffffffe000341d7a>] mmap_region+0x2cc/0x4d0
      [<ffffffe000342256>] do_mmap+0x2d8/0x3ac
      [<ffffffe000326318>] vm_mmap_pgoff+0x70/0xb8
      [<ffffffe00032638a>] vm_mmap+0x2a/0x36
      [<ffffffe0003cfdde>] elf_map+0x72/0x84
      [<ffffffe0003d05f8>] load_elf_binary+0x69a/0xec8
      [<ffffffe000376240>] bprm_execve+0x246/0x53a
      [<ffffffe00037786c>] kernel_execve+0xe8/0x124
      [<ffffffe000aecdf2>] run_init_process+0xfa/0x10c
      [<ffffffe000aece16>] try_to_run_init_process+0x12/0x3c
      [<ffffffe000afa920>] kernel_init+0xb4/0xf8
      [<ffffffe000201b80>] ret_from_exception+0x0/0xc
    
    Here is the error injection test code for the above output:
     drivers/irqchip/irq-riscv-intc.c:
     static asmlinkage void riscv_intc_irq(struct pt_regs *regs)
     {
            unsigned long cause = regs->cause & ~CAUSE_IRQ_FLAG;
    +       u32 tmp; __get_user(tmp, (u32 *)0);
    
    Signed-off-by: Guo Ren <[email protected]>
    Signed-off-by: Guo Ren <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [Palmer: use SYM_CODE_*]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Stable-dep-of: a2a4d4a6a0bf ("riscv: stacktrace: fixed walk_stackframe()")
    Signed-off-by: Sasha Levin <[email protected]>

 
rpcrdma: fix handling for RDMA_CM_EVENT_DEVICE_REMOVAL [+ + +]
Author: Dan Aloni <[email protected]>
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 <[email protected]>
    Signed-off-by: Dan Aloni <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Chuck Lever <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/ap: Fix crash in AP internal function modify_bitmap() [+ + +]
Author: Harald Freudenberger <[email protected]>
Date:   Mon May 13 14:49:13 2024 +0200

    s390/ap: Fix crash in AP internal function modify_bitmap()
    
    commit d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9 upstream.
    
    A system crash like this
    
      Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
      Fault in home space mode while using kernel ASCE.
      AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
      Oops: 0038 ilc:3 [#1] PREEMPT SMP
      Modules linked in: mlx5_ib ...
      CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
      Hardware name: IBM 3931 A01 704 (LPAR)
      Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
      R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
      Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
      000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
      000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
      000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
      Krnl Code: 0000014b75e7b5fc: a7840047            brc     8,0000014b75e7b68a
      0000014b75e7b600: 18b2                lr      %r11,%r2
      #0000014b75e7b602: a7f4000a            brc     15,0000014b75e7b616
      >0000014b75e7b606: eb22d00000e6        laog    %r2,%r2,0(%r13)
      0000014b75e7b60c: a7680001            lhi     %r6,1
      0000014b75e7b610: 187b                lr      %r7,%r11
      0000014b75e7b612: 84960021            brxh    %r9,%r6,0000014b75e7b654
      0000014b75e7b616: 18e9                lr      %r14,%r9
      Call Trace:
      [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
      ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
      [<0000014b75e7b758>] apmask_store+0x68/0x140
      [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
      [<0000014b75598524>] vfs_write+0x1b4/0x448
      [<0000014b7559894c>] ksys_write+0x74/0x100
      [<0000014b7618a440>] __do_syscall+0x268/0x328
      [<0000014b761a3558>] system_call+0x70/0x98
      INFO: lockdep is turned off.
      Last Breaking-Event-Address:
      [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
      Kernel panic - not syncing: Fatal exception: panic_on_oops
    
    occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
    (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
    
    The fix is simple: use unsigned long values for the internal variables. The
    correct checks are already in place in the function but a simple int for
    the internal variables was used with the possibility to overflow.
    
    Reported-by: Marc Hartmayer <[email protected]>
    Signed-off-by: Harald Freudenberger <[email protected]>
    Tested-by: Marc Hartmayer <[email protected]>
    Reviewed-by: Holger Dengler <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
s390/boot: Remove alt_stfle_fac_list from decompressor [+ + +]
Author: Sven Schnelle <[email protected]>
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 <[email protected]>
    Signed-off-by: Sven Schnelle <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/bpf: Emit a barrier for BPF_FETCH instructions [+ + +]
Author: Ilya Leoshkevich <[email protected]>
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 <[email protected]>
    Closes: https://lore.kernel.org/bpf/[email protected]/
    Signed-off-by: Ilya Leoshkevich <[email protected]>
    Reviewed-by: Puranjay Mohan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/cio: fix tracepoint subchannel type field [+ + +]
Author: Peter Oberparleiter <[email protected]>
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 <[email protected]>
    Signed-off-by: Peter Oberparleiter <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/cpacf: Make use of invalid opcode produce a link error [+ + +]
Author: Harald Freudenberger <[email protected]>
Date:   Tue May 14 10:09:32 2024 +0200

    s390/cpacf: Make use of invalid opcode produce a link error
    
    commit 32e8bd6423fc127d2b37bdcf804fd76af3bbec79 upstream.
    
    Instead of calling BUG() at runtime introduce and use a prototype for a
    non-existing function to produce a link error during compile when a not
    supported opcode is used with the __cpacf_query() or __cpacf_check_opcode()
    inline functions.
    
    Suggested-by: Heiko Carstens <[email protected]>
    Signed-off-by: Harald Freudenberger <[email protected]>
    Reviewed-by: Holger Dengler <[email protected]>
    Reviewed-by: Juergen Christ <[email protected]>
    Cc: [email protected]
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

s390/cpacf: Split and rework cpacf query functions [+ + +]
Author: Harald Freudenberger <[email protected]>
Date:   Fri May 3 11:31:42 2024 +0200

    s390/cpacf: Split and rework cpacf query functions
    
    commit 830999bd7e72f4128b9dfa37090d9fa8120ce323 upstream.
    
    Rework the cpacf query functions to use the correct RRE
    or RRF instruction formats and set register fields within
    instructions correctly.
    
    Fixes: 1afd43e0fbba ("s390/crypto: allow to query all known cpacf functions")
    Reported-by: Nina Schoetterl-Glausch <[email protected]>
    Suggested-by: Heiko Carstens <[email protected]>
    Suggested-by: Juergen Christ <[email protected]>
    Suggested-by: Holger Dengler <[email protected]>
    Signed-off-by: Harald Freudenberger <[email protected]>
    Reviewed-by: Holger Dengler <[email protected]>
    Reviewed-by: Juergen Christ <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
s390/ipl: Fix incorrect initialization of len fields in nvme reipl block [+ + +]
Author: Alexander Egorenkov <[email protected]>
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 <[email protected]>
    Signed-off-by: Alexander Egorenkov <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

s390/ipl: Fix incorrect initialization of nvme dump block [+ + +]
Author: Alexander Egorenkov <[email protected]>
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 <[email protected]>
    Signed-off-by: Alexander Egorenkov <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/vdso64: filter out munaligned-symbols flag for vdso [+ + +]
Author: Sumanth Korikkar <[email protected]>
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 <[email protected]>
    Signed-off-by: Sumanth Korikkar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Carstens <[email protected]>
    Stable-dep-of: 10f705253651 ("s390/vdso: Generate unwind information for C modules")
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/vdso: filter out mno-pic-data-is-text-relative cflag [+ + +]
Author: Sumanth Korikkar <[email protected]>
Date:   Fri Jun 23 15:12:05 2023 +0200

    s390/vdso: filter out mno-pic-data-is-text-relative cflag
    
    [ Upstream commit d15e4314abec83e4f910659437bc809b0889e3a5 ]
    
    cmd_vdso_check checks if there are any dynamic relocations in
    vdso64.so.dbg. When kernel is compiled with
    -mno-pic-data-is-text-relative, R_390_RELATIVE relocs are generated and
    this results in kernel build error.
    
    kpatch uses -mno-pic-data-is-text-relative option when building the
    kernel to prevent relative addressing between code and data. The flag
    avoids relocation error when klp text and data are too far apart
    
    kpatch does not patch vdso code and hence the
    mno-pic-data-is-text-relative flag is not essential.
    
    Signed-off-by: Sumanth Korikkar <[email protected]>
    Acked-by: Ilya Leoshkevich <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Stable-dep-of: 10f705253651 ("s390/vdso: Generate unwind information for C modules")
    Signed-off-by: Sasha Levin <[email protected]>

s390/vdso: Generate unwind information for C modules [+ + +]
Author: Jens Remus <[email protected]>
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 <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

s390/vdso: Use standard stack frame layout [+ + +]
Author: Heiko Carstens <[email protected]>
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 <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sched/core: Fix incorrect initialization of the 'burst' parameter in cpu_max_write() [+ + +]
Author: Cheng Yu <[email protected]>
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 <[email protected]>
    Signed-off-by: Cheng Yu <[email protected]>
    Signed-off-by: Zhang Qiao <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Reviewed-by: Vincent Guittot <[email protected]>
    Tested-by: Vincent Guittot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
sched/fair: Add EAS checks before updating root_domain::overutilized [+ + +]
Author: Shrikanth Hegde <[email protected]>
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 <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Reviewed-by: Qais Yousef <[email protected]>
    Reviewed-by: Srikar Dronamraju <[email protected]>
    Reviewed-by: Vincent Guittot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

sched/fair: Allow disabling sched_balance_newidle with sched_relax_domain_level [+ + +]
Author: Vitalii Bursov <[email protected]>
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 <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Tested-by: Dietmar Eggemann <[email protected]>
    Reviewed-by: Vincent Guittot <[email protected]>
    Reviewed-by: Valentin Schneider <[email protected]>
    Link: https://lore.kernel.org/r/bd6de28e80073c79466ec6401cdeae78f0d4423d.1714488502.git.vitaly@bursov.com
    Signed-off-by: Sasha Levin <[email protected]>

 
scripts/gdb: fix SB_* constants parsing [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Wed Jun 7 15:13:35 2023 -0700

    scripts/gdb: fix SB_* constants parsing
    
    commit 6a59cb5158bff13b80f116305155fbe4967a5010 upstream.
    
    --0000000000009a0c9905fd9173ad
    Content-Transfer-Encoding: 8bit
    
    After f15afbd34d8f ("fs: fix undefined behavior in bit shift for
    SB_NOUSER") the constants were changed from plain integers which
    LX_VALUE() can parse to constants using the BIT() macro which causes the
    following:
    
    Reading symbols from build/linux-custom/vmlinux...done.
    Traceback (most recent call last):
      File "/home/fainelli/work/buildroot/output/arm64/build/linux-custom/vmlinux-gdb.py", line 25, in <module>
        import linux.constants
      File "/home/fainelli/work/buildroot/output/arm64/build/linux-custom/scripts/gdb/linux/constants.py", line 5
        LX_SB_RDONLY = ((((1UL))) << (0))
    
    Use LX_GDBPARSED() which does not suffer from that issue.
    
    f15afbd34d8f ("fs: fix undefined behavior in bit shift for SB_NOUSER")
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Florian Fainelli <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Cc: Hao Ge <[email protected]>
    Cc: Jan Kiszka <[email protected]>
    Cc: Kieran Bingham <[email protected]>
    Cc: Luis Chamberlain <[email protected]>
    Cc: Pankaj Raghav <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
scsi: bfa: Ensure the copied buf is NUL terminated [+ + +]
Author: Bui Quang Minh <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: hpsa: Fix allocation size for Scsi_Host private data [+ + +]
Author: Yuri Karpov <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: libsas: Fix the failure of adding phy with zero-address to port [+ + +]
Author: Xingui Yang <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qedf: Ensure the copied buf is NUL terminated [+ + +]
Author: Bui Quang Minh <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qla2xxx: Fix debugfs output for fw_resource_count [+ + +]
Author: Himanshu Madhani <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qla2xxx: Replace all non-returning strlcpy() with strscpy() [+ + +]
Author: Azeem Shaikh <[email protected]>
Date:   Tue May 16 02:54:04 2023 +0000

    scsi: qla2xxx: Replace all non-returning strlcpy() with strscpy()
    
    [ Upstream commit 37f1663c91934f664fb850306708094a324c227c ]
    
    strlcpy() reads the entire source buffer first.  This read may exceed the
    destination size limit.  This is both inefficient and can lead to linear
    read overflows if a source string is not NUL-terminated [1].  In an effort
    to remove strlcpy() completely [2], replace strlcpy() here with strscpy().
    No return values were used, so direct replacement is safe.
    
    [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
    [2] https://github.com/KSPP/linux/issues/89
    
    Signed-off-by: Azeem Shaikh <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Kees Cook <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Stable-dep-of: c3408c4ae041 ("scsi: qla2xxx: Avoid possible run-time warning with long model_num")
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: cdns-pltfrm: Perform read back after writing HCLKDIV [+ + +]
Author: Andrew Halaney <[email protected]>
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 <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-6-181252004586@redhat.com
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Perform read back after disabling interrupts [+ + +]
Author: Andrew Halaney <[email protected]>
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 <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Reviewed-by: Can Guo <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-8-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Perform read back after disabling UIC_COMMAND_COMPL [+ + +]
Author: Andrew Halaney <[email protected]>
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 <[email protected]>
    Reviewed-by: Can Guo <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-9-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: qcom: Perform read back after writing CGC enable [+ + +]
Author: Andrew Halaney <[email protected]>
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 <[email protected]>
    Reviewed-by: Can Guo <[email protected]>
    Fixes: 81c0fc51b7a7 ("ufs-qcom: add support for Qualcomm Technologies Inc platforms")
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-5-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: qcom: Perform read back after writing REG_UFS_SYS1CLK_1US [+ + +]
Author: Andrew Halaney <[email protected]>
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 <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-2-181252004586@redhat.com
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: qcom: Perform read back after writing reset bit [+ + +]
Author: Andrew Halaney <[email protected]>
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 <[email protected]>
    Reviewed-by: Can Guo <[email protected]>
    Signed-off-by: Andrew Halaney <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-1-181252004586@redhat.com
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: qcom: Perform read back after writing unipro mode [+ + +]
Author: Andrew Halaney <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-4-181252004586@redhat.com
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: ufs-qcom: Clear qunipro_g4_sel for HW major version > 5 [+ + +]
Author: Neil Armstrong <[email protected]>
Date:   Mon Aug 21 14:11:21 2023 +0200

    scsi: ufs: ufs-qcom: Clear qunipro_g4_sel for HW major version > 5
    
    commit c422fbd5cb58c9a078172ae1e9750971b738a197 upstream.
    
    The qunipro_g4_sel clear is also needed for new platforms with major
    version > 5. Fix the version check to take this into account.
    
    Fixes: 9c02aa24bf40 ("scsi: ufs: ufs-qcom: Clear qunipro_g4_sel for HW version major 5")
    Acked-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Nitin Rawat <[email protected]>
    Signed-off-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/20230821-topic-sm8x50-upstream-ufs-major-5-plus-v2-1-f42a4b712e58@linaro.org
    Reviewed-by: "Bao D. Nguyen" <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: ufs: ufs-qcom: Clear qunipro_g4_sel for HW version major 5 [+ + +]
Author: Abel Vesa <[email protected]>
Date:   Thu Jan 19 17:14:05 2023 +0200

    scsi: ufs: ufs-qcom: Clear qunipro_g4_sel for HW version major 5
    
    [ Upstream commit 9c02aa24bf404a39ec509d9f50539056b9b128f7 ]
    
    On SM8550, depending on the Qunipro, we can run with G5 or G4.  For now,
    when the major version is 5 or above, we go with G5.  Therefore, we need to
    specifically tell UFS HC that.
    
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Stable-dep-of: 823150ecf04f ("scsi: ufs: qcom: Perform read back after writing unipro mode")
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: ufs-qcom: Fix the Qcom register name for offset 0xD0 [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Thu Dec 22 19:39:55 2022 +0530

    scsi: ufs: ufs-qcom: Fix the Qcom register name for offset 0xD0
    
    [ Upstream commit 7959587f3284bf163e4f1baff3c6fa71fc6a55b1 ]
    
    On newer UFS revisions, the register at offset 0xD0 is called,
    REG_UFS_PARAM0. Since the existing register, RETRY_TIMER_REG is not used
    anywhere, it is safe to use the new name.
    
    Reviewed-by: Andrew Halaney <[email protected]>
    Reviewed-by: Asutosh Das <[email protected]>
    Tested-by: Andrew Halaney <[email protected]> # Qdrive3/sa8540p-ride
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Stable-dep-of: 823150ecf04f ("scsi: ufs: qcom: Perform read back after writing unipro mode")
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/binderfs: use the Makefile's rules, not Make's implicit rules [+ + +]
Author: John Hubbard <[email protected]>
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 <[email protected]>
    Signed-off-by: John Hubbard <[email protected]>
    Reviewed-by: Christian Brauner <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/bpf: Fix umount cgroup2 error in test_sockmap [+ + +]
Author: Geliang Tang <[email protected]>
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 <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/r/0399983bde729708773416b8488bac2cd5e022b8.1712639568.git.tanggeliang@kylinos.cn
    Signed-off-by: Martin KaFai Lau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/kcmp: Make the test output consistent and clear [+ + +]
Author: Gautam Menghani <[email protected]>
Date:   Thu Jun 30 00:58:22 2022 +0530

    selftests/kcmp: Make the test output consistent and clear
    
    [ Upstream commit ff682226a353d88ffa5db9c2a9b945066776311e ]
    
    Make the output format of this test consistent. Currently the output is
    as follows:
    
    +TAP version 13
    +1..1
    +# selftests: kcmp: kcmp_test
    +# pid1:  45814 pid2:  45815 FD:  1 FILES:  1 VM:  2 FS:  1 SIGHAND:  2
    +  IO:  0 SYSVSEM:  0 INV: -1
    +# PASS: 0 returned as expected
    +# PASS: 0 returned as expected
    +# PASS: 0 returned as expected
    +# # Planned tests != run tests (0 != 3)
    +# # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0
    +# # Planned tests != run tests (0 != 3)
    +# # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0
    +# # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
    +ok 1 selftests: kcmp: kcmp_test
    
    With this patch applied the output is as follows:
    
    +TAP version 13
    +1..1
    +# selftests: kcmp: kcmp_test
    +# TAP version 13
    +# 1..3
    +# pid1:  46330 pid2:  46331 FD:  1 FILES:  2 VM:  2 FS:  2 SIGHAND:  1
    +  IO:  0 SYSVSEM:  0 INV: -1
    +# PASS: 0 returned as expected
    +# PASS: 0 returned as expected
    +# PASS: 0 returned as expected
    +# # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0
    +ok 1 selftests: kcmp: kcmp_test
    
    Signed-off-by: Gautam Menghani <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Stable-dep-of: eb59a5811371 ("selftests/kcmp: remove unused open mode")
    Signed-off-by: Sasha Levin <[email protected]>

selftests/kcmp: remove unused open mode [+ + +]
Author: Edward Liaw <[email protected]>
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/[email protected]
    Fixes: d97b46a64674 ("syscalls, x86: add __NR_kcmp syscall")
    Signed-off-by: Edward Liaw <[email protected]>
    Reviewed-by: Cyrill Gorcunov <[email protected]>
    Cc: Eric Biederman <[email protected]>
    Cc: Shuah Khan <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/resctrl: fix clang build failure: use LOCAL_HDRS [+ + +]
Author: John Hubbard <[email protected]>
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 <[email protected]>
    Signed-off-by: John Hubbard <[email protected]>
    Acked-by: Reinette Chatre <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests: net: bridge: increase IGMP/MLD exclude timeout membership interval [+ + +]
Author: Nikolay Aleksandrov <[email protected]>
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 <[email protected]>
    Signed-off-by: Nikolay Aleksandrov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

selftests: sud_test: return correct emulated syscall value on RISC-V [+ + +]
Author: Clément Léger <[email protected]>
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 <[email protected]>
    Reviewed-by: Palmer Dabbelt <[email protected]>
    Acked-by: Palmer Dabbelt <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
serial: 8250_bcm7271: use default_mux_rate if possible [+ + +]
Author: Doug Berger <[email protected]>
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: [email protected]
    Signed-off-by: Doug Berger <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

serial: max3100: Fix bitwise types [+ + +]
Author: Andy Shevchenko <[email protected]>
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 types for the respective variables.
    
    Fixes: 7831d56b0a35 ("tty: MAX3100")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

serial: max3100: Lock port->lock when calling uart_handle_cts_change() [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Tue Apr 2 22:50:28 2024 +0300

    serial: max3100: Lock port->lock when calling uart_handle_cts_change()
    
    [ Upstream commit 77ab53371a2066fdf9b895246505f5ef5a4b5d47 ]
    
    uart_handle_cts_change() has to be called with port lock taken,
    Since we run it in a separate work, the lock may not be taken at
    the time of running. Make sure that it's taken by explicitly doing
    that. Without it we got a splat:
    
      WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
      ...
      Workqueue: max3100-0 max3100_work [max3100]
      RIP: 0010:uart_handle_cts_change+0xa6/0xb0
      ...
       max3100_handlerx+0xc5/0x110 [max3100]
       max3100_work+0x12a/0x340 [max3100]
    
    Fixes: 7831d56b0a35 ("tty: MAX3100")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

serial: max3100: Update uart_driver_registered on driver removal [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Tue Apr 2 22:50:29 2024 +0300

    serial: max3100: Update uart_driver_registered on driver removal
    
    [ Upstream commit 712a1fcb38dc7cac6da63ee79a88708fbf9c45ec ]
    
    The removal of the last MAX3100 device triggers the removal of
    the driver. However, code doesn't update the respective global
    variable and after insmod — rmmod — insmod cycle the kernel
    oopses:
    
      max3100 spi-PRP0001:01: max3100_probe: adding port 0
      BUG: kernel NULL pointer dereference, address: 0000000000000408
      ...
      RIP: 0010:serial_core_register_port+0xa0/0x840
      ...
       max3100_probe+0x1b6/0x280 [max3100]
       spi_probe+0x8d/0xb0
    
    Update the actual state so next time UART driver will be registered
    again.
    
    Hugo also noticed, that the error path in the probe also affected
    by having the variable set, and not cleared. Instead of clearing it
    move the assignment after the successfull uart_register_driver() call.
    
    Fixes: 7831d56b0a35 ("tty: MAX3100")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Reviewed-by: Hugo Villeneuve <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

serial: sc16is7xx: add proper sched.h include for sched_set_fifo() [+ + +]
Author: Hugo Villeneuve <[email protected]>
Date:   Tue Apr 9 11:42:49 2024 -0400

    serial: sc16is7xx: add proper sched.h include for sched_set_fifo()
    
    [ Upstream commit 2a8e4ab0c93fad30769479f86849e22d63cd0e12 ]
    
    Replace incorrect include with the proper one for sched_set_fifo()
    declaration.
    
    Fixes: 28d2f209cd16 ("sched,serial: Convert to sched_set_fifo()")
    Signed-off-by: Hugo Villeneuve <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

serial: sh-sci: protect invalidating RXDMA on shutdown [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Mon May 6 13:40:17 2024 +0200

    serial: sh-sci: protect invalidating RXDMA on shutdown
    
    [ Upstream commit aae20f6e34cd0cbd67a1d0e5877561c40109a81b ]
    
    The to-be-fixed commit removed locking when invalidating the DMA RX
    descriptors on shutdown. It overlooked that there is still a rx_timer
    running which may still access the protected data. So, re-add the
    locking.
    
    Reported-by: Dirk Behme <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Fixes: 2c4ee23530ff ("serial: sh-sci: Postpone DMA release when falling back to PIO")
    Signed-off-by: Wolfram Sang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sh: kprobes: Merge arch_copy_kprobe() into arch_prepare_kprobe() [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Fri Mar 1 22:02:30 2024 +0100

    sh: kprobes: Merge arch_copy_kprobe() into arch_prepare_kprobe()
    
    [ Upstream commit 1422ae080b66134fe192082d9b721ab7bd93fcc5 ]
    
    arch/sh/kernel/kprobes.c:52:16: warning: no previous prototype for 'arch_copy_kprobe' [-Wmissing-prototypes]
    
    Although SH kprobes support was only merged in v2.6.28, it missed the
    earlier removal of the arch_copy_kprobe() callback in v2.6.15.
    
    Based on the powerpc part of commit 49a2a1b83ba6fa40 ("[PATCH] kprobes:
    changed from using spinlock to mutex").
    
    Fixes: d39f5450146ff39f ("sh: Add kprobes support.")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: John Paul Adrian Glaubitz <[email protected]>
    Link: https://lore.kernel.org/r/717d47a19689cc944fae6e981a1ad7cae1642c89.1709326528.git.geert+renesas@glider.be
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
soc: mediatek: cmdq: Fix typo of CMDQ_JUMP_RELATIVE [+ + +]
Author: Chun-Kuang Hu <[email protected]>
Date:   Thu Feb 22 15:41:09 2024 +0000

    soc: mediatek: cmdq: Fix typo of CMDQ_JUMP_RELATIVE
    
    [ Upstream commit ed4d5ab179b9f0a60da87c650a31f1816db9b4b4 ]
    
    For cmdq jump command, offset 0 means relative jump and offset 1
    means absolute jump. cmdq_pkt_jump() is absolute jump, so fix the
    typo of CMDQ_JUMP_RELATIVE in cmdq_pkt_jump().
    
    Fixes: 946f1792d3d7 ("soc: mediatek: cmdq: add jump function")
    Signed-off-by: Chun-Kuang Hu <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

soc: qcom: rpmh-rsc: Enhance check for VRM in-flight request [+ + +]
Author: Maulik Shah <[email protected]>
Date:   Thu Feb 15 10:55:44 2024 +0530

    soc: qcom: rpmh-rsc: Enhance check for VRM in-flight request
    
    commit f592cc5794747b81e53b53dd6e80219ee25f0611 upstream.
    
    Each RPMh VRM accelerator resource has 3 or 4 contiguous 4-byte aligned
    addresses associated with it. These control voltage, enable state, mode,
    and in legacy targets, voltage headroom. The current in-flight request
    checking logic looks for exact address matches. Requests for different
    addresses of the same RPMh resource as thus not detected as in-flight.
    
    Add new cmd-db API cmd_db_match_resource_addr() to enhance the in-flight
    request check for VRM requests by ignoring the address offset.
    
    This ensures that only one request is allowed to be in-flight for a given
    VRM resource. This is needed to avoid scenarios where request commands are
    carried out by RPMh hardware out-of-order leading to LDO regulator
    over-current protection triggering.
    
    Fixes: 658628e7ef78 ("drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs")
    Cc: [email protected]
    Reviewed-by: Konrad Dybcio <[email protected]>
    Tested-by: Elliot Berman <[email protected]> # sm8650-qrd
    Signed-off-by: Maulik Shah <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
softirq: Fix suspicious RCU usage in __do_softirq() [+ + +]
Author: Zqiang <[email protected]>
Date:   Sat Apr 27 18:28:08 2024 +0800

    softirq: Fix suspicious RCU usage in __do_softirq()
    
    [ Upstream commit 1dd1eff161bd55968d3d46bc36def62d71fb4785 ]
    
    Currently, the condition "__this_cpu_read(ksoftirqd) == current" is used to
    invoke rcu_softirq_qs() in ksoftirqd tasks context for non-RT kernels.
    
    This works correctly as long as the context is actually task context but
    this condition is wrong when:
    
         - the current task is ksoftirqd
         - the task is interrupted in a RCU read side critical section
         - __do_softirq() is invoked on return from interrupt
    
    Syzkaller triggered the following scenario:
    
      -> finish_task_switch()
        -> put_task_struct_rcu_user()
          -> call_rcu(&task->rcu, delayed_put_task_struct)
            -> __kasan_record_aux_stack()
              -> pfn_valid()
                -> rcu_read_lock_sched()
                  <interrupt>
                    __irq_exit_rcu()
                    -> __do_softirq)()
                       -> if (!IS_ENABLED(CONFIG_PREEMPT_RT) &&
                         __this_cpu_read(ksoftirqd) == current)
                         -> rcu_softirq_qs()
                           -> RCU_LOCKDEP_WARN(lock_is_held(&rcu_sched_lock_map))
    
    The rcu quiescent state is reported in the rcu-read critical section, so
    the lockdep warning is triggered.
    
    Fix this by splitting out the inner working of __do_softirq() into a helper
    function which takes an argument to distinguish between ksoftirqd task
    context and interrupted context and invoke it from the relevant call sites
    with the proper context information and use that for the conditional
    invocation of rcu_softirq_qs().
    
    Reported-by: [email protected]
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Zqiang <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/lkml/8f281a10-b85a-4586-9586-5bbc12dc784f@paulmck-laptop/T/#mea8aba4abfcb97bbf499d169ce7f30c4cff1b0e3
    Signed-off-by: Sasha Levin <[email protected]>

 
soundwire: cadence: fix invalid PDI offset [+ + +]
Author: Pierre-Louis Bossart <[email protected]>
Date:   Tue Mar 26 09:01:16 2024 +0000

    soundwire: cadence: fix invalid PDI offset
    
    [ Upstream commit 8ee1b439b1540ae543149b15a2a61b9dff937d91 ]
    
    For some reason, we add an offset to the PDI, presumably to skip the
    PDI0 and PDI1 which are reserved for BPT.
    
    This code is however completely wrong and leads to an out-of-bounds
    access. We were just lucky so far since we used only a couple of PDIs
    and remained within the PDI array bounds.
    
    A Fixes: tag is not provided since there are no known platforms where
    the out-of-bounds would be accessed, and the initial code had problems
    as well.
    
    A follow-up patch completely removes this useless offset.
    
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Reviewed-by: Rander Wang <[email protected]>
    Signed-off-by: Bard Liao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sparc64: Fix number of online CPUs [+ + +]
Author: Sam Ravnborg <[email protected]>
Date:   Sat Mar 30 10:57:45 2024 +0100

    sparc64: Fix number of online CPUs
    
    commit 98937707fea8375e8acea0aaa0b68a956dd52719 upstream.
    
    Nick Bowler reported:
        When using newer kernels on my Ultra 60 with dual 450MHz UltraSPARC-II
        CPUs, I noticed that only CPU 0 comes up, while older kernels (including
        4.7) are working fine with both CPUs.
    
          I bisected the failure to this commit:
    
          9b2f753ec23710aa32c0d837d2499db92fe9115b is the first bad commit
          commit 9b2f753ec23710aa32c0d837d2499db92fe9115b
          Author: Atish Patra <[email protected]>
          Date:   Thu Sep 15 14:54:40 2016 -0600
    
          sparc64: Fix cpu_possible_mask if nr_cpus is set
    
        This is a small change that reverts very easily on top of 5.18: there is
        just one trivial conflict.  Once reverted, both CPUs work again.
    
        Maybe this is related to the fact that the CPUs on this system are
        numbered CPU0 and CPU2 (there is no CPU1)?
    
    The current code that adjust cpu_possible based on nr_cpu_ids do not
    take into account that CPU's may not come one after each other.
    Move the chech to the function that setup the cpu_possible mask
    so there is no need to adjust it later.
    
    Signed-off-by: Sam Ravnborg <[email protected]>
    Fixes: 9b2f753ec237 ("sparc64: Fix cpu_possible_mask if nr_cpus is set")
    Reported-by: Nick Bowler <[email protected]>
    Tested-by: Nick Bowler <[email protected]>
    Link: https://lore.kernel.org/sparclinux/[email protected]/
    Link: https://lore.kernel.org/all/CADyTPEwt=ZNams+1bpMB1F9w_vUdPsGCt92DBQxxq_VtaLoTdw@mail.gmail.com/
    Cc: [email protected] # v4.8+
    Cc: Andreas Larsson <[email protected]>
    Cc: David S. Miller <[email protected]>
    Cc: Atish Patra <[email protected]>
    Cc: Bob Picco <[email protected]>
    Cc: Vijay Kumar <[email protected]>
    Cc: David S. Miller <[email protected]>
    Reviewed-by: Andreas Larsson <[email protected]>
    Acked-by: Arnd Bergmann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Andreas Larsson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
sparc: move struct termio to asm/termios.h [+ + +]
Author: Mike Gilbert <[email protected]>
Date:   Wed Mar 6 12:11:47 2024 -0500

    sparc: move struct termio to asm/termios.h
    
    commit c32d18e7942d7589b62e301eb426b32623366565 upstream.
    
    Every other arch declares struct termio in asm/termios.h, so make sparc
    match them.
    
    Resolves a build failure in the PPP software package, which includes
    both bits/ioctl-types.h via sys/ioctl.h (glibc) and asm/termbits.h.
    
    Closes: https://bugs.gentoo.org/918992
    Signed-off-by: Mike Gilbert <[email protected]>
    Cc: [email protected]
    Reviewed-by: Andreas Larsson <[email protected]>
    Tested-by: Andreas Larsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Andreas Larsson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
speakup: Fix sizeof() vs ARRAY_SIZE() bug [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Apr 15 14:02:23 2024 +0300

    speakup: Fix sizeof() vs ARRAY_SIZE() bug
    
    commit 008ab3c53bc4f0b2f20013c8f6c204a3203d0b8b upstream.
    
    The "buf" pointer is an array of u16 values.  This code should be
    using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),
    otherwise it can the still got out of bounds.
    
    Fixes: c8d2f34ea96e ("speakup: Avoid crash on very long word")
    Cc: [email protected]
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Samuel Thibault <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
spi: Don't mark message DMA mapped when no transfer in it is [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Wed May 22 20:09:49 2024 +0300

    spi: Don't mark message DMA mapped when no transfer in it is
    
    [ Upstream commit 9f788ba457b45b0ce422943fcec9fa35c4587764 ]
    
    There is no need to set the DMA mapped flag of the message if it has
    no mapped transfers. Moreover, it may give the code a chance to take
    the wrong paths, i.e. to exercise DMA related APIs on unmapped data.
    Make __spi_map_msg() to bail earlier on the above mentioned cases.
    
    Fixes: 99adef310f68 ("spi: Provide core support for DMA mapping transfers")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: stm32: Don't warn about spurious interrupts [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Tue May 21 12:52:42 2024 +0200

    spi: stm32: Don't warn about spurious interrupts
    
    [ Upstream commit 95d7c452a26564ef0c427f2806761b857106d8c4 ]
    
    The dev_warn to notify about a spurious interrupt was introduced with
    the reasoning that these are unexpected. However spurious interrupts
    tend to trigger continously and the error message on the serial console
    prevents that the core's detection of spurious interrupts kicks in
    (which disables the irq) and just floods the console.
    
    Fixes: c64e7efe46b7 ("spi: stm32: make spurious and overrun interrupts visible")
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
stm class: Fix a double free in stm_register_device() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Apr 29 16:01:05 2024 +0300

    stm class: Fix a double free in stm_register_device()
    
    [ Upstream commit 3df463865ba42b8f88a590326f4c9ea17a1ce459 ]
    
    The put_device(&stm->dev) call will trigger stm_device_release() which
    frees "stm" so the vfree(stm) on the next line is a double free.
    
    Fixes: 389b6699a2aa ("stm class: Fix stm device initialization order")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Amelie Delaunay <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Alexander Shishkin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sunrpc: exclude from freezer when waiting for requests: [+ + +]
Author: NeilBrown <[email protected]>
Date:   Fri Jun 7 09:10:48 2024 -0400

    sunrpc: exclude from freezer when waiting for requests:
    
    Prior to v6.1, the freezer will only wake a kernel thread from an
    uninterruptible sleep.  Since we changed svc_get_next_xprt() to use and
    IDLE sleep the freezer cannot wake it.  We need to tell the freezer to
    ignore it instead.
    
    To make this work with only upstream commits, 5.15.y would need
    commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
    which allows non-interruptible sleeps to be woken by the freezer.
    
    Fixes: 9b8a8e5e8129 ("nfsd: don't allow nfsd threads to be signalled.")
    Tested-by: Jon Hunter <[email protected]>
    Signed-off-by: NeilBrown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
SUNRPC: Fix gss_free_in_token_pages() [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Tue May 7 09:10:41 2024 -0400

    SUNRPC: Fix gss_free_in_token_pages()
    
    [ Upstream commit bafa6b4d95d97877baa61883ff90f7e374427fae ]
    
    Dan Carpenter says:
    > Commit 5866efa8cbfb ("SUNRPC: Fix svcauth_gss_proxy_init()") from Oct
    > 24, 2019 (linux-next), leads to the following Smatch static checker
    > warning:
    >
    >       net/sunrpc/auth_gss/svcauth_gss.c:1039 gss_free_in_token_pages()
    >       warn: iterator 'i' not incremented
    >
    > net/sunrpc/auth_gss/svcauth_gss.c
    >     1034 static void gss_free_in_token_pages(struct gssp_in_token *in_token)
    >     1035 {
    >     1036         u32 inlen;
    >     1037         int i;
    >     1038
    > --> 1039         i = 0;
    >     1040         inlen = in_token->page_len;
    >     1041         while (inlen) {
    >     1042                 if (in_token->pages[i])
    >     1043                         put_page(in_token->pages[i]);
    >                                                          ^
    > This puts page zero over and over.
    >
    >     1044                 inlen -= inlen > PAGE_SIZE ? PAGE_SIZE : inlen;
    >     1045         }
    >     1046
    >     1047         kfree(in_token->pages);
    >     1048         in_token->pages = NULL;
    >     1049 }
    
    Based on the way that the ->pages[] array is constructed in
    gss_read_proxy_verf(), we know that once the loop encounters a NULL
    page pointer, the remaining array elements must also be NULL.
    
    Reported-by: Dan Carpenter <[email protected]>
    Suggested-by: Trond Myklebust <[email protected]>
    Fixes: 5866efa8cbfb ("SUNRPC: Fix svcauth_gss_proxy_init()")
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

SUNRPC: Fix loop termination condition in gss_free_in_token_pages() [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Sun Jun 2 18:15:25 2024 -0400

    SUNRPC: Fix loop termination condition in gss_free_in_token_pages()
    
    commit 4a77c3dead97339478c7422eb07bf4bf63577008 upstream.
    
    The in_token->pages[] array is not NULL terminated. This results in
    the following KASAN splat:
    
      KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f]
    
    Fixes: bafa6b4d95d9 ("SUNRPC: Fix gss_free_in_token_pages()")
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
sunrpc: fix NFSACL RPC retry on soft mount [+ + +]
Author: Dan Aloni <[email protected]>
Date:   Thu Apr 25 13:49:38 2024 +0300

    sunrpc: fix NFSACL RPC retry on soft mount
    
    [ Upstream commit 0dc9f430027b8bd9073fdafdfcdeb1a073ab5594 ]
    
    It used to be quite awhile ago since 1b63a75180c6 ('SUNRPC: Refactor
    rpc_clone_client()'), in 2012, that `cl_timeout` was copied in so that
    all mount parameters propagate to NFSACL clients. However since that
    change, if mount options as follows are given:
    
        soft,timeo=50,retrans=16,vers=3
    
    The resultant NFSACL client receives:
    
        cl_softrtry: 1
        cl_timeout: to_initval=60000, to_maxval=60000, to_increment=0, to_retries=2, to_exponential=0
    
    These values lead to NFSACL operations not being retried under the
    condition of transient network outages with soft mount. Instead, getacl
    call fails after 60 seconds with EIO.
    
    The simple fix is to pass the existing client's `cl_timeout` as the new
    client timeout.
    
    Cc: Chuck Lever <[email protected]>
    Cc: Benjamin Coddington <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/T/
    Fixes: 1b63a75180c6 ('SUNRPC: Refactor rpc_clone_client()')
    Signed-off-by: Dan Aloni <[email protected]>
    Reviewed-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sunrpc: removed redundant procp check [+ + +]
Author: Aleksandr Aprelkov <[email protected]>
Date:   Wed Mar 27 14:10:44 2024 +0700

    sunrpc: removed redundant procp check
    
    [ Upstream commit a576f36971ab4097b6aa76433532aa1fb5ee2d3b ]
    
    since vs_proc pointer is dereferenced before getting it's address there's
    no need to check for NULL.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 8e5b67731d08 ("SUNRPC: Add a callback to initialise server requests")
    Signed-off-by: Aleksandr Aprelkov <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tcp: avoid premature drops in tcp_add_backlog() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Tue Apr 23 12:56:20 2024 +0000

    tcp: avoid premature drops in tcp_add_backlog()
    
    [ Upstream commit ec00ed472bdb7d0af840da68c8c11bff9f4d9caa ]
    
    While testing TCP performance with latest trees,
    I saw suspect SOCKET_BACKLOG drops.
    
    tcp_add_backlog() computes its limit with :
    
        limit = (u32)READ_ONCE(sk->sk_rcvbuf) +
                (u32)(READ_ONCE(sk->sk_sndbuf) >> 1);
        limit += 64 * 1024;
    
    This does not take into account that sk->sk_backlog.len
    is reset only at the very end of __release_sock().
    
    Both sk->sk_backlog.len and sk->sk_rmem_alloc could reach
    sk_rcvbuf in normal conditions.
    
    We should double sk->sk_rcvbuf contribution in the formula
    to absorb bubbles in the backlog, which happen more often
    for very fast flows.
    
    This change maintains decent protection against abuses.
    
    Fixes: c377411f2494 ("net: sk_add_backlog() take rmem_alloc into account")
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tcp: Fix shift-out-of-bounds in dctcp_update_alpha(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Fri May 17 18:16:26 2024 +0900

    tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
    
    [ Upstream commit 3ebc46ca8675de6378e3f8f40768e180bb8afa66 ]
    
    In dctcp_update_alpha(), we use a module parameter dctcp_shift_g
    as follows:
    
      alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g);
      ...
      delivered_ce <<= (10 - dctcp_shift_g);
    
    It seems syzkaller started fuzzing module parameters and triggered
    shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
    
      memcpy((void*)0x20000080,
             "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47);
      res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,
                    /*flags=*/2ul, /*mode=*/0ul);
      memcpy((void*)0x20000000, "100\000", 4);
      syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);
    
    Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
    
    With this patch:
    
      # echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
      # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g
      10
      # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g
      -bash: echo: write error: Invalid argument
    
    [0]:
    UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12
    shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int')
    CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    1.13.0-1ubuntu1.1 04/01/2014
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114
     ubsan_epilogue lib/ubsan.c:231 [inline]
     __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468
     dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143
     tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]
     tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948
     tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711
     tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937
     sk_backlog_rcv include/net/sock.h:1106 [inline]
     __release_sock+0x20f/0x350 net/core/sock.c:2983
     release_sock+0x61/0x1f0 net/core/sock.c:3549
     mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907
     mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976
     __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072
     mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127
     inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437
     __sock_release net/socket.c:659 [inline]
     sock_close+0xc0/0x240 net/socket.c:1421
     __fput+0x41b/0x890 fs/file_table.c:422
     task_work_run+0x23b/0x300 kernel/task_work.c:180
     exit_task_work include/linux/task_work.h:38 [inline]
     do_exit+0x9c8/0x2540 kernel/exit.c:878
     do_group_exit+0x201/0x2b0 kernel/exit.c:1027
     __do_sys_exit_group kernel/exit.c:1038 [inline]
     __se_sys_exit_group kernel/exit.c:1036 [inline]
     __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x67/0x6f
    RIP: 0033:0x7f6c2b5005b6
    Code: Unable to access opcode bytes at 0x7f6c2b50058c.
    RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
    RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6
    RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
    RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0
    R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0
    R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
     </TASK>
    
    Reported-by: syzkaller <[email protected]>
    Reported-by: Yue Sun <[email protected]>
    Reported-by: xingwei lee <[email protected]>
    Closes: https://lore.kernel.org/netdev/CAEkJfYNJM=cw-8x7_Vmj1J6uYVCWMbbvD=EFmDPVBGpTsqOxEA@mail.gmail.com/
    Fixes: e3118e8359bb ("net: tcp: add DCTCP congestion control algorithm")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
thermal/drivers/qcom/lmh: Check for SCM availability at probe [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Sat Mar 9 14:15:03 2024 +0100

    thermal/drivers/qcom/lmh: Check for SCM availability at probe
    
    commit d9d3490c48df572edefc0b64655259eefdcbb9be upstream.
    
    Up until now, the necessary scm availability check has not been
    performed, leading to possible null pointer dereferences (which did
    happen for me on RB1).
    
    Fix that.
    
    Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver")
    Cc: <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
thermal/drivers/tsens: Fix null pointer dereference [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Thu Apr 11 14:40:21 2024 +0300

    thermal/drivers/tsens: Fix null pointer dereference
    
    [ Upstream commit d998ddc86a27c92140b9f7984ff41e3d1d07a48f ]
    
    compute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c)
    as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null
    pointer dereference (if DEBUG or DYNAMIC_DEBUG set).
    Fix this bug by adding null pointer check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: dfc1193d4dbd ("thermal/drivers/tsens: Replace custom 8960 apis with generic apis")
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Signed-off-by: Daniel Lezcano <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
tls: fix missing memory barrier in tls_init [+ + +]
Author: Dae R. Jeong <[email protected]>
Date:   Tue May 21 19:34:38 2024 +0900

    tls: fix missing memory barrier in tls_init
    
    [ Upstream commit 91e61dd7a0af660408e87372d8330ceb218be302 ]
    
    In tls_init(), a write memory barrier is missing, and store-store
    reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.
    
    CPU0                               CPU1
    -----                              -----
    // In tls_init()
    // In tls_ctx_create()
    ctx = kzalloc()
    ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1)
    
    // In update_sk_prot()
    WRITE_ONCE(sk->sk_prot, tls_prots)     -(2)
    
                                       // In sock_common_setsockopt()
                                       READ_ONCE(sk->sk_prot)->setsockopt()
    
                                       // In tls_{setsockopt,getsockopt}()
                                       ctx->sk_proto->setsockopt()    -(3)
    
    In the above scenario, when (1) and (2) are reordered, (3) can observe
    the NULL value of ctx->sk_proto, causing NULL dereference.
    
    To fix it, we rely on rcu_assign_pointer() which implies the release
    barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is
    initialized, we can ensure that ctx->sk_proto are visible when
    changing sk->sk_prot.
    
    Fixes: d5bee7374b68 ("net/tls: Annotate access to sk_prot with READ_ONCE/WRITE_ONCE")
    Signed-off-by: Yewon Choi <[email protected]>
    Signed-off-by: Dae R. Jeong <[email protected]>
    Link: https://lore.kernel.org/netdev/ZU4OJG56g2V9z_H7@dragonet/T/
    Link: https://lore.kernel.org/r/Zkx4vjSFp0mfpjQ2@libra05
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tools/latency-collector: Fix -Wformat-security compile warns [+ + +]
Author: Shuah Khan <[email protected]>
Date:   Wed Apr 3 19:10:09 2024 -0600

    tools/latency-collector: Fix -Wformat-security compile warns
    
    commit df73757cf8f66fa54c4721c53b0916af3c4d9818 upstream.
    
    Fix the following -Wformat-security compile warnings adding missing
    format arguments:
    
    latency-collector.c: In function ‘show_available’:
    latency-collector.c:938:17: warning: format not a string literal and
    no format arguments [-Wformat-security]
      938 |                 warnx(no_tracer_msg);
          |                 ^~~~~
    
    latency-collector.c:943:17: warning: format not a string literal and
    no format arguments [-Wformat-security]
      943 |                 warnx(no_latency_tr_msg);
          |                 ^~~~~
    
    latency-collector.c: In function ‘find_default_tracer’:
    latency-collector.c:986:25: warning: format not a string literal and
    no format arguments [-Wformat-security]
      986 |                         errx(EXIT_FAILURE, no_tracer_msg);
          |
                             ^~~~
    latency-collector.c: In function ‘scan_arguments’:
    latency-collector.c:1881:33: warning: format not a string literal and
    no format arguments [-Wformat-security]
     1881 |                                 errx(EXIT_FAILURE, no_tracer_msg);
          |                                 ^~~~
    
    Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
    
    Cc: [email protected]
    Fixes: e23db805da2df ("tracing/tools: Add the latency-collector to tools directory")
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tty: n_gsm: fix missing receive state reset after mode switch [+ + +]
Author: Daniel Starke <[email protected]>
Date:   Wed Apr 24 07:48:42 2024 +0200

    tty: n_gsm: fix missing receive state reset after mode switch
    
    commit 70d7f1427afcf7fa2d21cb5a04c6f3555d5b9357 upstream.
    
    The current implementation uses either gsm0_receive() or gsm1_receive()
    depending on whether the user configured the mux in basic or advanced
    option mode. Both functions share some state values over the same logical
    elements of the frame. However, both frame types differ in their nature.
    gsm0_receive() uses non-transparency framing, whereas gsm1_receive() uses
    transparency mechanism. Switching between both modes leaves the receive
    function in an undefined state when done during frame reception.
    
    Fix this by splitting both states. Add gsm0_receive_state_check_and_fix()
    and gsm1_receive_state_check_and_fix() to ensure that gsm->state is reset
    after a change of gsm->receive.
    
    Note that gsm->state is only accessed in:
    - gsm0_receive()
    - gsm1_receive()
    - gsm_error()
    
    Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
    Cc: [email protected]
    Signed-off-by: Daniel Starke <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: n_gsm: fix possible out-of-bounds in gsm0_receive() [+ + +]
Author: Daniel Starke <[email protected]>
Date:   Wed Apr 24 07:48:41 2024 +0200

    tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
    
    commit 47388e807f85948eefc403a8a5fdc5b406a65d5a upstream.
    
    Assuming the following:
    - side A configures the n_gsm in basic option mode
    - side B sends the header of a basic option mode frame with data length 1
    - side A switches to advanced option mode
    - side B sends 2 data bytes which exceeds gsm->len
      Reason: gsm->len is not used in advanced option mode.
    - side A switches to basic option mode
    - side B keeps sending until gsm0_receive() writes past gsm->buf
      Reason: Neither gsm->state nor gsm->len have been reset after
      reconfiguration.
    
    Fix this by changing gsm->count to gsm->len comparison from equal to less
    than. Also add upper limit checks against the constant MAX_MRU in
    gsm0_receive() and gsm1_receive() to harden against memory corruption of
    gsm->len and gsm->mru.
    
    All other checks remain as we still need to limit the data according to the
    user configuration and actual payload size.
    
    Reported-by: [email protected]
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218708
    Tested-by: [email protected]
    Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
    Cc: [email protected]
    Signed-off-by: Daniel Starke <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
udp: Avoid call to compute_score on multiple sites [+ + +]
Author: Gabriel Krisman Bertazi <[email protected]>
Date:   Fri Apr 12 17:20:04 2024 -0400

    udp: Avoid call to compute_score on multiple sites
    
    [ Upstream commit 50aee97d15113b95a68848db1f0cb2a6c09f753a ]
    
    We've observed a 7-12% performance regression in iperf3 UDP ipv4 and
    ipv6 tests with multiple sockets on Zen3 cpus, which we traced back to
    commit f0ea27e7bfe1 ("udp: re-score reuseport groups when connected
    sockets are present").  The failing tests were those that would spawn
    UDP sockets per-cpu on systems that have a high number of cpus.
    
    Unsurprisingly, it is not caused by the extra re-scoring of the reused
    socket, but due to the compiler no longer inlining compute_score, once
    it has the extra call site in udp4_lib_lookup2.  This is augmented by
    the "Safe RET" mitigation for SRSO, needed in our Zen3 cpus.
    
    We could just explicitly inline it, but compute_score() is quite a large
    function, around 300b.  Inlining in two sites would almost double
    udp4_lib_lookup2, which is a silly thing to do just to workaround a
    mitigation.  Instead, this patch shuffles the code a bit to avoid the
    multiple calls to compute_score.  Since it is a static function used in
    one spot, the compiler can safely fold it in, as it did before, without
    increasing the text size.
    
    With this patch applied I ran my original iperf3 testcases.  The failing
    cases all looked like this (ipv4):
            iperf3 -c 127.0.0.1 --udp -4 -f K -b $R -l 8920 -t 30 -i 5 -P 64 -O 2
    
    where $R is either 1G/10G/0 (max, unlimited).  I ran 3 times each.
    baseline is v6.9-rc3. harmean == harmonic mean; CV == coefficient of
    variation.
    
    ipv4:
                     1G                10G                  MAX
                HARMEAN  (CV)      HARMEAN  (CV)    HARMEAN     (CV)
    baseline 1743852.66(0.0208) 1725933.02(0.0167) 1705203.78(0.0386)
    patched  1968727.61(0.0035) 1962283.22(0.0195) 1923853.50(0.0256)
    
    ipv6:
                     1G                10G                  MAX
                HARMEAN  (CV)      HARMEAN  (CV)    HARMEAN     (CV)
    baseline 1729020.03(0.0028) 1691704.49(0.0243) 1692251.34(0.0083)
    patched  1900422.19(0.0067) 1900968.01(0.0067) 1568532.72(0.1519)
    
    This restores the performance we had before the change above with this
    benchmark.  We obviously don't expect any real impact when mitigations
    are disabled, but just to be sure it also doesn't regresses:
    
    mitigations=off ipv4:
                     1G                10G                  MAX
                HARMEAN  (CV)      HARMEAN  (CV)    HARMEAN     (CV)
    baseline 3230279.97(0.0066) 3229320.91(0.0060) 2605693.19(0.0697)
    patched  3242802.36(0.0073) 3239310.71(0.0035) 2502427.19(0.0882)
    
    Cc: Lorenz Bauer <[email protected]>
    Fixes: f0ea27e7bfe1 ("udp: re-score reuseport groups when connected sockets are present")
    Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
    Reviewed-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
um: Add winch to winch_handlers before registering winch IRQ [+ + +]
Author: Roberto Sassu <[email protected]>
Date:   Thu Mar 7 11:49:26 2024 +0100

    um: Add winch to winch_handlers before registering winch IRQ
    
    [ Upstream commit a0fbbd36c156b9f7b2276871d499c9943dfe5101 ]
    
    Registering a winch IRQ is racy, an interrupt may occur before the winch is
    added to the winch_handlers list.
    
    If that happens, register_winch_irq() adds to that list a winch that is
    scheduled to be (or has already been) freed, causing a panic later in
    winch_cleanup().
    
    Avoid the race by adding the winch to the winch_handlers list before
    registering the IRQ, and rolling back if um_request_irq() fails.
    
    Fixes: 42a359e31a0e ("uml: SIGIO support cleanup")
    Signed-off-by: Roberto Sassu <[email protected]>
    Reviewed-by: Johannes Berg <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

um: Fix return value in ubd_init() [+ + +]
Author: Duoming Zhou <[email protected]>
Date:   Wed Mar 6 17:12:59 2024 +0800

    um: Fix return value in ubd_init()
    
    [ Upstream commit 31a5990ed253a66712d7ddc29c92d297a991fdf2 ]
    
    When kmalloc_array() fails to allocate memory, the ubd_init()
    should return -ENOMEM instead of -1. So, fix it.
    
    Fixes: f88f0bdfc32f ("um: UBD Improvements")
    Signed-off-by: Duoming Zhou <[email protected]>
    Reviewed-by: Johannes Berg <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

um: Fix the -Wmissing-prototypes warning for __switch_mm [+ + +]
Author: Tiwei Bie <[email protected]>
Date:   Tue Apr 23 20:58:53 2024 +0800

    um: Fix the -Wmissing-prototypes warning for __switch_mm
    
    [ Upstream commit 2cbade17b18c0f0fd9963f26c9fc9b057eb1cb3a ]
    
    The __switch_mm function is defined in the user code, and is called
    by the kernel code. It should be declared in a shared header.
    
    Fixes: 4dc706c2f292 ("um: take um_mmu.h to asm/mmu.h, clean asm/mmu_context.h a bit")
    Signed-off-by: Tiwei Bie <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

um: vector: fix bpfflash parameter evaluation [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Thu Mar 28 10:06:36 2024 +0100

    um: vector: fix bpfflash parameter evaluation
    
    [ Upstream commit 584ed2f76ff5fe360d87a04d17b6520c7999e06b ]
    
    With W=1 the build complains about a pointer compared to
    zero, clearly the result should've been compared.
    
    Fixes: 9807019a62dc ("um: Loadable BPF "Firmware" for vector drivers")
    Signed-off-by: Johannes Berg <[email protected]>
    Reviewed-by: Tiwei Bie <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
usb: aqc111: stop lying about skb->truesize [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Mon May 6 13:55:46 2024 +0000

    usb: aqc111: stop lying about skb->truesize
    
    [ Upstream commit 9aad6e45c4e7d16b2bb7c3794154b828fb4384b4 ]
    
    Some usb drivers try to set small skb->truesize and break
    core networking stacks.
    
    I replace 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: 361459cd9642 ("net: usb: aqc111: Implement RX data path")
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: gadget: u_audio: Clear uac pointer when freed. [+ + +]
Author: Chris Wulff <[email protected]>
Date:   Thu Apr 25 15:20:20 2024 +0000

    usb: gadget: u_audio: Clear uac pointer when freed.
    
    [ Upstream commit a2cf936ebef291ef7395172b9e2f624779fb6dc0 ]
    
    This prevents use of a stale pointer if functions are called after
    g_cleanup that shouldn't be. This doesn't fix any races, but converts
    a possibly silent kernel memory corruption into an obvious NULL pointer
    dereference report.
    
    Fixes: eb9fecb9e69b ("usb: gadget: f_uac2: split out audio core")
    Signed-off-by: Chris Wulff <[email protected]>
    Link: https://lore.kernel.org/stable/CO1PR17MB54194226DA08BFC9EBD8C163E1172%40CO1PR17MB5419.namprd17.prod.outlook.com
    Link: https://lore.kernel.org/r/CO1PR17MB54194226DA08BFC9EBD8C163E1172@CO1PR17MB5419.namprd17.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
virt: acrn: Prefer array_size and struct_size over open coded arithmetic [+ + +]
Author: Len Baker <[email protected]>
Date:   Fri Oct 29 19:27:46 2021 +0200

    virt: acrn: Prefer array_size and struct_size over open coded arithmetic
    
    [ Upstream commit 746f1b0ac5bf6ecfb71674af210ae476aa714f46 ]
    
    As noted in the "Deprecated Interfaces, Language Features, Attributes,
    and Conventions" documentation [1], size calculations (especially
    multiplication) should not be performed in memory allocator (or similar)
    function arguments due to the risk of them overflowing. This could lead
    to values wrapping around and a smaller allocation being made than the
    caller was expecting. Using those allocations could lead to linear
    overflows of heap memory and other misbehaviors.
    
    So, use the array_size() helper to do the arithmetic instead of the
    argument "count * size" in the vzalloc() function.
    
    Also, take the opportunity to add a flexible array member of struct
    vm_memory_region_op to the vm_memory_region_batch structure. And then,
    change the code accordingly and use the struct_size() helper to do the
    arithmetic instead of the argument "size + size * count" in the kzalloc
    function.
    
    This code was detected with the help of Coccinelle and audited and fixed
    manually.
    
    [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
    
    Acked-by: Fei Li <[email protected]>
    Signed-off-by: Len Baker <[email protected]>
    Signed-off-by: Gustavo A. R. Silva <[email protected]>
    Stable-dep-of: 3d6586008f7b ("drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()")
    Signed-off-by: Sasha Levin <[email protected]>

virt: acrn: stop using follow_pfn [+ + +]
Author: Christoph Hellwig <[email protected]>
Date:   Mon Mar 25 07:45:40 2024 +0800

    virt: acrn: stop using follow_pfn
    
    [ Upstream commit 1b265da7ea1e1ae997fa119c2846bb389eb39c6b ]
    
    Patch series "remove follow_pfn".
    
    This series open codes follow_pfn in the only remaining caller, although
    the code there remains questionable.  It then also moves follow_phys into
    the only user and simplifies it a bit.
    
    This patch (of 3):
    
    Switch from follow_pfn to follow_pte so that we can get rid of follow_pfn.
    Note that this doesn't fix any of the pre-existing raciness and lack of
    permission checking in the code.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: David Hildenbrand <[email protected]>
    Cc: Andy Lutomirski <[email protected]>
    Cc: Dave Hansen <[email protected]>
    Cc: Fei Li <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Stable-dep-of: 3d6586008f7b ("drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()")
    Signed-off-by: Sasha Levin <[email protected]>

 
virtio: delete vq in vp_find_vqs_msix() when request_irq() fails [+ + +]
Author: Jiri Pirko <[email protected]>
Date:   Fri Apr 26 17:08:45 2024 +0200

    virtio: delete vq in vp_find_vqs_msix() when request_irq() fails
    
    [ Upstream commit 89875151fccdd024d571aa884ea97a0128b968b6 ]
    
    When request_irq() fails, error path calls vp_del_vqs(). There, as vq is
    present in the list, free_irq() is called for the same vector. That
    causes following splat:
    
    [    0.414355] Trying to free already-free IRQ 27
    [    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0
    [    0.414510] Modules linked in:
    [    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27
    [    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
    [    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0
    [    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 <0f> 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40
    [    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086
    [    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000
    [    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001
    [    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001
    [    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760
    [    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600
    [    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000
    [    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0
    [    0.414540] Call Trace:
    [    0.414540]  <TASK>
    [    0.414540]  ? __warn+0x80/0x120
    [    0.414540]  ? free_irq+0x1a1/0x2d0
    [    0.414540]  ? report_bug+0x164/0x190
    [    0.414540]  ? handle_bug+0x3b/0x70
    [    0.414540]  ? exc_invalid_op+0x17/0x70
    [    0.414540]  ? asm_exc_invalid_op+0x1a/0x20
    [    0.414540]  ? free_irq+0x1a1/0x2d0
    [    0.414540]  vp_del_vqs+0xc1/0x220
    [    0.414540]  vp_find_vqs_msix+0x305/0x470
    [    0.414540]  vp_find_vqs+0x3e/0x1a0
    [    0.414540]  vp_modern_find_vqs+0x1b/0x70
    [    0.414540]  init_vqs+0x387/0x600
    [    0.414540]  virtnet_probe+0x50a/0xc80
    [    0.414540]  virtio_dev_probe+0x1e0/0x2b0
    [    0.414540]  really_probe+0xc0/0x2c0
    [    0.414540]  ? __pfx___driver_attach+0x10/0x10
    [    0.414540]  __driver_probe_device+0x73/0x120
    [    0.414540]  driver_probe_device+0x1f/0xe0
    [    0.414540]  __driver_attach+0x88/0x180
    [    0.414540]  bus_for_each_dev+0x85/0xd0
    [    0.414540]  bus_add_driver+0xec/0x1f0
    [    0.414540]  driver_register+0x59/0x100
    [    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10
    [    0.414540]  virtio_net_driver_init+0x90/0xb0
    [    0.414540]  do_one_initcall+0x58/0x230
    [    0.414540]  kernel_init_freeable+0x1a3/0x2d0
    [    0.414540]  ? __pfx_kernel_init+0x10/0x10
    [    0.414540]  kernel_init+0x1a/0x1c0
    [    0.414540]  ret_from_fork+0x31/0x50
    [    0.414540]  ? __pfx_kernel_init+0x10/0x10
    [    0.414540]  ret_from_fork_asm+0x1a/0x30
    [    0.414540]  </TASK>
    
    Fix this by calling deleting the current vq when request_irq() fails.
    
    Fixes: 0b0f9dc52ed0 ("Revert "virtio_pci: use shared interrupts for virtqueues"")
    Signed-off-by: Jiri Pirko <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vxlan: Fix regression when dropping packets due to invalid src addresses [+ + +]
Author: Daniel Borkmann <[email protected]>
Date:   Mon Jun 3 10:59:26 2024 +0200

    vxlan: Fix regression when dropping packets due to invalid src addresses
    
    commit 1cd4bc987abb2823836cbb8f887026011ccddc8a upstream.
    
    Commit f58f45c1e5b9 ("vxlan: drop packets from invalid src-address")
    has recently been added to vxlan mainly in the context of source
    address snooping/learning so that when it is enabled, an entry in the
    FDB is not being created for an invalid address for the corresponding
    tunnel endpoint.
    
    Before commit f58f45c1e5b9 vxlan was similarly behaving as geneve in
    that it passed through whichever macs were set in the L2 header. It
    turns out that this change in behavior breaks setups, for example,
    Cilium with netkit in L3 mode for Pods as well as tunnel mode has been
    passing before the change in f58f45c1e5b9 for both vxlan and geneve.
    After mentioned change it is only passing for geneve as in case of
    vxlan packets are dropped due to vxlan_set_mac() returning false as
    source and destination macs are zero which for E/W traffic via tunnel
    is totally fine.
    
    Fix it by only opting into the is_valid_ether_addr() check in
    vxlan_set_mac() when in fact source address snooping/learning is
    actually enabled in vxlan. This is done by moving the check into
    vxlan_snoop(). With this change, the Cilium connectivity test suite
    passes again for both tunnel flavors.
    
    Fixes: f58f45c1e5b9 ("vxlan: drop packets from invalid src-address")
    Signed-off-by: Daniel Borkmann <[email protected]>
    Cc: David Bauer <[email protected]>
    Cc: Ido Schimmel <[email protected]>
    Cc: Nikolay Aleksandrov <[email protected]>
    Cc: Martin KaFai Lau <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Reviewed-by: Nikolay Aleksandrov <[email protected]>
    Reviewed-by: David Bauer <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [ Backport note: vxlan snooping/learning not supported in 6.8 or older,
      so commit is simply a revert. ]
    Signed-off-by: Daniel Borkmann <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
watchdog: bd9576: Drop "always-running" property [+ + +]
Author: Matti Vaittinen <[email protected]>
Date:   Mon Apr 8 13:02:31 2024 +0300

    watchdog: bd9576: Drop "always-running" property
    
    [ Upstream commit e3b3afd34d84efcbe4543deb966b1990f43584b8 ]
    
    The always-running (from linux,wdt-gpio.yaml) is abused by the BD9576
    watchdog driver. It's defined meaning is "the watchdog is always running
    and can not be stopped". The BD9576 watchdog driver has implemented it
    as "start watchdog when loading the module and prevent it from being
    stopped".
    
    Furthermore, the implementation does not set the WDOG_HW_RUNNING when
    enabling the watchdog due to the "always-running" at module loading.
    This will end up resulting a watchdog timeout if the device is not
    opened.
    
    The culprit was pointed out by Guenter, discussion can be found from
    https://lore.kernel.org/lkml/[email protected]/
    
    Drop the invalid "always-running" handling.
    
    Signed-off-by: Matti Vaittinen <[email protected]>
    Reported-by: Guenter Roeck <[email protected]>
    Fixes: b237bcac557a ("wdt: Support wdt on ROHM BD9576MUF and BD9573MUF")
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/ZhPAt76yaJMersXf@fedora
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

watchdog: bd9576_wdt: switch to using devm_fwnode_gpiod_get() [+ + +]
Author: Dmitry Torokhov <[email protected]>
Date:   Sun Sep 4 23:31:02 2022 -0700

    watchdog: bd9576_wdt: switch to using devm_fwnode_gpiod_get()
    
    [ Upstream commit 4f719022a753bb15720c9ddeb0387a93caa372ce ]
    
    I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
    so that gpiolib can be cleaned a bit, so let's switch to the generic
    fwnode property API.
    
    While at it, switch the rest of the calls to read properties in
    bd9576_wdt_probe() to the generic device property API as well.
    
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Link: https://lore.kernel.org/r/20220903-gpiod_get_from_of_node-remove-v1-10-b29adfb27a6c@gmail.com
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Stable-dep-of: e3b3afd34d84 ("watchdog: bd9576: Drop "always-running" property")
    Signed-off-by: Sasha Levin <[email protected]>

watchdog: rti_wdt: Set min_hw_heartbeat_ms to accommodate a safety margin [+ + +]
Author: Judith Mendez <[email protected]>
Date:   Wed Apr 17 15:57:00 2024 -0500

    watchdog: rti_wdt: Set min_hw_heartbeat_ms to accommodate a safety margin
    
    commit cae58516534e110f4a8558d48aa4435e15519121 upstream.
    
    On AM62x, the watchdog is pet before the valid window is open. Fix
    min_hw_heartbeat and accommodate a 2% + static offset safety margin.
    The static offset accounts for max hardware error.
    
    Remove the hack in the driver which shifts the open window boundary,
    since it is no longer necessary due to the fix mentioned above.
    
    cc: [email protected]
    Fixes: 5527483f8f7c ("watchdog: rti-wdt: attach to running watchdog during probe")
    Signed-off-by: Judith Mendez <[email protected]>
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
wifi: ar5523: enable proper endpoint verification [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Mon Apr 8 05:14:25 2024 -0700

    wifi: ar5523: enable proper endpoint verification
    
    [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ]
    
    Syzkaller reports [1] hitting a warning about an endpoint in use
    not having an expected type to it.
    
    Fix the issue by checking for the existence of all proper
    endpoints with their according types intact.
    
    Sadly, this patch has not been tested on real hardware.
    
    [1] Syzkaller report:
    ------------[ cut here ]------------
    usb 1-1: BOGUS urb xfer, pipe 3 != type 1
    WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
    ...
    Call Trace:
     <TASK>
     ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275
     ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]
     ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]
     ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655
     usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396
     call_driver_probe drivers/base/dd.c:560 [inline]
     really_probe+0x249/0xb90 drivers/base/dd.c:639
     __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
     driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
     __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
     bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
     __device_attach+0x1e4/0x530 drivers/base/dd.c:1008
     bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
     device_add+0xbd9/0x1e90 drivers/base/core.c:3517
     usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170
     usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238
     usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293
     call_driver_probe drivers/base/dd.c:560 [inline]
     really_probe+0x249/0xb90 drivers/base/dd.c:639
     __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
     driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
     __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
     bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
     __device_attach+0x1e4/0x530 drivers/base/dd.c:1008
     bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
     device_add+0xbd9/0x1e90 drivers/base/core.c:3517
     usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573
     hub_port_connect drivers/usb/core/hub.c:5353 [inline]
     hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]
     port_event drivers/usb/core/hub.c:5653 [inline]
     hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735
     process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
     worker_thread+0x669/0x1090 kernel/workqueue.c:2436
     kthread+0x2e8/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
     </TASK>
    
    Reported-and-tested-by: [email protected]
    Fixes: b7d572e1871d ("ar5523: Add new driver")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath10k: Fix an error code problem in ath10k_dbg_sta_write_peer_debug_trigger() [+ + +]
Author: Su Hui <[email protected]>
Date:   Mon Apr 22 11:42:44 2024 +0800

    wifi: ath10k: Fix an error code problem in ath10k_dbg_sta_write_peer_debug_trigger()
    
    [ Upstream commit c511a9c12674d246916bb16c479d496b76983193 ]
    
    Clang Static Checker (scan-build) warns:
    
    drivers/net/wireless/ath/ath10k/debugfs_sta.c:line 429, column 3
    Value stored to 'ret' is never read.
    
    Return 'ret' rather than 'count' when 'ret' stores an error code.
    
    Fixes: ee8b08a1be82 ("ath10k: add debugfs support to get per peer tids log via tracing")
    Signed-off-by: Su Hui <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath10k: poll service ready message before failing [+ + +]
Author: Baochen Qiang <[email protected]>
Date:   Wed Mar 6 07:15:14 2024 +0200

    wifi: ath10k: poll service ready message before failing
    
    [ Upstream commit e57b7d62a1b2f496caf0beba81cec3c90fad80d5 ]
    
    Currently host relies on CE interrupts to get notified that
    the service ready message is ready. This results in timeout
    issue if the interrupt is not fired, due to some unknown
    reasons. See below logs:
    
    [76321.937866] ath10k_pci 0000:02:00.0: wmi service ready event not received
    ...
    [76322.016738] ath10k_pci 0000:02:00.0: Could not init core: -110
    
    And finally it causes WLAN interface bring up failure.
    
    Change to give it one more chance here by polling CE rings,
    before failing directly.
    
    Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00157-QCARMSWPZ-1
    
    Fixes: 5e3dd157d7e7 ("ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices")
    Reported-by: James Prestwood <[email protected]>
    Tested-By: James Prestwood <[email protected]> # on QCA6174 hw3.2
    Link: https://lore.kernel.org/linux-wireless/[email protected]/
    Signed-off-by: Baochen Qiang <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath10k: populate board data for WCN3990 [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Tue Jan 30 08:47:06 2024 +0200

    wifi: ath10k: populate board data for WCN3990
    
    [ Upstream commit f1f1b5b055c9f27a2f90fd0f0521f5920e9b3c18 ]
    
    Specify board data size (and board.bin filename) for the WCN3990
    platform.
    
    Reported-by: Yongqin Liu <[email protected]>
    Fixes: 03a72288c546 ("ath10k: wmi: add hw params entry for wcn3990")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: carl9170: add a proper sanity check for endpoints [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Mon Apr 22 11:33:55 2024 -0700

    wifi: carl9170: add a proper sanity check for endpoints
    
    [ Upstream commit b6dd09b3dac89b45d1ea3e3bd035a3859c0369a0 ]
    
    Syzkaller reports [1] hitting a warning which is caused by presence
    of a wrong endpoint type at the URB sumbitting stage. While there
    was a check for a specific 4th endpoint, since it can switch types
    between bulk and interrupt, other endpoints are trusted implicitly.
    Similar warning is triggered in a couple of other syzbot issues [2].
    
    Fix the issue by doing a comprehensive check of all endpoints
    taking into account difference between high- and full-speed
    configuration.
    
    [1] Syzkaller report:
    ...
    WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
    ...
    Call Trace:
     <TASK>
     carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504
     carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]
     carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]
     carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028
     request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107
     process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
     worker_thread+0x669/0x1090 kernel/workqueue.c:2436
     kthread+0x2e8/0x3a0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
     </TASK>
    
    [2] Related syzkaller crashes:
    Link: https://syzkaller.appspot.com/bug?extid=e394db78ae0b0032cb4d
    Link: https://syzkaller.appspot.com/bug?extid=9468df99cb63a4a4c4e1
    
    Reported-and-tested-by: [email protected]
    Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Acked-By: Christian Lamparter <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: cfg80211: fix the order of arguments for trace events of the tx_rx_evt class [+ + +]
Author: Igor Artemiev <[email protected]>
Date:   Fri Apr 5 18:24:30 2024 +0300

    wifi: cfg80211: fix the order of arguments for trace events of the tx_rx_evt class
    
    [ Upstream commit 9ef369973cd2c97cce3388d2c0c7e3c056656e8a ]
    
    The declarations of the tx_rx_evt class and the rdev_set_antenna event
    use the wrong order of arguments in the TP_ARGS macro.
    
    Fix the order of arguments in the TP_ARGS macro.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Igor Artemiev <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mwl8k: initialize cmd->addr[] properly [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Sat May 4 14:38:15 2024 +0300

    wifi: mwl8k: initialize cmd->addr[] properly
    
    [ Upstream commit 1d60eabb82694e58543e2b6366dae3e7465892a5 ]
    
    This loop is supposed to copy the mac address to cmd->addr but the
    i++ increment is missing so it copies everything to cmd->addr[0] and
    only the last address is recorded.
    
    Fixes: 22bedad3ce11 ("net: convert multicast list to list_head")
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtl8xxxu: Fix the TX power of RTL8192CU, RTL8723AU [+ + +]
Author: Bitterblue Smith <[email protected]>
Date:   Mon Apr 15 23:59:05 2024 +0300

    wifi: rtl8xxxu: Fix the TX power of RTL8192CU, RTL8723AU
    
    commit 08b5d052d17a89bb8706b2888277d0b682dc1610 upstream.
    
    Don't subtract 1 from the power index. This was added in commit
    2fc0b8e5a17d ("rtl8xxxu: Add TX power base values for gen1 parts")
    for unknown reasons. The vendor drivers don't do this.
    
    Also correct the calculations of values written to
    REG_OFDM0_X{C,D}_TX_IQ_IMBALANCE. According to the vendor driver,
    these are used for TX power training.
    
    With these changes rtl8xxxu sets the TX power of RTL8192CU the same
    as the vendor driver.
    
    None of this appears to have any effect on my RTL8192CU device.
    
    Cc: [email protected]
    Signed-off-by: Bitterblue Smith <[email protected]>
    Reviewed-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: rtlwifi: rtl8192de: Fix endianness issue in RX path [+ + +]
Author: Bitterblue Smith <[email protected]>
Date:   Thu Apr 25 21:13:12 2024 +0300

    wifi: rtlwifi: rtl8192de: Fix endianness issue in RX path
    
    commit 2f228d364da95ab58f63a3fedc00d5b2b7db16ab upstream.
    
    Structs rx_desc_92d and rx_fwinfo_92d will not work for big endian
    systems.
    
    Delete rx_desc_92d because it's big and barely used, and instead use
    the get_rx_desc_rxmcs and get_rx_desc_rxht functions, which work on big
    endian systems too.
    
    Fix rx_fwinfo_92d by duplicating four of its members in the correct
    order.
    
    Tested only with RTL8192DU, which will use the same code.
    Tested only on a little endian system.
    
    Cc: [email protected]
    Signed-off-by: Bitterblue Smith <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: rtlwifi: rtl8192de: Fix low speed with WPA3-SAE [+ + +]
Author: Bitterblue Smith <[email protected]>
Date:   Thu Apr 25 21:12:38 2024 +0300

    wifi: rtlwifi: rtl8192de: Fix low speed with WPA3-SAE
    
    commit a7c0f48410f546772ac94a0f7b7291a15c4fc173 upstream.
    
    Some (all?) management frames are incorrectly reported to mac80211 as
    decrypted when actually the hardware did not decrypt them. This results
    in speeds 3-5 times lower than expected, 20-30 Mbps instead of 100
    Mbps.
    
    Fix this by checking the encryption type field of the RX descriptor.
    rtw88 does the same thing.
    
    This fix was tested only with rtl8192du, which will use the same code.
    
    Cc: [email protected]
    Signed-off-by: Bitterblue Smith <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/boot: Ignore relocations in .notes sections in walk_relocs() too [+ + +]
Author: Guixiong Wei <[email protected]>
Date:   Sun Mar 17 23:05:47 2024 +0800

    x86/boot: Ignore relocations in .notes sections in walk_relocs() too
    
    [ Upstream commit 76e9762d66373354b45c33b60e9a53ef2a3c5ff2 ]
    
    Commit:
    
      aaa8736370db ("x86, relocs: Ignore relocations in .notes section")
    
    ... only started ignoring the .notes sections in print_absolute_relocs(),
    but the same logic should also by applied in walk_relocs() to avoid
    such relocations.
    
    [ mingo: Fixed various typos in the changelog, removed extra curly braces from the code. ]
    
    Fixes: aaa8736370db ("x86, relocs: Ignore relocations in .notes section")
    Fixes: 5ead97c84fa7 ("xen: Core Xen implementation")
    Fixes: da1a679cde9b ("Add /sys/kernel/notes")
    Signed-off-by: Guixiong Wei <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/insn: Fix PUSH instruction in x86 instruction decoder opcode map [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Thu May 2 13:58:45 2024 +0300

    x86/insn: Fix PUSH instruction in x86 instruction decoder opcode map
    
    [ Upstream commit 59162e0c11d7257cde15f907d19fefe26da66692 ]
    
    The x86 instruction decoder is used not only for decoding kernel
    instructions. It is also used by perf uprobes (user space probes) and by
    perf tools Intel Processor Trace decoding. Consequently, it needs to
    support instructions executed by user space also.
    
    Opcode 0x68 PUSH instruction is currently defined as 64-bit operand size
    only i.e. (d64). That was based on Intel SDM Opcode Map. However that is
    contradicted by the Instruction Set Reference section for PUSH in the
    same manual.
    
    Remove 64-bit operand size only annotation from opcode 0x68 PUSH
    instruction.
    
    Example:
    
      $ cat pushw.s
      .global  _start
      .text
      _start:
              pushw   $0x1234
              mov     $0x1,%eax   # system call number (sys_exit)
              int     $0x80
      $ as -o pushw.o pushw.s
      $ ld -s -o pushw pushw.o
      $ objdump -d pushw | tail -4
      0000000000401000 <.text>:
        401000:       66 68 34 12             pushw  $0x1234
        401004:       b8 01 00 00 00          mov    $0x1,%eax
        401009:       cd 80                   int    $0x80
      $ perf record -e intel_pt//u ./pushw
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.014 MB perf.data ]
    
     Before:
    
      $ perf script --insn-trace=disasm
      Warning:
      1 instruction trace errors
               pushw   10349 [000] 10586.869237014:            401000 [unknown] (/home/ahunter/git/misc/rtit-tests/pushw)           pushw $0x1234
               pushw   10349 [000] 10586.869237014:            401006 [unknown] (/home/ahunter/git/misc/rtit-tests/pushw)           addb %al, (%rax)
               pushw   10349 [000] 10586.869237014:            401008 [unknown] (/home/ahunter/git/misc/rtit-tests/pushw)           addb %cl, %ch
               pushw   10349 [000] 10586.869237014:            40100a [unknown] (/home/ahunter/git/misc/rtit-tests/pushw)           addb $0x2e, (%rax)
       instruction trace error type 1 time 10586.869237224 cpu 0 pid 10349 tid 10349 ip 0x40100d code 6: Trace doesn't match instruction
    
     After:
    
      $ perf script --insn-trace=disasm
                 pushw   10349 [000] 10586.869237014:            401000 [unknown] (./pushw)           pushw $0x1234
                 pushw   10349 [000] 10586.869237014:            401004 [unknown] (./pushw)           movl $1, %eax
    
    Fixes: eb13296cfaf6 ("x86: Instruction decoder API")
    Signed-off-by: Adrian Hunter <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/kconfig: Select ARCH_WANT_FRAME_POINTERS again when UNWINDER_FRAME_POINTER=y [+ + +]
Author: Masahiro Yamada <[email protected]>
Date:   Sun Feb 4 21:20:03 2024 +0900

    x86/kconfig: Select ARCH_WANT_FRAME_POINTERS again when UNWINDER_FRAME_POINTER=y
    
    [ Upstream commit 66ee3636eddcc82ab82b539d08b85fb5ac1dff9b ]
    
    It took me some time to understand the purpose of the tricky code at
    the end of arch/x86/Kconfig.debug.
    
    Without it, the following would be shown:
    
      WARNING: unmet direct dependencies detected for FRAME_POINTER
    
    because
    
      81d387190039 ("x86/kconfig: Consolidate unwinders into multiple choice selection")
    
    removed 'select ARCH_WANT_FRAME_POINTERS'.
    
    The correct and more straightforward approach should have been to move
    it where 'select FRAME_POINTER' is located.
    
    Several architectures properly handle the conditional selection of
    ARCH_WANT_FRAME_POINTERS. For example, 'config UNWINDER_FRAME_POINTER'
    in arch/arm/Kconfig.debug.
    
    Fixes: 81d387190039 ("x86/kconfig: Consolidate unwinders into multiple choice selection")
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Acked-by: Josh Poimboeuf <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/mm: Remove broken vsyscall emulation code from the page fault code [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Mon Apr 29 10:00:51 2024 +0200

    x86/mm: Remove broken vsyscall emulation code from the page fault code
    
    [ Upstream commit 02b670c1f88e78f42a6c5aee155c7b26960ca054 ]
    
    The syzbot-reported stack trace from hell in this discussion thread
    actually has three nested page faults:
    
      https://lore.kernel.org/r/[email protected]
    
    ... and I think that's actually the important thing here:
    
     - the first page fault is from user space, and triggers the vsyscall
       emulation.
    
     - the second page fault is from __do_sys_gettimeofday(), and that should
       just have caused the exception that then sets the return value to
       -EFAULT
    
     - the third nested page fault is due to _raw_spin_unlock_irqrestore() ->
       preempt_schedule() -> trace_sched_switch(), which then causes a BPF
       trace program to run, which does that bpf_probe_read_compat(), which
       causes that page fault under pagefault_disable().
    
    It's quite the nasty backtrace, and there's a lot going on.
    
    The problem is literally the vsyscall emulation, which sets
    
            current->thread.sig_on_uaccess_err = 1;
    
    and that causes the fixup_exception() code to send the signal *despite* the
    exception being caught.
    
    And I think that is in fact completely bogus.  It's completely bogus
    exactly because it sends that signal even when it *shouldn't* be sent -
    like for the BPF user mode trace gathering.
    
    In other words, I think the whole "sig_on_uaccess_err" thing is entirely
    broken, because it makes any nested page-faults do all the wrong things.
    
    Now, arguably, I don't think anybody should enable vsyscall emulation any
    more, but this test case clearly does.
    
    I think we should just make the "send SIGSEGV" be something that the
    vsyscall emulation does on its own, not this broken per-thread state for
    something that isn't actually per thread.
    
    The x86 page fault code actually tried to deal with the "incorrect nesting"
    by having that:
    
                    if (in_interrupt())
                            return;
    
    which ignores the sig_on_uaccess_err case when it happens in interrupts,
    but as shown by this example, these nested page faults do not need to be
    about interrupts at all.
    
    IOW, I think the only right thing is to remove that horrendously broken
    code.
    
    The attached patch looks like the ObviouslyCorrect(tm) thing to do.
    
    NOTE! This broken code goes back to this commit in 2011:
    
      4fc3490114bb ("x86-64: Set siginfo and context on vsyscall emulation faults")
    
    ... and back then the reason was to get all the siginfo details right.
    Honestly, I do not for a moment believe that it's worth getting the siginfo
    details right here, but part of the commit says:
    
        This fixes issues with UML when vsyscall=emulate.
    
    ... and so my patch to remove this garbage will probably break UML in this
    situation.
    
    I do not believe that anybody should be running with vsyscall=emulate in
    2024 in the first place, much less if you are doing things like UML. But
    let's see if somebody screams.
    
    Reported-and-tested-by: [email protected]
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Tested-by: Jiri Olsa <[email protected]>
    Acked-by: Andy Lutomirski <[email protected]>
    Link: https://lore.kernel.org/r/CAHk-=wh9D6f7HUkDgZHKmDCHUQmp+Co89GP+b8+z+G56BKeyNg@mail.gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/purgatory: Switch to the position-independent small code model [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Thu Apr 18 22:17:06 2024 +0200

    x86/purgatory: Switch to the position-independent small code model
    
    [ Upstream commit cba786af84a0f9716204e09f518ce3b7ada8555e ]
    
    On x86, the ordinary, position dependent small and kernel code models
    only support placement of the executable in 32-bit addressable memory,
    due to the use of 32-bit signed immediates to generate references to
    global variables. For the kernel, this implies that all global variables
    must reside in the top 2 GiB of the kernel virtual address space, where
    the implicit address bits 63:32 are equal to sign bit 31.
    
    This means the kernel code model is not suitable for other bare metal
    executables such as the kexec purgatory, which can be placed arbitrarily
    in the physical address space, where its address may no longer be
    representable as a sign extended 32-bit quantity. For this reason,
    commit
    
      e16c2983fba0 ("x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors")
    
    switched to the large code model, which uses 64-bit immediates for all
    symbol references, including function calls, in order to avoid relying
    on any assumptions regarding proximity of symbols in the final
    executable.
    
    The large code model is rarely used, clunky and the least likely to
    operate in a similar fashion when comparing GCC and Clang, so it is best
    avoided. This is especially true now that Clang 18 has started to emit
    executable code in two separate sections (.text and .ltext), which
    triggers an issue in the kexec loading code at runtime.
    
    The SUSE bugzilla fixes tag points to gcc 13 having issues with the
    large model too and that perhaps the large model should simply not be
    used at all.
    
    Instead, use the position independent small code model, which makes no
    assumptions about placement but only about proximity, where all
    referenced symbols must be within -/+ 2 GiB, i.e., in range for a
    RIP-relative reference. Use hidden visibility to suppress the use of a
    GOT, which carries absolute addresses that are not covered by static ELF
    relocations, and is therefore incompatible with the kexec loader's
    relocation logic.
    
      [ bp: Massage commit message. ]
    
    Fixes: e16c2983fba0 ("x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors")
    Fixes: https://bugzilla.suse.com/show_bug.cgi?id=1211853
    Closes: https://github.com/ClangBuiltLinux/linux/issues/2016
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Fangrui Song <[email protected]>
    Acked-by: Nick Desaulniers <[email protected]>
    Tested-by: Nathan Chancellor <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/tsc: Trust initial offset in architectural TSC-adjust MSRs [+ + +]
Author: Daniel J Blueman <[email protected]>
Date:   Fri Apr 19 16:51:46 2024 +0800

    x86/tsc: Trust initial offset in architectural TSC-adjust MSRs
    
    commit 455f9075f14484f358b3c1d6845b4a438de198a7 upstream.
    
    When the BIOS configures the architectural TSC-adjust MSRs on secondary
    sockets to correct a constant inter-chassis offset, after Linux brings the
    cores online, the TSC sync check later resets the core-local MSR to 0,
    triggering HPET fallback and leading to performance loss.
    
    Fix this by unconditionally using the initial adjust values read from the
    MSRs. Trusting the initial offsets in this architectural mechanism is a
    better approach than special-casing workarounds for specific platforms.
    
    Signed-off-by: Daniel J Blueman <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Steffen Persvold <[email protected]>
    Reviewed-by: James Cleverdon <[email protected]>
    Reviewed-by: Dimitri Sivanich <[email protected]>
    Reviewed-by: Prarit Bhargava <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>