Linux 6.6.28

 
accel/ivpu: Fix deadlock in context_xa [+ + +]
Author: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Date:   Tue Apr 2 12:49:29 2024 +0200

    accel/ivpu: Fix deadlock in context_xa
    
    commit fd7726e75968b27fe98534ccbf47ccd6fef686f3 upstream.
    
    ivpu_device->context_xa is locked both in kernel thread and IRQ context.
    It requires XA_FLAGS_LOCK_IRQ flag to be passed during initialization
    otherwise the lock could be acquired from a thread and interrupted by
    an IRQ that locks it for the second time causing the deadlock.
    
    This deadlock was reported by lockdep and observed in internal tests.
    
    Fixes: 35b137630f08 ("accel/ivpu: Introduce a new DRM driver for Intel VPU")
    Cc: <stable@vger.kernel.org> # v6.3+
    Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
    Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240402104929.941186-9-jacek.lawrynowicz@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ACPI: scan: Do not increase dep_unmet for already met dependencies [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Apr 6 13:40:52 2024 +0200

    ACPI: scan: Do not increase dep_unmet for already met dependencies
    
    commit d730192ff0246356a2d7e63ff5bd501060670eec upstream.
    
    On the Toshiba Encore WT10-A tablet the BATC battery ACPI device depends
    on 3 other devices:
    
                Name (_DEP, Package (0x03)  // _DEP: Dependencies
                {
                    I2C1,
                    GPO2,
                    GPO0
                })
    
    acpi_scan_check_dep() adds all 3 of these to the acpi_dep_list and then
    before an acpi_device is created for the BATC handle (and thus before
    acpi_scan_dep_init() runs) acpi_scan_clear_dep() gets called for both
    GPIO depenencies, with free_when_met not set for the dependencies.
    
    Since there is no adev for BATC yet, there also is no dep_unmet to
    decrement. The only result of acpi_scan_clear_dep() in this case is
    dep->met getting set.
    
    Soon after acpi_scan_clear_dep() has been called for the GPIO dependencies
    the acpi_device gets created for the BATC handle and acpi_scan_dep_init()
    runs, this sees 3 dependencies on the acpi_dep_list and initializes
    unmet_dep to 3. Later when the dependency for I2C1 is met unmet_dep
    becomes 2, but since the 2 GPIO deps where already met it never becomes 0
    causing battery monitoring to not work.
    
    Fix this by modifying acpi_scan_dep_init() to not increase dep_met for
    dependencies which have already been marked as being met.
    
    Fixes: 3ba12d8de3fa ("ACPI: scan: Reduce overhead related to devices with dependencies")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Cc: 6.5+ <stable@vger.kernel.org> # 6.5+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
af_unix: Clear stale u->oob_skb. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Fri Apr 5 15:10:57 2024 -0700

    af_unix: Clear stale u->oob_skb.
    
    [ Upstream commit b46f4eaa4f0ec38909fb0072eea3aeddb32f954e ]
    
    syzkaller started to report deadlock of unix_gc_lock after commit
    4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but
    it just uncovers the bug that has been there since commit 314001f0bf92
    ("af_unix: Add OOB support").
    
    The repro basically does the following.
    
      from socket import *
      from array import array
    
      c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
      c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB)
      c2.recv(1)  # blocked as no normal data in recv queue
    
      c2.close()  # done async and unblock recv()
      c1.close()  # done async and trigger GC
    
    A socket sends its file descriptor to itself as OOB data and tries to
    receive normal data, but finally recv() fails due to async close().
    
    The problem here is wrong handling of OOB skb in manage_oob().  When
    recvmsg() is called without MSG_OOB, manage_oob() is called to check
    if the peeked skb is OOB skb.  In such a case, manage_oob() pops it
    out of the receive queue but does not clear unix_sock(sk)->oob_skb.
    This is wrong in terms of uAPI.
    
    Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB.
    The 'o' is handled as OOB data.  When recv() is called twice without
    MSG_OOB, the OOB data should be lost.
    
      >>> from socket import *
      >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)
      >>> c1.send(b'hello', MSG_OOB)  # 'o' is OOB data
      5
      >>> c1.send(b'world')
      5
      >>> c2.recv(5)  # OOB data is not received
      b'hell'
      >>> c2.recv(5)  # OOB date is skipped
      b'world'
      >>> c2.recv(5, MSG_OOB)  # This should return an error
      b'o'
    
    In the same situation, TCP actually returns -EINVAL for the last
    recv().
    
    Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set
    EPOLLPRI even though the data has passed through by previous recv().
    
    To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing
    it from recv queue.
    
    The reason why the old GC did not trigger the deadlock is because the
    old GC relied on the receive queue to detect the loop.
    
    When it is triggered, the socket with OOB data is marked as GC candidate
    because file refcount == inflight count (1).  However, after traversing
    all inflight sockets, the socket still has a positive inflight count (1),
    thus the socket is excluded from candidates.  Then, the old GC lose the
    chance to garbage-collect the socket.
    
    With the old GC, the repro continues to create true garbage that will
    never be freed nor detected by kmemleak as it's linked to the global
    inflight list.  That's why we couldn't even notice the issue.
    
    Fixes: 314001f0bf92 ("af_unix: Add OOB support")
    Reported-by: syzbot+7f7f201cc2668a8fd169@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=7f7f201cc2668a8fd169
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240405221057.2406-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Do not use atomic ops for unix_sk(sk)->inflight. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Tue Jan 23 09:08:53 2024 -0800

    af_unix: Do not use atomic ops for unix_sk(sk)->inflight.
    
    [ Upstream commit 97af84a6bba2ab2b9c704c08e67de3b5ea551bb2 ]
    
    When touching unix_sk(sk)->inflight, we are always under
    spin_lock(&unix_gc_lock).
    
    Let's convert unix_sk(sk)->inflight to the normal unsigned long.
    
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240123170856.41348-3-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 47d8ac011fe1 ("af_unix: Fix garbage collector racing against connect()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

af_unix: Fix garbage collector racing against connect() [+ + +]
Author: Michal Luczaj <mhal@rbox.co>
Date:   Tue Apr 9 22:09:39 2024 +0200

    af_unix: Fix garbage collector racing against connect()
    
    [ Upstream commit 47d8ac011fe1c9251070e1bd64cb10b48193ec51 ]
    
    Garbage collector does not take into account the risk of embryo getting
    enqueued during the garbage collection. If such embryo has a peer that
    carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
    different set of children. Leading to an incorrectly elevated inflight
    count, and then a dangling pointer within the gc_inflight_list.
    
    sockets are AF_UNIX/SOCK_STREAM
    S is an unconnected socket
    L is a listening in-flight socket bound to addr, not in fdtable
    V's fd will be passed via sendmsg(), gets inflight count bumped
    
    connect(S, addr)        sendmsg(S, [V]); close(V)       __unix_gc()
    ----------------        -------------------------       -----------
    
    NS = unix_create1()
    skb1 = sock_wmalloc(NS)
    L = unix_find_other(addr)
    unix_state_lock(L)
    unix_peer(S) = NS
                            // V count=1 inflight=0
    
                            NS = unix_peer(S)
                            skb2 = sock_alloc()
                            skb_queue_tail(NS, skb2[V])
    
                            // V became in-flight
                            // V count=2 inflight=1
    
                            close(V)
    
                            // V count=1 inflight=1
                            // GC candidate condition met
    
                                                    for u in gc_inflight_list:
                                                      if (total_refs == inflight_refs)
                                                        add u to gc_candidates
    
                                                    // gc_candidates={L, V}
    
                                                    for u in gc_candidates:
                                                      scan_children(u, dec_inflight)
    
                                                    // embryo (skb1) was not
                                                    // reachable from L yet, so V's
                                                    // inflight remains unchanged
    __skb_queue_tail(L, skb1)
    unix_state_unlock(L)
                                                    for u in gc_candidates:
                                                      if (u.inflight)
                                                        scan_children(u, inc_inflight_move_tail)
    
                                                    // V count=1 inflight=2 (!)
    
    If there is a GC-candidate listening socket, lock/unlock its state. This
    makes GC wait until the end of any ongoing connect() to that socket. After
    flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
    there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
    this point, unix_inflight() can not happen because unix_gc_lock is already
    taken. Inflight graph remains unaffected.
    
    Fixes: 1fd05ba5a2f2 ("[AF_UNIX]: Rewrite garbage collector, fixes race.")
    Signed-off-by: Michal Luczaj <mhal@rbox.co>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20240409201047.1032217-1-mhal@rbox.co
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: dts: imx8-ss-conn: fix usb lpcg indices [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon Apr 1 18:25:04 2024 -0400

    arm64: dts: imx8-ss-conn: fix usb lpcg indices
    
    commit 808e7716edcdb39d3498b9f567ef6017858b49aa upstream.
    
    usb2_lpcg: clock-controller@5b270000 {
            ...                                                    Col1  Col2
            clocks = <&conn_ahb_clk>, <&conn_ipg_clk>;           // 0     6
            clock-indices = <IMX_LPCG_CLK_6>, <IMX_LPCG_CLK_7>;  // 0     7
            ...
    };
    
    Col1: index, which existing dts try to get.
    Col2: actual index in lpcg driver.
    
    usbotg1: usb@5b0d0000 {
            ...
            clocks = <&usb2_lpcg 0>;
                                 ^^
    Should be:
            clocks = <&usb2_lpcg IMX_LPCG_CLK_6>;
    };
    
    usbphy1: usbphy@5b100000 {
            clocks = <&usb2_lpcg 1>;
                                 ^^
    SHould be:
            clocks = <&usb2_lpcg IMX_LPCG_CLK_7>;
    };
    
    Arg0 is divided by 4 in lpcg driver. So lpcg will do dummy enable. Fix it
    by use correct clock indices.
    
    Cc: stable@vger.kernel.org
    Fixes: 8065fc937f0f ("arm64: dts: imx8dxl: add usb1 and usb2 support")
    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: imx8-ss-conn: fix usdhc wrong lpcg clock order [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Fri Mar 22 12:47:05 2024 -0400

    arm64: dts: imx8-ss-conn: fix usdhc wrong lpcg clock order
    
    [ Upstream commit c6ddd6e7b166532a0816825442ff60f70aed9647 ]
    
    The actual clock show wrong frequency:
    
       echo on >/sys/devices/platform/bus\@5b000000/5b010000.mmc/power/control
       cat /sys/kernel/debug/mmc0/ios
    
       clock:          200000000 Hz
       actual clock:   166000000 Hz
                       ^^^^^^^^^
       .....
    
    According to
    
    sdhc0_lpcg: clock-controller@5b200000 {
                    compatible = "fsl,imx8qxp-lpcg";
                    reg = <0x5b200000 0x10000>;
                    #clock-cells = <1>;
                    clocks = <&clk IMX_SC_R_SDHC_0 IMX_SC_PM_CLK_PER>,
                             <&conn_ipg_clk>, <&conn_axi_clk>;
                    clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>,
                                    <IMX_LPCG_CLK_5>;
                    clock-output-names = "sdhc0_lpcg_per_clk",
                                         "sdhc0_lpcg_ipg_clk",
                                         "sdhc0_lpcg_ahb_clk";
                    power-domains = <&pd IMX_SC_R_SDHC_0>;
            }
    
    "per_clk" should be IMX_LPCG_CLK_0 instead of IMX_LPCG_CLK_5.
    
    After correct clocks order:
    
       echo on >/sys/devices/platform/bus\@5b000000/5b010000.mmc/power/control
       cat /sys/kernel/debug/mmc0/ios
    
       clock:          200000000 Hz
       actual clock:   198000000 Hz
                       ^^^^^^^^
       ...
    
    Fixes: 16c4ea7501b1 ("arm64: dts: imx8: switch to new lpcg clock binding")
    Signed-off-by: Frank Li <Frank.Li@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8-ss-dma: fix adc lpcg indices [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon Apr 1 18:25:07 2024 -0400

    arm64: dts: imx8-ss-dma: fix adc lpcg indices
    
    commit 81975080f14167610976e968e8016e92d836266f upstream.
    
    adc0_lpcg: clock-controller@5ac80000 {
            ...                                                 Col1   Col2
            clocks = <&clk IMX_SC_R_ADC_0 IMX_SC_PM_CLK_PER>, // 0      0
                     <&dma_ipg_clk>;                          // 1      4
            clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
    };
    
    Col1: index, which existing dts try to get.
    Col2: actual index in lpcg driver.
    
    adc0: adc@5a880000 {
            clocks = <&adc0_lpcg 0>, <&adc0_lpcg 1>;
                                 ^^              ^^
            clocks = <&adc0_lpcg IMX_LPCG_CLK_0>, <&adc0_lpcg IMX_LPCG_CLK_4>;
    
    Arg0 is divided by 4 in lpcg driver. So adc get IMX_SC_PM_CLK_PER by
    <&adc0_lpcg 0>, <&adc0_lpcg 1>. Although function can work, code logic is
    wrong. Fix it by using correct indices.
    
    Cc: stable@vger.kernel.org
    Fixes: 1db044b25d2e ("arm64: dts: imx8dxl: add adc0 support")
    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: imx8-ss-dma: fix can lpcg indices [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon Apr 1 18:25:08 2024 -0400

    arm64: dts: imx8-ss-dma: fix can lpcg indices
    
    commit 0893392334b5dffdf616a53679c6a2942c46391b upstream.
    
    can0_lpcg: clock-controller@5acd0000 {
            ...                                                Col1  Col2
            clocks = <&clk IMX_SC_R_CAN_0 IMX_SC_PM_CLK_PER>, // 0    0
                     <&dma_ipg_clk>,                          // 1    4
                     <&dma_ipg_clk>;                          // 2    5
            clock-indices = <IMX_LPCG_CLK_0>,
                            <IMX_LPCG_CLK_4>,
                            <IMX_LPCG_CLK_5>;
    }
    
    Col1: index, which existing dts try to get.
    Col2: actual index in lpcg driver.
    
    flexcan1: can@5a8d0000 {
            clocks = <&can0_lpcg 1>, <&can0_lpcg 0>;
                                 ^^              ^^
    Should be:
            clocks = <&can0_lpcg IMX_LPCG_CLK_4>, <&can0_lpcg IMX_LPCG_CLK_0>;
    };
    
    Arg0 is divided by 4 in lpcg driver. flexcan driver get IMX_SC_PM_CLK_PER
    by <&can0_lpcg 1> and <&can0_lpcg 0>. Although function can work, code
    logic is wrong. Fix it by using correct clock indices.
    
    Cc: stable@vger.kernel.org
    Fixes: 5e7d5b023e03 ("arm64: dts: imx8qxp: add flexcan in adma")
    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: imx8-ss-dma: fix spi lpcg indices [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon Apr 1 18:25:05 2024 -0400

    arm64: dts: imx8-ss-dma: fix spi lpcg indices
    
    commit f72b544a514c07d34a0d9d5380f5905b3731e647 upstream.
    
    spi0_lpcg: clock-controller@5a400000 {
            ...                                                  Col0   Col1
            clocks = <&clk IMX_SC_R_SPI_0 IMX_SC_PM_CLK_PER>,//   0      1
                     <&dma_ipg_clk>;                         //   1      4
            clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
    };
    
    Col1: index, which existing dts try to get.
    Col2: actual index in lpcg driver.
    
    lpspi0: spi@5a000000 {
            ...
            clocks = <&spi0_lpcg 0>, <&spi0_lpcg 1>;
                                 ^               ^
    Should be:
            clocks = <&spi0_lpcg IMX_LPCG_CLK_0>, <&spi0_lpcg IMX_LPCG_CLK_4>;
    };
    
    Arg0 is divided by 4 in lpcg driver. <&spi0_lpcg 0> and <&spi0_lpcg 1> are
    IMX_SC_PM_CLK_PER. Although code can work, code logic is wrong. It should
    use IMX_LPCG_CLK_0 and IMX_LPCG_CLK_4 for lpcg arg0.
    
    Cc: stable@vger.kernel.org
    Fixes: c4098885e790 ("arm64: dts: imx8dxl: add lpspi support")
    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: imx8-ss-lsio: fix pwm lpcg indices [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon Apr 1 18:25:03 2024 -0400

    arm64: dts: imx8-ss-lsio: fix pwm lpcg indices
    
    commit 1d86c2b3946e69d6b0b93568d312aae6247847c0 upstream.
    
    lpcg's arg0 should use clock indices instead of index.
    
    pwm0_lpcg: clock-controller@5d400000 {
            ...                                                // Col1  Col2
            clocks = <&clk IMX_SC_R_PWM_0 IMX_SC_PM_CLK_PER>,  // 0     0
                     <&clk IMX_SC_R_PWM_0 IMX_SC_PM_CLK_PER>,  // 1     1
                     <&clk IMX_SC_R_PWM_0 IMX_SC_PM_CLK_PER>,  // 2     4
                     <&lsio_bus_clk>,                          // 3     5
                     <&clk IMX_SC_R_PWM_0 IMX_SC_PM_CLK_PER>;  // 4     6
            clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_1>,
                            <IMX_LPCG_CLK_4>, <IMX_LPCG_CLK_5>,
                            <IMX_LPCG_CLK_6>;
    };
    
    Col1: index, which existing dts try to get.
    Col2: actual index in lpcg driver.
    
    pwm1 {
            ....
            clocks = <&pwm1_lpcg 4>, <&pwm1_lpcg 1>;
                                 ^^              ^^
    should be:
    
            clocks = <&pwm1_lpcg IMX_LPCG_CLK_6>, <&pwm1_lpcg IMX_LPCG_CLK_1>;
    };
    
    Arg0 is divided by 4 in lpcg driver, so index 0 and 1 will be get by pwm
    driver, which are same as IMX_LPCG_CLK_6 and IMX_LPCG_CLK_1. Even it can
    work, but code logic is wrong. Fixed it by use correct indices.
    
    Cc: stable@vger.kernel.org
    Fixes: 23fa99b205ea ("arm64: dts: freescale: imx8-ss-lsio: add support for lsio_pwm0-3")
    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: imx8qm-ss-dma: fix can lpcg indices [+ + +]
Author: Frank Li <Frank.Li@nxp.com>
Date:   Mon Apr 1 18:25:09 2024 -0400

    arm64: dts: imx8qm-ss-dma: fix can lpcg indices
    
    commit 00b436182138310bb8d362b912b12a9df8f72ca3 upstream.
    
    can1_lpcg: clock-controller@5ace0000 {
            ...                                                 Col1   Col2
            clocks = <&clk IMX_SC_R_CAN_1 IMX_SC_PM_CLK_PER>,//  0       0
                     <&dma_ipg_clk>,                         //  1       4
                     <&dma_ipg_clk>;                         //  2       5
            clock-indices = <IMX_LPCG_CLK_0>,
                            <IMX_LPCG_CLK_4>,
                            <IMX_LPCG_CLK_5>;
    };
    
    Col1: index, which existing dts try to get.
    Col2: actual index in lpcg driver
    
    &flexcan2 {
            clocks = <&can1_lpcg 1>, <&can1_lpcg 0>;
                                 ^^              ^^
    Should be:
            clocks = <&can1_lpcg IMX_LPCG_CLK_4>, <&can1_lpcg IMX_LPCG_CLK_0>;
    };
    
    Arg0 is divided by 4 in lpcg driver. So flexcan get IMX_SC_PM_CLK_PER by
    <&can1_lpcg 1> and <&can1_lpcg 0>. Although function work, code logic is
    wrong. Fix it by using correct clock indices.
    
    Cc: stable@vger.kernel.org
    Fixes: be85831de020 ("arm64: dts: imx8qm: add can node in devicetree")
    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>

 
ARM: dts: imx7s-warp: Pass OV2680 link-frequencies [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Thu Mar 28 12:19:54 2024 -0300

    ARM: dts: imx7s-warp: Pass OV2680 link-frequencies
    
    commit 135f218255b28c5bbf71e9e32a49e5c734cabbe5 upstream.
    
    Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint
    property verification") the ov2680 no longer probes on a imx7s-warp7:
    
    ov2680 1-0036: error -EINVAL: supported link freq 330000000 not found
    ov2680 1-0036: probe with driver ov2680 failed with error -22
    
    Fix it by passing the required 'link-frequencies' property as
    recommended by:
    
    https://www.kernel.org/doc/html/v6.9-rc1/driver-api/media/camera-sensor.html#handling-clocks
    
    Cc: stable@vger.kernel.org
    Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: OMAP2+: fix bogus MMC GPIO labels on Nokia N8x0 [+ + +]
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Fri Feb 23 20:14:35 2024 +0200

    ARM: OMAP2+: fix bogus MMC GPIO labels on Nokia N8x0
    
    [ Upstream commit 95f37eb52e18879a1b16e51b972d992b39e50a81 ]
    
    The GPIO bank width is 32 on OMAP2, so all labels are incorrect.
    
    Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Message-ID: <20240223181439.1099750-2-aaro.koskinen@iki.fi>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: OMAP2+: fix N810 MMC gpiod table [+ + +]
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Fri Feb 23 20:14:36 2024 +0200

    ARM: OMAP2+: fix N810 MMC gpiod table
    
    [ Upstream commit 480d44d0820dd5ae043dc97c0b46dabbe53cb1cf ]
    
    Trying to append a second table for the same dev_id doesn't seem to work.
    The second table is just silently ignored. As a result eMMC GPIOs are not
    present.
    
    Fix by using separate tables for N800 and N810.
    
    Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Message-ID: <20240223181439.1099750-3-aaro.koskinen@iki.fi>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: OMAP2+: fix USB regression on Nokia N8x0 [+ + +]
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Fri Feb 23 20:16:56 2024 +0200

    ARM: OMAP2+: fix USB regression on Nokia N8x0
    
    [ Upstream commit 4421405e3634a3189b541cf1e34598e44260720d ]
    
    GPIO chip labels are wrong for OMAP2, so the USB does not work. Fix.
    
    Fixes: 8e0285ab95a9 ("ARM/musb: omap2: Remove global GPIO numbers from TUSB6010")
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Message-ID: <20240223181656.1099845-1-aaro.koskinen@iki.fi>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: libata-core: Allow command duration limits detection for ACS-4 drives [+ + +]
Author: Igor Pylypiv <ipylypiv@google.com>
Date:   Thu Apr 11 20:12:24 2024 +0000

    ata: libata-core: Allow command duration limits detection for ACS-4 drives
    
    commit c0297e7dd50795d559f3534887a6de1756b35d0f upstream.
    
    Even though the command duration limits (CDL) feature was first added
    in ACS-5 (major version 12), there are some ACS-4 (major version 11)
    drives that implement CDL as well.
    
    IDENTIFY_DEVICE, SUPPORTED_CAPABILITIES, and CURRENT_SETTINGS log pages
    are mandatory in the ACS-4 standard so it should be safe to read these
    log pages on older drives implementing the ACS-4 standard.
    
    Fixes: 62e4a60e0cdb ("scsi: ata: libata: Detect support for command duration limits")
    Cc: stable@vger.kernel.org
    Signed-off-by: Igor Pylypiv <ipylypiv@google.com>
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ata: libata-scsi: Fix ata_scsi_dev_rescan() error path [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Fri Apr 12 08:41:15 2024 +0900

    ata: libata-scsi: Fix ata_scsi_dev_rescan() error path
    
    commit 79336504781e7fee5ddaf046dcc186c8dfdf60b1 upstream.
    
    Commit 0c76106cb975 ("scsi: sd: Fix TCG OPAL unlock on system resume")
    incorrectly handles failures of scsi_resume_device() in
    ata_scsi_dev_rescan(), leading to a double call to
    spin_unlock_irqrestore() to unlock a device port. Fix this by redefining
    the goto labels used in case of errors and only unlock the port
    scsi_scan_mutex when scsi_resume_device() fails.
    
    Bug found with the Smatch static checker warning:
    
            drivers/ata/libata-scsi.c:4774 ata_scsi_dev_rescan()
            error: double unlocked 'ap->lock' (orig line 4757)
    
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Fixes: 0c76106cb975 ("scsi: sd: Fix TCG OPAL unlock on system resume")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
batman-adv: Avoid infinite loop trying to resize local TT [+ + +]
Author: Sven Eckelmann <sven@narfation.org>
Date:   Mon Feb 12 13:58:33 2024 +0100

    batman-adv: Avoid infinite loop trying to resize local TT
    
    commit b1f532a3b1e6d2e5559c7ace49322922637a28aa upstream.
    
    If the MTU of one of an attached interface becomes too small to transmit
    the local translation table then it must be resized to fit inside all
    fragments (when enabled) or a single packet.
    
    But if the MTU becomes too low to transmit even the header + the VLAN
    specific part then the resizing of the local TT will never succeed. This
    can for example happen when the usable space is 110 bytes and 11 VLANs are
    on top of batman-adv. In this case, at least 116 byte would be needed.
    There will just be an endless spam of
    
       batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
    
    in the log but the function will never finish. Problem here is that the
    timeout will be halved all the time and will then stagnate at 0 and
    therefore never be able to reduce the table even more.
    
    There are other scenarios possible with a similar result. The number of
    BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too
    high to fit inside a packet. Such a scenario can therefore happen also with
    only a single VLAN + 7 non-purgable addresses - requiring at least 120
    bytes.
    
    While this should be handled proactively when:
    
    * interface with too low MTU is added
    * VLAN is added
    * non-purgeable local mac is added
    * MTU of an attached interface is reduced
    * fragmentation setting gets disabled (which most likely requires dropping
      attached interfaces)
    
    not all of these scenarios can be prevented because batman-adv is only
    consuming events without the the possibility to prevent these actions
    (non-purgable MAC address added, MTU of an attached interface is reduced).
    It is therefore necessary to also make sure that the code is able to handle
    also the situations when there were already incompatible system
    configuration are present.
    
    Cc: stable@vger.kernel.org
    Fixes: a19d3d85e1b8 ("batman-adv: limit local translation table max size")
    Reported-by: syzbot+a6a4b5bb3da165594cff@syzkaller.appspotmail.com
    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>

 
block: fix q->blkg_list corruption during disk rebind [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sun Apr 7 20:59:10 2024 +0800

    block: fix q->blkg_list corruption during disk rebind
    
    [ Upstream commit 8b8ace080319a866f5dfe9da8e665ae51d971c54 ]
    
    Multiple gendisk instances can allocated/added for single request queue
    in case of disk rebind. blkg may still stay in q->blkg_list when calling
    blkcg_init_disk() for rebind, then q->blkg_list becomes corrupted.
    
    Fix the list corruption issue by:
    
    - add blkg_init_queue() to initialize q->blkg_list & q->blkcg_mutex only
    - move calling blkg_init_queue() into blk_alloc_queue()
    
    The list corruption should be started since commit f1c006f1c685 ("blk-cgroup:
    synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()")
    which delays removing blkg from q->blkg_list into blkg_free_workfn().
    
    Fixes: f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()")
    Fixes: 1059699f87eb ("block: move blkcg initialization/destroy into disk allocation/release handler")
    Cc: Yu Kuai <yukuai3@huawei.com>
    Cc: Tejun Heo <tj@kernel.org>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20240407125910.4053377-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: Fix memory leak in hci_req_sync_complete() [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Tue Apr 2 14:32:05 2024 +0300

    Bluetooth: Fix memory leak in hci_req_sync_complete()
    
    commit 45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810 upstream.
    
    In 'hci_req_sync_complete()', always free the previous sync
    request state before assigning reference to a new one.
    
    Reported-by: syzbot+39ec16ff6cc18b1d066d@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=39ec16ff6cc18b1d066d
    Cc: stable@vger.kernel.org
    Fixes: f60cb30579d3 ("Bluetooth: Convert hci_req_sync family of function to new request API")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_sync: Fix using the same interval and window for Coded PHY [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Mar 28 15:58:10 2024 -0400

    Bluetooth: hci_sync: Fix using the same interval and window for Coded PHY
    
    [ Upstream commit 53cb4197e63ab2363aa28c3029061e4d516e7626 ]
    
    Coded PHY recommended intervals are 3 time bigger than the 1M PHY so
    this aligns with that by multiplying by 3 the values given to 1M PHY
    since the code already used recommended values for that.
    
    Fixes: 288c90224eec ("Bluetooth: Enable all supported LE PHY by default")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: Use QoS to determine which PHY to scan [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Feb 21 09:38:10 2024 -0500

    Bluetooth: hci_sync: Use QoS to determine which PHY to scan
    
    [ Upstream commit 22cbf4f84c00da64196eb15034feee868e63eef0 ]
    
    This used the hci_conn QoS to determine which PHY to scan when creating
    a PA Sync.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 53cb4197e63a ("Bluetooth: hci_sync: Fix using the same interval and window for Coded PHY")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: Align broadcast sync_timeout with connection timeout [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Thu Mar 7 11:58:17 2024 -0500

    Bluetooth: ISO: Align broadcast sync_timeout with connection timeout
    
    [ Upstream commit 42ed95de82c01184a88945d3ca274be6a7ea607d ]
    
    This aligns broadcast sync_timeout with existing connection timeouts
    which are 20 seconds long.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: b37cab587aa3 ("Bluetooth: ISO: Don't reject BT_ISO_QOS if parameters are unset")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: Don't reject BT_ISO_QOS if parameters are unset [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Mar 13 15:43:18 2024 -0400

    Bluetooth: ISO: Don't reject BT_ISO_QOS if parameters are unset
    
    [ Upstream commit b37cab587aa3c9ab29c6b10aa55627dad713011f ]
    
    Consider certain values (0x00) as unset and load proper default if
    an application has not set them properly.
    
    Fixes: 0fe8c8d07134 ("Bluetooth: Split bt_iso_qos into dedicated structures")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: l2cap: Don't double set the HCI_CONN_MGMT_CONNECTED bit [+ + +]
Author: Archie Pusaka <apusaka@chromium.org>
Date:   Thu Apr 4 18:50:23 2024 +0800

    Bluetooth: l2cap: Don't double set the HCI_CONN_MGMT_CONNECTED bit
    
    [ Upstream commit 600b0bbe73d3a9a264694da0e4c2c0800309141e ]
    
    The bit is set and tested inside mgmt_device_connected(), therefore we
    must not set it just outside the function.
    
    Fixes: eeda1bf97bb5 ("Bluetooth: hci_event: Fix not indicating new connection for BIG Sync")
    Signed-off-by: Archie Pusaka <apusaka@chromium.org>
    Reviewed-by: Manish Mandlik <mmandlik@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: SCO: Fix not validating setsockopt user input [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Apr 5 15:41:52 2024 -0400

    Bluetooth: SCO: Fix not validating setsockopt user input
    
    [ Upstream commit 51eda36d33e43201e7a4fd35232e069b2c850b01 ]
    
    syzbot reported sco_sock_setsockopt() is copying data without
    checking user input length.
    
    BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
    include/linux/sockptr.h:49 [inline]
    BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
    include/linux/sockptr.h:55 [inline]
    BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90
    net/bluetooth/sco.c:893
    Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578
    
    Fixes: ad10b1a48754 ("Bluetooth: Add Bluetooth socket voice option")
    Fixes: b96e9c671b05 ("Bluetooth: Add BT_DEFER_SETUP option to sco socket")
    Fixes: 00398e1d5183 ("Bluetooth: Add support for BT_PKT_STATUS CMSG data for SCO connections")
    Fixes: f6873401a608 ("Bluetooth: Allow setting of codec for HFP offload use case")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bnxt_en: Fix error recovery for RoCE ulp client [+ + +]
Author: Vikas Gupta <vikas.gupta@broadcom.com>
Date:   Fri Apr 5 16:55:12 2024 -0700

    bnxt_en: Fix error recovery for RoCE ulp client
    
    [ Upstream commit b5ea7d33ba2a42b95b4298d08d2af9cdeeaf0090 ]
    
    Since runtime MSIXs vector allocation/free has been removed,
    the L2 driver needs to repopulate the MSIX entries for the
    ulp client as the irq table may change during the recovery
    process.
    
    Fixes: 303432211324 ("bnxt_en: Remove runtime interrupt vector allocation")
    Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com>
    Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init() [+ + +]
Author: Vikas Gupta <vikas.gupta@broadcom.com>
Date:   Fri Apr 5 16:55:11 2024 -0700

    bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init()
    
    [ Upstream commit 7ac10c7d728d75bc9daaa8fade3c7a3273b9a9ff ]
    
    If ulp = kzalloc() fails, the allocated edev will leak because it is
    not properly assigned and the cleanup path will not be able to free it.
    Fix it by assigning it properly immediately after allocation.
    
    Fixes: 303432211324 ("bnxt_en: Remove runtime interrupt vector allocation")
    Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com>
    Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bnxt_en: Reset PTP tx_avail after possible firmware reset [+ + +]
Author: Pavan Chebbi <pavan.chebbi@broadcom.com>
Date:   Fri Apr 5 16:55:13 2024 -0700

    bnxt_en: Reset PTP tx_avail after possible firmware reset
    
    [ Upstream commit faa12ca245585379d612736a4b5e98e88481ea59 ]
    
    It is possible that during error recovery and firmware reset,
    there is a pending TX PTP packet waiting for the timestamp.
    We need to reset this condition so that after recovery, the
    tx_avail count for PTP is reset back to the initial value.
    Otherwise, we may not accept any PTP TX timestamps after
    recovery.
    
    Fixes: 118612d519d8 ("bnxt_en: Add PTP clock APIs, ioctls, and ethtool methods")
    Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
    Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: qgroup: convert PREALLOC to PERTRANS after record_root_in_trans [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Thu Mar 21 10:18:39 2024 -0700

    btrfs: qgroup: convert PREALLOC to PERTRANS after record_root_in_trans
    
    commit 211de93367304ab395357f8cb12568a4d1e20701 upstream.
    
    The transaction is only able to free PERTRANS reservations for a root
    once that root has been recorded with the TRANS tag on the roots radix
    tree. Therefore, until we are sure that this root will get tagged, it
    isn't safe to convert. Generally, this is not an issue as *some*
    transaction will likely tag the root before long and this reservation
    will get freed in that transaction, but technically it could stick
    around until unmount and result in a warning about leaked metadata
    reservation space.
    
    This path is most exercised by running the generic/269 fstest with
    CONFIG_BTRFS_DEBUG.
    
    Fixes: a6496849671a ("btrfs: fix start transaction qgroup rsv double free")
    CC: stable@vger.kernel.org # 6.6+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: qgroup: correctly model root qgroup rsv in convert [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Tue Mar 19 10:54:22 2024 -0700

    btrfs: qgroup: correctly model root qgroup rsv in convert
    
    commit 141fb8cd206ace23c02cd2791c6da52c1d77d42a upstream.
    
    We use add_root_meta_rsv and sub_root_meta_rsv to track prealloc and
    pertrans reservations for subvolumes when quotas are enabled. The
    convert function does not properly increment pertrans after decrementing
    prealloc, so the count is not accurate.
    
    Note: we check that the fs is not read-only to mirror the logic in
    qgroup_convert_meta, which checks that before adding to the pertrans rsv.
    
    Fixes: 8287475a2055 ("btrfs: qgroup: Use root::qgroup_meta_rsv_* to record qgroup meta reserved space")
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Thu Mar 21 10:02:04 2024 -0700

    btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations
    
    commit 74e97958121aa1f5854da6effba70143f051b0cd upstream.
    
    Create subvolume, create snapshot and delete subvolume all use
    btrfs_subvolume_reserve_metadata() to reserve metadata for the changes
    done to the parent subvolume's fs tree, which cannot be mediated in the
    normal way via start_transaction. When quota groups (squota or qgroups)
    are enabled, this reserves qgroup metadata of type PREALLOC. Once the
    operation is associated to a transaction, we convert PREALLOC to
    PERTRANS, which gets cleared in bulk at the end of the transaction.
    
    However, the error paths of these three operations were not implementing
    this lifecycle correctly. They unconditionally converted the PREALLOC to
    PERTRANS in a generic cleanup step regardless of errors or whether the
    operation was fully associated to a transaction or not. This resulted in
    error paths occasionally converting this rsv to PERTRANS without calling
    record_root_in_trans successfully, which meant that unless that root got
    recorded in the transaction by some other thread, the end of the
    transaction would not free that root's PERTRANS, leaking it. Ultimately,
    this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount
    for the leaked reservation.
    
    The fix is to ensure that every qgroup PREALLOC reservation observes the
    following properties:
    
    1. any failure before record_root_in_trans is called successfully
       results in freeing the PREALLOC reservation.
    2. after record_root_in_trans, we convert to PERTRANS, and now the
       transaction owns freeing the reservation.
    
    This patch enforces those properties on the three operations. Without
    it, generic/269 with squotas enabled at mkfs time would fail in ~5-10
    runs on my system. With this patch, it ran successfully 1000 times in a
    row.
    
    Fixes: e85fde5162bf ("btrfs: qgroup: fix qgroup meta rsv leak for subvolume operations")
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: record delayed inode root in transaction [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Thu Mar 21 10:14:24 2024 -0700

    btrfs: record delayed inode root in transaction
    
    commit 71537e35c324ea6fbd68377a4f26bb93a831ae35 upstream.
    
    When running delayed inode updates, we do not record the inode's root in
    the transaction, but we do allocate PREALLOC and thus converted PERTRANS
    space for it. To be sure we free that PERTRANS meta rsv, we must ensure
    that we record the root in the transaction.
    
    Fixes: 4f5427ccce5d ("btrfs: delayed-inode: Use new qgroup meta rsv for delayed inode and item")
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cxl/core/regs: Fix usage of map->reg_type in cxl_decode_regblock() before assigned [+ + +]
Author: Dave Jiang <dave.jiang@intel.com>
Date:   Tue Mar 19 11:15:08 2024 -0700

    cxl/core/regs: Fix usage of map->reg_type in cxl_decode_regblock() before assigned
    
    [ Upstream commit 5c88a9ccd4c431d58b532e4158b6999a8350062c ]
    
    In the error path, map->reg_type is being used for kernel warning
    before its value is setup. Found by code inspection. Exposure to
    user is wrong reg_type being emitted via kernel log. Use a local
    var for reg_type and retrieve value for usage.
    
    Fixes: 6c7f4f1e51c2 ("cxl/core/regs: Make cxl_map_{component, device}_regs() device generic")
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/core: Fix initialization of mbox_cmd.size_out in get event [+ + +]
Author: Kwangjin Ko <kwangjin.ko@sk.com>
Date:   Tue Apr 2 17:14:03 2024 +0900

    cxl/core: Fix initialization of mbox_cmd.size_out in get event
    
    [ Upstream commit f7c52345ccc96343c0a05bdea3121c8ac7b67d5f ]
    
    Since mbox_cmd.size_out is overwritten with the actual output size in
    the function below, it needs to be initialized every time.
    
    cxl_internal_send_cmd -> __cxl_pci_mbox_send_cmd
    
    Problem scenario:
    
    1) The size_out variable is initially set to the size of the mailbox.
    2) Read an event.
       - size_out is set to 160 bytes(header 32B + one event 128B).
       - Two event are created while reading.
    3) Read the new *two* events.
       - size_out is still set to 160 bytes.
       - Although the value of out_len is 288 bytes, only 160 bytes are
         copied from the mailbox register to the local variable.
       - record_count is set to 2.
       - Accessing records[1] will result in reading incorrect data.
    
    Fixes: 6ebe28f9ec72 ("cxl/mem: Read, trace, and clear events on driver load")
    Tested-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Kwangjin Ko <kwangjin.ko@sk.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl/mem: Fix for the index of Clear Event Record Handle [+ + +]
Author: Yuquan Wang <wangyuquan1236@phytium.com.cn>
Date:   Mon Mar 18 10:29:28 2024 +0800

    cxl/mem: Fix for the index of Clear Event Record Handle
    
    [ Upstream commit b7c59b038c656214f56432867056997c2e0fc268 ]
    
    The dev_dbg info for Clear Event Records mailbox command would report
    the handle of the next record to clear not the current one.
    
    This was because the index 'i' had incremented before printing the
    current handle value.
    
    Fixes: 6ebe28f9ec72 ("cxl/mem: Read, trace, and clear events on driver load")
    Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Fan Ni <fan.ni@samsung.com>
    Signed-off-by: Dave Jiang <dave.jiang@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: fix disable otg wa logic in DCN316 [+ + +]
Author: Fudongwang <fudong.wang@amd.com>
Date:   Tue Mar 26 16:03:16 2024 +0800

    drm/amd/display: fix disable otg wa logic in DCN316
    
    commit cf79814cb0bf5749b9f0db53ca231aa540c02768 upstream.
    
    [Why]
    Wrong logic cause screen corruption.
    
    [How]
    Port logic from DCN35/314.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Fudongwang <fudong.wang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Program VSC SDP colorimetry for all DP sinks >= 1.4 [+ + +]
Author: Harry Wentland <harry.wentland@amd.com>
Date:   Tue Mar 12 11:55:52 2024 -0400

    drm/amd/display: Program VSC SDP colorimetry for all DP sinks >= 1.4
    
    commit 9e61ef8d219877202d4ee51d0d2ad9072c99a262 upstream.
    
    In order for display colorimetry to work correctly on DP displays
    we need to send the VSC SDP packet. We should only do so for
    panels with DPCD revision greater or equal to 1.4 as older
    receivers might have problems with it.
    
    Cc: stable@vger.kernel.org
    Cc: Joshua Ashton <joshua@froggi.es>
    Cc: Xaver Hugl <xaver.hugl@gmail.com>
    Cc: Melissa Wen <mwen@igalia.com>
    Cc: Agustin Gutierrez <Agustin.Gutierrez@amd.com>
    Reviewed-by: Agustin Gutierrez <agustin.gutierrez@amd.com>
    Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amd/display: Set VSC SDP Colorimetry same way for MST and SST [+ + +]
Author: Harry Wentland <harry.wentland@amd.com>
Date:   Thu Mar 21 11:13:38 2024 -0400

    drm/amd/display: Set VSC SDP Colorimetry same way for MST and SST
    
    commit c3e2a5f2da904a18661335e8be2b961738574998 upstream.
    
    The previous check for the is_vsc_sdp_colorimetry_supported flag
    for MST sink signals did nothing. Simplify the code and use the
    same check for MST and SST.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Agustin Gutierrez <agustin.gutierrez@amd.com>
    Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11 [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Wed Mar 27 13:10:37 2024 +0800

    drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11
    
    commit 31729e8c21ecfd671458e02b6511eb68c2225113 upstream.
    
    While doing multiple S4 stress tests, GC/RLC/PMFW get into
    an invalid state resulting into hard hangs.
    
    Adding a GFX reset as workaround just before sending the
    MP1_UNLOAD message avoids this failure.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: Mario Limonciello <superm1@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: always force full reset for SOC21 [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Sat Mar 23 20:46:53 2024 -0400

    drm/amdgpu: always force full reset for SOC21
    
    commit 65ff8092e4802f96d87d3d7cde146961f5228265 upstream.
    
    There are cases where soft reset seems to succeed, but
    does not, so always use mode1/2 for now.
    
    Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@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 incorrect number of active RBs for gfx11 [+ + +]
Author: Tim Huang <Tim.Huang@amd.com>
Date:   Wed Apr 3 17:28:44 2024 +0800

    drm/amdgpu: fix incorrect number of active RBs for gfx11
    
    commit bbca7f414ae9a12ea231cdbafd79c607e3337ea8 upstream.
    
    The RB bitmap should be global active RB bitmap &
    active RB bitmap based on active SA.
    
    Signed-off-by: Tim Huang <Tim.Huang@amd.com>
    Reviewed-by: Yifan Zhang <yifan1.zhang@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: Reset dGPU if suspend got aborted [+ + +]
Author: Lijo Lazar <lijo.lazar@amd.com>
Date:   Wed Feb 14 17:55:54 2024 +0530

    drm/amdgpu: Reset dGPU if suspend got aborted
    
    commit 8b2be55f4d6c1099d7f629b0ed7535a5be788c83 upstream.
    
    For SOC21 ASICs, there is an issue in re-enabling PM features if a
    suspend got aborted. In such cases, reset the device during resume
    phase. This is a workaround till a proper solution is finalized.
    
    Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Yang Wang <kevinyang.wang@amd.com>
    Reviewed-by: Hawking Zhang <Hawking.Zhang@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/amdkfd: Reset GPU on queue preemption failure [+ + +]
Author: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Date:   Tue Mar 26 15:32:46 2024 -0400

    drm/amdkfd: Reset GPU on queue preemption failure
    
    commit 8bdfb4ea95ca738d33ef71376c21eba20130f2eb upstream.
    
    Currently, with F32 HWS GPU reset is only when unmap queue fails.
    
    However, if compute queue doesn't repond to preemption request in time
    unmap will return without any error. In this case, only preemption error
    is logged and Reset is not triggered. Call GPU reset in this case also.
    
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
    Reviewed-by: Mukul Joshi <mukul.joshi@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/ast: Fix soft lockup [+ + +]
Author: Jammy Huang <jammy_huang@aspeedtech.com>
Date:   Wed Apr 3 17:02:46 2024 +0800

    drm/ast: Fix soft lockup
    
    commit bc004f5038220b1891ef4107134ccae44be55109 upstream.
    
    There is a while-loop in ast_dp_set_on_off() that could lead to
    infinite-loop. This is because the register, VGACRI-Dx, checked in
    this API is a scratch register actually controlled by a MCU, named
    DPMCU, in BMC.
    
    These scratch registers are protected by scu-lock. If suc-lock is not
    off, DPMCU can not update these registers and then host will have soft
    lockup due to never updated status.
    
    DPMCU is used to control DP and relative registers to handshake with
    host's VGA driver. Even the most time-consuming task, DP's link
    training, is less than 100ms. 200ms should be enough.
    
    Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
    Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory Display-Port")
    Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: KuoHsiang Chou <kuohsiang_chou@aspeedtech.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: Dave Airlie <airlied@redhat.com>
    Cc: Jocelyn Falempe <jfalempe@redhat.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v5.19+
    Link: https://patchwork.freedesktop.org/patch/msgid/20240403090246.1495487-1-jammy_huang@aspeedtech.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/client: Fully protect modes[] with dev->mode_config.mutex [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Apr 4 23:33:25 2024 +0300

    drm/client: Fully protect modes[] with dev->mode_config.mutex
    
    commit 3eadd887dbac1df8f25f701e5d404d1b90fd0fea upstream.
    
    The modes[] array contains pointers to modes on the connectors'
    mode lists, which are protected by dev->mode_config.mutex.
    Thus we need to extend modes[] the same protection or by the
    time we use it the elements may already be pointing to
    freed/reused memory.
    
    Cc: stable@vger.kernel.org
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10583
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240404203336.10454-2-ville.syrjala@linux.intel.com
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/cdclk: Fix CDCLK programming order when pipes are active [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Apr 2 18:50:03 2024 +0300

    drm/i915/cdclk: Fix CDCLK programming order when pipes are active
    
    commit 7b1f6b5aaec0f849e19c3e99d4eea75876853cdd upstream.
    
    Currently we always reprogram CDCLK from the
    intel_set_cdclk_pre_plane_update() when using squash/crawl.
    The code only works correctly for the cd2x update or full
    modeset cases, and it was simply never updated to deal with
    squash/crawl.
    
    If the CDCLK frequency is increasing we must reprogram it
    before we do anything else that might depend on the new
    higher frequency, and conversely we must not decrease
    the frequency until everything that might still depend
    on the old higher frequency has been dealt with.
    
    Since cdclk_state->pipe is only relevant when doing a cd2x
    update we can't use it to determine the correct sequence
    during squash/crawl. To that end introduce cdclk_state->disable_pipes
    which simply indicates that we must perform the update
    while the pipes are disable (ie. during
    intel_set_cdclk_pre_plane_update()). Otherwise we use the
    same old vs. new CDCLK frequency comparsiong as for cd2x
    updates.
    
    The only remaining problem case is when the voltage_level
    needs to increase due to a DDI port, but the CDCLK frequency
    is decreasing (and not all pipes are being disabled). The
    current approach will not bump the voltage level up until
    after the port has already been enabled, which is too late.
    But we'll take care of that case separately.
    
    v2: Don't break the "must disable pipes case"
    v3: Keep the on stack 'pipe' for future use
    
    Cc: stable@vger.kernel.org
    Fixes: d62686ba3b54 ("drm/i915/adl_p: CDCLK crawl support for ADL")
    Reviewed-by: Uma Shankar <uma.shankar@intel.com>
    Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-2-ville.syrjala@linux.intel.com
    (cherry picked from commit 3aecee90ac12a351905f12dda7643d5b0676d6ca)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915/vrr: Disable VRR when using bigjoiner [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Apr 5 00:34:29 2024 +0300

    drm/i915/vrr: Disable VRR when using bigjoiner
    
    commit dcd8992e47f13afb5c11a61e8d9c141c35e23751 upstream.
    
    All joined pipes share the same transcoder/timing generator.
    Currently we just do the commits per-pipe, which doesn't really
    work if we need to change switch between non-VRR and VRR timings
    generators on the fly, or even when sending the push to the
    transcoder. For now just disable VRR when bigjoiner is needed.
    
    Cc: stable@vger.kernel.org
    Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
    Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-6-ville.syrjala@linux.intel.com
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    (cherry picked from commit f9d5e51db65652dbd8a2102fd7619440e3599fd2)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/i915: Disable port sync when bigjoiner is used [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Apr 5 00:34:27 2024 +0300

    drm/i915: Disable port sync when bigjoiner is used
    
    commit 0653d501409eeb9f1deb7e4c12e4d0d2c9f1cba1 upstream.
    
    The current modeset sequence can't handle port sync and bigjoiner
    at the same time. Refuse port sync when bigjoiner is needed,
    at least until we fix the modeset sequence.
    
    v2: Add a FIXME (Vandite)
    
    Cc: stable@vger.kernel.org
    Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
    Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-4-ville.syrjala@linux.intel.com
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    (cherry picked from commit b37e1347b991459c38c56ec2476087854a4f720b)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/msm/dpu: don't allow overriding data from catalog [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu Mar 14 03:10:41 2024 +0200

    drm/msm/dpu: don't allow overriding data from catalog
    
    [ Upstream commit 4f3b77ae5ff5b5ba9d99c5d5450db388dbee5107 ]
    
    The data from catalog is marked as const, so it is a part of the RO
    segment. Allowing userspace to write to it through debugfs can cause
    protection faults. Set debugfs file mode to read-only for debug entries
    corresponding to perf_cfg coming from catalog.
    
    Fixes: abda0d925f9c ("drm/msm/dpu: Mark various data tables as const")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/582844/
    Link: https://lore.kernel.org/r/20240314-dpu-perf-rework-v3-1-79fa4e065574@linaro.org
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() [+ + +]
Author: Boris Brezillon <boris.brezillon@collabora.com>
Date:   Fri Jan 5 21:46:11 2024 +0300

    drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
    
    commit 1fc9af813b25e146d3607669247d0f970f5a87c3 upstream.
    
    Subject: drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
    
    If some the pages or sgt allocation failed, we shouldn't release the
    pages ref we got earlier, otherwise we will end up with unbalanced
    get/put_pages() calls. We should instead leave everything in place
    and let the BO release function deal with extra cleanup when the object
    is destroyed, or let the fault handler try again next time it's called.
    
    Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Steven Price <steven.price@arm.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
    Co-developed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240105184624.508603-18-dmitry.osipenko@collabora.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/vmwgfx: Enable DMA mappings with SEV [+ + +]
Author: Zack Rusin <zack.rusin@broadcom.com>
Date:   Sun Apr 7 22:28:02 2024 -0400

    drm/vmwgfx: Enable DMA mappings with SEV
    
    commit 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd upstream.
    
    Enable DMA mappings in vmwgfx after TTM has been fixed in commit
    3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")
    
    This enables full guest-backed memory support and in particular allows
    usage of screen targets as the presentation mechanism.
    
    Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
    Reported-by: Ye Li <ye.li@broadcom.com>
    Tested-by: Ye Li <ye.li@broadcom.com>
    Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is active")
    Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
    Cc: dri-devel@lists.freedesktop.org
    Cc: <stable@vger.kernel.org> # v6.6+
    Reviewed-by: Martin Krastev <martin.krastev@broadcom.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240408022802.358641-1-zack.rusin@broadcom.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
firmware: arm_scmi: Make raw debugfs entries non-seekable [+ + +]
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Fri Mar 15 14:03:24 2024 +0000

    firmware: arm_scmi: Make raw debugfs entries non-seekable
    
    [ Upstream commit b70c7996d4ffb2e02895132e8a79a37cee66504f ]
    
    SCMI raw debugfs entries are used to inject and snoop messages out of the
    SCMI core and, as such, the underlying virtual files have no reason to
    support seeking.
    
    Modify the related file_operations descriptors to be non-seekable.
    
    Fixes: 3c3d818a9317 ("firmware: arm_scmi: Add core raw transmission support")
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Link: https://lore.kernel.org/r/20240315140324.231830-1-cristian.marussi@arm.com
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
geneve: fix header validation in geneve[6]_xmit_skb [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 5 10:30:34 2024 +0000

    geneve: fix header validation in geneve[6]_xmit_skb
    
    [ Upstream commit d8a6213d70accb403b82924a1c229e733433a5ef ]
    
    syzbot is able to trigger an uninit-value in geneve_xmit() [1]
    
    Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
    uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
    skb->protocol.
    
    If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol,
    pskb_inet_may_pull() does nothing at all.
    
    If a vlan tag was provided by the caller (af_packet in the syzbot case),
    the network header might not point to the correct location, and skb
    linear part could be smaller than expected.
    
    Add skb_vlan_inet_prepare() to perform a complete mac validation.
    
    Use this in geneve for the moment, I suspect we need to adopt this
    more broadly.
    
    v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
       - Only call __vlan_get_protocol() for vlan types.
    Link: https://lore.kernel.org/netdev/20240404100035.3270a7d5@kernel.org/
    
    v2,v3 - Addressed Sabrina comments on v1 and v2
    Link: https://lore.kernel.org/netdev/Zg1l9L2BNoZWZDZG@hog/
    
    [1]
    
    BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
     BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
      geneve_xmit_skb drivers/net/geneve.c:910 [inline]
      geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
      __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
      netdev_start_xmit include/linux/netdevice.h:4917 [inline]
      xmit_one net/core/dev.c:3531 [inline]
      dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
      __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
      dev_queue_xmit include/linux/netdevice.h:3091 [inline]
      packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
      packet_snd net/packet/af_packet.c:3081 [inline]
      packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:745
      __sys_sendto+0x685/0x830 net/socket.c:2191
      __do_sys_sendto net/socket.c:2203 [inline]
      __se_sys_sendto net/socket.c:2199 [inline]
      __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    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:1318 [inline]
      alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
      sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
      packet_alloc_skb net/packet/af_packet.c:2930 [inline]
      packet_snd net/packet/af_packet.c:3024 [inline]
      packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:745
      __sys_sendto+0x685/0x830 net/socket.c:2191
      __do_sys_sendto net/socket.c:2203 [inline]
      __se_sys_sendto net/socket.c:2199 [inline]
      __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
    
    Fixes: d13f048dd40e ("net: geneve: modify IP header check in geneve6_xmit_skb and geneve_xmit_skb")
    Reported-by: syzbot+9ee20ec1de7b3168db09@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/000000000000d19c3a06152f9ee4@google.com/
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Phillip Potter <phil@philpotter.co.uk>
    Cc: Sabrina Dubroca <sd@queasysnail.net>
    Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
    Reviewed-by: Phillip Potter <phil@philpotter.co.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring/net: restore msg_control on sendzc retry [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Mon Apr 8 18:11:09 2024 +0100

    io_uring/net: restore msg_control on sendzc retry
    
    commit 4fe82aedeb8a8cb09bfa60f55ab57b5c10a74ac4 upstream.
    
    cac9e4418f4cb ("io_uring/net: save msghdr->msg_control for retries")
    reinstatiates msg_control before every __sys_sendmsg_sock(), since the
    function can overwrite the value in msghdr. We need to do same for
    zerocopy sendmsg.
    
    Cc: stable@vger.kernel.org
    Fixes: 493108d95f146 ("io_uring/net: zerocopy sendmsg")
    Link: https://github.com/axboe/liburing/issues/1067
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/cc1d5d9df0576fa66ddad4420d240a98a020b267.1712596179.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iommu/vt-d: Allocate local memory for page request queue [+ + +]
Author: Jacob Pan <jacob.jun.pan@linux.intel.com>
Date:   Thu Apr 11 11:07:43 2024 +0800

    iommu/vt-d: Allocate local memory for page request queue
    
    [ Upstream commit a34f3e20ddff02c4f12df2c0635367394e64c63d ]
    
    The page request queue is per IOMMU, its allocation should be made
    NUMA-aware for performance reasons.
    
    Fixes: a222a7f0bb6c ("iommu/vt-d: Implement page request handling")
    Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Link: https://lore.kernel.org/r/20240403214007.985600-1-jacob.jun.pan@linux.intel.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/vt-d: Fix wrong use of pasid config [+ + +]
Author: Xuchun Shang <xuchun.shang@linux.alibaba.com>
Date:   Thu Apr 11 11:07:42 2024 +0800

    iommu/vt-d: Fix wrong use of pasid config
    
    [ Upstream commit 5b3625a4f6422e8982f90f0c11b5546149c962b8 ]
    
    The commit "iommu/vt-d: Add IOMMU perfmon support" introduce IOMMU
    PMU feature, but use the wrong config when set pasid filter.
    
    Fixes: 7232ab8b89e9 ("iommu/vt-d: Add IOMMU perfmon support")
    Signed-off-by: Xuchun Shang <xuchun.shang@linux.alibaba.com>
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Link: https://lore.kernel.org/r/20240401060753.3321318-1-xuchun.shang@linux.alibaba.com
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv4/route: avoid unused-but-set-variable warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Apr 8 09:42:03 2024 +0200

    ipv4/route: avoid unused-but-set-variable warning
    
    [ Upstream commit cf1b7201df59fb936f40f4a807433fe3f2ce310a ]
    
    The log_martians variable is only used in an #ifdef, causing a 'make W=1'
    warning with gcc:
    
    net/ipv4/route.c: In function 'ip_rt_send_redirect':
    net/ipv4/route.c:880:13: error: variable 'log_martians' set but not used [-Werror=unused-but-set-variable]
    
    Change the #ifdef to an equivalent IS_ENABLED() to let the compiler
    see where the variable is used.
    
    Fixes: 30038fc61adf ("net: ip_rt_send_redirect() optimization")
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240408074219.3030256-2-arnd@kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: fib: hide unused 'pn' variable [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Apr 8 09:42:02 2024 +0200

    ipv6: fib: hide unused 'pn' variable
    
    [ Upstream commit 74043489fcb5e5ca4074133582b5b8011b67f9e7 ]
    
    When CONFIG_IPV6_SUBTREES is disabled, the only user is hidden, causing
    a 'make W=1' warning:
    
    net/ipv6/ip6_fib.c: In function 'fib6_add':
    net/ipv6/ip6_fib.c:1388:32: error: variable 'pn' set but not used [-Werror=unused-but-set-variable]
    
    Add another #ifdef around the variable declaration, matching the other
    uses in this file.
    
    Fixes: 66729e18df08 ("[IPV6] ROUTE: Make sure we have fn->leaf when adding a node on subtree.")
    Link: https://lore.kernel.org/netdev/20240322131746.904943-1-arnd@kernel.org/
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240408074219.3030256-1-arnd@kernel.org
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr [+ + +]
Author: Jiri Benc <jbenc@redhat.com>
Date:   Mon Apr 8 16:18:21 2024 +0200

    ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
    
    [ Upstream commit 7633c4da919ad51164acbf1aa322cc1a3ead6129 ]
    
    Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
    still means hlist_for_each_entry_rcu can return an item that got removed
    from the list. The memory itself of such item is not freed thanks to RCU
    but nothing guarantees the actual content of the memory is sane.
    
    In particular, the reference count can be zero. This can happen if
    ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
    from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all
    references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
    timing, this can happen:
    
    1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.
    
    2. Then, the whole ipv6_del_addr is executed for the given entry. The
       reference count drops to zero and kfree_rcu is scheduled.
    
    3. ipv6_get_ifaddr continues and tries to increments the reference count
       (in6_ifa_hold).
    
    4. The rcu is unlocked and the entry is freed.
    
    5. The freed entry is returned.
    
    Prevent increasing of the reference count in such case. The name
    in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.
    
    [   41.506330] refcount_t: addition on 0; use-after-free.
    [   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
    [   41.507413] Modules linked in: veth bridge stp llc
    [   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
    [   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
    [   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
    [   41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff
    [   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
    [   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
    [   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
    [   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
    [   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
    [   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
    [   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
    [   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
    [   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   41.516799] Call Trace:
    [   41.517037]  <TASK>
    [   41.517249]  ? __warn+0x7b/0x120
    [   41.517535]  ? refcount_warn_saturate+0xa5/0x130
    [   41.517923]  ? report_bug+0x164/0x190
    [   41.518240]  ? handle_bug+0x3d/0x70
    [   41.518541]  ? exc_invalid_op+0x17/0x70
    [   41.520972]  ? asm_exc_invalid_op+0x1a/0x20
    [   41.521325]  ? refcount_warn_saturate+0xa5/0x130
    [   41.521708]  ipv6_get_ifaddr+0xda/0xe0
    [   41.522035]  inet6_rtm_getaddr+0x342/0x3f0
    [   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10
    [   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0
    [   41.523102]  ? netlink_unicast+0x30f/0x390
    [   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
    [   41.523832]  netlink_rcv_skb+0x53/0x100
    [   41.524157]  netlink_unicast+0x23b/0x390
    [   41.524484]  netlink_sendmsg+0x1f2/0x440
    [   41.524826]  __sys_sendto+0x1d8/0x1f0
    [   41.525145]  __x64_sys_sendto+0x1f/0x30
    [   41.525467]  do_syscall_64+0xa5/0x1b0
    [   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a
    [   41.526213] RIP: 0033:0x7fbc4cfcea9a
    [   41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
    [   41.527942] RSP: 002b:00007ffcf54012a8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    [   41.528593] RAX: ffffffffffffffda RBX: 00007ffcf5401368 RCX: 00007fbc4cfcea9a
    [   41.529173] RDX: 000000000000002c RSI: 00007fbc4b9d9bd0 RDI: 0000000000000005
    [   41.529786] RBP: 00007fbc4bafb040 R08: 00007ffcf54013e0 R09: 000000000000000c
    [   41.530375] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    [   41.530977] R13: ffffffffc4653600 R14: 0000000000000001 R15: 00007fbc4ca85d1b
    [   41.531573]  </TASK>
    
    Fixes: 5c578aedcb21d ("IPv6: convert addrconf hash list to RCU")
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: Jiri Benc <jbenc@redhat.com>
    Link: https://lore.kernel.org/r/8ab821e36073a4a406c50ec83c9e8dc586c539e4.1712585809.git.jbenc@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqflags: Explicitly ignore lockdep_hrtimer_exit() argument [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Apr 8 09:46:01 2024 +0200

    irqflags: Explicitly ignore lockdep_hrtimer_exit() argument
    
    commit c1d11fc2c8320871b40730991071dd0a0b405bc8 upstream.
    
    When building with 'make W=1' but CONFIG_TRACE_IRQFLAGS=n, the
    unused argument to lockdep_hrtimer_exit() causes a warning:
    
    kernel/time/hrtimer.c:1655:14: error: variable 'expires_in_hardirq' set but not used [-Werror=unused-but-set-variable]
    
    This is intentional behavior, so add a cast to void to shut up the warning.
    
    Fixes: 73d20564e0dc ("hrtimer: Don't dereference the hrtimer pointer after the callback")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240408074609.3170807-1-arnd@kernel.org
    Closes: https://lore.kernel.org/oe-kbuild-all/202311191229.55QXHVc6-lkp@intel.com/
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kprobes: Fix possible use-after-free issue on kprobe registration [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Wed Apr 10 09:58:02 2024 +0800

    kprobes: Fix possible use-after-free issue on kprobe registration
    
    commit 325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8 upstream.
    
    When unloading a module, its state is changing MODULE_STATE_LIVE ->
     MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take
    a time. `is_module_text_address()` and `__module_text_address()`
    works with MODULE_STATE_LIVE and MODULE_STATE_GOING.
    If we use `is_module_text_address()` and `__module_text_address()`
    separately, there is a chance that the first one is succeeded but the
    next one is failed because module->state becomes MODULE_STATE_UNFORMED
    between those operations.
    
    In `check_kprobe_address_safe()`, if the second `__module_text_address()`
    is failed, that is ignored because it expected a kernel_text address.
    But it may have failed simply because module->state has been changed
    to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify
    non-exist module text address (use-after-free).
    
    To fix this problem, we should not use separated `is_module_text_address()`
    and `__module_text_address()`, but use only `__module_text_address()`
    once and do `try_module_get(module)` which is only available with
    MODULE_STATE_LIVE.
    
    Link: https://lore.kernel.org/all/20240410015802.265220-1-zhengyejian1@huawei.com/
    
    Fixes: 28f6c37a2910 ("kprobes: Forbid probing on trampoline and BPF code areas")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.6.28 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 17 11:19:38 2024 +0200

    Linux 6.6.28
    
    Link: https://lore.kernel.org/r/20240415141953.365222063@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: cec: core: remove length check of Timer Status [+ + +]
Author: Nini Song <nini.song@mediatek.com>
Date:   Thu Jan 25 21:28:45 2024 +0800

    media: cec: core: remove length check of Timer Status
    
    commit ce5d241c3ad4568c12842168288993234345c0eb upstream.
    
    The valid_la is used to check the length requirements,
    including special cases of Timer Status. If the length is
    shorter than 5, that means no Duration Available is returned,
    the message will be forced to be invalid.
    
    However, the description of Duration Available in the spec
    is that this parameter may be returned when these cases, or
    that it can be optionally return when these cases. The key
    words in the spec description are flexible choices.
    
    Remove the special length check of Timer Status to fit the
    spec which is not compulsory about that.
    
    Signed-off-by: Nini Song <nini.song@mediatek.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: omap: fix broken slot switch lookup [+ + +]
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Fri Feb 23 20:14:37 2024 +0200

    mmc: omap: fix broken slot switch lookup
    
    [ Upstream commit d4debbcbffa45c3de5df0040af2eea74a9e794a3 ]
    
    The lookup is done before host->dev is initialized. It will always just
    fail silently, and the MMC behaviour is totally unpredictable as the switch
    is left in an undefined state. Fix that.
    
    Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Message-ID: <20240223181439.1099750-4-aaro.koskinen@iki.fi>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: omap: fix deferred probe [+ + +]
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Fri Feb 23 20:14:38 2024 +0200

    mmc: omap: fix deferred probe
    
    [ Upstream commit f6862c7f156d04f81c38467e1c304b7e9517e810 ]
    
    After a deferred probe, GPIO descriptor lookup will fail with EBUSY. Fix by
    using managed descriptors.
    
    Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Message-ID: <20240223181439.1099750-5-aaro.koskinen@iki.fi>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: omap: restore original power up/down steps [+ + +]
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date:   Fri Feb 23 20:14:39 2024 +0200

    mmc: omap: restore original power up/down steps
    
    [ Upstream commit 894ad61b85d6ba8efd4274aa8719d9ff1c89ea54 ]
    
    Commit e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
    moved Nokia N810 MMC power up/down from the board file into the MMC driver.
    
    The change removed some delays, and ordering without a valid reason.
    Restore power up/down to match the original code. This matters only on N810
    where the 2nd GPIO is in use. Other boards will see an additional delay but
    that should be a lesser concern than omitting delays altogether.
    
    Fixes: e519f0bb64ef ("ARM/mmc: Convert old mmci-omap to GPIO descriptors")
    Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Message-ID: <20240223181439.1099750-6-aaro.koskinen@iki.fi>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5: Correctly compare pkt reformat ids [+ + +]
Author: Cosmin Ratiu <cratiu@nvidia.com>
Date:   Tue Apr 9 22:08:13 2024 +0300

    net/mlx5: Correctly compare pkt reformat ids
    
    [ Upstream commit 9eca93f4d5ab03905516a68683674d9c50ff95bd ]
    
    struct mlx5_pkt_reformat contains a naked union of a u32 id and a
    dr_action pointer which is used when the action is SW-managed (when
    pkt_reformat.owner is set to MLX5_FLOW_RESOURCE_OWNER_SW). Using id
    directly in that case is incorrect, as it maps to the least significant
    32 bits of the 64-bit pointer in mlx5_fs_dr_action and not to the pkt
    reformat id allocated in firmware.
    
    For the purpose of comparing whether two rules are identical,
    interpreting the least significant 32 bits of the mlx5_fs_dr_action
    pointer as an id mostly works... until it breaks horribly and produces
    the outcome described in [1].
    
    This patch fixes mlx5_flow_dests_cmp to correctly compare ids using
    mlx5_fs_dr_action_get_pkt_reformat_id for the SW-managed rules.
    
    Link: https://lore.kernel.org/netdev/ea5264d6-6b55-4449-a602-214c6f509c1e@163.com/T/#u [1]
    
    Fixes: 6a48faeeca10 ("net/mlx5: Add direct rule fs_cmd implementation")
    Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
    Reviewed-by: Mark Bloch <mbloch@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240409190820.227554-6-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: offset comp irq index in name by one [+ + +]
Author: Michael Liang <mliang@purestorage.com>
Date:   Tue Apr 9 22:08:11 2024 +0300

    net/mlx5: offset comp irq index in name by one
    
    [ Upstream commit 9f7e8fbb91f8fa29548e2f6ab50c03b628c67ede ]
    
    The mlx5 comp irq name scheme is changed a little bit between
    commit 3663ad34bc70 ("net/mlx5: Shift control IRQ to the last index")
    and commit 3354822cde5a ("net/mlx5: Use dynamic msix vectors allocation").
    The index in the comp irq name used to start from 0 but now it starts
    from 1. There is nothing critical here, but it's harmless to change
    back to the old behavior, a.k.a starting from 0.
    
    Fixes: 3354822cde5a ("net/mlx5: Use dynamic msix vectors allocation")
    Reviewed-by: Mohamed Khalfella <mkhalfella@purestorage.com>
    Reviewed-by: Yuanyuan Zhong <yzhong@purestorage.com>
    Signed-off-by: Michael Liang <mliang@purestorage.com>
    Reviewed-by: Shay Drory <shayd@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240409190820.227554-4-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Properly link new fs rules into the tree [+ + +]
Author: Cosmin Ratiu <cratiu@nvidia.com>
Date:   Tue Apr 9 22:08:12 2024 +0300

    net/mlx5: Properly link new fs rules into the tree
    
    [ Upstream commit 7c6782ad4911cbee874e85630226ed389ff2e453 ]
    
    Previously, add_rule_fg would only add newly created rules from the
    handle into the tree when they had a refcount of 1. On the other hand,
    create_flow_handle tries hard to find and reference already existing
    identical rules instead of creating new ones.
    
    These two behaviors can result in a situation where create_flow_handle
    1) creates a new rule and references it, then
    2) in a subsequent step during the same handle creation references it
       again,
    resulting in a rule with a refcount of 2 that is not linked into the
    tree, will have a NULL parent and root and will result in a crash when
    the flow group is deleted because del_sw_hw_rule, invoked on rule
    deletion, assumes node->parent is != NULL.
    
    This happened in the wild, due to another bug related to incorrect
    handling of duplicate pkt_reformat ids, which lead to the code in
    create_flow_handle incorrectly referencing a just-added rule in the same
    flow handle, resulting in the problem described above. Full details are
    at [1].
    
    This patch changes add_rule_fg to add new rules without parents into
    the tree, properly initializing them and avoiding the crash. This makes
    it more consistent with how rules are added to an FTE in
    create_flow_handle.
    
    Fixes: 74491de93712 ("net/mlx5: Add multi dest support")
    Link: https://lore.kernel.org/netdev/ea5264d6-6b55-4449-a602-214c6f509c1e@163.com/T/#u [1]
    Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Mark Bloch <mbloch@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240409190820.227554-5-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Register devlink first under devlink lock [+ + +]
Author: Shay Drory <shayd@nvidia.com>
Date:   Tue Apr 9 22:08:10 2024 +0300

    net/mlx5: Register devlink first under devlink lock
    
    [ Upstream commit c6e77aa9dd82bc18a89bf49418f8f7e961cfccc8 ]
    
    In case device is having a non fatal FW error during probe, the
    driver will report the error to user via devlink. This will trigger
    a WARN_ON, since mlx5 is calling devlink_register() last.
    In order to avoid the WARN_ON[1], change mlx5 to invoke devl_register()
    first under devlink lock.
    
    [1]
    WARNING: CPU: 5 PID: 227 at net/devlink/health.c:483 devlink_recover_notify.constprop.0+0xb8/0xc0
    CPU: 5 PID: 227 Comm: kworker/u16:3 Not tainted 6.4.0-rc5_for_upstream_min_debug_2023_06_12_12_38 #1
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    Workqueue: mlx5_health0000:08:00.0 mlx5_fw_reporter_err_work [mlx5_core]
    RIP: 0010:devlink_recover_notify.constprop.0+0xb8/0xc0
    Call Trace:
     <TASK>
     ? __warn+0x79/0x120
     ? devlink_recover_notify.constprop.0+0xb8/0xc0
     ? report_bug+0x17c/0x190
     ? handle_bug+0x3c/0x60
     ? exc_invalid_op+0x14/0x70
     ? asm_exc_invalid_op+0x16/0x20
     ? devlink_recover_notify.constprop.0+0xb8/0xc0
     devlink_health_report+0x4a/0x1c0
     mlx5_fw_reporter_err_work+0xa4/0xd0 [mlx5_core]
     process_one_work+0x1bb/0x3c0
     ? process_one_work+0x3c0/0x3c0
     worker_thread+0x4d/0x3c0
     ? process_one_work+0x3c0/0x3c0
     kthread+0xc6/0xf0
     ? kthread_complete_and_exit+0x20/0x20
     ret_from_fork+0x1f/0x30
     </TASK>
    
    Fixes: cf530217408e ("devlink: Notify users when objects are accessible")
    Signed-off-by: Shay Drory <shayd@nvidia.com>
    Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240409190820.227554-3-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: SF, Stop waiting for FW as teardown was called [+ + +]
Author: Moshe Shemesh <moshe@nvidia.com>
Date:   Thu Jan 25 14:24:09 2024 +0200

    net/mlx5: SF, Stop waiting for FW as teardown was called
    
    [ Upstream commit 137cef6d55564fb687d12fbc5f85be43ff7b53a7 ]
    
    When PF/VF teardown is called the driver sets the flag
    MLX5_BREAK_FW_WAIT to stop waiting for FW loading and initializing. Same
    should be applied to SF driver teardown to cut waiting time. On
    mlx5_sf_dev_remove() set the flag before draining health WQ as recovery
    flow may also wait for FW reloading while it is not relevant anymore.
    
    Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
    Reviewed-by: Aya Levin <ayal@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Stable-dep-of: c6e77aa9dd82 ("net/mlx5: Register devlink first under devlink lock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: Do not produce metadata freelist entries in Tx port ts WQE xmit [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Tue Apr 9 22:08:17 2024 +0300

    net/mlx5e: Do not produce metadata freelist entries in Tx port ts WQE xmit
    
    [ Upstream commit 86b0ca5b118d3a0bae5e5645a13e66f8a4f6c525 ]
    
    Free Tx port timestamping metadata entries in the NAPI poll context and
    consume metadata enties in the WQE xmit path. Do not free a Tx port
    timestamping metadata entry in the WQE xmit path even in the error path to
    avoid a race between two metadata entry producers.
    
    Fixes: 3178308ad4ca ("net/mlx5e: Make tx_port_ts logic resilient to out-of-order CQEs")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240409190820.227554-10-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Fix mlx5e_priv_init() cleanup flow [+ + +]
Author: Carolina Jubran <cjubran@nvidia.com>
Date:   Tue Apr 9 22:08:15 2024 +0300

    net/mlx5e: Fix mlx5e_priv_init() cleanup flow
    
    [ Upstream commit ecb829459a841198e142f72fadab56424ae96519 ]
    
    When mlx5e_priv_init() fails, the cleanup flow calls mlx5e_selq_cleanup which
    calls mlx5e_selq_apply() that assures that the `priv->state_lock` is held using
    lockdep_is_held().
    
    Acquire the state_lock in mlx5e_selq_cleanup().
    
    Kernel log:
    =============================
    WARNING: suspicious RCU usage
    6.8.0-rc3_net_next_841a9b5 #1 Not tainted
    -----------------------------
    drivers/net/ethernet/mellanox/mlx5/core/en/selq.c:124 suspicious rcu_dereference_protected() usage!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 1
    2 locks held by systemd-modules/293:
     #0: ffffffffa05067b0 (devices_rwsem){++++}-{3:3}, at: ib_register_client+0x109/0x1b0 [ib_core]
     #1: ffff8881096c65c0 (&device->client_data_rwsem){++++}-{3:3}, at: add_client_context+0x104/0x1c0 [ib_core]
    
    stack backtrace:
    CPU: 4 PID: 293 Comm: systemd-modules Not tainted 6.8.0-rc3_net_next_841a9b5 #1
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl+0x8a/0xa0
     lockdep_rcu_suspicious+0x154/0x1a0
     mlx5e_selq_apply+0x94/0xa0 [mlx5_core]
     mlx5e_selq_cleanup+0x3a/0x60 [mlx5_core]
     mlx5e_priv_init+0x2be/0x2f0 [mlx5_core]
     mlx5_rdma_setup_rn+0x7c/0x1a0 [mlx5_core]
     rdma_init_netdev+0x4e/0x80 [ib_core]
     ? mlx5_rdma_netdev_free+0x70/0x70 [mlx5_core]
     ipoib_intf_init+0x64/0x550 [ib_ipoib]
     ipoib_intf_alloc+0x4e/0xc0 [ib_ipoib]
     ipoib_add_one+0xb0/0x360 [ib_ipoib]
     add_client_context+0x112/0x1c0 [ib_core]
     ib_register_client+0x166/0x1b0 [ib_core]
     ? 0xffffffffa0573000
     ipoib_init_module+0xeb/0x1a0 [ib_ipoib]
     do_one_initcall+0x61/0x250
     do_init_module+0x8a/0x270
     init_module_from_file+0x8b/0xd0
     idempotent_init_module+0x17d/0x230
     __x64_sys_finit_module+0x61/0xb0
     do_syscall_64+0x71/0x140
     entry_SYSCALL_64_after_hwframe+0x46/0x4e
     </TASK>
    
    Fixes: 8bf30be75069 ("net/mlx5e: Introduce select queue parameters")
    Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240409190820.227554-8-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: HTB, Fix inconsistencies with QoS SQs number [+ + +]
Author: Carolina Jubran <cjubran@nvidia.com>
Date:   Tue Apr 9 22:08:16 2024 +0300

    net/mlx5e: HTB, Fix inconsistencies with QoS SQs number
    
    [ Upstream commit 2f436f1869771d46e1a9f85738d5a1a7c5653a4e ]
    
    When creating a new HTB class while the interface is down,
    the variable that follows the number of QoS SQs (htb_max_qos_sqs)
    may not be consistent with the number of HTB classes.
    
    Previously, we compared these two values to ensure that
    the node_qid is lower than the number of QoS SQs, and we
    allocated stats for that SQ when they are equal.
    
    Change the check to compare the node_qid with the current
    number of leaf nodes and fix the checking conditions to
    ensure allocation of stats_list and stats for each node.
    
    Fixes: 214baf22870c ("net/mlx5e: Support HTB offload")
    Signed-off-by: Carolina Jubran <cjubran@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://lore.kernel.org/r/20240409190820.227554-9-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: dsa: mt7530: trap link-local frames regardless of ST Port State [+ + +]
Author: Arınç ÜNAL <arinc.unal@arinc9.com>
Date:   Tue Apr 9 18:01:14 2024 +0300

    net: dsa: mt7530: trap link-local frames regardless of ST Port State
    
    [ Upstream commit 17c560113231ddc20088553c7b499b289b664311 ]
    
    In Clause 5 of IEEE Std 802-2014, two sublayers of the data link layer
    (DLL) of the Open Systems Interconnection basic reference model (OSI/RM)
    are described; the medium access control (MAC) and logical link control
    (LLC) sublayers. The MAC sublayer is the one facing the physical layer.
    
    In 8.2 of IEEE Std 802.1Q-2022, the Bridge architecture is described. A
    Bridge component comprises a MAC Relay Entity for interconnecting the Ports
    of the Bridge, at least two Ports, and higher layer entities with at least
    a Spanning Tree Protocol Entity included.
    
    Each Bridge Port also functions as an end station and shall provide the MAC
    Service to an LLC Entity. Each instance of the MAC Service is provided to a
    distinct LLC Entity that supports protocol identification, multiplexing,
    and demultiplexing, for protocol data unit (PDU) transmission and reception
    by one or more higher layer entities.
    
    It is described in 8.13.9 of IEEE Std 802.1Q-2022 that in a Bridge, the LLC
    Entity associated with each Bridge Port is modeled as being directly
    connected to the attached Local Area Network (LAN).
    
    On the switch with CPU port architecture, CPU port functions as Management
    Port, and the Management Port functionality is provided by software which
    functions as an end station. Software is connected to an IEEE 802 LAN that
    is wholly contained within the system that incorporates the Bridge.
    Software provides access to the LLC Entity associated with each Bridge Port
    by the value of the source port field on the special tag on the frame
    received by software.
    
    We call frames that carry control information to determine the active
    topology and current extent of each Virtual Local Area Network (VLAN),
    i.e., spanning tree or Shortest Path Bridging (SPB) and Multiple VLAN
    Registration Protocol Data Units (MVRPDUs), and frames from other link
    constrained protocols, such as Extensible Authentication Protocol over LAN
    (EAPOL) and Link Layer Discovery Protocol (LLDP), link-local frames. They
    are not forwarded by a Bridge. Permanently configured entries in the
    filtering database (FDB) ensure that such frames are discarded by the
    Forwarding Process. In 8.6.3 of IEEE Std 802.1Q-2022, this is described in
    detail:
    
    Each of the reserved MAC addresses specified in Table 8-1
    (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]) shall be
    permanently configured in the FDB in C-VLAN components and ERs.
    
    Each of the reserved MAC addresses specified in Table 8-2
    (01-80-C2-00-00-[01,02,03,04,05,06,07,08,09,0A,0E]) shall be permanently
    configured in the FDB in S-VLAN components.
    
    Each of the reserved MAC addresses specified in Table 8-3
    (01-80-C2-00-00-[01,02,04,0E]) shall be permanently configured in the FDB
    in TPMR components.
    
    The FDB entries for reserved MAC addresses shall specify filtering for all
    Bridge Ports and all VIDs. Management shall not provide the capability to
    modify or remove entries for reserved MAC addresses.
    
    The addresses in Table 8-1, Table 8-2, and Table 8-3 determine the scope of
    propagation of PDUs within a Bridged Network, as follows:
    
      The Nearest Bridge group address (01-80-C2-00-00-0E) is an address that
      no conformant Two-Port MAC Relay (TPMR) component, Service VLAN (S-VLAN)
      component, Customer VLAN (C-VLAN) component, or MAC Bridge can forward.
      PDUs transmitted using this destination address, or any other addresses
      that appear in Table 8-1, Table 8-2, and Table 8-3
      (01-80-C2-00-00-[00,01,02,03,04,05,06,07,08,09,0A,0B,0C,0D,0E,0F]), can
      therefore travel no further than those stations that can be reached via a
      single individual LAN from the originating station.
    
      The Nearest non-TPMR Bridge group address (01-80-C2-00-00-03), is an
      address that no conformant S-VLAN component, C-VLAN component, or MAC
      Bridge can forward; however, this address is relayed by a TPMR component.
      PDUs using this destination address, or any of the other addresses that
      appear in both Table 8-1 and Table 8-2 but not in Table 8-3
      (01-80-C2-00-00-[00,03,05,06,07,08,09,0A,0B,0C,0D,0F]), will be relayed
      by any TPMRs but will propagate no further than the nearest S-VLAN
      component, C-VLAN component, or MAC Bridge.
    
      The Nearest Customer Bridge group address (01-80-C2-00-00-00) is an
      address that no conformant C-VLAN component, MAC Bridge can forward;
      however, it is relayed by TPMR components and S-VLAN components. PDUs
      using this destination address, or any of the other addresses that appear
      in Table 8-1 but not in either Table 8-2 or Table 8-3
      (01-80-C2-00-00-[00,0B,0C,0D,0F]), will be relayed by TPMR components and
      S-VLAN components but will propagate no further than the nearest C-VLAN
      component or MAC Bridge.
    
    Because the LLC Entity associated with each Bridge Port is provided via CPU
    port, we must not filter these frames but forward them to CPU port.
    
    In a Bridge, the transmission Port is majorly decided by ingress and egress
    rules, FDB, and spanning tree Port State functions of the Forwarding
    Process. For link-local frames, only CPU port should be designated as
    destination port in the FDB, and the other functions of the Forwarding
    Process must not interfere with the decision of the transmission Port. We
    call this process trapping frames to CPU port.
    
    Therefore, on the switch with CPU port architecture, link-local frames must
    be trapped to CPU port, and certain link-local frames received by a Port of
    a Bridge comprising a TPMR component or an S-VLAN component must be
    excluded from it.
    
    A Bridge of the switch with CPU port architecture cannot comprise a
    Two-Port MAC Relay (TPMR) component as a TPMR component supports only a
    subset of the functionality of a MAC Bridge. A Bridge comprising two Ports
    (Management Port doesn't count) of this architecture will either function
    as a standard MAC Bridge or a standard VLAN Bridge.
    
    Therefore, a Bridge of this architecture can only comprise S-VLAN
    components, C-VLAN components, or MAC Bridge components. Since there's no
    TPMR component, we don't need to relay PDUs using the destination addresses
    specified on the Nearest non-TPMR section, and the proportion of the
    Nearest Customer Bridge section where they must be relayed by TPMR
    components.
    
    One option to trap link-local frames to CPU port is to add static FDB
    entries with CPU port designated as destination port. However, because that
    Independent VLAN Learning (IVL) is being used on every VID, each entry only
    applies to a single VLAN Identifier (VID). For a Bridge comprising a MAC
    Bridge component or a C-VLAN component, there would have to be 16 times
    4096 entries. This switch intellectual property can only hold a maximum of
    2048 entries. Using this option, there also isn't a mechanism to prevent
    link-local frames from being discarded when the spanning tree Port State of
    the reception Port is discarding.
    
    The remaining option is to utilise the BPC, RGAC1, RGAC2, RGAC3, and RGAC4
    registers. Whilst this applies to every VID, it doesn't contain all of the
    reserved MAC addresses without affecting the remaining Standard Group MAC
    Addresses. The REV_UN frame tag utilised using the RGAC4 register covers
    the remaining 01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F] destination
    addresses. It also includes the 01-80-C2-00-00-22 to 01-80-C2-00-00-FF
    destination addresses which may be relayed by MAC Bridges or VLAN Bridges.
    The latter option provides better but not complete conformance.
    
    This switch intellectual property also does not provide a mechanism to trap
    link-local frames with specific destination addresses to CPU port by
    Bridge, to conform to the filtering rules for the distinct Bridge
    components.
    
    Therefore, regardless of the type of the Bridge component, link-local
    frames with these destination addresses will be trapped to CPU port:
    
    01-80-C2-00-00-[00,01,02,03,0E]
    
    In a Bridge comprising a MAC Bridge component or a C-VLAN component:
    
      Link-local frames with these destination addresses won't be trapped to
      CPU port which won't conform to IEEE Std 802.1Q-2022:
    
      01-80-C2-00-00-[04,05,06,07,08,09,0A,0B,0C,0D,0F]
    
    In a Bridge comprising an S-VLAN component:
    
      Link-local frames with these destination addresses will be trapped to CPU
      port which won't conform to IEEE Std 802.1Q-2022:
    
      01-80-C2-00-00-00
    
      Link-local frames with these destination addresses won't be trapped to
      CPU port which won't conform to IEEE Std 802.1Q-2022:
    
      01-80-C2-00-00-[04,05,06,07,08,09,0A]
    
    Currently on this switch intellectual property, if the spanning tree Port
    State of the reception Port is discarding, link-local frames will be
    discarded.
    
    To trap link-local frames regardless of the spanning tree Port State, make
    the switch regard them as Bridge Protocol Data Units (BPDUs). This switch
    intellectual property only lets the frames regarded as BPDUs bypass the
    spanning tree Port State function of the Forwarding Process.
    
    With this change, the only remaining interference is the ingress rules.
    When the reception Port has no PVID assigned on software, VLAN-untagged
    frames won't be allowed in. There doesn't seem to be a mechanism on the
    switch intellectual property to have link-local frames bypass this function
    of the Forwarding Process.
    
    Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
    Reviewed-by: Daniel Golle <daniel@makrotopia.org>
    Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
    Link: https://lore.kernel.org/r/20240409-b4-for-net-mt7530-fix-link-local-when-stp-discarding-v2-1-07b1150164ac@arinc9.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ena: Fix incorrect descriptor free behavior [+ + +]
Author: David Arinzon <darinzon@amazon.com>
Date:   Wed Apr 10 09:13:57 2024 +0000

    net: ena: Fix incorrect descriptor free behavior
    
    [ Upstream commit bf02d9fe00632d22fa91d34749c7aacf397b6cde ]
    
    ENA has two types of TX queues:
    - queues which only process TX packets arriving from the network stack
    - queues which only process TX packets forwarded to it by XDP_REDIRECT
      or XDP_TX instructions
    
    The ena_free_tx_bufs() cycles through all descriptors in a TX queue
    and unmaps + frees every descriptor that hasn't been acknowledged yet
    by the device (uncompleted TX transactions).
    The function assumes that the processed TX queue is necessarily from
    the first category listed above and ends up using napi_consume_skb()
    for descriptors belonging to an XDP specific queue.
    
    This patch solves a bug in which, in case of a VF reset, the
    descriptors aren't freed correctly, leading to crashes.
    
    Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action")
    Signed-off-by: Shay Agroskin <shayagr@amazon.com>
    Signed-off-by: David Arinzon <darinzon@amazon.com>
    Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ena: Fix potential sign extension issue [+ + +]
Author: David Arinzon <darinzon@amazon.com>
Date:   Wed Apr 10 09:13:55 2024 +0000

    net: ena: Fix potential sign extension issue
    
    [ Upstream commit 713a85195aad25d8a26786a37b674e3e5ec09e3c ]
    
    Small unsigned types are promoted to larger signed types in
    the case of multiplication, the result of which may overflow.
    In case the result of such a multiplication has its MSB
    turned on, it will be sign extended with '1's.
    This changes the multiplication result.
    
    Code example of the phenomenon:
    -------------------------------
    u16 x, y;
    size_t z1, z2;
    
    x = y = 0xffff;
    printk("x=%x y=%x\n",x,y);
    
    z1 = x*y;
    z2 = (size_t)x*y;
    
    printk("z1=%lx z2=%lx\n", z1, z2);
    
    Output:
    -------
    x=ffff y=ffff
    z1=fffffffffffe0001 z2=fffe0001
    
    The expected result of ffff*ffff is fffe0001, and without the
    explicit casting to avoid the unwanted sign extension we got
    fffffffffffe0001.
    
    This commit adds an explicit casting to avoid the sign extension
    issue.
    
    Fixes: 689b2bdaaa14 ("net: ena: add functions for handling Low Latency Queues in ena_com")
    Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
    Signed-off-by: David Arinzon <darinzon@amazon.com>
    Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ena: Move XDP code to its new files [+ + +]
Author: David Arinzon <darinzon@amazon.com>
Date:   Mon Jan 1 19:08:45 2024 +0000

    net: ena: Move XDP code to its new files
    
    [ Upstream commit d000574d02870710c62751148cbfe22993222b98 ]
    
    XDP system has a very large footprint in the driver's overall code.
    makes the whole driver's code much harder to read.
    
    Moving XDP code to dedicated files.
    
    This patch doesn't make any changes to the code itself and only
    cut-pastes the code into ena_xdp.c and ena_xdp.h files so the change
    is purely cosmetic.
    
    Signed-off-by: Shay Agroskin <shayagr@amazon.com>
    Signed-off-by: David Arinzon <darinzon@amazon.com>
    Link: https://lore.kernel.org/r/20240101190855.18739-2-darinzon@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 36a1ca01f045 ("net: ena: Set tx_info->xdpf value to NULL")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ena: Pass ena_adapter instead of net_device to ena_xmit_common() [+ + +]
Author: David Arinzon <darinzon@amazon.com>
Date:   Mon Jan 1 19:08:46 2024 +0000

    net: ena: Pass ena_adapter instead of net_device to ena_xmit_common()
    
    [ Upstream commit 39a044f4dcfee1c776603a6589b6fb98a9e222f2 ]
    
    This change will enable the ability to use ena_xmit_common()
    in functions that don't have a net_device pointer.
    While it can be retrieved by dereferencing
    ena_adapter (adapter->netdev), there's no reason to do it in
    fast path code where this pointer is only needed for
    debug prints.
    
    Signed-off-by: Shay Agroskin <shayagr@amazon.com>
    Signed-off-by: David Arinzon <darinzon@amazon.com>
    Link: https://lore.kernel.org/r/20240101190855.18739-3-darinzon@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 36a1ca01f045 ("net: ena: Set tx_info->xdpf value to NULL")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ena: Set tx_info->xdpf value to NULL [+ + +]
Author: David Arinzon <darinzon@amazon.com>
Date:   Wed Apr 10 09:13:58 2024 +0000

    net: ena: Set tx_info->xdpf value to NULL
    
    [ Upstream commit 36a1ca01f0452f2549420e7279c2588729bd94df ]
    
    The patch mentioned in the `Fixes` tag removed the explicit assignment
    of tx_info->xdpf to NULL with the justification that there's no need
    to set tx_info->xdpf to NULL and tx_info->num_of_bufs to 0 in case
    of a mapping error. Both values won't be used once the mapping function
    returns an error, and their values would be overridden by the next
    transmitted packet.
    
    While both values do indeed get overridden in the next transmission
    call, the value of tx_info->xdpf is also used to check whether a TX
    descriptor's transmission has been completed (i.e. a completion for it
    was polled).
    
    An example scenario:
    1. Mapping failed, tx_info->xdpf wasn't set to NULL
    2. A VF reset occurred leading to IO resource destruction and
       a call to ena_free_tx_bufs() function
    3. Although the descriptor whose mapping failed was freed by the
       transmission function, it still passes the check
         if (!tx_info->skb)
    
       (skb and xdp_frame are in a union)
    4. The xdp_frame associated with the descriptor is freed twice
    
    This patch returns the assignment of NULL to tx_info->xdpf to make the
    cleaning function knows that the descriptor is already freed.
    
    Fixes: 504fd6a5390c ("net: ena: fix DMA mapping function issues in XDP")
    Signed-off-by: Shay Agroskin <shayagr@amazon.com>
    Signed-off-by: David Arinzon <darinzon@amazon.com>
    Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ena: Use tx_ring instead of xdp_ring for XDP channel TX [+ + +]
Author: David Arinzon <darinzon@amazon.com>
Date:   Mon Jan 1 19:08:49 2024 +0000

    net: ena: Use tx_ring instead of xdp_ring for XDP channel TX
    
    [ Upstream commit 911a8c960110b03ed519ce43ea6c9990a0ee0ceb ]
    
    When an XDP program is loaded the existing channels in the driver split
    into two halves:
    - The first half of the channels contain RX and TX rings, these queues
      are used for receiving traffic and sending packets originating from
      kernel.
    - The second half of the channels contain only a TX ring. These queues
      are used for sending packets that were redirected using XDP_TX
      or XDP_REDIRECT.
    
    Referring to the queues in the second half of the channels as "xdp_ring"
    can be confusing and may give the impression that ENA has the capability
    to generate an additional special queue.
    
    This patch ensures that the xdp_ring field is exclusively used to
    describe the XDP TX queue that a specific RX queue needs to utilize when
    forwarding packets with XDP TX and XDP REDIRECT, preserving the
    integrity of the xdp_ring field in ena_ring.
    
    Signed-off-by: Shay Agroskin <shayagr@amazon.com>
    Signed-off-by: David Arinzon <darinzon@amazon.com>
    Link: https://lore.kernel.org/r/20240101190855.18739-6-darinzon@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 36a1ca01f045 ("net: ena: Set tx_info->xdpf value to NULL")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ena: Wrong missing IO completions check order [+ + +]
Author: David Arinzon <darinzon@amazon.com>
Date:   Wed Apr 10 09:13:56 2024 +0000

    net: ena: Wrong missing IO completions check order
    
    [ Upstream commit f7e417180665234fdb7af2ebe33d89aaa434d16f ]
    
    Missing IO completions check is called every second (HZ jiffies).
    This commit fixes several issues with this check:
    
    1. Duplicate queues check:
       Max of 4 queues are scanned on each check due to monitor budget.
       Once reaching the budget, this check exits under the assumption that
       the next check will continue to scan the remainder of the queues,
       but in practice, next check will first scan the last already scanned
       queue which is not necessary and may cause the full queue scan to
       last a couple of seconds longer.
       The fix is to start every check with the next queue to scan.
       For example, on 8 IO queues:
       Bug: [0,1,2,3], [3,4,5,6], [6,7]
       Fix: [0,1,2,3], [4,5,6,7]
    
    2. Unbalanced queues check:
       In case the number of active IO queues is not a multiple of budget,
       there will be checks which don't utilize the full budget
       because the full scan exits when reaching the last queue id.
       The fix is to run every TX completion check with exact queue budget
       regardless of the queue id.
       For example, on 7 IO queues:
       Bug: [0,1,2,3], [4,5,6], [0,1,2,3]
       Fix: [0,1,2,3], [4,5,6,0], [1,2,3,4]
       The budget may be lowered in case the number of IO queues is less
       than the budget (4) to make sure there are no duplicate queues on
       the same check.
       For example, on 3 IO queues:
       Bug: [0,1,2,0], [1,2,0,1]
       Fix: [0,1,2], [0,1,2]
    
    Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)")
    Signed-off-by: Amit Bernstein <amitbern@amazon.com>
    Signed-off-by: David Arinzon <darinzon@amazon.com>
    Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ks8851: Handle softirqs at the end of IRQ thread to fix hang [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Fri Apr 5 22:30:40 2024 +0200

    net: ks8851: Handle softirqs at the end of IRQ thread to fix hang
    
    [ Upstream commit be0384bf599cf1eb8d337517feeb732d71f75a6f ]
    
    The ks8851_irq() thread may call ks8851_rx_pkts() in case there are
    any packets in the MAC FIFO, which calls netif_rx(). This netif_rx()
    implementation is guarded by local_bh_disable() and local_bh_enable().
    The local_bh_enable() may call do_softirq() to run softirqs in case
    any are pending. One of the softirqs is net_rx_action, which ultimately
    reaches the driver .start_xmit callback. If that happens, the system
    hangs. The entire call chain is below:
    
    ks8851_start_xmit_par from netdev_start_xmit
    netdev_start_xmit from dev_hard_start_xmit
    dev_hard_start_xmit from sch_direct_xmit
    sch_direct_xmit from __dev_queue_xmit
    __dev_queue_xmit from __neigh_update
    __neigh_update from neigh_update
    neigh_update from arp_process.constprop.0
    arp_process.constprop.0 from __netif_receive_skb_one_core
    __netif_receive_skb_one_core from process_backlog
    process_backlog from __napi_poll.constprop.0
    __napi_poll.constprop.0 from net_rx_action
    net_rx_action from __do_softirq
    __do_softirq from call_with_stack
    call_with_stack from do_softirq
    do_softirq from __local_bh_enable_ip
    __local_bh_enable_ip from netif_rx
    netif_rx from ks8851_irq
    ks8851_irq from irq_thread_fn
    irq_thread_fn from irq_thread
    irq_thread from kthread
    kthread from ret_from_fork
    
    The hang happens because ks8851_irq() first locks a spinlock in
    ks8851_par.c ks8851_lock_par() spin_lock_irqsave(&ksp->lock, ...)
    and with that spinlock locked, calls netif_rx(). Once the execution
    reaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again
    which attempts to claim the already locked spinlock again, and the
    hang happens.
    
    Move the do_softirq() call outside of the spinlock protected section
    of ks8851_irq() by disabling BHs around the entire spinlock protected
    section of ks8851_irq() handler. Place local_bh_enable() outside of
    the spinlock protected section, so that it can trigger do_softirq()
    without the ks8851_par.c ks8851_lock_par() spinlock being held, and
    safely call ks8851_start_xmit_par() without attempting to lock the
    already locked spinlock.
    
    Since ks8851_irq() is protected by local_bh_disable()/local_bh_enable()
    now, replace netif_rx() with __netif_rx() which is not duplicating the
    local_bh_disable()/local_bh_enable() calls.
    
    Fixes: 797047f875b5 ("net: ks8851: Implement Parallel bus operations")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Link: https://lore.kernel.org/r/20240405203204.82062-2-marex@denx.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ks8851: Inline ks8851_rx_skb() [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Fri Apr 5 22:30:39 2024 +0200

    net: ks8851: Inline ks8851_rx_skb()
    
    [ Upstream commit f96f700449b6d190e06272f1cf732ae8e45b73df ]
    
    Both ks8851_rx_skb_par() and ks8851_rx_skb_spi() call netif_rx(skb),
    inline the netif_rx(skb) call directly into ks8851_common.c and drop
    the .rx_skb callback and ks8851_rx_skb() wrapper. This removes one
    indirect call from the driver, no functional change otherwise.
    
    Signed-off-by: Marek Vasut <marex@denx.de>
    Link: https://lore.kernel.org/r/20240405203204.82062-1-marex@denx.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: be0384bf599c ("net: ks8851: Handle softirqs at the end of IRQ thread to fix hang")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: openvswitch: fix unwanted error log on timeout policy probing [+ + +]
Author: Ilya Maximets <i.maximets@ovn.org>
Date:   Wed Apr 3 22:38:01 2024 +0200

    net: openvswitch: fix unwanted error log on timeout policy probing
    
    [ Upstream commit 4539f91f2a801c0c028c252bffae56030cfb2cae ]
    
    On startup, ovs-vswitchd probes different datapath features including
    support for timeout policies.  While probing, it tries to execute
    certain operations with OVS_PACKET_ATTR_PROBE or OVS_FLOW_ATTR_PROBE
    attributes set.  These attributes tell the openvswitch module to not
    log any errors when they occur as it is expected that some of the
    probes will fail.
    
    For some reason, setting the timeout policy ignores the PROBE attribute
    and logs a failure anyway.  This is causing the following kernel log
    on each re-start of ovs-vswitchd:
    
      kernel: Failed to associated timeout policy `ovs_test_tp'
    
    Fix that by using the same logging macro that all other messages are
    using.  The message will still be printed at info level when needed
    and will be rate limited, but with a net rate limiter instead of
    generic printk one.
    
    The nf_ct_set_timeout() itself will still print some info messages,
    but at least this change makes logging in openvswitch module more
    consistent.
    
    Fixes: 06bd2bdf19d2 ("openvswitch: Add timeout support to ct action")
    Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
    Acked-by: Eelco Chaudron <echaudro@redhat.com>
    Link: https://lore.kernel.org/r/20240403203803.2137962-1-i.maximets@ovn.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: sparx5: fix wrong config being used when reconfiguring PCS [+ + +]
Author: Daniel Machon <daniel.machon@microchip.com>
Date:   Tue Apr 9 12:41:59 2024 +0200

    net: sparx5: fix wrong config being used when reconfiguring PCS
    
    [ Upstream commit 33623113a48ea906f1955cbf71094f6aa4462e8f ]
    
    The wrong port config is being used if the PCS is reconfigured. Fix this
    by correctly using the new config instead of the old one.
    
    Fixes: 946e7fd5053a ("net: sparx5: add port module support")
    Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Link: https://lore.kernel.org/r/20240409-link-mode-reconfiguration-fix-v2-1-db6a507f3627@microchip.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: complete validation of user input [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Apr 9 12:07:41 2024 +0000

    netfilter: complete validation of user input
    
    [ Upstream commit 65acf6e0501ac8880a4f73980d01b5d27648b956 ]
    
    In my recent commit, I missed that do_replace() handlers
    use copy_from_sockptr() (which I fixed), followed
    by unsafe copy_from_sockptr_offset() calls.
    
    In all functions, we can perform the @optlen validation
    before even calling xt_alloc_table_info() with the following
    check:
    
    if ((u64)optlen < (u64)tmp.size + sizeof(tmp))
            return -EINVAL;
    
    Fixes: 0c83842df40f ("netfilter: validate user input for expected length")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Link: https://lore.kernel.org/r/20240409120741.3538135-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nouveau: fix function cast warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Apr 4 18:02:25 2024 +0200

    nouveau: fix function cast warning
    
    [ Upstream commit 185fdb4697cc9684a02f2fab0530ecdd0c2f15d4 ]
    
    Calling a function through an incompatible pointer type causes breaks
    kcfi, so clang warns about the assignment:
    
    drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c:73:10: error: cast from 'void (*)(const void *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
       73 |         .fini = (void(*)(void *))kfree,
    
    Avoid this with a trivial wrapper.
    
    Fixes: c39f472e9f14 ("drm/nouveau: remove symlinks, move core/ to nvkm/ (no code changes)")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Danilo Krummrich <dakr@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240404160234.2923554-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-af: Fix NIX SQ mode and BP config [+ + +]
Author: Geetha sowjanya <gakula@marvell.com>
Date:   Mon Apr 8 12:06:43 2024 +0530

    octeontx2-af: Fix NIX SQ mode and BP config
    
    [ Upstream commit faf23006185e777db18912685922c5ddb2df383f ]
    
    NIX SQ mode and link backpressure configuration is required for
    all platforms. But in current driver this code is wrongly placed
    under specific platform check. This patch fixes the issue by
    moving the code out of platform check.
    
    Fixes: 5d9b976d4480 ("octeontx2-af: Support fixed transmit scheduler topology")
    Signed-off-by: Geetha sowjanya <gakula@marvell.com>
    Link: https://lore.kernel.org/r/20240408063643.26288-1-gakula@marvell.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-pf: Fix transmit scheduler resource leak [+ + +]
Author: Hariprasad Kelam <hkelam@marvell.com>
Date:   Thu Apr 4 16:54:27 2024 +0530

    octeontx2-pf: Fix transmit scheduler resource leak
    
    [ Upstream commit bccb798e07f8bb8b91212fe8ed1e421685449076 ]
    
    Inorder to support shaping and scheduling, Upon class creation
    Netdev driver allocates trasmit schedulers.
    
    The previous patch which added support for Round robin scheduling has
    a bug due to which driver is not freeing transmit schedulers post
    class deletion.
    
    This patch fixes the same.
    
    Fixes: 47a9656f168a ("octeontx2-pf: htb offload support for Round Robin scheduling")
    Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/x86: Fix out of range data [+ + +]
Author: Namhyung Kim <namhyung@kernel.org>
Date:   Tue Mar 5 22:10:03 2024 -0800

    perf/x86: Fix out of range data
    
    commit dec8ced871e17eea46f097542dd074d022be4bd1 upstream.
    
    On x86 each struct cpu_hw_events maintains a table for counter assignment but
    it missed to update one for the deleted event in x86_pmu_del().  This
    can make perf_clear_dirty_counters() reset used counter if it's called
    before event scheduling or enabling.  Then it would return out of range
    data which doesn't make sense.
    
    The following code can reproduce the problem.
    
      $ cat repro.c
      #include <pthread.h>
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include <linux/perf_event.h>
      #include <sys/ioctl.h>
      #include <sys/mman.h>
      #include <sys/syscall.h>
    
      struct perf_event_attr attr = {
            .type = PERF_TYPE_HARDWARE,
            .config = PERF_COUNT_HW_CPU_CYCLES,
            .disabled = 1,
      };
    
      void *worker(void *arg)
      {
            int cpu = (long)arg;
            int fd1 = syscall(SYS_perf_event_open, &attr, -1, cpu, -1, 0);
            int fd2 = syscall(SYS_perf_event_open, &attr, -1, cpu, -1, 0);
            void *p;
    
            do {
                    ioctl(fd1, PERF_EVENT_IOC_ENABLE, 0);
                    p = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd1, 0);
                    ioctl(fd2, PERF_EVENT_IOC_ENABLE, 0);
    
                    ioctl(fd2, PERF_EVENT_IOC_DISABLE, 0);
                    munmap(p, 4096);
                    ioctl(fd1, PERF_EVENT_IOC_DISABLE, 0);
            } while (1);
    
            return NULL;
      }
    
      int main(void)
      {
            int i;
            int n = sysconf(_SC_NPROCESSORS_ONLN);
            pthread_t *th = calloc(n, sizeof(*th));
    
            for (i = 0; i < n; i++)
                    pthread_create(&th[i], NULL, worker, (void *)(long)i);
            for (i = 0; i < n; i++)
                    pthread_join(th[i], NULL);
    
            free(th);
            return 0;
      }
    
    And you can see the out of range data using perf stat like this.
    Probably it'd be easier to see on a large machine.
    
      $ gcc -o repro repro.c -pthread
      $ ./repro &
      $ sudo perf stat -A -I 1000 2>&1 | awk '{ if (length($3) > 15) print }'
           1.001028462 CPU6   196,719,295,683,763      cycles                           # 194290.996 GHz                       (71.54%)
           1.001028462 CPU3   396,077,485,787,730      branch-misses                    # 15804359784.80% of all branches      (71.07%)
           1.001028462 CPU17  197,608,350,727,877      branch-misses                    # 14594186554.56% of all branches      (71.22%)
           2.020064073 CPU4   198,372,472,612,140      cycles                           # 194681.113 GHz                       (70.95%)
           2.020064073 CPU6   199,419,277,896,696      cycles                           # 195720.007 GHz                       (70.57%)
           2.020064073 CPU20  198,147,174,025,639      cycles                           # 194474.654 GHz                       (71.03%)
           2.020064073 CPU20  198,421,240,580,145      stalled-cycles-frontend          #  100.14% frontend cycles idle        (70.93%)
           3.037443155 CPU4   197,382,689,923,416      cycles                           # 194043.065 GHz                       (71.30%)
           3.037443155 CPU20  196,324,797,879,414      cycles                           # 193003.773 GHz                       (71.69%)
           3.037443155 CPU5   197,679,956,608,205      stalled-cycles-backend           # 1315606428.66% backend cycles idle   (71.19%)
           3.037443155 CPU5   198,571,860,474,851      instructions                     # 13215422.58  insn per cycle
    
    It should move the contents in the cpuc->assign as well.
    
    Fixes: 5471eea5d3bf ("perf/x86: Reset the dirty counter to prevent the leak for an RDPMC task")
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240306061003.1894224-1-namhyung@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
platform/chrome: cros_ec_uart: properly fix race condition [+ + +]
Author: Noah Loomans <noah@noahloomans.com>
Date:   Wed Apr 10 20:26:19 2024 +0200

    platform/chrome: cros_ec_uart: properly fix race condition
    
    commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
    
    The cros_ec_uart_probe() function calls devm_serdev_device_open() before
    it calls serdev_device_set_client_ops(). This can trigger a NULL pointer
    dereference:
    
        BUG: kernel NULL pointer dereference, address: 0000000000000000
        ...
        Call Trace:
         <TASK>
         ...
         ? ttyport_receive_buf
    
    A simplified version of crashing code is as follows:
    
        static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl,
                                                          const u8 *data,
                                                          size_t count)
        {
                struct serdev_device *serdev = ctrl->serdev;
    
                if (!serdev || !serdev->ops->receive_buf) // CRASH!
                    return 0;
    
                return serdev->ops->receive_buf(serdev, data, count);
        }
    
    It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops
    will also exist. This conflicts with the existing cros_ec_uart_probe()
    logic, as it first calls devm_serdev_device_open() (which sets
    SERPORT_ACTIVE), and only later sets serdev->ops via
    serdev_device_set_client_ops().
    
    Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race
    condition") attempted to fix a similar race condition, but while doing
    so, made the window of error for this race condition to happen much
    wider.
    
    Attempt to fix the race condition again, making sure we fully setup
    before calling devm_serdev_device_open().
    
    Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition")
    Cc: stable@vger.kernel.org
    Signed-off-by: Noah Loomans <noah@noahloomans.com>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com
    Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PM: s2idle: Make sure CPUs will wakeup directly on resume [+ + +]
Author: Anna-Maria Behnsen <anna-maria@linutronix.de>
Date:   Mon Apr 8 09:02:23 2024 +0200

    PM: s2idle: Make sure CPUs will wakeup directly on resume
    
    commit 3c89a068bfd0698a5478f4cf39493595ef757d5e upstream.
    
    s2idle works like a regular suspend with freezing processes and freezing
    devices. All CPUs except the control CPU go into idle. Once this is
    completed the control CPU kicks all other CPUs out of idle, so that they
    reenter the idle loop and then enter s2idle state. The control CPU then
    issues an swait() on the suspend state and therefore enters the idle loop
    as well.
    
    Due to being kicked out of idle, the other CPUs leave their NOHZ states,
    which means the tick is active and the corresponding hrtimer is programmed
    to the next jiffie.
    
    On entering s2idle the CPUs shut down their local clockevent device to
    prevent wakeups. The last CPU which enters s2idle shuts down its local
    clockevent and freezes timekeeping.
    
    On resume, one of the CPUs receives the wakeup interrupt, unfreezes
    timekeeping and its local clockevent and starts the resume process. At that
    point all other CPUs are still in s2idle with their clockevents switched
    off. They only resume when they are kicked by another CPU or after resuming
    devices and then receiving a device interrupt.
    
    That means there is no guarantee that all CPUs will wakeup directly on
    resume. As a consequence there is no guarantee that timers which are queued
    on those CPUs and should expire directly after resume, are handled. Also
    timer list timers which are remotely queued to one of those CPUs after
    resume will not result in a reprogramming IPI as the tick is
    active. Queueing a hrtimer will also not result in a reprogramming IPI
    because the first hrtimer event is already in the past.
    
    The recent introduction of the timer pull model (7ee988770326 ("timers:
    Implement the hierarchical pull model")) amplifies this problem, if the
    current migrator is one of the non woken up CPUs. When a non pinned timer
    list timer is queued and the queuing CPU goes idle, it relies on the still
    suspended migrator CPU to expire the timer which will happen by chance.
    
    The problem exists since commit 8d89835b0467 ("PM: suspend: Do not pause
    cpuidle in the suspend-to-idle path"). There the cpuidle_pause() call which
    in turn invoked a wakeup for all idle CPUs was moved to a later point in
    the resume process. This might not be reached or reached very late because
    it waits on a timer of a still suspended CPU.
    
    Address this by kicking all CPUs out of idle after the control CPU returns
    from swait() so that they resume their timers and restore consistent system
    state.
    
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218641
    Fixes: 8d89835b0467 ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path")
    Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Mario Limonciello <mario.limonciello@amd.com>
    Cc: 5.16+ <stable@kernel.org> # 5.16+
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
raid1: fix use-after-free for original bio in raid1_write_request() [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Fri Mar 8 17:37:26 2024 +0800

    raid1: fix use-after-free for original bio in raid1_write_request()
    
    commit fcf3f7e2fc8a53a6140beee46ec782a4c88e4744 upstream.
    
    r1_bio->bios[] is used to record new bios that will be issued to
    underlying disks, however, in raid1_write_request(), r1_bio->bios[]
    will set to the original bio temporarily. Meanwhile, if blocked rdev
    is set, free_r1bio() will be called causing that all r1_bio->bios[]
    to be freed:
    
    raid1_write_request()
     r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL
     for (i = 0;  i < disks; i++) -> for each rdev in conf
      // first rdev is normal
      r1_bio->bios[0] = bio; -> set to original bio
      // second rdev is blocked
      if (test_bit(Blocked, &rdev->flags))
       break
    
     if (blocked_rdev)
      free_r1bio()
       put_all_bios()
        bio_put(r1_bio->bios[0]) -> original bio is freed
    
    Test scripts:
    
    mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean
    fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \
        -iodepth=128 -name=test -direct=1
    echo blocked > /sys/block/md0/md/rd2/state
    
    Test result:
    
    BUG bio-264 (Not tainted): Object already free
    -----------------------------------------------------------------------------
    
    Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869
     kmem_cache_alloc+0x324/0x480
     mempool_alloc_slab+0x24/0x50
     mempool_alloc+0x6e/0x220
     bio_alloc_bioset+0x1af/0x4d0
     blkdev_direct_IO+0x164/0x8a0
     blkdev_write_iter+0x309/0x440
     aio_write+0x139/0x2f0
     io_submit_one+0x5ca/0xb70
     __do_sys_io_submit+0x86/0x270
     __x64_sys_io_submit+0x22/0x30
     do_syscall_64+0xb1/0x210
     entry_SYSCALL_64_after_hwframe+0x6c/0x74
    Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869
     kmem_cache_free+0x28c/0x550
     mempool_free_slab+0x1f/0x30
     mempool_free+0x40/0x100
     bio_free+0x59/0x80
     bio_put+0xf0/0x220
     free_r1bio+0x74/0xb0
     raid1_make_request+0xadf/0x1150
     md_handle_request+0xc7/0x3b0
     md_submit_bio+0x76/0x130
     __submit_bio+0xd8/0x1d0
     submit_bio_noacct_nocheck+0x1eb/0x5c0
     submit_bio_noacct+0x169/0xd40
     submit_bio+0xee/0x1d0
     blkdev_direct_IO+0x322/0x8a0
     blkdev_write_iter+0x309/0x440
     aio_write+0x139/0x2f0
    
    Since that bios for underlying disks are not allocated yet, fix this
    problem by using mempool_free() directly to free the r1_bio.
    
    Fixes: 992db13a4aee ("md/raid1: free the r1bio before waiting for blocked rdev")
    Cc: stable@vger.kernel.org # v6.6+
    Reported-by: Coly Li <colyli@suse.de>
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Tested-by: Coly Li <colyli@suse.de>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240308093726.1047420-1-yukuai1@huaweicloud.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "drm/qxl: simplify qxl_fence_wait" [+ + +]
Author: Alex Constantino <dreaming.about.electric.sheep@gmail.com>
Date:   Thu Apr 4 19:14:48 2024 +0100

    Revert "drm/qxl: simplify qxl_fence_wait"
    
    [ Upstream commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea ]
    
    This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
    
    Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
    result in a '[TTM] Buffer eviction failed' exception whenever it reached a
    timeout.
    Due to a dependency to DMA_FENCE_WARN this also restores some code deleted
    by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2").
    
    Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
    Link: https://lore.kernel.org/regressions/ZTgydqRlK6WX_b29@eldamar.lan/
    Reported-by: Timo Lindfors <timo.lindfors@iki.fi>
    Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514
    Signed-off-by: Alex Constantino <dreaming.about.electric.sheep@gmail.com>
    Signed-off-by: Maxime Ripard <mripard@kernel.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240404181448.1643-2-dreaming.about.electric.sheep@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "s390/ism: fix receive message buffer allocation" [+ + +]
Author: Gerd Bayer <gbayer@linux.ibm.com>
Date:   Tue Apr 9 13:37:53 2024 +0200

    Revert "s390/ism: fix receive message buffer allocation"
    
    [ Upstream commit d51dc8dd6ab6f93a894ff8b38d3b8d02c98eb9fb ]
    
    This reverts commit 58effa3476536215530c9ec4910ffc981613b413.
    Review was not finished on this patch. So it's not ready for
    upstreaming.
    
    Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240409113753.2181368-1-gbayer@linux.ibm.com
    Fixes: 58effa347653 ("s390/ism: fix receive message buffer allocation")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ring-buffer: Only update pages_touched when a new page is touched [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Apr 9 15:13:09 2024 -0400

    ring-buffer: Only update pages_touched when a new page is touched
    
    commit ffe3986fece696cf65e0ef99e74c75f848be8e30 upstream.
    
    The "buffer_percent" logic that is used by the ring buffer splice code to
    only wake up the tasks when there's no data after the buffer is filled to
    the percentage of the "buffer_percent" file is dependent on three
    variables that determine the amount of data that is in the ring buffer:
    
     1) pages_read - incremented whenever a new sub-buffer is consumed
     2) pages_lost - incremented every time a writer overwrites a sub-buffer
     3) pages_touched - incremented when a write goes to a new sub-buffer
    
    The percentage is the calculation of:
    
      (pages_touched - (pages_lost + pages_read)) / nr_pages
    
    Basically, the amount of data is the total number of sub-bufs that have been
    touched, minus the number of sub-bufs lost and sub-bufs consumed. This is
    divided by the total count to give the buffer percentage. When the
    percentage is greater than the value in the "buffer_percent" file, it
    wakes up splice readers waiting for that amount.
    
    It was observed that over time, the amount read from the splice was
    constantly decreasing the longer the trace was running. That is, if one
    asked for 60%, it would read over 60% when it first starts tracing, but
    then it would be woken up at under 60% and would slowly decrease the
    amount of data read after being woken up, where the amount becomes much
    less than the buffer percent.
    
    This was due to an accounting of the pages_touched incrementation. This
    value is incremented whenever a writer transfers to a new sub-buffer. But
    the place where it was incremented was incorrect. If a writer overflowed
    the current sub-buffer it would go to the next one. If it gets preempted
    by an interrupt at that time, and the interrupt performs a trace, it too
    will end up going to the next sub-buffer. But only one should increment
    the counter. Unfortunately, that was not the case.
    
    Change the cmpxchg() that does the real switch of the tail-page into a
    try_cmpxchg(), and on success, perform the increment of pages_touched. This
    will only increment the counter once for when the writer moves to a new
    sub-buffer, and not when there's a race and is incremented for when a
    writer and its preempting writer both move to the same new sub-buffer.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240409151309.0d0e5056@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Fixes: 2c2b0a78b3739 ("ring-buffer: Add percentage of ring buffer full to wake up reader")
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/ism: fix receive message buffer allocation [+ + +]
Author: Gerd Bayer <gbayer@linux.ibm.com>
Date:   Fri Apr 5 13:16:06 2024 +0200

    s390/ism: fix receive message buffer allocation
    
    [ Upstream commit 58effa3476536215530c9ec4910ffc981613b413 ]
    
    Since [1], dma_alloc_coherent() does not accept requests for GFP_COMP
    anymore, even on archs that may be able to fulfill this. Functionality that
    relied on the receive buffer being a compound page broke at that point:
    The SMC-D protocol, that utilizes the ism device driver, passes receive
    buffers to the splice processor in a struct splice_pipe_desc with a
    single entry list of struct pages. As the buffer is no longer a compound
    page, the splice processor now rejects requests to handle more than a
    page worth of data.
    
    Replace dma_alloc_coherent() and allocate a buffer with folio_alloc and
    create a DMA map for it with dma_map_page(). Since only receive buffers
    on ISM devices use DMA, qualify the mapping as FROM_DEVICE.
    Since ISM devices are available on arch s390, only and on that arch all
    DMA is coherent, there is no need to introduce and export some kind of
    dma_sync_to_cpu() method to be called by the SMC-D protocol layer.
    
    Analogously, replace dma_free_coherent by a two step dma_unmap_page,
    then folio_put to free the receive buffer.
    
    [1] https://lore.kernel.org/all/20221113163535.884299-1-hch@lst.de/
    
    Fixes: c08004eede4b ("s390/ism: don't pass bogus GFP_ flags to dma_alloc_coherent")
    Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: hisi_sas: Modify the deadline for ata_wait_after_reset() [+ + +]
Author: Xiang Chen <chenxiang66@hisilicon.com>
Date:   Tue Apr 2 11:55:13 2024 +0800

    scsi: hisi_sas: Modify the deadline for ata_wait_after_reset()
    
    [ Upstream commit 0098c55e0881f0b32591f2110410d5c8b7f9bd5a ]
    
    We found that the second parameter of function ata_wait_after_reset() is
    incorrectly used. We call smp_ata_check_ready_type() to poll the device
    type until the 30s timeout, so the correct deadline should be (jiffies +
    30000).
    
    Fixes: 3c2673a09cf1 ("scsi: hisi_sas: Fix SATA devices missing issue during I_T nexus reset")
    Co-developed-by: xiabing <xiabing12@h-partners.com>
    Signed-off-by: xiabing <xiabing12@h-partners.com>
    Co-developed-by: Yihang Li <liyihang9@huawei.com>
    Signed-off-by: Yihang Li <liyihang9@huawei.com>
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Link: https://lore.kernel.org/r/20240402035513.2024241-3-chenxiang66@hisilicon.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: Fix off by one in qla_edif_app_getstats() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Apr 2 12:56:54 2024 +0300

    scsi: qla2xxx: Fix off by one in qla_edif_app_getstats()
    
    [ Upstream commit 4406e4176f47177f5e51b4cc7e6a7a2ff3dbfbbd ]
    
    The app_reply->elem[] array is allocated earlier in this function and it
    has app_req.num_ports elements.  Thus this > comparison needs to be >= to
    prevent memory corruption.
    
    Fixes: 7878f22a2e03 ("scsi: qla2xxx: edif: Add getfcinfo and statistic bsgs")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/5c125b2f-92dd-412b-9b6f-fc3a3207bd60@moroto.mountain
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: sg: Avoid race in error handling & drop bogus warn [+ + +]
Author: Alexander Wetzel <Alexander@wetzel-home.de>
Date:   Mon Apr 1 21:10:38 2024 +0200

    scsi: sg: Avoid race in error handling & drop bogus warn
    
    commit d4e655c49f474deffaf5ed7e65034b8167ee39c8 upstream.
    
    Commit 27f58c04a8f4 ("scsi: sg: Avoid sg device teardown race") introduced
    an incorrect WARN_ON_ONCE() and missed a sequence where sg_device_destroy()
    was used after scsi_device_put().
    
    sg_device_destroy() is accessing the parent scsi_device request_queue which
    will already be set to NULL when the preceding call to scsi_device_put()
    removed the last reference to the parent scsi_device.
    
    Drop the incorrect WARN_ON_ONCE() - allowing more than one concurrent
    access to the sg device - and make sure sg_device_destroy() is not used
    after scsi_device_put() in the error handling.
    
    Link: https://lore.kernel.org/all/5375B275-D137-4D5F-BE25-6AF8ACAE41EF@linux.ibm.com
    Fixes: 27f58c04a8f4 ("scsi: sg: Avoid sg device teardown race")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de>
    Link: https://lore.kernel.org/r/20240401191038.18359-1-Alexander@wetzel-home.de
    Tested-by: Sachin Sant <sachinp@linux.ibm.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: sg: Avoid sg device teardown race [+ + +]
Author: Alexander Wetzel <Alexander@wetzel-home.de>
Date:   Wed Mar 20 22:30:32 2024 +0100

    scsi: sg: Avoid sg device teardown race
    
    commit 27f58c04a8f438078583041468ec60597841284d upstream.
    
    sg_remove_sfp_usercontext() must not use sg_device_destroy() after calling
    scsi_device_put().
    
    sg_device_destroy() is accessing the parent scsi_device request_queue which
    will already be set to NULL when the preceding call to scsi_device_put()
    removed the last reference to the parent scsi_device.
    
    The resulting NULL pointer exception will then crash the kernel.
    
    Link: https://lore.kernel.org/r/20240305150509.23896-1-Alexander@wetzel-home.de
    Fixes: db59133e9279 ("scsi: sg: fix blktrace debugfs entries leakage")
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de>
    Link: https://lore.kernel.org/r/20240320213032.18221-1-Alexander@wetzel-home.de
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests: mptcp: use += operator to append strings [+ + +]
Author: Geliang Tang <tanggeliang@kylinos.cn>
Date:   Fri Mar 8 23:10:15 2024 +0100

    selftests: mptcp: use += operator to append strings
    
    commit e7c42bf4d320affe37337aa83ae0347832b3f568 upstream.
    
    This patch uses addition assignment operator (+=) to append strings
    instead of duplicating the variable name in mptcp_connect.sh and
    mptcp_join.sh.
    
    This can make the statements shorter.
    
    Note: in mptcp_connect.sh, add a local variable extra in do_transfer to
    save the various extra warning logs, using += to append it. And add a
    new variable tc_info to save various tc info, also using += to append it.
    This can make the code more readable and prepare for the next commit.
    
    Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240308-upstream-net-next-20240308-selftests-mptcp-unification-v1-8-4f42c347b653@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ Conflicts in mptcp_connect.sh: this commit was supposed to be
      backported before commit 7a1b3490f47e ("mptcp: don't account accept()
      of non-MPC client as fallback to TCP"). The new condition added by
      this commit was then not expected, and was in fact at the wrong place
      in v6.6: in case of issue, the problem would not have been reported
      correctly. ]
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: timers: Fix abs() warning in posix_timers test [+ + +]
Author: John Stultz <jstultz@google.com>
Date:   Wed Apr 10 16:26:30 2024 -0700

    selftests: timers: Fix abs() warning in posix_timers test
    
    commit ed366de8ec89d4f960d66c85fc37d9de22f7bf6d upstream.
    
    Building with clang results in the following warning:
    
      posix_timers.c:69:6: warning: absolute value function 'abs' given an
          argument of type 'long long' but has parameter of type 'int' which may
          cause truncation of value [-Wabsolute-value]
            if (abs(diff - DELAY * USECS_PER_SEC) > USECS_PER_SEC / 2) {
                ^
    So switch to using llabs() instead.
    
    Fixes: 0bc4b0cf1570 ("selftests: add basic posix timers selftests")
    Signed-off-by: John Stultz <jstultz@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240410232637.4135564-3-jstultz@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
smb3: fix Open files on server counter going negative [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Sat Apr 6 23:16:08 2024 -0500

    smb3: fix Open files on server counter going negative
    
    commit 28e0947651ce6a2200b9a7eceb93282e97d7e51a upstream.
    
    We were decrementing the count of open files on server twice
    for the case where we were closing cached directories.
    
    Fixes: 8e843bf38f7b ("cifs: return a single-use cfid if we did not get a lease")
    Cc: stable@vger.kernel.org
    Acked-by: Bharath SM <bharathsm@microsoft.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
tracing: hide unused ftrace_event_id_fops [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Apr 3 10:06:24 2024 +0200

    tracing: hide unused ftrace_event_id_fops
    
    [ Upstream commit 5281ec83454d70d98b71f1836fb16512566c01cd ]
    
    When CONFIG_PERF_EVENTS, a 'make W=1' build produces a warning about the
    unused ftrace_event_id_fops variable:
    
    kernel/trace/trace_events.c:2155:37: error: 'ftrace_event_id_fops' defined but not used [-Werror=unused-const-variable=]
     2155 | static const struct file_operations ftrace_event_id_fops = {
    
    Hide this in the same #ifdef as the reference to it.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240403080702.3509288-7-arnd@kernel.org
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Zheng Yejian <zhengyejian1@huawei.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Ajay Kaher <akaher@vmware.com>
    Cc: Jinjie Ruan <ruanjinjie@huawei.com>
    Cc: Clément Léger <cleger@rivosinc.com>
    Cc: Dan Carpenter <dan.carpenter@linaro.org>
    Cc: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
    Fixes: 620a30e97feb ("tracing: Don't pass file_operations array to event_create_dir()")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
u64_stats: fix u64_stats_init() for lockdep when used repeatedly in one file [+ + +]
Author: Petr Tesarik <petr@tesarici.cz>
Date:   Thu Apr 4 09:57:40 2024 +0200

    u64_stats: fix u64_stats_init() for lockdep when used repeatedly in one file
    
    [ Upstream commit 38a15d0a50e0a43778561a5861403851f0b0194c ]
    
    Fix bogus lockdep warnings if multiple u64_stats_sync variables are
    initialized in the same file.
    
    With CONFIG_LOCKDEP, seqcount_init() is a macro which declares:
    
            static struct lock_class_key __key;
    
    Since u64_stats_init() is a function (albeit an inline one), all calls
    within the same file end up using the same instance, effectively treating
    them all as a single lock-class.
    
    Fixes: 9464ca650008 ("net: make u64_stats_init() a function")
    Closes: https://lore.kernel.org/netdev/ea1567d9-ce66-45e6-8168-ac40a47d1821@roeck-us.net/
    Signed-off-by: Petr Tesarik <petr@tesarici.cz>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20240404075740.30682-1-petr@tesarici.cz
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vhost: Add smp_rmb() in vhost_enable_notify() [+ + +]
Author: Gavin Shan <gshan@redhat.com>
Date:   Thu Mar 28 10:21:48 2024 +1000

    vhost: Add smp_rmb() in vhost_enable_notify()
    
    commit df9ace7647d4123209395bb9967e998d5758c645 upstream.
    
    A smp_rmb() has been missed in vhost_enable_notify(), inspired by
    Will. Otherwise, it's not ensured the available ring entries pushed
    by guest can be observed by vhost in time, leading to stale available
    ring entries fetched by vhost in vhost_get_vq_desc(), as reported by
    Yihuang Yu on NVidia's grace-hopper (ARM64) platform.
    
      /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64      \
      -accel kvm -machine virt,gic-version=host -cpu host          \
      -smp maxcpus=1,cpus=1,sockets=1,clusters=1,cores=1,threads=1 \
      -m 4096M,slots=16,maxmem=64G                                 \
      -object memory-backend-ram,id=mem0,size=4096M                \
       :                                                           \
      -netdev tap,id=vnet0,vhost=true                              \
      -device virtio-net-pci,bus=pcie.8,netdev=vnet0,mac=52:54:00:f1:26:b0
       :
      guest# netperf -H 10.26.1.81 -l 60 -C -c -t UDP_STREAM
      virtio_net virtio0: output.0:id 100 is not a head!
    
    Add the missed smp_rmb() in vhost_enable_notify(). When it returns true,
    it means there's still pending tx buffers. Since it might read indices,
    so it still can bypass the smp_rmb() in vhost_get_vq_desc(). Note that
    it should be safe until vq->avail_idx is changed by commit d3bb267bbdcb
    ("vhost: cache avail index in vhost_enable_notify()").
    
    Fixes: d3bb267bbdcb ("vhost: cache avail index in vhost_enable_notify()")
    Cc: <stable@kernel.org> # v5.18+
    Reported-by: Yihuang Yu <yihyu@redhat.com>
    Suggested-by: Will Deacon <will@kernel.org>
    Signed-off-by: Gavin Shan <gshan@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Message-Id: <20240328002149.1141302-3-gshan@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vhost: Add smp_rmb() in vhost_vq_avail_empty() [+ + +]
Author: Gavin Shan <gshan@redhat.com>
Date:   Thu Mar 28 10:21:47 2024 +1000

    vhost: Add smp_rmb() in vhost_vq_avail_empty()
    
    commit 22e1992cf7b034db5325660e98c41ca5afa5f519 upstream.
    
    A smp_rmb() has been missed in vhost_vq_avail_empty(), spotted by
    Will. Otherwise, it's not ensured the available ring entries pushed
    by guest can be observed by vhost in time, leading to stale available
    ring entries fetched by vhost in vhost_get_vq_desc(), as reported by
    Yihuang Yu on NVidia's grace-hopper (ARM64) platform.
    
      /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64      \
      -accel kvm -machine virt,gic-version=host -cpu host          \
      -smp maxcpus=1,cpus=1,sockets=1,clusters=1,cores=1,threads=1 \
      -m 4096M,slots=16,maxmem=64G                                 \
      -object memory-backend-ram,id=mem0,size=4096M                \
       :                                                           \
      -netdev tap,id=vnet0,vhost=true                              \
      -device virtio-net-pci,bus=pcie.8,netdev=vnet0,mac=52:54:00:f1:26:b0
       :
      guest# netperf -H 10.26.1.81 -l 60 -C -c -t UDP_STREAM
      virtio_net virtio0: output.0:id 100 is not a head!
    
    Add the missed smp_rmb() in vhost_vq_avail_empty(). When tx_can_batch()
    returns true, it means there's still pending tx buffers. Since it might
    read indices, so it still can bypass the smp_rmb() in vhost_get_vq_desc().
    Note that it should be safe until vq->avail_idx is changed by commit
    275bf960ac697 ("vhost: better detection of available buffers").
    
    Fixes: 275bf960ac69 ("vhost: better detection of available buffers")
    Cc: <stable@kernel.org> # v4.11+
    Reported-by: Yihuang Yu <yihyu@redhat.com>
    Suggested-by: Will Deacon <will@kernel.org>
    Signed-off-by: Gavin Shan <gshan@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Message-Id: <20240328002149.1141302-2-gshan@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/apic: Force native_apic_mem_read() to use the MOV instruction [+ + +]
Author: Adam Dunlap <acdunlap@google.com>
Date:   Mon Mar 18 16:09:27 2024 -0700

    x86/apic: Force native_apic_mem_read() to use the MOV instruction
    
    commit 5ce344beaca688f4cdea07045e0b8f03dc537e74 upstream.
    
    When done from a virtual machine, instructions that touch APIC memory
    must be emulated. By convention, MMIO accesses are typically performed
    via io.h helpers such as readl() or writeq() to simplify instruction
    emulation/decoding (ex: in KVM hosts and SEV guests) [0].
    
    Currently, native_apic_mem_read() does not follow this convention,
    allowing the compiler to emit instructions other than the MOV
    instruction generated by readl(). In particular, when the kernel is
    compiled with clang and run as a SEV-ES or SEV-SNP guest, the compiler
    would emit a TESTL instruction which is not supported by the SEV-ES
    emulator, causing a boot failure in that environment. It is likely the
    same problem would happen in a TDX guest as that uses the same
    instruction emulator as SEV-ES.
    
    To make sure all emulators can emulate APIC memory reads via MOV, use
    the readl() function in native_apic_mem_read(). It is expected that any
    emulator would support MOV in any addressing mode as it is the most
    generic and is what is usually emitted currently.
    
    The TESTL instruction is emitted when native_apic_mem_read() is inlined
    into apic_mem_wait_icr_idle(). The emulator comes from
    insn_decode_mmio() in arch/x86/lib/insn-eval.c. It's not worth it to
    extend insn_decode_mmio() to support more instructions since, in theory,
    the compiler could choose to output nearly any instruction for such
    reads which would bloat the emulator beyond reason.
    
      [0] https://lore.kernel.org/all/20220405232939.73860-12-kirill.shutemov@linux.intel.com/
    
      [ bp: Massage commit message, fix typos. ]
    
    Signed-off-by: Adam Dunlap <acdunlap@google.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Tested-by: Kevin Loughlin <kevinloughlin@google.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20240318230927.2191933-1-acdunlap@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/bugs: Cache the value of MSR_IA32_ARCH_CAPABILITIES [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Wed Apr 10 22:40:46 2024 -0700

    x86/bugs: Cache the value of MSR_IA32_ARCH_CAPABILITIES
    
    commit cb2db5bb04d7f778fbc1a1ea2507aab436f1bff3 upstream.
    
    There's no need to keep reading MSR_IA32_ARCH_CAPABILITIES over and
    over.  It's even read in the BHI sysfs function which is a big no-no.
    Just read it once and cache it.
    
    Fixes: ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Sean Christopherson <seanjc@google.com>
    Link: https://lore.kernel.org/r/9592a18a814368e75f8f4b9d74d3883aa4fd1eaf.1712813475.git.jpoimboe@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/bugs: Clarify that syscall hardening isn't a BHI mitigation [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Wed Apr 10 22:40:48 2024 -0700

    x86/bugs: Clarify that syscall hardening isn't a BHI mitigation
    
    commit 5f882f3b0a8bf0788d5a0ee44b1191de5319bb8a upstream.
    
    While syscall hardening helps prevent some BHI attacks, there's still
    other low-hanging fruit remaining.  Don't classify it as a mitigation
    and make it clear that the system may still be vulnerable if it doesn't
    have a HW or SW mitigation enabled.
    
    Fixes: ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Sean Christopherson <seanjc@google.com>
    Link: https://lore.kernel.org/r/b5951dae3fdee7f1520d5136a27be3bdfe95f88b.1712813475.git.jpoimboe@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/bugs: Fix BHI documentation [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Wed Apr 10 22:40:45 2024 -0700

    x86/bugs: Fix BHI documentation
    
    commit dfe648903f42296866d79f10d03f8c85c9dfba30 upstream.
    
    Fix up some inaccuracies in the BHI documentation.
    
    Fixes: ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Sean Christopherson <seanjc@google.com>
    Link: https://lore.kernel.org/r/8c84f7451bfe0dd08543c6082a383f390d4aa7e2.1712813475.git.jpoimboe@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/bugs: Fix BHI handling of RRSBA [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Wed Apr 10 22:40:47 2024 -0700

    x86/bugs: Fix BHI handling of RRSBA
    
    commit 1cea8a280dfd1016148a3820676f2f03e3f5b898 upstream.
    
    The ARCH_CAP_RRSBA check isn't correct: RRSBA may have already been
    disabled by the Spectre v2 mitigation (or can otherwise be disabled by
    the BHI mitigation itself if needed).  In that case retpolines are fine.
    
    Fixes: ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Sean Christopherson <seanjc@google.com>
    Link: https://lore.kernel.org/r/6f56f13da34a0834b69163467449be7f58f253dc.1712813475.git.jpoimboe@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/bugs: Fix return type of spectre_bhi_state() [+ + +]
Author: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Date:   Tue Apr 9 16:08:05 2024 -0700

    x86/bugs: Fix return type of spectre_bhi_state()
    
    commit 04f4230e2f86a4e961ea5466eda3db8c1762004d upstream.
    
    The definition of spectre_bhi_state() incorrectly returns a const char
    * const. This causes the a compiler warning when building with W=1:
    
     warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
     2812 | static const char * const spectre_bhi_state(void)
    
    Remove the const qualifier from the pointer.
    
    Fixes: ec9404e40e8f ("x86/bhi: Add BHI mitigation knob")
    Reported-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://lore.kernel.org/r/20240409230806.1545822-1-daniel.sneddon@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/bugs: Remove CONFIG_BHI_MITIGATION_AUTO and spectre_bhi=auto [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Wed Apr 10 22:40:50 2024 -0700

    x86/bugs: Remove CONFIG_BHI_MITIGATION_AUTO and spectre_bhi=auto
    
    commit 36d4fe147c870f6d3f6602befd7ef44393a1c87a upstream.
    
    Unlike most other mitigations' "auto" options, spectre_bhi=auto only
    mitigates newer systems, which is confusing and not particularly useful.
    
    Remove it.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://lore.kernel.org/r/412e9dc87971b622bbbaf64740ebc1f140bff343.1712813475.git.jpoimboe@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/bugs: Rename various 'ia32_cap' variables to 'x86_arch_cap_msr' [+ + +]
Author: Ingo Molnar <mingo@kernel.org>
Date:   Thu Apr 11 09:25:36 2024 +0200

    x86/bugs: Rename various 'ia32_cap' variables to 'x86_arch_cap_msr'
    
    commit d0485730d2189ffe5d986d4e9e191f1e4d5ffd24 upstream.
    
    So we are using the 'ia32_cap' value in a number of places,
    which got its name from MSR_IA32_ARCH_CAPABILITIES MSR register.
    
    But there's very little 'IA32' about it - this isn't 32-bit only
    code, nor does it originate from there, it's just a historic
    quirk that many Intel MSR names are prefixed with IA32_.
    
    This is already clear from the helper method around the MSR:
    x86_read_arch_cap_msr(), which doesn't have the IA32 prefix.
    
    So rename 'ia32_cap' to 'x86_arch_cap_msr' to be consistent with
    its role and with the naming of the helper function.
    
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Nikolay Borisov <nik.borisov@suse.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Sean Christopherson <seanjc@google.com>
    Link: https://lore.kernel.org/r/9592a18a814368e75f8f4b9d74d3883aa4fd1eaf.1712813475.git.jpoimboe@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/bugs: Replace CONFIG_SPECTRE_BHI_{ON,OFF} with CONFIG_MITIGATION_SPECTRE_BHI [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Wed Apr 10 22:40:51 2024 -0700

    x86/bugs: Replace CONFIG_SPECTRE_BHI_{ON,OFF} with CONFIG_MITIGATION_SPECTRE_BHI
    
    commit 4f511739c54b549061993b53fc0380f48dfca23b upstream.
    
    For consistency with the other CONFIG_MITIGATION_* options, replace the
    CONFIG_SPECTRE_BHI_{ON,OFF} options with a single
    CONFIG_MITIGATION_SPECTRE_BHI option.
    
    [ mingo: Fix ]
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Sean Christopherson <seanjc@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Nikolay Borisov <nik.borisov@suse.com>
    Link: https://lore.kernel.org/r/3833812ea63e7fdbe36bf8b932e63f70d18e2a2a.1712813475.git.jpoimboe@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/cpu: Actually turn off mitigations by default for SPECULATION_MITIGATIONS=n [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Apr 9 10:51:05 2024 -0700

    x86/cpu: Actually turn off mitigations by default for SPECULATION_MITIGATIONS=n
    
    commit f337a6a21e2fd67eadea471e93d05dd37baaa9be upstream.
    
    Initialize cpu_mitigations to CPU_MITIGATIONS_OFF if the kernel is built
    with CONFIG_SPECULATION_MITIGATIONS=n, as the help text quite clearly
    states that disabling SPECULATION_MITIGATIONS is supposed to turn off all
    mitigations by default.
    
      │ If you say N, all mitigations will be disabled. You really
      │ should know what you are doing to say so.
    
    As is, the kernel still defaults to CPU_MITIGATIONS_AUTO, which results in
    some mitigations being enabled in spite of SPECULATION_MITIGATIONS=n.
    
    Fixes: f43b9876e857 ("x86/retbleed: Add fine grained Kconfig knobs")
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
    Cc: stable@vger.kernel.org
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://lore.kernel.org/r/20240409175108.1512861-2-seanjc@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Apr 4 20:27:38 2024 +0000

    xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
    
    [ Upstream commit 237f3cf13b20db183d3706d997eedc3c49eacd44 ]
    
    syzbot reported an illegal copy in xsk_setsockopt() [1]
    
    Make sure to validate setsockopt() @optlen parameter.
    
    [1]
    
     BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
     BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
     BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
    Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
    
    CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
      print_address_description mm/kasan/report.c:377 [inline]
      print_report+0x169/0x550 mm/kasan/report.c:488
      kasan_report+0x143/0x180 mm/kasan/report.c:601
      copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
      copy_from_sockptr include/linux/sockptr.h:55 [inline]
      xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
      do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
      __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
      __do_sys_setsockopt net/socket.c:2343 [inline]
      __se_sys_setsockopt net/socket.c:2340 [inline]
      __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
     do_syscall_64+0xfb/0x240
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    RIP: 0033:0x7fb40587de69
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
    RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69
    RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006
    RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000
    R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08
     </TASK>
    
    Allocated by task 7549:
      kasan_save_stack mm/kasan/common.c:47 [inline]
      kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
      poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
      __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
      kasan_kmalloc include/linux/kasan.h:211 [inline]
      __do_kmalloc_node mm/slub.c:3966 [inline]
      __kmalloc+0x233/0x4a0 mm/slub.c:3979
      kmalloc include/linux/slab.h:632 [inline]
      __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869
      do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
      __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
      __do_sys_setsockopt net/socket.c:2343 [inline]
      __se_sys_setsockopt net/socket.c:2340 [inline]
      __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
     do_syscall_64+0xfb/0x240
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    The buggy address belongs to the object at ffff888028c6cde0
     which belongs to the cache kmalloc-8 of size 8
    The buggy address is located 1 bytes to the right of
     allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
    
    The buggy address belongs to the physical page:
    page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c
    anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
    page_type: 0xffffffff()
    raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001
    raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223
      set_page_owner include/linux/page_owner.h:31 [inline]
      post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533
      prep_new_page mm/page_alloc.c:1540 [inline]
      get_page_from_freelist+0x33ea/0x3580 mm/page_alloc.c:3311
      __alloc_pages+0x256/0x680 mm/page_alloc.c:4569
      __alloc_pages_node include/linux/gfp.h:238 [inline]
      alloc_pages_node include/linux/gfp.h:261 [inline]
      alloc_slab_page+0x5f/0x160 mm/slub.c:2175
      allocate_slab mm/slub.c:2338 [inline]
      new_slab+0x84/0x2f0 mm/slub.c:2391
      ___slab_alloc+0xc73/0x1260 mm/slub.c:3525
      __slab_alloc mm/slub.c:3610 [inline]
      __slab_alloc_node mm/slub.c:3663 [inline]
      slab_alloc_node mm/slub.c:3835 [inline]
      __do_kmalloc_node mm/slub.c:3965 [inline]
      __kmalloc_node+0x2db/0x4e0 mm/slub.c:3973
      kmalloc_node include/linux/slab.h:648 [inline]
      __vmalloc_area_node mm/vmalloc.c:3197 [inline]
      __vmalloc_node_range+0x5f9/0x14a0 mm/vmalloc.c:3392
      __vmalloc_node mm/vmalloc.c:3457 [inline]
      vzalloc+0x79/0x90 mm/vmalloc.c:3530
      bpf_check+0x260/0x19010 kernel/bpf/verifier.c:21162
      bpf_prog_load+0x1667/0x20f0 kernel/bpf/syscall.c:2895
      __sys_bpf+0x4ee/0x810 kernel/bpf/syscall.c:5631
      __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
    page last free pid 6650 tgid 6647 stack trace:
      reset_page_owner include/linux/page_owner.h:24 [inline]
      free_pages_prepare mm/page_alloc.c:1140 [inline]
      free_unref_page_prepare+0x95d/0xa80 mm/page_alloc.c:2346
      free_unref_page_list+0x5a3/0x850 mm/page_alloc.c:2532
      release_pages+0x2117/0x2400 mm/swap.c:1042
      tlb_batch_pages_flush mm/mmu_gather.c:98 [inline]
      tlb_flush_mmu_free mm/mmu_gather.c:293 [inline]
      tlb_flush_mmu+0x34d/0x4e0 mm/mmu_gather.c:300
      tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:392
      exit_mmap+0x4b6/0xd40 mm/mmap.c:3300
      __mmput+0x115/0x3c0 kernel/fork.c:1345
      exit_mm+0x220/0x310 kernel/exit.c:569
      do_exit+0x99e/0x27e0 kernel/exit.c:865
      do_group_exit+0x207/0x2c0 kernel/exit.c:1027
      get_signal+0x176e/0x1850 kernel/signal.c:2907
      arch_do_signal_or_restart+0x96/0x860 arch/x86/kernel/signal.c:310
      exit_to_user_mode_loop kernel/entry/common.c:105 [inline]
      exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]
      __syscall_exit_to_user_mode_work kernel/entry/common.c:201 [inline]
      syscall_exit_to_user_mode+0xc9/0x360 kernel/entry/common.c:212
      do_syscall_64+0x10a/0x240 arch/x86/entry/common.c:89
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    Memory state around the buggy address:
     ffff888028c6cc80: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
     ffff888028c6cd00: fa fc fc fc fa fc fc fc 00 fc fc fc 06 fc fc fc
    >ffff888028c6cd80: fa fc fc fc fa fc fc fc fa fc fc fc 02 fc fc fc
                                                           ^
     ffff888028c6ce00: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
     ffff888028c6ce80: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
    
    Fixes: 423f38329d26 ("xsk: add umem fill queue support and mmap")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: "Björn Töpel" <bjorn@kernel.org>
    Cc: Magnus Karlsson <magnus.karlsson@intel.com>
    Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
    Acked-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/r/20240404202738.3634547-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>