Changelog in Linux kernel 5.15.162

 
ACPI: video: Add backlight=native quirk for Lenovo Slim 7 16ARH7 [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon May 6 16:08:50 2024 +0200

    ACPI: video: Add backlight=native quirk for Lenovo Slim 7 16ARH7
    
    [ Upstream commit c901f63dc142c48326931f164f787dfff69273d9 ]
    
    Lenovo Slim 7 16ARH7 is a machine with switchable graphics between AMD
    and Nvidia, and the backlight can't be adjusted properly unless
    acpi_backlight=native is passed.  Although nvidia-wmi-backlight is
    present and loaded, this doesn't work as expected at all.
    
    For making it working as default, add the corresponding quirk entry
    with a DMI matching "LENOVO" "82UX".
    
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1217750
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: x86: Force StorageD3Enable on more products [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Thu May 9 13:45:02 2024 -0500

    ACPI: x86: Force StorageD3Enable on more products
    
    [ Upstream commit e79a10652bbd320649da705ca1ea0c04351af403 ]
    
    A Rembrandt-based HP thin client is reported to have problems where
    the NVME disk isn't present after resume from s2idle.
    
    This is because the NVME disk wasn't put into D3 at suspend, and
    that happened because the StorageD3Enable _DSD was missing in the BIOS.
    
    As AMD's architecture requires that the NVME is in D3 for s2idle, adjust
    the criteria for force_storage_d3 to match *all* Zen SoCs when the FADT
    advertises low power idle support.
    
    This will ensure that any future products with this BIOS deficiency don't
    need to be added to the allow list of overrides.
    
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: x86: utils: Add Picasso to the list for forcing StorageD3Enable [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Fri Mar 31 11:08:42 2023 -0500

    ACPI: x86: utils: Add Picasso to the list for forcing StorageD3Enable
    
    [ Upstream commit 10b6b4a8ac6120ec36555fd286eed577f7632e3b ]
    
    Picasso was the first APU that introduced s2idle support from AMD,
    and it was predating before vendors started to use `StorageD3Enable`
    in their firmware.
    
    Windows doesn't have problems with this hardware and NVME so it was
    likely on the list of hardcoded CPUs to use this behavior in Windows.
    
    Add it to the list for Linux to avoid NVME resume issues.
    
    Reported-by: Stuart Axon <stuaxo2@yahoo.com>
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2449
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: e79a10652bbd ("ACPI: x86: Force StorageD3Enable on more products")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine." [+ + +]
Author: Raju Rangoju <Raju.Rangoju@amd.com>
Date:   Fri Jun 14 19:31:49 2024 +0530

    ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."
    
    [ Upstream commit a83e1385b780d41307433ddbc86e3c528db031f0 ]
    
    Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid
    "Info: mapping multiple BARs. Your kernel is fine.""). The initial
    purpose of this commit was to stop memory mappings for operation
    regions from overlapping page boundaries, as it can trigger warnings
    if different page attributes are present.
    
    However, it was found that when this situation arises, mapping
    continues until the boundary's end, but there is still an attempt to
    read/write the entire length of the map, leading to a NULL pointer
    deference. For example, if a four-byte mapping request is made but
    only one byte is mapped because it hits the current page boundary's
    end, a four-byte read/write attempt is still made, resulting in a NULL
    pointer deference.
    
    Instead, map the entire length, as the ACPI specification does not
    mandate that it must be within the same page boundary. It is
    permissible for it to be mapped across different regions.
    
    Link: https://github.com/acpica/acpica/pull/954
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218849
    Fixes: d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine."")
    Co-developed-by: Sanath S <Sanath.S@amd.com>
    Signed-off-by: Sanath S <Sanath.S@amd.com>
    Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
af_packet: avoid a false positive warning in packet_setsockopt() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 5 11:49:39 2024 +0000

    af_packet: avoid a false positive warning in packet_setsockopt()
    
    [ Upstream commit 86d43e2bf93ccac88ef71cee36a23282ebd9e427 ]
    
    Although the code is correct, the following line
    
            copy_from_sockptr(&req_u.req, optval, len));
    
    triggers this warning :
    
    memcpy: detected field-spanning write (size 28) of single field "dst" at include/linux/sockptr.h:49 (size 16)
    
    Refactor the code to be more explicit.
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
af_unix: Annodate data-races around sk->sk_state for writers. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:28 2024 -0700

    af_unix: Annodate data-races around sk->sk_state for writers.
    
    [ Upstream commit 942238f9735a4a4ebf8274b218d9a910158941d1 ]
    
    sk->sk_state is changed under unix_state_lock(), but it's read locklessly
    in many places.
    
    This patch adds WRITE_ONCE() on the writer side.
    
    We will add READ_ONCE() to the lockless readers in the following patches.
    
    Fixes: 83301b5367a9 ("af_unix: Set TCP_ESTABLISHED for datagram sockets too")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Annotate data-race of net->unx.sysctl_max_dgram_qlen. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:37 2024 -0700

    af_unix: Annotate data-race of net->unx.sysctl_max_dgram_qlen.
    
    [ Upstream commit bd9f2d05731f6a112d0c7391a0d537bfc588dbe6 ]
    
    net->unx.sysctl_max_dgram_qlen is exposed as a sysctl knob and can be
    changed concurrently.
    
    Let's use READ_ONCE() in unix_create1().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Annotate data-race of sk->sk_shutdown in sk_diag_fill(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:41 2024 -0700

    af_unix: Annotate data-race of sk->sk_shutdown in sk_diag_fill().
    
    [ Upstream commit efaf24e30ec39ebbea9112227485805a48b0ceb1 ]
    
    While dumping sockets via UNIX_DIAG, we do not hold unix_state_lock().
    
    Let's use READ_ONCE() to read sk->sk_shutdown.
    
    Fixes: e4e541a84863 ("sock-diag: Report shutdown for inet and unix sockets (v2)")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Annotate data-race of sk->sk_state in unix_inq_len(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:29 2024 -0700

    af_unix: Annotate data-race of sk->sk_state in unix_inq_len().
    
    [ Upstream commit 3a0f38eb285c8c2eead4b3230c7ac2983707599d ]
    
    ioctl(SIOCINQ) calls unix_inq_len() that checks sk->sk_state first
    and returns -EINVAL if it's TCP_LISTEN.
    
    Then, for SOCK_STREAM sockets, unix_inq_len() returns the number of
    bytes in recvq.
    
    However, unix_inq_len() does not hold unix_state_lock(), and the
    concurrent listen() might change the state after checking sk->sk_state.
    
    If the race occurs, 0 is returned for the listener, instead of -EINVAL,
    because the length of skb with embryo is 0.
    
    We could hold unix_state_lock() in unix_inq_len(), but it's overkill
    given the result is true for pre-listen() TCP_CLOSE state.
    
    So, let's use READ_ONCE() for sk->sk_state in unix_inq_len().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Annotate data-race of sk->sk_state in unix_stream_connect(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:31 2024 -0700

    af_unix: Annotate data-race of sk->sk_state in unix_stream_connect().
    
    [ Upstream commit a9bf9c7dc6a5899c01cb8f6e773a66315a5cd4b7 ]
    
    As small optimisation, unix_stream_connect() prefetches the client's
    sk->sk_state without unix_state_lock() and checks if it's TCP_CLOSE.
    
    Later, sk->sk_state is checked again under unix_state_lock().
    
    Let's use READ_ONCE() for the first check and TCP_CLOSE directly for
    the second check.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Annotate data-race of sk->sk_state in unix_stream_read_skb(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:34 2024 -0700

    af_unix: Annotate data-race of sk->sk_state in unix_stream_read_skb().
    
    [ Upstream commit af4c733b6b1aded4dc808fafece7dfe6e9d2ebb3 ]
    
    unix_stream_read_skb() is called from sk->sk_data_ready() context
    where unix_state_lock() is not held.
    
    Let's use READ_ONCE() there.
    
    Fixes: 77462de14a43 ("af_unix: Add read_sock for stream socket types")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Annotate data-races around sk->sk_state in sendmsg() and recvmsg(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:33 2024 -0700

    af_unix: Annotate data-races around sk->sk_state in sendmsg() and recvmsg().
    
    [ Upstream commit 8a34d4e8d9742a24f74998f45a6a98edd923319b ]
    
    The following functions read sk->sk_state locklessly and proceed only if
    the state is TCP_ESTABLISHED.
    
      * unix_stream_sendmsg
      * unix_stream_read_generic
      * unix_seqpacket_sendmsg
      * unix_seqpacket_recvmsg
    
    Let's use READ_ONCE() there.
    
    Fixes: a05d2ad1c1f3 ("af_unix: Only allow recv on connected seqpacket sockets.")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Annotate data-races around sk->sk_state in UNIX_DIAG. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:35 2024 -0700

    af_unix: Annotate data-races around sk->sk_state in UNIX_DIAG.
    
    [ Upstream commit 0aa3be7b3e1f8f997312cc4705f8165e02806f8f ]
    
    While dumping AF_UNIX sockets via UNIX_DIAG, sk->sk_state is read
    locklessly.
    
    Let's use READ_ONCE() there.
    
    Note that the result could be inconsistent if the socket is dumped
    during the state change.  This is common for other SOCK_DIAG and
    similar interfaces.
    
    Fixes: c9da99e6475f ("unix_diag: Fixup RQLEN extension report")
    Fixes: 2aac7a2cb0d9 ("unix_diag: Pending connections IDs NLA")
    Fixes: 45a96b9be6ec ("unix_diag: Dumping all sockets core")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Annotate data-races around sk->sk_state in unix_write_space() and poll(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:30 2024 -0700

    af_unix: Annotate data-races around sk->sk_state in unix_write_space() and poll().
    
    [ Upstream commit eb0718fb3e97ad0d6f4529b810103451c90adf94 ]
    
    unix_poll() and unix_dgram_poll() read sk->sk_state locklessly and
    calls unix_writable() which also reads sk->sk_state without holding
    unix_state_lock().
    
    Let's use READ_ONCE() in unix_poll() and unix_dgram_poll() and pass
    it to unix_writable().
    
    While at it, we remove TCP_SYN_SENT check in unix_dgram_poll() as
    that state does not exist for AF_UNIX socket since the code was added.
    
    Fixes: 1586a5877db9 ("af_unix: do not report POLLOUT on listeners")
    Fixes: 3c73419c09a5 ("af_unix: fix 'poll for write'/ connected DGRAM sockets")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: annotate lockless accesses to sk->sk_err [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 15 20:57:46 2023 +0000

    af_unix: annotate lockless accesses to sk->sk_err
    
    [ Upstream commit cc04410af7de348234ac36a5f50c4ce416efdb4b ]
    
    unix_poll() and unix_dgram_poll() read sk->sk_err
    without any lock held.
    
    Add relevant READ_ONCE()/WRITE_ONCE() annotations.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 83690b82d228 ("af_unix: Use skb_queue_empty_lockless() in unix_release_sock().")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Read with MSG_PEEK loops if the first unread byte is OOB [+ + +]
Author: Rao Shoaib <Rao.Shoaib@oracle.com>
Date:   Tue Jun 11 01:46:39 2024 -0700

    af_unix: Read with MSG_PEEK loops if the first unread byte is OOB
    
    [ Upstream commit a6736a0addd60fccc3a3508461d72314cc609772 ]
    
    Read with MSG_PEEK flag loops if the first byte to read is an OOB byte.
    commit 22dd70eb2c3d ("af_unix: Don't peek OOB data without MSG_OOB.")
    addresses the loop issue but does not address the issue that no data
    beyond OOB byte can be read.
    
    >>> from socket import *
    >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
    >>> c1.send(b'a', MSG_OOB)
    1
    >>> c1.send(b'b')
    1
    >>> c2.recv(1, MSG_PEEK | MSG_DONTWAIT)
    b'b'
    
    >>> from socket import *
    >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
    >>> c2.setsockopt(SOL_SOCKET, SO_OOBINLINE, 1)
    >>> c1.send(b'a', MSG_OOB)
    1
    >>> c1.send(b'b')
    1
    >>> c2.recv(1, MSG_PEEK | MSG_DONTWAIT)
    b'a'
    >>> c2.recv(1, MSG_PEEK | MSG_DONTWAIT)
    b'a'
    >>> c2.recv(1, MSG_DONTWAIT)
    b'a'
    >>> c2.recv(1, MSG_PEEK | MSG_DONTWAIT)
    b'b'
    >>>
    
    Fixes: 314001f0bf92 ("af_unix: Add OOB support")
    Signed-off-by: Rao Shoaib <Rao.Shoaib@oracle.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240611084639.2248934-1-Rao.Shoaib@oracle.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Set sk->sk_state under unix_state_lock() for truly disconencted peer. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:27 2024 -0700

    af_unix: Set sk->sk_state under unix_state_lock() for truly disconencted peer.
    
    [ Upstream commit 26bfb8b57063f52b867f9b6c8d1742fcb5bd656c ]
    
    When a SOCK_DGRAM socket connect()s to another socket, the both sockets'
    sk->sk_state are changed to TCP_ESTABLISHED so that we can register them
    to BPF SOCKMAP.
    
    When the socket disconnects from the peer by connect(AF_UNSPEC), the state
    is set back to TCP_CLOSE.
    
    Then, the peer's state is also set to TCP_CLOSE, but the update is done
    locklessly and unconditionally.
    
    Let's say socket A connect()ed to B, B connect()ed to C, and A disconnects
    from B.
    
    After the first two connect()s, all three sockets' sk->sk_state are
    TCP_ESTABLISHED:
    
      $ ss -xa
      Netid State  Recv-Q Send-Q  Local Address:Port  Peer Address:PortProcess
      u_dgr ESTAB  0      0       @A 641              * 642
      u_dgr ESTAB  0      0       @B 642              * 643
      u_dgr ESTAB  0      0       @C 643              * 0
    
    And after the disconnect, B's state is TCP_CLOSE even though it's still
    connected to C and C's state is TCP_ESTABLISHED.
    
      $ ss -xa
      Netid State  Recv-Q Send-Q  Local Address:Port  Peer Address:PortProcess
      u_dgr UNCONN 0      0       @A 641              * 0
      u_dgr UNCONN 0      0       @B 642              * 643
      u_dgr ESTAB  0      0       @C 643              * 0
    
    In this case, we cannot register B to SOCKMAP.
    
    So, when a socket disconnects from the peer, we should not set TCP_CLOSE to
    the peer if the peer is connected to yet another socket, and this must be
    done under unix_state_lock().
    
    Note that we use WRITE_ONCE() for sk->sk_state as there are many lockless
    readers.  These data-races will be fixed in the following patches.
    
    Fixes: 83301b5367a9 ("af_unix: Set TCP_ESTABLISHED for datagram sockets too")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Use skb_queue_empty_lockless() in unix_release_sock(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:39 2024 -0700

    af_unix: Use skb_queue_empty_lockless() in unix_release_sock().
    
    [ Upstream commit 83690b82d228b3570565ebd0b41873933238b97f ]
    
    If the socket type is SOCK_STREAM or SOCK_SEQPACKET, unix_release_sock()
    checks the length of the peer socket's recvq under unix_state_lock().
    
    However, unix_stream_read_generic() calls skb_unlink() after releasing
    the lock.  Also, for SOCK_SEQPACKET, __skb_try_recv_datagram() unlinks
    skb without unix_state_lock().
    
    Thues, unix_state_lock() does not protect qlen.
    
    Let's use skb_queue_empty_lockless() in unix_release_sock().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Use skb_queue_len_lockless() in sk_diag_show_rqlen(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:40 2024 -0700

    af_unix: Use skb_queue_len_lockless() in sk_diag_show_rqlen().
    
    [ Upstream commit 5d915e584d8408211d4567c22685aae8820bfc55 ]
    
    We can dump the socket queue length via UNIX_DIAG by specifying
    UDIAG_SHOW_RQLEN.
    
    If sk->sk_state is TCP_LISTEN, we return the recv queue length,
    but here we do not hold recvq lock.
    
    Let's use skb_queue_len_lockless() in sk_diag_show_rqlen().
    
    Fixes: c9da99e6475f ("unix_diag: Fixup RQLEN extension report")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Use unix_recvq_full_lockless() in unix_stream_connect(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jun 4 09:52:38 2024 -0700

    af_unix: Use unix_recvq_full_lockless() in unix_stream_connect().
    
    [ Upstream commit 45d872f0e65593176d880ec148f41ad7c02e40a7 ]
    
    Once sk->sk_state is changed to TCP_LISTEN, it never changes.
    
    unix_accept() takes advantage of this characteristics; it does not
    hold the listener's unix_state_lock() and only acquires recvq lock
    to pop one skb.
    
    It means unix_state_lock() does not prevent the queue length from
    changing in unix_stream_connect().
    
    Thus, we need to use unix_recvq_full_lockless() to avoid data-race.
    
    Now we remove unix_recvq_full() as no one uses it.
    
    Note that we can remove READ_ONCE() for sk->sk_max_ack_backlog in
    unix_recvq_full_lockless() because of the following reasons:
    
      (1) For SOCK_DGRAM, it is a written-once field in unix_create1()
    
      (2) For SOCK_STREAM and SOCK_SEQPACKET, it is changed under the
          listener's unix_state_lock() in unix_listen(), and we hold
          the lock in unix_stream_connect()
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: emux: improve patch ioctl data validation [+ + +]
Author: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date:   Sat Apr 6 08:48:20 2024 +0200

    ALSA: emux: improve patch ioctl data validation
    
    [ Upstream commit 89b32ccb12ae67e630c6453d778ec30a592a212f ]
    
    In load_data(), make the validation of and skipping over the main info
    block match that in load_guspatch().
    
    In load_guspatch(), add checking that the specified patch length matches
    the actually supplied data, like load_data() already did.
    
    Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
    Message-ID: <20240406064830.1029573-8-oswald.buddenhagen@gmx.de>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/realtek: Limit mic boost on N14AP7 [+ + +]
Author: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Date:   Wed Jun 5 12:39:23 2024 -0300

    ALSA: hda/realtek: Limit mic boost on N14AP7
    
    commit 86a433862912f52597263aa224a9ed82bcd533bf upstream.
    
    The internal mic boost on the N14AP7 is too high. Fix this by applying the
    ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine to limit the gain.
    
    Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240605153923.2837-1-edson.drosdeck@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm64: dts: imx8qm-mek: fix gpio number for reg_usdhc2_vmmc [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Jun 14 11:06:32 2024 -0400

    arm64: dts: imx8qm-mek: fix gpio number for reg_usdhc2_vmmc
    
    commit dfd239a039b3581ca25f932e66b6e2c2bf77c798 upstream.
    
    The gpio in "reg_usdhc2_vmmc" should be 7 instead of 19.
    
    Cc: stable@vger.kernel.org
    Fixes: 307fd14d4b14 ("arm64: dts: imx: add imx8qm mek support")
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: dts: rockchip: Add sound-dai-cells for RK3368 [+ + +]
Author: Alex Bee <knaerzche@gmail.com>
Date:   Sun Jun 23 11:01:15 2024 +0200

    arm64: dts: rockchip: Add sound-dai-cells for RK3368
    
    [ Upstream commit 8d7ec44aa5d1eb94a30319074762a1740440cdc8 ]
    
    Add the missing #sound-dai-cells for RK3368's I2S and S/PDIF controllers.
    
    Fixes: f7d89dfe1e31 ("arm64: dts: rockchip: add i2s nodes support for RK3368 SoCs")
    Fixes: 0328d68ea76d ("arm64: dts: rockchip: add rk3368 spdif node")
    Signed-off-by: Alex Bee <knaerzche@gmail.com>
    Link: https://lore.kernel.org/r/20240623090116.670607-4-knaerzche@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: fix PMIC interrupt pin on ROCK Pi E [+ + +]
Author: FUKAUMI Naoki <naoki@radxa.com>
Date:   Wed Jun 19 14:00:46 2024 +0900

    arm64: dts: rockchip: fix PMIC interrupt pin on ROCK Pi E
    
    [ Upstream commit 02afd3d5b9fa4ffed284c0f7e7bec609097804fc ]
    
    use GPIO0_A2 as interrupt pin for PMIC. GPIO2_A6 was used for
    pre-production board.
    
    Fixes: b918e81f2145 ("arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E")
    Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
    Link: https://lore.kernel.org/r/20240619050047.1217-1-naoki@radxa.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node [+ + +]
Author: Johan Jonker <jbx6244@gmail.com>
Date:   Thu Jun 13 20:08:10 2024 +0200

    ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node
    
    [ Upstream commit cca46f811d0000c1522a5e18ea48c27a15e45c05 ]
    
    '#sound-dai-cells' is required to properly interpret
    the list of DAI specified in the 'sound-dai' property,
    so add them to the 'hdmi' node for 'rk3066a.dtsi'.
    
    Fixes: fadc78062477 ("ARM: dts: rockchip: add rk3066 hdmi nodes")
    Signed-off-by: Johan Jonker <jbx6244@gmail.com>
    Link: https://lore.kernel.org/r/8b229dcc-94e4-4bbc-9efc-9d5ddd694532@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: samsung: exynos4412-origen: fix keypad no-autorepeat [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Tue Mar 12 19:31:03 2024 +0100

    ARM: dts: samsung: exynos4412-origen: fix keypad no-autorepeat
    
    [ Upstream commit 88208d3cd79821117fd3fb80d9bcab618467d37b ]
    
    Although the Samsung SoC keypad binding defined
    linux,keypad-no-autorepeat property, Linux driver never implemented it
    and always used linux,input-no-autorepeat.  Correct the DTS to use
    property actually implemented.
    
    This also fixes dtbs_check errors like:
    
      exynos4412-origen.dtb: keypad@100a0000: 'linux,keypad-no-autorepeat' does not match any of the regexes: '^key-[0-9a-z]+$', 'pinctrl-[0-9]+'
    
    Cc: <stable@vger.kernel.org>
    Fixes: bd08f6277e44 ("ARM: dts: Add keypad entries to Exynos4412 based Origen")
    Link: https://lore.kernel.org/r/20240312183105.715735-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: samsung: smdk4412: fix keypad no-autorepeat [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Tue Mar 12 19:31:04 2024 +0100

    ARM: dts: samsung: smdk4412: fix keypad no-autorepeat
    
    [ Upstream commit 4ac4c1d794e7ff454d191bbdab7585ed8dbf3758 ]
    
    Although the Samsung SoC keypad binding defined
    linux,keypad-no-autorepeat property, Linux driver never implemented it
    and always used linux,input-no-autorepeat.  Correct the DTS to use
    property actually implemented.
    
    This also fixes dtbs_check errors like:
    
      exynos4412-smdk4412.dtb: keypad@100a0000: 'key-A', 'key-B', 'key-C', 'key-D', 'key-E', 'linux,keypad-no-autorepeat' do not match any of the regexes: '^key-[0-9a-z]+$', 'pinctrl-[0-9]+'
    
    Cc: <stable@vger.kernel.org>
    Fixes: c9b92dd70107 ("ARM: dts: Add keypad entries to SMDK4412")
    Link: https://lore.kernel.org/r/20240312183105.715735-3-krzysztof.kozlowski@linaro.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: samsung: smdkv310: fix keypad no-autorepeat [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Tue Mar 12 19:31:02 2024 +0100

    ARM: dts: samsung: smdkv310: fix keypad no-autorepeat
    
    [ Upstream commit 87d8e522d6f5a004f0aa06c0def302df65aff296 ]
    
    Although the Samsung SoC keypad binding defined
    linux,keypad-no-autorepeat property, Linux driver never implemented it
    and always used linux,input-no-autorepeat.  Correct the DTS to use
    property actually implemented.
    
    This also fixes dtbs_check errors like:
    
      exynos4210-smdkv310.dtb: keypad@100a0000: 'linux,keypad-no-autorepeat' does not match any of the regexes: '^key-[0-9a-z]+$', 'pinctrl-[0-9]+'
    
    Cc: <stable@vger.kernel.org>
    Fixes: 0561ceabd0f1 ("ARM: dts: Add intial dts file for EXYNOS4210 SoC, SMDKV310 and ORIGEN")
    Link: https://lore.kernel.org/r/20240312183105.715735-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: fsl-asoc-card: set priv->pdev before using it [+ + +]
Author: Elinor Montmasson <elinor.montmasson@savoirfairelinux.com>
Date:   Thu Jun 20 15:25:03 2024 +0200

    ASoC: fsl-asoc-card: set priv->pdev before using it
    
    [ Upstream commit 90f3feb24172185f1832636264943e8b5e289245 ]
    
    priv->pdev pointer was set after being used in
    fsl_asoc_card_audmux_init().
    Move this assignment at the start of the probe function, so
    sub-functions can correctly use pdev through priv.
    
    fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the
    dev struct, used with dev_err macros.
    As priv is zero-initialised, there would be a NULL pointer dereference.
    Note that if priv->dev is dereferenced before assignment but never used,
    for example if there is no error to be printed, the driver won't crash
    probably due to compiler optimisations.
    
    Fixes: 708b4351f08c ("ASoC: fsl: Add Freescale Generic ASoC Sound Card with ASRC support")
    Signed-off-by: Elinor Montmasson <elinor.montmasson@savoirfairelinux.com>
    Link: https://patch.msgid.link/20240620132511.4291-2-elinor.montmasson@savoirfairelinux.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: ahci: Clean up sysfs file on error [+ + +]
Author: Niklas Cassel <cassel@kernel.org>
Date:   Sat Jun 29 14:42:14 2024 +0200

    ata: ahci: Clean up sysfs file on error
    
    commit eeb25a09c5e0805d92e4ebd12c4b0ad0df1b0295 upstream.
    
    .probe() (ahci_init_one()) calls sysfs_add_file_to_group(), however,
    if probe() fails after this call, we currently never call
    sysfs_remove_file_from_group().
    
    (The sysfs_remove_file_from_group() call in .remove() (ahci_remove_one())
    does not help, as .remove() is not called on .probe() error.)
    
    Thus, if probe() fails after the sysfs_add_file_to_group() call, the next
    time we insmod the module we will get:
    
    sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/remapped_nvme'
    CPU: 11 PID: 954 Comm: modprobe Not tainted 6.10.0-rc5 #43
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x5d/0x80
     sysfs_warn_dup.cold+0x17/0x23
     sysfs_add_file_mode_ns+0x11a/0x130
     sysfs_add_file_to_group+0x7e/0xc0
     ahci_init_one+0x31f/0xd40 [ahci]
    
    Fixes: 894fba7f434a ("ata: ahci: Add sysfs attribute to show remapped NVMe device count")
    Cc: stable@vger.kernel.org
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Link: https://lore.kernel.org/r/20240629124210.181537-10-cassel@kernel.org
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ata: libata-core: Fix double free on error [+ + +]
Author: Niklas Cassel <cassel@kernel.org>
Date:   Sat Jun 29 14:42:13 2024 +0200

    ata: libata-core: Fix double free on error
    
    commit ab9e0c529eb7cafebdd31fe1644524e80a48b05d upstream.
    
    If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
    to the err_out label, which will call devres_release_group().
    devres_release_group() will trigger a call to ata_host_release().
    ata_host_release() calls kfree(host), so executing the kfree(host) in
    ata_host_alloc() will lead to a double free:
    
    kernel BUG at mm/slub.c:553!
    Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
    RIP: 0010:kfree+0x2cf/0x2f0
    Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
    RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
    RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
    RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
    RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
    R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
    R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
    FS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? __die_body.cold+0x19/0x27
     ? die+0x2e/0x50
     ? do_trap+0xca/0x110
     ? do_error_trap+0x6a/0x90
     ? kfree+0x2cf/0x2f0
     ? exc_invalid_op+0x50/0x70
     ? kfree+0x2cf/0x2f0
     ? asm_exc_invalid_op+0x1a/0x20
     ? ata_host_alloc+0xf5/0x120 [libata]
     ? ata_host_alloc+0xf5/0x120 [libata]
     ? kfree+0x2cf/0x2f0
     ata_host_alloc+0xf5/0x120 [libata]
     ata_host_alloc_pinfo+0x14/0xa0 [libata]
     ahci_init_one+0x6c9/0xd20 [ahci]
    
    Ensure that we will not call kfree(host) twice, by performing the kfree()
    only if the devres_open_group() call failed.
    
    Fixes: dafd6c496381 ("libata: ensure host is free'd on error exit paths")
    Cc: stable@vger.kernel.org
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Link: https://lore.kernel.org/r/20240629124210.181537-9-cassel@kernel.org
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Avoid hw_desc array overrun in dw-axi-dmac [+ + +]
Author: Joao Pinto <Joao.Pinto@synopsys.com>
Date:   Wed Mar 27 10:49:24 2024 +0000

    Avoid hw_desc array overrun in dw-axi-dmac
    
    [ Upstream commit 333e11bf47fa8d477db90e2900b1ed3c9ae9b697 ]
    
    I have a use case where nr_buffers = 3 and in which each descriptor is composed by 3
    segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put()
    handles the hw_desc considering the descs_allocated, this scenario would result in a
    kernel panic (hw_desc array will be overrun).
    
    To fix this, the proposal is to add a new member to the axi_dma_desc structure,
    where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in
    axi_desc_put() to handle the hw_desc array correctly.
    
    Additionally I propose to remove the axi_chan_start_first_queued() call after completing
    the transfer, since it was identified that unbalance can occur (started descriptors can
    be interrupted and transfer ignored due to DMA channel not being enabled).
    
    Signed-off-by: Joao Pinto <jpinto@synopsys.com>
    Link: https://lore.kernel.org/r/1711536564-12919-1-git-send-email-jpinto@synopsys.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
batman-adv: bypass empty buckets in batadv_purge_orig_ref() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Mar 30 15:54:38 2024 +0000

    batman-adv: bypass empty buckets in batadv_purge_orig_ref()
    
    [ Upstream commit 40dc8ab605894acae1473e434944924a22cfaaa0 ]
    
    Many syzbot reports are pointing to soft lockups in
    batadv_purge_orig_ref() [1]
    
    Root cause is unknown, but we can avoid spending too much
    time there and perhaps get more interesting reports.
    
    [1]
    
    watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]
    Modules linked in:
    irq event stamp: 6182794
     hardirqs last  enabled at (6182793): [<ffff8000801dae10>] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
     hardirqs last disabled at (6182794): [<ffff80008ad66a78>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
     hardirqs last disabled at (6182794): [<ffff80008ad66a78>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
     softirqs last  enabled at (6182792): [<ffff80008aab71c4>] spin_unlock_bh include/linux/spinlock.h:396 [inline]
     softirqs last  enabled at (6182792): [<ffff80008aab71c4>] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
     softirqs last disabled at (6182790): [<ffff80008aab61dc>] spin_lock_bh include/linux/spinlock.h:356 [inline]
     softirqs last disabled at (6182790): [<ffff80008aab61dc>] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271
    CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    Workqueue: bat_events batadv_purge_orig
    pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]
     pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388
     lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
    sp : ffff800099007970
    x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000
    x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001
    x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4
    x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0
    x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001
    x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003
    x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000
    x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000
    x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000
    x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000
    Call trace:
      __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]
      arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]
      __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386
      __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
      _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210
      spin_unlock_bh include/linux/spinlock.h:396 [inline]
      batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
      batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300
      process_one_work+0x694/0x1204 kernel/workqueue.c:2633
      process_scheduled_works kernel/workqueue.c:2706 [inline]
      worker_thread+0x938/0xef4 kernel/workqueue.c:2787
      kthread+0x288/0x310 kernel/kthread.c:388
      ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
    Sending NMI from CPU 0 to CPUs 1:
    NMI backtrace for cpu 1
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51
     lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103
    sp : ffff800093a17d30
    x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4
    x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002
    x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000
    x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396
    x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001
    x14: 1fffe00036805f10 x13: 0000000000000000 x12: 0000000000000003
    x11: 0000000000000001 x10: 0000000000000003 x9 : 0000000000000000
    x8 : 00000000000ce8d1 x7 : ffff8000804609e4 x6 : 0000000000000000
    x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff80008ad6aac0
    x2 : 0000000000000000 x1 : ffff80008aedea60 x0 : ffff800125436000
    Call trace:
      __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]
      arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:49
      cpuidle_idle_call kernel/sched/idle.c:170 [inline]
      do_idle+0x1f0/0x4e8 kernel/sched/idle.c:312
      cpu_startup_entry+0x5c/0x74 kernel/sched/idle.c:410
      secondary_start_kernel+0x198/0x1c0 arch/arm64/kernel/smp.c:272
      __secondary_switched+0xb8/0xbc arch/arm64/kernel/head.S:404
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

batman-adv: Don't accept TT entries for out-of-spec VIDs [+ + +]
Author: Sven Eckelmann <sven@narfation.org>
Date:   Sat May 4 21:57:30 2024 +0200

    batman-adv: Don't accept TT entries for out-of-spec VIDs
    
    commit 537a350d14321c8cca5efbf0a33a404fec3a9f9e upstream.
    
    The internal handling of VLAN IDs in batman-adv is only specified for
    following encodings:
    
    * VLAN is used
      - bit 15 is 1
      - bit 11 - bit 0 is the VLAN ID (0-4095)
      - remaining bits are 0
    * No VLAN is used
      - bit 15 is 0
      - remaining bits are 0
    
    batman-adv was only preparing new translation table entries (based on its
    soft interface information) using this encoding format. But the receive
    path was never checking if entries in the roam or TT TVLVs were also
    following this encoding.
    
    It was therefore possible to create more than the expected maximum of 4096
    + 1 entries in the originator VLAN list. Simply by setting the "remaining
    bits" to "random" values in corresponding TVLV.
    
    Cc: stable@vger.kernel.org
    Fixes: 7ea7b4a14275 ("batman-adv: make the TT CRC logic VLAN specific")
    Reported-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bcache: fix variable length array abuse in btree_iter [+ + +]
Author: Matthew Mirvish <matthew@mm12.xyz>
Date:   Thu May 9 09:11:17 2024 +0800

    bcache: fix variable length array abuse in btree_iter
    
    [ Upstream commit 3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31 ]
    
    btree_iter is used in two ways: either allocated on the stack with a
    fixed size MAX_BSETS, or from a mempool with a dynamic size based on the
    specific cache set. Previously, the struct had a fixed-length array of
    size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized
    iterators, which causes UBSAN to complain.
    
    This patch uses the same approach as in bcachefs's sort_iter and splits
    the iterator into a btree_iter with a flexible array member and a
    btree_iter_stack which embeds a btree_iter as well as a fixed-length
    data array.
    
    Cc: stable@vger.kernel.org
    Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039368
    Signed-off-by: Matthew Mirvish <matthew@mm12.xyz>
    Signed-off-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20240509011117.2697-3-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block/ioctl: prefer different overflow check [+ + +]
Author: Justin Stitt <justinstitt@google.com>
Date:   Tue May 7 03:53:49 2024 +0000

    block/ioctl: prefer different overflow check
    
    [ Upstream commit ccb326b5f9e623eb7f130fbbf2505ec0e2dcaff9 ]
    
    Running syzkaller with the newly reintroduced signed integer overflow
    sanitizer shows this report:
    
    [   62.982337] ------------[ cut here ]------------
    [   62.985692] cgroup: Invalid name
    [   62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46
    [   62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1
    [   62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long'
    [   62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1
    [   62.999369] random: crng reseeded on system resumption
    [   63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000)
    [   63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
    [   63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    [   63.000682] Call Trace:
    [   63.000686]  <TASK>
    [   63.000731]  dump_stack_lvl+0x93/0xd0
    [   63.000919]  __get_user_pages+0x903/0xd30
    [   63.001030]  __gup_longterm_locked+0x153e/0x1ba0
    [   63.001041]  ? _raw_read_unlock_irqrestore+0x17/0x50
    [   63.001072]  ? try_get_folio+0x29c/0x2d0
    [   63.001083]  internal_get_user_pages_fast+0x1119/0x1530
    [   63.001109]  iov_iter_extract_pages+0x23b/0x580
    [   63.001206]  bio_iov_iter_get_pages+0x4de/0x1220
    [   63.001235]  iomap_dio_bio_iter+0x9b6/0x1410
    [   63.001297]  __iomap_dio_rw+0xab4/0x1810
    [   63.001316]  iomap_dio_rw+0x45/0xa0
    [   63.001328]  ext4_file_write_iter+0xdde/0x1390
    [   63.001372]  vfs_write+0x599/0xbd0
    [   63.001394]  ksys_write+0xc8/0x190
    [   63.001403]  do_syscall_64+0xd4/0x1b0
    [   63.001421]  ? arch_exit_to_user_mode_prepare+0x3a/0x60
    [   63.001479]  entry_SYSCALL_64_after_hwframe+0x6f/0x77
    [   63.001535] RIP: 0033:0x7f7fd3ebf539
    [   63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    [   63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [   63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539
    [   63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004
    [   63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000
    [   63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    [   63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8
    ...
    [   63.018142] ---[ end trace ]---
    
    Historically, the signed integer overflow sanitizer did not work in the
    kernel due to its interaction with `-fwrapv` but this has since been
    changed [1] in the newest version of Clang; It was re-enabled in the
    kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow
    sanitizer").
    
    Let's rework this overflow checking logic to not actually perform an
    overflow during the check itself, thus avoiding the UBSAN splat.
    
    [1]: https://github.com/llvm/llvm-project/pull/82432
    
    Signed-off-by: Justin Stitt <justinstitt@google.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20240507-b4-sio-block-ioctl-v3-1-ba0c2b32275e@google.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: ath3k: Fix multiple issues reported by checkpatch.pl [+ + +]
Author: Uri Arev <me@wantyapps.xyz>
Date:   Sat Apr 6 00:42:24 2024 +0300

    Bluetooth: ath3k: Fix multiple issues reported by checkpatch.pl
    
    [ Upstream commit 68aa21054ec3a1a313af90a5f95ade16c3326d20 ]
    
    This fixes some CHECKs reported by the checkpatch script.
    
    Issues reported in ath3k.c:
    -------
    ath3k.c
    -------
    CHECK: Please don't use multiple blank lines
    +
    +
    
    CHECK: Blank lines aren't necessary after an open brace '{'
    +static const struct usb_device_id ath3k_blist_tbl[] = {
    +
    
    CHECK: Alignment should match open parenthesis
    +static int ath3k_load_firmware(struct usb_device *udev,
    +                               const struct firmware *firmware)
    
    CHECK: Alignment should match open parenthesis
    +               err = usb_bulk_msg(udev, pipe, send_buf, size,
    +                                       &len, 3000);
    
    CHECK: Unnecessary parentheses around 'len != size'
    +               if (err || (len != size)) {
    
    CHECK: Alignment should match open parenthesis
    +static int ath3k_get_version(struct usb_device *udev,
    +                       struct ath3k_version *version)
    
    CHECK: Alignment should match open parenthesis
    +static int ath3k_load_fwfile(struct usb_device *udev,
    +               const struct firmware *firmware)
    
    CHECK: Alignment should match open parenthesis
    +               err = usb_bulk_msg(udev, pipe, send_buf, size,
    +                                       &len, 3000);
    
    CHECK: Unnecessary parentheses around 'len != size'
    +               if (err || (len != size)) {
    
    CHECK: Blank lines aren't necessary after an open brace '{'
    +       switch (fw_version.ref_clock) {
    +
    
    CHECK: Alignment should match open parenthesis
    +       snprintf(filename, ATH3K_NAME_LEN, "ar3k/ramps_0x%08x_%d%s",
    +               le32_to_cpu(fw_version.rom_version), clk_value, ".dfu");
    
    CHECK: Alignment should match open parenthesis
    +static int ath3k_probe(struct usb_interface *intf,
    +                       const struct usb_device_id *id)
    
    CHECK: Alignment should match open parenthesis
    +                       BT_ERR("Firmware file \"%s\" not found",
    +                                                       ATH3K_FIRMWARE);
    
    CHECK: Alignment should match open parenthesis
    +               BT_ERR("Firmware file \"%s\" request failed (err=%d)",
    +                                               ATH3K_FIRMWARE, ret);
    
    total: 0 errors, 0 warnings, 14 checks, 540 lines checked
    
    Signed-off-by: Uri Arev <me@wantyapps.xyz>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: btqca: Add WCN3988 support [+ + +]
Author: Luca Weiss <luca.weiss@fairphone.com>
Date:   Wed Aug 2 08:56:29 2023 +0200

    Bluetooth: btqca: Add WCN3988 support
    
    [ Upstream commit f904feefe60c28b6852d5625adc4a2c39426a2d9 ]
    
    Add support for the Bluetooth chip codenamed APACHE which is part of
    WCN3988.
    
    The firmware for this chip has a slightly different naming scheme
    compared to most others. For ROM Version 0x0200 we need to use
    apbtfw10.tlv + apnv10.bin and for ROM version 0x201 apbtfw11.tlv +
    apnv11.bin
    
    Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: cda0d6a198e2 ("Bluetooth: qca: fix info leak when fetching fw build id")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: btqca: use le32_to_cpu for ver.soc_id [+ + +]
Author: Min-Hua Chen <minhuadotchen@gmail.com>
Date:   Fri May 19 18:43:23 2023 +0800

    Bluetooth: btqca: use le32_to_cpu for ver.soc_id
    
    [ Upstream commit 8153b738bc547878a017889d2b1cf8dd2de0e0c6 ]
    
    Use le32_to_cpu for ver.soc_id to fix the following
    sparse warning.
    
    drivers/bluetooth/btqca.c:640:24: sparse: warning: restricted
    __le32 degrades to integer
    
    Signed-off-by: Min-Hua Chen <minhuadotchen@gmail.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: cda0d6a198e2 ("Bluetooth: qca: fix info leak when fetching fw build id")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_qca: mark OF related data as maybe unused [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sat Mar 11 12:13:53 2023 +0100

    Bluetooth: hci_qca: mark OF related data as maybe unused
    
    [ Upstream commit 44fac8a2fd2f72ee98ee41e6bc9ecc7765b5d3cc ]
    
    The driver can be compile tested with !CONFIG_OF making certain data
    unused:
    
      drivers/bluetooth/hci_qca.c:1869:37: error: ‘qca_soc_data_wcn6750’
      defined but not used [-Werror=unused-const-variable=]
      drivers/bluetooth/hci_qca.c:1853:37: error: ‘qca_soc_data_wcn3998’
      defined but not used [-Werror=unused-const-variable=]
      drivers/bluetooth/hci_qca.c:1841:37: error: ‘qca_soc_data_wcn3991’
      defined but not used [-Werror=unused-const-variable=]
      drivers/bluetooth/hci_qca.c:1830:37: error: ‘qca_soc_data_wcn3990’
      defined but not used [-Werror=unused-const-variable=]
    
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: cda0d6a198e2 ("Bluetooth: qca: fix info leak when fetching fw build id")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: L2CAP: Fix rejecting L2CAP_CONN_PARAM_UPDATE_REQ [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon May 20 16:03:07 2024 -0400

    Bluetooth: L2CAP: Fix rejecting L2CAP_CONN_PARAM_UPDATE_REQ
    
    [ Upstream commit 806a5198c05987b748b50f3d0c0cfb3d417381a4 ]
    
    This removes the bogus check for max > hcon->le_conn_max_interval since
    the later is just the initial maximum conn interval not the maximum the
    stack could support which is really 3200=4000ms.
    
    In order to pass GAP/CONN/CPUP/BV-05-C one shall probably enter values
    of the following fields in IXIT that would cause hci_check_conn_params
    to fail:
    
    TSPX_conn_update_int_min
    TSPX_conn_update_int_max
    TSPX_conn_update_peripheral_latency
    TSPX_conn_update_supervision_timeout
    
    Link: https://github.com/bluez/bluez/issues/847
    Fixes: e4b019515f95 ("Bluetooth: Enforce validation on max value of connection interval")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: qca: add support for QCA2066 [+ + +]
Author: Tim Jiang <quic_tjiang@quicinc.com>
Date:   Tue Sep 12 17:39:57 2023 +0800

    Bluetooth: qca: add support for QCA2066
    
    [ Upstream commit a7f8dedb4be2cc930a29af24427b885405ecd15d ]
    
    This patch adds support for QCA2066 firmware patch and NVM downloading.
    as the RF performance of QCA2066 SOC chip from different foundries may
    vary. Therefore we use different NVM to configure them based on board ID.
    
    Changes in v2
     - optimize the function qca_generate_hsp_nvm_name
     - remove redundant debug code for function qca_read_fw_board_id
    
    Signed-off-by: Tim Jiang <quic_tjiang@quicinc.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: cda0d6a198e2 ("Bluetooth: qca: fix info leak when fetching fw build id")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

Bluetooth: qca: fix info leak when fetching board id [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed May 1 14:34:53 2024 +0200

    Bluetooth: qca: fix info leak when fetching board id
    
    commit 0adcf6be1445ed50bfd4a451a7a782568f270197 upstream.
    
    Add the missing sanity check when fetching the board id to avoid leaking
    slab data when later requesting the firmware.
    
    Fixes: a7f8dedb4be2 ("Bluetooth: qca: add support for QCA2066")
    Cc: stable@vger.kernel.org      # 6.7
    Cc: Tim Jiang <quic_tjiang@quicinc.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: qca: fix info leak when fetching fw build id [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed May 1 14:34:52 2024 +0200

    Bluetooth: qca: fix info leak when fetching fw build id
    
    [ Upstream commit cda0d6a198e2a7ec6f176c36173a57bdd8af7af2 ]
    
    Add the missing sanity checks and move the 255-byte build-id buffer off
    the stack to avoid leaking stack data through debugfs in case the
    build-info reply is malformed.
    
    Fixes: c0187b0bd3e9 ("Bluetooth: btqca: Add support to read FW build version for WCN3991 BTSoC")
    Cc: stable@vger.kernel.org      # 5.12
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: qca: use switch case for soc type behavior [+ + +]
Author: Neil Armstrong <neil.armstrong@linaro.org>
Date:   Wed Aug 16 10:06:47 2023 +0200

    Bluetooth: qca: use switch case for soc type behavior
    
    [ Upstream commit 691d54d0f7cb14baac1ff4af210d13c0e4897e27 ]
    
    Use switch/case to handle soc type specific behaviour,
    the permit dropping the qca_is_xxx() inline functions
    and make the code clearer and easier to update for new
    SoCs.
    
    Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Suggested-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: cda0d6a198e2 ("Bluetooth: qca: fix info leak when fetching fw build id")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bnxt_en: Restore PTP tx_avail count in case of skb_pad() error [+ + +]
Author: Pavan Chebbi <pavan.chebbi@broadcom.com>
Date:   Tue Jun 18 14:53:13 2024 -0700

    bnxt_en: Restore PTP tx_avail count in case of skb_pad() error
    
    [ Upstream commit 1e7962114c10957fe4d10a15eb714578a394e90b ]
    
    The current code only restores PTP tx_avail count when we get DMA
    mapping errors.  Fix it so that the PTP tx_avail count will be
    restored for both DMA mapping errors and skb_pad() errors.
    Otherwise PTP TX timestamp will not be available after a PTP
    packet hits the skb_pad() error.
    
    Fixes: 83bb623c968e ("bnxt_en: Transmit and retrieve packet timestamps")
    Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com>
    Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240618215313.29631-4-michael.chan@broadcom.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Add a check for struct bpf_fib_lookup size [+ + +]
Author: Anton Protopopov <aspsk@isovalent.com>
Date:   Tue Mar 26 10:17:42 2024 +0000

    bpf: Add a check for struct bpf_fib_lookup size
    
    [ Upstream commit 59b418c7063d30e0a3e1f592d47df096db83185c ]
    
    The struct bpf_fib_lookup should not grow outside of its 64 bytes.
    Add a static assert to validate this.
    
    Suggested-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Anton Protopopov <aspsk@isovalent.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240326101742.17421-4-aspsk@isovalent.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Set run context for rawtp test_run callback [+ + +]
Author: Jiri Olsa <jolsa@kernel.org>
Date:   Tue Jun 4 17:00:24 2024 +0200

    bpf: Set run context for rawtp test_run callback
    
    [ Upstream commit d0d1df8ba18abc57f28fb3bc053b2bf319367f2c ]
    
    syzbot reported crash when rawtp program executed through the
    test_run interface calls bpf_get_attach_cookie helper or any
    other helper that touches task->bpf_ctx pointer.
    
    Setting the run context (task->bpf_ctx pointer) for test_run
    callback.
    
    Fixes: 7adfc6c9b315 ("bpf: Add bpf_get_attach_cookie() BPF helper to access bpf_cookie value")
    Reported-by: syzbot+3ab78ff125b7979e45f9@syzkaller.appspotmail.com
    Signed-off-by: Jiri Olsa <jolsa@kernel.org>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Closes: https://syzkaller.appspot.com/bug?extid=3ab78ff125b7979e45f9
    Link: https://lore.kernel.org/bpf/20240604150024.359247-1-jolsa@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro() [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Fri Mar 8 06:38:07 2024 +0100

    bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()
    
    [ Upstream commit 7d2cc63eca0c993c99d18893214abf8f85d566d8 ]
    
    set_memory_ro() can fail, leaving memory unprotected.
    
    Check its return and take it into account as an error.
    
    Link: https://github.com/KSPP/linux/issues/7
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Cc: linux-hardening@vger.kernel.org <linux-hardening@vger.kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Message-ID: <286def78955e04382b227cb3e4b6ba272a7442e3.1709850515.git.christophe.leroy@csgroup.eu>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: fix leak of qgroup extent records after transaction abort [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Jun 3 12:49:08 2024 +0100

    btrfs: fix leak of qgroup extent records after transaction abort
    
    [ Upstream commit fb33eb2ef0d88e75564983ef057b44c5b7e4fded ]
    
    Qgroup extent records are created when delayed ref heads are created and
    then released after accounting extents at btrfs_qgroup_account_extents(),
    called during the transaction commit path.
    
    If a transaction is aborted we free the qgroup records by calling
    btrfs_qgroup_destroy_extent_records() at btrfs_destroy_delayed_refs(),
    unless we don't have delayed references. We are incorrectly assuming
    that no delayed references means we don't have qgroup extents records.
    
    We can currently have no delayed references because we ran them all
    during a transaction commit and the transaction was aborted after that
    due to some error in the commit path.
    
    So fix this by ensuring we btrfs_qgroup_destroy_extent_records() at
    btrfs_destroy_delayed_refs() even if we don't have any delayed references.
    
    Reported-by: syzbot+0fecc032fa134afd49df@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/linux-btrfs/0000000000004e7f980619f91835@google.com/
    Fixes: 81f7eb00ff5b ("btrfs: destroy qgroup extent records on transaction abort")
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: retry block group reclaim without infinite loop [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Fri Jun 7 12:50:14 2024 -0700

    btrfs: retry block group reclaim without infinite loop
    
    commit 4eb4e85c4f818491efc67e9373aa16b123c3f522 upstream.
    
    If inc_block_group_ro systematically fails (e.g. due to ETXTBUSY from
    swap) or btrfs_relocate_chunk systematically fails (from lack of
    space), then this worker becomes an infinite loop.
    
    At the very least, this strands the cleaner thread, but can also result
    in hung tasks/RCU stalls on PREEMPT_NONE kernels and if the
    reclaim_bgs_lock mutex is not contended.
    
    I believe the best long term fix is to manage reclaim via work queue,
    where we queue up a relocation on the triggering condition and re-queue
    on failure. In the meantime, this is an easy fix to apply to avoid the
    immediate pain.
    
    Fixes: 7e2718099438 ("btrfs: reinsert BGs failed to reclaim")
    CC: stable@vger.kernel.org # 6.6+
    Signed-off-by: Boris Burkov <boris@bur.io>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cifs: fix typo in module parameter enable_gcm_256 [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Wed Jun 19 14:46:48 2024 -0500

    cifs: fix typo in module parameter enable_gcm_256
    
    [ Upstream commit 8bf0287528da1992c5e49d757b99ad6bbc34b522 ]
    
    enable_gcm_256 (which allows the server to require the strongest
    encryption) is enabled by default, but the modinfo description
    incorrectly showed it disabled by default. Fix the typo.
    
    Cc: stable@vger.kernel.org
    Fixes: fee742b50289 ("smb3.1.1: enable negotiating stronger encryption by default")
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cipso: fix total option length computation [+ + +]
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Fri Jun 7 18:07:52 2024 +0200

    cipso: fix total option length computation
    
    [ Upstream commit 9f36169912331fa035d7b73a91252d7c2512eb1a ]
    
    As evident from the definition of ip_options_get(), the IP option
    IPOPT_END is used to pad the IP option data array, not IPOPT_NOP. Yet
    the loop that walks the IP options to determine the total IP options
    length in cipso_v4_delopt() doesn't take IPOPT_END into account.
    
    Fix it by recognizing the IPOPT_END value as the end of actual options.
    
    Fixes: 014ab19a69c3 ("selinux: Set socket NetLabel based on connection endpoint")
    Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: sifive: Do not register clkdevs for PRCI clocks [+ + +]
Author: Samuel Holland <samuel.holland@sifive.com>
Date:   Mon May 27 17:14:12 2024 -0700

    clk: sifive: Do not register clkdevs for PRCI clocks
    
    [ Upstream commit 2607133196c35f31892ee199ce7ffa717bea4ad1 ]
    
    These clkdevs were unnecessary, because systems using this driver always
    look up clocks using the devicetree. And as Russell King points out[1],
    since the provided device name was truncated, lookups via clkdev would
    never match.
    
    Recently, commit 8d532528ff6a ("clkdev: report over-sized strings when
    creating clkdev entries") caused clkdev registration to fail due to the
    truncation, and this now prevents the driver from probing. Fix the
    driver by removing the clkdev registration.
    
    Link: https://lore.kernel.org/linux-clk/ZkfYqj+OcAxd9O2t@shell.armlinux.org.uk/ [1]
    Fixes: 30b8e27e3b58 ("clk: sifive: add a driver for the SiFive FU540 PRCI IP block")
    Fixes: 8d532528ff6a ("clkdev: report over-sized strings when creating clkdev entries")
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Closes: https://lore.kernel.org/linux-clk/7eda7621-0dde-4153-89e4-172e4c095d01@roeck-us.net/
    Suggested-by: Russell King <linux@armlinux.org.uk>
    Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
    Link: https://lore.kernel.org/r/20240528001432.1200403-1-samuel.holland@sifive.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cma: factor out minimum alignment requirement [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Tue Mar 22 14:43:17 2022 -0700

    cma: factor out minimum alignment requirement
    
    [ Upstream commit e16faf26780fc0c8dd693ea9ee8420a7706cb2f5 ]
    
    Patch series "mm: enforce pageblock_order < MAX_ORDER".
    
    Having pageblock_order >= MAX_ORDER seems to be able to happen in corner
    cases and some parts of the kernel are not prepared for it.
    
    For example, Aneesh has shown [1] that such kernels can be compiled on
    ppc64 with 64k base pages by setting FORCE_MAX_ZONEORDER=8, which will
    run into a WARN_ON_ONCE(order >= MAX_ORDER) in comapction code right
    during boot.
    
    We can get pageblock_order >= MAX_ORDER when the default hugetlb size is
    bigger than the maximum allocation granularity of the buddy, in which
    case we are no longer talking about huge pages but instead gigantic
    pages.
    
    Having pageblock_order >= MAX_ORDER can only make alloc_contig_range()
    of such gigantic pages more likely to succeed.
    
    Reliable use of gigantic pages either requires boot time allcoation or
    CMA, no need to overcomplicate some places in the kernel to optimize for
    corner cases that are broken in other areas of the kernel.
    
    This patch (of 2):
    
    Let's enforce pageblock_order < MAX_ORDER and simplify.
    
    Especially patch #1 can be regarded a cleanup before:
            [PATCH v5 0/6] Use pageblock_order for cma and alloc_contig_range
            alignment. [2]
    
    [1] https://lkml.kernel.org/r/87r189a2ks.fsf@linux.ibm.com
    [2] https://lkml.kernel.org/r/20220211164135.1803616-1-zi.yan@sent.com
    
    Link: https://lkml.kernel.org/r/20220214174132.219303-2-david@redhat.com
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Zi Yan <ziy@nvidia.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Frank Rowand <frowand.list@gmail.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Marek Szyprowski <m.szyprowski@samsung.com>
    Cc: Robin Murphy <robin.murphy@arm.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: John Garry via iommu <iommu@lists.linux-foundation.org>
    
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Stable-dep-of: b174f139bdc8 ("mm/cma: drop incorrect alignment check in cma_init_reserved_mem")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpu/hotplug: Fix dynstate assignment in __cpuhp_setup_state_cpuslocked() [+ + +]
Author: Yuntao Wang <ytcoode@gmail.com>
Date:   Wed May 15 21:45:54 2024 +0800

    cpu/hotplug: Fix dynstate assignment in __cpuhp_setup_state_cpuslocked()
    
    commit 932d8476399f622aa0767a4a0a9e78e5341dc0e1 upstream.
    
    Commit 4205e4786d0b ("cpu/hotplug: Provide dynamic range for prepare
    stage") added a dynamic range for the prepare states, but did not handle
    the assignment of the dynstate variable in __cpuhp_setup_state_cpuslocked().
    
    This causes the corresponding startup callback not to be invoked when
    calling __cpuhp_setup_state_cpuslocked() with the CPUHP_BP_PREPARE_DYN
    parameter, even though it should be.
    
    Currently, the users of __cpuhp_setup_state_cpuslocked(), for one reason or
    another, have not triggered this bug.
    
    Fixes: 4205e4786d0b ("cpu/hotplug: Provide dynamic range for prepare stage")
    Signed-off-by: Yuntao Wang <ytcoode@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240515134554.427071-1-ytcoode@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
crypto: ecdh - explicitly zeroize private_key [+ + +]
Author: Joachim Vandersmissen <git@jvdsn.com>
Date:   Thu Mar 28 11:24:30 2024 -0500

    crypto: ecdh - explicitly zeroize private_key
    
    [ Upstream commit 73e5984e540a76a2ee1868b91590c922da8c24c9 ]
    
    private_key is overwritten with the key parameter passed in by the
    caller (if present), or alternatively a newly generated private key.
    However, it is possible that the caller provides a key (or the newly
    generated key) which is shorter than the previous key. In that
    scenario, some key material from the previous key would not be
    overwritten. The easiest solution is to explicitly zeroize the entire
    private_key array first.
    
    Note that this patch slightly changes the behavior of this function:
    previously, if the ecc_gen_privkey failed, the old private_key would
    remain. Now, the private_key is always zeroized. This behavior is
    consistent with the case where params.key is set and ecc_is_key_valid
    fails.
    
    Signed-off-by: Joachim Vandersmissen <git@jvdsn.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: hisilicon/sec - Fix memory leak for sec resource release [+ + +]
Author: Chenghai Huang <huangchenghai2@huawei.com>
Date:   Sun Apr 7 15:59:58 2024 +0800

    crypto: hisilicon/sec - Fix memory leak for sec resource release
    
    [ Upstream commit bba4250757b4ae1680fea435a358d8093f254094 ]
    
    The AIV is one of the SEC resources. When releasing resources,
    it need to release the AIV resources at the same time.
    Otherwise, memory leakage occurs.
    
    The aiv resource release is added to the sec resource release
    function.
    
    Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
csky, hexagon: fix broken sys_sync_file_range [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jun 14 09:54:20 2024 +0200

    csky, hexagon: fix broken sys_sync_file_range
    
    commit 3339b99ef6fe38dac43b534cba3a8a0e29fb2eff upstream.
    
    Both of these architectures require u64 function arguments to be
    passed in even/odd pairs of registers or stack slots, which in case of
    sync_file_range would result in a seven-argument system call that is
    not currently possible. The system call is therefore incompatible with
    all existing binaries.
    
    While it would be possible to implement support for seven arguments
    like on mips, it seems better to use a six-argument version, either
    with the normal argument order but misaligned as on most architectures
    or with the reordered sync_file_range2() calling conventions as on
    arm and powerpc.
    
    Cc: stable@vger.kernel.org
    Acked-by: Guo Ren <guoren@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dmaengine: axi-dmac: fix possible race in remove() [+ + +]
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Thu Mar 28 14:58:50 2024 +0100

    dmaengine: axi-dmac: fix possible race in remove()
    
    commit 1bc31444209c8efae98cb78818131950d9a6f4d6 upstream.
    
    We need to first free the IRQ before calling of_dma_controller_free().
    Otherwise we could get an interrupt and schedule a tasklet while
    removing the DMA controller.
    
    Fixes: 0e3b67b348b8 ("dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller")
    Cc: stable@kernel.org
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240328-axi-dmac-devm-probe-v3-1-523c0176df70@analog.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list [+ + +]
Author: Li RongQing <lirongqing@baidu.com>
Date:   Mon Jun 3 09:24:44 2024 +0800

    dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
    
    [ Upstream commit e3215deca4520773cd2b155bed164c12365149a7 ]
    
    Use list_for_each_entry_safe() to allow iterating through the list and
    deleting the entry in the iteration process. The descriptor is freed via
    idxd_desc_complete() and there's a slight chance may cause issue for
    the list iterator when the descriptor is reused by another thread
    without it being deleted from the list.
    
    Fixes: 16e19e11228b ("dmaengine: idxd: Fix list corruption in description completion")
    Signed-off-by: Li RongQing <lirongqing@baidu.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Reviewed-by: Fenghua Yu <fenghua.yu@intel.com>
    Link: https://lore.kernel.org/r/20240603012444.11902-1-lirongqing@baidu.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ioat: Drop redundant pci_enable_pcie_error_reporting() [+ + +]
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Mar 7 13:26:54 2023 -0600

    dmaengine: ioat: Drop redundant pci_enable_pcie_error_reporting()
    
    [ Upstream commit e32622f84ae289dc7a04e9f01cd62cb914fdc5c6 ]
    
    pci_enable_pcie_error_reporting() enables the device to send ERR_*
    Messages.  Since f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is
    native"), the PCI core does this for all devices during enumeration, so the
    driver doesn't need to do it itself.
    
    Remove the redundant pci_enable_pcie_error_reporting() call from the
    driver.  Also remove the corresponding pci_disable_pcie_error_reporting()
    from the driver .remove() path.
    
    Note that this only controls ERR_* Messages from the device.  An ERR_*
    Message may cause the Root Port to generate an interrupt, depending on the
    AER Root Error Command register managed by the AER service driver.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20230307192655.874008-2-helgaas@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Stable-dep-of: 1b11b4ef6bd6 ("dmaengine: ioatdma: Fix leaking on version mismatch")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ioat: switch from 'pci_' to 'dma_' API [+ + +]
Author: Qing Wang <wangqing@vivo.com>
Date:   Thu Oct 7 20:28:28 2021 -0700

    dmaengine: ioat: switch from 'pci_' to 'dma_' API
    
    [ Upstream commit 0c5afef7bf1fbda7e7883dc4b93f64f90003706f ]
    
    The wrappers in include/linux/pci-dma-compat.h should go away.
    
    pci_set_dma_mask()/pci_set_consistent_dma_mask() should be
    replaced with dma_set_mask()/dma_set_coherent_mask(),
    and use dma_set_mask_and_coherent() for both.
    
    Signed-off-by: Qing Wang <wangqing@vivo.com>
    Link: https://lore.kernel.org/r/1633663733-47199-3-git-send-email-wangqing@vivo.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Stable-dep-of: 1b11b4ef6bd6 ("dmaengine: ioatdma: Fix leaking on version mismatch")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ioat: use PCI core macros for PCIe Capability [+ + +]
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Mar 7 15:46:15 2023 -0600

    dmaengine: ioat: use PCI core macros for PCIe Capability
    
    [ Upstream commit 8f6707d0773be31972768abd6e0bf7b8515b5b1a ]
    
    The PCIe Capability is defined by the PCIe spec, so use the PCI_EXP_DEVCTL
    macros defined by the PCI core instead of defining copies in IOAT.  This
    makes it easier to find all uses of the PCIe Device Control register.  No
    functional change intended.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20230307214615.887354-1-helgaas@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Stable-dep-of: f0dc9fda2e0e ("dmaengine: ioatdma: Fix error path in ioat3_dma_probe()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ioatdma: Fix error path in ioat3_dma_probe() [+ + +]
Author: Nikita Shubin <n.shubin@yadro.com>
Date:   Tue May 28 09:09:24 2024 +0300

    dmaengine: ioatdma: Fix error path in ioat3_dma_probe()
    
    [ Upstream commit f0dc9fda2e0ee9e01496c2f5aca3a831131fad79 ]
    
    Make sure we are disabling interrupts and destroying DMA pool if
    pcie_capability_read/write_word() call failed.
    
    Fixes: 511deae0261c ("dmaengine: ioatdma: disable relaxed ordering for ioatdma")
    Signed-off-by: Nikita Shubin <n.shubin@yadro.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20240528-ioatdma-fixes-v2-2-a9f2fbe26ab1@yadro.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ioatdma: Fix kmemleak in ioat_pci_probe() [+ + +]
Author: Nikita Shubin <n.shubin@yadro.com>
Date:   Tue May 28 09:09:25 2024 +0300

    dmaengine: ioatdma: Fix kmemleak in ioat_pci_probe()
    
    [ Upstream commit 29b7cd255f3628e0d65be33a939d8b5bba10aa62 ]
    
    If probing fails we end up with leaking ioatdma_device and each
    allocated channel.
    
    Following kmemleak easy to reproduce by injecting an error in
    ioat_alloc_chan_resources() when doing ioat_dma_self_test().
    
    unreferenced object 0xffff888014ad5800 (size 1024): [..]
        [<ffffffff827692ca>] kmemleak_alloc+0x4a/0x80
        [<ffffffff81430600>] kmalloc_trace+0x270/0x2f0
        [<ffffffffa000b7d1>] ioat_pci_probe+0xc1/0x1c0 [ioatdma]
    [..]
    
    repeated for each ioatdma channel:
    
    unreferenced object 0xffff8880148e5c00 (size 512): [..]
        [<ffffffff827692ca>] kmemleak_alloc+0x4a/0x80
        [<ffffffff81430600>] kmalloc_trace+0x270/0x2f0
        [<ffffffffa0009641>] ioat_enumerate_channels+0x101/0x2d0 [ioatdma]
        [<ffffffffa000b266>] ioat3_dma_probe+0x4d6/0x970 [ioatdma]
        [<ffffffffa000b891>] ioat_pci_probe+0x181/0x1c0 [ioatdma]
    [..]
    
    Fixes: bf453a0a18b2 ("dmaengine: ioat: Support in-use unbind")
    Signed-off-by: Nikita Shubin <n.shubin@yadro.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20240528-ioatdma-fixes-v2-3-a9f2fbe26ab1@yadro.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ioatdma: Fix leaking on version mismatch [+ + +]
Author: Nikita Shubin <n.shubin@yadro.com>
Date:   Tue May 28 09:09:23 2024 +0300

    dmaengine: ioatdma: Fix leaking on version mismatch
    
    [ Upstream commit 1b11b4ef6bd68591dcaf8423c7d05e794e6aec6f ]
    
    Fix leaking ioatdma_device if I/OAT version is less than IOAT_VER_3_0.
    
    Fixes: bf453a0a18b2 ("dmaengine: ioat: Support in-use unbind")
    Signed-off-by: Nikita Shubin <n.shubin@yadro.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20240528-ioatdma-fixes-v2-1-a9f2fbe26ab1@yadro.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ioatdma: Fix missing kmem_cache_destroy() [+ + +]
Author: Nikita Shubin <n.shubin@yadro.com>
Date:   Tue May 14 13:52:31 2024 +0300

    dmaengine: ioatdma: Fix missing kmem_cache_destroy()
    
    [ Upstream commit 5422145d0b749ad554ada772133b9b20f9fb0ec8 ]
    
    Fix missing kmem_cache_destroy() for ioat_sed_cache in
    ioat_exit_module().
    
    Noticed via:
    
    ```
    modprobe ioatdma
    rmmod ioatdma
    modprobe ioatdma
    debugfs: Directory 'ioat_sed_ent' with parent 'slab' already present!
    ```
    
    Fixes: c0f28ce66ecf ("dmaengine: ioatdma: move all the init routines")
    Signed-off-by: Nikita Shubin <n.shubin@yadro.com>
    Acked-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20240514-ioatdma_fixes-v1-1-2776a0913254@yadro.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers: core: synchronize really_probe() and dev_uevent() [+ + +]
Author: Dirk Behme <dirk.behme@de.bosch.com>
Date:   Mon May 13 07:06:34 2024 +0200

    drivers: core: synchronize really_probe() and dev_uevent()
    
    commit c0a40097f0bc81deafc15f9195d1fb54595cd6d0 upstream.
    
    Synchronize the dev->driver usage in really_probe() and dev_uevent().
    These can run in different threads, what can result in the following
    race condition for dev->driver uninitialization:
    
    Thread #1:
    ==========
    
    really_probe() {
    ...
    probe_failed:
    ...
    device_unbind_cleanup(dev) {
        ...
        dev->driver = NULL;   // <= Failed probe sets dev->driver to NULL
        ...
        }
    ...
    }
    
    Thread #2:
    ==========
    
    dev_uevent() {
    ...
    if (dev->driver)
          // If dev->driver is NULLed from really_probe() from here on,
          // after above check, the system crashes
          add_uevent_var(env, "DRIVER=%s", dev->driver->name);
    ...
    }
    
    really_probe() holds the lock, already. So nothing needs to be done
    there. dev_uevent() is called with lock held, often, too. But not
    always. What implies that we can't add any locking in dev_uevent()
    itself. So fix this race by adding the lock to the non-protected
    path. This is the path where above race is observed:
    
     dev_uevent+0x235/0x380
     uevent_show+0x10c/0x1f0  <= Add lock here
     dev_attr_show+0x3a/0xa0
     sysfs_kf_seq_show+0x17c/0x250
     kernfs_seq_show+0x7c/0x90
     seq_read_iter+0x2d7/0x940
     kernfs_fop_read_iter+0xc6/0x310
     vfs_read+0x5bc/0x6b0
     ksys_read+0xeb/0x1b0
     __x64_sys_read+0x42/0x50
     x64_sys_call+0x27ad/0x2d30
     do_syscall_64+0xcd/0x1d0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Similar cases are reported by syzkaller in
    
    https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a
    
    But these are regarding the *initialization* of dev->driver
    
    dev->driver = drv;
    
    As this switches dev->driver to non-NULL these reports can be considered
    to be false-positives (which should be "fixed" by this commit, as well,
    though).
    
    The same issue was reported and tried to be fixed back in 2015 in
    
    https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/
    
    already.
    
    Fixes: 239378f16aa1 ("Driver core: add uevent vars for devices of a class")
    Cc: stable <stable@kernel.org>
    Cc: syzbot+ffa8143439596313a85a@syzkaller.appspotmail.com
    Cc: Ashish Sangwan <a.sangwan@samsung.com>
    Cc: Namjae Jeon <namjae.jeon@samsung.com>
    Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
    Link: https://lore.kernel.org/r/20240513050634.3964461-1-dirk.behme@de.bosch.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drivers: fix typo in firmware/efi/memmap.c [+ + +]
Author: Zheng Zhi Yuan <kevinjone25@g.ncu.edu.tw>
Date:   Sat Jun 29 17:12:32 2024 +0200

    drivers: fix typo in firmware/efi/memmap.c
    
    [ Commit 1df4d1724baafa55e9803414ebcdf1ca702bc958 upstream ]
    
    This patch fixes the spelling error in firmware/efi/memmap.c, changing
    it to the correct word.
    
    Signed-off-by: Zheng Zhi Yuan <kevinjone25@g.ncu.edu.tw>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Clean up some inconsistent indenting [+ + +]
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date:   Tue Jul 26 15:25:55 2022 +0800

    drm/amd/display: Clean up some inconsistent indenting
    
    [ Upstream commit 1da2fcc435114ea5a65d7e15fc31b4d0ce11113c ]
    
    Eliminate the follow smatch warning:
    
    drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_srv.c:622
    dmub_srv_cmd_execute() warn: inconsistent indenting.
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 892b41b16f61 ("drm/amd/display: Fix incorrect DSC instance for MST")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: drop unnecessary NULL checks in debugfs [+ + +]
Author: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
Date:   Tue Dec 27 20:04:15 2022 +0300

    drm/amd/display: drop unnecessary NULL checks in debugfs
    
    [ Upstream commit f8e12e770e8049917f82387033b3cf44bc43b915 ]
    
    pipe_ctx pointer cannot be NULL when getting the address of
    an element of the pipe_ctx array. Moreover, the MAX_PIPES is
    defined as 6, so pipe_ctx is not NULL after the loop either.
    
    Detected using the static analysis tool - Svace.
    
    Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Stable-dep-of: 892b41b16f61 ("drm/amd/display: Fix incorrect DSC instance for MST")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Exit idle optimizations before HDCP execution [+ + +]
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date:   Mon Feb 12 16:51:59 2024 -0500

    drm/amd/display: Exit idle optimizations before HDCP execution
    
    [ Upstream commit f30a3bea92bdab398531129d187629fb1d28f598 ]
    
    [WHY]
    PSP can access DCN registers during command submission and we need
    to ensure that DCN is not in PG before doing so.
    
    [HOW]
    Add a callback to DM to lock and notify DC for idle optimization exit.
    It can't be DC directly because of a potential race condition with the
    link protection thread and the rest of DM operation.
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Charlene Liu <charlene.liu@amd.com>
    Acked-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix incorrect DSC instance for MST [+ + +]
Author: Hersen Wu <hersenxs.wu@amd.com>
Date:   Tue Feb 13 14:26:06 2024 -0500

    drm/amd/display: Fix incorrect DSC instance for MST
    
    [ Upstream commit 892b41b16f6163e6556545835abba668fcab4eea ]
    
    [Why] DSC debugfs, such as dp_dsc_clock_en_read,
    use aconnector->dc_link to find pipe_ctx for display.
    Displays connected to MST hub share the same dc_link.
    DSC instance is from pipe_ctx. This causes incorrect
    DSC instance for display connected to MST hub.
    
    [How] Add aconnector->sink check to find pipe_ctx.
    
    CC: stable@vger.kernel.org
    Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
    Signed-off-by: Hersen Wu <hersenxs.wu@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Handle Y carry-over in VCP X.Y calculation [+ + +]
Author: George Shen <george.shen@amd.com>
Date:   Thu Sep 16 19:55:39 2021 -0400

    drm/amd/display: Handle Y carry-over in VCP X.Y calculation
    
    [ Upstream commit 3626a6aebe62ce7067cdc460c0c644e9445386bb ]
    
    [Why/How]
    Theoretically rare corner case where ceil(Y) results in rounding
    up to an integer. If this happens, the 1 should be carried over to
    the X value.
    
    Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
    Acked-by: Anson Jacob <Anson.Jacob@amd.com>
    Signed-off-by: George Shen <george.shen@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: revert Exit idle optimizations before HDCP execution [+ + +]
Author: Martin Leung <martin.leung@amd.com>
Date:   Mon Feb 26 13:20:08 2024 -0500

    drm/amd/display: revert Exit idle optimizations before HDCP execution
    
    commit f2703a3596a279b0be6eeed4c500bdbaa8dc3ce4 upstream.
    
    why and how:
    causes black screen on PNP on DCN 3.5
    
    This reverts commit f30a3bea92bd ("drm/amd/display: Exit idle
    optimizations before HDCP execution")
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Martin Leung <martin.leung@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: avoid using null object of framebuffer [+ + +]
Author: Julia Zhang <julia.zhang@amd.com>
Date:   Mon Jun 3 19:31:09 2024 +0800

    drm/amdgpu: avoid using null object of framebuffer
    
    commit bcfa48ff785bd121316592b131ff6531e3e696bb upstream.
    
    Instead of using state->fb->obj[0] directly, get object from framebuffer
    by calling drm_gem_fb_get_obj() and return error code when object is
    null to avoid using null object of framebuffer.
    
    Reported-by: Fusheng Huang <fusheng.huang@ecarxgroup.com>
    Signed-off-by: Julia Zhang <Julia.Zhang@amd.com>
    Reviewed-by: Huang Rui <ray.huang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: fix UBSAN warning in kv_dpm.c [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon May 20 09:05:21 2024 -0400

    drm/amdgpu: fix UBSAN warning in kv_dpm.c
    
    [ Upstream commit f0d576f840153392d04b2d52cf3adab8f62e8cb6 ]
    
    Adds bounds check for sumo_vid_mapping_entry.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3392
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/bridge/panel: Fix runtime warning on panel bridge release [+ + +]
Author: Adam Miotk <adam.miotk@arm.com>
Date:   Mon Jun 10 11:27:39 2024 +0100

    drm/bridge/panel: Fix runtime warning on panel bridge release
    
    [ Upstream commit ce62600c4dbee8d43b02277669dd91785a9b81d9 ]
    
    Device managed panel bridge wrappers are created by calling to
    drm_panel_bridge_add_typed() and registering a release handler for
    clean-up when the device gets unbound.
    
    Since the memory for this bridge is also managed and linked to the panel
    device, the release function should not try to free that memory.
    Moreover, the call to devm_kfree() inside drm_panel_bridge_remove() will
    fail in this case and emit a warning because the panel bridge resource
    is no longer on the device resources list (it has been removed from
    there before the call to release handlers).
    
    Fixes: 67022227ffb1 ("drm/bridge: Add a devm_ allocator for panel bridge.")
    Signed-off-by: Adam Miotk <adam.miotk@arm.com>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240610102739.139852-1-adam.miotk@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/exynos/vidi: fix memory leak in .get_modes() [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu May 30 13:01:51 2024 +0300

    drm/exynos/vidi: fix memory leak in .get_modes()
    
    commit 38e3825631b1f314b21e3ade00b5a4d737eb054e upstream.
    
    The duplicated EDID is never freed. Fix it.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found [+ + +]
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Thu Apr 25 11:48:51 2024 +0200

    drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found
    
    commit 799d4b392417ed6889030a5b2335ccb6dcf030ab upstream.
    
    When reading EDID fails and driver reports no modes available, the DRM
    core adds an artificial 1024x786 mode to the connector. Unfortunately
    some variants of the Exynos HDMI (like the one in Exynos4 SoCs) are not
    able to drive such mode, so report a safe 640x480 mode instead of nothing
    in case of the EDID reading failure.
    
    This fixes the following issue observed on Trats2 board since commit
    13d5b040363c ("drm/exynos: do not return negative values from .get_modes()"):
    
    [drm] Exynos DRM: using 11c00000.fimd device for DMA mapping operations
    exynos-drm exynos-drm: bound 11c00000.fimd (ops fimd_component_ops)
    exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops)
    exynos-dsi 11c80000.dsi: [drm:samsung_dsim_host_attach] Attached s6e8aa0 device (lanes:4 bpp:24 mode-flags:0x10b)
    exynos-drm exynos-drm: bound 11c80000.dsi (ops exynos_dsi_component_ops)
    exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops)
    [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1
    exynos-hdmi 12d00000.hdmi: [drm:hdmiphy_enable.part.0] *ERROR* PLL could not reach steady state
    panel-samsung-s6e8aa0 11c80000.dsi.0: ID: 0xa2, 0x20, 0x8c
    exynos-mixer 12c10000.mixer: timeout waiting for VSYNC
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 11 at drivers/gpu/drm/drm_atomic_helper.c:1682 drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8
    [CRTC:70:crtc-1] vblank wait timed out
    Modules linked in:
    CPU: 1 PID: 11 Comm: kworker/u16:0 Not tainted 6.9.0-rc5-next-20240424 #14913
    Hardware name: Samsung Exynos (Flattened Device Tree)
    Workqueue: events_unbound deferred_probe_work_func
    Call trace:
     unwind_backtrace from show_stack+0x10/0x14
     show_stack from dump_stack_lvl+0x68/0x88
     dump_stack_lvl from __warn+0x7c/0x1c4
     __warn from warn_slowpath_fmt+0x11c/0x1a8
     warn_slowpath_fmt from drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8
     drm_atomic_helper_wait_for_vblanks.part.0 from drm_atomic_helper_commit_tail_rpm+0x7c/0x8c
     drm_atomic_helper_commit_tail_rpm from commit_tail+0x9c/0x184
     commit_tail from drm_atomic_helper_commit+0x168/0x190
     drm_atomic_helper_commit from drm_atomic_commit+0xb4/0xe0
     drm_atomic_commit from drm_client_modeset_commit_atomic+0x23c/0x27c
     drm_client_modeset_commit_atomic from drm_client_modeset_commit_locked+0x60/0x1cc
     drm_client_modeset_commit_locked from drm_client_modeset_commit+0x24/0x40
     drm_client_modeset_commit from __drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc4
     __drm_fb_helper_restore_fbdev_mode_unlocked from drm_fb_helper_set_par+0x2c/0x3c
     drm_fb_helper_set_par from fbcon_init+0x3d8/0x550
     fbcon_init from visual_init+0xc0/0x108
     visual_init from do_bind_con_driver+0x1b8/0x3a4
     do_bind_con_driver from do_take_over_console+0x140/0x1ec
     do_take_over_console from do_fbcon_takeover+0x70/0xd0
     do_fbcon_takeover from fbcon_fb_registered+0x19c/0x1ac
     fbcon_fb_registered from register_framebuffer+0x190/0x21c
     register_framebuffer from __drm_fb_helper_initial_config_and_unlock+0x350/0x574
     __drm_fb_helper_initial_config_and_unlock from exynos_drm_fbdev_client_hotplug+0x6c/0xb0
     exynos_drm_fbdev_client_hotplug from drm_client_register+0x58/0x94
     drm_client_register from exynos_drm_bind+0x160/0x190
     exynos_drm_bind from try_to_bring_up_aggregate_device+0x200/0x2d8
     try_to_bring_up_aggregate_device from __component_add+0xb0/0x170
     __component_add from mixer_probe+0x74/0xcc
     mixer_probe from platform_probe+0x5c/0xb8
     platform_probe from really_probe+0xe0/0x3d8
     really_probe from __driver_probe_device+0x9c/0x1e4
     __driver_probe_device from driver_probe_device+0x30/0xc0
     driver_probe_device from __device_attach_driver+0xa8/0x120
     __device_attach_driver from bus_for_each_drv+0x80/0xcc
     bus_for_each_drv from __device_attach+0xac/0x1fc
     __device_attach from bus_probe_device+0x8c/0x90
     bus_probe_device from deferred_probe_work_func+0x98/0xe0
     deferred_probe_work_func from process_one_work+0x240/0x6d0
     process_one_work from worker_thread+0x1a0/0x3f4
     worker_thread from kthread+0x104/0x138
     kthread from ret_from_fork+0x14/0x28
    Exception stack(0xf0895fb0 to 0xf0895ff8)
    ...
    irq event stamp: 82357
    hardirqs last  enabled at (82363): [<c01a96e8>] vprintk_emit+0x308/0x33c
    hardirqs last disabled at (82368): [<c01a969c>] vprintk_emit+0x2bc/0x33c
    softirqs last  enabled at (81614): [<c0101644>] __do_softirq+0x320/0x500
    softirqs last disabled at (81609): [<c012dfe0>] __irq_exit_rcu+0x130/0x184
    ---[ end trace 0000000000000000 ]---
    exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out
    exynos-drm exynos-drm: [drm] *ERROR* [CRTC:70:crtc-1] commit wait timed out
    exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out
    exynos-drm exynos-drm: [drm] *ERROR* [CONNECTOR:74:HDMI-A-1] commit wait timed out
    exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out
    exynos-drm exynos-drm: [drm] *ERROR* [PLANE:56:plane-5] commit wait timed out
    exynos-mixer 12c10000.mixer: timeout waiting for VSYNC
    
    Cc: stable@vger.kernel.org
    Fixes: 13d5b040363c ("drm/exynos: do not return negative values from .get_modes()")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/gt: Disarm breadcrumbs if engines are already idle [+ + +]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 23 18:23:10 2024 +0200

    drm/i915/gt: Disarm breadcrumbs if engines are already idle
    
    [ Upstream commit 70cb9188ffc75e643debf292fcddff36c9dbd4ae ]
    
    The breadcrumbs use a GT wakeref for guarding the interrupt, but are
    disarmed during release of the engine wakeref. This leaves a hole where
    we may attach a breadcrumb just as the engine is parking (after it has
    parked its breadcrumbs), execute the irq worker with some signalers still
    attached, but never be woken again.
    
    That issue manifests itself in CI with IGT runner timeouts while tests
    are waiting indefinitely for release of all GT wakerefs.
    
    <6> [209.151778] i915: Running live_engine_pm_selftests/live_engine_busy_stats
    <7> [209.231628] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_5
    <7> [209.231816] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_4
    <7> [209.231944] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_3
    <7> [209.232056] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_2
    <7> [209.232166] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling DC_off
    <7> [209.232270] i915 0000:00:02.0: [drm:skl_enable_dc6 [i915]] Enabling DC6
    <7> [209.232368] i915 0000:00:02.0: [drm:gen9_set_dc_state.part.0 [i915]] Setting DC state from 00 to 02
    <4> [299.356116] [IGT] Inactivity timeout exceeded. Killing the current test with SIGQUIT.
    ...
    <6> [299.356526] sysrq: Show State
    ...
    <6> [299.373964] task:i915_selftest   state:D stack:11784 pid:5578  tgid:5578  ppid:873    flags:0x00004002
    <6> [299.373967] Call Trace:
    <6> [299.373968]  <TASK>
    <6> [299.373970]  __schedule+0x3bb/0xda0
    <6> [299.373974]  schedule+0x41/0x110
    <6> [299.373976]  intel_wakeref_wait_for_idle+0x82/0x100 [i915]
    <6> [299.374083]  ? __pfx_var_wake_function+0x10/0x10
    <6> [299.374087]  live_engine_busy_stats+0x9b/0x500 [i915]
    <6> [299.374173]  __i915_subtests+0xbe/0x240 [i915]
    <6> [299.374277]  ? __pfx___intel_gt_live_setup+0x10/0x10 [i915]
    <6> [299.374369]  ? __pfx___intel_gt_live_teardown+0x10/0x10 [i915]
    <6> [299.374456]  intel_engine_live_selftests+0x1c/0x30 [i915]
    <6> [299.374547]  __run_selftests+0xbb/0x190 [i915]
    <6> [299.374635]  i915_live_selftests+0x4b/0x90 [i915]
    <6> [299.374717]  i915_pci_probe+0x10d/0x210 [i915]
    
    At the end of the interrupt worker, if there are no more engines awake,
    disarm the breadcrumb and go to sleep.
    
    Fixes: 9d5612ca165a ("drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission")
    Closes: https://gitlab.freedesktop.org/drm/intel/issues/10026
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Andrzej Hajda <andrzej.hajda@intel.com>
    Cc: <stable@vger.kernel.org> # v5.12+
    Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
    Acked-by: Nirmoy Das <nirmoy.das@intel.com>
    Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240423165505.465734-2-janusz.krzysztofik@linux.intel.com
    (cherry picked from commit fbad43eccae5cb14594195c20113369aabaa22b5)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/i915/gt: Fix potential UAF by revoke of fence registers [+ + +]
Author: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Date:   Mon Jun 3 21:54:45 2024 +0200

    drm/i915/gt: Fix potential UAF by revoke of fence registers
    
    commit 996c3412a06578e9d779a16b9e79ace18125ab50 upstream.
    
    CI has been sporadically reporting the following issue triggered by
    igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
    
    <6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
    ...
    <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
    <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
    <3> [414.070354] Unable to pin Y-tiled fence; err:-4
    <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active))
    ...
    <4>[  609.603992] ------------[ cut here ]------------
    <2>[  609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
    <4>[  609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    <4>[  609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G     U  W          6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
    <4>[  609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
    <4>[  609.604010] Workqueue: i915 __i915_gem_free_work [i915]
    <4>[  609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
    ...
    <4>[  609.604271] Call Trace:
    <4>[  609.604273]  <TASK>
    ...
    <4>[  609.604716]  __i915_vma_evict+0x2e9/0x550 [i915]
    <4>[  609.604852]  __i915_vma_unbind+0x7c/0x160 [i915]
    <4>[  609.604977]  force_unbind+0x24/0xa0 [i915]
    <4>[  609.605098]  i915_vma_destroy+0x2f/0xa0 [i915]
    <4>[  609.605210]  __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
    <4>[  609.605330]  __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
    <4>[  609.605440]  process_scheduled_works+0x351/0x690
    ...
    
    In the past, there were similar failures reported by CI from other IGT
    tests, observed on other platforms.
    
    Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity
    before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for
    idleness of vma->active via fence_update().   That commit introduced
    vma->fence->active in order for the fence_update() to be able to wait
    selectively on that one instead of vma->active since only idleness of
    fence registers was needed.  But then, another commit 0d86ee35097a
    ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to
    fence_update() in i915_vma_revoke_fence() with only fence_write(), and
    also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front.
    No justification was provided on why we might then expect idleness of
    vma->fence->active without first waiting on it.
    
    The issue can be potentially caused by a race among revocation of fence
    registers on one side and sequential execution of signal callbacks invoked
    on completion of a request that was using them on the other, still
    processed in parallel to revocation of those fence registers.  Fix it by
    waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
    
    Fixes: 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal")
    Closes: https://gitlab.freedesktop.org/drm/intel/issues/10021
    Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
    Cc: stable@vger.kernel.org # v5.8+
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240603195446.297690-2-janusz.krzysztofik@linux.intel.com
    (cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/i915/gt: Only kick the signal worker if there's been an update [+ + +]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 8 16:20:13 2022 +0200

    drm/i915/gt: Only kick the signal worker if there's been an update
    
    [ Upstream commit c877bed82e1017c102c137d432933ccbba92c119 ]
    
    One impact of commit 047a1b877ed4 ("dma-buf & drm/amdgpu: remove
    dma_resv workaround") is that it stores many, many more fences. Whereas
    adding an exclusive fence used to remove the shared fence list, that
    list is now preserved and the write fences included into the list. Not
    just a single write fence, but now a write/read fence per context. That
    causes us to have to track more fences than before (albeit half of those
    are redundant), and we trigger more interrupts for multi-engine
    workloads.
    
    As part of reducing the impact from handling more signaling, we observe
    we only need to kick the signal worker after adding a fence iff we have
    good cause to believe that there is work to be done in processing the
    fence i.e. we either need to enable the interrupt or the request is
    already complete but we don't know if we saw the interrupt and so need
    to check signaling.
    
    References: 047a1b877ed4 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Karolina Drobnik <karolina.drobnik@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/d7b953c7a4ba747c8196a164e2f8c5aef468d048.1657289332.git.karolina.drobnik@intel.com
    Stable-dep-of: 70cb9188ffc7 ("drm/i915/gt: Disarm breadcrumbs if engines are already idle")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/mso: using joiner is not possible with eDP MSO [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Jun 14 17:23:11 2024 +0300

    drm/i915/mso: using joiner is not possible with eDP MSO
    
    commit 49cc17967be95d64606d5684416ee51eec35e84a upstream.
    
    It's not possible to use the joiner at the same time with eDP MSO. When
    a panel needs MSO, it's not optional, so MSO trumps joiner.
    
    v3: Only change intel_dp_has_joiner(), leave debugfs alone (Ville)
    
    Fixes: bc71194e8897 ("drm/i915/edp: enable eDP MSO during link training")
    Cc: <stable@vger.kernel.org> # v5.13+
    Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
    Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1668
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240614142311.589089-1-jani.nikula@intel.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    (cherry picked from commit 8b5a92ca24eb96bb71e2a55e352687487d87687f)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/komeda: check for error-valued pointer [+ + +]
Author: Amjad Ouled-Ameur <amjad.ouled-ameur@arm.com>
Date:   Mon Jun 10 11:20:56 2024 +0100

    drm/komeda: check for error-valued pointer
    
    [ Upstream commit b880018edd3a577e50366338194dee9b899947e0 ]
    
    komeda_pipeline_get_state() may return an error-valued pointer, thus
    check the pointer for negative or null value before dereferencing.
    
    Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for CORE")
    Signed-off-by: Amjad Ouled-Ameur <amjad.ouled-ameur@arm.com>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240610102056.40406-1-amjad.ouled-ameur@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/lima: add mask irq callback to gp and pp [+ + +]
Author: Erico Nunes <nunes.erico@gmail.com>
Date:   Fri Apr 5 17:29:49 2024 +0200

    drm/lima: add mask irq callback to gp and pp
    
    [ Upstream commit 49c13b4d2dd4a831225746e758893673f6ae961c ]
    
    This is needed because we want to reset those devices in device-agnostic
    code such as lima_sched.
    In particular, masking irqs will be useful before a hard reset to
    prevent race conditions.
    
    Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
    Signed-off-by: Qiang Yu <yuq825@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240405152951.1531555-2-nunes.erico@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/lima: mask irqs in timeout path before hard reset [+ + +]
Author: Erico Nunes <nunes.erico@gmail.com>
Date:   Fri Apr 5 17:29:51 2024 +0200

    drm/lima: mask irqs in timeout path before hard reset
    
    [ Upstream commit a421cc7a6a001b70415aa4f66024fa6178885a14 ]
    
    There is a race condition in which a rendering job might take just long
    enough to trigger the drm sched job timeout handler but also still
    complete before the hard reset is done by the timeout handler.
    This runs into race conditions not expected by the timeout handler.
    In some very specific cases it currently may result in a refcount
    imbalance on lima_pm_idle, with a stack dump such as:
    
    [10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0
    ...
    [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0
    ...
    [10136.669628] Call trace:
    [10136.669634]  lima_devfreq_record_idle+0xa0/0xb0
    [10136.669646]  lima_sched_pipe_task_done+0x5c/0xb0
    [10136.669656]  lima_gp_irq_handler+0xa8/0x120
    [10136.669666]  __handle_irq_event_percpu+0x48/0x160
    [10136.669679]  handle_irq_event+0x4c/0xc0
    
    We can prevent that race condition entirely by masking the irqs at the
    beginning of the timeout handler, at which point we give up on waiting
    for that job entirely.
    The irqs will be enabled again at the next hard reset which is already
    done as a recovery by the timeout handler.
    
    Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
    Reviewed-by: Qiang Yu <yuq825@gmail.com>
    Signed-off-by: Qiang Yu <yuq825@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240405152951.1531555-4-nunes.erico@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes [+ + +]
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Tue Jun 25 16:10:29 2024 +0800

    drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
    
    commit 6d411c8ccc0137a612e0044489030a194ff5c843 upstream.
    
    In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
    assigned to mode, which will lead to a possible NULL pointer dereference
    on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
    Add a check to avoid null pointer dereference.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240625081029.2619437-1-make24@iscas.ac.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes [+ + +]
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Tue Jun 25 16:18:28 2024 +0800

    drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
    
    commit 66edf3fb331b6c55439b10f9862987b0916b3726 upstream.
    
    In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is
    assigned to mode, which will lead to a possible NULL pointer dereference
    on failure of drm_mode_duplicate(). Add a check to avoid npd.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240625081828.2620794-1-make24@iscas.ac.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep [+ + +]
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Sun Mar 17 17:48:39 2024 +0200

    drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
    
    [ Upstream commit ee7860cd8b5763017f8dc785c2851fecb7a0c565 ]
    
    The ilitek-ili9881c controls the reset GPIO using the non-sleeping
    gpiod_set_value() function. This complains loudly when the GPIO
    controller needs to sleep. As the caller can sleep, use
    gpiod_set_value_cansleep() to fix the issue.
    
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20240317154839.21260-1-laurent.pinchart@ideasonboard.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240317154839.21260-1-laurent.pinchart@ideasonboard.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/panel: simple: Add missing display timing flags for KOE TX26D202VM0BWA [+ + +]
Author: Liu Ying <victor.liu@nxp.com>
Date:   Mon Jun 24 09:56:12 2024 +0800

    drm/panel: simple: Add missing display timing flags for KOE TX26D202VM0BWA
    
    [ Upstream commit 37ce99b77762256ec9fda58d58fd613230151456 ]
    
    KOE TX26D202VM0BWA panel spec indicates the DE signal is active high in
    timing chart, so add DISPLAY_FLAGS_DE_HIGH flag in display timing flags.
    This aligns display_timing with panel_desc.
    
    Fixes: 8a07052440c2 ("drm/panel: simple: Add support for KOE TX26D202VM0BWA panel")
    Signed-off-by: Liu Ying <victor.liu@nxp.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20240624015612.341983-1-victor.liu@nxp.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240624015612.341983-1-victor.liu@nxp.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon/radeon_display: Decrease the size of allocated memory [+ + +]
Author: Erick Archer <erick.archer@outlook.com>
Date:   Sat Mar 30 17:34:47 2024 +0100

    drm/radeon/radeon_display: Decrease the size of allocated memory
    
    [ Upstream commit ae6a233092747e9652eb793d92f79d0820e01c6a ]
    
    This is an effort to get rid of all multiplications from allocation
    functions in order to prevent integer overflows [1] [2].
    
    In this case, the memory allocated to store RADEONFB_CONN_LIMIT pointers
    to "drm_connector" structures can be avoided. This is because this
    memory area is never accessed.
    
    Also, in the kzalloc function, it is preferred to use sizeof(*pointer)
    instead of sizeof(type) due to the type of the variable can change and
    one needs not change the former (unlike the latter).
    
    At the same time take advantage to remove the "#if 0" block, the code
    where the removed memory area was accessed, and the RADEONFB_CONN_LIMIT
    constant due to now is never used.
    
    Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1]
    Link: https://github.com/KSPP/linux/issues/160 [2]
    Acked-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Erick Archer <erick.archer@outlook.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon: fix UBSAN warning in kv_dpm.c [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon May 20 09:11:45 2024 -0400

    drm/radeon: fix UBSAN warning in kv_dpm.c
    
    commit a498df5421fd737d11bfd152428ba6b1c8538321 upstream.
    
    Adds bounds check for sumo_vid_mapping_entry.
    
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/vmwgfx: 3D disabled should not effect STDU memory limits [+ + +]
Author: Ian Forbes <ian.forbes@broadcom.com>
Date:   Tue May 21 13:47:18 2024 -0500

    drm/vmwgfx: 3D disabled should not effect STDU memory limits
    
    [ Upstream commit fb5e19d2dd03eb995ccd468d599b2337f7f66555 ]
    
    This limit became a hard cap starting with the change referenced below.
    Surface creation on the device will fail if the requested size is larger
    than this limit so altering the value arbitrarily will expose modes that
    are too large for the device's hard limits.
    
    Fixes: 7ebb47c9f9ab ("drm/vmwgfx: Read new register for GB memory when available")
    
    Signed-off-by: Ian Forbes <ian.forbes@broadcom.com>
    Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240521184720.767-3-ian.forbes@broadcom.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drop_monitor: replace spin_lock by raw_spin_lock [+ + +]
Author: Wander Lairson Costa <wander@redhat.com>
Date:   Thu Apr 11 11:13:46 2024 -0300

    drop_monitor: replace spin_lock by raw_spin_lock
    
    [ Upstream commit f1e197a665c2148ebc25fe09c53689e60afea195 ]
    
    trace_drop_common() is called with preemption disabled, and it acquires
    a spin_lock. This is problematic for RT kernels because spin_locks are
    sleeping locks in this configuration, which causes the following splat:
    
    BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
    in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47
    preempt_count: 1, expected: 0
    RCU nest depth: 2, expected: 2
    5 locks held by rcuc/47/449:
     #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
     #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
     #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
     #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
     #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
    irq event stamp: 139909
    hardirqs last  enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80
    hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290
    softirqs last  enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170
    softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0
    Preemption disabled at:
    [<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0
    CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7
    Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022
    Call Trace:
     <TASK>
     dump_stack_lvl+0x8c/0xd0
     dump_stack+0x14/0x20
     __might_resched+0x21e/0x2f0
     rt_spin_lock+0x5e/0x130
     ? trace_drop_common.constprop.0+0xb5/0x290
     ? skb_queue_purge_reason.part.0+0x1bf/0x230
     trace_drop_common.constprop.0+0xb5/0x290
     ? preempt_count_sub+0x1c/0xd0
     ? _raw_spin_unlock_irqrestore+0x4a/0x80
     ? __pfx_trace_drop_common.constprop.0+0x10/0x10
     ? rt_mutex_slowunlock+0x26a/0x2e0
     ? skb_queue_purge_reason.part.0+0x1bf/0x230
     ? __pfx_rt_mutex_slowunlock+0x10/0x10
     ? skb_queue_purge_reason.part.0+0x1bf/0x230
     trace_kfree_skb_hit+0x15/0x20
     trace_kfree_skb+0xe9/0x150
     kfree_skb_reason+0x7b/0x110
     skb_queue_purge_reason.part.0+0x1bf/0x230
     ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10
     ? mark_lock.part.0+0x8a/0x520
    ...
    
    trace_drop_common() also disables interrupts, but this is a minor issue
    because we could easily replace it with a local_lock.
    
    Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic
    context.
    
    Signed-off-by: Wander Lairson Costa <wander@redhat.com>
    Reported-by: Hu Chunyu <chuhu@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dt-bindings: i2c: google,cros-ec-i2c-tunnel: correct path to i2c-controller schema [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Thu Jun 20 13:34:50 2024 +0200

    dt-bindings: i2c: google,cros-ec-i2c-tunnel: correct path to i2c-controller schema
    
    commit 5c8cfd592bb7632200b4edac8f2c7ec892ed9d81 upstream.
    
    The referenced i2c-controller.yaml schema is provided by dtschema
    package (outside of Linux kernel), so use full path to reference it.
    
    Cc: stable@vger.kernel.org
    Fixes: 1acd4577a66f ("dt-bindings: i2c: convert i2c-cros-ec-tunnel to json-schema")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
efi/x86: Free EFI memory map only when installing a new one. [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Sat Jun 29 17:12:36 2024 +0200

    efi/x86: Free EFI memory map only when installing a new one.
    
    [ Commit 75dde792d6f6c2d0af50278bd374bf0c512fe196 upstream ]
    
    The logic in __efi_memmap_init() is shared between two different
    execution flows:
    - mapping the EFI memory map early or late into the kernel VA space, so
      that its entries can be accessed;
    - the x86 specific cloning of the EFI memory map in order to insert new
      entries that are created as a result of making a memory reservation
      via a call to efi_mem_reserve().
    
    In the former case, the underlying memory containing the kernel's view
    of the EFI memory map (which may be heavily modified by the kernel
    itself on x86) is not modified at all, and the only thing that changes
    is the virtual mapping of this memory, which is different between early
    and late boot.
    
    In the latter case, an entirely new allocation is created that carries a
    new, updated version of the kernel's view of the EFI memory map. When
    installing this new version, the old version will no longer be
    referenced, and if the memory was allocated by the kernel, it will leak
    unless it gets freed.
    
    The logic that implements this freeing currently lives on the code path
    that is shared between these two use cases, but it should only apply to
    the latter. So move it to the correct spot.
    
    While at it, drop the dummy definition for non-x86 architectures, as
    that is no longer needed.
    
    Cc: <stable@vger.kernel.org>
    Fixes: f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks")
    Tested-by: Ashish Kalra <Ashish.Kalra@amd.com>
    Link: https://lore.kernel.org/all/36ad5079-4326-45ed-85f6-928ff76483d3@amd.com
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
efi: Correct comment on efi_memmap_alloc [+ + +]
Author: Liu Zixian <liuzixian4@huawei.com>
Date:   Sat Jun 29 17:12:33 2024 +0200

    efi: Correct comment on efi_memmap_alloc
    
    [ Commit db01ea882bf601252dad57242655da17fd9ad2f5 upstream ]
    
    Returning zero means success now.
    
    Signed-off-by: Liu Zixian <liuzixian4@huawei.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

efi: memmap: Move manipulation routines into x86 arch tree [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Sat Jun 29 17:12:34 2024 +0200

    efi: memmap: Move manipulation routines into x86 arch tree
    
    [ Commit fdc6d38d64a20c542b1867ebeb8dd03b98829336 upstream ]
    
    The EFI memory map is a description of the memory layout as provided by
    the firmware, and only x86 manipulates it in various different ways for
    its own memory bookkeeping. So let's move the memmap routines that are
    only used by x86 into the x86 arch tree.
    
    [ardb: s/memblock_phys_free/memblock_free for linux-5.15.y backport]
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

efi: xen: Set EFI_PARAVIRT for Xen dom0 boot on all architectures [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Sat Jun 29 17:12:35 2024 +0200

    efi: xen: Set EFI_PARAVIRT for Xen dom0 boot on all architectures
    
    [ Commit d85e3e34940788578eeffd94e8b7e1d28e7278e9 upstream ]
    
    Currently, the EFI_PARAVIRT flag is only used by Xen dom0 boot on x86,
    even though other architectures also support pseudo-EFI boot, where the
    core kernel is invoked directly and provided with a set of data tables
    that resemble the ones constructed by the EFI stub, which never actually
    runs in that case.
    
    Let's fix this inconsistency, and always set this flag when booting dom0
    via the EFI boot path. Note that Xen on x86 does not provide the EFI
    memory map in this case, whereas other architectures do, so move the
    associated EFI_PARAVIRT check into the x86 platform code.
    
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
f2fs: remove clear SB_INLINECRYPT flag in default_options [+ + +]
Author: Yunlei He <heyunlei@oppo.com>
Date:   Tue Mar 26 14:10:43 2024 +0800

    f2fs: remove clear SB_INLINECRYPT flag in default_options
    
    [ Upstream commit ac5eecf481c29942eb9a862e758c0c8b68090c33 ]
    
    In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.
    If create new file or open file during this gap, these files
    will not use inlinecrypt. Worse case, it may lead to data
    corruption if wrappedkey_v0 is enable.
    
    Thread A:                               Thread B:
    
    -f2fs_remount                           -f2fs_file_open or f2fs_new_inode
      -default_options
            <- clear SB_INLINECRYPT flag
    
                                              -fscrypt_select_encryption_impl
    
      -parse_options
            <- set SB_INLINECRYPT again
    
    Signed-off-by: Yunlei He <heyunlei@oppo.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Fix race for duplicate reqsk on identical SYN [+ + +]
Author: luoxuanqiang <luoxuanqiang@kylinos.cn>
Date:   Fri Jun 21 09:39:29 2024 +0800

    Fix race for duplicate reqsk on identical SYN
    
    [ Upstream commit ff46e3b4421923937b7f6e44ffcd3549a074f321 ]
    
    When bonding is configured in BOND_MODE_BROADCAST mode, if two identical
    SYN packets are received at the same time and processed on different CPUs,
    it can potentially create the same sk (sock) but two different reqsk
    (request_sock) in tcp_conn_request().
    
    These two different reqsk will respond with two SYNACK packets, and since
    the generation of the seq (ISN) incorporates a timestamp, the final two
    SYNACK packets will have different seq values.
    
    The consequence is that when the Client receives and replies with an ACK
    to the earlier SYNACK packet, we will reset(RST) it.
    
    ========================================================================
    
    This behavior is consistently reproducible in my local setup,
    which comprises:
    
                      | NETA1 ------ NETB1 |
    PC_A --- bond --- |                    | --- bond --- PC_B
                      | NETA2 ------ NETB2 |
    
    - PC_A is the Server and has two network cards, NETA1 and NETA2. I have
      bonded these two cards using BOND_MODE_BROADCAST mode and configured
      them to be handled by different CPU.
    
    - PC_B is the Client, also equipped with two network cards, NETB1 and
      NETB2, which are also bonded and configured in BOND_MODE_BROADCAST mode.
    
    If the client attempts a TCP connection to the server, it might encounter
    a failure. Capturing packets from the server side reveals:
    
    10.10.10.10.45182 > localhost: Flags [S], seq 320236027,
    10.10.10.10.45182 > localhost: Flags [S], seq 320236027,
    localhost > 10.10.10.10.45182: Flags [S.], seq 2967855116,
    localhost > 10.10.10.10.45182: Flags [S.], seq 2967855123, <==
    10.10.10.10.45182 > localhost: Flags [.], ack 4294967290,
    10.10.10.10.45182 > localhost: Flags [.], ack 4294967290,
    localhost > 10.10.10.10.45182: Flags [R], seq 2967855117, <==
    localhost > 10.10.10.10.45182: Flags [R], seq 2967855117,
    
    Two SYNACKs with different seq numbers are sent by localhost,
    resulting in an anomaly.
    
    ========================================================================
    
    The attempted solution is as follows:
    Add a return value to inet_csk_reqsk_queue_hash_add() to confirm if the
    ehash insertion is successful (Up to now, the reason for unsuccessful
    insertion is that a reqsk for the same connection has already been
    inserted). If the insertion fails, release the reqsk.
    
    Due to the refcnt, Kuniyuki suggests also adding a return value check
    for the DCCP module; if ehash insertion fails, indicating a successful
    insertion of the same connection, simply release the reqsk as well.
    
    Simultaneously, In the reqsk_queue_hash_req(), the start of the
    req->rsk_timer is adjusted to be after successful insertion.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: luoxuanqiang <luoxuanqiang@kylinos.cn>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240621013929.1386815-1-luoxuanqiang@kylinos.cn
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/proc: fix softlockup in __read_vmcore [+ + +]
Author: Rik van Riel <riel@surriel.com>
Date:   Tue May 7 09:18:58 2024 -0400

    fs/proc: fix softlockup in __read_vmcore
    
    commit 5cbcb62dddf5346077feb82b7b0c9254222d3445 upstream.
    
    While taking a kernel core dump with makedumpfile on a larger system,
    softlockup messages often appear.
    
    While softlockup warnings can be harmless, they can also interfere with
    things like RCU freeing memory, which can be problematic when the kdump
    kexec image is configured with as little memory as possible.
    
    Avoid the softlockup, and give things like work items and RCU a chance to
    do their thing during __read_vmcore by adding a cond_resched.
    
    Link: https://lkml.kernel.org/r/20240507091858.36ff767f@imladris.surriel.com
    Signed-off-by: Rik van Riel <riel@surriel.com>
    Acked-by: Baoquan He <bhe@redhat.com>
    Cc: Dave Young <dyoung@redhat.com>
    Cc: Vivek Goyal <vgoyal@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

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

 
ftruncate: pass a signed offset [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jun 19 11:34:09 2024 +0200

    ftruncate: pass a signed offset
    
    commit 4b8e88e563b5f666446d002ad0dc1e6e8e7102b0 upstream.
    
    The old ftruncate() syscall, using the 32-bit off_t misses a sign
    extension when called in compat mode on 64-bit architectures.  As a
    result, passing a negative length accidentally succeeds in truncating
    to file size between 2GiB and 4GiB.
    
    Changing the type of the compat syscall to the signed compat_off_t
    changes the behavior so it instead returns -EINVAL.
    
    The native entry point, the truncate() syscall and the corresponding
    loff_t based variants are all correct already and do not suffer
    from this mistake.
    
    Fixes: 3f6d078d4acc ("fix compat truncate/ftruncate")
    Reviewed-by: Christian Brauner <brauner@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gcov: add support for GCC 14 [+ + +]
Author: Peter Oberparleiter <oberpar@linux.ibm.com>
Date:   Mon Jun 10 11:27:43 2024 +0200

    gcov: add support for GCC 14
    
    commit c1558bc57b8e5b4da5d821537cd30e2e660861d8 upstream.
    
    Using gcov on kernels compiled with GCC 14 results in truncated 16-byte
    long .gcda files with no usable data.  To fix this, update GCOV_COUNTERS
    to match the value defined by GCC 14.
    
    Tested with GCC versions 14.1.0 and 13.2.0.
    
    Link: https://lkml.kernel.org/r/20240610092743.1609845-1-oberpar@linux.ibm.com
    Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Reported-by: Allison Henderson <allison.henderson@oracle.com>
    Reported-by: Chuck Lever III <chuck.lever@oracle.com>
    Tested-by: Chuck Lever <chuck.lever@oracle.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gpio: davinci: Validate the obtained number of IRQs [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Tue Jun 18 17:43:44 2024 +0300

    gpio: davinci: Validate the obtained number of IRQs
    
    [ Upstream commit 7aa9b96e9a73e4ec1771492d0527bd5fc5ef9164 ]
    
    Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken
    DT due to any error this value can be any. Without this value validation
    there can be out of chips->irqs array boundaries access in
    davinci_gpio_probe().
    
    Validate the obtained nirq value so that it won't exceed the maximum
    number of IRQs per bank.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Link: https://lore.kernel.org/r/20240618144344.16943-1-amishin@t-argos.ru
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gpio: tqmx86: fix typo in Kconfig label [+ + +]
Author: Gregor Herburger <gregor.herburger@tq-group.com>
Date:   Thu May 30 12:19:59 2024 +0200

    gpio: tqmx86: fix typo in Kconfig label
    
    [ Upstream commit 8c219e52ca4d9a67cd6a7074e91bf29b55edc075 ]
    
    Fix description for GPIO_TQMX86 from QTMX86 to TQMx86.
    
    Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
    Signed-off-by: Gregor Herburger <gregor.herburger@tq-group.com>
    Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/e0e38c9944ad6d281d9a662a45d289b88edc808e.1717063994.git.matthias.schiffer@ew.tq-group.com
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gpio: tqmx86: store IRQ trigger type and unmask status separately [+ + +]
Author: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Date:   Thu May 30 12:20:01 2024 +0200

    gpio: tqmx86: store IRQ trigger type and unmask status separately
    
    commit 08af509efdf8dad08e972b48de0e2c2a7919ea8b upstream.
    
    irq_set_type() should not implicitly unmask the IRQ.
    
    All accesses to the interrupt configuration register are moved to a new
    helper tqmx86_gpio_irq_config(). We also introduce the new rule that
    accessing irq_type must happen while locked, which will become
    significant for fixing EDGE_BOTH handling.
    
    Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
    Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
    Link: https://lore.kernel.org/r/6aa4f207f77cb58ef64ffb947e91949b0f753ccd.1717063994.git.matthias.schiffer@ew.tq-group.com
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gpiolib: cdev: Disallow reconfiguration without direction (uAPI v1) [+ + +]
Author: Kent Gibson <warthog618@gmail.com>
Date:   Wed Jun 26 13:29:22 2024 +0800

    gpiolib: cdev: Disallow reconfiguration without direction (uAPI v1)
    
    [ Upstream commit 9919cce62f68e6ab68dc2a975b5dc670f8ca7d40 ]
    
    linehandle_set_config() behaves badly when direction is not set.
    The configuration validation is borrowed from linehandle_create(), where,
    to verify the intent of the user, the direction must be set to in order
    to effect a change to the electrical configuration of a line. But, when
    applied to reconfiguration, that validation does not allow for the unset
    direction case, making it possible to clear flags set previously without
    specifying the line direction.
    
    Adding to the inconsistency, those changes are not immediately applied by
    linehandle_set_config(), but will take effect when the line value is next
    get or set.
    
    For example, by requesting a configuration with no flags set, an output
    line with GPIOHANDLE_REQUEST_ACTIVE_LOW and GPIOHANDLE_REQUEST_OPEN_DRAIN
    requested could have those flags cleared, inverting the sense of the line
    and changing the line drive to push-pull on the next line value set.
    
    Ensure the intent of the user by disallowing configurations which do not
    have direction set, returning an error to userspace to indicate that the
    configuration is invalid.
    
    And, for clarity, use lflags, a local copy of gcnf.flags, throughout when
    dealing with the requested flags, rather than a mixture of both.
    
    Fixes: e588bb1eae31 ("gpio: add new SET_CONFIG ioctl() to gpio chardev")
    Signed-off-by: Kent Gibson <warthog618@gmail.com>
    Link: https://lore.kernel.org/r/20240626052925.174272-2-warthog618@gmail.com
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
greybus: Fix use-after-free bug in gb_interface_release due to race condition. [+ + +]
Author: Sicong Huang <congei42@163.com>
Date:   Tue Apr 16 16:03:13 2024 +0800

    greybus: Fix use-after-free bug in gb_interface_release due to race condition.
    
    commit 5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce upstream.
    
    In gb_interface_create, &intf->mode_switch_completion is bound with
    gb_interface_mode_switch_work. Then it will be started by
    gb_interface_request_mode_switch. Here is the relevant code.
    if (!queue_work(system_long_wq, &intf->mode_switch_work)) {
            ...
    }
    
    If we call gb_interface_release to make cleanup, there may be an
    unfinished work. This function will call kfree to free the object
    "intf". However, if gb_interface_mode_switch_work is scheduled to
    run after kfree, it may cause use-after-free error as
    gb_interface_mode_switch_work will use the object "intf".
    The possible execution flow that may lead to the issue is as follows:
    
    CPU0                            CPU1
    
                                |   gb_interface_create
                                |   gb_interface_request_mode_switch
    gb_interface_release        |
    kfree(intf) (free)          |
                                |   gb_interface_mode_switch_work
                                |   mutex_lock(&intf->mutex) (use)
    
    Fix it by canceling the work before kfree.
    
    Signed-off-by: Sicong Huang <congei42@163.com>
    Link: https://lore.kernel.org/r/20240416080313.92306-1-congei42@163.com
    Cc: Ronnie Sahlberg <rsahlberg@ciq.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gve: Add RX context. [+ + +]
Author: David Awogbemila <awogbemila@google.com>
Date:   Sun Oct 24 11:42:36 2021 -0700

    gve: Add RX context.
    
    [ Upstream commit 1344e751e91092ac0cb63b194621e59d2f364197 ]
    
    This refactor moves the skb_head and skb_tail fields into a new
    gve_rx_ctx struct. This new struct will contain information about the
    current packet being processed. This is in preparation for
    multi-descriptor RX packets.
    
    Signed-off-by: David Awogbemila <awogbemila@google.com>
    Signed-off-by: Jeroen de Borst <jeroendb@google.com>
    Reviewed-by: Catherine Sullivan <csully@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 6f4d93b78ade ("gve: Clear napi->skb before dev_kfree_skb_any()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gve: Clear napi->skb before dev_kfree_skb_any() [+ + +]
Author: Ziwei Xiao <ziweixiao@google.com>
Date:   Wed Jun 12 00:16:54 2024 +0000

    gve: Clear napi->skb before dev_kfree_skb_any()
    
    [ Upstream commit 6f4d93b78ade0a4c2cafd587f7b429ce95abb02e ]
    
    gve_rx_free_skb incorrectly leaves napi->skb referencing an skb after it
    is freed with dev_kfree_skb_any(). This can result in a subsequent call
    to napi_get_frags returning a dangling pointer.
    
    Fix this by clearing napi->skb before the skb is freed.
    
    Fixes: 9b8dd5e5ea48 ("gve: DQO: Add RX path")
    Cc: stable@vger.kernel.org
    Reported-by: Shailend Chand <shailend@google.com>
    Signed-off-by: Ziwei Xiao <ziweixiao@google.com>
    Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
    Reviewed-by: Shailend Chand <shailend@google.com>
    Reviewed-by: Praveen Kaligineedi <pkaligineedi@google.com>
    Link: https://lore.kernel.org/r/20240612001654.923887-1-ziweixiao@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hexagon: fix fadvise64_64 calling conventions [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Jun 20 15:24:11 2024 +0200

    hexagon: fix fadvise64_64 calling conventions
    
    commit 896842284c6ccba25ec9d78b7b6e62cdd507c083 upstream.
    
    fadvise64_64() has two 64-bit arguments at the wrong alignment
    for hexagon, which turns them into a 7-argument syscall that is
    not supported by Linux.
    
    The downstream musl port for hexagon actually asks for a 6-argument
    version the same way we do it on arm, csky, powerpc, so make the
    kernel do it the same way to avoid having to change both.
    
    Link: https://github.com/quic/musl/blob/hexagon/arch/hexagon/syscall_arch.h#L78
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HID: Add quirk for Logitech Casa touchpad [+ + +]
Author: Sean O'Brien <seobrien@chromium.org>
Date:   Mon Apr 29 18:08:05 2024 +0000

    HID: Add quirk for Logitech Casa touchpad
    
    [ Upstream commit dd2c345a94cfa3873cc20db87387ee509c345c1b ]
    
    This device sometimes doesn't send touch release signals when moving
    from >=4 fingers to <4 fingers. Using MT_QUIRK_NOT_SEEN_MEANS_UP instead
    of MT_QUIRK_ALWAYS_VALID makes sure that no touches become stuck.
    
    MT_QUIRK_FORCE_MULTI_INPUT is not necessary for this device, but does no
    harm.
    
    Signed-off-by: Sean O'Brien <seobrien@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: core: remove unnecessary WARN_ON() in implement() [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Fri May 17 07:19:14 2024 -0700

    HID: core: remove unnecessary WARN_ON() in implement()
    
    [ Upstream commit 4aa2dcfbad538adf7becd0034a3754e1bd01b2b5 ]
    
    Syzkaller hit a warning [1] in a call to implement() when trying
    to write a value into a field of smaller size in an output report.
    
    Since implement() already has a warn message printed out with the
    help of hid_warn() and value in question gets trimmed with:
            ...
            value &= m;
            ...
    WARN_ON may be considered superfluous. Remove it to suppress future
    syzkaller triggers.
    
    [1]
    WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
    WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
    Modules linked in:
    CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
    RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
    RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
    ...
    Call Trace:
     <TASK>
     __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
     usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
     hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
     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: 95d1c8951e5b ("HID: simplify implement() a bit")
    Reported-by: <syzbot+5186630949e3c55f0799@syzkaller.appspotmail.com>
    Suggested-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode() [+ + +]
Author: José Expósito <jose.exposito89@gmail.com>
Date:   Fri May 24 15:05:39 2024 +0200

    HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()
    
    [ Upstream commit ce3af2ee95170b7d9e15fff6e500d67deab1e7b3 ]
    
    Fix a memory leak on logi_dj_recv_send_report() error path.
    
    Fixes: 6f20d3261265 ("HID: logitech-dj: Fix error handling in logi_dj_recv_switch_to_dj_mode()")
    Signed-off-by: José Expósito <jose.exposito89@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hugetlb_encode.h: fix undefined behaviour (34 << 26) [+ + +]
Author: Matthias Goergens <matthias.goergens@gmail.com>
Date:   Mon Sep 5 11:19:04 2022 +0800

    hugetlb_encode.h: fix undefined behaviour (34 << 26)
    
    commit 710bb68c2e3a24512e2d2bae470960d7488e97b1 upstream.
    
    Left-shifting past the size of your datatype is undefined behaviour in C.
    The literal 34 gets the type `int`, and that one is not big enough to be
    left shifted by 26 bits.
    
    An `unsigned` is long enough (on any machine that has at least 32 bits for
    their ints.)
    
    For uniformity, we mark all the literals as unsigned.  But it's only
    really needed for HUGETLB_FLAG_ENCODE_16GB.
    
    Thanks to Randy Dunlap for an initial review and suggestion.
    
    Link: https://lkml.kernel.org/r/20220905031904.150925-1-matthias.goergens@gmail.com
    Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
    Acked-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Muchun Song <songmuchun@bytedance.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Carlos Llamas <cmllamas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i2c: acpi: Unbind mux adapters before delete [+ + +]
Author: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Date:   Wed Mar 13 11:16:32 2024 +1300

    i2c: acpi: Unbind mux adapters before delete
    
    [ Upstream commit 3f858bbf04dbac934ac279aaee05d49eb9910051 ]
    
    There is an issue with ACPI overlay table removal specifically related
    to I2C multiplexers.
    
    Consider an ACPI SSDT Overlay that defines a PCA9548 I2C mux on an
    existing I2C bus. When this table is loaded we see the creation of a
    device for the overall PCA9548 chip and 8 further devices - one
    i2c_adapter each for the mux channels. These are all bound to their
    ACPI equivalents via an eventual invocation of acpi_bind_one().
    
    When we unload the SSDT overlay we run into the problem. The ACPI
    devices are deleted as normal via acpi_device_del_work_fn() and the
    acpi_device_del_list.
    
    However, the following warning and stack trace is output as the
    deletion does not go smoothly:
    ------------[ cut here ]------------
    kernfs: can not remove 'physical_node', no directory
    WARNING: CPU: 1 PID: 11 at fs/kernfs/dir.c:1674 kernfs_remove_by_name_ns+0xb9/0xc0
    Modules linked in:
    CPU: 1 PID: 11 Comm: kworker/u128:0 Not tainted 6.8.0-rc6+ #1
    Hardware name: congatec AG conga-B7E3/conga-B7E3, BIOS 5.13 05/16/2023
    Workqueue: kacpi_hotplug acpi_device_del_work_fn
    RIP: 0010:kernfs_remove_by_name_ns+0xb9/0xc0
    Code: e4 00 48 89 ef e8 07 71 db ff 5b b8 fe ff ff ff 5d 41 5c 41 5d e9 a7 55 e4 00 0f 0b eb a6 48 c7 c7 f0 38 0d 9d e8 97 0a d5 ff <0f> 0b eb dc 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
    RSP: 0018:ffff9f864008fb28 EFLAGS: 00010286
    RAX: 0000000000000000 RBX: ffff8ef90a8d4940 RCX: 0000000000000000
    RDX: ffff8f000e267d10 RSI: ffff8f000e25c780 RDI: ffff8f000e25c780
    RBP: ffff8ef9186f9870 R08: 0000000000013ffb R09: 00000000ffffbfff
    R10: 00000000ffffbfff R11: ffff8f000e0a0000 R12: ffff9f864008fb50
    R13: ffff8ef90c93dd60 R14: ffff8ef9010d0958 R15: ffff8ef9186f98c8
    FS:  0000000000000000(0000) GS:ffff8f000e240000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f48f5253a08 CR3: 00000003cb82e000 CR4: 00000000003506f0
    Call Trace:
     <TASK>
     ? kernfs_remove_by_name_ns+0xb9/0xc0
     ? __warn+0x7c/0x130
     ? kernfs_remove_by_name_ns+0xb9/0xc0
     ? report_bug+0x171/0x1a0
     ? handle_bug+0x3c/0x70
     ? exc_invalid_op+0x17/0x70
     ? asm_exc_invalid_op+0x1a/0x20
     ? kernfs_remove_by_name_ns+0xb9/0xc0
     ? kernfs_remove_by_name_ns+0xb9/0xc0
     acpi_unbind_one+0x108/0x180
     device_del+0x18b/0x490
     ? srso_return_thunk+0x5/0x5f
     ? srso_return_thunk+0x5/0x5f
     device_unregister+0xd/0x30
     i2c_del_adapter.part.0+0x1bf/0x250
     i2c_mux_del_adapters+0xa1/0xe0
     i2c_device_remove+0x1e/0x80
     device_release_driver_internal+0x19a/0x200
     bus_remove_device+0xbf/0x100
     device_del+0x157/0x490
     ? __pfx_device_match_fwnode+0x10/0x10
     ? srso_return_thunk+0x5/0x5f
     device_unregister+0xd/0x30
     i2c_acpi_notify+0x10f/0x140
     notifier_call_chain+0x58/0xd0
     blocking_notifier_call_chain+0x3a/0x60
     acpi_device_del_work_fn+0x85/0x1d0
     process_one_work+0x134/0x2f0
     worker_thread+0x2f0/0x410
     ? __pfx_worker_thread+0x10/0x10
     kthread+0xe3/0x110
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x2f/0x50
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1b/0x30
     </TASK>
    ---[ end trace 0000000000000000 ]---
    ...
    repeated 7 more times, 1 for each channel of the mux
    ...
    
    The issue is that the binding of the ACPI devices to their peer I2C
    adapters is not correctly cleaned up. Digging deeper into the issue we
    see that the deletion order is such that the ACPI devices matching the
    mux channel i2c adapters are deleted first during the SSDT overlay
    removal. For each of the channels we see a call to i2c_acpi_notify()
    with ACPI_RECONFIG_DEVICE_REMOVE but, because these devices are not
    actually i2c_clients, nothing is done for them.
    
    Later on, after each of the mux channels has been dealt with, we come
    to delete the i2c_client representing the PCA9548 device. This is the
    call stack we see above, whereby the kernel cleans up the i2c_client
    including destruction of the mux and its channel adapters. At this
    point we do attempt to unbind from the ACPI peers but those peers no
    longer exist and so we hit the kernfs errors.
    
    The fix is to augment i2c_acpi_notify() to handle i2c_adapters. But,
    given that the life cycle of the adapters is linked to the i2c_client,
    instead of deleting the i2c_adapters during the i2c_acpi_notify(), we
    just trigger unbinding of the ACPI device from the adapter device, and
    allow the clean up of the adapter to continue in the way it always has.
    
    Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications")
    Cc: <stable@vger.kernel.org> # v4.8+
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: add fwnode APIs [+ + +]
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Wed Jan 11 10:54:21 2023 +0000

    i2c: add fwnode APIs
    
    [ Upstream commit 373c612d72461ddaea223592df31e62c934aae61 ]
    
    Add fwnode APIs for finding and getting I2C adapters, which will be
    used by the SFP code. These are passed the fwnode corresponding to
    the adapter, and return the I2C adapter. It is the responsibility of
    the caller to find the appropriate fwnode.
    
    We keep the DT and ACPI interfaces, but where appropriate, recode them
    to use the fwnode interfaces internally.
    
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Stable-dep-of: 3f858bbf04db ("i2c: acpi: Unbind mux adapters before delete")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: at91: Fix the functionality flags of the slave-only interface [+ + +]
Author: Jean Delvare <jdelvare@suse.de>
Date:   Fri May 31 11:19:14 2024 +0200

    i2c: at91: Fix the functionality flags of the slave-only interface
    
    [ Upstream commit d6d5645e5fc1233a7ba950de4a72981c394a2557 ]
    
    When an I2C adapter acts only as a slave, it should not claim to
    support I2C master capabilities.
    
    Fixes: 9d3ca54b550c ("i2c: at91: added slave mode support")
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Cc: Juergen Fitschen <me@jue.yt>
    Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
    Cc: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
    Cc: Andi Shyti <andi.shyti@kernel.org>
    Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
    Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: designware: Fix the functionality flags of the slave-only interface [+ + +]
Author: Jean Delvare <jdelvare@suse.de>
Date:   Fri May 31 11:17:48 2024 +0200

    i2c: designware: Fix the functionality flags of the slave-only interface
    
    [ Upstream commit cbf3fb5b29e99e3689d63a88c3cddbffa1b8de99 ]
    
    When an I2C adapter acts only as a slave, it should not claim to
    support I2C master capabilities.
    
    Fixes: 5b6d721b266a ("i2c: designware: enable SLAVE in platform module")
    Signed-off-by: Jean Delvare <jdelvare@suse.de>
    Cc: Luis Oliveira <lolivei@synopsys.com>
    Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
    Cc: Jan Dabros <jsd@semihalf.com>
    Cc: Andi Shyti <andi.shyti@kernel.org>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: ocores: set IACK bit after core is enabled [+ + +]
Author: Grygorii Tertychnyi <grembeter@gmail.com>
Date:   Mon May 20 17:39:32 2024 +0200

    i2c: ocores: set IACK bit after core is enabled
    
    commit 5a72477273066b5b357801ab2d315ef14949d402 upstream.
    
    Setting IACK bit when core is disabled does not clear the "Interrupt Flag"
    bit in the status register, and the interrupt remains pending.
    
    Sometimes it causes failure for the very first message transfer, that is
    usually a device probe.
    
    Hence, set IACK bit after core is enabled to clear pending interrupt.
    
    Fixes: 18f98b1e3147 ("[PATCH] i2c: New bus driver for the OpenCores I2C controller")
    Signed-off-by: Grygorii Tertychnyi <grygorii.tertychnyi@leica-geosystems.com>
    Acked-by: Peter Korsgaard <peter@korsgaard.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i2c: testunit: discard write requests while old command is running [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Jun 27 13:14:48 2024 +0200

    i2c: testunit: discard write requests while old command is running
    
    [ Upstream commit c116deafd1a5cc1e9739099eb32114e90623209c ]
    
    When clearing registers on new write requests was added, the protection
    for currently running commands was missed leading to concurrent access
    to the testunit registers. Check the flag beforehand.
    
    Fixes: b39ab96aa894 ("i2c: testunit: add support for block process calls")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: testunit: don't erase registers after STOP [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Jun 27 13:14:47 2024 +0200

    i2c: testunit: don't erase registers after STOP
    
    [ Upstream commit c422b6a630240f706063e0ecbb894aa8491b1fa1 ]
    
    STOP fallsthrough to WRITE_REQUESTED but this became problematic when
    clearing the testunit registers was added to the latter. Actually, there
    is no reason to clear the testunit state after STOP. Doing it when a new
    WRITE_REQUESTED arrives is enough. So, no need to fallthrough, at all.
    
    Fixes: b39ab96aa894 ("i2c: testunit: add support for block process calls")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ibmvnic: Free any outstanding tx skbs during scrq reset [+ + +]
Author: Nick Child <nnac123@linux.ibm.com>
Date:   Thu Jun 20 10:23:12 2024 -0500

    ibmvnic: Free any outstanding tx skbs during scrq reset
    
    [ Upstream commit 49bbeb5719c2f56907d3a9623b47c6c15c2c431d ]
    
    There are 2 types of outstanding tx skb's:
    Type 1: Packets that are sitting in the drivers ind_buff that are
    waiting to be batch sent to the NIC. During a device reset, these are
    freed with a call to ibmvnic_tx_scrq_clean_buffer()
    Type 2: Packets that have been sent to the NIC and are awaiting a TX
    completion IRQ. These are free'd during a reset with a call to
    clean_tx_pools()
    
    During any reset which requires us to free the tx irq, ensure that the
    Type 2 skb references are freed. Since the irq is released, it is
    impossible for the NIC to inform of any completions.
    
    Furthermore, later in the reset process is a call to init_tx_pools()
    which marks every entry in the tx pool as free (ie not outstanding).
    So if the driver is to make a call to init_tx_pools(), it must first
    be sure that the tx pool is empty of skb references.
    
    This issue was discovered by observing the following in the logs during
    EEH testing:
            TX free map points to untracked skb (tso_pool 0 idx=4)
            TX free map points to untracked skb (tso_pool 0 idx=5)
            TX free map points to untracked skb (tso_pool 1 idx=36)
    
    Fixes: 65d6470d139a ("ibmvnic: clean pending indirect buffs during reset")
    Signed-off-by: Nick Child <nnac123@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iio: accel: fxls8962af: select IIO_BUFFER & IIO_KFIFO_BUF [+ + +]
Author: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Date:   Wed Jun 5 22:38:06 2024 +0200

    iio: accel: fxls8962af: select IIO_BUFFER & IIO_KFIFO_BUF
    
    commit a821d7111e3f7c8869961b606714a299bfe20014 upstream.
    
    Provide missing symbols to the module:
    ERROR: modpost: iio_push_to_buffers [drivers/iio/accel/fxls8962af-core.ko] undefined!
    ERROR: modpost: devm_iio_kfifo_buffer_setup_ext [drivers/iio/accel/fxls8962af-core.ko] undefined!
    
    Cc: stable@vger.kernel.org
    Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling")
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
    Reviewed-by: Sean Nyekjaer <sean@geanix.com>
    Link: https://lore.kernel.org/r/20240605203810.2908980-2-alexander.sverdlin@siemens.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

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

iio: adc: ad7266: Fix variable checking bug [+ + +]
Author: Fernando Yang <hagisf@usp.br>
Date:   Mon Jun 3 15:07:54 2024 -0300

    iio: adc: ad7266: Fix variable checking bug
    
    commit a2b86132955268b2a1703082fbc2d4832fc001b8 upstream.
    
    The ret variable was not checked after iio_device_release_direct_mode(),
    which could possibly cause errors
    
    Fixes: c70df20e3159 ("iio: adc: ad7266: claim direct mode during sensor read")
    Signed-off-by: Fernando Yang <hagisf@usp.br>
    Link: https://lore.kernel.org/r/20240603180757.8560-1-hagisf@usp.br
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: adc: ad9467: fix scan type sign [+ + +]
Author: David Lechner <dlechner@baylibre.com>
Date:   Fri May 3 14:45:05 2024 -0500

    iio: adc: ad9467: fix scan type sign
    
    commit 8a01ef749b0a632f0e1f4ead0f08b3310d99fcb1 upstream.
    
    According to the IIO documentation, the sign in the scan type should be
    lower case. The ad9467 driver was incorrectly using upper case.
    
    Fix by changing to lower case.
    
    Fixes: 4606d0f4b05f ("iio: adc: ad9467: add support for AD9434 high-speed ADC")
    Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC")
    Signed-off-by: David Lechner <dlechner@baylibre.com>
    Link: https://lore.kernel.org/r/20240503-ad9467-fix-scan-type-sign-v1-1-c7a1a066ebb9@baylibre.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: chemical: bme680: Fix calibration data variable [+ + +]
Author: Vasileios Amoiridis <vassilisamir@gmail.com>
Date:   Thu Jun 6 23:22:54 2024 +0200

    iio: chemical: bme680: Fix calibration data variable
    
    commit b47c0fee73a810c4503c4a94ea34858a1d865bba upstream.
    
    According to the BME68x Sensor API [1], the h6 calibration
    data variable should be an unsigned integer of size 8.
    
    [1]: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x_defs.h#L789
    
    Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
    Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
    Link: https://lore.kernel.org/r/20240606212313.207550-3-vassilisamir@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: chemical: bme680: Fix overflows in compensate() functions [+ + +]
Author: Vasileios Amoiridis <vassilisamir@gmail.com>
Date:   Thu Jun 6 23:22:55 2024 +0200

    iio: chemical: bme680: Fix overflows in compensate() functions
    
    commit fdd478c3ae98c3f13628e110dce9b6cfb0d9b3c8 upstream.
    
    There are cases in the compensate functions of the driver that
    there could be overflows of variables due to bit shifting ops.
    These implications were initially discussed here [1] and they
    were mentioned in log message of Commit 1b3bd8592780 ("iio:
    chemical: Add support for Bosch BME680 sensor").
    
    [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/
    
    Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
    Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
    Link: https://lore.kernel.org/r/20240606212313.207550-4-vassilisamir@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: chemical: bme680: Fix pressure value output [+ + +]
Author: Vasileios Amoiridis <vassilisamir@gmail.com>
Date:   Thu Jun 6 23:22:53 2024 +0200

    iio: chemical: bme680: Fix pressure value output
    
    commit ae1f7b93b52095be6776d0f34957b4f35dda44d9 upstream.
    
    The IIO standard units are measured in kPa while the driver
    is using hPa.
    
    Apart from checking the userspace value itself, it is mentioned also
    in the Bosch API [1] that the pressure value is in Pascal.
    
    [1]: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x_defs.h#L742
    
    Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
    Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
    Link: https://lore.kernel.org/r/20240606212313.207550-2-vassilisamir@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: chemical: bme680: Fix sensor data read operation [+ + +]
Author: Vasileios Amoiridis <vassilisamir@gmail.com>
Date:   Thu Jun 6 23:22:56 2024 +0200

    iio: chemical: bme680: Fix sensor data read operation
    
    commit 4241665e6ea063a9c1d734de790121a71db763fc upstream.
    
    A read operation is happening as follows:
    
    a) Set sensor to forced mode
    b) Sensor measures values and update data registers and sleeps again
    c) Read data registers
    
    In the current implementation the read operation happens immediately
    after the sensor is set to forced mode so the sensor does not have
    the time to update properly the registers. This leads to the following
    2 problems:
    
    1) The first ever value which is read by the register is always wrong
    2) Every read operation, puts the register into forced mode and reads
    the data that were calculated in the previous conversion.
    
    This behaviour was tested in 2 ways:
    
    1) The internal meas_status_0 register was read before and after every
    read operation in order to verify that the data were ready even before
    the register was set to forced mode and also to check that after the
    forced mode was set the new data were not yet ready.
    
    2) Physically changing the temperature and measuring the temperature
    
    This commit adds the waiting time in between the set of the forced mode
    and the read of the data. The function is taken from the Bosch BME68x
    Sensor API [1].
    
    [1]: https://github.com/boschsensortec/BME68x_SensorAPI/blob/v4.4.8/bme68x.c#L490
    
    Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
    Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
    Link: https://lore.kernel.org/r/20240606212313.207550-5-vassilisamir@gmail.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: dac: ad5592r: fix temperature channel scaling value [+ + +]
Author: Marc Ferland <marc.ferland@sonatest.com>
Date:   Wed May 1 11:05:54 2024 -0400

    iio: dac: ad5592r: fix temperature channel scaling value
    
    commit 279428df888319bf68f2686934897301a250bb84 upstream.
    
    The scale value for the temperature channel is (assuming Vref=2.5 and
    the datasheet):
    
        376.7897513
    
    When calculating both val and val2 for the temperature scale we
    use (3767897513/25) and multiply it by Vref (here I assume 2500mV) to
    obtain:
    
      2500 * (3767897513/25) ==> 376789751300
    
    Finally we divide with remainder by 10^9 to get:
    
        val = 376
        val2 = 789751300
    
    However, we return IIO_VAL_INT_PLUS_MICRO (should have been NANO) as
    the scale type. So when converting the raw temperature value to the
    'processed' temperature value we will get (assuming raw=810,
    offset=-753):
    
        processed = (raw + offset) * scale_val
                  = (810 + -753) * 376
                  = 21432
    
        processed += div((raw + offset) * scale_val2, 10^6)
                  += div((810 + -753) * 789751300, 10^6)
                  += 45015
        ==> 66447
        ==> 66.4 Celcius
    
    instead of the expected 21.5 Celsius.
    
    Fix this issue by changing IIO_VAL_INT_PLUS_MICRO to
    IIO_VAL_INT_PLUS_NANO.
    
    Fixes: 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs")
    Signed-off-by: Marc Ferland <marc.ferland@sonatest.com>
    Link: https://lore.kernel.org/r/20240501150554.1871390-1-marc.ferland@sonatest.com
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: imu: inv_icm42600: delete unneeded update watermark call [+ + +]
Author: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Date:   Mon May 27 21:00:08 2024 +0000

    iio: imu: inv_icm42600: delete unneeded update watermark call
    
    commit 245f3b149e6cc3ac6ee612cdb7042263bfc9e73c upstream.
    
    Update watermark will be done inside the hwfifo_set_watermark callback
    just after the update_scan_mode. It is useless to do it here.
    
    Fixes: 7f85e42a6c54 ("iio: imu: inv_icm42600: add buffer support in iio devices")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
    Link: https://lore.kernel.org/r/20240527210008.612932-1-inv.git-commit@tdk.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Input: ili210x - fix ili251x_read_touch_data() return value [+ + +]
Author: John Keeping <jkeeping@inmusicbrands.com>
Date:   Thu May 23 09:56:24 2024 +0100

    Input: ili210x - fix ili251x_read_touch_data() return value
    
    [ Upstream commit 9f0fad0382124e7e23b3c730fa78818c22c89c0a ]
    
    The caller of this function treats all non-zero values as an error, so
    the return value of i2c_master_recv() cannot be returned directly.
    
    This fixes touch reporting when there are more than 6 active touches.
    
    Fixes: ef536abd3afd1 ("Input: ili210x - define and use chip operations structure")
    Signed-off-by: John Keeping <jkeeping@inmusicbrands.com>
    Link: https://lore.kernel.org/r/20240523085624.2295988-1-jkeeping@inmusicbrands.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
intel_th: pci: Add Granite Rapids SOC support [+ + +]
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Mon Apr 29 16:01:15 2024 +0300

    intel_th: pci: Add Granite Rapids SOC support
    
    commit 854afe461b009801a171b3a49c5f75ea43e4c04c upstream.
    
    Add support for the Trace Hub in Granite Rapids SOC.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20240429130119.1518073-12-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

intel_th: pci: Add Granite Rapids support [+ + +]
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Mon Apr 29 16:01:14 2024 +0300

    intel_th: pci: Add Granite Rapids support
    
    commit e44937889bdf4ecd1f0c25762b7226406b9b7a69 upstream.
    
    Add support for the Trace Hub in Granite Rapids.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20240429130119.1518073-11-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

intel_th: pci: Add Lunar Lake support [+ + +]
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Mon Apr 29 16:01:19 2024 +0300

    intel_th: pci: Add Lunar Lake support
    
    commit f866b65322bfbc8fcca13c25f49e1a5c5a93ae4d upstream.
    
    Add support for the Trace Hub in Lunar Lake.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20240429130119.1518073-16-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

intel_th: pci: Add Meteor Lake-S support [+ + +]
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Mon Apr 29 16:01:17 2024 +0300

    intel_th: pci: Add Meteor Lake-S support
    
    commit c4a30def564d75e84718b059d1a62cc79b137cf9 upstream.
    
    Add support for the Trace Hub in Meteor Lake-S.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20240429130119.1518073-14-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

intel_th: pci: Add Sapphire Rapids SOC support [+ + +]
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Mon Apr 29 16:01:16 2024 +0300

    intel_th: pci: Add Sapphire Rapids SOC support
    
    commit 2e1da7efabe05cb0cf0b358883b2bc89080ed0eb upstream.
    
    Add support for the Trace Hub in Sapphire Rapids SOC.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20240429130119.1518073-13-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommu/amd: Fix sysfs leak in iommu init [+ + +]
Author: Kun(llfl) <llfl@linux.alibaba.com>
Date:   Thu May 9 08:42:20 2024 +0800

    iommu/amd: Fix sysfs leak in iommu init
    
    [ Upstream commit a295ec52c8624883885396fde7b4df1a179627c3 ]
    
    During the iommu initialization, iommu_init_pci() adds sysfs nodes.
    However, these nodes aren't remove in free_iommu_resources() subsequently.
    
    Fixes: 39ab9555c241 ("iommu: Add sysfs bindings for struct iommu_device")
    Signed-off-by: Kun(llfl) <llfl@linux.alibaba.com>
    Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Link: https://lore.kernel.org/r/c8e0d11c6ab1ee48299c288009cf9c5dae07b42d.1715215003.git.llfl@linux.alibaba.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/amd: Introduce pci segment structure [+ + +]
Author: Vasant Hegde <vasant.hegde@amd.com>
Date:   Wed Jul 6 17:07:52 2022 +0530

    iommu/amd: Introduce pci segment structure
    
    [ Upstream commit 404ec4e4c169fb64da6b2a38b471c13ac0897c76 ]
    
    Newer AMD systems can support multiple PCI segments, where each segment
    contains one or more IOMMU instances. However, an IOMMU instance can only
    support a single PCI segment.
    
    Current code assumes that system contains only one pci segment (segment 0)
    and creates global data structures such as device table, rlookup table,
    etc.
    
    Introducing per PCI segment data structure, which contains segment
    specific data structures. This will eventually replace the global
    data structures.
    
    Also update `amd_iommu->pci_seg` variable to point to PCI segment
    structure instead of PCI segment ID.
    
    Co-developed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
    Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
    Link: https://lore.kernel.org/r/20220706113825.25582-3-vasant.hegde@amd.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Stable-dep-of: a295ec52c862 ("iommu/amd: Fix sysfs leak in iommu init")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/arm-smmu-v3: Free MSIs in case of ENOMEM [+ + +]
Author: Aleksandr Aprelkov <aaprelkov@usergate.com>
Date:   Wed Apr 3 12:37:59 2024 +0700

    iommu/arm-smmu-v3: Free MSIs in case of ENOMEM
    
    [ Upstream commit 80fea979dd9d48d67c5b48d2f690c5da3e543ebd ]
    
    If devm_add_action() returns -ENOMEM, then MSIs are allocated but not
    not freed on teardown. Use devm_add_action_or_reset() instead to keep
    the static analyser happy.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Aleksandr Aprelkov <aaprelkov@usergate.com>
    Link: https://lore.kernel.org/r/20240403053759.643164-1-aaprelkov@usergate.com
    [will: Tweak commit message, remove warning message]
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu: Return right value in iommu_sva_bind_device() [+ + +]
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Tue May 28 12:25:28 2024 +0800

    iommu: Return right value in iommu_sva_bind_device()
    
    [ Upstream commit 89e8a2366e3bce584b6c01549d5019c5cda1205e ]
    
    iommu_sva_bind_device() should return either a sva bond handle or an
    ERR_PTR value in error cases. Existing drivers (idxd and uacce) only
    check the return value with IS_ERR(). This could potentially lead to
    a kernel NULL pointer dereference issue if the function returns NULL
    instead of an error pointer.
    
    In reality, this doesn't cause any problems because iommu_sva_bind_device()
    only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.
    In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will
    return an error, and the device drivers won't call iommu_sva_bind_device()
    at all.
    
    Fixes: 26b25a2b98e4 ("iommu: Bind process address spaces to devices")
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
    Link: https://lore.kernel.org/r/20240528042528.71396-1-baolu.lu@linux.intel.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ionic: fix use after netif_napi_del() [+ + +]
Author: Taehee Yoo <ap420073@gmail.com>
Date:   Wed Jun 12 06:04:46 2024 +0000

    ionic: fix use after netif_napi_del()
    
    [ Upstream commit 79f18a41dd056115d685f3b0a419c7cd40055e13 ]
    
    When queues are started, netif_napi_add() and napi_enable() are called.
    If there are 4 queues and only 3 queues are used for the current
    configuration, only 3 queues' napi should be registered and enabled.
    The ionic_qcq_enable() checks whether the .poll pointer is not NULL for
    enabling only the using queue' napi. Unused queues' napi will not be
    registered by netif_napi_add(), so the .poll pointer indicates NULL.
    But it couldn't distinguish whether the napi was unregistered or not
    because netif_napi_del() doesn't reset the .poll pointer to NULL.
    So, ionic_qcq_enable() calls napi_enable() for the queue, which was
    unregistered by netif_napi_del().
    
    Reproducer:
       ethtool -L <interface name> rx 1 tx 1 combined 0
       ethtool -L <interface name> rx 0 tx 0 combined 1
       ethtool -L <interface name> rx 0 tx 0 combined 4
    
    Splat looks like:
    kernel BUG at net/core/dev.c:6666!
    Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16
    Workqueue: events ionic_lif_deferred_work [ionic]
    RIP: 0010:napi_enable+0x3b/0x40
    Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f
    RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029
    RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28
    RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001
    R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
    R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20
    FS:  0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? die+0x33/0x90
     ? do_trap+0xd9/0x100
     ? napi_enable+0x3b/0x40
     ? do_error_trap+0x83/0xb0
     ? napi_enable+0x3b/0x40
     ? napi_enable+0x3b/0x40
     ? exc_invalid_op+0x4e/0x70
     ? napi_enable+0x3b/0x40
     ? asm_exc_invalid_op+0x16/0x20
     ? napi_enable+0x3b/0x40
     ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
     ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
     ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
     ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
     process_one_work+0x145/0x360
     worker_thread+0x2bb/0x3d0
     ? __pfx_worker_thread+0x10/0x10
     kthread+0xcc/0x100
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x2d/0x50
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1a/0x30
    
    Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling")
    Signed-off-by: Taehee Yoo <ap420073@gmail.com>
    Reviewed-by: Brett Creeley <brett.creeley@amd.com>
    Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
    Link: https://lore.kernel.org/r/20240612060446.1754392-1-ap420073@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: annotate some data-races around sk->sk_prot [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 17 15:48:41 2022 -0800

    ipv6: annotate some data-races around sk->sk_prot
    
    commit 086d49058cd8471046ae9927524708820f5fd1c7 upstream.
    
    IPv6 has this hack changing sk->sk_prot when an IPv6 socket
    is 'converted' to an IPv4 one with IPV6_ADDRFORM option.
    
    This operation is only performed for TCP and UDP, knowing
    their 'struct proto' for the two network families are populated
    in the same way, and can not disappear while a reader
    might use and dereference sk->sk_prot.
    
    If we think about it all reads of sk->sk_prot while
    either socket lock or RTNL is not acquired should be using READ_ONCE().
    
    Also note that other layers like MPTCP, XFRM, CHELSIO_TLS also
    write over sk->sk_prot.
    
    BUG: KCSAN: data-race in inet6_recvmsg / ipv6_setsockopt
    
    write to 0xffff8881386f7aa8 of 8 bytes by task 26932 on cpu 0:
     do_ipv6_setsockopt net/ipv6/ipv6_sockglue.c:492 [inline]
     ipv6_setsockopt+0x3758/0x3910 net/ipv6/ipv6_sockglue.c:1019
     udpv6_setsockopt+0x85/0x90 net/ipv6/udp.c:1649
     sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3489
     __sys_setsockopt+0x209/0x2a0 net/socket.c:2180
     __do_sys_setsockopt net/socket.c:2191 [inline]
     __se_sys_setsockopt net/socket.c:2188 [inline]
     __x64_sys_setsockopt+0x62/0x70 net/socket.c:2188
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    read to 0xffff8881386f7aa8 of 8 bytes by task 26911 on cpu 1:
     inet6_recvmsg+0x7a/0x210 net/ipv6/af_inet6.c:659
     ____sys_recvmsg+0x16c/0x320
     ___sys_recvmsg net/socket.c:2674 [inline]
     do_recvmmsg+0x3f5/0xae0 net/socket.c:2768
     __sys_recvmmsg net/socket.c:2847 [inline]
     __do_sys_recvmmsg net/socket.c:2870 [inline]
     __se_sys_recvmmsg net/socket.c:2863 [inline]
     __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2863
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    value changed: 0xffffffff85e0e980 -> 0xffffffff85e01580
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 26911 Comm: syz-executor.3 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipv6: Fix data races around sk->sk_prot. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu Oct 6 11:53:48 2022 -0700

    ipv6: Fix data races around sk->sk_prot.
    
    commit 364f997b5cfe1db0d63a390fe7c801fa2b3115f6 upstream.
    
    Commit 086d49058cd8 ("ipv6: annotate some data-races around sk->sk_prot")
    fixed some data-races around sk->sk_prot but it was not enough.
    
    Some functions in inet6_(stream|dgram)_ops still access sk->sk_prot
    without lock_sock() or rtnl_lock(), so they need READ_ONCE() to avoid
    load tearing.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipv6: fix possible race in __fib6_drop_pcpu_from() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 4 19:35:49 2024 +0000

    ipv6: fix possible race in __fib6_drop_pcpu_from()
    
    [ Upstream commit b01e1c030770ff3b4fe37fc7cc6bca03f594133f ]
    
    syzbot found a race in __fib6_drop_pcpu_from() [1]
    
    If compiler reads more than once (*ppcpu_rt),
    second read could read NULL, if another cpu clears
    the value in rt6_get_pcpu_route().
    
    Add a READ_ONCE() to prevent this race.
    
    Also add rcu_read_lock()/rcu_read_unlock() because
    we rely on RCU protection while dereferencing pcpu_rt.
    
    [1]
    
    Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI
    KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
    CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
    Workqueue: netns cleanup_net
     RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984
    Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48
    RSP: 0018:ffffc900040df070 EFLAGS: 00010206
    RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16
    RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091
    RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007
    R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8
    R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001
    FS:  0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
      __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]
      fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]
      fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038
      fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]
      fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043
      fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205
      fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127
      fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175
      fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255
      __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271
      rt6_sync_down_dev net/ipv6/route.c:4906 [inline]
      rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911
      addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855
      addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778
      notifier_call_chain+0xb9/0x410 kernel/notifier.c:93
      call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992
      call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]
      call_netdevice_notifiers net/core/dev.c:2044 [inline]
      dev_close_many+0x333/0x6a0 net/core/dev.c:1585
      unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193
      unregister_netdevice_many net/core/dev.c:11276 [inline]
      default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759
      ops_exit_list+0x128/0x180 net/core/net_namespace.c:178
      cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640
      process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
      process_scheduled_works kernel/workqueue.c:3312 [inline]
      worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
      kthread+0x2c1/0x3a0 kernel/kthread.c:389
      ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
      ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
    
    Fixes: d52d3997f843 ("ipv6: Create percpu rt6_info")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Link: https://lore.kernel.org/r/20240604193549.981839-1-edumazet@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: prevent possible NULL deref in fib6_nh_init() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jun 14 08:20:02 2024 +0000

    ipv6: prevent possible NULL deref in fib6_nh_init()
    
    [ Upstream commit 2eab4543a2204092c3a7af81d7d6c506e59a03a6 ]
    
    syzbot reminds us that in6_dev_get() can return NULL.
    
    fib6_nh_init()
        ip6_validate_gw(  &idev  )
            ip6_route_check_nh(  idev  )
                *idev = in6_dev_get(dev); // can be NULL
    
    Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
    KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
    CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
     RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606
    Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b
    RSP: 0018:ffffc900032775a0 EFLAGS: 00010202
    RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000
    RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8
    RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000
    R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8
    R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000
    FS:  00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
      ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809
      ip6_route_add+0x28/0x160 net/ipv6/route.c:3853
      ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483
      inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579
      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:907 [inline]
      __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f940f07cea9
    
    Fixes: 428604fb118f ("ipv6: do not set routes if disable_ipv6 has been enabled")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20240614082002.26407-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: prevent possible NULL dereference in rt6_probe() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Jun 15 15:14:54 2024 +0000

    ipv6: prevent possible NULL dereference in rt6_probe()
    
    [ Upstream commit b86762dbe19a62e785c189f313cda5b989931f37 ]
    
    syzbot caught a NULL dereference in rt6_probe() [1]
    
    Bail out if  __in6_dev_get() returns NULL.
    
    [1]
    Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI
    KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]
    CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
     RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]
     RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758
    Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19
    RSP: 0018:ffffc900034af070 EFLAGS: 00010203
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000
    RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c
    RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a
    R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000
    FS:  00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
      rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784
      nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496
      __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825
      find_rr_leaf net/ipv6/route.c:853 [inline]
      rt6_select net/ipv6/route.c:897 [inline]
      fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195
      ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231
      pol_lookup_func include/net/ip6_fib.h:616 [inline]
      fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121
      ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]
      ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651
      ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147
      ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250
      rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898
      inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg net/socket.c:745 [inline]
      sock_write_iter+0x4b8/0x5c0 net/socket.c:1160
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0x6b6/0x1140 fs/read_write.c:590
      ksys_write+0x1f8/0x260 fs/read_write.c:643
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Fixes: 52e1635631b3 ("[IPV6]: ROUTE: Add router_probe_interval sysctl.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20240615151454.166404-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: sr: block BH in seg6_output_core() and seg6_input_core() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 31 13:26:34 2024 +0000

    ipv6: sr: block BH in seg6_output_core() and seg6_input_core()
    
    [ Upstream commit c0b98ac1cc104f48763cdb27b1e9ac25fd81fc90 ]
    
    As explained in commit 1378817486d6 ("tipc: block BH
    before using dst_cache"), net/core/dst_cache.c
    helpers need to be called with BH disabled.
    
    Disabling preemption in seg6_output_core() is not good enough,
    because seg6_output_core() is called from process context,
    lwtunnel_output() only uses rcu_read_lock().
    
    We might be interrupted by a softirq, re-enter seg6_output_core()
    and corrupt dst_cache data structures.
    
    Fix the race by using local_bh_disable() instead of
    preempt_disable().
    
    Apply a similar change in seg6_input_core().
    
    Fixes: fa79581ea66c ("ipv6: sr: fix several BUGs when preemption is enabled")
    Fixes: 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: David Lebrun <dlebrun@google.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/20240531132636.2637995-4-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
jfs: xattr: fix buffer overflow for invalid xattr [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue May 14 12:06:34 2024 +0200

    jfs: xattr: fix buffer overflow for invalid xattr
    
    commit 7c55b78818cfb732680c4a72ab270cc2d2ee3d0f upstream.
    
    When an xattr size is not what is expected, it is printed out to the
    kernel log in hex format as a form of debugging.  But when that xattr
    size is bigger than the expected size, printing it out can cause an
    access off the end of the buffer.
    
    Fix this all up by properly restricting the size of the debug hex dump
    in the kernel log.
    
    Reported-by: syzbot+9dfe490c8176301c1d06@syzkaller.appspotmail.com
    Cc: Dave Kleikamp <shaggy@kernel.org>
    Link: https://lore.kernel.org/r/2024051433-slider-cloning-98f9@gregkh
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kbuild: Install dtb files as 0644 in Makefile.dtbinst [+ + +]
Author: Dragan Simic <dsimic@manjaro.org>
Date:   Mon Jun 10 07:21:12 2024 +0200

    kbuild: Install dtb files as 0644 in Makefile.dtbinst
    
    commit 9cc5f3bf63aa98bd7cc7ce8a8599077fde13283e upstream.
    
    The compiled dtb files aren't executable, so install them with 0644 as their
    permission mode, instead of defaulting to 0755 for the permission mode and
    installing them with the executable bits set.
    
    Some Linux distributions, including Debian, [1][2][3] already include fixes
    in their kernel package build recipes to change the dtb file permissions to
    0644 in their kernel packages.  These changes, when additionally propagated
    into the long-term kernel versions, will allow such distributions to remove
    their downstream fixes.
    
    [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/642
    [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/749
    [3] https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.8.12-1/debian/rules.real#L193
    
    Cc: Diederik de Haas <didi.debian@cknow.org>
    Cc: <stable@vger.kernel.org>
    Fixes: aefd80307a05 ("kbuild: refactor Makefile.dtbinst more")
    Signed-off-by: Dragan Simic <dsimic@manjaro.org>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kbuild: Remove support for Clang's ThinLTO caching [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed May 1 15:55:25 2024 -0700

    kbuild: Remove support for Clang's ThinLTO caching
    
    commit aba091547ef6159d52471f42a3ef531b7b660ed8 upstream.
    
    There is an issue in clang's ThinLTO caching (enabled for the kernel via
    '--thinlto-cache-dir') with .incbin, which the kernel occasionally uses
    to include data within the kernel, such as the .config file for
    /proc/config.gz. For example, when changing the .config and rebuilding
    vmlinux, the copy of .config in vmlinux does not match the copy of
    .config in the build folder:
    
      $ echo 'CONFIG_LTO_NONE=n
      CONFIG_LTO_CLANG_THIN=y
      CONFIG_IKCONFIG=y
      CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config
    
      $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux
      ...
    
      $ grep CONFIG_HEADERS_INSTALL .config
      CONFIG_HEADERS_INSTALL=y
    
      $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
      CONFIG_HEADERS_INSTALL=y
    
      $ scripts/config -d HEADERS_INSTALL
    
      $ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux
      ...
        UPD     kernel/config_data
        GZIP    kernel/config_data.gz
        CC      kernel/configs.o
      ...
        LD      vmlinux
      ...
    
      $ grep CONFIG_HEADERS_INSTALL .config
      # CONFIG_HEADERS_INSTALL is not set
    
      $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
      CONFIG_HEADERS_INSTALL=y
    
    Without '--thinlto-cache-dir' or when using full LTO, this issue does
    not occur.
    
    Benchmarking incremental builds on a few different machines with and
    without the cache shows a 20% increase in incremental build time without
    the cache when measured by touching init/main.c and running 'make all'.
    
    ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host:
    
      Benchmark 1: With ThinLTO cache
        Time (mean ± σ):     56.347 s ±  0.163 s    [User: 83.768 s, System: 24.661 s]
        Range (min … max):   56.109 s … 56.594 s    10 runs
    
      Benchmark 2: Without ThinLTO cache
        Time (mean ± σ):     67.740 s ±  0.479 s    [User: 718.458 s, System: 31.797 s]
        Range (min … max):   67.059 s … 68.556 s    10 runs
    
      Summary
        With ThinLTO cache ran
          1.20 ± 0.01 times faster than Without ThinLTO cache
    
    ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host:
    
      Benchmark 1: With ThinLTO cache
        Time (mean ± σ):     85.772 s ±  0.252 s    [User: 91.505 s, System: 8.408 s]
        Range (min … max):   85.447 s … 86.244 s    10 runs
    
      Benchmark 2: Without ThinLTO cache
        Time (mean ± σ):     103.833 s ±  0.288 s    [User: 232.058 s, System: 8.569 s]
        Range (min … max):   103.286 s … 104.124 s    10 runs
    
      Summary
        With ThinLTO cache ran
          1.21 ± 0.00 times faster than Without ThinLTO cache
    
    While it is unfortunate to take this performance improvement off the
    table, correctness is more important. If/when this is fixed in LLVM, it
    can potentially be brought back in a conditional manner. Alternatively,
    a developer can just disable LTO if doing incremental compiles quickly
    is important, as a full compile cycle can still take over a minute even
    with the cache and it is unlikely that LTO will result in functional
    differences for a kernel change.
    
    Cc: stable@vger.kernel.org
    Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO")
    Reported-by: Yifan Hong <elsk@google.com>
    Closes: https://github.com/ClangBuiltLinux/linux/issues/2021
    Reported-by: Masami Hiramatsu <mhiramat@kernel.org>
    Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.org/
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    [nathan: Address conflict in Makefile]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kcov: don't lose track of remote references during softirqs [+ + +]
Author: Aleksandr Nogikh <nogikh@google.com>
Date:   Tue Jun 11 15:32:29 2024 +0200

    kcov: don't lose track of remote references during softirqs
    
    commit 01c8f9806bde438ca1c8cbbc439f0a14a6694f6c upstream.
    
    In kcov_remote_start()/kcov_remote_stop(), we swap the previous KCOV
    metadata of the current task into a per-CPU variable.  However, the
    kcov_mode_enabled(mode) check is not sufficient in the case of remote KCOV
    coverage: current->kcov_mode always remains KCOV_MODE_DISABLED for remote
    KCOV objects.
    
    If the original task that has invoked the KCOV_REMOTE_ENABLE ioctl happens
    to get interrupted and kcov_remote_start() is called, it ultimately leads
    to kcov_remote_stop() NOT restoring the original KCOV reference.  So when
    the task exits, all registered remote KCOV handles remain active forever.
    
    The most uncomfortable effect (at least for syzkaller) is that the bug
    prevents the reuse of the same /sys/kernel/debug/kcov descriptor.  If
    we obtain it in the parent process and then e.g.  drop some
    capabilities and continuously fork to execute individual programs, at
    some point current->kcov of the forked process is lost,
    kcov_task_exit() takes no action, and all KCOV_REMOTE_ENABLE ioctls
    calls from subsequent forks fail.
    
    And, yes, the efficiency is also affected if we keep on losing remote
    kcov objects.
    a) kcov_remote_map keeps on growing forever.
    b) (If I'm not mistaken), we're also not freeing the memory referenced
    by kcov->area.
    
    Fix it by introducing a special kcov_mode that is assigned to the task
    that owns a KCOV remote object.  It makes kcov_mode_enabled() return true
    and yet does not trigger coverage collection in __sanitizer_cov_trace_pc()
    and write_comp_data().
    
    [nogikh@google.com: replace WRITE_ONCE() with an ordinary assignment]
      Link: https://lkml.kernel.org/r/20240614171221.2837584-1-nogikh@google.com
    Link: https://lkml.kernel.org/r/20240611133229.527822-1-nogikh@google.com
    Fixes: 5ff3b30ab57d ("kcov: collect coverage from interrupts")
    Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
    Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
    Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
    Tested-by: Andrey Konovalov <andreyknvl@gmail.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Marco Elver <elver@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kheaders: explicitly define file modes for archived headers [+ + +]
Author: Matthias Maennich <maennich@google.com>
Date:   Tue May 28 11:32:43 2024 +0000

    kheaders: explicitly define file modes for archived headers
    
    [ Upstream commit 3bd27a847a3a4827a948387cc8f0dbc9fa5931d5 ]
    
    Build environments might be running with different umask settings
    resulting in indeterministic file modes for the files contained in
    kheaders.tar.xz. The file itself is served with 444, i.e. world
    readable. Archive the files explicitly with 744,a+X to improve
    reproducibility across build environments.
    
    --mode=0444 is not suitable as directories need to be executable. Also,
    444 makes it hard to delete all the readonly files after extraction.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Matthias Maennich <maennich@google.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
knfsd: LOOKUP can return an illegal error value [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon May 6 12:30:04 2024 -0400

    knfsd: LOOKUP can return an illegal error value
    
    commit e221c45da3770962418fb30c27d941bbc70d595a upstream.
    
    The 'NFS error' NFSERR_OPNOTSUPP is not described by any of the official
    NFS related RFCs, but appears to have snuck into some older .x files for
    NFSv2.
    Either way, it is not in RFC1094, RFC1813 or any of the NFSv4 RFCs, so
    should not be returned by the knfsd server, and particularly not by the
    "LOOKUP" operation.
    
    Instead, let's return NFSERR_STALE, which is more appropriate if the
    filesystem encodes the filehandle as FILEID_INVALID.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kselftest: arm64: Add a null pointer check [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Tue Apr 23 16:21:02 2024 +0800

    kselftest: arm64: Add a null pointer check
    
    [ Upstream commit 80164282b3620a3cb73de6ffda5592743e448d0e ]
    
    There is a 'malloc' call, which can be unsuccessful.
    This patch will add the malloc failure checking
    to avoid possible null dereference and give more information
    about test fail reasons.
    
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Link: https://lore.kernel.org/r/20240423082102.2018886-1-chentao@kylinos.cn
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

 
KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Thu Jul 13 08:06:57 2023 +0100

    KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption
    
    commit b321c31c9b7b309dcde5e8854b741c8e6a9a05f0 upstream.
    
    Xiang reports that VMs occasionally fail to boot on GICv4.1 systems when
    running a preemptible kernel, as it is possible that a vCPU is blocked
    without requesting a doorbell interrupt.
    
    The issue is that any preemption that occurs between vgic_v4_put() and
    schedule() on the block path will mark the vPE as nonresident and *not*
    request a doorbell irq. This occurs because when the vcpu thread is
    resumed on its way to block, vcpu_load() will make the vPE resident
    again. Once the vcpu actually blocks, we don't request a doorbell
    anymore, and the vcpu won't be woken up on interrupt delivery.
    
    Fix it by tracking that we're entering WFI, and key the doorbell
    request on that flag. This allows us not to make the vPE resident
    when going through a preempt/schedule cycle, meaning we don't lose
    any state.
    
    Cc: stable@vger.kernel.org
    Fixes: 8e01d9a396e6 ("KVM: arm64: vgic-v4: Move the GICv4 residency flow to be driven by vcpu_load/put")
    Reported-by: Xiang Chen <chenxiang66@hisilicon.com>
    Suggested-by: Zenghui Yu <yuzenghui@huawei.com>
    Tested-by: Xiang Chen <chenxiang66@hisilicon.com>
    Co-developed-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Zenghui Yu <yuzenghui@huawei.com>
    Link: https://lore.kernel.org/r/20230713070657.3873244-1-maz@kernel.org
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    [ modified to wrangle the vCPU flags directly instead of going through
      the flag helper macros as they have not yet been introduced. Also doing
      the flag wranging in the kvm_arch_vcpu_{un}blocking() hooks as the
      introduction of kvm_vcpu_wfi has not yet happened. See:
      6109c5a6ab7f ("KVM: arm64: Move vGIC v4 handling for WFI out arch callback hook") ]
    Signed-off-by: James Gowans <jgowans@amazon.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: x86: Always sync PIR to IRR prior to scanning I/O APIC routes [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Mon Jun 10 18:48:45 2024 -0700

    KVM: x86: Always sync PIR to IRR prior to scanning I/O APIC routes
    
    commit f3ced000a2df53f4b12849e121769045a81a3b22 upstream.
    
    Sync pending posted interrupts to the IRR prior to re-scanning I/O APIC
    routes, irrespective of whether the I/O APIC is emulated by userspace or
    by KVM.  If a level-triggered interrupt routed through the I/O APIC is
    pending or in-service for a vCPU, KVM needs to intercept EOIs on said
    vCPU even if the vCPU isn't the destination for the new routing, e.g. if
    servicing an interrupt using the old routing races with I/O APIC
    reconfiguration.
    
    Commit fceb3a36c29a ("KVM: x86: ioapic: Fix level-triggered EOI and
    userspace I/OAPIC reconfigure race") fixed the common cases, but
    kvm_apic_pending_eoi() only checks if an interrupt is in the local
    APIC's IRR or ISR, i.e. misses the uncommon case where an interrupt is
    pending in the PIR.
    
    Failure to intercept EOI can manifest as guest hangs with Windows 11 if
    the guest uses the RTC as its timekeeping source, e.g. if the VMM doesn't
    expose a more modern form of time to the guest.
    
    Cc: stable@vger.kernel.org
    Cc: Adamos Ttofari <attofari@amazon.de>
    Cc: Raghavendra Rao Ananta <rananta@google.com>
    Reviewed-by: Jim Mattson <jmattson@google.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-ID: <20240611014845.82795-1-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 5.15.162 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Jul 5 09:14:52 2024 +0200

    Linux 5.15.162
    
    Link: https://lore.kernel.org/r/20240703102913.093882413@linuxfoundation.org
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Wed Jun 5 13:11:35 2024 +0300

    liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
    
    [ Upstream commit c44711b78608c98a3e6b49ce91678cd0917d5349 ]
    
    In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,
    but then it is unconditionally passed to skb_add_rx_frag() which looks
    strange and could lead to null pointer dereference.
    
    lio_vf_rep_copy_packet() call trace looks like:
            octeon_droq_process_packets
             octeon_droq_fast_process_packets
              octeon_droq_dispatch_pkt
               octeon_create_recv_info
                ...search in the dispatch_list...
                 ->disp_fn(rdisp->rinfo, ...)
                  lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)
    In this path there is no code which sets pg_info->page to NULL.
    So this check looks unneeded and doesn't solve potential problem.
    But I guess the author had reason to add a check and I have no such card
    and can't do real test.
    In addition, the code in the function liquidio_push_packet() in
    liquidio/lio_core.c does exactly the same.
    
    Based on this, I consider the most acceptable compromise solution to
    adjust this issue by moving skb_add_rx_frag() into conditional scope.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 1f233f327913 ("liquidio: switchdev support for LiquidIO NIC")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: dvbdev: Initialize sbuf [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Mon Mar 25 14:50:25 2024 +0000

    media: dvbdev: Initialize sbuf
    
    [ Upstream commit 17d1316de0d7dc1bdc5d6e3ad4efd30a9bf1a381 ]
    
    Because the size passed to copy_from_user() cannot be known beforehand,
    it needs to be checked during runtime with check_object_size. That makes
    gcc believe that the content of sbuf can be used before init.
    
    Fix:
    ./include/linux/thread_info.h:215:17: warning: ‘sbuf’ may be used uninitialized [-Wmaybe-uninitialized]
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mei: me: release irq in mei_me_pci_resume error path [+ + +]
Author: Tomas Winkler <tomas.winkler@intel.com>
Date:   Tue Jun 4 12:07:28 2024 +0300

    mei: me: release irq in mei_me_pci_resume error path
    
    commit 283cb234ef95d94c61f59e1cd070cd9499b51292 upstream.
    
    The mei_me_pci_resume doesn't release irq on the error path,
    in case mei_start() fails.
    
    Cc: <stable@kernel.org>
    Fixes: 33ec08263147 ("mei: revamp mei reset state machine")
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20240604090728.1027307-1-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mips: bmips: BCM6358: make sure CBR is correctly set [+ + +]
Author: Christian Marangi <ansuelsmth@gmail.com>
Date:   Tue Jun 11 13:35:33 2024 +0200

    mips: bmips: BCM6358: make sure CBR is correctly set
    
    [ Upstream commit ce5cdd3b05216b704a704f466fb4c2dff3778caf ]
    
    It was discovered that some device have CBR address set to 0 causing
    kernel panic when arch_sync_dma_for_cpu_all is called.
    
    This was notice in situation where the system is booted from TP1 and
    BMIPS_GET_CBR() returns 0 instead of a valid address and
    !!(read_c0_brcm_cmt_local() & (1 << 31)); not failing.
    
    The current check whether RAC flush should be disabled or not are not
    enough hence lets check if CBR is a valid address or not.
    
    Fixes: ab327f8acdf8 ("mips: bmips: BCM6358: disable RAC flush for TP1")
    Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
    Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: Octeon: Add PCIe link status check [+ + +]
Author: Songyang Li <leesongyang@outlook.com>
Date:   Wed Mar 20 23:22:00 2024 +0800

    MIPS: Octeon: Add PCIe link status check
    
    [ Upstream commit 29b83a64df3b42c88c0338696feb6fdcd7f1f3b7 ]
    
    The standard PCIe configuration read-write interface is used to
    access the configuration space of the peripheral PCIe devices
    of the mips processor after the PCIe link surprise down, it can
    generate kernel panic caused by "Data bus error". So it is
    necessary to add PCIe link status check for system protection.
    When the PCIe link is down or in training, assigning a value
    of 0 to the configuration address can prevent read-write behavior
    to the configuration space of peripheral PCIe devices, thereby
    preventing kernel panic.
    
    Signed-off-by: Songyang Li <leesongyang@outlook.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

MIPS: Routerboard 532: Fix vendor retry check code [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Wed May 8 15:07:00 2024 +0300

    MIPS: Routerboard 532: Fix vendor retry check code
    
    [ Upstream commit ae9daffd9028f2500c9ac1517e46d4f2b57efb80 ]
    
    read_config_dword() contains strange condition checking ret for a
    number of values. The ret variable, however, is always zero because
    config_access() never returns anything else. Thus, the retry is always
    taken until number of tries is exceeded.
    
    The code looks like it wants to check *val instead of ret to see if the
    read gave an error response.
    
    Fixes: 73b4390fb234 ("[MIPS] Routerboard 532: Support for base system")
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

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

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

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

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

 
mm/cma: drop incorrect alignment check in cma_init_reserved_mem [+ + +]
Author: Frank van der Linden <fvdl@google.com>
Date:   Thu Apr 4 16:25:14 2024 +0000

    mm/cma: drop incorrect alignment check in cma_init_reserved_mem
    
    [ Upstream commit b174f139bdc8aaaf72f5b67ad1bd512c4868a87e ]
    
    cma_init_reserved_mem uses IS_ALIGNED to check if the size represented by
    one bit in the cma allocation bitmask is aligned with
    CMA_MIN_ALIGNMENT_BYTES (pageblock size).
    
    However, this is too strict, as this will fail if order_per_bit >
    pageblock_order, which is a valid configuration.
    
    We could check IS_ALIGNED both ways, but since both numbers are powers of
    two, no check is needed at all.
    
    Link: https://lkml.kernel.org/r/20240404162515.527802-1-fvdl@google.com
    Fixes: de9e14eebf33 ("drivers: dma-contiguous: add initialization from device tree")
    Signed-off-by: Frank van der Linden <fvdl@google.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Marek Szyprowski <m.szyprowski@samsung.com>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: Roman Gushchin <roman.gushchin@linux.dev>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/huge_memory: don't unpoison huge_zero_folio [+ + +]
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Thu May 16 20:26:08 2024 +0800

    mm/huge_memory: don't unpoison huge_zero_folio
    
    commit fe6f86f4b40855a130a19aa589f9ba7f650423f4 upstream.
    
    When I did memory failure tests recently, below panic occurs:
    
     kernel BUG at include/linux/mm.h:1135!
     invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
     CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14
     RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0
     RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246
     RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8
     RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0
     RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492
     R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000
     R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00
     FS:  0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0
     Call Trace:
      <TASK>
      do_shrink_slab+0x14f/0x6a0
      shrink_slab+0xca/0x8c0
      shrink_node+0x2d0/0x7d0
      balance_pgdat+0x33a/0x720
      kswapd+0x1f3/0x410
      kthread+0xd5/0x100
      ret_from_fork+0x2f/0x50
      ret_from_fork_asm+0x1a/0x30
      </TASK>
     Modules linked in: mce_inject hwpoison_inject
     ---[ end trace 0000000000000000 ]---
     RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0
     RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246
     RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8
     RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0
     RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492
     R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000
     R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00
     FS:  0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0
    
    The root cause is that HWPoison flag will be set for huge_zero_folio
    without increasing the folio refcnt.  But then unpoison_memory() will
    decrease the folio refcnt unexpectedly as it appears like a successfully
    hwpoisoned folio leading to VM_BUG_ON_PAGE(page_ref_count(page) == 0) when
    releasing huge_zero_folio.
    
    Skip unpoisoning huge_zero_folio in unpoison_memory() to fix this issue.
    We're not prepared to unpoison huge_zero_folio yet.
    
    Link: https://lkml.kernel.org/r/20240516122608.22610-1-linmiaohe@huawei.com
    Fixes: 478d134e9506 ("mm/huge_memory: do not overkill when splitting huge_zero_page")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Yang Shi <shy828301@gmail.com>
    Reviewed-by: Oscar Salvador <osalvador@suse.de>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
    Cc: Xu Yu <xuyu@linux.alibaba.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    mmc: davinci: Don't strip remove function when driver is builtin
    
    [ Upstream commit 55c421b364482b61c4c45313a535e61ed5ae4ea3 ]
    
    Using __exit for the remove function results in the remove callback being
    discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.
    using sysfs or hotplug), the driver is just removed without the cleanup
    being performed. This results in resource leaks. Fix it by compiling in the
    remove callback unconditionally.
    
    This also fixes a W=1 modpost warning:
    
    WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in
    reference: davinci_mmcsd_driver+0x10 (section: .data) ->
    davinci_mmcsd_remove (section: .exit.text)
    
    Fixes: b4cff4549b7a ("DaVinci: MMC: MMC/SD controller driver for DaVinci family")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240324114017.231936-2-u.kleine-koenig@pengutronix.de
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: davinci_mmc: Convert to platform remove callback returning void [+ + +]
Author: Yangtao Li <frank.li@vivo.com>
Date:   Thu Jul 27 14:59:56 2023 +0800

    mmc: davinci_mmc: Convert to platform remove callback returning void
    
    [ Upstream commit bc1711e8332da03648d8fe1950189237e66313af ]
    
    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.
    
    Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Yangtao Li <frank.li@vivo.com>
    Link: https://lore.kernel.org/r/20230727070051.17778-7-frank.li@vivo.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Stable-dep-of: 55c421b36448 ("mmc: davinci: Don't strip remove function when driver is builtin")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci-pci: Convert PCIBIOS_* return codes to errnos [+ + +]
Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Date:   Mon May 27 16:24:41 2024 +0300

    mmc: sdhci-pci: Convert PCIBIOS_* return codes to errnos
    
    commit ebc4fc34eae8ddfbef49f2bdaced1bf4167ef80d upstream.
    
    jmicron_pmos() and sdhci_pci_probe() use pci_{read,write}_config_byte()
    that return PCIBIOS_* codes. The return code is then returned as is by
    jmicron_probe() and sdhci_pci_probe(). Similarly, the return code is
    also returned as is from jmicron_resume(). Both probe and resume
    functions should return normal errnos.
    
    Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal
    errno before returning them the fix these issues.
    
    Fixes: 7582041ff3d4 ("mmc: sdhci-pci: fix simple_return.cocci warnings")
    Fixes: 45211e215984 ("sdhci: toggle JMicron PMOS setting")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/20240527132443.14038-1-ilpo.jarvinen@linux.intel.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: sdhci: Do not invert write-protect twice [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri Jun 14 11:00:49 2024 +0300

    mmc: sdhci: Do not invert write-protect twice
    
    commit fbd64f902b93fe9658b855b9892ae59ef6ea22b9 upstream.
    
    mmc_of_parse() reads device property "wp-inverted" and sets
    MMC_CAP2_RO_ACTIVE_HIGH if it is true. MMC_CAP2_RO_ACTIVE_HIGH is used
    to invert a write-protect (AKA read-only) GPIO value.
    
    sdhci_get_property() also reads "wp-inverted" and sets
    SDHCI_QUIRK_INVERTED_WRITE_PROTECT which is used to invert the
    write-protect value as well but also acts upon a value read out from the
    SDHCI_PRESENT_STATE register.
    
    Many drivers call both mmc_of_parse() and sdhci_get_property(),
    so that both MMC_CAP2_RO_ACTIVE_HIGH and
    SDHCI_QUIRK_INVERTED_WRITE_PROTECT will be set if the controller has
    device property "wp-inverted".
    
    Amend the logic in sdhci_check_ro() to allow for that possibility,
    so that the write-protect value is not inverted twice.
    
    Also do not invert the value if it is a negative error value. Note that
    callers treat an error the same as not-write-protected, so the result is
    functionally the same in that case.
    
    Also do not invert the value if sdhci host operation ->get_ro() is used.
    None of the users of that callback set SDHCI_QUIRK_INVERTED_WRITE_PROTECT
    directly or indirectly, but two do call mmc_gpio_get_ro(), so leave it to
    them to deal with that if they ever set SDHCI_QUIRK_INVERTED_WRITE_PROTECT
    in the future.
    
    Fixes: 6d5cd068ee59 ("mmc: sdhci: use WP GPIO in sdhci_check_ro()")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240614080051.4005-2-adrian.hunter@intel.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: sdhci: Do not lock spinlock around mmc_gpio_get_ro() [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri Jun 14 11:00:50 2024 +0300

    mmc: sdhci: Do not lock spinlock around mmc_gpio_get_ro()
    
    commit ab069ce125965a5e282f7b53b86aee76ab32975c upstream.
    
    sdhci_check_ro() can call mmc_gpio_get_ro() while holding the sdhci
    host->lock spinlock. That would be a problem if the GPIO access done by
    mmc_gpio_get_ro() needed to sleep.
    
    However, host->lock is not needed anyway. The mmc core ensures that host
    operations do not race with each other, and asynchronous callbacks like the
    interrupt handler, software timeouts, completion work etc, cannot affect
    sdhci_check_ro().
    
    So remove the locking.
    
    Fixes: 6d5cd068ee59 ("mmc: sdhci: use WP GPIO in sdhci_check_ro()")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240614080051.4005-3-adrian.hunter@intel.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mptcp: ensure snd_una is properly initialized on connect [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Fri Jun 7 17:01:48 2024 +0200

    mptcp: ensure snd_una is properly initialized on connect
    
    commit 8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3 upstream.
    
    This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt
    is properly initialized on connect"). It turns out that syzkaller can
    trigger the retransmit after fallback and before processing any other
    incoming packet - so that snd_una is still left uninitialized.
    
    Address the issue explicitly initializing snd_una together with snd_nxt
    and write_seq.
    
    Suggested-by: Mat Martineau <martineau@kernel.org>
    Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect")
    Cc: stable@vger.kernel.org
    Reported-by: Christoph Paasch <cpaasch@apple.com>
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-1-1ab9ddfa3d00@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID [+ + +]
Author: YonglongLi <liyonglong@chinatelecom.cn>
Date:   Fri Jun 7 17:01:49 2024 +0200

    mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID
    
    commit 6a09788c1a66e3d8b04b3b3e7618cc817bb60ae9 upstream.
    
    The RmAddr MIB counter is supposed to be incremented once when a valid
    RM_ADDR has been received. Before this patch, it could have been
    incremented as many times as the number of subflows connected to the
    linked address ID, so it could have been 0, 1 or more than 1.
    
    The "RmSubflow" is incremented after a local operation. In this case,
    it is normal to tied it with the number of subflows that have been
    actually removed.
    
    The "remove invalid addresses" MP Join subtest has been modified to
    validate this case. A broadcast IP address is now used instead: the
    client will not be able to create a subflow to this address. The
    consequence is that when receiving the RM_ADDR with the ID attached to
    this broadcast IP address, no subflow linked to this ID will be found.
    
    Fixes: 7a7e52e38a40 ("mptcp: add RM_ADDR related mibs")
    Cc: stable@vger.kernel.org
    Co-developed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: YonglongLi <liyonglong@chinatelecom.cn>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-2-1ab9ddfa3d00@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in pm_netlink.c because the context has changed later in
      multiple commits linked to new features, e.g. commit 86e39e04482b
      ("mptcp: keep track of local endpoint still available for each msk"),
      commit a88c9e496937 ("mptcp: do not block subflows creation on errors")
      and commit 3ad14f54bd74 ("mptcp: more accurate MPC endpoint tracking"),
      but the independent lines that needed to be modified were still there.
      Conflicts in the selftests, because many features modifying the whole
      file have been added later, e.g. commit ae7bd9ccecc3 ("selftests:
      mptcp: join: option to execute specific tests"). The same
      modifications have been reported to the old code: simply changing the
      IP address and add a new comment. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mptcp: pm: update add_addr counters after connect [+ + +]
Author: YonglongLi <liyonglong@chinatelecom.cn>
Date:   Fri Jun 7 17:01:50 2024 +0200

    mptcp: pm: update add_addr counters after connect
    
    commit 40eec1795cc27b076d49236649a29507c7ed8c2d upstream.
    
    The creation of new subflows can fail for different reasons. If no
    subflow have been created using the received ADD_ADDR, the related
    counters should not be updated, otherwise they will never be decremented
    for events related to this ID later on.
    
    For the moment, the number of accepted ADD_ADDR is only decremented upon
    the reception of a related RM_ADDR, and only if the remote address ID is
    currently being used by at least one subflow. In other words, if no
    subflow can be created with the received address, the counter will not
    be decremented. In this case, it is then important not to increment
    pm.add_addr_accepted counter, and not to modify pm.accept_addr bit.
    
    Note that this patch does not modify the behaviour in case of failures
    later on, e.g. if the MP Join is dropped or rejected.
    
    The "remove invalid addresses" MP Join subtest has been modified to
    validate this case. The broadcast IP address is added before the "valid"
    address that will be used to successfully create a subflow, and the
    limit is decreased by one: without this patch, it was not possible to
    create the last subflow, because:
    
    - the broadcast address would have been accepted even if it was not
      usable: the creation of a subflow to this address results in an error,
    
    - the limit of 2 accepted ADD_ADDR would have then been reached.
    
    Fixes: 01cacb00b35c ("mptcp: add netlink-based PM")
    Cc: stable@vger.kernel.org
    Co-developed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: YonglongLi <liyonglong@chinatelecom.cn>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-3-1ab9ddfa3d00@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in pm_netlink.c because commit 12a18341b5c3 ("mptcp: send
      ADD_ADDR echo before create subflows") is not present in this version,
      and it changes the context, but not the block that needs to be moved.
      Conflicts in the selftests, because many features modifying the whole
      file have been added later, e.g. commit ae7bd9ccecc3 ("selftests:
      mptcp: join: option to execute specific tests"). The same
      modifications have been reported to the old code: simply moving one
      line, and changing the limits. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mtd: partitions: redboot: Added conversion of operands to a larger type [+ + +]
Author: Denis Arefev <arefev@swemel.ru>
Date:   Fri Mar 15 12:37:58 2024 +0300

    mtd: partitions: redboot: Added conversion of operands to a larger type
    
    [ Upstream commit 1162bc2f8f5de7da23d18aa4b7fbd4e93c369c50 ]
    
    The value of an arithmetic expression directory * master->erasesize is
    subject to overflow due to a failure to cast operands to a larger data
    type before perfroming arithmetic
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Denis Arefev <arefev@swemel.ru>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20240315093758.20790-1-arefev@swemel.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/dpaa2: Avoid explicit cpumask var allocation on stack [+ + +]
Author: Dawei Li <dawei.li@shingroup.cn>
Date:   Sun Mar 31 13:34:41 2024 +0800

    net/dpaa2: Avoid explicit cpumask var allocation on stack
    
    [ Upstream commit d33fe1714a44ff540629b149d8fab4ac6967585c ]
    
    For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
    variable on stack is not recommended since it can cause potential stack
    overflow.
    
    Instead, kernel code should always use *cpumask_var API(s) to allocate
    cpumask var in config-neutral way, leaving allocation strategy to
    CONFIG_CPUMASK_OFFSTACK.
    
    Use *cpumask_var API(s) to address it.
    
    Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
    Link: https://lore.kernel.org/r/20240331053441.1276826-3-dawei.li@shingroup.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/ipv6: Fix the RT cache flush via sysctl using a previous delay [+ + +]
Author: Petr Pavlu <petr.pavlu@suse.com>
Date:   Fri Jun 7 13:28:28 2024 +0200

    net/ipv6: Fix the RT cache flush via sysctl using a previous delay
    
    [ Upstream commit 14a20e5b4ad998793c5f43b0330d9e1388446cf3 ]
    
    The net.ipv6.route.flush system parameter takes a value which specifies
    a delay used during the flush operation for aging exception routes. The
    written value is however not used in the currently requested flush and
    instead utilized only in the next one.
    
    A problem is that ipv6_sysctl_rtcache_flush() first reads the old value
    of net->ipv6.sysctl.flush_delay into a local delay variable and then
    calls proc_dointvec() which actually updates the sysctl based on the
    provided input.
    
    Fix the problem by switching the order of the two operations.
    
    Fixes: 4990509f19e8 ("[NETNS][IPV6]: Make sysctls route per namespace.")
    Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20240607112828.30285-1-petr.pavlu@suse.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/iucv: Avoid explicit cpumask var allocation on stack [+ + +]
Author: Dawei Li <dawei.li@shingroup.cn>
Date:   Sun Mar 31 13:34:40 2024 +0800

    net/iucv: Avoid explicit cpumask var allocation on stack
    
    [ Upstream commit be4e1304419c99a164b4c0e101c7c2a756b635b9 ]
    
    For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
    variable on stack is not recommended since it can cause potential stack
    overflow.
    
    Instead, kernel code should always use *cpumask_var API(s) to allocate
    cpumask var in config-neutral way, leaving allocation strategy to
    CONFIG_CPUMASK_OFFSTACK.
    
    Use *cpumask_var API(s) to address it.
    
    Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
    Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240331053441.1276826-2-dawei.li@shingroup.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: Fix features validation check for tunneled UDP (non-VXLAN) packets [+ + +]
Author: Gal Pressman <gal@nvidia.com>
Date:   Thu Jun 6 23:32:49 2024 +0300

    net/mlx5e: Fix features validation check for tunneled UDP (non-VXLAN) packets
    
    [ Upstream commit 791b4089e326271424b78f2fae778b20e53d071b ]
    
    Move the vxlan_features_check() call to after we verified the packet is
    a tunneled VXLAN packet.
    
    Without this, tunneled UDP non-VXLAN packets (for ex. GENENVE) might
    wrongly not get offloaded.
    In some cases, it worked by chance as GENEVE header is the same size as
    VXLAN, but it is obviously incorrect.
    
    Fixes: e3cfc7e6b7bd ("net/mlx5e: TX, Add geneve tunnel stateless offload support")
    Signed-off-by: Gal Pressman <gal@nvidia.com>
    Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/ncsi: Fix the multi thread manner of NCSI driver [+ + +]
Author: DelphineCCChiu <delphine_cc_chiu@wiwynn.com>
Date:   Wed May 29 14:58:55 2024 +0800

    net/ncsi: Fix the multi thread manner of NCSI driver
    
    [ Upstream commit e85e271dec0270982afed84f70dc37703fcc1d52 ]
    
    Currently NCSI driver will send several NCSI commands back to back without
    waiting the response of previous NCSI command or timeout in some state
    when NIC have multi channel. This operation against the single thread
    manner defined by NCSI SPEC(section 6.3.2.3 in DSP0222_1.1.1)
    
    According to NCSI SPEC(section 6.2.13.1 in DSP0222_1.1.1), we should probe
    one channel at a time by sending NCSI commands (Clear initial state, Get
    version ID, Get capabilities...), than repeat this steps until the max
    number of channels which we got from NCSI command (Get capabilities) has
    been probed.
    
    Fixes: e6f44ed6d04d ("net/ncsi: Package and channel management")
    Signed-off-by: DelphineCCChiu <delphine_cc_chiu@wiwynn.com>
    Link: https://lore.kernel.org/r/20240529065856.825241-1-delphine_cc_chiu@wiwynn.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/ncsi: Simplify Kconfig/dts control flow [+ + +]
Author: Peter Delevoryas <peter@pjd.dev>
Date:   Tue Nov 14 10:07:33 2023 -0600

    net/ncsi: Simplify Kconfig/dts control flow
    
    [ Upstream commit c797ce168930ce3d62a9b7fc4d7040963ee6a01e ]
    
    Background:
    
    1. CONFIG_NCSI_OEM_CMD_KEEP_PHY
    
    If this is enabled, we send an extra OEM Intel command in the probe
    sequence immediately after discovering a channel (e.g. after "Clear
    Initial State").
    
    2. CONFIG_NCSI_OEM_CMD_GET_MAC
    
    If this is enabled, we send one of 3 OEM "Get MAC Address" commands from
    Broadcom, Mellanox (Nvidida), and Intel in the *configuration* sequence
    for a channel.
    
    3. mellanox,multi-host (or mlx,multi-host)
    
    Introduced by this patch:
    
    https://lore.kernel.org/all/20200108234341.2590674-1-vijaykhemka@fb.com/
    
    Which was actually originally from cosmo.chou@quantatw.com:
    
    https://github.com/facebook/openbmc-linux/commit/9f132a10ec48db84613519258cd8a317fb9c8f1b
    
    Cosmo claimed that the Nvidia ConnectX-4 and ConnectX-6 NIC's don't
    respond to Get Version ID, et. al in the probe sequence unless you send
    the Set MC Affinity command first.
    
    Problem Statement:
    
    We've been using a combination of #ifdef code blocks and IS_ENABLED()
    conditions to conditionally send these OEM commands.
    
    It makes adding any new code around these commands hard to understand.
    
    Solution:
    
    In this patch, I just want to remove the conditionally compiled blocks
    of code, and always use IS_ENABLED(...) to do dynamic control flow.
    
    I don't think the small amount of code this adds to non-users of the OEM
    Kconfigs is a big deal.
    
    Signed-off-by: Peter Delevoryas <peter@pjd.dev>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: e85e271dec02 ("net/ncsi: Fix the multi thread manner of NCSI driver")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc() [+ + +]
Author: David Ruth <druth@chromium.org>
Date:   Fri Jun 14 19:03:26 2024 +0000

    net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
    
    [ Upstream commit d864319871b05fadd153e0aede4811ca7008f5d6 ]
    
    syzbot found hanging tasks waiting on rtnl_lock [1]
    
    A reproducer is available in the syzbot bug.
    
    When a request to add multiple actions with the same index is sent, the
    second request will block forever on the first request. This holds
    rtnl_lock, and causes tasks to hang.
    
    Return -EAGAIN to prevent infinite looping, while keeping documented
    behavior.
    
    [1]
    
    INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
    Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
    Workqueue: events_power_efficient reg_check_chans_work
    Call Trace:
    <TASK>
    context_switch kernel/sched/core.c:5409 [inline]
    __schedule+0xf15/0x5d00 kernel/sched/core.c:6746
    __schedule_loop kernel/sched/core.c:6823 [inline]
    schedule+0xe7/0x350 kernel/sched/core.c:6838
    schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895
    __mutex_lock_common kernel/locking/mutex.c:684 [inline]
    __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752
    wiphy_lock include/net/cfg80211.h:5953 [inline]
    reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]
    reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481
    
    Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action")
    Reported-by: syzbot+b87c222546179f4513a7@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=b87c222546179f4513a7
    Signed-off-by: David Ruth <druth@chromium.org>
    Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Link: https://lore.kernel.org/r/20240614190326.1349786-1-druth@chromium.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: act_api: rely on rcu in tcf_idr_check_alloc [+ + +]
Author: Pedro Tammela <pctammela@mojatatu.com>
Date:   Mon Dec 11 15:18:06 2023 -0300

    net/sched: act_api: rely on rcu in tcf_idr_check_alloc
    
    [ Upstream commit 4b55e86736d5b492cf689125da2600f59c7d2c39 ]
    
    Instead of relying only on the idrinfo->lock mutex for
    bind/alloc logic, rely on a combination of rcu + mutex + atomics
    to better scale the case where multiple rtnl-less filters are
    binding to the same action object.
    
    Action binding happens when an action index is specified explicitly and
    an action exists which such index exists. Example:
      tc actions add action drop index 1
      tc filter add ... matchall action drop index 1
      tc filter add ... matchall action drop index 1
      tc filter add ... matchall action drop index 1
      tc filter ls ...
         filter protocol all pref 49150 matchall chain 0 filter protocol all pref 49150 matchall chain 0 handle 0x1
         not_in_hw
               action order 1: gact action drop
                random type none pass val 0
                index 1 ref 4 bind 3
    
       filter protocol all pref 49151 matchall chain 0 filter protocol all pref 49151 matchall chain 0 handle 0x1
         not_in_hw
               action order 1: gact action drop
                random type none pass val 0
                index 1 ref 4 bind 3
    
       filter protocol all pref 49152 matchall chain 0 filter protocol all pref 49152 matchall chain 0 handle 0x1
         not_in_hw
               action order 1: gact action drop
                random type none pass val 0
                index 1 ref 4 bind 3
    
    When no index is specified, as before, grab the mutex and allocate
    in the idr the next available id. In this version, as opposed to before,
    it's simplified to store the -EBUSY pointer instead of the previous
    alloc + replace combination.
    
    When an index is specified, rely on rcu to find if there's an object in
    such index. If there's none, fallback to the above, serializing on the
    mutex and reserving the specified id. If there's one, it can be an -EBUSY
    pointer, in which case we just try again until it's an action, or an action.
    Given the rcu guarantees, the action found could be dead and therefore
    we need to bump the refcount if it's not 0, handling the case it's
    in fact 0.
    
    As bind and the action refcount are already atomics, these increments can
    happen without the mutex protection while many tcf_idr_check_alloc race
    to bind to the same action instance.
    
    In case binding encounters a parallel delete or add, it will return
    -EAGAIN in order to try again. Both filter and action apis already
    have the retry machinery in-place. In case it's an unlocked filter it
    retries under the rtnl lock.
    
    Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Reviewed-by: Vlad Buslov <vladbu@nvidia.com>
    Link: https://lore.kernel.org/r/20231211181807.96028-2-pctammela@mojatatu.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: d864319871b0 ("net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: act_ct: set 'net' pointer when creating new nf_flow_table [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Wed Jun 15 12:43:54 2022 +0200

    net/sched: act_ct: set 'net' pointer when creating new nf_flow_table
    
    [ Upstream commit fc54d9065f90dd25063883f404e6ff9a76913e73 ]
    
    Following patches in series use the pointer to access flow table offload
    debug variables.
    
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Signed-off-by: Oz Shlomo <ozsh@nvidia.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Stable-dep-of: 88c67aeb1407 ("sched: act_ct: add netns into the key of tcf_ct_flow_table")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jun 4 18:15:11 2024 +0000

    net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP
    
    [ Upstream commit f921a58ae20852d188f70842431ce6519c4fdc36 ]
    
    If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,
    taprio_parse_mqprio_opt() must validate it, or userspace
    can inject arbitrary data to the kernel, the second time
    taprio_change() is called.
    
    First call (with valid attributes) sets dev->num_tc
    to a non zero value.
    
    Second call (with arbitrary mqprio attributes)
    returns early from taprio_parse_mqprio_opt()
    and bad things can happen.
    
    Fixes: a3d43c0d56f1 ("taprio: Add support adding an admin schedule")
    Reported-by: Noam Rathaus <noamr@ssd-disclosure.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Link: https://lore.kernel.org/r/20240604181511.769870-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new [+ + +]
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Fri Nov 17 13:49:59 2023 +0100

    net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
    
    commit d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb upstream.
    
    This patch enhances error handling in scenarios with RTS (Request to
    Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE
    backtraces with a new error handling method. This provides clearer error
    messages and allows for the early termination of problematic sessions.
    Previously, sessions were only released at the end of j1939_xtp_rx_rts().
    
    Potentially this could be reproduced with something like:
    testj1939 -r vcan0:0x80 &
    while true; do
            # send first RTS
            cansend vcan0 18EC8090#1014000303002301;
            # send second RTS
            cansend vcan0 18EC8090#1014000303002301;
            # send abort
            cansend vcan0 18EC8090#ff00000000002301;
    done
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Reported-by: syzbot+daa36413a5cedf799ae4@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/all/20231117124959.961171-1-o.rempel@pengutronix.de
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: can: j1939: Initialize unused data in j1939_send_one() [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Fri May 17 12:59:53 2024 +0900

    net: can: j1939: Initialize unused data in j1939_send_one()
    
    commit b7cdf1dd5d2a2d8200efd98d1893684db48fe134 upstream.
    
    syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()
    creates full frame including unused data, but it doesn't initialize
    it. This causes the kernel-infoleak issue. Fix this by initializing
    unused data.
    
    [1]
    BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
    BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
    BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
    BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
    BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
    BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
     instrument_copy_to_user include/linux/instrumented.h:114 [inline]
     copy_to_user_iter lib/iov_iter.c:24 [inline]
     iterate_ubuf include/linux/iov_iter.h:29 [inline]
     iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
     iterate_and_advance include/linux/iov_iter.h:271 [inline]
     _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
     copy_to_iter include/linux/uio.h:196 [inline]
     memcpy_to_msg include/linux/skbuff.h:4113 [inline]
     raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008
     sock_recvmsg_nosec net/socket.c:1046 [inline]
     sock_recvmsg+0x2c4/0x340 net/socket.c:1068
     ____sys_recvmsg+0x18a/0x620 net/socket.c:2803
     ___sys_recvmsg+0x223/0x840 net/socket.c:2845
     do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939
     __sys_recvmmsg net/socket.c:3018 [inline]
     __do_sys_recvmmsg net/socket.c:3041 [inline]
     __se_sys_recvmmsg net/socket.c:3034 [inline]
     __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034
     x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was created at:
     slab_post_alloc_hook mm/slub.c:3804 [inline]
     slab_alloc_node mm/slub.c:3845 [inline]
     kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
     kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
     __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
     alloc_skb include/linux/skbuff.h:1313 [inline]
     alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
     sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
     sock_alloc_send_skb include/net/sock.h:1842 [inline]
     j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]
     j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]
     j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg+0x30f/0x380 net/socket.c:745
     ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
     ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
     __sys_sendmsg net/socket.c:2667 [inline]
     __do_sys_sendmsg net/socket.c:2676 [inline]
     __se_sys_sendmsg net/socket.c:2674 [inline]
     __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
     x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Bytes 12-15 of 16 are uninitialized
    Memory access of size 16 starts at ffff888120969690
    Data copied to user address 00000000200017c0
    
    CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Reported-and-tested-by: syzbot+5681e40d297b30f5b513@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=5681e40d297b30f5b513
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Link: https://lore.kernel.org/all/20240517035953.2617090-1-syoshida@redhat.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: can: j1939: recover socket queue on CAN bus error during BAM transmission [+ + +]
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Tue May 28 09:06:48 2024 +0200

    net: can: j1939: recover socket queue on CAN bus error during BAM transmission
    
    commit 9ad1da14ab3bf23087ae45fe399d84a109ddb81a upstream.
    
    Addresses an issue where a CAN bus error during a BAM transmission
    could stall the socket queue, preventing further transmissions even
    after the bus error is resolved. The fix activates the next queued
    session after the error recovery, allowing communication to continue.
    
    Fixes: 9d71dd0c70099 ("can: add support of SAE J1939 protocol")
    Cc: stable@vger.kernel.org
    Reported-by: Alexander Hölzl <alexander.hoelzl@gmx.net>
    Tested-by: Alexander Hölzl <alexander.hoelzl@gmx.net>
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://lore.kernel.org/all/20240528070648.1947203-1-o.rempel@pengutronix.de
    Cc: stable@vger.kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: do not leave a dangling sk pointer, when socket creation fails [+ + +]
Author: Ignat Korchagin <ignat@cloudflare.com>
Date:   Mon Jun 17 22:02:05 2024 +0100

    net: do not leave a dangling sk pointer, when socket creation fails
    
    commit 6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2 upstream.
    
    It is possible to trigger a use-after-free by:
      * attaching an fentry probe to __sock_release() and the probe calling the
        bpf_get_socket_cookie() helper
      * running traceroute -I 1.1.1.1 on a freshly booted VM
    
    A KASAN enabled kernel will log something like below (decoded and stripped):
    ==================================================================
    BUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
    Read of size 8 at addr ffff888007110dd8 by task traceroute/299
    
    CPU: 2 PID: 299 Comm: traceroute Tainted: G            E      6.10.0-rc2+ #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
    Call Trace:
     <TASK>
    dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))
    print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
    ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
    kasan_report (mm/kasan/report.c:603)
    ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
    kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189)
    __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
    bpf_get_socket_ptr_cookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092)
    bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e
    bpf_trampoline_6442506592+0x47/0xaf
    __sock_release (net/socket.c:652)
    __sock_create (net/socket.c:1601)
    ...
    Allocated by task 299 on cpu 2 at 78.328492s:
    kasan_save_stack (mm/kasan/common.c:48)
    kasan_save_track (mm/kasan/common.c:68)
    __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338)
    kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007)
    sk_prot_alloc (net/core/sock.c:2075)
    sk_alloc (net/core/sock.c:2134)
    inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252)
    __sock_create (net/socket.c:1572)
    __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)
    __x64_sys_socket (net/socket.c:1718)
    do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
    Freed by task 299 on cpu 2 at 78.328502s:
    kasan_save_stack (mm/kasan/common.c:48)
    kasan_save_track (mm/kasan/common.c:68)
    kasan_save_free_info (mm/kasan/generic.c:582)
    poison_slab_object (mm/kasan/common.c:242)
    __kasan_slab_free (mm/kasan/common.c:256)
    kmem_cache_free (mm/slub.c:4437 mm/slub.c:4511)
    __sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208)
    inet_create (net/ipv4/af_inet.c:397 net/ipv4/af_inet.c:252)
    __sock_create (net/socket.c:1572)
    __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)
    __x64_sys_socket (net/socket.c:1718)
    do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
    Fix this by clearing the struct socket reference in sk_common_release() to cover
    all protocol families create functions, which may already attached the
    reference to the sk object with sock_init_data().
    
    Fixes: c5dbb89fc2ac ("bpf: Expose bpf_get_socket_cookie to tracing programs")
    Suggested-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/netdev/20240613194047.36478-1-kuniyu@amazon.com/T/
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: D. Wythe <alibuda@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20240617210205.67311-1-ignat@cloudflare.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: drop nopreempt requirement on sock_prot_inuse_add() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Nov 15 09:11:50 2021 -0800

    net: drop nopreempt requirement on sock_prot_inuse_add()
    
    [ Upstream commit b3cb764aa1d753cf6a58858f9e2097ba71e8100b ]
    
    This is distracting really, let's make this simpler,
    because many callers had to take care of this
    by themselves, even if on x86 this adds more
    code than really needed.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: a9bf9c7dc6a5 ("af_unix: Annotate data-race of sk->sk_state in unix_stream_connect().")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: microchip: fix initial port flush problem [+ + +]
Author: Tristram Ha <tristram.ha@microchip.com>
Date:   Tue Jun 18 17:16:42 2024 -0700

    net: dsa: microchip: fix initial port flush problem
    
    [ Upstream commit ad53f5f54f351e967128edbc431f0f26427172cf ]
    
    The very first flush in any port will flush all learned addresses in all
    ports.  This can be observed by unplugging the cable from one port while
    additional ports are connected and dumping the fdb entries.
    
    This problem is caused by the initially wrong value programmed to the
    REG_SW_LUE_CTRL_1 register.  Setting SW_FLUSH_STP_TABLE and
    SW_FLUSH_MSTP_TABLE bits does not have an immediate effect.  It is when
    ksz9477_flush_dyn_mac_table() is called then the SW_FLUSH_STP_TABLE bit
    takes effect and flushes all learned entries.  After that call both bits
    are reset and so the next port flush will not cause such problem again.
    
    Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
    Signed-off-by: Tristram Ha <tristram.ha@microchip.com>
    Link: https://patch.msgid.link/1718756202-2731-1-git-send-email-Tristram.Ha@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: hns3: add cond_resched() to hns3 ring buffer init process [+ + +]
Author: Jie Wang <wangjie125@huawei.com>
Date:   Wed Jun 5 15:20:58 2024 +0800

    net: hns3: add cond_resched() to hns3 ring buffer init process
    
    [ Upstream commit 968fde83841a8c23558dfbd0a0c69d636db52b55 ]
    
    Currently hns3 ring buffer init process would hold cpu too long with big
    Tx/Rx ring depth. This could cause soft lockup.
    
    So this patch adds cond_resched() to the process. Then cpu can break to
    run other tasks instead of busy looping.
    
    Fixes: a723fb8efe29 ("net: hns3: refine for set ring parameters")
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: fix kernel crash problem in concurrent scenario [+ + +]
Author: Yonglong Liu <liuyonglong@huawei.com>
Date:   Wed Jun 5 15:20:57 2024 +0800

    net: hns3: fix kernel crash problem in concurrent scenario
    
    [ Upstream commit 12cda920212a49fa22d9e8b9492ac4ea013310a4 ]
    
    When link status change, the nic driver need to notify the roce
    driver to handle this event, but at this time, the roce driver
    may uninit, then cause kernel crash.
    
    To fix the problem, when link status change, need to check
    whether the roce registered, and when uninit, need to wait link
    update finish.
    
    Fixes: 45e92b7e4e27 ("net: hns3: add calling roce callback function when link status change")
    Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: inline sock_prot_inuse_add() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Nov 15 09:11:47 2021 -0800

    net: inline sock_prot_inuse_add()
    
    [ Upstream commit 2a12ae5d433df3d3c3f1a930799ec09cb2b8058f ]
    
    sock_prot_inuse_add() is very small, we can inline it.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: a9bf9c7dc6a5 ("af_unix: Annotate data-race of sk->sk_state in unix_stream_connect().")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mdio: add helpers to extract clause 45 regad and devad fields [+ + +]
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date:   Tue Jan 4 12:07:00 2022 +0000

    net: mdio: add helpers to extract clause 45 regad and devad fields
    
    [ Upstream commit c6af53f038aa32cec12e8a305ba07c7ef168f1b0 ]
    
    Add a couple of helpers and definitions to extract the clause 45 regad
    and devad fields from the regnum passed into MDIO drivers.
    
    Tested-by: Daniel Golle <daniel@makrotopia.org>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Daniel Golle <daniel@makrotopia.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 8851346912a1 ("net: stmmac: Assign configured channel value to EXTTS event")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: micrel: add Microchip KSZ 9477 to the device table [+ + +]
Author: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Date:   Fri Jun 21 16:43:20 2024 +0200

    net: phy: micrel: add Microchip KSZ 9477 to the device table
    
    [ Upstream commit 54a4e5c16382e871c01dd82b47e930fdce30406b ]
    
    PHY_ID_KSZ9477 was supported but not added to the device table passed to
    MODULE_DEVICE_TABLE.
    
    Fixes: fc3973a1fa09 ("phy: micrel: add Microchip KSZ 9477 Switch PHY support")
    Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: sched: sch_multiq: fix possible OOB write in multiq_tune() [+ + +]
Author: Hangyu Hua <hbh25y@gmail.com>
Date:   Mon Jun 3 15:13:03 2024 +0800

    net: sched: sch_multiq: fix possible OOB write in multiq_tune()
    
    [ Upstream commit affc18fdc694190ca7575b9a86632a73b9fe043d ]
    
    q->bands will be assigned to qopt->bands to execute subsequent code logic
    after kmalloc. So the old q->bands should not be used in kmalloc.
    Otherwise, an out-of-bounds write will occur.
    
    Fixes: c2999f7fb05b ("net: sched: multiq: don't call qdisc_put() while holding tree lock")
    Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
    Acked-by: Cong Wang <cong.wang@bytedance.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: sfp: Always call `sfp_sm_mod_remove()` on remove [+ + +]
Author: Csókás, Bence <csokas.bence@prolan.hu>
Date:   Wed Jun 5 10:42:51 2024 +0200

    net: sfp: Always call `sfp_sm_mod_remove()` on remove
    
    [ Upstream commit e96b2933152fd87b6a41765b2f58b158fde855b6 ]
    
    If the module is in SFP_MOD_ERROR, `sfp_sm_mod_remove()` will
    not be run. As a consequence, `sfp_hwmon_remove()` is not getting
    run either, leaving a stale `hwmon` device behind. `sfp_sm_mod_remove()`
    itself checks `sfp->sm_mod_state` anyways, so this check was not
    really needed in the first place.
    
    Fixes: d2e816c0293f ("net: sfp: handle module remove outside state machine")
    Signed-off-by: "Csókás, Bence" <csokas.bence@prolan.hu>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20240605084251.63502-1-csokas.bence@prolan.hu
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: Assign configured channel value to EXTTS event [+ + +]
Author: Oleksij Rempel <o.rempel@pengutronix.de>
Date:   Tue Jun 18 09:38:21 2024 +0200

    net: stmmac: Assign configured channel value to EXTTS event
    
    [ Upstream commit 8851346912a1fa33e7a5966fe51f07313b274627 ]
    
    Assign the configured channel value to the EXTTS event in the timestamp
    interrupt handler. Without assigning the correct channel, applications
    like ts2phc will refuse to accept the event, resulting in errors such
    as:
    ...
    ts2phc[656.834]: config item end1.ts2phc.pin_index is 0
    ts2phc[656.834]: config item end1.ts2phc.channel is 3
    ts2phc[656.834]: config item end1.ts2phc.extts_polarity is 2
    ts2phc[656.834]: config item end1.ts2phc.extts_correction is 0
    ...
    ts2phc[656.862]: extts on unexpected channel
    ts2phc[658.141]: extts on unexpected channel
    ts2phc[659.140]: extts on unexpected channel
    
    Fixes: f4da56529da60 ("net: stmmac: Add support for external trigger timestamping")
    Cc: stable@vger.kernel.org
    Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Link: https://lore.kernel.org/r/20240618073821.619751-1-o.rempel@pengutronix.de
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: No need to calculate speed divider when offload is disabled [+ + +]
Author: Xiaolei Wang <xiaolei.wang@windriver.com>
Date:   Mon Jun 17 09:39:22 2024 +0800

    net: stmmac: No need to calculate speed divider when offload is disabled
    
    [ Upstream commit b8c43360f6e424131fa81d3ba8792ad8ff25a09e ]
    
    commit be27b8965297 ("net: stmmac: replace priv->speed with
    the portTransmitRate from the tc-cbs parameters") introduced
    a problem. When deleting, it prompts "Invalid portTransmitRate
    0 (idleSlope - sendSlope)" and exits. Add judgment on cbs.enable.
    Only when offload is enabled, speed divider needs to be calculated.
    
    Fixes: be27b8965297 ("net: stmmac: replace priv->speed with the portTransmitRate from the tc-cbs parameters")
    Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240617013922.1035854-1-xiaolei.wang@windriver.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: replace priv->speed with the portTransmitRate from the tc-cbs parameters [+ + +]
Author: Xiaolei Wang <xiaolei.wang@windriver.com>
Date:   Sat Jun 8 22:35:24 2024 +0800

    net: stmmac: replace priv->speed with the portTransmitRate from the tc-cbs parameters
    
    [ Upstream commit be27b896529787e23a35ae4befb6337ce73fcca0 ]
    
    The current cbs parameter depends on speed after uplinking,
    which is not needed and will report a configuration error
    if the port is not initially connected. The UAPI exposed by
    tc-cbs requires userspace to recalculate the send slope anyway,
    because the formula depends on port_transmit_rate (see man tc-cbs),
    which is not an invariant from tc's perspective. Therefore, we
    use offload->sendslope and offload->idleslope to derive the
    original port_transmit_rate from the CBS formula.
    
    Fixes: 1f705bc61aee ("net: stmmac: Add support for CBS QDISC")
    Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20240608143524.2065736-1-xiaolei.wang@windriver.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: ax88179_178a: improve link status logs [+ + +]
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Date:   Thu Jun 20 15:34:31 2024 +0200

    net: usb: ax88179_178a: improve link status logs
    
    commit 058722ee350c0bdd664e467156feb2bf5d9cc271 upstream.
    
    Avoid spurious link status logs that may ultimately be wrong; for example,
    if the link is set to down with the cable plugged, then the cable is
    unplugged and after this the link is set to up, the last new log that is
    appearing is incorrectly telling that the link is up.
    
    In order to avoid errors, show link status logs after link_reset
    processing, and in order to avoid spurious as much as possible, only show
    the link loss when some link status change is detected.
    
    cc: stable@vger.kernel.org
    Fixes: e2ca90c276e1 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver")
    Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: rtl8150 fix unintiatilzed variables in rtl8150_get_link_ksettings [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Jun 19 15:28:03 2024 +0200

    net: usb: rtl8150 fix unintiatilzed variables in rtl8150_get_link_ksettings
    
    [ Upstream commit fba383985354e83474f95f36d7c65feb75dba19d ]
    
    This functions retrieves values by passing a pointer. As the function
    that retrieves them can fail before touching the pointers, the variables
    must be initialized.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot+5186630949e3c55f0799@syzkaller.appspotmail.com
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20240619132816.11526-1-oneukum@suse.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type [+ + +]
Author: Jozsef Kadlecsik <kadlec@netfilter.org>
Date:   Tue Jun 4 15:58:03 2024 +0200

    netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type
    
    [ Upstream commit 4e7aaa6b82d63e8ddcbfb56b4fd3d014ca586f10 ]
    
    Lion Ackermann reported that there is a race condition between namespace cleanup
    in ipset and the garbage collection of the list:set type. The namespace
    cleanup can destroy the list:set type of sets while the gc of the set type is
    waiting to run in rcu cleanup. The latter uses data from the destroyed set which
    thus leads use after free. The patch contains the following parts:
    
    - When destroying all sets, first remove the garbage collectors, then wait
      if needed and then destroy the sets.
    - Fix the badly ordered "wait then remove gc" for the destroy a single set
      case.
    - Fix the missing rcu locking in the list:set type in the userspace test
      case.
    - Use proper RCU list handlings in the list:set type.
    
    The patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc).
    
    Fixes: 97f7cf1cd80e (netfilter: ipset: fix performance regression in swap operation)
    Reported-by: Lion Ackermann <nnamrec@gmail.com>
    Tested-by: Lion Ackermann <nnamrec@gmail.com>
    Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: ipset: Fix suspicious rcu_dereference_protected() [+ + +]
Author: Jozsef Kadlecsik <kadlec@netfilter.org>
Date:   Mon Jun 17 11:18:15 2024 +0200

    netfilter: ipset: Fix suspicious rcu_dereference_protected()
    
    [ Upstream commit 8ecd06277a7664f4ef018abae3abd3451d64e7a6 ]
    
    When destroying all sets, we are either in pernet exit phase or
    are executing a "destroy all sets command" from userspace. The latter
    was taken into account in ip_set_dereference() (nfnetlink mutex is held),
    but the former was not. The patch adds the required check to
    rcu_dereference_protected() in ip_set_dereference().
    
    Fixes: 4e7aaa6b82d6 ("netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type")
    Reported-by: syzbot+b62c37cdd58103293a5a@syzkaller.appspotmail.com
    Reported-by: syzbot+cfbe1da5fdfc39efc293@syzkaller.appspotmail.com
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202406141556.e0b6f17e-lkp@intel.com
    Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Jun 26 23:15:38 2024 +0200

    netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
    
    [ Upstream commit 7931d32955e09d0a11b1fe0b6aac1bfa061c005c ]
    
    register store validation for NFT_DATA_VALUE is conditional, however,
    the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This
    only requires a new helper function to infer the register type from the
    set datatype so this conditional check can be removed. Otherwise,
    pointer to chain object can be leaked through the registers.
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Reported-by: Linus Torvalds <torvalds@linuxfoundation.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netns: Make get_net_ns() handle zero refcount net [+ + +]
Author: Yue Haibing <yuehaibing@huawei.com>
Date:   Fri Jun 14 21:13:02 2024 +0800

    netns: Make get_net_ns() handle zero refcount net
    
    [ Upstream commit ff960f9d3edbe08a736b5a224d91a305ccc946b0 ]
    
    Syzkaller hit a warning:
    refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0
    Modules linked in:
    CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    RIP: 0010:refcount_warn_saturate+0xdf/0x1d0
    Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1
    RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac
    RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001
    RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139
    R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4
    R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040
    FS:  00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     ? show_regs+0xa3/0xc0
     ? __warn+0xa5/0x1c0
     ? refcount_warn_saturate+0xdf/0x1d0
     ? report_bug+0x1fc/0x2d0
     ? refcount_warn_saturate+0xdf/0x1d0
     ? handle_bug+0xa1/0x110
     ? exc_invalid_op+0x3c/0xb0
     ? asm_exc_invalid_op+0x1f/0x30
     ? __warn_printk+0xcc/0x140
     ? __warn_printk+0xd5/0x140
     ? refcount_warn_saturate+0xdf/0x1d0
     get_net_ns+0xa4/0xc0
     ? __pfx_get_net_ns+0x10/0x10
     open_related_ns+0x5a/0x130
     __tun_chr_ioctl+0x1616/0x2370
     ? __sanitizer_cov_trace_switch+0x58/0xa0
     ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30
     ? __pfx_tun_chr_ioctl+0x10/0x10
     tun_chr_ioctl+0x2f/0x40
     __x64_sys_ioctl+0x11b/0x160
     x64_sys_call+0x1211/0x20d0
     do_syscall_64+0x9e/0x1d0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f5b28f165d7
    Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8
    RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7
    RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003
    RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0
    R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730
    R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000
     </TASK>
    Kernel panic - not syncing: kernel: panic_on_warn set ...
    
    This is trigger as below:
              ns0                                    ns1
    tun_set_iff() //dev is tun0
       tun->dev = dev
    //ip link set tun0 netns ns1
                                           put_net() //ref is 0
    __tun_chr_ioctl() //TUNGETDEVNETNS
       net = dev_net(tun->dev);
       open_related_ns(&net->ns, get_net_ns); //ns1
         get_net_ns()
            get_net() //addition on 0
    
    Use maybe_get_net() in get_net_ns in case net's ref is zero to fix this
    
    Fixes: 0c3e0e3bb623 ("tun: Add ioctl() TUNGETDEVNETNS cmd to allow obtaining real net ns of tun device")
    Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
    Link: https://lore.kernel.org/r/20240614131302.2698509-1-yuehaibing@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netpoll: Fix race condition in netpoll_owner_active [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Mon Apr 29 03:04:33 2024 -0700

    netpoll: Fix race condition in netpoll_owner_active
    
    [ Upstream commit c2e6a872bde9912f1a7579639c5ca3adf1003916 ]
    
    KCSAN detected a race condition in netpoll:
    
            BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb
            write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:
            net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)
    <snip>
            read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:
            netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)
            netpoll_send_udp (net/core/netpoll.c:?)
    <snip>
            value changed: 0x0000000a -> 0xffffffff
    
    This happens because netpoll_owner_active() needs to check if the
    current CPU is the owner of the lock, touching napi->poll_owner
    non atomically. The ->poll_owner field contains the current CPU holding
    the lock.
    
    Use an atomic read to check if the poll owner is the current CPU.
    
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Link: https://lore.kernel.org/r/20240429100437.3487432-1-leitao@debian.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netrom: Fix a memory leak in nr_heartbeat_expiry() [+ + +]
Author: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
Date:   Thu Jun 13 08:23:00 2024 +0000

    netrom: Fix a memory leak in nr_heartbeat_expiry()
    
    [ Upstream commit 0b9130247f3b6a1122478471ff0e014ea96bb735 ]
    
    syzbot reported a memory leak in nr_create() [0].
    
    Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")
    added sock_hold() to the nr_heartbeat_expiry() function, where
    a) a socket has a SOCK_DESTROY flag or
    b) a listening socket has a SOCK_DEAD flag.
    
    But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor
    has already been closed and the nr_release() function has been called.
    So it makes no sense to hold the reference count because no one will
    call another nr_destroy_socket() and put it as in the case "b."
    
    nr_connect
      nr_establish_data_link
        nr_start_heartbeat
    
    nr_release
      switch (nr->state)
      case NR_STATE_3
        nr->state = NR_STATE_2
        sock_set_flag(sk, SOCK_DESTROY);
    
                            nr_rx_frame
                              nr_process_rx_frame
                                switch (nr->state)
                                case NR_STATE_2
                                  nr_state2_machine()
                                    nr_disconnect()
                                      nr_sk(sk)->state = NR_STATE_0
                                      sock_set_flag(sk, SOCK_DEAD)
    
                            nr_heartbeat_expiry
                              switch (nr->state)
                              case NR_STATE_0
                                if (sock_flag(sk, SOCK_DESTROY) ||
                                   (sk->sk_state == TCP_LISTEN
                                     && sock_flag(sk, SOCK_DEAD)))
                                   sock_hold()  // ( !!! )
                                   nr_destroy_socket()
    
    To fix the memory leak, let's call sock_hold() only for a listening socket.
    
    Found by InfoTeCS on behalf of Linux Verification Center
    (linuxtesting.org) with Syzkaller.
    
    [0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16
    
    Reported-by: syzbot+d327a1f3b12e1e206c16@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16
    Fixes: 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")
    Signed-off-by: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfs: Leave pages in the pagecache if readpage failed [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Mon May 16 10:30:09 2022 -0400

    nfs: Leave pages in the pagecache if readpage failed
    
    commit 0b768a9610c6de9811c6d33900bebfb665192ee1 upstream.
    
    The pagecache handles readpage failing by itself; it doesn't want
    filesystems to remove pages from under it.
    
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Tue Jun 4 22:42:55 2024 +0900

    nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors
    
    [ Upstream commit 7373a51e7998b508af7136530f3a997b286ce81c ]
    
    The error handling in nilfs_empty_dir() when a directory folio/page read
    fails is incorrect, as in the old ext2 implementation, and if the
    folio/page cannot be read or nilfs_check_folio() fails, it will falsely
    determine the directory as empty and corrupt the file system.
    
    In addition, since nilfs_empty_dir() does not immediately return on a
    failed folio/page read, but continues to loop, this can cause a long loop
    with I/O if i_size of the directory's inode is also corrupted, causing the
    log writer thread to wait and hang, as reported by syzbot.
    
    Fix these issues by making nilfs_empty_dir() immediately return a false
    value (0) if it fails to get a directory folio/page.
    
    Link: https://lkml.kernel.org/r/20240604134255.7165-1-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+c8166c541d3971bf6c87@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=c8166c541d3971bf6c87
    Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations")
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nilfs2: fix potential kernel bug due to lack of writeback flag waiting [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Thu May 30 23:15:56 2024 +0900

    nilfs2: fix potential kernel bug due to lack of writeback flag waiting
    
    commit a4ca369ca221bb7e06c725792ac107f0e48e82e7 upstream.
    
    Destructive writes to a block device on which nilfs2 is mounted can cause
    a kernel bug in the folio/page writeback start routine or writeback end
    routine (__folio_start_writeback in the log below):
    
     kernel BUG at mm/page-writeback.c:3070!
     Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
     ...
     RIP: 0010:__folio_start_writeback+0xbaa/0x10e0
     Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff
      e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f>
      0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00
     ...
     Call Trace:
      <TASK>
      nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]
      nilfs_segctor_construct+0x181/0x6b0 [nilfs2]
      nilfs_segctor_thread+0x548/0x11c0 [nilfs2]
      kthread+0x2f0/0x390
      ret_from_fork+0x4b/0x80
      ret_from_fork_asm+0x1a/0x30
      </TASK>
    
    This is because when the log writer starts a writeback for segment summary
    blocks or a super root block that use the backing device's page cache, it
    does not wait for the ongoing folio/page writeback, resulting in an
    inconsistent writeback state.
    
    Fix this issue by waiting for ongoing writebacks when putting
    folios/pages on the backing device into writeback state.
    
    Link: https://lkml.kernel.org/r/20240530141556.4411-1-konishi.ryusuke@gmail.com
    Fixes: 9ff05123e3bf ("nilfs2: segment constructor")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nilfs2: Remove check for PageError [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Tue May 17 18:12:25 2022 -0400

    nilfs2: Remove check for PageError
    
    [ Upstream commit 79ea65563ad8aaab309d61eeb4d5019dd6cf5fa0 ]
    
    If read_mapping_page() encounters an error, it returns an errno, not a
    page with PageError set, so this test is not needed.
    
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Stable-dep-of: 7373a51e7998 ("nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nilfs2: return the mapped address from nilfs_get_page() [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Mon Nov 27 23:30:25 2023 +0900

    nilfs2: return the mapped address from nilfs_get_page()
    
    [ Upstream commit 09a46acb3697e50548bb265afa1d79163659dd85 ]
    
    In prepartion for switching from kmap() to kmap_local(), return the kmap
    address from nilfs_get_page() instead of having the caller look up
    page_address().
    
    [konishi.ryusuke: fixed a missing blank line after declaration]
    Link: https://lkml.kernel.org/r/20231127143036.2425-7-konishi.ryusuke@gmail.com
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: 7373a51e7998 ("nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
null_blk: Print correct max open zones limit in null_init_zoned_dev() [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Tue May 28 15:28:52 2024 +0900

    null_blk: Print correct max open zones limit in null_init_zoned_dev()
    
    commit 233e27b4d21c3e44eb863f03e566d3a22e81a7ae upstream.
    
    When changing the maximum number of open zones, print that number
    instead of the total number of zones.
    
    Fixes: dc4d137ee3b7 ("null_blk: add support for max open/active zone limit for zoned devices")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Niklas Cassel <cassel@kernel.org>
    Link: https://lore.kernel.org/r/20240528062852.437599-1-dlemoal@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nvme: fixup comment for nvme RDMA Provider Type [+ + +]
Author: Hannes Reinecke <hare@suse.de>
Date:   Mon Jun 17 09:27:27 2024 +0200

    nvme: fixup comment for nvme RDMA Provider Type
    
    [ Upstream commit f80a55fa90fa76d01e3fffaa5d0413e522ab9a00 ]
    
    PRTYPE is the provider type, not the QP service type.
    
    Fixes: eb793e2c9286 ("nvme.h: add NVMe over Fabrics definitions")
    Signed-off-by: Hannes Reinecke <hare@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ocfs2: fix DIO failure due to insufficient transaction credits [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Fri Jun 14 16:52:43 2024 +0200

    ocfs2: fix DIO failure due to insufficient transaction credits
    
    commit be346c1a6eeb49d8fda827d2a9522124c2f72f36 upstream.
    
    The code in ocfs2_dio_end_io_write() estimates number of necessary
    transaction credits using ocfs2_calc_extend_credits().  This however does
    not take into account that the IO could be arbitrarily large and can
    contain arbitrary number of extents.
    
    Extent tree manipulations do often extend the current transaction but not
    in all of the cases.  For example if we have only single block extents in
    the tree, ocfs2_mark_extent_written() will end up calling
    ocfs2_replace_extent_rec() all the time and we will never extend the
    current transaction and eventually exhaust all the transaction credits if
    the IO contains many single block extents.  Once that happens a
    WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in
    jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
    this error.  This was actually triggered by one of our customers on a
    heavily fragmented OCFS2 filesystem.
    
    To fix the issue make sure the transaction always has enough credits for
    one extent insert before each call of ocfs2_mark_extent_written().
    
    Heming Zhao said:
    
    ------
    PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
    
    PID: xxx  TASK: xxxx  CPU: 5  COMMAND: "SubmitThread-CA"
      #0 machine_kexec at ffffffff8c069932
      #1 __crash_kexec at ffffffff8c1338fa
      #2 panic at ffffffff8c1d69b9
      #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]
      #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]
      #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]
      #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]
      #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]
      #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]
      #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
    #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
    #11 dio_complete at ffffffff8c2b9fa7
    #12 do_blockdev_direct_IO at ffffffff8c2bc09f
    #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
    #14 generic_file_direct_write at ffffffff8c1dcf14
    #15 __generic_file_write_iter at ffffffff8c1dd07b
    #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
    #17 aio_write at ffffffff8c2cc72e
    #18 kmem_cache_alloc at ffffffff8c248dde
    #19 do_io_submit at ffffffff8c2ccada
    #20 do_syscall_64 at ffffffff8c004984
    #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba
    
    Link: https://lkml.kernel.org/r/20240617095543.6971-1-jack@suse.cz
    Link: https://lkml.kernel.org/r/20240614145243.8837-1-jack@suse.cz
    Fixes: c15471f79506 ("ocfs2: fix sparse file & data ordering issue in direct io")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Reviewed-by: Heming Zhao <heming.zhao@suse.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ocfs2: fix races between hole punching and AIO+DIO [+ + +]
Author: Su Yue <glass.su@suse.com>
Date:   Mon Apr 8 16:20:39 2024 +0800

    ocfs2: fix races between hole punching and AIO+DIO
    
    commit 952b023f06a24b2ad6ba67304c4c84d45bea2f18 upstream.
    
    After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block",
    fstests/generic/300 become from always failed to sometimes failed:
    
    ========================================================================
    [  473.293420 ] run fstests generic/300
    
    [  475.296983 ] JBD2: Ignoring recovery information on journal
    [  475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.
    [  494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found
    [  494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
    [  494.292018 ] OCFS2: File system is now read-only.
    [  494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30
    [  494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3
    fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072
    =========================================================================
    
    In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten
    extents to a list.  extents are also inserted into extent tree in
    ocfs2_write_begin_nolock.  Then another thread call fallocate to puch a
    hole at one of the unwritten extent.  The extent at cpos was removed by
    ocfs2_remove_extent().  At end io worker thread, ocfs2_search_extent_list
    found there is no such extent at the cpos.
    
        T1                        T2                T3
                                  inode lock
                                    ...
                                    insert extents
                                    ...
                                  inode unlock
    ocfs2_fallocate
     __ocfs2_change_file_space
      inode lock
      lock ip_alloc_sem
      ocfs2_remove_inode_range inode
       ocfs2_remove_btree_range
        ocfs2_remove_extent
        ^---remove the extent at cpos 78723
      ...
      unlock ip_alloc_sem
      inode unlock
                                           ocfs2_dio_end_io
                                            ocfs2_dio_end_io_write
                                             lock ip_alloc_sem
                                             ocfs2_mark_extent_written
                                              ocfs2_change_extent_flag
                                               ocfs2_search_extent_list
                                               ^---failed to find extent
                                              ...
                                              unlock ip_alloc_sem
    
    In most filesystems, fallocate is not compatible with racing with AIO+DIO,
    so fix it by adding to wait for all dio before fallocate/punch_hole like
    ext4.
    
    Link: https://lkml.kernel.org/r/20240408082041.20925-3-glass.su@suse.com
    Fixes: b25801038da5 ("ocfs2: Support xfs style space reservation ioctls")
    Signed-off-by: Su Yue <glass.su@suse.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ocfs2: use coarse time for new created files [+ + +]
Author: Su Yue <glass.su@suse.com>
Date:   Mon Apr 8 16:20:41 2024 +0800

    ocfs2: use coarse time for new created files
    
    commit b8cb324277ee16f3eca3055b96fce4735a5a41c6 upstream.
    
    The default atime related mount option is '-o realtime' which means file
    atime should be updated if atime <= ctime or atime <= mtime.  atime should
    be updated in the following scenario, but it is not:
    ==========================================================
    $ rm /mnt/testfile;
    $ echo test > /mnt/testfile
    $ stat -c "%X %Y %Z" /mnt/testfile
    1711881646 1711881646 1711881646
    $ sleep 5
    $ cat /mnt/testfile > /dev/null
    $ stat -c "%X %Y %Z" /mnt/testfile
    1711881646 1711881646 1711881646
    ==========================================================
    
    And the reason the atime in the test is not updated is that ocfs2 calls
    ktime_get_real_ts64() in __ocfs2_mknod_locked during file creation.  Then
    inode_set_ctime_current() is called in inode_set_ctime_current() calls
    ktime_get_coarse_real_ts64() to get current time.
    
    ktime_get_real_ts64() is more accurate than ktime_get_coarse_real_ts64().
    In my test box, I saw ctime set by ktime_get_coarse_real_ts64() is less
    than ktime_get_real_ts64() even ctime is set later.  The ctime of the new
    inode is smaller than atime.
    
    The call trace is like:
    
    ocfs2_create
      ocfs2_mknod
        __ocfs2_mknod_locked
        ....
    
          ktime_get_real_ts64 <------- set atime,ctime,mtime, more accurate
          ocfs2_populate_inode
        ...
        ocfs2_init_acl
          ocfs2_acl_set_mode
            inode_set_ctime_current
              current_time
                ktime_get_coarse_real_ts64 <-------less accurate
    
    ocfs2_file_read_iter
      ocfs2_inode_lock_atime
        ocfs2_should_update_atime
          atime <= ctime ? <-------- false, ctime < atime due to accuracy
    
    So here call ktime_get_coarse_real_ts64 to set inode time coarser while
    creating new files.  It may lower the accuracy of file times.  But it's
    not a big deal since we already use coarse time in other places like
    ocfs2_update_inode_atime and inode_set_ctime_current.
    
    Link: https://lkml.kernel.org/r/20240408082041.20925-5-glass.su@suse.com
    Fixes: c62c38f6b91b ("ocfs2: replace CURRENT_TIME macro")
    Signed-off-by: Su Yue <glass.su@suse.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
octeontx2-af: Always allocate PF entries from low prioriy zone [+ + +]
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date:   Wed May 29 20:59:44 2024 +0530

    octeontx2-af: Always allocate PF entries from low prioriy zone
    
    [ Upstream commit 8b0f7410942cdc420c4557eda02bfcdf60ccec17 ]
    
    PF mcam entries has to be at low priority always so that VF
    can install longest prefix match rules at higher priority.
    This was taken care currently but when priority allocation
    wrt reference entry is requested then entries are allocated
    from mid-zone instead of low priority zone. Fix this and
    always allocate entries from low priority zone for PFs.
    
    Fixes: 7df5b4b260dd ("octeontx2-af: Allocate low priority entries for PF")
    Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-pf: Add error handling to VLAN unoffload handling [+ + +]
Author: Simon Horman <horms@kernel.org>
Date:   Mon Jun 17 17:50:26 2024 +0100

    octeontx2-pf: Add error handling to VLAN unoffload handling
    
    [ Upstream commit b95a4afe2defd6f46891985f9436a568cd35a31c ]
    
    otx2_sq_append_skb makes used of __vlan_hwaccel_push_inside()
    to unoffload VLANs - push them from skb meta data into skb data.
    However, it omitts a check for __vlan_hwaccel_push_inside()
    returning NULL.
    
    Found by inspection based on [1] and [2].
    Compile tested only.
    
    [1] Re: [PATCH net-next v1] net: stmmac: Enable TSO on VLANs
        https://lore.kernel.org/all/ZmrN2W8Fye450TKs@shell.armlinux.org.uk/
    [2] Re: [PATCH net-next v2] net: stmmac: Enable TSO on VLANs
        https://lore.kernel.org/all/CANn89i+11L5=tKsa7V7Aeyxaj6nYGRwy35PAbCRYJ73G+b25sg@mail.gmail.com/
    
    Fixes: fd9d7859db6c ("octeontx2-pf: Implement ingress/egress VLAN offload")
    Signed-off-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
padata: Disable BH when taking works lock on MT path [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Wed Apr 3 17:36:18 2024 +0800

    padata: Disable BH when taking works lock on MT path
    
    [ Upstream commit 58329c4312031603bb1786b44265c26d5065fe72 ]
    
    As the old padata code can execute in softirq context, disable
    softirqs for the new padata_do_mutithreaded code too as otherwise
    lockdep will get antsy.
    
    Reported-by: syzbot+0cb5bb0f4bf9e79db3b3@syzkaller.appspotmail.com
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Acked-by: Daniel Jordan <daniel.m.jordan@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
parisc: use correct compat recv/recvfrom syscalls [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jun 19 14:27:55 2024 +0200

    parisc: use correct compat recv/recvfrom syscalls
    
    [ Upstream commit 20a50787349fadf66ac5c48f62e58d753878d2bb ]
    
    Johannes missed parisc back when he introduced the compat version
    of these syscalls, so receiving cmsg messages that require a compat
    conversion is still broken.
    
    Use the correct calls like the other architectures do.
    
    Fixes: 1dacc76d0014 ("net/compat/wext: send different messages to compat tasks")
    Acked-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

parisc: use generic sys_fanotify_mark implementation [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jun 7 13:40:45 2024 +0200

    parisc: use generic sys_fanotify_mark implementation
    
    [ Upstream commit 403f17a330732a666ae793f3b15bc75bb5540524 ]
    
    The sys_fanotify_mark() syscall on parisc uses the reverse word order
    for the two halves of the 64-bit argument compared to all syscalls on
    all 32-bit architectures. As far as I can tell, the problem is that
    the function arguments on parisc are sorted backwards (26, 25, 24, 23,
    ...) compared to everyone else, so the calling conventions of using an
    even/odd register pair in native word order result in the lower word
    coming first in function arguments, matching the expected behavior
    on little-endian architectures. The system call conventions however
    ended up matching what the other 32-bit architectures do.
    
    A glibc cleanup in 2020 changed the userspace behavior in a way that
    handles all architectures consistently, but this inadvertently broke
    parisc32 by changing to the same method as everyone else.
    
    The change made it into glibc-2.35 and subsequently into debian 12
    (bookworm), which is the latest stable release. This means we
    need to choose between reverting the glibc change or changing the
    kernel to match it again, but either hange will leave some systems
    broken.
    
    Pick the option that is more likely to help current and future
    users and change the kernel to match current glibc. This also
    means the behavior is now consistent across architectures, but
    it breaks running new kernels with old glibc builds before 2.35.
    
    Link: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d150181d73d9
    Link: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/arch/parisc/kernel/sys_parisc.c?h=57b1dfbd5b4a39d
    Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>
    Tested-by: Helge Deller <deller@gmx.de>
    Acked-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>

 
PCI/PM: Avoid D3cold for HP Pavilion 17 PC/1972 PCIe Ports [+ + +]
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Thu Mar 7 10:37:09 2024 -0600

    PCI/PM: Avoid D3cold for HP Pavilion 17 PC/1972 PCIe Ports
    
    [ Upstream commit 256df20c590bf0e4d63ac69330cf23faddac3e08 ]
    
    Hewlett-Packard HP Pavilion 17 Notebook PC/1972 is an Intel Ivy Bridge
    system with a muxless AMD Radeon dGPU.  Attempting to use the dGPU fails
    with the following sequence:
    
      ACPI Error: Aborting method \AMD3._ON due to previous error (AE_AML_LOOP_TIMEOUT) (20230628/psparse-529)
      radeon 0000:01:00.0: not ready 1023ms after resume; waiting
      radeon 0000:01:00.0: not ready 2047ms after resume; waiting
      radeon 0000:01:00.0: not ready 4095ms after resume; waiting
      radeon 0000:01:00.0: not ready 8191ms after resume; waiting
      radeon 0000:01:00.0: not ready 16383ms after resume; waiting
      radeon 0000:01:00.0: not ready 32767ms after resume; waiting
      radeon 0000:01:00.0: not ready 65535ms after resume; giving up
      radeon 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
    
    The issue is that the Root Port the dGPU is connected to can't handle the
    transition from D3cold to D0 so the dGPU can't properly exit runtime PM.
    
    The existing logic in pci_bridge_d3_possible() checks for systems that are
    newer than 2015 to decide that D3 is safe.  This would nominally work for
    an Ivy Bridge system (which was discontinued in 2015), but this system
    appears to have continued to receive BIOS updates until 2017 and so this
    existing logic doesn't appropriately capture it.
    
    Add the system to bridge_d3_blacklist to prevent D3cold from being used.
    
    Link: https://lore.kernel.org/r/20240307163709.323-1-mario.limonciello@amd.com
    Reported-by: Eric Heintzmann <heintzmann.eric@free.fr>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3229
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Tested-by: Eric Heintzmann <heintzmann.eric@free.fr>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI: Add PCI_ERROR_RESPONSE and related definitions [+ + +]
Author: Naveen Naidu <naveennaidu479@gmail.com>
Date:   Thu Nov 18 19:33:11 2021 +0530

    PCI: Add PCI_ERROR_RESPONSE and related definitions
    
    [ Upstream commit 57bdeef4716689d9b0e3571034d65cf420f6efcd ]
    
    A config or MMIO read from a PCI device that doesn't exist or doesn't
    respond causes a PCI error. There's no real data to return to satisfy the
    CPU read, so most hardware fabricates ~0 data.
    
    Add a PCI_ERROR_RESPONSE definition for that and use it where appropriate
    to make these checks consistent and easier to find.
    
    Also add helper definitions PCI_SET_ERROR_RESPONSE() and
    PCI_POSSIBLE_ERROR() to make the code more readable.
    
    Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
    Link: https://lore.kernel.org/r/55563bf4dfc5d3fdc96695373c659d099bf175b1.1637243717.git.naveennaidu479@gmail.com
    Signed-off-by: Naveen Naidu <naveennaidu479@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Pali Rohár <pali@kernel.org>
    Stable-dep-of: c625dabbf1c4 ("x86/amd_nb: Check for invalid SMN reads")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: rockchip-ep: Remove wrong mask on subsys_vendor_id [+ + +]
Author: Rick Wertenbroek <rick.wertenbroek@gmail.com>
Date:   Wed Apr 3 16:45:08 2024 +0200

    PCI: rockchip-ep: Remove wrong mask on subsys_vendor_id
    
    commit 2dba285caba53f309d6060fca911b43d63f41697 upstream.
    
    Remove wrong mask on subsys_vendor_id. Both the Vendor ID and Subsystem
    Vendor ID are u16 variables and are written to a u32 register of the
    controller. The Subsystem Vendor ID was always 0 because the u16 value
    was masked incorrectly with GENMASK(31,16) resulting in all lower 16
    bits being set to 0 prior to the shift.
    
    Remove both masks as they are unnecessary and set the register correctly
    i.e., the lower 16-bits are the Vendor ID and the upper 16-bits are the
    Subsystem Vendor ID.
    
    This is documented in the RK3399 TRM section 17.6.7.1.17
    
    [kwilczynski: removed unnecesary newline]
    Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller")
    Link: https://lore.kernel.org/linux-pci/20240403144508.489835-1-rick.wertenbroek@gmail.com
    Signed-off-by: Rick Wertenbroek <rick.wertenbroek@gmail.com>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf script: Show also errors for --insn-trace option [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri Mar 15 09:13:33 2024 +0200

    perf script: Show also errors for --insn-trace option
    
    [ Upstream commit d4a98b45fbe6d06f4b79ed90d0bb05ced8674c23 ]
    
    The trace could be misleading if trace errors are not taken into
    account, so display them also by adding the itrace "e" option.
    
    Note --call-trace and --call-ret-trace already add the itrace "e"
    option.
    
    Fixes: b585ebdb5912cf14 ("perf script: Add --insn-trace for instruction decoding")
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240315071334.3478-1-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/core: Fix missing wakeup when waiting for context reference [+ + +]
Author: Haifeng Xu <haifeng.xu@shopee.com>
Date:   Mon May 13 10:39:48 2024 +0000

    perf/core: Fix missing wakeup when waiting for context reference
    
    [ Upstream commit 74751ef5c1912ebd3e65c3b65f45587e05ce5d36 ]
    
    In our production environment, we found many hung tasks which are
    blocked for more than 18 hours. Their call traces are like this:
    
    [346278.191038] __schedule+0x2d8/0x890
    [346278.191046] schedule+0x4e/0xb0
    [346278.191049] perf_event_free_task+0x220/0x270
    [346278.191056] ? init_wait_var_entry+0x50/0x50
    [346278.191060] copy_process+0x663/0x18d0
    [346278.191068] kernel_clone+0x9d/0x3d0
    [346278.191072] __do_sys_clone+0x5d/0x80
    [346278.191076] __x64_sys_clone+0x25/0x30
    [346278.191079] do_syscall_64+0x5c/0xc0
    [346278.191083] ? syscall_exit_to_user_mode+0x27/0x50
    [346278.191086] ? do_syscall_64+0x69/0xc0
    [346278.191088] ? irqentry_exit_to_user_mode+0x9/0x20
    [346278.191092] ? irqentry_exit+0x19/0x30
    [346278.191095] ? exc_page_fault+0x89/0x160
    [346278.191097] ? asm_exc_page_fault+0x8/0x30
    [346278.191102] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    The task was waiting for the refcount become to 1, but from the vmcore,
    we found the refcount has already been 1. It seems that the task didn't
    get woken up by perf_event_release_kernel() and got stuck forever. The
    below scenario may cause the problem.
    
    Thread A                                        Thread B
    ...                                             ...
    perf_event_free_task                            perf_event_release_kernel
                                                       ...
                                                       acquire event->child_mutex
                                                       ...
                                                       get_ctx
       ...                                             release event->child_mutex
       acquire ctx->mutex
       ...
       perf_free_event (acquire/release event->child_mutex)
       ...
       release ctx->mutex
       wait_var_event
                                                       acquire ctx->mutex
                                                       acquire event->child_mutex
                                                       # move existing events to free_list
                                                       release event->child_mutex
                                                       release ctx->mutex
                                                       put_ctx
    ...                                             ...
    
    In this case, all events of the ctx have been freed, so we couldn't
    find the ctx in free_list and Thread A will miss the wakeup. It's thus
    necessary to add a wakeup after dropping the reference.
    
    Fixes: 1cf8dfe8a661 ("perf/core: Fix race between close() and fork()")
    Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/20240513103948.33570-1-haifeng.xu@shopee.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf: script: add raw|disasm arguments to --insn-trace option [+ + +]
Author: Changbin Du <changbin.du@huawei.com>
Date:   Sat Feb 17 15:40:45 2024 +0800

    perf: script: add raw|disasm arguments to --insn-trace option
    
    [ Upstream commit 6750ba4b6442fa5ea4bf5c0e4b4ff8b0249ef71d ]
    
    Now '--insn-trace' accept a argument to specify the output format:
      - raw: display raw instructions.
      - disasm: display mnemonic instructions (if capstone is installed).
    
    $ sudo perf script --insn-trace=raw
                  ls 1443864 [006] 2275506.209908875:      7f216b426100 _start+0x0 (/usr/lib/x86_64-linux-gnu/ld-2.31.so) insn: 48 89 e7
                  ls 1443864 [006] 2275506.209908875:      7f216b426103 _start+0x3 (/usr/lib/x86_64-linux-gnu/ld-2.31.so) insn: e8 e8 0c 00 00
                  ls 1443864 [006] 2275506.209908875:      7f216b426df0 _dl_start+0x0 (/usr/lib/x86_64-linux-gnu/ld-2.31.so) insn: f3 0f 1e fa
    
    $ sudo perf script --insn-trace=disasm
                  ls 1443864 [006] 2275506.209908875:      7f216b426100 _start+0x0 (/usr/lib/x86_64-linux-gnu/ld-2.31.so)           movq %rsp, %rdi
                  ls 1443864 [006] 2275506.209908875:      7f216b426103 _start+0x3 (/usr/lib/x86_64-linux-gnu/ld-2.31.so)           callq _dl_start+0x0
                  ls 1443864 [006] 2275506.209908875:      7f216b426df0 _dl_start+0x0 (/usr/lib/x86_64-linux-gnu/ld-2.31.so)        illegal instruction
                  ls 1443864 [006] 2275506.209908875:      7f216b426df4 _dl_start+0x4 (/usr/lib/x86_64-linux-gnu/ld-2.31.so)        pushq %rbp
                  ls 1443864 [006] 2275506.209908875:      7f216b426df5 _dl_start+0x5 (/usr/lib/x86_64-linux-gnu/ld-2.31.so)        movq %rsp, %rbp
                  ls 1443864 [006] 2275506.209908875:      7f216b426df8 _dl_start+0x8 (/usr/lib/x86_64-linux-gnu/ld-2.31.so)        pushq %r15
    
    Signed-off-by: Changbin Du <changbin.du@huawei.com>
    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: changbin.du@gmail.com
    Cc: Thomas Richter <tmricht@linux.ibm.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20240217074046.4100789-5-changbin.du@huawei.com
    Stable-dep-of: d4a98b45fbe6 ("perf script: Show also errors for --insn-trace option")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER [+ + +]
Author: Hagar Hemdan <hagarhem@amazon.com>
Date:   Tue Jun 4 08:58:38 2024 +0000

    pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
    
    [ Upstream commit adec57ff8e66aee632f3dd1f93787c13d112b7a1 ]
    
    In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
    add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
    calls pinctrl_free(). However, pinctrl_free() attempts to acquire
    pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
    a potential deadlock.
    
    This patch resolves the issue by releasing pinctrl_maps_mutex before
    calling pinctrl_free(), preventing the deadlock.
    
    This bug was discovered and resolved using Coverity Static Analysis
    Security Testing (SAST) by Synopsys, Inc.
    
    Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct")
    Suggested-by: Maximilian Heyne <mheyne@amazon.de>
    Signed-off-by: Hagar Hemdan <hagarhem@amazon.com>
    Link: https://lore.kernel.org/r/20240604085838.3344-1-hagarhem@amazon.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins [+ + +]
Author: Huang-Huang Bao <i@eh5.me>
Date:   Thu Jun 6 20:57:52 2024 +0800

    pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins
    
    [ Upstream commit e8448a6c817c2aa6c6af785b1d45678bd5977e8d ]
    
    The pinmux bits for GPIO2-B0 to GPIO2-B6 actually have 2 bits width,
    correct the bank flag for GPIO2-B. The pinmux bits for GPIO2-B7 is
    recalculated so it remain unchanged.
    
    The pinmux bits for those pins are not explicitly specified in RK3328
    TRM, however we can get hint from pad name and its correspinding IOMUX
    setting for pins in interface descriptions. The correspinding IOMIX
    settings for GPIO2-B0 to GPIO2-B6 can be found in the same row next to
    occurrences of following pad names in RK3328 TRM.
    
    GPIO2-B0: IO_SPIclkm0_GPIO2B0vccio5
    GPIO2-B1: IO_SPItxdm0_GPIO2B1vccio5
    GPIO2-B2: IO_SPIrxdm0_GPIO2B2vccio5
    GPIO2-B3: IO_SPIcsn0m0_GPIO2B3vccio5
    GPIO2-B4: IO_SPIcsn1m0_FLASHvol_sel_GPIO2B4vccio5
    GPIO2-B5: IO_ I2C2sda_TSADCshut_GPIO2B5vccio5
    GPIO2-B6: IO_ I2C2scl_GPIO2B6vccio5
    
    This fix has been tested on NanoPi R2S for fixing confliting pinmux bits
    between GPIO2-B7 with GPIO2-B5.
    
    Signed-off-by: Huang-Huang Bao <i@eh5.me>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Fixes: 3818e4a7678e ("pinctrl: rockchip: Add rk3328 pinctrl support")
    Link: https://lore.kernel.org/r/20240606125755.53778-2-i@eh5.me
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: rockchip: fix pinmux bits for RK3328 GPIO3-B pins [+ + +]
Author: Huang-Huang Bao <i@eh5.me>
Date:   Thu Jun 6 20:57:53 2024 +0800

    pinctrl: rockchip: fix pinmux bits for RK3328 GPIO3-B pins
    
    [ Upstream commit 5ef6914e0bf578357b4c906ffe6b26e7eedb8ccf ]
    
    The pinmux bits for GPIO3-B1 to GPIO3-B6 pins are not explicitly
    specified in RK3328 TRM, however we can get hint from pad name and its
    correspinding IOMUX setting for pins in interface descriptions. The
    correspinding IOMIX settings for these pins can be found in the same
    row next to occurrences of following pad names in RK3328 TRM.
    
    GPIO3-B1:  IO_TSPd5m0_CIFdata5m0_GPIO3B1vccio6
    GPIO3-B2: IO_TSPd6m0_CIFdata6m0_GPIO3B2vccio6
    GPIO3-B3: IO_TSPd7m0_CIFdata7m0_GPIO3B3vccio6
    GPIO3-B4: IO_CARDclkm0_GPIO3B4vccio6
    GPIO3-B5: IO_CARDrstm0_GPIO3B5vccio6
    GPIO3-B6: IO_CARDdetm0_GPIO3B6vccio6
    
    Add pinmux data to rk3328_mux_recalced_data as mux register offset for
    these pins does not follow rockchip convention.
    
    Signed-off-by: Huang-Huang Bao <i@eh5.me>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Fixes: 3818e4a7678e ("pinctrl: rockchip: Add rk3328 pinctrl support")
    Link: https://lore.kernel.org/r/20240606125755.53778-3-i@eh5.me
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: rockchip: fix pinmux reset in rockchip_pmx_set [+ + +]
Author: Huang-Huang Bao <i@eh5.me>
Date:   Thu Jun 6 20:57:55 2024 +0800

    pinctrl: rockchip: fix pinmux reset in rockchip_pmx_set
    
    [ Upstream commit 4ea4d4808e342ddf89ba24b93ffa2057005aaced ]
    
    rockchip_pmx_set reset all pinmuxs in group to 0 in the case of error,
    add missing bank data retrieval in that code to avoid setting mux on
    unexpected pins.
    
    Fixes: 14797189b35e ("pinctrl: rockchip: add return value to rockchip_set_mux")
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Huang-Huang Bao <i@eh5.me>
    Link: https://lore.kernel.org/r/20240606125755.53778-5-i@eh5.me
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: rockchip: use dedicated pinctrl type for RK3328 [+ + +]
Author: Huang-Huang Bao <i@eh5.me>
Date:   Thu Jun 6 20:57:54 2024 +0800

    pinctrl: rockchip: use dedicated pinctrl type for RK3328
    
    [ Upstream commit 01b4b1d1cec48ef4c26616c2fc4600b2c9fec05a ]
    
    rk3328_pin_ctrl uses type of RK3288 which has a hack in
    rockchip_pinctrl_suspend and rockchip_pinctrl_resume to restore GPIO6-C6
    at assume, the hack is not applicable to RK3328 as GPIO6 is not even
    exist in it. So use a dedicated pinctrl type to skip this hack.
    
    Fixes: 3818e4a7678e ("pinctrl: rockchip: Add rk3328 pinctrl support")
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Huang-Huang Bao <i@eh5.me>
    Link: https://lore.kernel.org/r/20240606125755.53778-4-i@eh5.me
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: dell-smbios-base: Use sysfs_emit() [+ + +]
Author: ye xingchen <ye.xingchen@zte.com.cn>
Date:   Fri Sep 23 06:32:33 2022 +0000

    platform/x86: dell-smbios-base: Use sysfs_emit()
    
    [ Upstream commit bbfa903b4f9a0a76719f386367fed5e64187f577 ]
    
    Replace the open-code with sysfs_emit() to simplify the code.
    
    Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
    Link: https://lore.kernel.org/r/20220923063233.239091-1-ye.xingchen@zte.com.cn
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Stable-dep-of: 1981b296f858 ("platform/x86: dell-smbios: Fix wrong token data in sysfs")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: dell-smbios: Fix wrong token data in sysfs [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Tue May 28 22:49:02 2024 +0200

    platform/x86: dell-smbios: Fix wrong token data in sysfs
    
    [ Upstream commit 1981b296f858010eae409548fd297659b2cc570e ]
    
    When reading token data from sysfs on my Inspiron 3505, the token
    locations and values are wrong. This happens because match_attribute()
    blindly assumes that all entries in da_tokens have an associated
    entry in token_attrs.
    
    This however is not true as soon as da_tokens[] contains zeroed
    token entries. Those entries are being skipped when initialising
    token_attrs, breaking the core assumption of match_attribute().
    
    Fix this by defining an extra struct for each pair of token attributes
    and use container_of() to retrieve token information.
    
    Tested on a Dell Inspiron 3050.
    
    Fixes: 33b9ca1e53b4 ("platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20240528204903.445546-1-W_Armin@gmx.de
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pmdomain: ti-sci: Fix duplicate PD referrals [+ + +]
Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Date:   Mon Apr 15 19:00:23 2024 +0300

    pmdomain: ti-sci: Fix duplicate PD referrals
    
    [ Upstream commit 670c900f69645db394efb38934b3344d8804171a ]
    
    When the dts file has multiple referrers to a single PD (e.g.
    simple-framebuffer and dss nodes both point to the DSS power-domain) the
    ti-sci driver will create two power domains, both with the same ID, and
    that will cause problems as one of the power domains will hide the other
    one.
    
    Fix this checking if a PD with the ID has already been created, and only
    create a PD for new IDs.
    
    Fixes: efa5c01cd7ee ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one")
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240415-ti-sci-pd-v1-1-a0e56b8ad897@ideasonboard.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
power: supply: cros_usbpd: provide ID table for avoiding fallback match [+ + +]
Author: Tzung-Bi Shih <tzungbi@kernel.org>
Date:   Mon Apr 1 11:00:49 2024 +0800

    power: supply: cros_usbpd: provide ID table for avoiding fallback match
    
    [ Upstream commit 0f8678c34cbfdc63569a9b0ede1fe235ec6ec693 ]
    
    Instead of using fallback driver name match, provide ID table[1] for the
    primary match.
    
    [1]: https://elixir.bootlin.com/linux/v6.8/source/drivers/base/platform.c#L1353
    
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Reviewed-by: Prashant Malani <pmalani@chromium.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
    Link: https://lore.kernel.org/r/20240401030052.2887845-4-tzungbi@kernel.org
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/io: Avoid clang null pointer arithmetic warnings [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri May 3 17:56:18 2024 +1000

    powerpc/io: Avoid clang null pointer arithmetic warnings
    
    [ Upstream commit 03c0f2c2b2220fc9cf8785cd7b61d3e71e24a366 ]
    
    With -Wextra clang warns about pointer arithmetic using a null pointer.
    When building with CONFIG_PCI=n, that triggers a warning in the IO
    accessors, eg:
    
      In file included from linux/arch/powerpc/include/asm/io.h:672:
      linux/arch/powerpc/include/asm/io-defs.h:23:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
         23 | DEF_PCI_AC_RET(inb, u8, (unsigned long port), (port), pio, port)
            | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ...
      linux/arch/powerpc/include/asm/io.h:591:53: note: expanded from macro '__do_inb'
        591 | #define __do_inb(port)          readb((PCI_IO_ADDR)_IO_BASE + port);
            |                                       ~~~~~~~~~~~~~~~~~~~~~ ^
    
    That is because when CONFIG_PCI=n, _IO_BASE is defined as 0.
    
    Although _IO_BASE is defined as plain 0, the cast (PCI_IO_ADDR) converts
    it to void * before the addition with port happens.
    
    Instead the addition can be done first, and then the cast. The resulting
    value will be the same, but avoids the warning, and also avoids void
    pointer arithmetic which is apparently non-standard.
    
    Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
    Closes: https://lore.kernel.org/all/CA+G9fYtEh8zmq8k8wE-8RZwW-Qr927RLTn+KqGnq1F=ptaaNsA@mail.gmail.com
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240503075619.394467-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/pseries: Enforce hcall result buffer validity and size [+ + +]
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Mon Apr 8 09:08:31 2024 -0500

    powerpc/pseries: Enforce hcall result buffer validity and size
    
    [ Upstream commit ff2e185cf73df480ec69675936c4ee75a445c3e4 ]
    
    plpar_hcall(), plpar_hcall9(), and related functions expect callers to
    provide valid result buffers of certain minimum size. Currently this
    is communicated only through comments in the code and the compiler has
    no idea.
    
    For example, if I write a bug like this:
    
      long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE
      plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);
    
    This compiles with no diagnostics emitted, but likely results in stack
    corruption at runtime when plpar_hcall9() stores results past the end
    of the array. (To be clear this is a contrived example and I have not
    found a real instance yet.)
    
    To make this class of error less likely, we can use explicitly-sized
    array parameters instead of pointers in the declarations for the hcall
    APIs. When compiled with -Warray-bounds[1], the code above now
    provokes a diagnostic like this:
    
    error: array argument is too small;
    is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]
       60 |                 plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,
          |                 ^                                   ~~~~~~
    
    [1] Enabled for LLVM builds but not GCC for now. See commit
        0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and
        related changes.
    
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240408-pseries-hvcall-retbuf-v1-1-ebc73d7253cf@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/uaccess: Fix build errors seen with GCC 13/14 [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed May 29 22:30:28 2024 +1000

    powerpc/uaccess: Fix build errors seen with GCC 13/14
    
    commit 2d43cc701b96f910f50915ac4c2a0cae5deb734c upstream.
    
    Building ppc64le_defconfig with GCC 14 fails with assembler errors:
    
        CC      fs/readdir.o
      /tmp/ccdQn0mD.s: Assembler messages:
      /tmp/ccdQn0mD.s:212: Error: operand out of domain (18 is not a multiple of 4)
      /tmp/ccdQn0mD.s:226: Error: operand out of domain (18 is not a multiple of 4)
      ... [6 lines]
      /tmp/ccdQn0mD.s:1699: Error: operand out of domain (18 is not a multiple of 4)
    
    A snippet of the asm shows:
    
      # ../fs/readdir.c:210:         unsafe_copy_dirent_name(dirent->d_name, name, namlen, efault_end);
             ld 9,0(29)       # MEM[(u64 *)name_38(D) + _88 * 1], MEM[(u64 *)name_38(D) + _88 * 1]
      # 210 "../fs/readdir.c" 1
             1:      std 9,18(8)     # put_user       # *__pus_addr_52, MEM[(u64 *)name_38(D) + _88 * 1]
    
    The 'std' instruction requires a 4-byte aligned displacement because
    it is a DS-form instruction, and as the assembler says, 18 is not a
    multiple of 4.
    
    A similar error is seen with GCC 13 and CONFIG_UBSAN_SIGNED_WRAP=y.
    
    The fix is to change the constraint on the memory operand to put_user(),
    from "m" which is a general memory reference to "YZ".
    
    The "Z" constraint is documented in the GCC manual PowerPC machine
    constraints, and specifies a "memory operand accessed with indexed or
    indirect addressing". "Y" is not documented in the manual but specifies
    a "memory operand for a DS-form instruction". Using both allows the
    compiler to generate a DS-form "std" or X-form "stdx" as appropriate.
    
    The change has to be conditional on CONFIG_PPC_KERNEL_PREFIXED because
    the "Y" constraint does not guarantee 4-byte alignment when prefixed
    instructions are enabled.
    
    Unfortunately clang doesn't support the "Y" constraint so that has to be
    behind an ifdef.
    
    Although the build error is only seen with GCC 13/14, that appears
    to just be luck. The constraint has been incorrect since it was first
    added.
    
    Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()")
    Cc: stable@vger.kernel.org # v5.10+
    Suggested-by: Kewen Lin <linkw@gcc.gnu.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240529123029.146953-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ptp: Fix error message on failed pin verification [+ + +]
Author: Karol Kolacinski <karol.kolacinski@intel.com>
Date:   Tue Jun 4 14:05:27 2024 +0200

    ptp: Fix error message on failed pin verification
    
    [ Upstream commit 323a359f9b077f382f4483023d096a4d316fd135 ]
    
    On failed verification of PTP clock pin, error message prints channel
    number instead of pin index after "pin", which is incorrect.
    
    Fix error message by adding channel number to the message and printing
    pin number instead of channel number.
    
    Fixes: 6092315dfdec ("ptp: introduce programmable pins.")
    Signed-off-by: Karol Kolacinski <karol.kolacinski@intel.com>
    Acked-by: Richard Cochran <richardcochran@gmail.com>
    Link: https://lore.kernel.org/r/20240604120555.16643-1-karol.kolacinski@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ptp: fix integer overflow in max_vclocks_store [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Mon Jun 17 12:34:32 2024 +0300

    ptp: fix integer overflow in max_vclocks_store
    
    [ Upstream commit 81d23d2a24012e448f651e007fac2cfd20a45ce0 ]
    
    On 32bit systems, the "4 * max" multiply can overflow.  Use kcalloc()
    to do the allocation to prevent this.
    
    Fixes: 44c494c8e30e ("ptp: track available ptp vclocks information")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Reviewed-by: Heng Qi <hengqi@linux.alibaba.com>
    Link: https://lore.kernel.org/r/ee8110ed-6619-4bd7-9024-28c1f2ac24f4@moroto.mountain
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pvpanic: Indentation fixes here and there [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Sun Aug 29 15:43:54 2021 +0300

    pvpanic: Indentation fixes here and there
    
    [ Upstream commit 84b0f12a953c4feff9994b1c4583ed18b441f482 ]
    
    1) replace double spaces with single;
    2) relax line width limitation a bit.
    
    Reviewed-by: Mihai Carabas <mihai.carabas@oracle.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20210829124354.81653-3-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: ee59be35d7a8 ("misc/pvpanic-pci: register attributes via pci_driver")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pvpanic: Keep single style across modules [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Sun Aug 29 15:43:52 2021 +0300

    pvpanic: Keep single style across modules
    
    [ Upstream commit 33a430419456991480cde9d8889e5a27f6049df4 ]
    
    We have different style on where we place module_*() and MODULE_*() macros.
    Inherit the style from the original module (now pvpanic-mmio.c).
    
    Reviewed-by: Mihai Carabas <mihai.carabas@oracle.com
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20210829124354.81653-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: ee59be35d7a8 ("misc/pvpanic-pci: register attributes via pci_driver")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pwm: stm32: Refuse too small period requests [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Date:   Fri Jun 21 16:37:12 2024 +0200

    pwm: stm32: Refuse too small period requests
    
    commit c45fcf46ca2368dafe7e5c513a711a6f0f974308 upstream.
    
    If period_ns is small, prd might well become 0. Catch that case because
    otherwise with
    
            regmap_write(priv->regmap, TIM_ARR, prd - 1);
    
    a few lines down quite a big period is configured.
    
    Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm")
    Cc: stable@vger.kernel.org
    Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com>
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
    Link: https://lore.kernel.org/r/b86f62f099983646f97eeb6bfc0117bb2d0c340d.1718979150.git.u.kleine-koenig@baylibre.com
    Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
qca_spi: Make interrupt remembering atomic [+ + +]
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Fri Jun 14 16:50:30 2024 +0200

    qca_spi: Make interrupt remembering atomic
    
    [ Upstream commit 2d7198278ece01818cd95a3beffbdf8b2a353fa0 ]
    
    The whole mechanism to remember occurred SPI interrupts is not atomic,
    which could lead to unexpected behavior. So fix this by using atomic bit
    operations instead.
    
    Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Link: https://lore.kernel.org/r/20240614145030.7781-1-wahrenst@gmx.net
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rcutorture: Fix invalid context warning when enable srcu barrier testing [+ + +]
Author: Zqiang <qiang.zhang1211@gmail.com>
Date:   Mon Mar 25 15:52:19 2024 +0800

    rcutorture: Fix invalid context warning when enable srcu barrier testing
    
    [ Upstream commit 668c0406d887467d53f8fe79261dda1d22d5b671 ]
    
    When the torture_type is set srcu or srcud and cb_barrier is
    non-zero, running the rcutorture test will trigger the
    following warning:
    
    [  163.910989][    C1] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
    [  163.910994][    C1] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
    [  163.910999][    C1] preempt_count: 10001, expected: 0
    [  163.911002][    C1] RCU nest depth: 0, expected: 0
    [  163.911005][    C1] INFO: lockdep is turned off.
    [  163.911007][    C1] irq event stamp: 30964
    [  163.911010][    C1] hardirqs last  enabled at (30963): [<ffffffffabc7df52>] do_idle+0x362/0x500
    [  163.911018][    C1] hardirqs last disabled at (30964): [<ffffffffae616eff>] sysvec_call_function_single+0xf/0xd0
    [  163.911025][    C1] softirqs last  enabled at (0): [<ffffffffabb6475f>] copy_process+0x16ff/0x6580
    [  163.911033][    C1] softirqs last disabled at (0): [<0000000000000000>] 0x0
    [  163.911038][    C1] Preemption disabled at:
    [  163.911039][    C1] [<ffffffffacf1964b>] stack_depot_save_flags+0x24b/0x6c0
    [  163.911063][    C1] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W          6.8.0-rc4-rt4-yocto-preempt-rt+ #3 1e39aa9a737dd024a3275c4f835a872f673a7d3a
    [  163.911071][    C1] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
    [  163.911075][    C1] Call Trace:
    [  163.911078][    C1]  <IRQ>
    [  163.911080][    C1]  dump_stack_lvl+0x88/0xd0
    [  163.911089][    C1]  dump_stack+0x10/0x20
    [  163.911095][    C1]  __might_resched+0x36f/0x530
    [  163.911105][    C1]  rt_spin_lock+0x82/0x1c0
    [  163.911112][    C1]  spin_lock_irqsave_ssp_contention+0xb8/0x100
    [  163.911121][    C1]  srcu_gp_start_if_needed+0x782/0xf00
    [  163.911128][    C1]  ? _raw_spin_unlock_irqrestore+0x46/0x70
    [  163.911136][    C1]  ? debug_object_active_state+0x336/0x470
    [  163.911148][    C1]  ? __pfx_srcu_gp_start_if_needed+0x10/0x10
    [  163.911156][    C1]  ? __pfx_lock_release+0x10/0x10
    [  163.911165][    C1]  ? __pfx_rcu_torture_barrier_cbf+0x10/0x10
    [  163.911188][    C1]  __call_srcu+0x9f/0xe0
    [  163.911196][    C1]  call_srcu+0x13/0x20
    [  163.911201][    C1]  srcu_torture_call+0x1b/0x30
    [  163.911224][    C1]  rcu_torture_barrier1cb+0x4a/0x60
    [  163.911247][    C1]  __flush_smp_call_function_queue+0x267/0xca0
    [  163.911256][    C1]  ? __pfx_rcu_torture_barrier1cb+0x10/0x10
    [  163.911281][    C1]  generic_smp_call_function_single_interrupt+0x13/0x20
    [  163.911288][    C1]  __sysvec_call_function_single+0x7d/0x280
    [  163.911295][    C1]  sysvec_call_function_single+0x93/0xd0
    [  163.911302][    C1]  </IRQ>
    [  163.911304][    C1]  <TASK>
    [  163.911308][    C1]  asm_sysvec_call_function_single+0x1b/0x20
    [  163.911313][    C1] RIP: 0010:default_idle+0x17/0x20
    [  163.911326][    C1] RSP: 0018:ffff888001997dc8 EFLAGS: 00000246
    [  163.911333][    C1] RAX: 0000000000000000 RBX: dffffc0000000000 RCX: ffffffffae618b51
    [  163.911337][    C1] RDX: 0000000000000000 RSI: ffffffffaea80920 RDI: ffffffffaec2de80
    [  163.911342][    C1] RBP: ffff888001997dc8 R08: 0000000000000001 R09: ffffed100d740cad
    [  163.911346][    C1] R10: ffffed100d740cac R11: ffff88806ba06563 R12: 0000000000000001
    [  163.911350][    C1] R13: ffffffffafe460c0 R14: ffffffffafe460c0 R15: 0000000000000000
    [  163.911358][    C1]  ? ct_kernel_exit.constprop.3+0x121/0x160
    [  163.911369][    C1]  ? lockdep_hardirqs_on+0xc4/0x150
    [  163.911376][    C1]  arch_cpu_idle+0x9/0x10
    [  163.911383][    C1]  default_idle_call+0x7a/0xb0
    [  163.911390][    C1]  do_idle+0x362/0x500
    [  163.911398][    C1]  ? __pfx_do_idle+0x10/0x10
    [  163.911404][    C1]  ? complete_with_flags+0x8b/0xb0
    [  163.911416][    C1]  cpu_startup_entry+0x58/0x70
    [  163.911423][    C1]  start_secondary+0x221/0x280
    [  163.911430][    C1]  ? __pfx_start_secondary+0x10/0x10
    [  163.911440][    C1]  secondary_startup_64_no_verify+0x17f/0x18b
    [  163.911455][    C1]  </TASK>
    
    This commit therefore use smp_call_on_cpu() instead of
    smp_call_function_single(), make rcu_torture_barrier1cb() invoked
    happens on task-context.
    
    Signed-off-by: Zqiang <qiang.zhang1211@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rcutorture: Fix rcu_torture_one_read() pipe_count overflow comment [+ + +]
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Wed Mar 6 19:21:47 2024 -0800

    rcutorture: Fix rcu_torture_one_read() pipe_count overflow comment
    
    [ Upstream commit 8b9b443fa860276822b25057cb3ff3b28734dec0 ]
    
    The "pipe_count > RCU_TORTURE_PIPE_LEN" check has a comment saying "Should
    not happen, but...".  This is only true when testing an RCU whose grace
    periods are always long enough.  This commit therefore fixes this comment.
    
    Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
    Closes: https://lore.kernel.org/lkml/CAHk-=wi7rJ-eGq+xaxVfzFEgbL9tdf6Kc8Z89rCpfcQOKm74Tw@mail.gmail.com/
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rcutorture: Make stall-tasks directly exit when rcutorture tests end [+ + +]
Author: Zqiang <qiang.zhang1211@gmail.com>
Date:   Thu Mar 21 16:28:50 2024 +0800

    rcutorture: Make stall-tasks directly exit when rcutorture tests end
    
    [ Upstream commit 431315a563015f259b28e34c5842f6166439e969 ]
    
    When the rcutorture tests start to exit, the rcu_torture_cleanup() is
    invoked to stop kthreads and release resources, if the stall-task
    kthreads exist, cpu-stall has started and the rcutorture.stall_cpu
    is set to a larger value, the rcu_torture_cleanup() will be blocked
    for a long time and the hung-task may occur, this commit therefore
    add kthread_should_stop() to the loop of cpu-stall operation, when
    rcutorture tests ends, no need to wait for cpu-stall to end, exit
    directly.
    
    Use the following command to test:
    
    insmod rcutorture.ko torture_type=srcu fwd_progress=0 stat_interval=4
    stall_cpu_block=1 stall_cpu=200 stall_cpu_holdoff=10 read_exit_burst=0
    object_debug=1
    rmmod rcutorture
    
    [15361.918610] INFO: task rmmod:878 blocked for more than 122 seconds.
    [15361.918613]       Tainted: G        W
    6.8.0-rc2-yoctodev-standard+ #25
    [15361.918615] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
    disables this message.
    [15361.918616] task:rmmod           state:D stack:0     pid:878
    tgid:878   ppid:773    flags:0x00004002
    [15361.918621] Call Trace:
    [15361.918623]  <TASK>
    [15361.918626]  __schedule+0xc0d/0x28f0
    [15361.918631]  ? __pfx___schedule+0x10/0x10
    [15361.918635]  ? rcu_is_watching+0x19/0xb0
    [15361.918638]  ? schedule+0x1f6/0x290
    [15361.918642]  ? __pfx_lock_release+0x10/0x10
    [15361.918645]  ? schedule+0xc9/0x290
    [15361.918648]  ? schedule+0xc9/0x290
    [15361.918653]  ? trace_preempt_off+0x54/0x100
    [15361.918657]  ? schedule+0xc9/0x290
    [15361.918661]  schedule+0xd0/0x290
    [15361.918665]  schedule_timeout+0x56d/0x7d0
    [15361.918669]  ? debug_smp_processor_id+0x1b/0x30
    [15361.918672]  ? rcu_is_watching+0x19/0xb0
    [15361.918676]  ? __pfx_schedule_timeout+0x10/0x10
    [15361.918679]  ? debug_smp_processor_id+0x1b/0x30
    [15361.918683]  ? rcu_is_watching+0x19/0xb0
    [15361.918686]  ? wait_for_completion+0x179/0x4c0
    [15361.918690]  ? __pfx_lock_release+0x10/0x10
    [15361.918693]  ? __kasan_check_write+0x18/0x20
    [15361.918696]  ? wait_for_completion+0x9d/0x4c0
    [15361.918700]  ? _raw_spin_unlock_irq+0x36/0x50
    [15361.918703]  ? wait_for_completion+0x179/0x4c0
    [15361.918707]  ? _raw_spin_unlock_irq+0x36/0x50
    [15361.918710]  ? wait_for_completion+0x179/0x4c0
    [15361.918714]  ? trace_preempt_on+0x54/0x100
    [15361.918718]  ? wait_for_completion+0x179/0x4c0
    [15361.918723]  wait_for_completion+0x181/0x4c0
    [15361.918728]  ? __pfx_wait_for_completion+0x10/0x10
    [15361.918738]  kthread_stop+0x152/0x470
    [15361.918742]  _torture_stop_kthread+0x44/0xc0 [torture
    7af7f9cbba28271a10503b653f9e05d518fbc8c3]
    [15361.918752]  rcu_torture_cleanup+0x2ac/0xe90 [rcutorture
    f2cb1f556ee7956270927183c4c2c7749a336529]
    [15361.918766]  ? __pfx_rcu_torture_cleanup+0x10/0x10 [rcutorture
    f2cb1f556ee7956270927183c4c2c7749a336529]
    [15361.918777]  ? __kasan_check_write+0x18/0x20
    [15361.918781]  ? __mutex_unlock_slowpath+0x17c/0x670
    [15361.918789]  ? __might_fault+0xcd/0x180
    [15361.918793]  ? find_module_all+0x104/0x1d0
    [15361.918799]  __x64_sys_delete_module+0x2a4/0x3f0
    [15361.918803]  ? __pfx___x64_sys_delete_module+0x10/0x10
    [15361.918807]  ? syscall_exit_to_user_mode+0x149/0x280
    
    Signed-off-by: Zqiang <qiang.zhang1211@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/mlx5: Add check for srq max_sge attribute [+ + +]
Author: Patrisious Haddad <phaddad@nvidia.com>
Date:   Tue May 28 15:52:56 2024 +0300

    RDMA/mlx5: Add check for srq max_sge attribute
    
    [ Upstream commit 36ab7ada64caf08f10ee5a114d39964d1f91e81d ]
    
    max_sge attribute is passed by the user, and is inserted and used
    unchecked, so verify that the value doesn't exceed maximum allowed value
    before using it.
    
    Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
    Signed-off-by: Patrisious Haddad <phaddad@nvidia.com>
    Link: https://lore.kernel.org/r/277ccc29e8d57bfd53ddeb2ac633f2760cf8cdd0.1716900410.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/restrack: Fix potential invalid address access [+ + +]
Author: Wenchao Hao <haowenchao2@huawei.com>
Date:   Mon Mar 18 17:23:20 2024 +0800

    RDMA/restrack: Fix potential invalid address access
    
    [ Upstream commit ca537a34775c103f7b14d7bbd976403f1d1525d8 ]
    
    struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME
    in ib_create_cq(), while if the module exited but forgot del this
    rdma_restrack_entry, it would cause a invalid address access in
    rdma_restrack_clean() when print the owner of this rdma_restrack_entry.
    
    These code is used to help find one forgotten PD release in one of the
    ULPs. But it is not needed anymore, so delete them.
    
    Signed-off-by: Wenchao Hao <haowenchao2@huawei.com>
    Link: https://lore.kernel.org/r/20240318092320.1215235-1-haowenchao2@huawei.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regulator: bd71815: fix ramp values [+ + +]
Author: Kalle Niemi <kaleposti@gmail.com>
Date:   Wed Jun 12 14:42:34 2024 +0300

    regulator: bd71815: fix ramp values
    
    [ Upstream commit 4cac29b846f38d5f0654cdfff5c5bfc37305081c ]
    
    Ramp values are inverted. This caused wrong values written to register
    when ramp values were defined in device tree.
    
    Invert values in table to fix this.
    
    Signed-off-by: Kalle Niemi <kaleposti@gmail.com>
    Fixes: 1aad39001e85 ("regulator: Support ROHM BD71815 regulators")
    Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
    Link: https://lore.kernel.org/r/ZmmJXtuVJU6RgQAH@latitude5580
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: core: Fix modpost error "regulator_get_regmap" undefined [+ + +]
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Mon Jun 10 20:55:32 2024 +0100

    regulator: core: Fix modpost error "regulator_get_regmap" undefined
    
    [ Upstream commit 3f60497c658d2072714d097a177612d34b34aa3d ]
    
    Fix the modpost error "regulator_get_regmap" undefined by adding export
    symbol.
    
    Fixes: 04eca28cde52 ("regulator: Add helpers for low-level register access")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202406110117.mk5UR3VZ-lkp@intel.com
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Link: https://lore.kernel.org/r/20240610195532.175942-1-biju.das.jz@bp.renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "kheaders: substituting --sort in archive creation" [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sun May 21 22:23:35 2023 +0900

    Revert "kheaders: substituting --sort in archive creation"
    
    [ Upstream commit 49c386ebbb43394ff4773ce24f726f6afc4c30c8 ]
    
    This reverts commit 700dea5a0bea9f64eba89fae7cb2540326fdfdc1.
    
    The reason for that commit was --sort=ORDER introduced in
    tar 1.28 (2014). More than 3 years have passed since then.
    
    Requiring GNU tar 1.28 should be fine now because we require
    GCC 5.1 (2015).
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
    Stable-dep-of: 3bd27a847a3a ("kheaders: explicitly define file modes for archived headers")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
riscv: fix overlap of allocated page and PTR_ERR [+ + +]
Author: Nam Cao <namcao@linutronix.de>
Date:   Thu Apr 25 13:52:01 2024 +0200

    riscv: fix overlap of allocated page and PTR_ERR
    
    [ Upstream commit 994af1825a2aa286f4903ff64a1c7378b52defe6 ]
    
    On riscv32, it is possible for the last page in virtual address space
    (0xfffff000) to be allocated. This page overlaps with PTR_ERR, so that
    shouldn't happen.
    
    There is already some code to ensure memblock won't allocate the last page.
    However, buddy allocator is left unchecked.
    
    Fix this by reserving physical memory that would be mapped at virtual
    addresses greater than 0xfffff000.
    
    Reported-by: Björn Töpel <bjorn@kernel.org>
    Closes: https://lore.kernel.org/linux-riscv/878r1ibpdn.fsf@all.your.base.are.belong.to.us
    Fixes: 76d2a0493a17 ("RISC-V: Init and Halt Code")
    Signed-off-by: Nam Cao <namcao@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Tested-by: Björn Töpel <bjorn@rivosinc.com>
    Reviewed-by: Björn Töpel <bjorn@rivosinc.com>
    Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org>
    Link: https://lore.kernel.org/r/20240425115201.3044202-1-namcao@linutronix.de
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

riscv: mm: init: try best to use IS_ENABLED(CONFIG_64BIT) instead of #ifdef [+ + +]
Author: Jisheng Zhang <jszhang@kernel.org>
Date:   Mon Dec 6 23:03:50 2021 +0800

    riscv: mm: init: try best to use IS_ENABLED(CONFIG_64BIT) instead of #ifdef
    
    [ Upstream commit 07aabe8fb6d1ac3163cc74c856521f2ee746270b ]
    
    Try our best to replace the conditional compilation using
    "#ifdef CONFIG_64BIT" by a check for "IS_ENABLED(CONFIG_64BIT)", to
    simplify the code and to increase compile coverage.
    
    Now we can also remove the __maybe_unused used in max_mapped_addr
    declaration.
    
    We also remove the BUG_ON check of mapping the last 4K bytes of the
    addressable memory since this is always true for every kernel actually.
    
    Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
    Reviewed-by: Alexandre Ghiti <alex@ghiti.fr>
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Stable-dep-of: 994af1825a2a ("riscv: fix overlap of allocated page and PTR_ERR")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rtlwifi: rtl8192de: Style clean-ups [+ + +]
Author: Kees Cook <kees@kernel.org>
Date:   Fri Nov 19 11:22:33 2021 -0800

    rtlwifi: rtl8192de: Style clean-ups
    
    [ Upstream commit 69831173fcbbfebb7aa2d76523deaf0b87b8eddd ]
    
    Clean up some style issues:
    - Use ARRAY_SIZE() even though it's a u8 array.
    - Remove redundant CHANNEL_MAX_NUMBER_2G define.
    Additionally fix some dead code WARNs.
    
    Acked-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://lore.kernel.org/lkml/57d0d1b6064342309f680f692192556c@realtek.com/
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211119192233.1021063-1-keescook@chromium.org
    Stable-dep-of: de4d4be4fa64 ("wifi: rtlwifi: rtl8192de: Fix 5 GHz TX power")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched: act_ct: add netns into the key of tcf_ct_flow_table [+ + +]
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sat Jun 15 17:47:30 2024 -0400

    sched: act_ct: add netns into the key of tcf_ct_flow_table
    
    [ Upstream commit 88c67aeb14070bab61d3dd8be96c8b42ebcaf53a ]
    
    zones_ht is a global hashtable for flow_table with zone as key. However,
    it does not consider netns when getting a flow_table from zones_ht in
    tcf_ct_init(), and it means an act_ct action in netns A may get a
    flow_table that belongs to netns B if it has the same zone value.
    
    In Shuang's test with the TOPO:
    
      tcf2_c <---> tcf2_sw1 <---> tcf2_sw2 <---> tcf2_s
    
    tcf2_sw1 and tcf2_sw2 saw the same flow and used the same flow table,
    which caused their ct entries entering unexpected states and the
    TCP connection not able to end normally.
    
    This patch fixes the issue simply by adding netns into the key of
    tcf_ct_flow_table so that an act_ct action gets a flow_table that
    belongs to its own netns in tcf_ct_init().
    
    Note that for easy coding we don't use tcf_ct_flow_table.nf_ft.net,
    as the ct_ft is initialized after inserting it to the hashtable in
    tcf_ct_flow_table_get() and also it requires to implement several
    functions in rhashtable_params including hashfn, obj_hashfn and
    obj_cmpfn.
    
    Fixes: 64ff70b80fd4 ("net/sched: act_ct: Offload established connections to flow table")
    Reported-by: Shuang Li <shuali@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/1db5b6cc6902c5fc6f8c6cbd85494a2008087be5.1718488050.git.lucien.xin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: mpi3mr: Fix ATA NCQ priority support [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Tue Jun 11 17:34:35 2024 +0900

    scsi: mpi3mr: Fix ATA NCQ priority support
    
    commit 90e6f08915ec6efe46570420412a65050ec826b2 upstream.
    
    The function mpi3mr_qcmd() of the mpi3mr driver is able to indicate to
    the HBA if a read or write command directed at an ATA device should be
    translated to an NCQ read/write command with the high prioiryt bit set
    when the request uses the RT priority class and the user has enabled NCQ
    priority through sysfs.
    
    However, unlike the mpt3sas driver, the mpi3mr driver does not define
    the sas_ncq_prio_supported and sas_ncq_prio_enable sysfs attributes, so
    the ncq_prio_enable field of struct mpi3mr_sdev_priv_data is never
    actually set and NCQ Priority cannot ever be used.
    
    Fix this by defining these missing atributes to allow a user to check if
    an ATA device supports NCQ priority and to enable/disable the use of NCQ
    priority. To do this, lift the function scsih_ncq_prio_supp() out of the
    mpt3sas driver and make it the generic SCSI SAS transport function
    sas_ata_ncq_prio_supported(). Nothing in that function is hardware
    specific, so this function can be used in both the mpt3sas driver and
    the mpi3mr driver.
    
    Reported-by: Scott McCoy <scott.mccoy@wdc.com>
    Fixes: 023ab2a9b4ed ("scsi: mpi3mr: Add support for queue command processing")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Link: https://lore.kernel.org/r/20240611083435.92961-1-dlemoal@kernel.org
    Reviewed-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory [+ + +]
Author: Breno Leitao <leitao@debian.org>
Date:   Wed Jun 5 01:55:29 2024 -0700

    scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory
    
    commit 4254dfeda82f20844299dca6c38cbffcfd499f41 upstream.
    
    There is a potential out-of-bounds access when using test_bit() on a single
    word. The test_bit() and set_bit() functions operate on long values, and
    when testing or setting a single word, they can exceed the word
    boundary. KASAN detects this issue and produces a dump:
    
             BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas
    
             Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965
    
    For full log, please look at [1].
    
    Make the allocation at least the size of sizeof(unsigned long) so that
    set_bit() and test_bit() have sufficient room for read/write operations
    without overwriting unallocated memory.
    
    [1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/
    
    Fixes: c696f7b83ede ("scsi: mpt3sas: Implement device_remove_in_progress check in IOCTL path")
    Cc: stable@vger.kernel.org
    Suggested-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Breno Leitao <leitao@debian.org>
    Link: https://lore.kernel.org/r/20240605085530.499432-1-leitao@debian.org
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qedi: Fix crash while reading debugfs attribute [+ + +]
Author: Manish Rangankar <mrangankar@marvell.com>
Date:   Mon Apr 15 12:51:55 2024 +0530

    scsi: qedi: Fix crash while reading debugfs attribute
    
    [ Upstream commit 28027ec8e32ecbadcd67623edb290dad61e735b5 ]
    
    The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly
    on a __user pointer, which results into the crash.
    
    To fix this issue, use a small local stack buffer for sprintf() and then
    call simple_read_from_buffer(), which in turns make the copy_to_user()
    call.
    
    BUG: unable to handle page fault for address: 00007f4801111000
    PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0
    Oops: 0002 [#1] PREEMPT SMP PTI
    Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023
    RIP: 0010:memcpy_orig+0xcd/0x130
    RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202
    RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f
    RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000
    RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572
    R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff
    R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af
    FS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? __die_body+0x1a/0x60
     ? page_fault_oops+0x183/0x510
     ? exc_page_fault+0x69/0x150
     ? asm_exc_page_fault+0x22/0x30
     ? memcpy_orig+0xcd/0x130
     vsnprintf+0x102/0x4c0
     sprintf+0x51/0x80
     qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]
     full_proxy_read+0x50/0x80
     vfs_read+0xa5/0x2e0
     ? folio_add_new_anon_rmap+0x44/0xa0
     ? set_pte_at+0x15/0x30
     ? do_pte_missing+0x426/0x7f0
     ksys_read+0xa5/0xe0
     do_syscall_64+0x58/0x80
     ? __count_memcg_events+0x46/0x90
     ? count_memcg_event_mm+0x3d/0x60
     ? handle_mm_fault+0x196/0x2f0
     ? do_user_addr_fault+0x267/0x890
     ? exc_page_fault+0x69/0x150
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    RIP: 0033:0x7f4800f20b4d
    
    Tested-by: Martin Hoyer <mhoyer@redhat.com>
    Reviewed-by: John Meneghini <jmeneghi@redhat.com>
    Signed-off-by: Manish Rangankar <mrangankar@marvell.com>
    Link: https://lore.kernel.org/r/20240415072155.30840-1-mrangankar@marvell.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors [+ + +]
Author: Jianguo Wu <wujianguo@chinatelecom.cn>
Date:   Thu Jun 13 17:42:46 2024 +0800

    seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors
    
    [ Upstream commit 9a3bc8d16e0aacd65c31aaf23a2bced3288a7779 ]
    
    input_action_end_dx4() and input_action_end_dx6() are called NF_HOOK() for
    PREROUTING hook, in PREROUTING hook, we should passing a valid indev,
    and a NULL outdev to NF_HOOK(), otherwise may trigger a NULL pointer
    dereference, as below:
    
        [74830.647293] BUG: kernel NULL pointer dereference, address: 0000000000000090
        [74830.655633] #PF: supervisor read access in kernel mode
        [74830.657888] #PF: error_code(0x0000) - not-present page
        [74830.659500] PGD 0 P4D 0
        [74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI
        ...
        [74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
        [74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter]
        ...
        [74830.689725] Call Trace:
        [74830.690402]  <IRQ>
        [74830.690953]  ? show_trace_log_lvl+0x1c4/0x2df
        [74830.692020]  ? show_trace_log_lvl+0x1c4/0x2df
        [74830.693095]  ? ipt_do_table+0x286/0x710 [ip_tables]
        [74830.694275]  ? __die_body.cold+0x8/0xd
        [74830.695205]  ? page_fault_oops+0xac/0x140
        [74830.696244]  ? exc_page_fault+0x62/0x150
        [74830.697225]  ? asm_exc_page_fault+0x22/0x30
        [74830.698344]  ? rpfilter_mt+0x44/0x15e [ipt_rpfilter]
        [74830.699540]  ipt_do_table+0x286/0x710 [ip_tables]
        [74830.700758]  ? ip6_route_input+0x19d/0x240
        [74830.701752]  nf_hook_slow+0x3f/0xb0
        [74830.702678]  input_action_end_dx4+0x19b/0x1e0
        [74830.703735]  ? input_action_end_t+0xe0/0xe0
        [74830.704734]  seg6_local_input_core+0x2d/0x60
        [74830.705782]  lwtunnel_input+0x5b/0xb0
        [74830.706690]  __netif_receive_skb_one_core+0x63/0xa0
        [74830.707825]  process_backlog+0x99/0x140
        [74830.709538]  __napi_poll+0x2c/0x160
        [74830.710673]  net_rx_action+0x296/0x350
        [74830.711860]  __do_softirq+0xcb/0x2ac
        [74830.713049]  do_softirq+0x63/0x90
    
    input_action_end_dx4() passing a NULL indev to NF_HOOK(), and finally
    trigger a NULL dereference in rpfilter_mt()->rpfilter_is_loopback():
    
        static bool
        rpfilter_is_loopback(const struct sk_buff *skb,
                           const struct net_device *in)
        {
                // in is NULL
                return skb->pkt_type == PACKET_LOOPBACK ||
                     in->flags & IFF_LOOPBACK;
        }
    
    Fixes: 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane")
    Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/bpf: Fix flaky test btf_map_in_map/lookup_update [+ + +]
Author: Yonghong Song <yonghong.song@linux.dev>
Date:   Thu Mar 21 23:13:53 2024 -0700

    selftests/bpf: Fix flaky test btf_map_in_map/lookup_update
    
    [ Upstream commit 14bb1e8c8d4ad5d9d2febb7d19c70a3cf536e1e5 ]
    
    Recently, I frequently hit the following test failure:
    
      [root@arch-fb-vm1 bpf]# ./test_progs -n 33/1
      test_lookup_update:PASS:skel_open 0 nsec
      [...]
      test_lookup_update:PASS:sync_rcu 0 nsec
      test_lookup_update:FAIL:map1_leak inner_map1 leaked!
      #33/1    btf_map_in_map/lookup_update:FAIL
      #33      btf_map_in_map:FAIL
    
    In the test, after map is closed and then after two rcu grace periods,
    it is assumed that map_id is not available to user space.
    
    But the above assumption cannot be guaranteed. After zero or one
    or two rcu grace periods in different siturations, the actual
    freeing-map-work is put into a workqueue. Later on, when the work
    is dequeued, the map will be actually freed.
    See bpf_map_put() in kernel/bpf/syscall.c.
    
    By using workqueue, there is no ganrantee that map will be actually
    freed after a couple of rcu grace periods. This patch removed
    such map leak detection and then the test can pass consistently.
    
    Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20240322061353.632136-1-yonghong.song@linux.dev
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/bpf: Prevent client connect before server bind in test_tc_tunnel.sh [+ + +]
Author: Alessandro Carminati (Red Hat) <alessandro.carminati@gmail.com>
Date:   Thu Mar 14 10:59:11 2024 +0000

    selftests/bpf: Prevent client connect before server bind in test_tc_tunnel.sh
    
    [ Upstream commit f803bcf9208a2540acb4c32bdc3616673169f490 ]
    
    In some systems, the netcat server can incur in delay to start listening.
    When this happens, the test can randomly fail in various points.
    This is an example error message:
    
       # ip gre none gso
       # encap 192.168.1.1 to 192.168.1.2, type gre, mac none len 2000
       # test basic connectivity
       # Ncat: Connection refused.
    
    The issue stems from a race condition between the netcat client and server.
    The test author had addressed this problem by implementing a sleep, which
    I have removed in this patch.
    This patch introduces a function capable of sleeping for up to two seconds.
    However, it can terminate the waiting period early if the port is reported
    to be listening.
    
    Signed-off-by: Alessandro Carminati (Red Hat) <alessandro.carminati@gmail.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20240314105911.213411-1-alessandro.carminati@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/mm: compaction_test: fix bogus test success on Aarch64 [+ + +]
Author: Dev Jain <dev.jain@arm.com>
Date:   Tue May 21 13:13:56 2024 +0530

    selftests/mm: compaction_test: fix bogus test success on Aarch64
    
    [ Upstream commit d4202e66a4b1fe6968f17f9f09bbc30d08f028a1 ]
    
    Patch series "Fixes for compaction_test", v2.
    
    The compaction_test memory selftest introduces fragmentation in memory
    and then tries to allocate as many hugepages as possible. This series
    addresses some problems.
    
    On Aarch64, if nr_hugepages == 0, then the test trivially succeeds since
    compaction_index becomes 0, which is less than 3, due to no division by
    zero exception being raised. We fix that by checking for division by
    zero.
    
    Secondly, correctly set the number of hugepages to zero before trying
    to set a large number of them.
    
    Now, consider a situation in which, at the start of the test, a non-zero
    number of hugepages have been already set (while running the entire
    selftests/mm suite, or manually by the admin). The test operates on 80%
    of memory to avoid OOM-killer invocation, and because some memory is
    already blocked by hugepages, it would increase the chance of OOM-killing.
    Also, since mem_free used in check_compaction() is the value before we
    set nr_hugepages to zero, the chance that the compaction_index will
    be small is very high if the preset nr_hugepages was high, leading to a
    bogus test success.
    
    This patch (of 3):
    
    Currently, if at runtime we are not able to allocate a huge page, the test
    will trivially pass on Aarch64 due to no exception being raised on
    division by zero while computing compaction_index.  Fix that by checking
    for nr_hugepages == 0.  Anyways, in general, avoid a division by zero by
    exiting the program beforehand.  While at it, fix a typo, and handle the
    case where the number of hugepages may overflow an integer.
    
    Link: https://lkml.kernel.org/r/20240521074358.675031-1-dev.jain@arm.com
    Link: https://lkml.kernel.org/r/20240521074358.675031-2-dev.jain@arm.com
    Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory")
    Signed-off-by: Dev Jain <dev.jain@arm.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Sri Jayaramappa <sjayaram@akamai.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages [+ + +]
Author: Dev Jain <dev.jain@arm.com>
Date:   Tue May 21 13:13:57 2024 +0530

    selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages
    
    [ Upstream commit 9ad665ef55eaad1ead1406a58a34f615a7c18b5e ]
    
    Currently, the test tries to set nr_hugepages to zero, but that is not
    actually done because the file offset is not reset after read().  Fix that
    using lseek().
    
    Link: https://lkml.kernel.org/r/20240521074358.675031-3-dev.jain@arm.com
    Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory")
    Signed-off-by: Dev Jain <dev.jain@arm.com>
    Cc: <stable@vger.kernel.org>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Sri Jayaramappa <sjayaram@akamai.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

selftests/mm: conform test to TAP format output [+ + +]
Author: Muhammad Usama Anjum <usama.anjum@collabora.com>
Date:   Mon Jan 1 13:36:12 2024 +0500

    selftests/mm: conform test to TAP format output
    
    [ Upstream commit 9a21701edc41465de56f97914741bfb7bfc2517d ]
    
    Conform the layout, informational and status messages to TAP.  No
    functional change is intended other than the layout of output messages.
    
    Link: https://lkml.kernel.org/r/20240101083614.1076768-1-usama.anjum@collabora.com
    Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Cc: Shuah Khan <shuah@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: d4202e66a4b1 ("selftests/mm: compaction_test: fix bogus test success on Aarch64")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: 8250_omap: Fix Errata i2310 with RX FIFO level check [+ + +]
Author: Udit Kumar <u-kumar1@ti.com>
Date:   Tue Jun 25 21:37:25 2024 +0530

    serial: 8250_omap: Fix Errata i2310 with RX FIFO level check
    
    commit c128a1b0523b685c8856ddc0ac0e1caef1fdeee5 upstream.
    
    Errata i2310[0] says, Erroneous timeout can be triggered,
    if this Erroneous interrupt is not cleared then it may leads
    to storm of interrupts.
    
    Commit 9d141c1e6157 ("serial: 8250_omap: Implementation of Errata i2310")
    which added the workaround but missed ensuring RX FIFO is really empty
    before applying the errata workaround as recommended in the errata text.
    Fix this by adding back check for UART_OMAP_RX_LVL to be 0 for
    workaround to take effect.
    
    [0] https://www.ti.com/lit/pdf/sprz536 page 23
    
    Fixes: 9d141c1e6157 ("serial: 8250_omap: Implementation of Errata i2310")
    Cc: stable@vger.kernel.org
    Reported-by: Vignesh Raghavendra <vigneshr@ti.com>
    Closes: https://lore.kernel.org/all/e96d0c55-0b12-4cbf-9d23-48963543de49@ti.com/
    Signed-off-by: Udit Kumar <u-kumar1@ti.com>
    Link: https://lore.kernel.org/r/20240625160725.2102194-1-u-kumar1@ti.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8250_omap: Implementation of Errata i2310 [+ + +]
Author: Udit Kumar <u-kumar1@ti.com>
Date:   Wed Jun 19 16:29:03 2024 +0530

    serial: 8250_omap: Implementation of Errata i2310
    
    commit 9d141c1e615795eeb93cd35501ad144ee997a826 upstream.
    
    As per Errata i2310[0], Erroneous timeout can be triggered,
    if this Erroneous interrupt is not cleared then it may leads
    to storm of interrupts, therefore apply Errata i2310 solution.
    
    [0] https://www.ti.com/lit/pdf/sprz536 page 23
    
    Fixes: b67e830d38fa ("serial: 8250: 8250_omap: Fix possible interrupt storm on K3 SoCs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Udit Kumar <u-kumar1@ti.com>
    Link: https://lore.kernel.org/r/20240619105903.165434-1-u-kumar1@ti.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: 8250_pxa: Configure tx_loadsz to match FIFO IRQ level [+ + +]
Author: Doug Brown <doug@schmorgal.com>
Date:   Sun May 19 12:19:30 2024 -0700

    serial: 8250_pxa: Configure tx_loadsz to match FIFO IRQ level
    
    commit 5208e7ced520a813b4f4774451fbac4e517e78b2 upstream.
    
    The FIFO is 64 bytes, but the FCR is configured to fire the TX interrupt
    when the FIFO is half empty (bit 3 = 0). Thus, we should only write 32
    bytes when a TX interrupt occurs.
    
    This fixes a problem observed on the PXA168 that dropped a bunch of TX
    bytes during large transmissions.
    
    Fixes: ab28f51c77cd ("serial: rewrite pxa2xx-uart to use 8250_core")
    Signed-off-by: Doug Brown <doug@schmorgal.com>
    Link: https://lore.kernel.org/r/20240519191929.122202-1-doug@schmorgal.com
    Cc: stable <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: exar: adding missing CTI and Exar PCI ids [+ + +]
Author: Parker Newman <pnewman@connecttech.com>
Date:   Tue Apr 16 08:55:28 2024 -0400

    serial: exar: adding missing CTI and Exar PCI ids
    
    [ Upstream commit b86ae40ffcf5a16b9569b1016da4a08c4f352ca2 ]
    
    - Added Connect Tech and Exar IDs not already in pci_ids.h
    
    Signed-off-by: Parker Newman <pnewman@connecttech.com>
    Link: https://lore.kernel.org/r/7c3d8e795a864dd9b0a00353b722060dc27c4e09.1713270624.git.pnewman@connecttech.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: imx: Introduce timeout when waiting on transmitter empty [+ + +]
Author: Esben Haabendal <esben@geanix.com>
Date:   Thu Apr 11 14:19:23 2024 +0200

    serial: imx: Introduce timeout when waiting on transmitter empty
    
    [ Upstream commit e533e4c62e9993e62e947ae9bbec34e4c7ae81c2 ]
    
    By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential
    deadlock.
    
    In case of the timeout, there is not much we can do, so we simply ignore
    the transmitter state and optimistically try to continue.
    
    Signed-off-by: Esben Haabendal <esben@geanix.com>
    Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Link: https://lore.kernel.org/r/919647898c337a46604edcabaf13d42d80c0915d.1712837613.git.esben@geanix.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: sc16is7xx: fix bug in sc16is7xx_set_baud() when using prescaler [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Tue Apr 30 16:04:30 2024 -0400

    serial: sc16is7xx: fix bug in sc16is7xx_set_baud() when using prescaler
    
    [ Upstream commit 8492bd91aa055907c67ef04f2b56f6dadd1f44bf ]
    
    When using a high speed clock with a low baud rate, the 4x prescaler is
    automatically selected if required. In that case, sc16is7xx_set_baud()
    properly configures the chip registers, but returns an incorrect baud
    rate by not taking into account the prescaler value. This incorrect baud
    rate is then fed to uart_update_timeout().
    
    For example, with an input clock of 80MHz, and a selected baud rate of 50,
    sc16is7xx_set_baud() will return 200 instead of 50.
    
    Fix this by first changing the prescaler variable to hold the selected
    prescaler value instead of the MCR bitfield. Then properly take into
    account the selected prescaler value in the return value computation.
    
    Also add better documentation about the divisor value computation.
    
    Fixes: dfeae619d781 ("serial: sc16is7xx")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/20240430200431.4102923-1-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: sc16is7xx: replace hardcoded divisor value with BIT() macro [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Thu Dec 21 18:18:19 2023 -0500

    serial: sc16is7xx: replace hardcoded divisor value with BIT() macro
    
    [ Upstream commit 2e57cefc4477659527f7adab1f87cdbf60ef1ae6 ]
    
    To better show why the limit is what it is, since we have only 16 bits for
    the divisor.
    
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20231221231823.2327894-13-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 8492bd91aa05 ("serial: sc16is7xx: fix bug in sc16is7xx_set_baud() when using prescaler")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: stm32: rework RX over DMA [+ + +]
Author: Erwan Le Ray <erwan.leray@foss.st.com>
Date:   Wed Oct 20 17:03:31 2021 +0200

    serial: stm32: rework RX over DMA
    
    commit 33bb2f6ac3088936b7aad3cab6f439f91af0223c upstream.
    
    This patch reworks RX support over DMA to improve reliability:
    - change dma buffer cyclic configuration by using 2 periods. DMA buffer
    data are handled by a flip-flop between the 2 periods in order to avoid
    risk of data loss/corruption
    - change the size of dma buffer to 4096 to limit overruns
    - add rx errors management (breaks, parity, framing and overrun).
      When an error occurs on the uart line, the dma request line is masked at
      HW level. The SW must 1st clear DMAR (dma request line enable), to
      handle the error, then re-enable DMAR to recover. So, any correct data
      is taken from the DMA buffer, before handling the error itself. Then
      errors are handled from RDR/ISR/FIFO (e.g. in PIO mode). Last, DMA
      reception is resumed.
    - add a condition on DMA request line in DMA RX routines in order to
    switch to PIO mode when no DMA request line is disabled, even if the DMA
    channel is still enabled.
      When the UART is wakeup source and is configured to use DMA for RX, any
      incoming data that wakes up the system isn't correctly received.
      At data reception, the irq_handler handles the WUF irq, and then the
      data reception over DMA.
      As the DMA transfer has been terminated at suspend, and will be restored
      by resume callback (which has no yet been called by system), the data
      can't be received.
      The wake-up data has to be handled in PIO mode while suspend callback
      has not been called.
    
    Signed-off-by: Valentin Caron <valentin.caron@foss.st.com>
    Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com>
    Link: https://lore.kernel.org/r/20211020150332.10214-3-erwan.leray@foss.st.com
    [ dario: fix conflicts for backport to v5.15. From the [1] series, only the
      first patch was applied to the v5.15 branch. This caused a regression in
      character reception, which can be fixed by applying the second patch. The
      patch has been tested on the stm32f469-disco board.
      [1] https://lore.kernel.org/all/20211020150332.10214-1-erwan.leray@foss.st.com/. ]
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sh: rework sync_file_range ABI [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jun 11 22:12:43 2024 +0200

    sh: rework sync_file_range ABI
    
    commit 30766f1105d6d2459c3b9fe34a3e52b637a72950 upstream.
    
    The unusual function calling conventions on SuperH ended up causing
    sync_file_range to have the wrong argument order, with the 'flags'
    argument getting sorted before 'nbytes' by the compiler.
    
    In userspace, I found that musl, glibc, uclibc and strace all expect the
    normal calling conventions with 'nbytes' last, so changing the kernel
    to match them should make all of those work.
    
    In order to be able to also fix libc implementations to work with existing
    kernels, they need to be able to tell which ABI is used. An easy way
    to do this is to add yet another system call using the sync_file_range2
    ABI that works the same on all architectures.
    
    Old user binaries can now work on new kernels, and new binaries can
    try the new sync_file_range2() to work with new kernels or fall back
    to the old sync_file_range() version if that doesn't exist.
    
    Cc: stable@vger.kernel.org
    Fixes: 75c92acdd5b1 ("sh: Wire up new syscalls.")
    Acked-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
skbuff: introduce skb_pull_data [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Dec 1 10:54:52 2021 -0800

    skbuff: introduce skb_pull_data
    
    [ Upstream commit 13244cccc2b61ec715f0ac583d3037497004d4a5 ]
    
    Like skb_pull but returns the original data pointer before pulling the
    data after performing a check against sbk->len.
    
    This allows to change code that does "struct foo *p = (void *)skb->data;"
    which is hard to audit and error prone, to:
    
            p = skb_pull_data(skb, sizeof(*p));
            if (!p)
                    return;
    
    Which is both safer and cleaner.
    
    Acked-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Stable-dep-of: cda0d6a198e2 ("Bluetooth: qca: fix info leak when fetching fw build id")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
smb: client: fix deadlock in smb2_find_smb_tcon() [+ + +]
Author: Enzo Matsumiya <ematsumiya@suse.de>
Date:   Thu Jun 6 13:13:13 2024 -0300

    smb: client: fix deadlock in smb2_find_smb_tcon()
    
    [ Upstream commit 02c418774f76a0a36a6195c9dbf8971eb4130a15 ]
    
    Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such
    deadlock.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
    Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
    Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
soc: ti: wkup_m3_ipc: Send NULL dummy message instead of pointer message [+ + +]
Author: Andrew Davis <afd@ti.com>
Date:   Mon Mar 25 11:55:07 2024 -0500

    soc: ti: wkup_m3_ipc: Send NULL dummy message instead of pointer message
    
    [ Upstream commit ddbf3204f600a4d1f153498f618369fca352ae00 ]
    
    mbox_send_message() sends a u32 bit message, not a pointer to a message.
    We only convert to a pointer type as a generic type. If we want to send
    a dummy message of 0, then simply send 0 (NULL).
    
    Signed-off-by: Andrew Davis <afd@ti.com>
    Link: https://lore.kernel.org/r/20240325165507.30323-1-afd@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sock_map: avoid race between sock_map_close and sk_psock_put [+ + +]
Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Date:   Fri May 24 11:47:02 2024 -0300

    sock_map: avoid race between sock_map_close and sk_psock_put
    
    commit 4b4647add7d3c8530493f7247d11e257ee425bf0 upstream.
    
    sk_psock_get will return NULL if the refcount of psock has gone to 0, which
    will happen when the last call of sk_psock_put is done. However,
    sk_psock_drop may not have finished yet, so the close callback will still
    point to sock_map_close despite psock being NULL.
    
    This can be reproduced with a thread deleting an element from the sock map,
    while the second one creates a socket, adds it to the map and closes it.
    
    That will trigger the WARN_ON_ONCE:
    
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
    Modules linked in:
    CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
    RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
    Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02
    RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293
    RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000
    RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0
    RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3
    R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840
    R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870
    FS:  000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0
    Call Trace:
     <TASK>
     unix_release+0x87/0xc0 net/unix/af_unix.c:1048
     __sock_release net/socket.c:659 [inline]
     sock_close+0xbe/0x240 net/socket.c:1421
     __fput+0x42b/0x8a0 fs/file_table.c:422
     __do_sys_close fs/open.c:1556 [inline]
     __se_sys_close fs/open.c:1541 [inline]
     __x64_sys_close+0x7f/0x110 fs/open.c:1541
     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
    RIP: 0033:0x7fb37d618070
    Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c
    RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
    RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070
    RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004
    RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000
    R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
     </TASK>
    
    Use sk_psock, which will only check that the pointer is not been set to
    NULL yet, which should only happen after the callbacks are restored. If,
    then, a reference can still be gotten, we may call sk_psock_stop and cancel
    psock->work.
    
    As suggested by Paolo Abeni, reorder the condition so the control flow is
    less convoluted.
    
    After that change, the reproducer does not trigger the WARN_ON_ONCE
    anymore.
    
    Suggested-by: Paolo Abeni <pabeni@redhat.com>
    Reported-by: syzbot+07a2e4a1a57118ef7355@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=07a2e4a1a57118ef7355
    Fixes: aadb2bb83ff7 ("sock_map: Fix a potential use-after-free in sock_map_close()")
    Fixes: 5b4a79ba65a1 ("bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself")
    Cc: stable@vger.kernel.org
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/r/20240524144702.1178377-1-cascardo@igalia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sparc: fix compat recv/recvfrom syscalls [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jun 19 12:49:39 2024 +0200

    sparc: fix compat recv/recvfrom syscalls
    
    [ Upstream commit d6fbd26fb872ec518d25433a12e8ce8163e20909 ]
    
    sparc has the wrong compat version of recv() and recvfrom() for both the
    direct syscalls and socketcall().
    
    The direct syscalls just need to use the compat version. For socketcall,
    the same thing could be done, but it seems better to completely remove
    the custom assembler code for it and just use the same implementation that
    everyone else has.
    
    Fixes: 1dacc76d0014 ("net/compat/wext: send different messages to compat tasks")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

sparc: fix old compat_sys_select() [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jun 19 14:07:30 2024 +0200

    sparc: fix old compat_sys_select()
    
    [ Upstream commit bae6428a9fffb2023191b0723e276cf1377a7c9f ]
    
    sparc has two identical select syscalls at numbers 93 and 230, respectively.
    During the conversion to the modern syscall.tbl format, the older one of the
    two broke in compat mode, and now refers to the native 64-bit syscall.
    
    Restore the correct behavior. This has very little effect, as glibc has
    been using the newer number anyway.
    
    Fixes: 6ff645dd683a ("sparc: add system call table generation support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spmi: hisi-spmi-controller: Do not override device identifier [+ + +]
Author: Vamshi Gajjela <vamshigajjela@google.com>
Date:   Tue May 7 14:07:41 2024 -0700

    spmi: hisi-spmi-controller: Do not override device identifier
    
    commit eda4923d78d634482227c0b189d9b7ca18824146 upstream.
    
    'nr' member of struct spmi_controller, which serves as an identifier
    for the controller/bus. This value is a dynamic ID assigned in
    spmi_controller_alloc, and overriding it from the driver results in an
    ida_free error "ida_free called for id=xx which is not allocated".
    
    Signed-off-by: Vamshi Gajjela <vamshigajjela@google.com>
    Fixes: 70f59c90c819 ("staging: spmi: add Hikey 970 SPMI controller driver")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240228185116.1269-1-vamshigajjela@google.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Link: https://lore.kernel.org/r/20240507210809.3479953-5-sboyd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
SUNRPC: return proper error from gss_wrap_req_priv [+ + +]
Author: Chen Hanxiao <chenhx.fnst@fujitsu.com>
Date:   Thu May 23 16:47:16 2024 +0800

    SUNRPC: return proper error from gss_wrap_req_priv
    
    [ Upstream commit 33c94d7e3cb84f6d130678d6d59ba475a6c489cf ]
    
    don't return 0 if snd_buf->len really greater than snd_buf->buflen
    
    Signed-off-by: Chen Hanxiao <chenhx.fnst@fujitsu.com>
    Fixes: 0c77668ddb4e ("SUNRPC: Introduce trace points in rpc_auth_gss.ko")
    Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
syscalls: fix compat_sys_io_pgetevents_time64 usage [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Jun 20 14:16:37 2024 +0200

    syscalls: fix compat_sys_io_pgetevents_time64 usage
    
    commit d3882564a77c21eb746ba5364f3fa89b88de3d61 upstream.
    
    Using sys_io_pgetevents() as the entry point for compat mode tasks
    works almost correctly, but misses the sign extension for the min_nr
    and nr arguments.
    
    This was addressed on parisc by switching to
    compat_sys_io_pgetevents_time64() in commit 6431e92fc827 ("parisc:
    io_pgetevents_time64() needs compat syscall in 32-bit compat mode"),
    as well as by using more sophisticated system call wrappers on x86 and
    s390. However, arm64, mips, powerpc, sparc and riscv still have the
    same bug.
    
    Change all of them over to use compat_sys_io_pgetevents_time64()
    like parisc already does. This was clearly the intention when the
    function was originally added, but it got hooked up incorrectly in
    the tables.
    
    Cc: stable@vger.kernel.org
    Fixes: 48166e6ea47d ("y2038: add 64-bit time_t syscalls to all 32-bit architectures")
    Acked-by: Heiko Carstens <hca@linux.ibm.com> # s390
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

syscalls: fix sys_fanotify_mark prototype [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sat Jun 29 21:48:41 2024 +0200

    syscalls: fix sys_fanotify_mark prototype
    
    [ Upstream commit 63e2f40c9e3187641afacde4153f54b3ee4dbc8c ]
    
    My earlier fix missed an incorrect function prototype that shows up on
    native 32-bit builds:
    
    In file included from fs/notify/fanotify/fanotify_user.c:14:
    include/linux/syscalls.h:248:25: error: conflicting types for 'sys_fanotify_mark'; have 'long int(int,  unsigned int,  u32,  u32,  int,  const char *)' {aka 'long int(int,  unsigned int,  unsigned int,  unsigned int,  int,  const char *)'}
     1924 | SYSCALL32_DEFINE6(fanotify_mark,
          | ^~~~~~~~~~~~~~~~~
    include/linux/syscalls.h:862:17: note: previous declaration of 'sys_fanotify_mark' with type 'long int(int,  unsigned int,  u64,  int, const char *)' {aka 'long int(int,  unsigned int,  long long unsigned int,  int,  const char *)'}
    
    On x86 and powerpc, the prototype is also wrong but hidden in an #ifdef,
    so it never caused problems.
    
    Add another alternative declaration that matches the conditional function
    definition.
    
    Fixes: 403f17a33073 ("parisc: use generic sys_fanotify_mark implementation")
    Cc: stable@vger.kernel.org
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: clear tp->retrans_stamp in tcp_rcv_fastopen_synack() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jun 14 13:06:15 2024 +0000

    tcp: clear tp->retrans_stamp in tcp_rcv_fastopen_synack()
    
    commit 9e046bb111f13461d3f9331e24e974324245140e upstream.
    
    Some applications were reporting ETIMEDOUT errors on apparently
    good looking flows, according to packet dumps.
    
    We were able to root cause the issue to an accidental setting
    of tp->retrans_stamp in the following scenario:
    
    - client sends TFO SYN with data.
    - server has TFO disabled, ACKs only SYN but not payload.
    - client receives SYNACK covering only SYN.
    - tcp_ack() eats SYN and sets tp->retrans_stamp to 0.
    - tcp_rcv_fastopen_synack() calls tcp_xmit_retransmit_queue()
      to retransmit TFO payload w/o SYN, sets tp->retrans_stamp to "now",
      but we are not in any loss recovery state.
    - TFO payload is ACKed.
    - we are not in any loss recovery state, and don't see any dupacks,
      so we don't get to any code path that clears tp->retrans_stamp.
    - tp->retrans_stamp stays non-zero for the lifetime of the connection.
    - after first RTO, tcp_clamp_rto_to_user_timeout() clamps second RTO
      to 1 jiffy due to bogus tp->retrans_stamp.
    - on clamped RTO with non-zero icsk_retransmits, retransmits_timed_out()
      sets start_ts from tp->retrans_stamp from TFO payload retransmit
      hours/days ago, and computes bogus long elapsed time for loss recovery,
      and suffers ETIMEDOUT early.
    
    Fixes: a7abf3cd76e1 ("tcp: consider using standard rtx logic in tcp_rcv_fastopen_synack()")
    CC: stable@vger.kernel.org
    Co-developed-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Co-developed-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240614130615.396837-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: count CLOSE-WAIT sockets for TCP_MIB_CURRESTAB [+ + +]
Author: Jason Xing <kernelxing@tencent.com>
Date:   Tue Jun 4 01:02:16 2024 +0800

    tcp: count CLOSE-WAIT sockets for TCP_MIB_CURRESTAB
    
    [ Upstream commit a46d0ea5c94205f40ecf912d1bb7806a8a64704f ]
    
    According to RFC 1213, we should also take CLOSE-WAIT sockets into
    consideration:
    
      "tcpCurrEstab OBJECT-TYPE
       ...
       The number of TCP connections for which the current state
       is either ESTABLISHED or CLOSE- WAIT."
    
    After this, CurrEstab counter will display the total number of
    ESTABLISHED and CLOSE-WAIT sockets.
    
    The logic of counting
    When we increment the counter?
    a) if we change the state to ESTABLISHED.
    b) if we change the state from SYN-RECEIVED to CLOSE-WAIT.
    
    When we decrement the counter?
    a) if the socket leaves ESTABLISHED and will never go into CLOSE-WAIT,
    say, on the client side, changing from ESTABLISHED to FIN-WAIT-1.
    b) if the socket leaves CLOSE-WAIT, say, on the server side, changing
    from CLOSE-WAIT to LAST-ACK.
    
    Please note: there are two chances that old state of socket can be changed
    to CLOSE-WAIT in tcp_fin(). One is SYN-RECV, the other is ESTABLISHED.
    So we have to take care of the former case.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Jason Xing <kernelxing@tencent.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: Fix data races around icsk->icsk_af_ops. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu Oct 6 11:53:49 2022 -0700

    tcp: Fix data races around icsk->icsk_af_ops.
    
    commit f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57 upstream.
    
    setsockopt(IPV6_ADDRFORM) and tcp_v6_connect() change icsk->icsk_af_ops
    under lock_sock(), but tcp_(get|set)sockopt() read it locklessly.  To
    avoid load/store tearing, we need to add READ_ONCE() and WRITE_ONCE()
    for the reads and writes.
    
    Thanks to Eric Dumazet for providing the syzbot report:
    
    BUG: KCSAN: data-race in tcp_setsockopt / tcp_v6_connect
    
    write to 0xffff88813c624518 of 8 bytes by task 23936 on cpu 0:
    tcp_v6_connect+0x5b3/0xce0 net/ipv6/tcp_ipv6.c:240
    __inet_stream_connect+0x159/0x6d0 net/ipv4/af_inet.c:660
    inet_stream_connect+0x44/0x70 net/ipv4/af_inet.c:724
    __sys_connect_file net/socket.c:1976 [inline]
    __sys_connect+0x197/0x1b0 net/socket.c:1993
    __do_sys_connect net/socket.c:2003 [inline]
    __se_sys_connect net/socket.c:2000 [inline]
    __x64_sys_connect+0x3d/0x50 net/socket.c:2000
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    read to 0xffff88813c624518 of 8 bytes by task 23937 on cpu 1:
    tcp_setsockopt+0x147/0x1c80 net/ipv4/tcp.c:3789
    sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3585
    __sys_setsockopt+0x212/0x2b0 net/socket.c:2252
    __do_sys_setsockopt net/socket.c:2263 [inline]
    __se_sys_setsockopt net/socket.c:2260 [inline]
    __x64_sys_setsockopt+0x62/0x70 net/socket.c:2260
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0xffffffff8539af68 -> 0xffffffff8539aff8
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 1 PID: 23937 Comm: syz-executor.5 Not tainted
    6.0.0-rc4-syzkaller-00331-g4ed9c1e971b1-dirty #0
    
    Hardware name: Google Google Compute Engine/Google Compute Engine,
    BIOS Google 08/26/2022
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reported-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Kazunori Kobayashi <kazunori.kobayashi@miraclelinux.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tcp: fix race in tcp_v6_syn_recv_sock() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jun 6 15:46:51 2024 +0000

    tcp: fix race in tcp_v6_syn_recv_sock()
    
    [ Upstream commit d37fe4255abe8e7b419b90c5847e8ec2b8debb08 ]
    
    tcp_v6_syn_recv_sock() calls ip6_dst_store() before
    inet_sk(newsk)->pinet6 has been set up.
    
    This means ip6_dst_store() writes over the parent (listener)
    np->dst_cookie.
    
    This is racy because multiple threads could share the same
    parent and their final np->dst_cookie could be wrong.
    
    Move ip6_dst_store() call after inet_sk(newsk)->pinet6
    has been changed and after the copy of parent ipv6_pinfo.
    
    Fixes: e994b2f0fb92 ("tcp: do not lock listener to process SYN packets")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: fix tcp_rcv_fastopen_synack() to enter TCP_CA_Loss for failed TFO [+ + +]
Author: Neal Cardwell <ncardwell@google.com>
Date:   Mon Jun 24 14:43:23 2024 +0000

    tcp: fix tcp_rcv_fastopen_synack() to enter TCP_CA_Loss for failed TFO
    
    [ Upstream commit 5dfe9d273932c647bdc9d664f939af9a5a398cbc ]
    
    Testing determined that the recent commit 9e046bb111f1 ("tcp: clear
    tp->retrans_stamp in tcp_rcv_fastopen_synack()") has a race, and does
    not always ensure retrans_stamp is 0 after a TFO payload retransmit.
    
    If transmit completion for the SYN+data skb happens after the client
    TCP stack receives the SYNACK (which sometimes happens), then
    retrans_stamp can erroneously remain non-zero for the lifetime of the
    connection, causing a premature ETIMEDOUT later.
    
    Testing and tracing showed that the buggy scenario is the following
    somewhat tricky sequence:
    
    + Client attempts a TFO handshake. tcp_send_syn_data() sends SYN + TFO
      cookie + data in a single packet in the syn_data skb. It hands the
      syn_data skb to tcp_transmit_skb(), which makes a clone. Crucially,
      it then reuses the same original (non-clone) syn_data skb,
      transforming it by advancing the seq by one byte and removing the
      FIN bit, and enques the resulting payload-only skb in the
      sk->tcp_rtx_queue.
    
    + Client sets retrans_stamp to the start time of the three-way
      handshake.
    
    + Cookie mismatches or server has TFO disabled, and server only ACKs
      SYN.
    
    + tcp_ack() sees SYN is acked, tcp_clean_rtx_queue() clears
      retrans_stamp.
    
    + Since the client SYN was acked but not the payload, the TFO failure
      code path in tcp_rcv_fastopen_synack() tries to retransmit the
      payload skb.  However, in some cases the transmit completion for the
      clone of the syn_data (which had SYN + TFO cookie + data) hasn't
      happened.  In those cases, skb_still_in_host_queue() returns true
      for the retransmitted TFO payload, because the clone of the syn_data
      skb has not had its tx completetion.
    
    + Because skb_still_in_host_queue() finds skb_fclone_busy() is true,
      it sets the TSQ_THROTTLED bit and the retransmit does not happen in
      the tcp_rcv_fastopen_synack() call chain.
    
    + The tcp_rcv_fastopen_synack() code next implicitly assumes the
      retransmit process is finished, and sets retrans_stamp to 0 to clear
      it, but this is later overwritten (see below).
    
    + Later, upon tx completion, tcp_tsq_write() calls
      tcp_xmit_retransmit_queue(), which puts the retransmit in flight and
      sets retrans_stamp to a non-zero value.
    
    + The client receives an ACK for the retransmitted TFO payload data.
    
    + Since we're in CA_Open and there are no dupacks/SACKs/DSACKs/ECN to
      make tcp_ack_is_dubious() true and make us call
      tcp_fastretrans_alert() and reach a code path that clears
      retrans_stamp, retrans_stamp stays nonzero.
    
    + Later, if there is a TLP, RTO, RTO sequence, then the connection
      will suffer an early ETIMEDOUT due to the erroneously ancient
      retrans_stamp.
    
    The fix: this commit refactors the code to have
    tcp_rcv_fastopen_synack() retransmit by reusing the relevant parts of
    tcp_simple_retransmit() that enter CA_Loss (without changing cwnd) and
    call tcp_xmit_retransmit_queue(). We have tcp_simple_retransmit() and
    tcp_rcv_fastopen_synack() share code in this way because in both cases
    we get a packet indicating non-congestion loss (MTU reduction or TFO
    failure) and thus in both cases we want to retransmit as many packets
    as cwnd allows, without reducing cwnd. And given that retransmits will
    set retrans_stamp to a non-zero value (and may do so in a later
    calling context due to TSQ), we also want to enter CA_Loss so that we
    track when all retransmitted packets are ACked and clear retrans_stamp
    when that happens (to ensure later recurring RTOs are using the
    correct retrans_stamp and don't declare ETIMEDOUT prematurely).
    
    Fixes: 9e046bb111f1 ("tcp: clear tp->retrans_stamp in tcp_rcv_fastopen_synack()")
    Fixes: a7abf3cd76e1 ("tcp: consider using standard rtx logic in tcp_rcv_fastopen_synack()")
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Link: https://patch.msgid.link/20240624144323.2371403-1-ncardwell.sw@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: Use BPF timeout setting for SYN ACK RTO [+ + +]
Author: Akhmat Karakotov <hmukos@yandex-team.ru>
Date:   Fri Jan 28 22:26:21 2022 +0300

    tcp: Use BPF timeout setting for SYN ACK RTO
    
    [ Upstream commit 5903123f662ed18483f05cac3f9e800a074c29ff ]
    
    When setting RTO through BPF program, some SYN ACK packets were unaffected
    and continued to use TCP_TIMEOUT_INIT constant. This patch adds timeout
    option to struct request_sock. Option is initialized with TCP_TIMEOUT_INIT
    and is reassigned through BPF using tcp_timeout_init call. SYN ACK
    retransmits now use newly added timeout option.
    
    Signed-off-by: Akhmat Karakotov <hmukos@yandex-team.ru>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    
    v2:
            - Add timeout option to struct request_sock. Do not call
              tcp_timeout_init on every syn ack retransmit.
    
    v3:
            - Use unsigned long for min. Bound tcp_timeout_init to TCP_RTO_MAX.
    
    v4: - Refactor duplicate code by adding reqsk_timeout function.
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: ff46e3b44219 ("Fix race for duplicate reqsk on identical SYN")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tick/nohz_full: Don't abuse smp_call_function_single() in tick_setup_device() [+ + +]
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Tue May 28 14:20:19 2024 +0200

    tick/nohz_full: Don't abuse smp_call_function_single() in tick_setup_device()
    
    commit 07c54cc5988f19c9642fd463c2dbdac7fc52f777 upstream.
    
    After the recent commit 5097cbcb38e6 ("sched/isolation: Prevent boot crash
    when the boot CPU is nohz_full") the kernel no longer crashes, but there is
    another problem.
    
    In this case tick_setup_device() calls tick_take_do_timer_from_boot() to
    update tick_do_timer_cpu and this triggers the WARN_ON_ONCE(irqs_disabled)
    in smp_call_function_single().
    
    Kill tick_take_do_timer_from_boot() and just use WRITE_ONCE(), the new
    comment explains why this is safe (thanks Thomas!).
    
    Fixes: 08ae95f4fd3b ("nohz_full: Allow the boot CPU to be nohz_full")
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240528122019.GA28794@redhat.com
    Link: https://lore.kernel.org/all/20240522151742.GA10400@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tipc: force a dst refcount before doing decryption [+ + +]
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sat Jun 15 14:27:20 2024 -0400

    tipc: force a dst refcount before doing decryption
    
    [ Upstream commit 2ebe8f840c7450ecbfca9d18ac92e9ce9155e269 ]
    
    As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before
    entering the xfrm type handlers"):
    
    "Crypto requests might return asynchronous. In this case we leave the
     rcu protected region, so force a refcount on the skb's destination
     entry before we enter the xfrm type input/output handlers."
    
    On TIPC decryption path it has the same problem, and skb_dst_force()
    should be called before doing decryption to avoid a possible crash.
    
    Shuang reported this issue when this warning is triggered:
    
      [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc]
      [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug
      [] Workqueue: crypto cryptd_queue_worker
      [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc]
      [] Call Trace:
      [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc]
      [] tipc_rcv+0xcf5/0x1060 [tipc]
      [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc]
      [] cryptd_aead_crypt+0xdb/0x190
      [] cryptd_queue_worker+0xed/0x190
      [] process_one_work+0x93d/0x17e0
    
    Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
    Reported-by: Shuang Li <shuali@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Link: https://lore.kernel.org/r/fbe3195fad6997a4eec62d9bf076b2ad03ac336b.1718476040.git.lucien.xin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tracing/net_sched: NULL pointer dereference in perf_trace_qdisc_reset() [+ + +]
Author: Yunseong Kim <yskelg@gmail.com>
Date:   Tue Jun 25 02:33:23 2024 +0900

    tracing/net_sched: NULL pointer dereference in perf_trace_qdisc_reset()
    
    commit bab4923132feb3e439ae45962979c5d9d5c7c1f1 upstream.
    
    In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
    
     qdisc->dev_queue->dev <NULL> ->name
    
    This situation simulated from bunch of veths and Bluetooth disconnection
    and reconnection.
    
    During qdisc initialization, qdisc was being set to noop_queue.
    In veth_init_queue, the initial tx_num was reduced back to one,
    causing the qdisc reset to be called with noop, which led to the kernel
    panic.
    
    I've attached the GitHub gist link that C converted syz-execprogram
    source code and 3 log of reproduced vmcore-dmesg.
    
     https://gist.github.com/yskelg/cc64562873ce249cdd0d5a358b77d740
    
    Yeoreum and I use two fuzzing tool simultaneously.
    
    One process with syz-executor : https://github.com/google/syzkaller
    
     $ ./syz-execprog -executor=./syz-executor -repeat=1 -sandbox=setuid \
        -enable=none -collide=false log1
    
    The other process with perf fuzzer:
     https://github.com/deater/perf_event_tests/tree/master/fuzzer
    
     $ perf_event_tests/fuzzer/perf_fuzzer
    
    I think this will happen on the kernel version.
    
     Linux kernel version +v6.7.10, +v6.8, +v6.9 and it could happen in v6.10.
    
    This occurred from 51270d573a8d. I think this patch is absolutely
    necessary. Previously, It was showing not intended string value of name.
    
    I've reproduced 3 time from my fedora 40 Debug Kernel with any other module
    or patched.
    
     version: 6.10.0-0.rc2.20240608gitdc772f8237f9.29.fc41.aarch64+debug
    
    [ 5287.164555] veth0_vlan: left promiscuous mode
    [ 5287.164929] veth1_macvtap: left promiscuous mode
    [ 5287.164950] veth0_macvtap: left promiscuous mode
    [ 5287.164983] veth1_vlan: left promiscuous mode
    [ 5287.165008] veth0_vlan: left promiscuous mode
    [ 5287.165450] veth1_macvtap: left promiscuous mode
    [ 5287.165472] veth0_macvtap: left promiscuous mode
    [ 5287.165502] veth1_vlan: left promiscuous mode
    …
    [ 5297.598240] bridge0: port 2(bridge_slave_1) entered blocking state
    [ 5297.598262] bridge0: port 2(bridge_slave_1) entered forwarding state
    [ 5297.598296] bridge0: port 1(bridge_slave_0) entered blocking state
    [ 5297.598313] bridge0: port 1(bridge_slave_0) entered forwarding state
    [ 5297.616090] 8021q: adding VLAN 0 to HW filter on device bond0
    [ 5297.620405] bridge0: port 1(bridge_slave_0) entered disabled state
    [ 5297.620730] bridge0: port 2(bridge_slave_1) entered disabled state
    [ 5297.627247] 8021q: adding VLAN 0 to HW filter on device team0
    [ 5297.629636] bridge0: port 1(bridge_slave_0) entered blocking state
    …
    [ 5298.002798] bridge_slave_0: left promiscuous mode
    [ 5298.002869] bridge0: port 1(bridge_slave_0) entered disabled state
    [ 5298.309444] bond0 (unregistering): (slave bond_slave_0): Releasing backup interface
    [ 5298.315206] bond0 (unregistering): (slave bond_slave_1): Releasing backup interface
    [ 5298.320207] bond0 (unregistering): Released all slaves
    [ 5298.354296] hsr_slave_0: left promiscuous mode
    [ 5298.360750] hsr_slave_1: left promiscuous mode
    [ 5298.374889] veth1_macvtap: left promiscuous mode
    [ 5298.374931] veth0_macvtap: left promiscuous mode
    [ 5298.374988] veth1_vlan: left promiscuous mode
    [ 5298.375024] veth0_vlan: left promiscuous mode
    [ 5299.109741] team0 (unregistering): Port device team_slave_1 removed
    [ 5299.185870] team0 (unregistering): Port device team_slave_0 removed
    …
    [ 5300.155443] Bluetooth: hci3: unexpected cc 0x0c03 length: 249 > 1
    [ 5300.155724] Bluetooth: hci3: unexpected cc 0x1003 length: 249 > 9
    [ 5300.155988] Bluetooth: hci3: unexpected cc 0x1001 length: 249 > 9
    ….
    [ 5301.075531] team0: Port device team_slave_1 added
    [ 5301.085515] bridge0: port 1(bridge_slave_0) entered blocking state
    [ 5301.085531] bridge0: port 1(bridge_slave_0) entered disabled state
    [ 5301.085588] bridge_slave_0: entered allmulticast mode
    [ 5301.085800] bridge_slave_0: entered promiscuous mode
    [ 5301.095617] bridge0: port 1(bridge_slave_0) entered blocking state
    [ 5301.095633] bridge0: port 1(bridge_slave_0) entered disabled state
    …
    [ 5301.149734] bond0: (slave bond_slave_0): Enslaving as an active interface with an up link
    [ 5301.173234] bond0: (slave bond_slave_0): Enslaving as an active interface with an up link
    [ 5301.180517] bond0: (slave bond_slave_1): Enslaving as an active interface with an up link
    [ 5301.193481] hsr_slave_0: entered promiscuous mode
    [ 5301.204425] hsr_slave_1: entered promiscuous mode
    [ 5301.210172] debugfs: Directory 'hsr0' with parent 'hsr' already present!
    [ 5301.210185] Cannot create hsr debugfs directory
    [ 5301.224061] bond0: (slave bond_slave_1): Enslaving as an active interface with an up link
    [ 5301.246901] bond0: (slave bond_slave_0): Enslaving as an active interface with an up link
    [ 5301.255934] team0: Port device team_slave_0 added
    [ 5301.256480] team0: Port device team_slave_1 added
    [ 5301.256948] team0: Port device team_slave_0 added
    …
    [ 5301.435928] hsr_slave_0: entered promiscuous mode
    [ 5301.446029] hsr_slave_1: entered promiscuous mode
    [ 5301.455872] debugfs: Directory 'hsr0' with parent 'hsr' already present!
    [ 5301.455884] Cannot create hsr debugfs directory
    [ 5301.502664] hsr_slave_0: entered promiscuous mode
    [ 5301.513675] hsr_slave_1: entered promiscuous mode
    [ 5301.526155] debugfs: Directory 'hsr0' with parent 'hsr' already present!
    [ 5301.526164] Cannot create hsr debugfs directory
    [ 5301.563662] hsr_slave_0: entered promiscuous mode
    [ 5301.576129] hsr_slave_1: entered promiscuous mode
    [ 5301.580259] debugfs: Directory 'hsr0' with parent 'hsr' already present!
    [ 5301.580270] Cannot create hsr debugfs directory
    [ 5301.590269] 8021q: adding VLAN 0 to HW filter on device bond0
    
    [ 5301.595872] KASAN: null-ptr-deref in range [0x0000000000000130-0x0000000000000137]
    [ 5301.595877] Mem abort info:
    [ 5301.595881]   ESR = 0x0000000096000006
    [ 5301.595885]   EC = 0x25: DABT (current EL), IL = 32 bits
    [ 5301.595889]   SET = 0, FnV = 0
    [ 5301.595893]   EA = 0, S1PTW = 0
    [ 5301.595896]   FSC = 0x06: level 2 translation fault
    [ 5301.595900] Data abort info:
    [ 5301.595903]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
    [ 5301.595907]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    [ 5301.595911]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    [ 5301.595915] [dfff800000000026] address between user and kernel address ranges
    [ 5301.595971] Internal error: Oops: 0000000096000006 [#1] SMP
    …
    [ 5301.596076] CPU: 2 PID: 102769 Comm:
    syz-executor.3 Kdump: loaded Tainted:
     G        W         -------  ---  6.10.0-0.rc2.20240608gitdc772f8237f9.29.fc41.aarch64+debug #1
    [ 5301.596080] Hardware name: VMware, Inc. VMware20,1/VBSA,
     BIOS VMW201.00V.21805430.BA64.2305221830 05/22/2023
    [ 5301.596082] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
    [ 5301.596085] pc : strnlen+0x40/0x88
    [ 5301.596114] lr : trace_event_get_offsets_qdisc_reset+0x6c/0x2b0
    [ 5301.596124] sp : ffff8000beef6b40
    [ 5301.596126] x29: ffff8000beef6b40 x28: dfff800000000000 x27: 0000000000000001
    [ 5301.596131] x26: 6de1800082c62bd0 x25: 1ffff000110aa9e0 x24: ffff800088554f00
    [ 5301.596136] x23: ffff800088554ec0 x22: 0000000000000130 x21: 0000000000000140
    [ 5301.596140] x20: dfff800000000000 x19: ffff8000beef6c60 x18: ffff7000115106d8
    [ 5301.596143] x17: ffff800121bad000 x16: ffff800080020000 x15: 0000000000000006
    [ 5301.596147] x14: 0000000000000002 x13: ffff0001f3ed8d14 x12: ffff700017ddeda5
    [ 5301.596151] x11: 1ffff00017ddeda4 x10: ffff700017ddeda4 x9 : ffff800082cc5eec
    [ 5301.596155] x8 : 0000000000000004 x7 : 00000000f1f1f1f1 x6 : 00000000f2f2f200
    [ 5301.596158] x5 : 00000000f3f3f3f3 x4 : ffff700017dded80 x3 : 00000000f204f1f1
    [ 5301.596162] x2 : 0000000000000026 x1 : 0000000000000000 x0 : 0000000000000130
    [ 5301.596166] Call trace:
    [ 5301.596175]  strnlen+0x40/0x88
    [ 5301.596179]  trace_event_get_offsets_qdisc_reset+0x6c/0x2b0
    [ 5301.596182]  perf_trace_qdisc_reset+0xb0/0x538
    [ 5301.596184]  __traceiter_qdisc_reset+0x68/0xc0
    [ 5301.596188]  qdisc_reset+0x43c/0x5e8
    [ 5301.596190]  netif_set_real_num_tx_queues+0x288/0x770
    [ 5301.596194]  veth_init_queues+0xfc/0x130 [veth]
    [ 5301.596198]  veth_newlink+0x45c/0x850 [veth]
    [ 5301.596202]  rtnl_newlink_create+0x2c8/0x798
    [ 5301.596205]  __rtnl_newlink+0x92c/0xb60
    [ 5301.596208]  rtnl_newlink+0xd8/0x130
    [ 5301.596211]  rtnetlink_rcv_msg+0x2e0/0x890
    [ 5301.596214]  netlink_rcv_skb+0x1c4/0x380
    [ 5301.596225]  rtnetlink_rcv+0x20/0x38
    [ 5301.596227]  netlink_unicast+0x3c8/0x640
    [ 5301.596231]  netlink_sendmsg+0x658/0xa60
    [ 5301.596234]  __sock_sendmsg+0xd0/0x180
    [ 5301.596243]  __sys_sendto+0x1c0/0x280
    [ 5301.596246]  __arm64_sys_sendto+0xc8/0x150
    [ 5301.596249]  invoke_syscall+0xdc/0x268
    [ 5301.596256]  el0_svc_common.constprop.0+0x16c/0x240
    [ 5301.596259]  do_el0_svc+0x48/0x68
    [ 5301.596261]  el0_svc+0x50/0x188
    [ 5301.596265]  el0t_64_sync_handler+0x120/0x130
    [ 5301.596268]  el0t_64_sync+0x194/0x198
    [ 5301.596272] Code: eb15001f 54000120 d343fc02 12000801 (38f46842)
    [ 5301.596285] SMP: stopping secondary CPUs
    [ 5301.597053] Starting crashdump kernel...
    [ 5301.597057] Bye!
    
    After applying our patch, I didn't find any kernel panic errors.
    
    We've found a simple reproducer
    
     # echo 1 > /sys/kernel/debug/tracing/events/qdisc/qdisc_reset/enable
    
     # ip link add veth0 type veth peer name veth1
    
     Error: Unknown device type.
    
    However, without our patch applied, I tested upstream 6.10.0-rc3 kernel
    using the qdisc_reset event and the ip command on my qemu virtual machine.
    
    This 2 commands makes always kernel panic.
    
    Linux version: 6.10.0-rc3
    
    [    0.000000] Linux version 6.10.0-rc3-00164-g44ef20baed8e-dirty
    (paran@fedora) (gcc (GCC) 14.1.1 20240522 (Red Hat 14.1.1-4), GNU ld
    version 2.41-34.fc40) #20 SMP PREEMPT Sat Jun 15 16:51:25 KST 2024
    
    Kernel panic message:
    
    [  615.236484] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
    [  615.237250] Dumping ftrace buffer:
    [  615.237679]    (ftrace buffer empty)
    [  615.238097] Modules linked in: veth crct10dif_ce virtio_gpu
    virtio_dma_buf drm_shmem_helper drm_kms_helper zynqmp_fpga xilinx_can
    xilinx_spi xilinx_selectmap xilinx_core xilinx_pr_decoupler versal_fpga
    uvcvideo uvc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videodev
    videobuf2_common mc usbnet deflate zstd ubifs ubi rcar_canfd rcar_can
    omap_mailbox ntb_msi_test ntb_hw_epf lattice_sysconfig_spi
    lattice_sysconfig ice40_spi gpio_xilinx dwmac_altr_socfpga mdio_regmap
    stmmac_platform stmmac pcs_xpcs dfl_fme_region dfl_fme_mgr dfl_fme_br
    dfl_afu dfl fpga_region fpga_bridge can can_dev br_netfilter bridge stp
    llc atl1c ath11k_pci mhi ath11k_ahb ath11k qmi_helpers ath10k_sdio
    ath10k_pci ath10k_core ath mac80211 libarc4 cfg80211 drm fuse backlight ipv6
    Jun 22 02:36:5[3   6k152.62-4sm98k4-0k]v  kCePUr:n e1l :P IUDn:a b4le6
    8t oC ohmma: nidpl eN oketr nteali nptaedg i6n.g1 0re.0q-urecs3t- 0at0
    1v6i4r-tgu4a4le fa2d0dbraeeds0se-dir tyd f#f2f08
      615.252376] Hardware name: linux,dummy-virt (DT)
    [  615.253220] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
    BTYPE=--)
    [  615.254433] pc : strnlen+0x6c/0xe0
    [  615.255096] lr : trace_event_get_offsets_qdisc_reset+0x94/0x3d0
    [  615.256088] sp : ffff800080b269a0
    [  615.256615] x29: ffff800080b269a0 x28: ffffc070f3f98500 x27:
    0000000000000001
    [  615.257831] x26: 0000000000000010 x25: ffffc070f3f98540 x24:
    ffffc070f619cf60
    [  615.259020] x23: 0000000000000128 x22: 0000000000000138 x21:
    dfff800000000000
    [  615.260241] x20: ffffc070f631ad00 x19: 0000000000000128 x18:
    ffffc070f448b800
    [  615.261454] x17: 0000000000000000 x16: 0000000000000001 x15:
    ffffc070f4ba2a90
    [  615.262635] x14: ffff700010164d73 x13: 1ffff80e1e8d5eb3 x12:
    1ffff00010164d72
    [  615.263877] x11: ffff700010164d72 x10: dfff800000000000 x9 :
    ffffc070e85d6184
    [  615.265047] x8 : ffffc070e4402070 x7 : 000000000000f1f1 x6 :
    000000001504a6d3
    [  615.266336] x5 : ffff28ca21122140 x4 : ffffc070f5043ea8 x3 :
    0000000000000000
    [  615.267528] x2 : 0000000000000025 x1 : 0000000000000000 x0 :
    0000000000000000
    [  615.268747] Call trace:
    [  615.269180]  strnlen+0x6c/0xe0
    [  615.269767]  trace_event_get_offsets_qdisc_reset+0x94/0x3d0
    [  615.270716]  trace_event_raw_event_qdisc_reset+0xe8/0x4e8
    [  615.271667]  __traceiter_qdisc_reset+0xa0/0x140
    [  615.272499]  qdisc_reset+0x554/0x848
    [  615.273134]  netif_set_real_num_tx_queues+0x360/0x9a8
    [  615.274050]  veth_init_queues+0x110/0x220 [veth]
    [  615.275110]  veth_newlink+0x538/0xa50 [veth]
    [  615.276172]  __rtnl_newlink+0x11e4/0x1bc8
    [  615.276944]  rtnl_newlink+0xac/0x120
    [  615.277657]  rtnetlink_rcv_msg+0x4e4/0x1370
    [  615.278409]  netlink_rcv_skb+0x25c/0x4f0
    [  615.279122]  rtnetlink_rcv+0x48/0x70
    [  615.279769]  netlink_unicast+0x5a8/0x7b8
    [  615.280462]  netlink_sendmsg+0xa70/0x1190
    
    Yeoreum and I don't know if the patch we wrote will fix the underlying
    cause, but we think that priority is to prevent kernel panic happening.
    So, we're sending this patch.
    
    Fixes: 51270d573a8d ("tracing/net_sched: Fix tracepoints that save qdisc_dev() as a string")
    Link: https://lore.kernel.org/lkml/20240229143432.273b4871@gandalf.local.home/t/
    Cc: netdev@vger.kernel.org
    Tested-by: Yunseong Kim <yskelg@gmail.com>
    Signed-off-by: Yunseong Kim <yskelg@gmail.com>
    Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
    Link: https://lore.kernel.org/r/20240624173320.24945-4-yskelg@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing/selftests: Fix kprobe event name test for .isra. functions [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Mon May 20 20:57:37 2024 -0400

    tracing/selftests: Fix kprobe event name test for .isra. functions
    
    commit 23a4b108accc29a6125ed14de4a044689ffeda78 upstream.
    
    The kprobe_eventname.tc test checks if a function with .isra. can have a
    kprobe attached to it. It loops through the kallsyms file for all the
    functions that have the .isra. name, and checks if it exists in the
    available_filter_functions file, and if it does, it uses it to attach a
    kprobe to it.
    
    The issue is that kprobes can not attach to functions that are listed more
    than once in available_filter_functions. With the latest kernel, the
    function that is found is: rapl_event_update.isra.0
    
      # grep rapl_event_update.isra.0 /sys/kernel/tracing/available_filter_functions
      rapl_event_update.isra.0
      rapl_event_update.isra.0
    
    It is listed twice. This causes the attached kprobe to it to fail which in
    turn fails the test. Instead of just picking the function function that is
    found in available_filter_functions, pick the first one that is listed
    only once in available_filter_functions.
    
    Cc: stable@vger.kernel.org
    Fixes: 604e3548236d ("selftests/ftrace: Select an existing function in kprobe_eventname test")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing: Add MODULE_DESCRIPTION() to preemptirq_delay_test [+ + +]
Author: Jeff Johnson <quic_jjohnson@quicinc.com>
Date:   Sat May 18 15:54:49 2024 -0700

    tracing: Add MODULE_DESCRIPTION() to preemptirq_delay_test
    
    [ Upstream commit 23748e3e0fbfe471eff5ce439921629f6a427828 ]
    
    Fix the 'make W=1' warning:
    
    WARNING: modpost: missing MODULE_DESCRIPTION() in kernel/trace/preemptirq_delay_test.o
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240518-md-preemptirq_delay_test-v1-1-387d11b30d85@quicinc.com
    
    Cc: stable@vger.kernel.org
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Fixes: f96e8577da10 ("lib: Add module for testing preemptoff/irqsoff latency tracers")
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tracing: Build event generation tests only as modules [+ + +]
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Tue Jun 11 22:30:37 2024 +0900

    tracing: Build event generation tests only as modules
    
    [ Upstream commit 3572bd5689b0812b161b40279e39ca5b66d73e88 ]
    
    The kprobes and synth event generation test modules add events and lock
    (get a reference) those event file reference in module init function,
    and unlock and delete it in module exit function. This is because those
    are designed for playing as modules.
    
    If we make those modules as built-in, those events are left locked in the
    kernel, and never be removed. This causes kprobe event self-test failure
    as below.
    
    [   97.349708] ------------[ cut here ]------------
    [   97.353453] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:2133 kprobe_trace_self_tests_init+0x3f1/0x480
    [   97.357106] Modules linked in:
    [   97.358488] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.9.0-g699646734ab5-dirty #14
    [   97.361556] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    [   97.363880] RIP: 0010:kprobe_trace_self_tests_init+0x3f1/0x480
    [   97.365538] Code: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff ff 90 <0f> 0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 90
    [   97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286
    [   97.371852] RAX: 00000000fffffff0 RBX: ffff888005919c00 RCX: 0000000000000000
    [   97.373829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68
    [   97.375715] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
    [   97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000
    [   97.379591] R13: 0000000000000001 R14: 0000000000000015 R15: 0000000000000000
    [   97.381536] FS:  0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000
    [   97.383813] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0
    [   97.387347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   97.391196] Call Trace:
    [   97.391967]  <TASK>
    [   97.392647]  ? __warn+0xcc/0x180
    [   97.393640]  ? kprobe_trace_self_tests_init+0x3f1/0x480
    [   97.395181]  ? report_bug+0xbd/0x150
    [   97.396234]  ? handle_bug+0x3e/0x60
    [   97.397311]  ? exc_invalid_op+0x1a/0x50
    [   97.398434]  ? asm_exc_invalid_op+0x1a/0x20
    [   97.399652]  ? trace_kprobe_is_busy+0x20/0x20
    [   97.400904]  ? tracing_reset_all_online_cpus+0x15/0x90
    [   97.402304]  ? kprobe_trace_self_tests_init+0x3f1/0x480
    [   97.403773]  ? init_kprobe_trace+0x50/0x50
    [   97.404972]  do_one_initcall+0x112/0x240
    [   97.406113]  do_initcall_level+0x95/0xb0
    [   97.407286]  ? kernel_init+0x1a/0x1a0
    [   97.408401]  do_initcalls+0x3f/0x70
    [   97.409452]  kernel_init_freeable+0x16f/0x1e0
    [   97.410662]  ? rest_init+0x1f0/0x1f0
    [   97.411738]  kernel_init+0x1a/0x1a0
    [   97.412788]  ret_from_fork+0x39/0x50
    [   97.413817]  ? rest_init+0x1f0/0x1f0
    [   97.414844]  ret_from_fork_asm+0x11/0x20
    [   97.416285]  </TASK>
    [   97.417134] irq event stamp: 13437323
    [   97.418376] hardirqs last  enabled at (13437337): [<ffffffff8110bc0c>] console_unlock+0x11c/0x150
    [   97.421285] hardirqs last disabled at (13437370): [<ffffffff8110bbf1>] console_unlock+0x101/0x150
    [   97.423838] softirqs last  enabled at (13437366): [<ffffffff8108e17f>] handle_softirqs+0x23f/0x2a0
    [   97.426450] softirqs last disabled at (13437393): [<ffffffff8108e346>] __irq_exit_rcu+0x66/0xd0
    [   97.428850] ---[ end trace 0000000000000000 ]---
    
    And also, since we can not cleanup dynamic_event file, ftracetest are
    failed too.
    
    To avoid these issues, build these tests only as modules.
    
    Link: https://lore.kernel.org/all/171811263754.85078.5877446624311852525.stgit@devnote2/
    
    Fixes: 9fe41efaca08 ("tracing: Add synth event generation test module")
    Fixes: 64836248dda2 ("tracing: Add kprobe event command generation test module")
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tty: mcf: MCF54418 has 10 UARTS [+ + +]
Author: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
Date:   Thu Jun 20 18:29:59 2024 +0200

    tty: mcf: MCF54418 has 10 UARTS
    
    commit 7c92a8bd53f24d50c8cf4aba53bb75505b382fed upstream.
    
    Most of the colfires have up to 5 UARTs but MCF54418 has up-to 10 !
    Change the maximum value authorized.
    
    Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
    Cc: stable <stable@kernel.org>
    Fixes: 2545cf6e94b4 ("m68knommu: allow 4 coldfire serial ports")
    Link: https://lore.kernel.org/r/20240620-upstream-uart-v1-1-a9d0d95fb19e@yoseli.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
udf: udftime: prevent overflow in udf_disk_stamp_to_time() [+ + +]
Author: Roman Smirnov <r.smirnov@omp.ru>
Date:   Wed Mar 27 16:27:55 2024 +0300

    udf: udftime: prevent overflow in udf_disk_stamp_to_time()
    
    [ Upstream commit 3b84adf460381169c085e4bc09e7b57e9e16db0a ]
    
    An overflow can occur in a situation where src.centiseconds
    takes the value of 255. This situation is unlikely, but there
    is no validation check anywere in the code.
    
    Found by Linux Verification Center (linuxtesting.org) with Svace.
    
    Suggested-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Roman Smirnov <r.smirnov@omp.ru>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Message-Id: <20240327132755.13945-1-r.smirnov@omp.ru>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb-storage: alauda: Check whether the media is initialized [+ + +]
Author: Shichao Lai <shichaorai@gmail.com>
Date:   Sun May 26 09:27:45 2024 +0800

    usb-storage: alauda: Check whether the media is initialized
    
    [ Upstream commit 16637fea001ab3c8df528a8995b3211906165a30 ]
    
    The member "uzonesize" of struct alauda_info will remain 0
    if alauda_init_media() fails, potentially causing divide errors
    in alauda_read_data() and alauda_write_lba().
    - Add a member "media_initialized" to struct alauda_info.
    - Change a condition in alauda_check_media() to ensure the
      first initialization.
    - Add an error check for the return value of alauda_init_media().
    
    Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support")
    Reported-by: xingwei lee <xrivendell7@gmail.com>
    Reported-by: yue sun <samsun1006219@gmail.com>
    Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Shichao Lai <shichaorai@gmail.com>
    Link: https://lore.kernel.org/r/20240526012745.2852061-1-shichaorai@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: atm: cxacru: fix endpoint checking in cxacru_bind() [+ + +]
Author: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Date:   Sun Jun 9 06:15:46 2024 -0700

    usb: atm: cxacru: fix endpoint checking in cxacru_bind()
    
    commit 2eabb655a968b862bc0c31629a09f0fbf3c80d51 upstream.
    
    Syzbot is still reporting quite an old issue [1] that occurs due to
    incomplete checking of present usb endpoints. As such, wrong
    endpoints types may be used at urb sumbitting stage which in turn
    triggers a warning in usb_submit_urb().
    
    Fix the issue by verifying that required endpoint types are present
    for both in and out endpoints, taking into account cmd endpoint type.
    
    Unfortunately, this patch has not been tested on real hardware.
    
    [1] Syzbot report:
    usb 1-1: BOGUS urb xfer, pipe 1 != type 3
    WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
    Modules linked in:
    CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: usb_hub_wq hub_event
    RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
    ...
    Call Trace:
     cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649
     cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760
     cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209
     usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055
     cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363
     usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
     call_driver_probe drivers/base/dd.c:517 [inline]
     really_probe+0x23c/0xcd0 drivers/base/dd.c:595
     __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
     driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
     __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
     bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
     __device_attach+0x228/0x4a0 drivers/base/dd.c:965
     bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
     device_add+0xc2f/0x2180 drivers/base/core.c:3354
     usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170
     usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
     usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
    
    Reported-and-tested-by: syzbot+00c18ee8497dd3be6ade@syzkaller.appspotmail.com
    Fixes: 902ffc3c707c ("USB: cxacru: Use a bulk/int URB to access the command endpoint")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
    Link: https://lore.kernel.org/r/20240609131546.3932-1-n.zhandarovich@fintech.ru
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Jun 13 21:30:43 2024 -0400

    USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages
    
    commit 22f00812862564b314784167a89f27b444f82a46 upstream.
    
    The syzbot fuzzer found that the interrupt-URB completion callback in
    the cdc-wdm driver was taking too long, and the driver's immediate
    resubmission of interrupt URBs with -EPROTO status combined with the
    dummy-hcd emulation to cause a CPU lockup:
    
    cdc_wdm 1-1:1.0: nonzero urb status received: -71
    cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes
    watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]
    CPU#0 Utilization every 4s during lockup:
            #1:  98% system,          0% softirq,     3% hardirq,     0% idle
            #2:  98% system,          0% softirq,     3% hardirq,     0% idle
            #3:  98% system,          0% softirq,     3% hardirq,     0% idle
            #4:  98% system,          0% softirq,     3% hardirq,     0% idle
            #5:  98% system,          1% softirq,     3% hardirq,     0% idle
    Modules linked in:
    irq event stamp: 73096
    hardirqs last  enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline]
    hardirqs last  enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994
    hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
    hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
    softirqs last  enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline]
    softirqs last  enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582
    softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588
    CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G        W          6.10.0-rc2-syzkaller-g8867bbd4a056 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
    
    Testing showed that the problem did not occur if the two error
    messages -- the first two lines above -- were removed; apparently adding
    material to the kernel log takes a surprisingly large amount of time.
    
    In any case, the best approach for preventing these lockups and to
    avoid spamming the log with thousands of error messages per second is
    to ratelimit the two dev_err() calls.  Therefore we replace them with
    dev_err_ratelimited().
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Suggested-by: Greg KH <gregkh@linuxfoundation.org>
    Reported-and-tested-by: syzbot+5f996b83575ef4058638@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-usb/00000000000073d54b061a6a1c65@google.com/
    Reported-and-tested-by: syzbot+1b2abad17596ad03dcff@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/linux-usb/000000000000f45085061aa9b37e@google.com/
    Fixes: 9908a32e94de ("USB: remove err() macro from usb class drivers")
    Link: https://lore.kernel.org/linux-usb/40dfa45b-5f21-4eef-a8c1-51a2f320e267@rowland.harvard.edu/
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/29855215-52f5-4385-b058-91f42c2bee18@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock [+ + +]
Author: Meng Li <Meng.Li@windriver.com>
Date:   Tue Jun 18 11:19:18 2024 +0800

    usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock
    
    commit 7838de15bb700c2898a7d741db9b1f3cbc86c136 upstream.
    
    When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system
    to enter suspend status with below command:
    echo mem > /sys/power/state
    There will be a deadlock issue occurring. Detailed invoking path as
    below:
    dwc3_suspend_common()
        spin_lock_irqsave(&dwc->lock, flags);              <-- 1st
        dwc3_gadget_suspend(dwc);
            dwc3_gadget_soft_disconnect(dwc);
                spin_lock_irqsave(&dwc->lock, flags);      <-- 2nd
    This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix
    NULL pointer dereference in dwc3_gadget_suspend") that removes the code
    of checking whether dwc->gadget_driver is NULL or not. It causes the
    following code is executed and deadlock occurs when trying to get the
    spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3:
    Remove DWC3 locking during gadget suspend/resume") that forgot to remove
    the lock of otg mode. So, remove the redundant lock of otg mode during
    gadget suspend/resume.
    
    Fixes: 5265397f9442 ("usb: dwc3: Remove DWC3 locking during gadget suspend/resume")
    Cc: Xu Yang <xu.yang_2@nxp.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Meng Li <Meng.Li@windriver.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240618031918.2585799-1-Meng.Li@windriver.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete [+ + +]
Author: Wesley Cheng <quic_wcheng@quicinc.com>
Date:   Mon Apr 8 18:40:59 2024 -0700

    usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete
    
    [ Upstream commit 24729b307eefcd7c476065cd7351c1a018082c19 ]
    
    FFS based applications can utilize the aio_cancel() callback to dequeue
    pending USB requests submitted to the UDC.  There is a scenario where the
    FFS application issues an AIO cancel call, while the UDC is handling a
    soft disconnect.  For a DWC3 based implementation, the callstack looks
    like the following:
    
        DWC3 Gadget                               FFS Application
    dwc3_gadget_soft_disconnect()              ...
      --> dwc3_stop_active_transfers()
        --> dwc3_gadget_giveback(-ESHUTDOWN)
          --> ffs_epfile_async_io_complete()   ffs_aio_cancel()
            --> usb_ep_free_request()            --> usb_ep_dequeue()
    
    There is currently no locking implemented between the AIO completion
    handler and AIO cancel, so the issue occurs if the completion routine is
    running in parallel to an AIO cancel call coming from the FFS application.
    As the completion call frees the USB request (io_data->req) the FFS
    application is also referencing it for the usb_ep_dequeue() call.  This can
    lead to accessing a stale/hanging pointer.
    
    commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
    relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().
    However, in order to properly implement locking to mitigate this issue, the
    spinlock can't be added to ffs_epfile_async_io_complete(), as
    usb_ep_dequeue() (if successfully dequeuing a USB request) will call the
    function driver's completion handler in the same context.  Hence, leading
    into a deadlock.
    
    Fix this issue by moving the usb_ep_free_request() back to
    ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req
    to NULL after freeing it within the ffs->eps_lock.  This resolves the race
    condition above, as the ffs_aio_cancel() routine will not continue
    attempting to dequeue a request that has already been freed, or the
    ffs_user_copy_work() not freeing the USB request until the AIO cancel is
    done referencing it.
    
    This fix depends on
      commit b566d38857fc ("usb: gadget: f_fs: use io_data->status
      consistently")
    
    Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
    Cc: stable <stable@kernel.org>  # b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
    Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
    Link: https://lore.kernel.org/r/20240409014059.6740-1-quic_wcheng@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: gadget: f_fs: use io_data->status consistently [+ + +]
Author: John Keeping <john@keeping.me.uk>
Date:   Thu Nov 24 17:04:28 2022 +0000

    usb: gadget: f_fs: use io_data->status consistently
    
    [ Upstream commit b566d38857fcb6777f25b674b90a831eec0817a2 ]
    
    Commit fb1f16d74e26 ("usb: gadget: f_fs: change ep->status safe in
    ffs_epfile_io()") added a new ffs_io_data::status field to fix lifetime
    issues in synchronous requests.
    
    While there are no similar lifetime issues for asynchronous requests
    (the separate ep member in ffs_io_data avoids them) using the status
    field means the USB request can be freed earlier and that there is more
    consistency between the synchronous and asynchronous I/O paths.
    
    Cc: Linyu Yuan <quic_linyyuan@quicinc.com>
    Signed-off-by: John Keeping <john@metanate.com>
    Reviewed-by: Linyu Yuan <quic_linyyuan@quicinc.com>
    Link: https://lore.kernel.org/r/20221124170430.3998755-1-john@metanate.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 24729b307eef ("usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: gadget: printer: fix races against disable [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Jun 20 13:40:26 2024 +0200

    usb: gadget: printer: fix races against disable
    
    commit e587a7633dfee8987a999cf253f7c52a8e09276c upstream.
    
    printer_read() and printer_write() guard against the race
    against disable() by checking the dev->interface flag,
    which in turn is guarded by a spinlock.
    These functions, however, drop the lock on multiple occasions.
    This means that the test has to be redone after reacquiring
    the lock and before doing IO.
    
    Add the tests.
    
    This also addresses CVE-2024-25741
    
    Fixes: 7f2ca14d2f9b9 ("usb: gadget: function: printer: Interface is disabled and returns error")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20240620114039.5767-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: printer: SS+ support [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Jun 20 11:37:39 2024 +0200

    usb: gadget: printer: SS+ support
    
    commit fd80731e5e9d1402cb2f85022a6abf9b1982ec5f upstream.
    
    We need to treat super speed plus as super speed, not the default,
    which is full speed.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20240620093800.28901-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: misc: uss720: check for incompatible versions of the Belkin F5U002 [+ + +]
Author: Alex Henrie <alexhenrie24@gmail.com>
Date:   Tue Mar 26 09:07:11 2024 -0600

    usb: misc: uss720: check for incompatible versions of the Belkin F5U002
    
    [ Upstream commit 3295f1b866bfbcabd625511968e8a5c541f9ab32 ]
    
    The incompatible device in my possession has a sticker that says
    "F5U002 Rev 2" and "P80453-B", and lsusb identifies it as
    "050d:0002 Belkin Components IEEE-1284 Controller". There is a bug
    report from 2007 from Michael Trausch who was seeing the exact same
    errors that I saw in 2024 trying to use this cable.
    
    Link: https://lore.kernel.org/all/46DE5830.9060401@trausch.us/
    Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
    Link: https://lore.kernel.org/r/20240326150723.99939-5-alexhenrie24@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: musb: da8xx: fix a resource leak in probe() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Mon Jun 17 12:31:30 2024 +0300

    usb: musb: da8xx: fix a resource leak in probe()
    
    commit de644a4a86be04ed8a43ef8267d0f7d021941c5e upstream.
    
    Call usb_phy_generic_unregister() if of_platform_populate() fails.
    
    Fixes: d6299b6efbf6 ("usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/69af1b1d-d3f4-492b-bcea-359ca5949f30@moroto.mountain
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: tcpm: Ignore received Hard Reset in TOGGLING state [+ + +]
Author: Kyle Tso <kyletso@google.com>
Date:   Mon May 20 23:48:58 2024 +0800

    usb: typec: tcpm: Ignore received Hard Reset in TOGGLING state
    
    commit fc8fb9eea94d8f476e15f3a4a7addeb16b3b99d6 upstream.
    
    Similar to what fixed in Commit a6fe37f428c1 ("usb: typec: tcpm: Skip
    hard reset when in error recovery"), the handling of the received Hard
    Reset has to be skipped during TOGGLING state.
    
    [ 4086.021288] VBUS off
    [ 4086.021295] pending state change SNK_READY -> SNK_UNATTACHED @ 650 ms [rev2 NONE_AMS]
    [ 4086.022113] VBUS VSAFE0V
    [ 4086.022117] state change SNK_READY -> SNK_UNATTACHED [rev2 NONE_AMS]
    [ 4086.022447] VBUS off
    [ 4086.022450] state change SNK_UNATTACHED -> SNK_UNATTACHED [rev2 NONE_AMS]
    [ 4086.023060] VBUS VSAFE0V
    [ 4086.023064] state change SNK_UNATTACHED -> SNK_UNATTACHED [rev2 NONE_AMS]
    [ 4086.023070] disable BIST MODE TESTDATA
    [ 4086.023766] disable vbus discharge ret:0
    [ 4086.023911] Setting usb_comm capable false
    [ 4086.028874] Setting voltage/current limit 0 mV 0 mA
    [ 4086.028888] polarity 0
    [ 4086.030305] Requesting mux state 0, usb-role 0, orientation 0
    [ 4086.033539] Start toggling
    [ 4086.038496] state change SNK_UNATTACHED -> TOGGLING [rev2 NONE_AMS]
    
    // This Hard Reset is unexpected
    [ 4086.038499] Received hard reset
    [ 4086.038501] state change TOGGLING -> HARD_RESET_START [rev2 HARD_RESET]
    
    Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kyle Tso <kyletso@google.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240520154858.1072347-1-kyletso@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vduse: Temporarily fail if control queue feature requested [+ + +]
Author: Maxime Coquelin <maxime.coquelin@redhat.com>
Date:   Tue Jan 9 12:10:24 2024 +0100

    vduse: Temporarily fail if control queue feature requested
    
    [ Upstream commit 56e71885b0349241c07631a7b979b61e81afab6a ]
    
    Virtio-net driver control queue implementation is not safe
    when used with VDUSE. If the VDUSE application does not
    reply to control queue messages, it currently ends up
    hanging the kernel thread sending this command.
    
    Some work is on-going to make the control queue
    implementation robust with VDUSE. Until it is completed,
    let's fail features check if control-queue feature is
    requested.
    
    Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
    Message-Id: <20240109111025.1320976-3-maxime.coquelin@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Eugenio Pérez <eperezma@redhat.com>
    Reviewed-by: Xie Yongji <xieyongji@bytedance.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

vduse: validate block features only with block devices [+ + +]
Author: Maxime Coquelin <maxime.coquelin@redhat.com>
Date:   Tue Jan 9 12:10:23 2024 +0100

    vduse: validate block features only with block devices
    
    [ Upstream commit a115b5716fc9a64652aa9cb332070087178ffafa ]
    
    This patch is preliminary work to enable network device
    type support to VDUSE.
    
    As VIRTIO_BLK_F_CONFIG_WCE shares the same value as
    VIRTIO_NET_F_HOST_TSO4, we need to restrict its check
    to Virtio-blk device type.
    
    Acked-by: Jason Wang <jasowang@redhat.com>
    Reviewed-by: Xie Yongji <xieyongji@bytedance.com>
    Reviewed-by: Eugenio Pérez <eperezma@redhat.com>
    Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
    Message-Id: <20240109111025.1320976-2-maxime.coquelin@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio_net: checksum offloading handling fix [+ + +]
Author: Heng Qi <hengqi@linux.alibaba.com>
Date:   Mon Jun 17 21:15:23 2024 +0800

    virtio_net: checksum offloading handling fix
    
    [ Upstream commit 604141c036e1b636e2a71cf6e1aa09d1e45f40c2 ]
    
    In virtio spec 0.95, VIRTIO_NET_F_GUEST_CSUM was designed to handle
    partially checksummed packets, and the validation of fully checksummed
    packets by the device is independent of VIRTIO_NET_F_GUEST_CSUM
    negotiation. However, the specification erroneously stated:
    
      "If VIRTIO_NET_F_GUEST_CSUM is not negotiated, the device MUST set flags
       to zero and SHOULD supply a fully checksummed packet to the driver."
    
    This statement is inaccurate because even without VIRTIO_NET_F_GUEST_CSUM
    negotiation, the device can still set the VIRTIO_NET_HDR_F_DATA_VALID flag.
    Essentially, the device can facilitate the validation of these packets'
    checksums - a process known as RX checksum offloading - removing the need
    for the driver to do so.
    
    This scenario is currently not implemented in the driver and requires
    correction. The necessary specification correction[1] has been made and
    approved in the virtio TC vote.
    [1] https://lists.oasis-open.org/archives/virtio-comment/202401/msg00011.html
    
    Fixes: 4f49129be6fa ("virtio-net: Set RXCSUM feature if GUEST_CSUM is available")
    Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vmci: prevent speculation leaks by sanitizing event in event_deliver() [+ + +]
Author: Hagar Gamal Halim Hemdan <hagarhem@amazon.com>
Date:   Tue Apr 30 08:59:16 2024 +0000

    vmci: prevent speculation leaks by sanitizing event in event_deliver()
    
    commit 8003f00d895310d409b2bf9ef907c56b42a4e0f4 upstream.
    
    Coverity spotted that event_msg is controlled by user-space,
    event_msg->event_data.event is passed to event_deliver() and used
    as an index without sanitization.
    
    This change ensures that the event index is sanitized to mitigate any
    possibility of speculative information leaks.
    
    This bug was discovered and resolved using Coverity Static Analysis
    Security Testing (SAST) by Synopsys, Inc.
    
    Only compile tested, no access to HW.
    
    Fixes: 1d990201f9bb ("VMCI: event handling implementation.")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Hagar Gamal Halim Hemdan <hagarhem@amazon.com>
    Link: https://lore.kernel.org/stable/20231127193533.46174-1-hagarhem%40amazon.com
    Link: https://lore.kernel.org/r/20240430085916.4753-1-hagarhem@amazon.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

    vxlan: Fix regression when dropping packets due to invalid src addresses
    
    [ Upstream commit 1cd4bc987abb2823836cbb8f887026011ccddc8a ]
    
    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 <daniel@iogearbox.net>
    Cc: David Bauer <mail@david-bauer.net>
    Cc: Ido Schimmel <idosch@nvidia.com>
    Cc: Nikolay Aleksandrov <razor@blackwall.org>
    Cc: Martin KaFai Lau <martin.lau@kernel.org>
    Reviewed-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
    Reviewed-by: David Bauer <mail@david-bauer.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: ath10k: fix QCOM_RPROC_COMMON dependency [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri May 17 10:00:28 2024 +0300

    wifi: ath10k: fix QCOM_RPROC_COMMON dependency
    
    [ Upstream commit 21ae74e1bf18331ae5e279bd96304b3630828009 ]
    
    If ath10k_snoc is built-in, while Qualcomm remoteprocs are built as
    modules, compilation fails with:
    
    /usr/bin/aarch64-linux-gnu-ld: drivers/net/wireless/ath/ath10k/snoc.o: in function `ath10k_modem_init':
    drivers/net/wireless/ath/ath10k/snoc.c:1534: undefined reference to `qcom_register_ssr_notifier'
    /usr/bin/aarch64-linux-gnu-ld: drivers/net/wireless/ath/ath10k/snoc.o: in function `ath10k_modem_deinit':
    drivers/net/wireless/ath/ath10k/snoc.c:1551: undefined reference to `qcom_unregister_ssr_notifier'
    
    Add corresponding dependency to ATH10K_SNOC Kconfig entry so that it's
    built as module if QCOM_RPROC_COMMON is built as module too.
    
    Fixes: 747ff7d3d742 ("ath10k: Don't always treat modem stop events as crashes")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://msgid.link/20240511-ath10k-snoc-dep-v1-1-9666e3af5c27@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: ath9k: work around memset overflow warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Apr 4 09:35:59 2024 +0300

    wifi: ath9k: work around memset overflow warning
    
    [ Upstream commit 61752ac69b69ed2e04444d090f6917c77ab36d42 ]
    
    gcc-9 and some other older versions produce a false-positive warning
    for zeroing two fields
    
    In file included from include/linux/string.h:369,
                     from drivers/net/wireless/ath/ath9k/main.c:18:
    In function 'fortify_memset_chk',
        inlined from 'ath9k_ps_wakeup' at drivers/net/wireless/ath/ath9k/main.c:140:3:
    include/linux/fortify-string.h:462:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
      462 |                         __write_overflow_field(p_size_field, size);
          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Using a struct_group seems to reliably avoid the warning and
    not make the code much uglier. The combined memset() should even
    save a couple of cpu cycles.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://msgid.link/20240328135509.3755090-3-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: Lock wiphy in cfg80211_get_station [+ + +]
Author: Remi Pommarel <repk@triplefau.lt>
Date:   Tue May 21 21:47:26 2024 +0200

    wifi: cfg80211: Lock wiphy in cfg80211_get_station
    
    [ Upstream commit 642f89daa34567d02f312d03e41523a894906dae ]
    
    Wiphy should be locked before calling rdev_get_station() (see lockdep
    assert in ieee80211_get_station()).
    
    This fixes the following kernel NULL dereference:
    
     Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050
     Mem abort info:
       ESR = 0x0000000096000006
       EC = 0x25: DABT (current EL), IL = 32 bits
       SET = 0, FnV = 0
       EA = 0, S1PTW = 0
       FSC = 0x06: level 2 translation fault
     Data abort info:
       ISV = 0, ISS = 0x00000006
       CM = 0, WnR = 0
     user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000
     [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000
     Internal error: Oops: 0000000096000006 [#1] SMP
     Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath
     CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705
     Hardware name: RPT (r1) (DT)
     Workqueue: bat_events batadv_v_elp_throughput_metric_update
     pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core]
     lr : sta_set_sinfo+0xcc/0xbd4
     sp : ffff000007b43ad0
     x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98
     x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000
     x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc
     x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000
     x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d
     x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e
     x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000
     x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000
     x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90
     x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000
     Call trace:
      ath10k_sta_statistics+0x10/0x2dc [ath10k_core]
      sta_set_sinfo+0xcc/0xbd4
      ieee80211_get_station+0x2c/0x44
      cfg80211_get_station+0x80/0x154
      batadv_v_elp_get_throughput+0x138/0x1fc
      batadv_v_elp_throughput_metric_update+0x1c/0xa4
      process_one_work+0x1ec/0x414
      worker_thread+0x70/0x46c
      kthread+0xdc/0xe0
      ret_from_fork+0x10/0x20
     Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)
    
    This happens because STA has time to disconnect and reconnect before
    batadv_v_elp_throughput_metric_update() delayed work gets scheduled. In
    this situation, ath10k_sta_state() can be in the middle of resetting
    arsta data when the work queue get chance to be scheduled and ends up
    accessing it. Locking wiphy prevents that.
    
    Fixes: 7406353d43c8 ("cfg80211: implement cfg80211_get_station cfg80211 API")
    Signed-off-by: Remi Pommarel <repk@triplefau.lt>
    Reviewed-by: Nicolas Escande <nico.escande@gmail.com>
    Acked-by: Antonio Quartulli <a@unstable.cc>
    Link: https://msgid.link/983b24a6a176e0800c01aedcd74480d9b551cb13.1716046653.git.repk@triplefau.lt
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: pmsr: use correct nla_get_uX functions [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Tue May 21 15:50:59 2024 +0800

    wifi: cfg80211: pmsr: use correct nla_get_uX functions
    
    [ Upstream commit ab904521f4de52fef4f179d2dfc1877645ef5f5c ]
    
    The commit 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM
    initiator API") defines four attributes NL80211_PMSR_FTM_REQ_ATTR_
    {NUM_BURSTS_EXP}/{BURST_PERIOD}/{BURST_DURATION}/{FTMS_PER_BURST} in
    following ways.
    
    static const struct nla_policy
    nl80211_pmsr_ftm_req_attr_policy[NL80211_PMSR_FTM_REQ_ATTR_MAX + 1] = {
        ...
        [NL80211_PMSR_FTM_REQ_ATTR_NUM_BURSTS_EXP] =
            NLA_POLICY_MAX(NLA_U8, 15),
        [NL80211_PMSR_FTM_REQ_ATTR_BURST_PERIOD] = { .type = NLA_U16 },
        [NL80211_PMSR_FTM_REQ_ATTR_BURST_DURATION] =
            NLA_POLICY_MAX(NLA_U8, 15),
        [NL80211_PMSR_FTM_REQ_ATTR_FTMS_PER_BURST] =
            NLA_POLICY_MAX(NLA_U8, 31),
        ...
    };
    
    That is, those attributes are expected to be NLA_U8 and NLA_U16 types.
    However, the consumers of these attributes in `pmsr_parse_ftm` blindly
    all use `nla_get_u32`, which is incorrect and causes functionality issues
    on little-endian platforms. Hence, fix them with the correct `nla_get_u8`
    and `nla_get_u16` functions.
    
    Fixes: 9bb7e0f24e7e ("cfg80211: add peer measurement with FTM initiator API")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Link: https://msgid.link/20240521075059.47999-1-linma@zju.edu.cn
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: dbg_ini: move iwl_dbg_tlv_free outside of debugfs ifdef [+ + +]
Author: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Date:   Fri May 10 17:06:39 2024 +0300

    wifi: iwlwifi: dbg_ini: move iwl_dbg_tlv_free outside of debugfs ifdef
    
    [ Upstream commit 87821b67dea87addbc4ab093ba752753b002176a ]
    
    The driver should call iwl_dbg_tlv_free even if debugfs is not defined
    since ini mode does not depend on debugfs ifdef.
    
    Fixes: 68f6f492c4fa ("iwlwifi: trans: support loading ini TLVs from external file")
    Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
    Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240510170500.c8e3723f55b0.I5e805732b0be31ee6b83c642ec652a34e974ff10@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: check n_ssids before accessing the ssids [+ + +]
Author: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Date:   Mon May 13 13:27:12 2024 +0300

    wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
    
    [ Upstream commit 60d62757df30b74bf397a2847a6db7385c6ee281 ]
    
    In some versions of cfg80211, the ssids poinet might be a valid one even
    though n_ssids is 0. Accessing the pointer in this case will cuase an
    out-of-bound access. Fix this by checking n_ssids first.
    
    Fixes: c1a7515393e4 ("iwlwifi: mvm: add adaptive dwell support")
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Reviewed-by: Ilan Peer <ilan.peer@intel.com>
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Link: https://msgid.link/20240513132416.6e4d1762bf0d.I5a0e6cc8f02050a766db704d15594c61fe583d45@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: don't read past the mfuart notifcation [+ + +]
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Mon May 13 13:27:14 2024 +0300

    wifi: iwlwifi: mvm: don't read past the mfuart notifcation
    
    [ Upstream commit 4bb95f4535489ed830cf9b34b0a891e384d1aee4 ]
    
    In case the firmware sends a notification that claims it has more data
    than it has, we will read past that was allocated for the notification.
    Remove the print of the buffer, we won't see it by default. If needed,
    we can see the content with tracing.
    
    This was reported by KFENCE.
    
    Fixes: bdccdb854f2f ("iwlwifi: mvm: support MFUART dump in case of MFUART assert")
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Reviewed-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240513132416.ba82a01a559e.Ia91dd20f5e1ca1ad380b95e68aebf2794f553d9b@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: revert gen2 TX A-MPDU size to 64 [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri May 10 17:06:33 2024 +0300

    wifi: iwlwifi: mvm: revert gen2 TX A-MPDU size to 64
    
    [ Upstream commit 4a7aace2899711592327463c1a29ffee44fcc66e ]
    
    We don't actually support >64 even for HE devices, so revert
    back to 64. This fixes an issue where the session is refused
    because the queue is configured differently from the actual
    session later.
    
    Fixes: 514c30696fbc ("iwlwifi: add support for IEEE802.11ax")
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Reviewed-by: Liad Kaufman <liad.kaufman@intel.com>
    Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Link: https://msgid.link/20240510170500.52f7b4cf83aa.If47e43adddf7fe250ed7f5571fbb35d8221c7c47@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: correctly parse Spatial Reuse Parameter Set element [+ + +]
Author: Lingbo Kong <quic_lingbok@quicinc.com>
Date:   Thu May 16 10:18:54 2024 +0800

    wifi: mac80211: correctly parse Spatial Reuse Parameter Set element
    
    [ Upstream commit a26d8dc5227f449a54518a8b40733a54c6600a8b ]
    
    Currently, the way of parsing Spatial Reuse Parameter Set element is
    incorrect and some members of struct ieee80211_he_obss_pd are not assigned.
    
    To address this issue, it must be parsed in the order of the elements of
    Spatial Reuse Parameter Set defined in the IEEE Std 802.11ax specification.
    
    The diagram of the Spatial Reuse Parameter Set element (IEEE Std 802.11ax
    -2021-9.4.2.252).
    
    -------------------------------------------------------------------------
    |       |      |         |       |Non-SRG|  SRG  | SRG   | SRG  | SRG   |
    |Element|Length| Element |  SR   |OBSS PD|OBSS PD|OBSS PD| BSS  |Partial|
    |   ID  |      |   ID    |Control|  Max  |  Min  | Max   |Color | BSSID |
    |       |      |Extension|       | Offset| Offset|Offset |Bitmap|Bitmap |
    -------------------------------------------------------------------------
    
    Fixes: 1ced169cc1c2 ("mac80211: allow setting spatial reuse parameters from bss_conf")
    Signed-off-by: Lingbo Kong <quic_lingbok@quicinc.com>
    Link: https://msgid.link/20240516021854.5682-3-quic_lingbok@quicinc.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup() [+ + +]
Author: Remi Pommarel <repk@triplefau.lt>
Date:   Wed May 29 08:57:53 2024 +0200

    wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()
    
    [ Upstream commit 44c06bbde6443de206b30f513100b5670b23fc5e ]
    
    The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to
    synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from
    softirq context. However using only spin_lock() to get sta->ps_lock in
    ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute
    on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to
    take this same lock ending in deadlock. Below is an example of rcu stall
    that arises in such situation.
    
     rcu: INFO: rcu_sched self-detected stall on CPU
     rcu:    2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996
     rcu:    (t=42586894 jiffies g=2057 q=362405 ncpus=4)
     CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G        W          6.4.0-02158-g1b062f552873 #742
     Hardware name: RPT (r1) (DT)
     pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : queued_spin_lock_slowpath+0x58/0x2d0
     lr : invoke_tx_handlers_early+0x5b4/0x5c0
     sp : ffff00001ef64660
     x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8
     x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000
     x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000
     x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000
     x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80
     x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da
     x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440
     x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880
     x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000
     x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8
     Call trace:
      queued_spin_lock_slowpath+0x58/0x2d0
      ieee80211_tx+0x80/0x12c
      ieee80211_tx_pending+0x110/0x278
      tasklet_action_common.constprop.0+0x10c/0x144
      tasklet_action+0x20/0x28
      _stext+0x11c/0x284
      ____do_softirq+0xc/0x14
      call_on_irq_stack+0x24/0x34
      do_softirq_own_stack+0x18/0x20
      do_softirq+0x74/0x7c
      __local_bh_enable_ip+0xa0/0xa4
      _ieee80211_wake_txqs+0x3b0/0x4b8
      __ieee80211_wake_queue+0x12c/0x168
      ieee80211_add_pending_skbs+0xec/0x138
      ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480
      ieee80211_mps_sta_status_update.part.0+0xd8/0x11c
      ieee80211_mps_sta_status_update+0x18/0x24
      sta_apply_parameters+0x3bc/0x4c0
      ieee80211_change_station+0x1b8/0x2dc
      nl80211_set_station+0x444/0x49c
      genl_family_rcv_msg_doit.isra.0+0xa4/0xfc
      genl_rcv_msg+0x1b0/0x244
      netlink_rcv_skb+0x38/0x10c
      genl_rcv+0x34/0x48
      netlink_unicast+0x254/0x2bc
      netlink_sendmsg+0x190/0x3b4
      ____sys_sendmsg+0x1e8/0x218
      ___sys_sendmsg+0x68/0x8c
      __sys_sendmsg+0x44/0x84
      __arm64_sys_sendmsg+0x20/0x28
      do_el0_svc+0x6c/0xe8
      el0_svc+0x14/0x48
      el0t_64_sync_handler+0xb0/0xb4
      el0t_64_sync+0x14c/0x150
    
    Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise
    on the same CPU that is holding the lock.
    
    Fixes: 1d147bfa6429 ("mac80211: fix AP powersave TX vs. wakeup race")
    Signed-off-by: Remi Pommarel <repk@triplefau.lt>
    Link: https://msgid.link/8e36fe07d0fbc146f89196cd47a53c8a0afe84aa.1716910344.git.repk@triplefau.lt
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects [+ + +]
Author: Nicolas Escande <nico.escande@gmail.com>
Date:   Tue May 28 16:26:05 2024 +0200

    wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
    
    [ Upstream commit b7d7f11a291830fdf69d3301075dd0fb347ced84 ]
    
    The hwmp code use objects of type mesh_preq_queue, added to a list in
    ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath
    gets deleted, ex mesh interface is removed, the entries in that list will
    never get cleaned. Fix this by flushing all corresponding items of the
    preq_queue in mesh_path_flush_pending().
    
    This should take care of KASAN reports like this:
    
    unreferenced object 0xffff00000668d800 (size 128):
      comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s)
      hex dump (first 32 bytes):
        00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff  ..........h.....
        8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00  ....>...........
      backtrace:
        [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c
        [<00000000049bd418>] kmalloc_trace+0x34/0x80
        [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8
        [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c
        [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4
        [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764
        [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4
        [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440
        [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c
        [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4
        [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508
        [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c
        [<00000000b36425d1>] worker_thread+0x9c/0x634
        [<0000000005852dd5>] kthread+0x1bc/0x1c4
        [<000000005fccd770>] ret_from_fork+0x10/0x20
    unreferenced object 0xffff000009051f00 (size 128):
      comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s)
      hex dump (first 32 bytes):
        90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff  ..........h.....
        36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff  6'.......Xy.....
      backtrace:
        [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c
        [<00000000049bd418>] kmalloc_trace+0x34/0x80
        [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8
        [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c
        [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4
        [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764
        [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4
        [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440
        [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c
        [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4
        [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508
        [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c
        [<00000000b36425d1>] worker_thread+0x9c/0x634
        [<0000000005852dd5>] kthread+0x1bc/0x1c4
        [<000000005fccd770>] ret_from_fork+0x10/0x20
    
    Fixes: 050ac52cbe1f ("mac80211: code for on-demand Hybrid Wireless Mesh Protocol")
    Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
    Link: https://msgid.link/20240528142605.1060566-1-nico.escande@gmail.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
wifi: rtlwifi: rtl8192de: Fix 5 GHz TX power [+ + +]
Author: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Date:   Thu Apr 25 21:09:21 2024 +0300

    wifi: rtlwifi: rtl8192de: Fix 5 GHz TX power
    
    [ Upstream commit de4d4be4fa64ed7b4aa1c613061015bd8fa98b24 ]
    
    Different channels have different TX power settings. rtl8192de is using
    the TX power setting from the wrong channel in the 5 GHz band because
    _rtl92c_phy_get_rightchnlplace expects an array which includes all the
    channel numbers, but it's using an array which includes only the 5 GHz
    channel numbers.
    
    Use the array channel_all (defined in rtl8192de/phy.c) instead of
    the incorrect channel5g (defined in core.c).
    
    Tested only with rtl8192du, which will use the same TX power code.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://msgid.link/c7653517-cf88-4f57-b79a-8edb0a8b32f0@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/amd_nb: Check for invalid SMN reads [+ + +]
Author: Yazen Ghannam <yazen.ghannam@amd.com>
Date:   Mon Apr 3 16:42:44 2023 +0000

    x86/amd_nb: Check for invalid SMN reads
    
    [ Upstream commit c625dabbf1c4a8e77e4734014f2fde7aa9071a1f ]
    
    AMD Zen-based systems use a System Management Network (SMN) that
    provides access to implementation-specific registers.
    
    SMN accesses are done indirectly through an index/data pair in PCI
    config space. The PCI config access may fail and return an error code.
    This would prevent the "read" value from being updated.
    
    However, the PCI config access may succeed, but the return value may be
    invalid. This is in similar fashion to PCI bad reads, i.e. return all
    bits set.
    
    Most systems will return 0 for SMN addresses that are not accessible.
    This is in line with AMD convention that unavailable registers are
    Read-as-Zero/Writes-Ignored.
    
    However, some systems will return a "PCI Error Response" instead. This
    value, along with an error code of 0 from the PCI config access, will
    confuse callers of the amd_smn_read() function.
    
    Check for this condition, clear the return value, and set a proper error
    code.
    
    Fixes: ddfe43cdc0da ("x86/amd_nb: Add SMN and Indirect Data Fabric access for AMD Fam17h")
    Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230403164244.471141-1-yazen.ghannam@amd.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/cpu/vfm: Add new macros to work with (vendor/family/model) values [+ + +]
Author: Tony Luck <tony.luck@intel.com>
Date:   Tue Apr 16 14:19:04 2024 -0700

    x86/cpu/vfm: Add new macros to work with (vendor/family/model) values
    
    [ Upstream commit e6dfdc2e89a0adedf455814c91b977d6a584cc88 ]
    
    To avoid adding a slew of new macros for each new Intel CPU family
    switch over from providing CPU model number #defines to a new
    scheme that encodes vendor, family, and model in a single number.
    
      [ bp: s/casted/cast/g ]
    
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20240416211941.9369-3-tony.luck@intel.com
    Stable-dep-of: 93022482b294 ("x86/cpu: Fix x86_match_cpu() to match just X86_VENDOR_INTEL")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/cpu: Fix x86_match_cpu() to match just X86_VENDOR_INTEL [+ + +]
Author: Tony Luck <tony.luck@intel.com>
Date:   Mon May 20 15:45:33 2024 -0700

    x86/cpu: Fix x86_match_cpu() to match just X86_VENDOR_INTEL
    
    [ Upstream commit 93022482b2948a9a7e9b5a2bb685f2e1cb4c3348 ]
    
    Code in v6.9 arch/x86/kernel/smpboot.c was changed by commit
    
      4db64279bc2b ("x86/cpu: Switch to new Intel CPU model defines") from:
    
      static const struct x86_cpu_id intel_cod_cpu[] = {
              X86_MATCH_INTEL_FAM6_MODEL(HASWELL_X, 0),       /* COD */
              X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_X, 0),     /* COD */
              X86_MATCH_INTEL_FAM6_MODEL(ANY, 1),             /* SNC */     <--- 443
              {}
      };
    
      static bool match_llc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
      {
              const struct x86_cpu_id *id = x86_match_cpu(intel_cod_cpu);
    
    to:
    
      static const struct x86_cpu_id intel_cod_cpu[] = {
               X86_MATCH_VFM(INTEL_HASWELL_X,   0),    /* COD */
               X86_MATCH_VFM(INTEL_BROADWELL_X, 0),    /* COD */
               X86_MATCH_VFM(INTEL_ANY,         1),    /* SNC */
               {}
       };
    
      static bool match_llc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
      {
              const struct x86_cpu_id *id = x86_match_cpu(intel_cod_cpu);
    
    On an Intel CPU with SNC enabled this code previously matched the rule on line
    443 to avoid printing messages about insane cache configuration.  The new code
    did not match any rules.
    
    Expanding the macros for the intel_cod_cpu[] array shows that the old is
    equivalent to:
    
      static const struct x86_cpu_id intel_cod_cpu[] = {
      [0] = { .vendor = 0, .family = 6, .model = 0x3F, .steppings = 0, .feature = 0, .driver_data = 0 },
      [1] = { .vendor = 0, .family = 6, .model = 0x4F, .steppings = 0, .feature = 0, .driver_data = 0 },
      [2] = { .vendor = 0, .family = 6, .model = 0x00, .steppings = 0, .feature = 0, .driver_data = 1 },
      [3] = { .vendor = 0, .family = 0, .model = 0x00, .steppings = 0, .feature = 0, .driver_data = 0 }
      }
    
    while the new code expands to:
    
      static const struct x86_cpu_id intel_cod_cpu[] = {
      [0] = { .vendor = 0, .family = 6, .model = 0x3F, .steppings = 0, .feature = 0, .driver_data = 0 },
      [1] = { .vendor = 0, .family = 6, .model = 0x4F, .steppings = 0, .feature = 0, .driver_data = 0 },
      [2] = { .vendor = 0, .family = 0, .model = 0x00, .steppings = 0, .feature = 0, .driver_data = 1 },
      [3] = { .vendor = 0, .family = 0, .model = 0x00, .steppings = 0, .feature = 0, .driver_data = 0 }
      }
    
    Looking at the code for x86_match_cpu():
    
      const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
      {
               const struct x86_cpu_id *m;
               struct cpuinfo_x86 *c = &boot_cpu_data;
    
               for (m = match;
                    m->vendor | m->family | m->model | m->steppings | m->feature;
                    m++) {
                    ...
               }
               return NULL;
    
    it is clear that there was no match because the ANY entry in the table (array
    index 2) is now the loop termination condition (all of vendor, family, model,
    steppings, and feature are zero).
    
    So this code was working before because the "ANY" check was looking for any
    Intel CPU in family 6. But fails now because the family is a wild card. So the
    root cause is that x86_match_cpu() has never been able to match on a rule with
    just X86_VENDOR_INTEL and all other fields set to wildcards.
    
    Add a new flags field to struct x86_cpu_id that has a bit set to indicate that
    this entry in the array is valid. Update X86_MATCH*() macros to set that bit.
    Change the end-marker check in x86_match_cpu() to just check the flags field
    for this bit.
    
    Backporter notes: The commit in Fixes is really the one that is broken:
    you can't have m->vendor as part of the loop termination conditional in
    x86_match_cpu() because it can happen - as it has happened above
    - that that whole conditional is 0 albeit vendor == 0 is a valid case
    - X86_VENDOR_INTEL is 0.
    
    However, the only case where the above happens is the SNC check added by
    4db64279bc2b1 so you only need this fix if you have backported that
    other commit
    
      4db64279bc2b ("x86/cpu: Switch to new Intel CPU model defines")
    
    Fixes: 644e9cbbe3fc ("Add driver auto probing for x86 features v4")
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Suggested-by: Borislav Petkov <bp@alien8.de>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: <stable+noautosel@kernel.org> # see above
    Link: https://lore.kernel.org/r/20240517144312.GBZkdtAOuJZCvxhFbJ@fat_crate.local
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/fpu: Fix AMD X86_BUG_FXSAVE_LEAK fixup [+ + +]
Author: Uros Bizjak <ubizjak@gmail.com>
Date:   Fri Mar 15 09:18:23 2024 +0100

    x86/fpu: Fix AMD X86_BUG_FXSAVE_LEAK fixup
    
    [ Upstream commit 5d31174f3c8c465d9dbe88f6b9d1fe5716f44981 ]
    
    The assembly snippet in restore_fpregs_from_fpstate() that implements
    X86_BUG_FXSAVE_LEAK fixup loads the value from a random variable,
    preferably the one that is already in the L1 cache.
    
    However, the access to fpinit_state via *fpstate pointer is not
    implemented correctly. The "m" asm constraint requires dereferenced
    pointer variable, otherwise the compiler just reloads the value
    via temporary stack slot. The current asm code reflects this:
    
         mov    %rdi,(%rsp)
         ...
         fildl  (%rsp)
    
    With dereferenced pointer variable, the code does what the
    comment above the asm snippet says:
    
         fildl  (%rdi)
    
    Also, remove the pointless %P operand modifier. The modifier is
    ineffective on non-symbolic references - it was used to prevent
    %rip-relative addresses in .altinstr sections, but FILDL in the
    .text section can use %rip-relative addresses without problems.
    
    Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://lore.kernel.org/r/20240315081849.5187-1-ubizjak@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/ibt,ftrace: Search for __fentry__ location [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Mar 8 16:30:29 2022 +0100

    x86/ibt,ftrace: Search for __fentry__ location
    
    [ Upstream commit aebfd12521d9c7d0b502cf6d06314cfbcdccfe3b ]
    
    Currently a lot of ftrace code assumes __fentry__ is at sym+0. However
    with Intel IBT enabled the first instruction of a function will most
    likely be ENDBR.
    
    Change ftrace_location() to not only return the __fentry__ location
    when called for the __fentry__ location, but also when called for the
    sym+0 location.
    
    Then audit/update all callsites of this function to consistently use
    these new semantics.
    
    Suggested-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
    Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Link: https://lore.kernel.org/r/20220308154318.227581603@infradead.org
    Stable-dep-of: e60b613df8b6 ("ftrace: Fix possible use-after-free issue in ftrace_location()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86: stop playing stack games in profile_pc() [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Jun 28 14:27:22 2024 -0700

    x86: stop playing stack games in profile_pc()
    
    [ Upstream commit 093d9603b60093a9aaae942db56107f6432a5dca ]
    
    The 'profile_pc()' function is used for timer-based profiling, which
    isn't really all that relevant any more to begin with, but it also ends
    up making assumptions based on the stack layout that aren't necessarily
    valid.
    
    Basically, the code tries to account the time spent in spinlocks to the
    caller rather than the spinlock, and while I support that as a concept,
    it's not worth the code complexity or the KASAN warnings when no serious
    profiling is done using timers anyway these days.
    
    And the code really does depend on stack layout that is only true in the
    simplest of cases.  We've lost the comment at some point (I think when
    the 32-bit and 64-bit code was unified), but it used to say:
    
            Assume the lock function has either no stack frame or a copy
            of eflags from PUSHF.
    
    which explains why it just blindly loads a word or two straight off the
    stack pointer and then takes a minimal look at the values to just check
    if they might be eflags or the return pc:
    
            Eflags always has bits 22 and up cleared unlike kernel addresses
    
    but that basic stack layout assumption assumes that there isn't any lock
    debugging etc going on that would complicate the code and cause a stack
    frame.
    
    It causes KASAN unhappiness reported for years by syzkaller [1] and
    others [2].
    
    With no real practical reason for this any more, just remove the code.
    
    Just for historical interest, here's some background commits relating to
    this code from 2006:
    
      0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels")
      31679f38d886 ("Simplify profile_pc on x86-64")
    
    and a code unification from 2009:
    
      ef4512882dbe ("x86: time_32/64.c unify profile_pc")
    
    but the basics of this thing actually goes back to before the git tree.
    
    Link: https://syzkaller.appspot.com/bug?extid=84fe685c02cd112a2ac3 [1]
    Link: https://lore.kernel.org/all/CAK55_s7Xyq=nh97=K=G1sxueOFrJDAvPOJAL4TPTCAYvmxO9_A@mail.gmail.com/ [2]
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xdp: Remove WARN() from __xdp_reg_mem_model() [+ + +]
Author: Daniil Dulov <d.dulov@aladdin.ru>
Date:   Mon Jun 24 11:07:47 2024 +0300

    xdp: Remove WARN() from __xdp_reg_mem_model()
    
    [ Upstream commit 7e9f79428372c6eab92271390851be34ab26bfb4 ]
    
    syzkaller reports a warning in __xdp_reg_mem_model().
    
    The warning occurs only if __mem_id_init_hash_table() returns an error. It
    returns the error in two cases:
    
      1. memory allocation fails;
      2. rhashtable_init() fails when some fields of rhashtable_params
         struct are not initialized properly.
    
    The second case cannot happen since there is a static const rhashtable_params
    struct with valid fields. So, warning is only triggered when there is a
    problem with memory allocation.
    
    Thus, there is no sense in using WARN() to handle this error and it can be
    safely removed.
    
    WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
    
    CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
    RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299
    
    Call Trace:
     xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344
     xdp_test_run_setup net/bpf/test_run.c:188 [inline]
     bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377
     bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267
     bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240
     __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649
     __do_sys_bpf kernel/bpf/syscall.c:5738 [inline]
     __se_sys_bpf kernel/bpf/syscall.c:5736 [inline]
     __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736
     do_syscall_64+0xfb/0x240
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    Found by Linux Verification Center (linuxtesting.org) with syzkaller.
    
    Fixes: 8d5d88527587 ("xdp: rhashtable with allocator ID to pointer mapping")
    Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
    Link: https://lore.kernel.org/all/20240617162708.492159-1-d.dulov@aladdin.ru
    Link: https://lore.kernel.org/bpf/20240624080747.36858-1-d.dulov@aladdin.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Jun 15 15:42:31 2024 +0000

    xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()
    
    [ Upstream commit d46401052c2d5614da8efea5788532f0401cb164 ]
    
    ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.
    
    syzbot reported:
    
    Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
    Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker
     RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64
    Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00
    RSP: 0018:ffffc90000117378 EFLAGS: 00010246
    RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7
    RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98
    RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000
    R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
      xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]
      xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]
      xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541
      xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835
      xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]
      xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201
      xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]
      xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309
      ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256
      send6+0x611/0xd20 drivers/net/wireguard/socket.c:139
      wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178
      wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200
      wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40
      wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51
      process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
      process_scheduled_works kernel/workqueue.c:3312 [inline]
      worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
      kthread+0x2c1/0x3a0 kernel/kthread.c:389
      ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
      ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20240615154231.234442-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xhci: Apply broken streams quirk to Etron EJ188 xHCI host [+ + +]
Author: Kuangyi Chiang <ki.chiang65@gmail.com>
Date:   Tue Jun 11 15:06:09 2024 +0300

    xhci: Apply broken streams quirk to Etron EJ188 xHCI host
    
    commit 91f7a1524a92c70ffe264db8bdfa075f15bbbeb9 upstream.
    
    As described in commit 8f873c1ff4ca ("xhci: Blacklist using streams on the
    Etron EJ168 controller"), EJ188 have the same issue as EJ168, where Streams
    do not work reliable on EJ188. So apply XHCI_BROKEN_STREAMS quirk to EJ188
    as well.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Kuangyi Chiang <ki.chiang65@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20240611120610.3264502-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Apply reset resume quirk to Etron EJ188 xHCI host [+ + +]
Author: Kuangyi Chiang <ki.chiang65@gmail.com>
Date:   Tue Jun 11 15:06:08 2024 +0300

    xhci: Apply reset resume quirk to Etron EJ188 xHCI host
    
    commit 17bd54555c2aaecfdb38e2734149f684a73fa584 upstream.
    
    As described in commit c877b3b2ad5c ("xhci: Add reset on resume quirk for
    asrock p67 host"), EJ188 have the same issue as EJ168, where completely
    dies on resume. So apply XHCI_RESET_ON_RESUME quirk to EJ188 as well.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Kuangyi Chiang <ki.chiang65@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20240611120610.3264502-3-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Handle TD clearing for multiple streams case [+ + +]
Author: Hector Martin <marcan@marcan.st>
Date:   Tue Jun 11 15:06:10 2024 +0300

    xhci: Handle TD clearing for multiple streams case
    
    commit 5ceac4402f5d975e5a01c806438eb4e554771577 upstream.
    
    When multiple streams are in use, multiple TDs might be in flight when
    an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for
    each, to ensure everything is reset properly and the caches cleared.
    Change the logic so that any N>1 TDs found active for different streams
    are deferred until after the first one is processed, calling
    xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to
    queue another command until we are done with all of them. Also change
    the error/"should never happen" paths to ensure we at least clear any
    affected TDs, even if we can't issue a command to clear the hardware
    cache, and complain loudly with an xhci_warn() if this ever happens.
    
    This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct
    assumptions about number of rings per endpoint.") early on in the XHCI
    driver's life, when stream support was first added.
    It was then identified but not fixed nor made into a warning in commit
    674f8438c121 ("xhci: split handling halted endpoints into two steps"),
    which added a FIXME comment for the problem case (without materially
    changing the behavior as far as I can tell, though the new logic made
    the problem more obvious).
    
    Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some
    cached cancelled URBs."), it was acknowledged again.
    
    [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached
    cancelled URBs.") was a targeted regression fix to the previously mentioned
    patch. Users reported issues with usb stuck after unmounting/disconnecting
    UAS devices. This rolled back the TD clearing of multiple streams to its
    original state.]
    
    Apparently the commit author was aware of the problem (yet still chose
    to submit it): It was still mentioned as a FIXME, an xhci_dbg() was
    added to log the problem condition, and the remaining issue was mentioned
    in the commit description. The choice of making the log type xhci_dbg()
    for what is, at this point, a completely unhandled and known broken
    condition is puzzling and unfortunate, as it guarantees that no actual
    users would see the log in production, thereby making it nigh
    undebuggable (indeed, even if you turn on DEBUG, the message doesn't
    really hint at there being a problem at all).
    
    It took me *months* of random xHC crashes to finally find a reliable
    repro and be able to do a deep dive debug session, which could all have
    been avoided had this unhandled, broken condition been actually reported
    with a warning, as it should have been as a bug intentionally left in
    unfixed (never mind that it shouldn't have been left in at all).
    
    > Another fix to solve clearing the caches of all stream rings with
    > cancelled TDs is needed, but not as urgent.
    
    3 years after that statement and 14 years after the original bug was
    introduced, I think it's finally time to fix it. And maybe next time
    let's not leave bugs unfixed (that are actually worse than the original
    bug), and let's actually get people to review kernel commits please.
    
    Fixes xHC crashes and IOMMU faults with UAS devices when handling
    errors/faults. Easiest repro is to use `hdparm` to mark an early sector
    (e.g. 1024) on a disk as bad, then `cat /dev/sdX > /dev/null` in a loop.
    At least in the case of JMicron controllers, the read errors end up
    having to cancel two TDs (for two queued requests to different streams)
    and the one that didn't get cleared properly ends up faulting the xHC
    entirely when it tries to access DMA pages that have since been unmapped,
    referred to by the stale TDs. This normally happens quickly (after two
    or three loops). After this fix, I left the `cat` in a loop running
    overnight and experienced no xHC failures, with all read errors
    recovered properly. Repro'd and tested on an Apple M1 Mac Mini
    (dwc3 host).
    
    On systems without an IOMMU, this bug would instead silently corrupt
    freed memory, making this a security bug (even on systems with IOMMUs
    this could silently corrupt memory belonging to other USB devices on the
    same controller, so it's still a security bug). Given that the kernel
    autoprobes partition tables, I'm pretty sure a malicious USB device
    pretending to be a UAS device and reporting an error with the right
    timing could deliberately trigger a UAF and write to freed memory, with
    no user action.
    
    [Mathias: Commit message and code comment edit, original at:]
    https://lore.kernel.org/linux-usb/20240524-xhci-streams-v1-1-6b1f13819bea@marcan.st/
    
    Fixes: e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.")
    Fixes: 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.")
    Fixes: 674f8438c121 ("xhci: split handling halted endpoints into two steps")
    Cc: stable@vger.kernel.org
    Cc: security@kernel.org
    Reviewed-by: Neal Gompa <neal@gompa.dev>
    Signed-off-by: Hector Martin <marcan@marcan.st>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20240611120610.3264502-5-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci: Set correct transferred length for cancelled bulk transfers [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Tue Jun 11 15:06:07 2024 +0300

    xhci: Set correct transferred length for cancelled bulk transfers
    
    commit f0260589b439e2637ad54a2b25f00a516ef28a57 upstream.
    
    The transferred length is set incorrectly for cancelled bulk
    transfer TDs in case the bulk transfer ring stops on the last transfer
    block with a 'Stop - Length Invalid' completion code.
    
    length essentially ends up being set to the requested length:
    urb->actual_length = urb->transfer_buffer_length
    
    Length for 'Stop - Length Invalid' cases should be the sum of all
    TRB transfer block lengths up to the one the ring stopped on,
    _excluding_ the one stopped on.
    
    Fix this by always summing up TRB lengths for 'Stop - Length Invalid'
    bulk cases.
    
    This issue was discovered by Alan Stern while debugging
    https://bugzilla.kernel.org/show_bug.cgi?id=218890, but does not
    solve that bug. Issue is older than 4.10 kernel but fix won't apply
    to those due to major reworks in that area.
    
    Tested-by: Pierre Tomon <pierretom+12@ik.me>
    Cc: stable@vger.kernel.org # v4.10+
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20240611120610.3264502-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING [+ + +]
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Sat Jun 8 14:06:16 2024 +0200

    zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING
    
    [ Upstream commit 7fea700e04bd3f424c2d836e98425782f97b494e ]
    
    kernel_wait4() doesn't sleep and returns -EINTR if there is no
    eligible child and signal_pending() is true.
    
    That is why zap_pid_ns_processes() clears TIF_SIGPENDING but this is not
    enough, it should also clear TIF_NOTIFY_SIGNAL to make signal_pending()
    return false and avoid a busy-wait loop.
    
    Link: https://lkml.kernel.org/r/20240608120616.GB7947@redhat.com
    Fixes: 12db8b690010 ("entry: Add support for TIF_NOTIFY_SIGNAL")
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Reported-by: Rachel Menge <rachelmenge@linux.microsoft.com>
    Closes: https://lore.kernel.org/all/1386cd49-36d0-4a5c-85e9-bc42056a5a38@linux.microsoft.com/
    Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
    Tested-by: Wei Fu <fuweid89@gmail.com>
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Cc: Allen Pais <apais@linux.microsoft.com>
    Cc: Christian Brauner <brauner@kernel.org>
    Cc: Frederic Weisbecker <frederic@kernel.org>
    Cc: Joel Fernandes (Google) <joel@joelfernandes.org>
    Cc: Joel Granados <j.granados@samsung.com>
    Cc: Josh Triplett <josh@joshtriplett.org>
    Cc: Lai Jiangshan <jiangshanlai@gmail.com>
    Cc: Mateusz Guzik <mjguzik@gmail.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Mike Christie <michael.christie@oracle.com>
    Cc: Neeraj Upadhyay <neeraj.upadhyay@kernel.org>
    Cc: Paul E. McKenney <paulmck@kernel.org>
    Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
    Cc: Zqiang <qiang.zhang1211@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>